Palvelinten hallinta kotitehtävät 4 (Syksy 2017)


Palvelinten hallinta kotitehtävät 4 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

Viikon harjoitusten tavoitteena oli kokeilla Puppetin lisäksi kahta muuta keskitetyn hallinnan järjestelmää, Ansiblea ja Salt:ia.

Molemmat järjestelmät asennettiin ja niiden toimintaa testattiin yksinkertaisen “moduulin” avulla.

 

a) Kokeile Ansiblea

 

Testilaitteistona kaksi kappaletta Hyper-V:llä luotuja virtuaalikoneita, joille oli asennettu 64-bittinen Xubuntu 16.04.3 LTS versiot. Tavoitteena oli asentaa koneelle 1 Ansible ja määritellä asetukset niin, että luotu yksinkertainen moduuli voitiin ajaa koneella 2.

Harjoitus aloitettiin asentamalla “herra” -koneelle Ansible ja OpenSSH suojausavainten luontia varten

$ sudo apt-get update

$ sudo apt-get -y install openssh-server openssh-client ssh ansible

Seuraavaksi määriteltiin “orja” -virtuaalikoneen IP-osoite Ansiblen hosts -tiedostoon ryhmän [orja] alle

$ sudoedit /etc/ansible/hosts

 

Toiselle virtuaalikoneelle asennettiin samat SSH-ohjelmat, mutta Ansiblea ei tarvinnut asentaa kohdelaitteelle. Tässä vaiheessa varmistettiin vielä, että herra pystyi pingaamaan orjaa.

Seuraavaksi luotiin herrakoneelle salausavain, joka siirrettiin orjakoneelle. Avaimen toiminta testattiin ottamalla SSH-yhteys herrakoneelta orjakoneelle.

ssh-keygen -t rsa

ssh-copy-id orja@192.168.1.175

ssh orja@192.168.1.175

SSH-yhteys onnistui ilman salasanaa, mistä voitiin päätellä että avaimen siirto onnistui. Jatkettiin harjoitusta testaamalla orjakoneen pingausta Ansiblen avulla.

$ ansible orja -m ping

Tuloksena saatiin seuraava virheilmoitus

 

Lisäämällä -vvvv komentoon saatiin lisätietoja virheilmoituksesta.

 

Virheilmoituksesta ei suoraan saatu selvää, mikä ongelmana oli. Virheilmoituksen google-hakutulosten perusteella ongelman voi kiertää lisäämällä käyttäjän komentoon. Testausta jatkettiin seuraavalla komennolla:

$ ansible orja -m ping -u orja

Tällä kertaa komento meni läpi. Oletettavasti käyttäjää ei tarvitse lisätä komentoon jos käyttäjänimi on sama kummallakin laitteella. Seuraavaksi luotiin yksinkertainen Ansible playbook ajettavaksi orja-koneella.

$ nano hellosimo.yml

Tiedostoon määriteltiin hostit, joilla ks. playbook ajetaan sekä tehtävät jotka halutaan ajettavan. Tällä kertaa tehtävä oli luoda tekstitiedosto halutulla sisällöllä haluttuun kohteeseen.

---
- name: hellosimo
  hosts: orja
  tasks:
  - name: Luo /tmp/hellosimo.txt tiedosto halutulla sisällolla
    copy: content="Hello Simo!\n" dest=/tmp/hellosimo.txt

Luotu playbook ajettiin komennolla ansible-playbook hellosimo.yml -u orja. Komento meni läpi ilman ongelmia ja Ansiblen tulostus paljasti, että hostiin 192.168.1.175 tehtiin muutoksia. Siirtymällä orjakoneelle ja hakemalla tiedoston /tmp/hellosimo.txt voitiin todeta, että luotu playbook oli ajettu onnistuneesti orjakoneella.

 

Lähteet:

Ansible – A “hello world” Playbook

Joona Leppälahti – CCM/Ansible raportti

b) Kokeile Salt:tia

 

Tavoitteena oli luoda Vagrantin ja Virtualboxin avulla virtuaalikone, josta tehtäisiin rautakoneen Salt-minion, eli orjakone. Harjoitus aloitettiin poistamalla edelliset virtuaalikonekokeilut.

$ vagrant destroy
$ rm Vagrantfile
$ vagrant init bento/ubuntu-16.04
$ vagrant up
$ vagrant ssh

Seuraavaksi asennettiin luodulle virtuaalikoneelle salt-minion ja määriteltiin sen herraksi testikoneen IP-osoite.

$ sudo apt-get update && sudo apt-get -y install salt-minion
$ sudoedit /etc/salt/minion

$ sudo service salt-minion restart

minion -asetustiedosto sisältää pelkkää kommenttia, jonka voi tyhjentää tai säästää myöhempää käyttöä varten. Virtuaalikoneen minion -tiedosto tyhjennettiin ja lisättiin rivi master: IP-osoite osoittamaan rautakoneen IP-osoitteeseen. Lopuksi käynnistettiin salt-minion -palvelu uudestaan, jotta orja ymmärtäisi hakea uutta määriteltyä isäntää. Tämän jälkeen siirryttiin testikoneelle asentamaan salt-master ja muokkaamaan asetuksia.

$ sudo apt-get update && sudo apt-get -y install salt-master
$ sudo salt-key list

vagrant.vm -orjakone löytyi hyväksymättömien avainten listasta (ks. kuva). Avaimen hyväksymisen jälkeen ajettiin komento, jolla hyväksytyillä orjakoneilla voitiin ajaa komentoja.

 

$ sudo salt-key --accept vagrant.vm
$ sudo salt '*' cmd.run "hostname -I"

Komennolla ajettiin siis kaikissa (‘*’) hyväksytyissä salt-slave -koneissa komento “hostname -I”. Tällä kertaa orjia ei ollut kuin yksi. Lopputuloksena voitiin todeta, että herra- ja orjakoneen asetukset toimivat ja harjoitusta voitiin jatkaa. Lopuksi testailtiin komentoja orjakoneille. Paketin asennus ja tietojen hankkiminen orjakoneelta onnistuivat mainiosti.

$ sudo salt '*' pkg.install tree    //paketin asennus
$ sudo salt '*' disk.usage    //kovalevyn tietoja

Lähteenä käytettiin SaltStackin Salt in 10 Minutes -tutoriaalia ja Tero Karvisen kirjoitusta.

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 3 (Syksy 2017)


Palvelinten hallinta kotitehtävät 3 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

a) Asenna useita orjia yhteen masteriin. Ainakin yksi rauta- ja useampia virtuaalisia orjia.

c) OrjaSkripti: Tee skripti, joka muuttaa koneen Puppet-orjaksi tietylle masterille.

d) (vapaaehtoinen) Laita skripti Vagrantfile:n provisointiskriptiksi.

 

Harjoituksen tavoitteena oli asentaa useampi orja yhteen masteriin. Harjoitusta varten luotiin Vagrantin avulla 5kpl virtuaalikoneita, joille määriteltiin Puppet isäntä Vagrantfilen provisiointiskriptin avulla. Lisäksi otettiin vielä 1kpl rauta-orjia.

