Category: Palvelinten hallinta


Palvelinten hallinta loppumoduuli (Syksy 2017)


Palvelinten hallinta loppumoduuli (Syksy 2017)

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

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

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

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

16GiB RAM

 

Harjoituksen tavoitteena oli luoda kokonaisuus, jonka avulla oli mahdollista asentaa Windows 10 tyhjälle koneelle, asettaa käyttöjärjestelmä

Puppetin orjaksi ja ajaa Puppet-moduuli joka ottaa käyttöön halutut ohjelmat ja asetukset. Tavoitteena oli, että käyttäjän ei tarvitsee puuttua asennukseen mahdollisimman vähän.

Kohdelaitteena oli koodinimi “Pelikone” ,jota varten halutaan mahdollisimman pelkistetty Windows-ympäristö ilman Microsoftin bloatwarea.

 

Automatisoitu Windows 10 asennus

 

Windows 10 ISO-tiedoston muokkaukseen käytettiin WinReducer -ohjelmaa. Ohjelman avulla luotiin unattended.xml -tiedosto, jota tarvitaan Windowsin automatisoituun asennukseen.

Lisäksi lisättiin asennettavan Windowsin rekisteriin viittaus, joka poisti UAC:n käytöstä sekä määriteltiin skripti, joka luotiin kun käyttäjä kirjautuu ensimmäistä kertaa asennettuun käyttöjärjestelmään.

 

Harjoituksessa käytettiin apuna WinReducer EX-100 ohjelman kokeiluversiota. Ohjelman käynnistyksen jälkeen valittiin Start -> ISO -> valittiin aiemmin ladattu Windows 10 ISO (en_windows_10_education_version_1703_updated_march_2017_x64_dvd_10189297).

Seuraavaksi ohjelma avasi ISO-tiedoston sisällön muokkausta varten. Ohjelman avulla on mahdollista lisätä, poistaa ja muokata Windowsin asetuksia ja ominaisuuksia. Tavoitteena oli muokata asetuksia Puppetin avulla, joten asennukseen tehtiin ainoastaan ne muutokset, jotka olivat välttämättömiä.

 

UAC:n poisto käytöstä

UAC:n käytöstä poisto onnistuu esimerkiksi rekisteriä muokkaamalla. Lähteenä käytettiin TechNetin artikkelia, jonka perusteella muutos tehtiin ensin omaan tietokoneeseen jonka jälkeen ks. kohta rekisterissä tallennettiin .reg -tiedostoksi (…export). Ohjelman System -> WinReducer Registry Integrator

-välilehden alta lisättiin .reg -tiedosto asennukseen (Add a Registry File -> Save in a Registry File).

 

Ohjelmien asennusskripti

System -> WinReduce Post Installation -> OOBE muokattiin .cmd -tiedostoa, joka ajetaan sen jälkeen kun Windows on asennettu. Add a File -napin avulla lisättiin puppet.bat ja puppet-3.8.7-x64.msi -tiedostot asennukseen, jonka jälkeen muokattiin skriptiä.

@ECHO OFF
for %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\sources\install.wim set CDROM=%%i:
if not defined CDROM goto :eof
echo Detected CDROM as drive %CDROM%
cd\

Title WINDOWS PUPPET SLAVE SETUP
Color F0

@echo ********** Welcome **********
@echo ********** Installing Puppet Agent with master at puppet.simosuominen.com **********
msiexec /qn /norestart /i %CDROM%\WinReducerEX100PI\puppet-3.8.7-x64.msi PUPPET_MASTER_SERVER=puppet.simosuominen.com
timeout 10
start "PuppetWindow" cmd /c %CDROM%\WinReducerEX100PI\puppet.bat
@echo ********** Connecting to the Puppetmaster **********
cd "C:\Program Files\Puppet Labs\Puppet\bin"
timeout 2
puppet agent -tdv
@echo ********** Done **********

 

Skripti tunnistaa asennusmedian (jota ei saa poistaa ennen kuin koko asennus on valmis) ja asentaa medialta Puppetin puppet.simosuominen.com. Asennuksen jälkeen skripti ajaa puppet.bat -tiedoston, joka odottaa 45 sekuntia ja ajaa puppet agent -tdv -komennon. Skripti ajaa samaan aikaan ks. komennon uudestaan. Käyttäjälle jää n. 35 sekunttia aikaa käydä hyväksymässä uuden Puppet-orjan sertifikaatti. Alla näkyy puppet.bat -tiedoston sisältö.

:: puppet.bat file for unattended Windows 10 Puppet slave installation
@echo ********** You now have 45 seconds to accept the certificate **********
timeout 45
cd C:\Program Files\Puppet Labs\Puppet\bin
puppet agent -tdv

 

Unattended.xml

Lopuksi otettiin käyttöön automatisoitu asennus kohdasta Unattended -> Activate Unattended Options.

Seuraavat kohdat muuttamalla asennus kysyi ainoastaan mille levylle Windows asennetaan.

Administrator Account -> ON

Administrative Password -> "salasana"

Activate Autologon -> ON

Turn Off Password Expiration -> ON

Accept EULA -> ON

Hide Cortana Setup -> ON

Hide Local Account -> ON

Hide Online Account -> ON

Hide Wireless Setup -> ON

Protect your PC -> Turn off Express settings

