Month: November 2017


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


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

Oppimistehtävä 2:n sovellukseen lisätty tietokantayhteys. Luodun henkilön tiedot voi nyt tallentaa tietokantaan. Lisäksi tietokannasta voidaan hakea kaikki henkilöt

sekä hakea Jsonin avulla henkilöitä sukunimen perusteella (ääkköset eivät toimi haussa). Tietokannasta voi myös poistaa henkilöitä.

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