Tag: xubuntu


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


Palvelinten hallinta kotitehtävät 5 (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 64-bit

Windows-harjoitusympäristönä Windows 10 Pro 64-bit

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

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

16GiB RAM

 

a) Asenna Puppetin orjaksi vähintään kaksi eri käyttöjärjestelmää. (Tee alusta, pelkkä tunnilla tehdyn muistelu ei riitä).

 

Tavoitteena oli asentaa Lenovo Ideapadin 64-bittinen Windows 10 Home -kone Puppet-orjaksi. Lähteenä harjoitukseen käytettiin Tero Karvisen kirjoitusta sekä tunnilla Tatu Erkinjuntin kanssa tehtyjä moduuleja.

Harjoitus aloitettiin poistamalla UAC käytöstä. Poisto onnistuu esim. siirtymällä Control Panel -> User Accounts -> Change User Account Control Settings. Kun asetus on muutettu kuvan mukaiseksi, tietokone täytyi käynnistää uudestaan.

 

 

Seuraavaksi ladattiin Puppet asennuspaketti Puppetlabsin sivuilta. Tiedoston versio oli puppet-3.8.7-x64.msi. Puppet asennettiin järjestelmänvalvojan oikeuksilla oletuskansioon. Asennusvaiheessa ohjelma kysyi Puppet masterin domainosoitetta, joksi määriteltiin aikaisemmin luotu puppet.simosuominen.com. Asennuksen jälkeen testattiin puppettia siirtymällä Windowsin Command Promptiin, jälleen järjestelmänvalvojan oikeuksilla (Run as Administrator).

Command Promptissa ajettiin vanha kunnon komento puppet agent -tdv. Vastauksena saatiin tieto, että sertifikaattia ei vielä löytynyt, joten siirryttiin Puppet master-virtuaalipalvelimelle hyväksymään sertifikaatti.

 

Sertifikaatin hyväksymisen jälkeen luotiin yksinkertainen hellosimo -moduuli testausta varten. Moduuli lisättiin masterkoneen site.pp -tiedostoon ja ajettiin orjakoneella uudestaan puppet agent -tdv -komento. Moduulin luoma hellosimo.txt -tiedosto löytyi C: juuresta niin kuin pitikin.

 

Toiseksi orjajärjestelmäksi valittiin ensimmäinen Linux distro, joka sattui tulemaan vastaan. Tällä kertaa valituksi tuli Linux Mint 18.2 64-bittinen Hyper-V virtuaalikoneen kautta ajettuna. Valitettavasti puppetin asennus ks. käyttöjärjestelmään ei poikennut mitenkään Xubuntun Puppetin asennuksesta. Lopputuloksena kaksi uutta käyttöjärjestelmää puppet.simosuominen.com Puppetmasterin orjana.

 

b) Säädä Windows-työpöytää. Voit esimerkiksi asentaa jonkin sovelluksen ja tehdä sille asetukset.

 

Jatkettiin Puppet-orja Lenovo-läppärin kanssa säätämistä asentamalla orjakoneelle ohjelmia. Ensin asennettiin master-konelle puppetlabs/windows -moduuli, joka sisältää pakettienhallintaohjelman (Chocolatey) ja muita Windows-orjan tarvitsemia työkaluja.

$ sudo apt-get update

$ sudo puppet module install puppetlabs/windows

Seuraavaksi luotiin uusi moduuli ohjelmien asennusta varten. Moduuliin tuli lisätä viittaus pakettienhallintaohjelmaan, jotta asennus onnistuu.

 

Moduulia ajettaessa saatiin virheilmoitus:

notice: Run of Puppet configuration client already in progress; skipping (C:\ProgramData\PuppetLabs\puppet\var\state\agent_catalog_run.lock exists)

 

Aloin tutkimaan käynnissä olevia prosesseja ja palveluita ja kokeilin ajaa moduulin kahden minuutin päästä uudestaan. Tällä kertaa moduuli asensi ohjelmat ilman virheilmoituksia.