$ sudo apt-get -y install vagrant virtualbox

Todettiin, että molemmat oli asennettu. Seuraavaksi muokattiin Vagrantfile -tiedostoa käyttäjän kotihakemistossa. Apuna käytettiin Tero Karvisen kirjoitusta.  

 

 

Käytetty Vagrantfile oli kuvan mukainen. Slavesetup-Puppet-moduuli (sekä Vagrantfile) löytyy Simo Suomisen GitHubista. Moduuli muokkaa /etc/puppet/puppet.conf -tiedostoa ja määrittelee masterkoneeksi virtuaalipalvelimen, jonka asetukset on määritelty aiemmassa tehtävässä. Seuraavaksi käynnistettiin Vagrant-boksit.

$ vagrant up

Ensimmäisen virtuaalikoneen käynnistysvaiheessa saatiin seuraava virheilmoitus:

Error: Could not request certificate: Failed to open TCP connection to puppet.simosuominen.com:8140 (Connection refused - connect(2) for "puppet.simosuominen.com" port 8140)

Siirryin SSH-yhteydellä virtuaalikoneelle ja tarkistin palomuurin asetukset, jotka olivat kunnossa. Kävi ilmi, että puppetmaster-palvelu oli pysäytetty, joten se käynnistettiin uudelleen. Seuraavaksi saatiin eri virheilmoitus:

==> slave03: Error: puppet agent -tdv returned 1 instead of one of [0]
==> slave03: Error: /Stage[main]/Slavesetup/Exec[puppet-agent]/returns: change from notrun to 0 failed: puppet agent -tdv returned 1 instead of one of [0]

 

Virheilmoitus ei vaikuttanut niin kriittiseltä, joten harjoitusta päätettiin jatkaa ja siirryttiin taas masterkoneelle tutkimaan, saadaanko orjakoneiden sertifikaatit hyväksyttyä.

$ sudo puppet cert list

 

Sertifikaatit hyväksyttiin komennolla sudo puppet cert sign slave0x (jossa x on muuttuva numero). Seuraavaksi siirryttiin testikoneelta SSH-yhteyden kautta Vagrant-koneelle slave05.

$ vagrant ssh slave05
$ cat /tmp/helloworld.txt

Cat-komennolla varmistettiin, että Puppetmasterin site.pp -tiedostoon määriteltyä helloworld-moduulia ei oltu vielä ajettu orjakoneella. Tämä oli itsestään selvää, joska slavesetup-moduuli ajettiin ennen kuin orjakoneen sertifikaatti oli hyväksytty. slave05 -koneella ajettiin vielä pari komentoa, jotta moduulin ajo onnistui.

$ sudo puppet agent -tdv
$ sudo puppet --enable$ sudo puppet agent -tdv
$ cat /tmp/helloworld.txt

Ongelmaksi täysautomaation kannalta jäi, että orjakoneiden sertifikaatit täytyy hyväksyä käsin. Automaattinen sertifikaattien hyväksyminen on mahdollista, mutta koska masterkoneena toimi virtuaalipalvelin, jätin tämän vaihtoehdon kokeilematta tietoturvasyistä. Orjakoneiden automatisointi toimi sinänsä mainiosti.

Rautakoneen lisääminen orjaksi

Testikoneena Lenovon kannettava, käyttöjärjestelmänä kustomoitu 64-bittinen live-USB Xubuntu 16.04.3. Kannettavalle asennettiin Git ja Puppet, haettiin käyttäjän GitHubista moduulit ja ajettiin slavesetup-moduuli.

$ sudo apt-get update && sudo apt-get -y install git puppet
$ git clone https://github.com/suomisim/puppet
$ sudo puppet apply --modulepath /home/suomisim/puppet/modules -e "include slavesetup"

Moduulin ajo antoi saman virheilmoituksen kuin virtuaalikoneella ajettaessa. Puppetmaster-palvelimella hyväksyttiin sertifikaatti, jonka jälkeen testikoneella ajettiin sudo puppet –enable ja sudo puppet agent -tdv -komennot, jotta yhteys toimisi ja helloworld.txt -tiedostoon päästiin käsiksi. Nyt samalla Puppetmaster-palvelimelle oli 5 virtuaalikonetta ja 1 rautakone orjana.

b) Kerää tietoa orjista: verkkokorttien MAC-numerot, virtuaalinen vai oikea… (Katso /var/lib/puppet/)

 

Jatkettiin harjoitusta ja kirjauduttiin masterkoneelle. Kansiosta /var/lib/puppet/yaml/facts löytyi reilusti tietoja orjakoneista. Kuvan orja “1001px” oli viime kevään tehtävässä lisätty läppäri, jonka lisäksi oma .yaml -tiedosto löytyi Xubuntulle sekä viidelle luoduille Vagrant-virtuaaliorjille. is_virtual -tietueesta voitiin päätellä, että kuvan kone oli fyysinen laite. Alempana tiedostosta löytyi laitteen mac-osoite.

 

 

 

f) Vapaaehtoinen: Unelmien tikku. Tee unelmiesi USB-live-tikku.

 

Päivitetään myöhemmin

 

 

 

 

e) Vapaaehtoinen: Oikeaa elämää. Ratkaise jokin kurssin ulkopuolinen asia Puppetilla.

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


PHP-ohjelmointitehtäviä


Web-ohjelmointi PHP:llä

Kurssin kotisivu

 

Oppimistehtävä 1

Web-sovellus, jonka lomakkeen tiedot tarkastetaan luotujen sääntöjen mukaan. Kenttien käsittely on toteutettu luokan avulla. Luokka sisältää konstruktorin,

omat attribuutit joka tekstikentälle sekä set-, get- ja check-metodit jokaiselle attribuutille.

 

Harjoituksessa käytetty HTML5, PHP, Bootstrap, regex

Linkki

 

Oppimistehtävä 2

Oppimistehtävä 1:n sovellukseen lisätty tietojen näyttösivu. Tiedot tallennetaan laittamalla olio istuntoon (session). Näyttösivulla on mahdollisuus korjata annettuja tietoja.

Asetukset-sivulle lisätty mahdollisuus asettaa käyttäjänimi, joka tallennetaan cookieen.

Linkki

 

 

Oppimistehtävä 3

Täydennetäään myöhemmin

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 2 (Syksy 2017)


Palvelinten hallinta kotitehtävät 2 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

h2a) Gittiä livenä: Tee ohjeet ja skriptit, joilla saat live-USB -tikun konfiguroitua hetkessä – ohjelmat asennettua ja asetukset tehtyä.

 

Harjoituksen tavoitteena oli saada Xubuntun live-USB -tikku käyttökuntoon mahdollisimman nopeasti. Harjoituksessa päätettiin luoda kustomoitu live-USB -tikku, johon sisällytettäisiin tarvittavat ohjelmat ja tiedostot. Ohjeena käytettiin AskUbuntun ohjetta.

 

Kustomoitu live-USB -tikku

Käyttöjärjestelmän kustomointia varten haettiin Cubic-ohjelma.

$ sudo apt-add-repository ppa:cubic-wizard/release

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 6494C6D6997C215E

