Month: April 2017


Palvelinten hallinta – kotitehtävät 4


Palvelinten hallinta kotitehtävät 4

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

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

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

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

16GiB RAM

 

Puppet: Master-slave.

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

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

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

Masterkoneen asetukset

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

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

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


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

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

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

dns_alt_names = puppet.simosuominen.com

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

$ sudo service puppetmaster restart

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

class {"helloworld":}

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

Orjakoneen asetukset

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

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

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

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

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

[agent]

server = puppet.simosuominen.com

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

$ sudo service puppet start //palvelun käynnistys


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

Testistä saatiin aikaan seuraava virheilmoitus:

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

Exting: no certificate found and waitforcert is disabled.

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

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

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

$ sudo puppet cert --sign 1001px

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

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

$ sudo puppet agent -tvd //asetusten testaus

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

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

 

 

 

 

 

 

 

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

Simo Suominen


Palvelinten hallinta – kotitehtävät 3


Palvelinten hallinta kotitehtävät 3

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

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

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

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

16GiB RAM

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

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

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

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

$ sudo bash getgit

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

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

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

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

Apache asennus

Aloitettiin luomalla apache2 -paketin asennus moduuliin.

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

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

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




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

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




}

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

PHP asennus

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

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

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

Selection_005.png

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

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

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

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


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

 }


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


 }

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

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

 }


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

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

}

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

MySQL asennus

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

class lamp {

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

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

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

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

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

    $mysqlpw = "ChangeOnFirstStart!"

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

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

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

Harjoitus tuli toteutettua edellisessä harjoituksessa.

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

 

 

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

Simo Suominen


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