Windows-orjakoneen kustomointi jatkuu kurssin loppumoduulissa.

 

 

 

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 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


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


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


Palvelinten hallinta – kotitehtävät 2


Palvelinten hallinta kotitehtävät 2

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

Näytönohjain GeForce GTX 690

Tee puppet-moduli, joka tekee asetukset jollekin komentorivi- tai graafisen käyttöliittymän ohjelmalle.

Harjoitustyön tavoitteena on tehdä käytännönläheinen moduuli muokkaamaan Xubuntun käyttöliittymää haluttuun suuntaan. Lopullisena tavoitteena on moduuli, jonka voi ajaa esim. livetikulla tai heti ensimmäisenä uudelleen asennetulle Xubuntulle. Muutokset saattavat olla pieniä, mutta niiden tekeminen erikseen joka kerta vie aikaa. Testikoneella oli tehty muutoksia mm. käynnistysvalikkoon ja työpöytään, joten kopioimalla näiden asetustiedostot moduuliin tehdyt muutokset saatiin monistettua.

Harjoitustyössä hyödynnettiin Git -versionhallintaa, joten työskentelykansiona toimi käyttäjän kotihakemisto. Näin ollen moduulit luotiin ja niitä muokattiin ilman sudo-oikeuksia. Ennen moduulien testausta ne siirrettiin /etc/puppet/modules/ -kansioon ja ajettiin sudo-oikeuksilla.

Tehtävä alotettiin ottamalla käyttöön käyttäjän Github-varasto Puppet-moduuleille:

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

Työpöydän asetukset

Pikaisen googletuksen perusteella Xfce4 työpöydän ja käynnistysvalikon asetukset löytyivät polulta /home//.config/xfce4/. Talteen päätettiin ottaa käynnistysvalikon asetustiedosto whiskermenu-1.rc ja komentokehotteen asetustiedosto terminalrc. Harjoituksessa luotiin Puppet-moduuli settingsmod, joka siirtää asetustiedostot oikeaan paikkaan ja näin asettaa asetukset voimaan. Asetustiedostoihin ei tehty muutoksia, koska halutut muutokset oli jo tehty graafiseen käyttöliittymään.

$ cd
$ mkdir settingsmod
$ cd settingsmod
$ mkdir manifests
$ mkdir templates
$ cd manifests
$ nano init.pp

init.pp -tiedostoon kirjattiin seuraava pätkä koodia:

class settingsmod {

    	file {'/home/suomisim/.config/xfce4/panel/whiskermenu-1.rc':
            content => template('settingsmod/whiskermenu-1.rc.erb')

    	}

    	file {'/home/suomisim/.config/xfce4/terminal/terminalrc':
            content => template('settingsmod/terminalrc.erb')

    	}


}

Seuraavaksi kopioitiin asetustiedostot template-kansioon oikeassa muodossa (.erb)

cp terminalrc /home/suomisim/puppet/settingsmod/templates/terminalrc.erb
cp whiskermenu-1.rc /home/suomisim/puppet/settingsmod/templates/whiskermenu-1.rc.erb

Lopuksi kopioitiin moduuli /etc/puppet/modules -kansioon. Ennen moduulin ajamista muokattiin komentokehotteen ja käynnistysvalikon asetuksia, jotta nähtäisiin että asetukset muuttuvat takaisin. Komentokehotteen kokoa muutettiin pienemmäksi (Preferences -> Appearance -> Default geometrics) ja käynnistysvalikosta Favourites -pikakuvakkeista poistettiin pari kuvaketta. Seuraavaksi ajettiin moduuli komennolla:

$ sudo puppet apply -e 'class {"settingsmod":}'

Moduuli toimi ilman virheilmoituksia. Avaamalla uuden komentokehotteen voitiin todeta, että muutettu asetus oli palannut takaisin “oikeaksi”. Käynnistysvalikon muutokset astuivat voimaan vasta uudelleenkäynnistyksessä, joten livetikun konfigurointiin moduuli soveltuu kehnosti. Uuudelleenkäynnistyksen jälkeen poistetut pikakuvakkeet olivat palanneet valikkoon, joten moduuli toimii ainakin jollain tasolla.