$ sudo apt-get update

$ sudo apt-get install cubic

Tämän jälkeen ohjelma ajettiin käynnistysvalikosta ja valittiin projektille oma kansio. Jos käytössä on monta eri projektia, niille kaikille tulee luoda oma kansio.

Seuraavaksi valittiin muokattava ISO-tiedosto, joka oli ladattu Xubuntun lataussivulta. Lisäksi valittiin luotavalle custom-levykuvalle nimi.

Tämän jälkeen ohjelma purki ISO-tiedoston sisällön ja avasi komentokehotteen, jonka kautta live-USB -käyttöjärjestelmää oli mahdollista muokata. Muutokset tehtiin chroot-ympäristössä, joten sudo -etuliitettä ei tarvittu komentoihin.

$ apt-get update

$ apt-get install git puppet

$ adduser suomisim

$ adduser suomisim sudo

$ setxkbmap fi

$ nano /etc/rc.local

$ nano /etc/hosts

Ylläolevilla komennoilla muokattiin tiedostoja rc.local ja hosts. rc.local -tiedostoon lisättiin komento, joka ajetaan joka kerta, kun Xubuntu käynnistetään livetikulta. Hosts-tiedostoa muokkaamalla voitiin asettaa uusi hostname.

 

Kun muutokset, valittiin Next. Seuraavaksi valittiin kernelversio, jota käytetään kun käyttöjärjestelmä ajetaan livetikulta. Jos edellisessä vaiheessa ei lisätty kerneleitä, vaihtoehtoja on vain yksi. Tämän jälkeen oli mahdollista valita ohjelmiston asennuksen jälkeen poistettavat paketit. Annoin ohjelman käyttää oletusasetuksia.  Seuraavaksi ohjelma loi uuden ISO-tiedoston annettujen asetusten perusteella. Lopuksi voitiin poistaa muokatun projektin tiedostot, pl. luotu ISO-tiedosto.

Luodusta ISO-tiedostosta tehtiin livetikku Unetbootin -ohjelman avulla. Tikku bootattiin testikoneella onnistuneesti ja ilman virheilmoituksia. Seuraavaksi ajettiin testejä, joilla voitiin päätellä mitä onnistui ja mitä ei. Kirjautuessa huomattiin, että luotu käyttäjä toimi oletuksena, mutta hostname oli yhä Xubuntu. Terminal Emulatoria käytettäessä huomattiin, että näppäimistön asetukset olivat väärin.

 

Epäonnistumisesta huolimatta päätettiin yrittää uudestaan täydellisen livetikun luontia. Tällä kertaa annettiin seuraavat komennot muokkausvaiheessa:

$ apt-get update

$ apt-get install git puppet

$ adduser suomisim

$ adduser suomisim sudo

$ nano /etc/rc.local

$ nano /etc/default/keyboard

Keyboard -tiedostoon muutettiin XKBLAYOUT=”us” kohtaan “fi” ja muokattiin rc.local -tiedostoon yllä olevan kuvan lisäksi rivi hostctl set-hostname itlabra. Tiedosto luotiin ja siirrettiin USB-tikulle kuten aiemminkin ja bootattiin testikoneella.

Testivaiheessa voitiin todeta, että näppäimistön asetukset ovat oikein. Hostname ei muuttunut, joten se täytyy korjata skriptin tai Puppet-moduulin avulla. GitHubista rc.local -tiedoston avulla haettu Puppet-moduulien kansio löytyi luodun käyttäjän kotihakemistosta. Kansioon oli aiemmin luotu skriptit moduulien kopiointia ja ajamista varten. Harjoituksen lopputuloksena oli Xubuntu 16.04 LTS 3 livetikku, joka oli helppo ottaa käyttöön oppituntien alussa.

 

h2b) Kokeile Puppetin master-slave arkkitehtuuria kahdella koneella. Liitä raporttiisi listaus avaimista (sudo puppet cert list) ja pätkä herran http-lokista (sudo tail -5 /var/log/puppet/masterhttp.log).

 

Harjoitus toteutettiin testikoneen 64-bittisen Windows 10-käyttöjärjestelmän kautta luomalla Hyper-V:n kautta kaksi virtuaalikonetta. Toisessa virtuaalikoneessa oli asennettuna 64-bittinen Ubuntu Server 16.04.3 ja toisessa koneessa ajettiin Xubuntu 16.04.3 livetikkua. Virtuaalikoneille oli määritelty verkkoyhteys ja ping-komento toimi.

 

Masterkoneen asetukset

Ensin määriteltiin masterkoneen asetukset. Puppetmaster -ohjelmiston asennuksen jälkeen ohjelman palvelu pysäytettiin ja alkuperäiset sertifikaatit poistettiin.

$ sudo apt-get update

$ sudo apt-get install puppetmaster

$ sudo service puppetmaster stop

$ sudo rm -r /var/liv/puppet/ssl

Tämän jälkeen muokattiin /etc/hosts -tiedostoa kuvan mukaisesti. Näin master-palvelimelle saatiin domain-osoitetta vastaava osoite Puppettia varten.

Tämän jälkeen muokattiin /etc/puppet/puppet.conf -tiedostoa, jonne lisättiin [master] -rivin alle viittaus luotuun DNS-osoitteeseen.

[master]

dns_alt_names = itlabra.local

Lopuksi käynnistettiin puppetmaster -palvelu uudestaan, jolloin uudet sertifikaatit luodaan automaattisesti.

$ sudo service puppetmaster start

 

Orjakoneen asetukset

Orjakoneelle asennettiin Puppet, jonka palvelu pysäytettiin ja muokattiin jälleen /etc/puppet/puppet.conf -asetustiedostoa.

$ sudo apt-get update

$ sudo apt-get install puppet

$ sudo service puppet stop

$ sudoedit /etc/puppet/puppet.conf

 

puppet.conf -tiedostoon lisättiin viittaus masterkoneeseen [agent] -tietueen alle. Tämän jälkeen käynnistettiin palvelu uudestaan ja testattiin yhteyttä.

$ sudo service puppet start

$ sudo puppet agent -tdv

Komennon ajo onnistui ilman virheilmoituksia. Viimeisellä rivillä ohjelma totesi, että sertifikaatteja ei löydy. Seuraavaksi siirryttiin takaisin masterkoneelle katsomaan,

onnistuisiko sertifikaattien lisäys.

 

Sertifikaatit ja moduulin testaus

Masterkoneella haettiin orjakoneen sertifiointipyyntö ja hyväksyttiin se. Tämän jälkeen haettiin käyttäjän GitHubista yksinkertainen moduuli, joka lisättiin ajettavaksi kaikille orjakoneille.

$ sudo puppet cert list

$ sudo puppet cert --sign xubuntu

$ cd

$ git clone https://github.com/suomisim/puppet

Tämän jälkeen siirrettiin haluttu moduuli /etc/puppet/modules -kansioon ja muokattiin /etc/puppet/manifests/site.pp -tiedostoa, jotta moduuli otetaan käyttöön orjakoneilla. Alla olevassa kuvassa näkyy, kuinka “helloworld” -moduuli otettiin käyttöön.

 