Power schemes -> High Performance

System Language -> United Kingdom

System Keyboard -> Finnish

Text Size (DPI) -> 100%

Time Zone (UTC +02:00) Helsinki, ....

ISO-tiedoston luonti suoritettiin loppuun ohjelman avulla valitsemalla Finish ja seuraamalla ohjelman ohjeita. Lopputuloksena Windows 10 ISO-tiedosto, joka asentaessa kysyy ainoastaan mille kiintolevylle käyttöjärjestelmä asennetaan. Loppuasennus toimii automaattisesti. Asennuksen jälkeen käyttäjä Administrator kirjataan automaattisesti sisään ja luotu skripti käynnistyy.

Moduulit

 

Moduulien ajoa varten tarvitaan Puppetmasterilla seuraavat Windows Puppet moduulit:

puppetlabs/powershell

puppetlabs/registry

councyl/windows

chocolatey/chocolatey

 

Vasta asennetun Windows 10 asetusten muokkausta varten luotiin kaksi moduulia. winsteam -moduulin tehtävänä oli asentaa ja käynnistää Steam -pelialusta haluttuun kohteeseen. winsetup -moduuli asensi tarvittavat ohjelmat ja poisti ylimääräisiä ohjelmia ja asetuksia. Lisäksi winsetup muokkasi päivitysten asennusta sekä rekisteriä. Moduulit määriteltiin Puppetmasterilla ajettavaksi järjestyksessä winsteam -> winsetup. Ensimmäinen moduuli käynnistää ohjelmia, joiden päivitys vie aikaa ja toinen moduuli käynnistää koneen uudelleen moduulin lopuksi. Tavoitteena oli ajoittaa moduulien ajon valmistuminen niin, että päivitykset olisivat valmistuneet siinä vaiheessa, kun kone käynnistyy uudestaan.

 

Käytetyt moduulit winsteam ja winsetup GitHubissa.

PS. winsetup-moduuliin lisättiin GitHubista skripti, joka muokkaa Windows 10 asetuksia rajusti. Skriptiin kannattaa tutustua, ennen kuin käyttää moduulia.

 

Testaus

 

Windows-asennusta ja moduuleja testattiin Hyper-V virtuaalikoneella, johon oli lisätty toinen kiintolevy. Asennus nauhoitettiin Windows 10 oman Game DVR -työkalun avulla. Nauhoitus katkesi joka kerta, kun virtuaalikone käynnistyi uudelleen, joten videoita on useampi kappale.

 

Winpuppet 1: Asennuksen aloitus, asennuskohteen valinta

 

Winpuppet 2: Asennus jatkuu, moduuleja edeltävä tilanne, skriptin toiminta ja moduulien ajo

 

Winpuppet 3: Moduulien ajon jälkeinen tilanne

 

Moduulien ajon jälkeen voitiin todeta, että halutut ohjelmat olivat asentuneet ja asetukset olivat voimassa. Windowsin “modernit” ohjelmat oli poistettu, OneDrive kadonnut sekä Cortana piilotettu. Syystä tai toisesta Virtuaalikoneen Windowsin verkkoyhteys oli mennyt epäkuntoon. Tätä ei tapahtunut muilla testauskerroilla ja ongelma korjaantui joko ajamalla virheiden selvityksen tai käynnistämällä virtuaalikoneen uudestaan.

 

Olin varsin tyytyväinen lopputulokseen, vaikka kehitettävää jäi. Koko asennusprosessiin meni aikaa n. 30 minuuttia, josta varmasti saadaan vielä aikaa pois kun käyttöjärjestelmä asennetaan oikealle nopealle raudalle.

 

Jatkokehitys

 

  1. Perehdyttävä Windows-asennuksen muokkauksen ilman ohjelmistoa. Käytännössä asennukseen ei vaadita kuin unattended.xml -tiedosto USB-aseman juureen sekä joku tapa ajaa skriptiasennuksen jälkeen. Windows Answer File Generatorin avulla unattended.xml -tiedoston luonti onnistuu ilman XML-osaamista.
  2. Edelliseen liittyen Windows -asennusmedian /sources/install.wim -tiedoston voi purkaa ja lisätä tiedostoja Windows-asennukseen. Lisäämällä skriptin kansioon C:\ProgramData\Windows\Start Menu\Programs\Startup voidaan ajaa ks. skripti joka kerta kun käyttäjä kirjautuu sisään. Skripti pitää poistaa ensimmäisen kirjautumisen jälkeen esim. Puppet-moduulin avulla. WinReducer -ohjelman avulla luotua skriptiä pitää muuttaa tätä tarkoitusta varten.
  3. Luotava ylläpitomoduuli Windowsia varten. winsteam ja winsetup -moduuleja ei voi ajaa useampaa kertaa kovinkaan onnistuneesti. Ylläpitomoduuliin ohjelmien päivitykset, Win10.ps1 -skripti sekä muut poistot.
  4. Lisättävä ajurien asennukset siinä vaiheessa, kun kohderauta on hankittu.
  5. Muita korjauksia, esim. “rumat ratkaisut pois

 

 

 

Muut lähteet:

Windows 10 Initial Setup Script

Windows 10 Annoyance-free Automated Install

Mount and Modify a Windows Image Using DISM

 

 

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