Toimiva moduuli + muut harjoitusmoduulit siirrettiin lopuksi Githubiin alla olevilla komennoilla:

$ git add *
$ git commit
$ git pull
$ git push 

Harjoitustyö on nähtävissä myös GitHubissa

 

 

 

 

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


Palvelinten hallinta kotitehtävät 1

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

Näytönohjain GeForce GTX 690

Tee ja testaa moduli, joka käyttää ainakin kahta eri resurssia (esim. file ja package)

Harjoitustyön tavoiteena oli asentaa Puppet ja testata asennettua ohjelmaa luomalla yksinkertainen moduli. Aloitettiin asennuksella ja tarvittavien kansioiden luonnilla.

$ sudo apt-get update

$ sudo apt-get -y install puppet //asennus

$ sudo mkdir -p /etc/puppet/modules/simotest/manifests/ //luotiin tarvittavat kansiot


$ sudoedit /etc/puppet/modules/simotest/manifests/init.pp //avattiin muokattavaksi moduulia varten tarvittava tiedosto

Harjoitusta varten luotiin moduuli, joka loi tiedoston tmp -kansioon ja kirjoitti tiedostoon lauseen tekstiä. Lisäksi moduuli ajoi komennon apt-get update. Lopuksi moduuli asensi paketit ‘vlc’, ‘curl’ ja ‘lynx’. Jos paketit olivat jo asennettuna, moduuli varmisti, että ne ovat myös päivitetty uusimpaan versioon. Alla on nähtävissä tiedoston sisältö.

class simotest {

    file {"/tmp/hellosimo2":                #tiedoston luonti
     content => "Hello again, Simo!\n",        #tiedoston sisältö
    }

    exec { 'apt-update':                    #komento
     command => '/usr/bin/apt-get update'    #komennon polku
    }

    $paketit = [ 'vlc', 'curl', 'lynx' ]    #asennettavien pakettien kuvaus

    package { $paketit: ensure => 'latest'    #pakettien asennus

    }

}

Moduuli ajettiin komennolla sudo puppet apply -e ‘class {“simotest”:}’

Lopuksi testattiin, että moduulin tekemät muutokset toimivat. Asennetut ohjelmistot löytyivät testikoneelta ja luodun tiedoston sisältö saatiin esiin komennolla cat /tmp/hellosimo2.

Lähteet: Puppet Cookbook

Vapaaehtoinen: Tärkeimmät resurssit. Tee moduleja, jotka käyttävät resursseja package, file, service, user, exec

Harjoitusta jatkettiin käyttämällä edellisen harjoituksen modulia pohjana. Seuraavaa moduulia varten luotiin kansiot /etc/puppet/modules/simotest2/manifests/. Alkuperäiseen moduliin lisättiin user ja service resurssit. Tässä tapauksessa moduli varmistaa, että cron-palvelu on päällä ja luo testuser -käyttäjätunnuksen sekä tälle kotihakemiston.

class simotest2 {

    file {"/tmp/hellosimo2":                #tiedoston luonti
     content => "Hello again, Simo!\n",        #tiedoston sisältö
    }

    exec { 'apt-update':                    #komento
     command => '/usr/bin/apt-get update'    #komennon polku
    }

    $paketit = [ 'vlc', 'curl', 'lynx' ]    #asennettavien pakettien kuvaus

    package { $paketit: ensure => 'latest'    #pakettien asennus
    
    }

    service { 'cron':                        #palvelun nimi
     ensure => 'running',                    #varmistetaan, että palvelu on päällä ja käynnistyy uudestaan jos näin vaaditaan
    
    }
    