Lopuksi siirryttiin takaisin orjakoneelle ja ajettiin taas komento sudo puppet agent -tdv. Tuloksena kolmas, informatiivinen virheilmoitus, joka neuvoi ottamaan puppet agentin käyttöön, sillä ks. palvelu on oletuksena pois käytöstä. Jatkettiin antamalla suositeltu komento ja testaamalla jälleen yhteys ja moduulin toiminta.

$ sudo puppet agent --enable

$ sudo puppet agent -tdv

$ cat /etc/helloworld.txt

Tällä kertaa ei saatu enää virheilmoituksia, ja hellowowrld.txt -tiedosto löytyi halutusta kansiosta. Näin ollen voitiin todeta, että master-slave -arkkitehtuuri toimi kahden testilaitteen välillä.

Lähteenä käytin aiempaa harjoitustani samasta aiheesta.

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 1 (Syksy 2017)


Palvelinten hallinta kotitehtävät 1 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu Xubuntu 16.04, Xenial Xerus

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

H1. Asenna jokin muu demoni kuin Apache. Raportoi, miten rakensit, selvitit ja testasit kunkin osan (esim. sudo puppet resource, puppet describe, lähteet…). Julkaise myös modulisi lähdekoodi niin, että sen voi helposti ottaa käyttöön.

 

Osa 1: Packet

Harjoituksen tavoitteeksi otettiin UFW-palomuurin asennus ja asetusten muokkaus Puppetin avulla. UFW (Uncomplicated Firewall) on helppokäyttöiseksi tarkoitettu työkalu Netfilter-palomuurin hallintaan. Harjoitus aloitettiin poistamalla testikoneesta UFW ja sen asetukset purge-komennolla.

$ sudo apt-get purge ufw

Seuraavaksi luotiin skriptin avulla uusi Puppet-moduuli ufwmod ja tarvittavat kansiot ja tiedostot. Luodut tiedostot ja kansiot näkyvät raportin lopussa olevassa kuvassa (readme.md -tiedosto ei ole tarpeellinen). Jatkettiin harjoitusta muokkaamalla luotua init.pp -tiedostoa. Ensimmäiseksi lisättiin moduuliin asennettava paketti ufw.

class ufwmod {
    package { 'ufw':
        ensure => 'installed',
    }
}

Seuraavaksi varmistettiin, että luotu moduuli toimi oikein. Moduuli kopioitiin /etc/puppet/modules -kansioon ja ajettiin alla olevalla komennolla.

$ sudo puppet apply -e  ‘class {“ufwmod”:}’

Moduulin käynnistys sujui ongelmitta ja UFW asennus varmistettiin komennolla sudo ufw status. UFW oli asennettu, mutta tilassa inactive, sillä ohjelman käyttöönotto vaatii erillisen komennon.

 

Osa 2: Exec

Harjoitusta jatkettiin poistamalla UFW asennus koneelta ja lisäämällä init.pp -tiedostoon komento, jolla UFW otettaisiin käyttöön asennuksen jälkeen.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
    exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
    }
}

Tiedostoon lisättiin komento ufw enable, joka vaatii, että paketti ufw on asennettuna. Moduuli todettiin toimivaksi, sillä paketin asennus onnistui ja UFW oli tilassa active.

 

Osa 3: File

Seuraavaksi tehtiin reikiä palomuuriin, jotta haluttu liikenne pääsisi muurista läpi. Ubuntu Wikin mukaan käyttäjän tekemät asetukset tallentuvat tiedostoihin /etc/ufw/user.rules ja user6.rules.

Harjoitusta varten päätettiin avata portit 22, 80 ja 443 TCP. Muutokset tehtiin ensin käsin, jonka jälkeen asetustiedostoista otettiin kopiot moduulin templates -kansioon. Moduuliin lisättiin tämän jälkeen osa, joka siirtää asetustiedostot oikeaan paikkaan kun moduuli ajetaan.

$ sudo ufw allow 22/tcp$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw status
$ cd /etc/ufw/$ sudo cp user.rules /home/suomisim/puppet/modules/ufwmod/templates/user.rules.erb
$ sudo cp user6.rules /home/suomisim/puppet/modules/ufwmod/templates/user6.rules.erb
$ sudo apt-get purge ufw

Seuraavaksi muokattiin jälleen init.pp -tiedostoa.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
     exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv4)
     file {'/etc/ufw/user.rules':
         content => template('ufwmod/user.rules.erb'),
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv6)
     file {'/etc/ufw/user6.rules':
         content => template('ufwmod/user6.rules.erb'),
         require => Package['ufw'],
     }
}

Moduuli toimi ongelmitta, mutta portit pysyivät kiinni. Moduuliin päätettiin lisätä palomuurin service, joka voitiin potkaista käynnistymään uudelleen aina, kun asetustiedostoja muokataan.

 

Osa 4: Service

Muokattiin init.pp -tiedostoa (toivottavasti) viimeistä kertaa. Tiedostoon lisättiin viittaus UFW palveluun, joka vaatii UFW paketin asennuksen. Asetustiedostojen siirtoon lisättiin huomautus palveluun, joka käynnistyy uudelleen kun asetustiedostot siirretään.

class ufwmod {
 
 # Komentojen polun määrittely
 Exec { path => [ '/bin/', '/sbin/' , '/usr/bin/', '/usr/sbin/' ] }
 
 # Paketin asennus
     package { 'ufw':
         ensure => 'installed',
     }
 
 # Komennon ajo
     exec { 'ufw-enable':
         command => 'ufw enable',
         require => Package['ufw'],
     }
 # Asetustiedoston muokkaus (IPv4)
     file {'/etc/ufw/user.rules':
         content => template('ufwmod/user.rules.erb'),
         require => Package['ufw'],
         notify => Service['ufw'],
     }
 # Asetustiedoston muokkaus (IPv6)
     file {'/etc/ufw/user6.rules':
         content => template('ufwmod/user6.rules.erb'),
         require => Package['ufw'],
         notify => Service['ufw'],
     }
 # Servicen toiminnan varmistaminen
     service { 'ufw':
         ensure => 'true',
         enable => 'true',
         require => Package['ufw'],
     }
}

Moduulin testaamista varten UFW poistettiin jälleen, moduuli siirrettiin /etc/puppet/modules -kansioon ja ajettiin skriptin avulla (tai raportin alussa käytetyllä komennolla). Moduulin ajon jälkeen palomuurin tilanne tarkistettiin sudo ufw status -komennolla.

Voitiin todeta, että moduuli toimii niin kuin pitääkin. Asetustiedostojen syntaksi oli aika yksinkertainen, joten uusien sääntöjen luominen onnistuu ilman, että niitä tehdään ensin käsin.

Alla olevassa kuvassa näkyy moduulin rakenne ja tarvittavat tiedostot + ylimääräinen readme.md -tiedosto.

Lopuksi projekti vietiin GitHubiin käyttäjän omaan puppet-repositoryyn. Koska moduulia muokattiin käyttäjän kotihakemistossa ja repon omassa kansiossa, tiedostoja ei tarvinnut siirrellä tässä vaiheessa mihinkään.