    user { 'testuser':                        #käyttäjätunnus
     ensure => present,
     comment => 'Testi Käyttäjä',            #koko nimi
     home => '/home/testuser',                #kotihakemisto
     managehome => true                        #kotihakemiston käyttöönotto
    }
    
}

Moduuli ajettiin komennolla sudo puppet apply -e ‘class {“simotest2”:}’

Komennolla cut -d: -f1 /etc/passwd saatiin kaikki käyttäjät näkyville ja voitiin todeta, että käyttäjä testuser löytyy listalta. Palvelun toiminnan varmistaminen testattiin pysäyttämällä palvelu komennolla sudo service cron stop. Kun moduuli ajettiin tämän jälkeen debug-tilassa komennolla puppet apply -e ‘class {“simotest2”:}’ –verbose –debug saatiin esille seuraavat rivit:

Debug: Executing '/bin/systemctl is-active cron'
Debug: Executing '/bin/systemctl start cron'
Notice: /Stage[main]/Simotest2/Service[cron]/ensure: ensure changed 'stopped' to 'running'
Debug: /Stage[main]/Simotest2/Service[cron]: The container Class[Simotest2] will propagate my refresh event
Info: /Stage[main]/Simotest2/Service[cron]: Unscheduling refresh on Service[cron]
Debug: Class[Simotest2]: The container Stage[main] will propagate my refresh event

Cron-palvelun uudelleenkäynnistyminen varmistettiin vielä komennolla sudo service cron status.

Lähteet: Puppet Cookbook

Vapaaehtoinen: Oikeaa elämää. Ratkaise jokin yksinkertainen oikean elämän ongelma Puppetilla. Esimerkiksi asenna jokin työpöytä- tai komentoriviohjelma ja tee siihen säädöt.

HUOM! Tehtävä päivitetty 13.4.2017

Ongelma: Elämä ilman mainosten estoa verkkoselaimessa on kurjaa. Ratkaisu: Yksinkertainen Puppet-moduuli, joka muokkaa Firefoxin asetuksia ja asentaa Ublock Origin -mainostenestolisäosan automaattisesti. Moduuli luotiin käyttäjän puppet-kansioon ja siirrettiin se ajettavaksi /etc/puppet/modules -kansioon. Moduuli luotiin skriptin avulla. Skripti loi annetun nimen mukaan moduulin ja tarvittavat kansiot sekä init.pp -tiedoston. Skripti make löytyy käyttäjän GitHubista. Lähteenä harjoituksessa käytettin M. Selvisen WordPress-sivua aiheesta.

init.pp -tiedoston sisältö:

class firefox { 

    package { 'xul-ext-ublock-origin':
        ensure => 'installed',
        require => Package['firefox'],
    }

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

    file { '/etc/firefox/syspref.js':
        content => template('firefox/syspref.js.erb'),
        notify => Service['firefox'],
        require => Package['xul-ext-ublock-origin'],

    }
    
    service { 'firefox':
#        ensure  => 'true',
#        enable  => 'true',
        require => Package['firefox'],
        provider => 'systemd',
    }

}

Lähteen avulla selvisi, että tiedostoon /etc/firefox/syspre.js täytyi tehtä muutoksia, jotta lisäosa asentuu ilman ongelmia. Lisäys tehtiin kopioimalla ks. tiedosto moduulin templates-kansioon .erb -päätteellä ja lisäämällä seuraava rivi uuteen tiedostoon:

user_pref(“xpinstall.signatures.required”, false);

Luotu moduuli kopioitiin skriptin avulla /etc/puppet/modules -kansioon ja ajettiin toisen skriptin avulla. Uudelleenkäynnistyksen jälkeen Ublock Origin oli otettu käyttöön selaimessa.

Katso video esim. Puppetista ja toisesta vastaavasta järjestelmästä (esim. Salt) ja kirjoita niistä analyyttinen ja vertaileva kirjoitus.

Harjoitusta varten valittiin video keskitetyn hallinnan järjestelmästä/järjestelmistä. Tämän jälkeen tutustuttiin videon sisältöön ja pyrittiin analysoimaan sen sisältöä. Kohdevideoksi valittiin Edurekan toteuttama video, jossa verrattiin neljän eri hallintajärjestelmän ominaisuuksia. Edureka on Intiassa 2011 perustettu interaktiiviseen opetukseen erikoistunut yritys, joka tarjoaa kursseja IT-ammattilaisille. (lähde). Video on julkaistu 19.12.2016, joten sitä voidaan pitää ajankohtaisena.

Videossa vertailtiin Chef, Puppet, Ansible ja SaltStack -hallintajärjestelmiä. Vertailtavat osa-alueet olivat skaalautuvuus, käyttöönoton helppous, saatavuus, hallinta ja yhteentoimivuus.

Skaalautuvuus (Scalability)

Skaalautuvuudella tarkoitettiin mahdollisuutta konfiguroida vaihtelevia määriä laitteita ja videon mukaan jokainen palvelu pystyy suoriutumaan tästä erinomaisesti.

Asennuksen helppous (Ease of Setup)

Sekä Puppet, Chef että SaltStack toimivat Master – Slave -periaatteella. Nämä järjestelmät vaativat omat ohjelmistonsa master-servereille ja orjakoneissa pyörii myös oma ohjelmisto. Ansible taas perustuu SSH-yhteyden luomiseen orjakoneille, jolloin tarvitaan ainoastaan yksi ohjelmisto master-serverille. Ansiblen käyttöönotto on näin ollen videon mukaan “A cakewalk” – eli helpompi kuin kilpailijoilla.

Saatavuus (Availability)

Saatavuudella tarkoitettiin toiminnan jatkuvuutta tilanteessa, jossa masterkone putoaa pois pelistä. Jokaisella hallintajärjestelmällä on videon mukaan useaan masteriin perustuva arkkitehtuuri, jolloin pääserverin pudotessa pois pelistä varaserveri on aina määritelty ja käytössä.

Hallinta (Management)

Hallinnan vertailussa käytiin läpi push- ja pull-metodeja laitekonfiguraatioiden siirrossa client-koneille. Puppet ja Chef toimivat videon mukaan pull-metodilla, jossa client-koneet hakevat konfiguraationsa serveriltä (master). Ansible ja SaltStack taas työntävät konfiguraationsa client-koneille.

Lisäksi viitattiin palveluiden käyttävän kielen ymmärrettävyyteen. Puppet (Puppet DSL) ja Chef (Ruby) saivat videolla risuja hankalasta DSL -kielestä, kun taas Python-pohjaiset Ansible ja SaltStack tarjosivat helpomman tavan luoda hallita konfiguraatioita.

Yhteentoimivuus(Interoperatibility)

Yhteentoimivuudella tarkoitettiin mahdollisuuksia toimia eri käyttöjärjestelmillä. Kaikkien palveluiden masterserveri täytyi olla Linux/Unix -laitteella, mutta client-koneet voivat olla myös Windows-laitteita.

Lopputulos + pohdinta

Videon loppupisteissä Ansible ja SaltStack saivat hieman korkeammat pisteet käyttöönoton ja hallinnan helppouden perusteella. Pisteytyksen jälkeen palveluita verrattiin vielä mm. GitHub-yhteisön aktiivisuuden, Google -trendien, yritysesimerkkien sekä hintojen perusteella. Videon tekijä muistuttaa videon lopussa, että loppujen lopuksi “paras” hallintaohjelmisto yrityksen käyttöön on se, joka sopii parhaiten yrityksen toimintaympäristöön ja tarpeisiin.

Video hyvin tehty ja selkeä ja käytti hyvin esimerkkejä hyödyksi. Videon sanoma oli uskottava eikä se yrittänyt kehua mitään palveluista yli muiden. Video oli äänite virtuaaliluennolta ja se sisälsi täydentäviä kysymyksiä oppilailta. Näin palvelinten hallinnan kurssin alussa en löytänyt suoranaisia asiavirheitä ja uskon, että videota voi suositella kaikille hallintaohjelmista kiinnostuneille aloitteilijoille.

 

 

 

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