git add .

git commit -m 'Update ufwmod module'
git pull && git push

Moduuli löytyy Githubista Linkki

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinohjelmointi – tehtäviä


Kurssin kotisivu

Tehtäviä GitHubissa

Huom. GitHubiin ei ole siirretty .properties -tiedostoja tietoturvasyistä. Näin ollen suurin osa tehtävistä ei toimi suoraan.

Huom2. Tietokantaa käyttävät harjoitukset antavat ensimmäisellä ajokerralla HTTP Status 500 virheilmoituksen, joka liittyy tietokantayhteyteen.

Harjoitukset toimivat kun ohjelman ajaa uudestaan.

Viikko 1

Jsp-sivu, joka sisältää lomakkeen, johon syötetään kirjan nimi, tekijätiedot ja ISBN-koodi. Luotiin servlet, joka poimii tarvittavat tiedot http-pyynnöstä ja tallentaa ne Kirja-olioon requestin attribuutiksi.

Sivu ohjaa http-pyynnön servletiltä toiselle jsp-sivulle, joka osaa tulostaa Kirja-olion tiedot html-muotoiltuna.

Kirja-Ohjelma

 

Viikko 2

 

PreparedStatement, SQL Injection

Jsp-sivu, joka lukee tietokannasta käyttäjänimiä. Käyttäjiä voi lisätä sekä poistaa tietokannasta.

Käyttäjänimet

 

Viikko 3

Maven, JUnit

Demo sisältää kaksi sovellusta, laskimen ja kellon. Laskin-luokan metodeita on testattu JUnit-yksikkötesteillä. SuomiKello-luokan metodeita on myös testattu yksikkötesteillä ja ulkoinen KelloLahde on rajattu testistä pois käyttäen Mock-oliota.

Viikkotentin harjoitusta varten Kello-sovellukseen on lisätty GmtIsoKello -luokka, joka näyttää GMT-ajan ISO-standardin mukaan. GmtIsoKello-luokan metodeita on myös testattu yksikkötestillä ja testi on lisätty AllTests-suiteen

Demo 11

 

Viikko 4

Spring Framework, Spring JDBC

Komentorivisovellus, joka hakee levyjen tietoja tietokannasta.

Viikkotentti 4 harjoitus 13 (GitHub)

 

Viikko 5

Spring Web MVC, Anonyymi sisäluokka, Callback, GeneratedKeyHolder

Lomake, jonka avulla käyttäjä luodaan tietokantaan. Kun lomakkeen avulla on luotu uusi henkilö tietokantaan, käyttäjä siirretään sivulle, joka hakee tietokannasta juuri lisätyn henkilön tiedot ja näyttää ne. Lisätty toiminnallisuus: henkilöt/lista -linkistä sivu hakee tietokannasta kaikkien henkilöiden tiedot.

Viikkotentti 5 harjoitus 11

 

Viikko 6

Internationalization (I18n), Localization (L10n), Bean validation (JSR 303), Custom annotation, Custom validator

Käyttäjä voi vaihtaa käyttöliittymän kieltä napin painalluksella. Kaikki kieliriippuvaiset tekstit on tallennettu kielikohtaisiin properties-tiedostoihin. Henkilön ominaisuuksia on laajennettu. Mikäli syötetty data ei ole validia, käyttäjä ohjataan takaisin lomakesivulle ja häntä opastetaan korjaamaan virheet.

Lisätty toiminnallisuus: Luotu demosovellukseen uusi validaattori kenttiin etunimi, sukunimi ja lahiosoite tarkastamaan, että merkkijono alkaa isolla kirjaimella. Toteutettu validointi uudella annotaatiolla, jonka nimi on @AlkaaIsollaKirjaimella.

Viikkotentti 6 harjoitus 12

 

Harjoitustehtävä

Spring Web MVC, Anonyymi sisäluokka, Callback,GeneratedKeyHolder, Internationalization (I18n), Localization (L10n),

Bean validation (JSR 303), Custom annotation, Custom validator

Käyttäjä voi kirjata järjestelmään painokirjauksia ja hakea kaikki tai tiettynä päivänä tehdyt kirjaukset. Validointia käytetään havaitsemaan tyhjät kentät ja väärässä muodossa annetut tiedot.

PainoOhjelma.v1


Apache Tomcat 8 asennus virtuaalipalvelimelle


Apache Tomcat 8 asennus virtuaalipalvelimelle

 

Tavoitteena oli asentaa Apache Tomcat 8 Palvelinohjelmoinnin kurssin harjoitustöiden esittelyä varten. Lähtötilanteessa käytössä oli virtuaalipalvelin, jossa oli asennettuna Ubuntu 16.04 LTS käyttöjärjestelmä ja LAMP-stack

WordPress-sisällönhallintajärjestelmää varten. Lähteenä käytettiin DigitalOceanin mainiota tutoriaalia.

 

Esivalmistelut

Tomcat vaatii Java Development Kitin asennuksen, joten se asennettiin ensimmäisenä.

$ sudo apt-get update
$ sudo apt-get install default-jdk

Seuraavaksi luotiin oma käyttäjä Tomcatille. Käyttäjä luotiin turvallisuussyistä ilman sudo-oikeuksia sekä mahdollisuuksia kirjautua sisään. Käyttäjän kotihakemistoksi annettiin /opt/tomcat/, minne Tomcat ohjelmisto asennettaisiin.

$ sudo groupadd tomcat
$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Tomcat 8 asennus

Seuraavaksi haettiin Tomcat 8 uusimman version osoite ohjelman lataussivuilta. Asennusta varten ladattiin Core version tar.gz -paketti.

$ cd /tmp
$ curl -O http://www.nic.funet.fi/pub/mirrors/apache.org/tomcat/tomcat-8/v8.5.20/bin/apache-tomcat-8.5.20.tar.gz
$ sudo mkdir /opt/tomcat
$ sudo tar xzvf apache-tomcat-8.5.20.tar.gz -C /opt/tomcat --strip-components=1

Kansioiden käyttöoikeudet

Tämän jälkeen päivitettiin kansioiden käyttäjäoikeuksia. käyttäjälle tomcat annettiin omistajuus koko asennuskansiolle. tomcat-ryhmälle annettiin lukuoikeus conf-kansioon ja sen sisältöön ja suoritusoikeus itse kansioon.

Lopuksi tomcat käyttäjälle annetaan omistajuus kansioille webapps, work, temp ja logs.

$ sudo chgrp -R tomcat /opt/tomcat

$ sudo chmod -R g+r conf

$ sudo chmod g+x conf

$ sudo chown -R webapps/ work/ temp/ logs/

systemd asetukset

systemd asetuksia muokkaamalla Tomcat 8:a voidaan ajaa palveluna ja se voidaan asettaa käynnistymään automaattisesti. Tomcatille täytyy myös kertoa, mihin kansioon Java on asennettu (JAVA_HOME -polku)

$ sudo update-java-alternatives -l

Tarvittava JAVA_HOME polku oli kuvan mukainen polku, jonka perään liitettäisiin /jre kansio eli tässä tapauksessa:

/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre

Seuraavaksi luotiin Tomcat 8 asetukset systemd kansioon

$ sudoedit /etc/systemd/system/tomcat.service

Tiedoston sisältöön kopioitiin seuraavat tiedot, varmistaen että JAVA_HOME muuttuja viittasi oikeaan kansioon.

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

 

Seuraavaksi käynnistettiin Tomcat palvelu ja testattiin sen toimivuutta.

$ sudo systemctl daemon-reload
$ sudo systemctl start tomcat
$ sudo systemctl status tomcat

 

Palomuurin konfigurointi ja Tomcat serverin testaus

Tomcat käyttää porttia 8080, joka avattiin UFW-palomuurista liikennettä varten.

$ sudo ufw allow 8080

Tämän jälkeen voitiin testata serverin toimintaa siirtymällä osoitteeseen http://serverinosoite:8080

Tomcatin oletuskotisivu saatiin näkyviin, joten asennus oli onnistunut.  Manager App ja Host Manager sivut eivät vielä toimineet,

koska ne vaativat asetusten muokkausta. Tässä vaiheessa voitiin kuitenkin asettaa Tomcat palvelu käynnistymään automaattisesti järjestelmän käynnistyessä.

$ sudo systemctl enable tomcat

Lisäasetukset

Manager App ja Host Manager hallintaa varten Tomcatille täytyi seuraavaksi luoda käyttäjiä. Kuten kotisivulla näkyy, käyttäjiä hallitaan $CATALINA_HOME/conf/tomcat-users.xml -tiedostossa.

$ sudoedit /opt/tomcat/conf/tomcat-users.xml

Luotavalle käyttäjälle annettiin roolit manager-gui ja admin-gui, jolloin käyttäjällä pääsee hallitsemaan Manager App ja Host Manager toiminnallisuuksia. Käyttäjätiedot luotiin tomcat-users.xml -tiedostoon alla olevan kuvan mukaisesti

(luonnollisesti käyttäjätunnus ja salasana muutettiin…)

Oletusasetuksena Tomcat estää Manager App ja Host Manager toiminnallisuuksien käytön, jos niitä ohjataan suoraan serveriltä. Asetus otettiin pois päältä muokkaamalla kahta context.xml -tiedostoa.

$ sudoedit /opt/tomcat/webapps/manager/META-INF/context.xml
$ sudoedit /opt/tomcat/webapps/host-manager/META-INF/context.xml

Molemmista tiedostoista kommentoitiin ulos kuvan mukaiset kaksi riviä, jolloin Manager App ja Host Manager toiminnallisuuksia voi käyttää mistä tahansa. Vaihtoehtoisesti asetustiedostoista voi määritellä halutut IP-osoitteet, jotka voivat käyttää toiminnallisuuksia.

Asetusten muokkaamisen jälkeen Tomcat palvelu käynnistettiin uudestaan.

$ sudo systemctl restart tomcat

Tämän jälkeen sekä Manager App että Host Manager toimivat annetuilla käyttäjätunnuksilla. /opt/tomcat/webapps -kansioon siirretyt .war tiedostot voitiin ottaa käyttöön Manager App:in kautta.

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Kesäopintoja 2017


Kesäopintoja 2017

 

Opiskelin kesän 2017 aikana täydentäviä opintoja Professional Summer School 2017 kautta. Opinnot olivat osa Haaga-Helia, Metropolia- ja Laurea-ammattikorkeakoulujen tarjoamia kesäopintoja. Kesäopinnot ovat erinomainen tapa laajentaa omaa osaamista ja opintokokonaisuutta kursseilla, joita oma oppilaitos ei välttämättä tarjoa. Kurssien toteutus oli hyvin suunniteltu ja voin suositella niitä kaikille kiinnostuneille! Kurssien suorituskieli oli englanti.

Professional Summer School (Haaga-Helia)

Alla olevasta linkistä löytyvät suorittamani kurssit ja niiden lyhyet kuvaukset. Pyrin mahdollisuuksien mukaan lisäämään kursseja varten toteutettuja yksinkertaisia projekteja.

Simo Suominen – Kesäopintoja 2017

 


Palvelinten hallinta – kotitehtävät 4


Palvelinten hallinta kotitehtävät 4

Lähde  Tero Karvinen 2017: Linux kurssi, http://terokarvinen.com

Harjoitusympäristönä asennettu Xubuntu 16.04, Xenial Xerus

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

Puppet: Master-slave.

Aloita tyhjästä koneesta. Tee yhdestä koneesta orja ja toisesta herra. Kokeile, että orja saa herralta modulin. (Voit käyttää labraa, kun se on tyhjä. Laita mukaan ‘puppet cert –list –all’, ‘tail /var/log/auth.log’, ‘tail /var/log/syslog’).

Harjoitustyön tavoitteena on toteuttaa Puppet keskitetyn hallinnan ratkaisu niin, että master-palvelima toimii virtuaalipalvelin. Master- ja orjakoneitten asetukset määritellään niin, että orja noutaa sille määritellyt moduulit virtuaalipalvelimelta.

Lähtötilanteessa virtuaalipalvelimelle on asennettu valmiiksi Ubuntu 16.04 Xenial Xerus -käyttöjärjestelmä. Palvelimen tietoturvaa on parannettu ottamalla palomuuri käyttöön ja luomalla uusi sudo-käyttäjä + lukitsemalla root-käyttäjä. Toimenpiteiden tarkempi kuvaus löytyy Linux-palvelinten kurssin kotitehtävistä. Tämän lisäksi domainin DNS-asetukset on määritelty niin, että osoite puppet.simosuominen.com osoittaa virtuaalipalvelimen IP-osoitteeseen.

Masterkoneen asetukset

Harjoitus aloitettiin määrittelemällä masterkoneen asetukset, lähteenä käytettiin Tero Karvisen artikkelia. Masterkoneelle oli otettu yhteys SSH:n kautta.

$ sudo apt-get update && sudo apt-get -y install puppetmaster //master-ohjelmiston asennus

$ sudo service puppetmaster stop //master-palvelun pysäytys


$ sudo rm -r /var/lib/puppet/ssl //vanhojen sertifikaattien poisto

$ sudoedit /etc/puppet/puppet.conf //Puppet asetustiedoston muokkaus

Master-ohjelmiston asennuksen jälkeen asennettu palvelu pysäytettiin ja luodut sertifikaatit poistettiin. Koska Puppetin asetustiedosto oli vajavainen, sertifikaateista puuttui oikea DNS-nimi. Puppet.conf -tiedostoon, [master] -rivin alle lisättiin rivi osoittamaan oikeaan DNS-osoitteeseen:

dns_alt_names = puppet.simosuominen.com

Tämän jälkeen puppetmaster -palvelu käynnistettiin uudelleen, jolloin uusi sertifikaatti luotiin automaattisesti uudelleen.

$ sudo service puppetmaster restart