Linux palvelimet – kotitehtävät 4


Linux palvelimet – kotitehtävät 4

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

Harjoitusympäristönä Ubuntu 17.04 (Zesty Zapus) Daily Build

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

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

16GiB RAM

Näytönohjain GeForce GTX 690

Asenna alusta lähtien LAMP. (Linux voi olla asennettu valmiiksi tai Live-USB).

AsennettinLAMP otettiin aikaa toimenpiteistä. Ensimmäinen osa on testikoneelle asennettu (L)inux Xubuntu 17.04. Seuraavaksi asennettiin Apache2 -webpalvelin.

$ sudo apt-get update

$ sudo apt-get install apache2

Seuraavaksi todettiin asennuksen onnistuneen käymällä verkkoselaimella osoitteessa http://localhost, jolloin saatiin Apache2:n oletussivu näkyville. Aikaa kului 5min 30sek (toimenpiteet + raportointi).

Selection_001.png

Seuraavaksi otettiin käyttöön käyttäjän kansio palvelimella ja luotiin käyttäjälle aloitussivu. Tähän käytettiin seuraavia komentoja:

$ sudo a2enmod userdir //käyttäjän kansion käyttöönotto

$ sudo service apache2 restart //apache2 -palvelun uudelleenkäynnistys

$ cd //siirryttiin käyttäjän kotihakemistoon

$ mkdir public_html //luotiin kansio tuleville julkisille html -tiedostoille

Linux oli asennettu testikoneelle valmiiksi ja käyttäjä (suomisim) luotu asennuksen yhteydessä. Siirtymällä osoitteeseen http://localhost/~suomisim/ päästiin kansioon, johon käyttäjän kotisivut tehtäisiin.

Selection_003.png

Palomuuri

Seuraava askel oli parantaa tietoturvaa ottamalla käyttöön palomuuri. Tähän käytettiin komentoa sudo ufw enable. Koska kokoonpanoa ei ohjattu eikä testattu etänä, jätettiin palomuuri ehjäksi eikä puhkottu siihen reikiä. Aikaa kului yhteensä 12min.

MySQL

Jatkettiin LAMP-kokoamista asentamalla MySQL -tietokantaohjelma. Samalla asennettiin seuraavissa tehtävissä tarvittavat PHP-lisäpalikat. Käytetyt komennot:

$ sudo apt-get update

$ sudo apt-get -y install mysql-server mysql-client libapache2-mod-php php-mysql

MySQL -asennus kysyi Root-käyttäjän salasanaa, salasanaksi annettiin tarpeeksi monimutkainen salasana. Seuraavaksi kirjauduttiin tietokantaan, luotiin uusi tietokanta sekä käyttäjä ks. tietokannalle.

$ mysql -u root -p //käyttäjä root, -p varmistaa, että salasanaa kysytään erikseen, jotta se pysyy poissa lokeista

create database suomisim character set utf8; //luotiin uusi tietokanta (suomisim) ja valittiin käytettävä merkkijärjestelmä UTF-8

grant all on suomisim.* to suomisim@localhost identified by 'sensuroitusalasana'; //annettiin käyttäjälle suomisim kaikki oikeudet tietokantaan suomisim(ja tuleviin tämän alaisiin tietokantoihin) annettua salasanaa vastaan.

exit //kirjauduttiin ulos root-käyttäjältä

mysql -u suomisim -p //kirjauduttiin käyttäjänä suomisim)

show databases; //näytettiin tietokannat, joihin ks. käyttäjällä on oikeus

Selection_004.png

Näin luotu käyttäjä ei pysty sotkemaan muita kuin oman tietokantansa. Seuraavaksi kokeiltiin automatisoida MySQL -kirjautumisprosessi käyttäjälle suomisim.

$ exit

$ cd

$ nano .my.cnf //luotiin tiedosto, johon kirjattiin seuraavat kirjautumistiedot:
[client]
user="suomisim"
password="sensuroitusalasana"
database="suomisim"

Kun tämän jälkeen ajettiin komento mysql, päästiin kirjautumaan oikeaan tietokantaan oikealla käyttäjällä ilman hidasta kirjautumisprosessia. Aikaa kului alusta yhteensä 29 minuuttia. Lopuksi otettiin vielä PHP käyttöön ja varmistettiin sen toimivuus:

PHP asennus ja testaus

$ cd /etc/apache2/ //siirryttiin apache2 asetuskansioon

$ grep -ir php * //haettiin ks. kansion tiedostoista merkintöjä PHP

$ sudoedit /etc/apache2/mods-available/php7.0.conf //muokattiin tiedostoa, joka löytyi edellisen haun perusteella

Tiedostosta otettiin alla olevat asetukset pois päältä lisäämällä rivien eteen kommenttimerkin #.

Selection_005.png

$ sudo service apache2 restart 

$ cd

$ cd public_html

$ nano index.php

Lisättiin index.php -tiedostoon seuraava rivi: <?php print(2+2+”\n\n”); ?>

http://localhost/~suomisim/ -sivulla näkyi PHP-koodilla kirjoitetun laskutoimituksen tulos -> PHP toimii. Kokomaisaika LAMP-harjoituksen läpikäyntiin ja raportointiin oli n. 45 minuuttia.

Tee weppisivu, joka lukee PHP:lla rivejä tietokannasta.

Harjoitukseen käytettiin edellisessä tehtävässä asennettua LAMP:ia. Aloitettiin harjoitus luomalla tietokantataulu käyttäjälle suomisim. Tämän jälkeen lisättiin tietoja ja varmistettiin, että tiedot tallentuivat tietokantaan.

$ mysql //kirjauduttiin sisään

use suomisim; //valittiin oma tietokanta

create table pizza(id int auto_increment primary key, name varchar(1024), taste varchar(1024)); //luotiin tietokanta pizza ja siihen arvot id, name, taste

insert into pizza(name) values ('Kinkku'); //lisättiin tietokantaan pizza tietue kinkku

insert into pizza(name) values ('Tonnikala');

insert into pizza(name) values ('Ananas');

update pizza set taste="Herkullinen" where name="Kinkku"; //lisättiin tietueelle kinkku arvo Herkullinen

update pizza set taste="OK" where name="Tonnikala";

update pizza set taste="Menettelee" where name="Tonnikala";

select * from pizza; 

Selection_006.png

Näin varmistettiin, että tietokannan tiedot ovat ajan tasalla. Seuraavaksi luotiin websivu, joka hakee tiedot tietokannasta. Harjoituksen vuoksi luotiin ja muokattiin tiedosto Geany-tekstieditorilla, joka toimi erinomaisesti. Lähteenä PHP-koodille käytettiin w3schools.com -sivua. Koodia muokattiin omaan tietokantaan soveltuvaksi alla olevan kuvan mukaisesti.

-PHPo.php - -home-suomisim-public_html - Geany_007.png

Lopputuloksena tuotantoon valmis websivu, joka hakee pizzojen tiedot MySQL -tietokannasta. Alla kuvankaappaus sivusta.

Selection_008.png

Laita liitteeksi tai linkiksi raporttiisi tällä komenolla kerätty log.txt:

tail /var/log/syslog /var/log/auth.log /etc/lsb-release /var/log/apache2/*.log /proc/uptime >log.txt

==> /var/log/syslog <==
Feb 12 20:25:30 thor anacron[1281]: Job `cron.daily’ terminated
Feb 12 20:25:30 thor anacron[1281]: Normal exit (1 job run)
Feb 12 20:27:26 thor kernel: [ 421.746964] [UFW BLOCK] IN=eno1 OUT= MAC=d4:3d:7e:01:b0:4b:30:59:b7:8b:f5:60:08:00 SRC=192.168.1.112 DST=192.168.1.87 LEN=515 TOS=0x00 PREC=0x00 TTL=128 ID=24564 PROTO=UDP SPT=1900 DPT=59052 LEN=495
Feb 12 20:27:27 thor kernel: [ 422.991959] [UFW BLOCK] IN=eno1 OUT= MAC=d4:3d:7e:01:b0:4b:30:59:b7:8b:f5:60:08:00 SRC=192.168.1.112 DST=192.168.1.87 LEN=515 TOS=0x00 PREC=0x00 TTL=128 ID=24565 PROTO=UDP SPT=1900 DPT=59052 LEN=495
Feb 12 20:27:28 thor kernel: [ 423.897291] [UFW BLOCK] IN=eno1 OUT= MAC=d4:3d:7e:01:b0:4b:30:59:b7:8b:f5:60:08:00 SRC=192.168.1.112 DST=192.168.1.87 LEN=515 TOS=0x00 PREC=0x00 TTL=128 ID=24566 PROTO=UDP SPT=1900 DPT=59052 LEN=495
Feb 12 20:27:29 thor kernel: [ 424.973855] [UFW BLOCK] IN=eno1 OUT= MAC=d4:3d:7e:01:b0:4b:30:59:b7:8b:f5:60:08:00 SRC=192.168.1.112 DST=192.168.1.87 LEN=515 TOS=0x00 PREC=0x00 TTL=128 ID=24567 PROTO=UDP SPT=1900 DPT=59052 LEN=495

==> /var/log/auth.log <==

==> /etc/lsb-release <==
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.04
DISTRIB_CODENAME=zesty
DISTRIB_DESCRIPTION=”Ubuntu Zesty Zapus (development branch)”

==> /var/log/apache2/access.log <==

==> /var/log/apache2/error.log <==
[Sun Feb 12 20:25:29.382208 2017] [mpm_prefork:notice] [pid 1442] AH00163: Apache/2.4.23 (Ubuntu) configured — resuming normal operations
[Sun Feb 12 20:25:29.382233 2017] [core:notice] [pid 1442] AH00094: Command line: ‘/usr/sbin/apache2’

==> /var/log/apache2/other_vhosts_access.log <==

==> /proc/uptime <==
461.12 5351.63

Tee pinta-alan laskuri PHP:lla. Eli käyttäjä syöttää lomakkeella (form) pellon pituuden ja leveyden, laskuri kertoo weppisivulla pellon alan.

Pinta-ala-ohjelma toteutettiin Geany-tekstieditorilla, jolla luotiin kaksi .php tiedostoa, pala.php (pääsivu) ja pala-action.php.

pala.php

<!doctype html>

<html lang="en">
<head>
 <meta charset="utf-8">
 <title>Pinta-ala-Ohjelma</title>
 <meta name="author" content="Simo Suominen">
 <link rel="stylesheet" href="css/styles.css?v=1.0">

</head>

<body>
 http://js/scripts.js
 
 
 <form action="pala-action.php" method="post">
 <p>Anna pellon leveys metreissä: <input type="number" name="leveys" /></p>
 <p>Anna pellon pituus metreissä: <input type="number" name="pituus" /></p>
 <p><input type="submit" /></p>
</form>
 
</body>
</html>

pala-action.php

Pellon leveys on <?php echo htmlspecialchars($_POST['leveys']); ?> metriä
<p></p>
Pellon pituus on <?php echo htmlspecialchars($_POST['pituus']); ?> metriä

<p></p>
Pellon kokonaispinta-ala on

<?php

$first_number = htmlspecialchars($_POST['leveys']);
$second_number = htmlspecialchars($_POST['pituus']);
$sum_total = $second_number * $first_number;

print ($sum_total);

?>

neliömetriä.

Lopputuloksena oli yksinkertainen websivu, joka kysyi käyttäjältä pellon pituutta ja leveyttä ja laski niiden perusteella pellon pinta-alan.

Selection_010.png

Selection_012.png

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