Lopuksi luotiin yksinkertainen moduuli kansioon /etc/puppet/modules. Moduuli luo /tmp/helloworld.txt -tiedoston kun se ajetaan. Tämän jälkeen muokattiin vielä /etc/puppet/manifests/site.pp -tiedostoa seuraavalla rivillä:

class {"helloworld":}

Lopputuloksena kaikki masterkoneeseen yhteyttä ottavat orjakoneet ajavat helloworld -moduulin omissa laitteissaan.

Orjakoneen asetukset

Orjakoneena käytettiin ikivanhaa Asus eeePc -kannettavaa, johon oli asennettu 32-bittinen Xubuntu 16.04 LTS käyttöjärjestelmä. Orjakoneen asetusten asentaminen aloitettiin asentamalla puppet ja muokkaamalla tarvittavia asetuksia.

$ sudo apt-get update && sudo apt-get -y install puppet //puppet-ohjelman asennus

$ sudo service puppet stop //puppet-palvelun pysäytys

$ sudoedit /etc/puppet/puppet.conf //asetustiedoston muokkaus

Sekä herra- että orjakoneen asetustiedosto on saman niminen. Orjakoneen asetukset tehdään luomalla tiedostoon [agent] -rivi, jonka alle tehdään halutut asetukset.

[agent]

server = puppet.simosuominen.com

Seuraavaksi käynnistettiin puppet-palvelu uudelleen sekä testattiin asetuksia.

$ sudo service puppet start //palvelun käynnistys


$ sudo puppet agent -tvd //asetusten testaus (-tvd = --test --verbose --debug)

Testistä saatiin aikaan seuraava virheilmoitus:

Samalla hetkellä tajuttiin, että virtuaalipalvelimen palomuuriin ei ole puhkaistu reikää Puppetin oletusporttia varten. Kirjautumalla virtuaalipalvelimelle ja avaamalla tarvittava portti päästiin harjoituksessa eteenpäin. Seuraavaksi ajettiin testikomento uudestaan ja saatiin uusi ilmoitus:

Exting: no certificate found and waitforcert is disabled.

Testikomennon debug-lokeja tutkimalla saatiin selville, että orjakone oli luonut sertifikaattipyynnön herrakoneelle. Kirjauduttiin taas herrakoneelle ja tutkittiin asiaa.

$ sudo puppet cert list //avattiin sertifikaattipyynnöt, joihin ei ole vastattu

Listalta löytyi host nimi 1001px, joka tunnistettiin vanhaksi surkeaksi orjakoneeksi. Hyävksyttiin ks. sertifikaattipyyntö.

$ sudo puppet cert --sign 1001px

Sertifikaatin hyväksymisen jälkeen herra- ja orjakoneen välille on luotu luottamussuhde. Jatkettiin ajamalla vanha tuttu testikomento orjakoneella. Tuloksena kolmas, informatiivinen virheilmoitus, joka neuvoi ottamaan puppet agentin käyttöön, sillä ks. palvelu on oletuksena pois käytöstä. Ajettiin lisää komentoja:

$ sudo puppet agent --enable //puppet agentin käyttöönotto

$ sudo puppet agent -tvd //asetusten testaus

Viides kerta, ja komento saatiin ajettua ilman virheilmoutksia. Seuraavaksi tutkittiin moduulin tekemiä muutoksia orjakoneella komennolla sudo cat /tmp/helloworld.txt

Hello world! Sekä herra- että orjakoneen Puppet-asetukset saatiin onnistuneesti toimimaan.

 

 

 

 

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta – kotitehtävät 3


Palvelinten hallinta kotitehtävät 3

Lähde  Tero Karvinen 2017: Linux kurssi, http://terokarvinen.com

Harjoitusympäristönä asennettu Xubuntu 16.04, Xenial Xerus

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

Modulit Gitistä. Tee skripti, jolla saat nopeasti modulisi kloonattua GitHubista ja ajettua vaikkapa liverompulle. Voit katsoa mallia terokarvinen/nukke GitHub-varastosta.

Harjoituksen tavoitteena oli varmistaa, että moduulit ovat saatavilla eri laitteilla ja nopeasti otettavissa käyttöön missä tahansa. Harjoituksen lähtötilanteessa moduuleilla oli oma Github repository puppet.

Livetikulle tallennettiin scripts -kansioon getgit -skripti. Vaihtoehtoisesti sama skripti löytyy Githubista. Skripti ajaa apt-get update -komennon, asentaa git ja puppet -paketit sekä kloonaa käyttäjän puppet-repositoryn käyttäjän kotikansioon. . Livetikkua käytettäessä moduulit saadaan käyttöön esim. seuraavasti:

$ wget https://raw.githubusercontent.com/suomisim/puppet/master/getgit

$ sudo bash getgit

Käyttäjälle oli nyt asennettu tarvittavat ohjelmat moduulien käyttöönottoa varten. Moduulien luonti, kopiointi ja ajaminen suorittiin tämän jälkeen skriptien avulla. Moduulit luodaan käyttäjän kotihakemistoon puppet/modules/ -kansioon, josta ne siirretään ajettavaksi /etc/puppet/modules/ -kansioon. Käytetyt skriptit löytyvät GitHubista.

Package-File-Server. Asenna ja konfiguroi jokin demoni package-file-server -tyyliin. Tee jokin muu asetus kuin tunnilla näytetty sshd:n portin vaihto.

Harjoitustyön tavoitteena oli asentaa LAMP. Toinen tavoite oli kerrankin suorittaa yksi pieni osa asennuksesta kerrallaan, jolloin virheiden selvittäminen olisi huomattavasti helpompaa. Tehtävän kaikki vaiheet käydään läpi, mutta yksinkertaisimpia komentoja on jätetty pois selkeyden vuoksi. Osa komennoista tehdään skriptien avulla (moduulien kansioiden luonti, moduulien kopiointi ja suorittaminen jne.)

Harjoituksen tavoite täyttyi ja moduuli asentaa LAMP -ohjelmistot onnistuneesti. Moduulia ei voi suositella laajempaan käyttöön koska se ei ole tietoturvan kannalta optimaalinen eikä sitä vielä ole testattu kuin testikokoonpanolla.

Apache asennus

Aloitettiin luomalla apache2 -paketin asennus moduuliin.

class lamp {
    
    package { 'apache2':
        ensure => 'installed',
    }
}

Moduulin suorittaminen onnistui ilman virheilmoituksia ja osoitteesta http://localhost saatiin näkyviin Apachen aloitussivu. Seuraavaksi otettiin käyttöön käyttäjän kansio, johon moduuli siirtää halutun websivun templates-kansiosta. Templates-kansioon luotiin yksinkertainen html-sivu index.html.erb. Käyttäjän kansion käyttöönottoon haettiin vinkkejä Lauri Soivin blogista. Alla päivitetty init.pp.

class lamp {
    
    package { 'apache2':
        ensure => 'installed',
    }
#
#    file { '':
#        content => template(''),
#        notify => Service[''],
#        require => Package[''],
#
#    }
#    
    service { 'apache2':
        ensure  => 'true',
        enable  => true,
        require => Package['apache2'],
    }




    file { '/home/suomisim/public_html':
        ensure => 'directory',
     
    }
    
    
    file { '/home/suomisim/public_html/index.html':
        content => template('lamp/index.html.erb'),
        require => File['/home/suomisim/public_html'],
    
    
    }
    
    file { '/etc/apache2/mods-enabled/userdir.load':
        ensure => 'link',
        target => '/etc/apache2/mods-available/userdir.load',
        notify => Service["apache2"],
        require => Package["apache2"],
    }

    file { '/etc/apache2/mods-enabled/userdir.conf':
        ensure => 'link',
        target => '/etc/apache2/mods-available/userdir.conf',
        notify => Service["apache2"],
        require => Package["apache2"],
        }




}

Moduulin ajon jälkeen websivu osoitteessa http://localhost/~suomisim näytti halutun sivun. Tämän jälkeen moduuli valitettavasti toimii ainoastaan käyttäjällä suomisim. Käyttäjästä riippumattomiin ratkaisuihin täytyy palata myöhemmin. Tässä vaiheessa ajettiin commit-skripti, jotta pystyttäisiin palaamaan toimivaan moduulin versioon tarvittaessa.

PHP asennus

Aloitettiin PHP asennus lisäämällä seuraavat rivit edelliseen init.pp -tiedostoon:

    package {'libapache2-mod-php':
        ensure => installed
    }

Tämän jälkeen moduuli ajettiin uudestaan. Tämä tehtiin siksi, että päästäisiin käsiksi asennuksen mukana tulleeseen asetustiedostoon php7.0.conf. Tämä tiedosto kopioitiin moduulin templates-kansioon ja annettiin sille jälleen .erb -pääte. Tiedostoa muokattiin niin, alla oleville riveille lisättiin kuvan mukaisesti kommenttimerkki #:

Selection_005.png

Näin saatiin PHP toimimaan myös käyttäjän kansioissa. Tämän jälkeen tehtiin tarvittavat muutokset init.pp -tiedostoon. Muutokset liittyivät /etc/apache2/mods-available/php7.0.conf -tiedoston muokkaukseen. Tämän lisäksi .html -tiedostot vaihdettiin .php tiedostoiksi sekä index.php.erb -tiedostoon lisättiin yksinkertainen php -koodi:

          <?php
              echo "Hello World!";
          ?>
class lamp {

 package { 'apache2':
 ensure => 'installed',
 }

 service { 'apache2':
 ensure => 'true',
 enable => true,
 require => Package['apache2'],
 }


 file { '/home/suomisim/public_html':
 ensure => 'directory',

 }


 file { '/home/suomisim/public_html/index.php':
 content => template('lamp/index.php.erb'),
 require => File['/home/suomisim/public_html'],


 }

 file { '/etc/apache2/mods-enabled/userdir.load':
 ensure => 'link',
 target => '/etc/apache2/mods-available/userdir.load',
 notify => Service["apache2"],
 require => Package["apache2"],
 }

 file { '/etc/apache2/mods-enabled/userdir.conf':
 ensure => 'link',
 target => '/etc/apache2/mods-available/userdir.conf',
 notify => Service["apache2"],
 require => Package["apache2"],

 }


 package {'libapache2-mod-php':
 ensure => installed
 }

 file { '/etc/apache2/mods-available/php7.0.conf':
 content => template('lamp/php7.0.conf.erb'),
 require => Package["libapache2-mod-php"],
 notify => Service["apache2"],
 }

}

Moduulin ajon jälkeen luotu index.php -tiedosto toimi osoitteessa http://localhost/~suomisim. Tässä vaiheessa tehtiin taas git commit -toimenpiteet. Moduulista otettiin git -kansioon vielä kopio nimellä phpapache, koska moduuli toimi hyvin.

MySQL asennus

Jatkettiin LAMP -asennusta asentamalla MySQL -tietokantaohjelmisto sekä tarvittavat PHP-kilkkeet (php-mysql -paketti). Ongelmana MySQL -asennuksessa oli root-käyttäjän salasanan asetus asennusvaiheessa. Tässä vaiheessa kurssia osaaminen ei riittänyt salasanan piilottamiseen mihinkään vaan se tallennettiin selkokielellä init.pp -tiedostoon. Tämä oli tietoturvariski, mutta moduuli haluttiin saada toimivaksi harjoitusta varten. Alla on nähtävissä viimeinen versio init.pp -tiedoston sisällöstä.

class lamp {

     
    package { 'apache2':
        ensure => 'installed',
    }
   
    service { 'apache2':
        ensure  => 'true',
        enable  => true,
        require => Package['apache2'],
    }

    file { '/home/suomisim/public_html':
        ensure => 'directory',

    }
    
    
    file { '/home/suomisim/public_html/index.php':
        content => template('lamp/index.php.erb'),
        require => File['/home/suomisim/public_html'],
    
    }
    
    file { '/etc/apache2/mods-enabled/userdir.load':
        ensure => 'link',
        target => '/etc/apache2/mods-available/userdir.load',
        notify => Service["apache2"],
        require => Package["apache2"],
    }

    file { '/etc/apache2/mods-enabled/userdir.conf':
        ensure => 'link',
        target => '/etc/apache2/mods-available/userdir.conf',
        notify => Service["apache2"],
        require => Package["apache2"],
    }

    package {'libapache2-mod-php':
        ensure => 'installed',
    }
    
    file { '/etc/apache2/mods-available/php7.0.conf':
        content => template('lamp/php7.0.conf.erb'),
        require => Package["libapache2-mod-php"],
        notify => Service["apache2"],
    }
    
    package {'mysql-server':
        ensure => 'installed',
    }

    $mysqlpw = "ChangeOnFirstStart!"

    exec { 'mysqlpw':
        path => ["/bin", "/usr/bin"],
        command => "mysqladmin -uroot password $mysqlpw",
        require => Package["mysql-server"],
    }
    
    service { 'mysql':
        ensure  => 'true',
        enable  => 'true',
        require => Package['mysql-server'],
    }
    
    package {'php-mysql':
        ensure => 'installed',
        require => Package['mysql-server'],
    }
        
}

Moduuli toimi ilman virheilmoituksia. Poikkeuksena käsin suoritettuun MySQL -asennukseen kirjautuminen root-tunnuksilla vaati sudo-käyttäjänä kirjautumista. Kun tietokantaan luotiin uusi käyttäjä, käyttäjänä oli mahdollista kirjautua ohjelmaan myös ilman sudo-oikeuksia. Yllä oleva koodi jäi ensimmäiseksi versioksi lamp-moduulista. Koodiin jäi kehittämistä, mm. käyttäjäsidonnaisuuden poistaminen, tietoturvan parantaminen sekä yleinen koodin siistiminen sekä riippuvuuksien korjaaminen/parantaminen.

Vapaaehtoinen: Vaihda Apachen default VirtualHost Puppetilla siten, että sivut ovat jonkun kotihakemistossa ja niitä voi muokata normaalin käyttäjän oikeuksin.

Harjoitus tuli toteutettua edellisessä harjoituksessa.

Vapaaehtoinen vaikea: Konfiguroi jokin muu demoni (kuin Apache tai SSH) Puppetilla.

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen