In-Finnish on Puppeteers Oy

COSS-webinaari: automaatio avoimen lähdekoodin välinein

Mon, 20 Nov 2023 00:00:00 +0000

Toimitusjohtajamme Samuli Seppänen on kutsuttu puhujaksi COSS ry:n webinaariin ma 4.12. 2023 klo 9. Webinaarin aiheena avoimen lähdekootin välinein toteutettava IT-automaatio.

“IT-automaatiolla nostetaan kierroksia samalla kun vähennetään kaasua. Avoimen lähdekoodin välinein tehdyllä IT-automaatiolla voidaan nopeuttaa ja tehostaa toimintaa sekä parantaa työn tuloksia mitattavasti. Yrityksille ja organisaatioille, joiden on pakko hakea yhä uusia keinoja kilpailukykynsä parantamiseen, IT-automaatio antaa syvällisesti toteutettuna mukavan lisäpotkun kilpailijoista erottautumiseen laadulla ja nopeudella. Strategisella automaatiolla voidaan lisäksi vähentää organisaation siiloutumista ja poistaa prosessien pullonkauloja. Mitä sitten avoimen lähdekoodin IT-automaatiosta tulisi tietää, jotta yritykset ja organisaatiot voivat valjastaa sen keskeiseksi osaksi tehokkuuden ja laadun maksimointia?”

Red Hat -automaatiolounas 1.11.2023

Tue, 24 Oct 2023 00:00:00 +0000

Järjestämme yhteisen lounastapahtuman Red Hatin ja 6G Nordic Oyn kanssa Turussa 1.11.2023. Tapahtuma kulkee nimellä automaatiolounas ja siellä kuullaan käytännön esimerkkejä ja ajatuksia IT-automaatiosta ja siitä, miten se kannattaa valjastaa koko yrityksen käyttöön strategiseksi voimavaraksi. Tilaisuus on tarkoitettu tekijöille, tiiminvetäjille ja managereille - kaikille, jotka näkevät, että automaatiotason nostosta olisi hyötyä.

Lämpimästä tervetuloa!

Lisätietoja ja ilmoittautumiset tästä.

Helpotusta työsuhde-etujen lataamiseen: Edenred-latausten automatisointi

Fri, 27 Jan 2023 00:00:00 +0000

Kyllästyimme Edenred-korttien latauksen kankeuteen ja automatisoimme latausprosessin. Tässä artikkelissa kerrotaan, miten automaatio toteutettiin CSV-tiedostoilla ja ohjelmistorobotilla. Lisäksi artikkelista löytyy linkit GitHub-sivustollemme, josta voit ladata koodit käyttöösi.

Edenred-korttien lataustapoja

Edenred on yksi suurimmista suomalaisista työsuhde-etujen tarjoajista. Edenred tarjoaa fyysisiä ja virtuaalisia kortteja, joihin voidaan ladata työntekijöiden lounas-, virike- ja työmatkaetuja. Edenred-korttien lataamiseen on lukuisia tapoja, mutta kaikki ne vaativat merkittävästi käsityötä työntekijän ja/tai työnantajan puolelta. Vaikka työntekijät voivatkin automatisoida omat saldolatauspyyntönsä, pitää työnantajan silti muistaa hyväksyä ne. Tässä artikkelissa esitellään tapa automatisoida Edenred lataus kokonaan CSV-tiedostolla ja Robot Frameworkia käyttävällä ohjelmistorobotilla. Ainoastaan Edenredin lähettämien saldotilauslaskujen maksu pitää tehdä käsin, joskin tämäkin olisi haluttaessa automatisoitavissa.

Webinaaritallenne: Infrastruktuurin rakentaminen koodilla

Wed, 06 May 2020 00:00:00 +0000

Järjestimme Turku Business Regionin kanssa yhteistyössä webinaarin 5.5.2020 aiheesta “Infrastruktuurin rakehtaminen koodilla”. Webinaaritallenne on saatavilla täällä:

Infrastruktuurin rakentaminen koodilla

Webinaarissa käsiteltiin perusasioita seuraavista aiheista: infrastruktuurin rakentaminen koodilla eli IaC, versionhallint, laadunhallintamenetelmät sekä työkalut kuten Puppet, Terraform, Ansible sekä Puppet Bolt.

Video: infrastruktuurin rakentaminen koodilla

Tue, 05 May 2020 00:00:00 +0000

Tässä webinaaritallenteessa esittelemme perusteet infrastruktuurin rakentamisesta koodilla, mukaan luettuna versionhallinnan, laadunvarmistuksen ja erilaiset työkalut kuten Puppetin, Terraformin, Ansiblen ja Puppet Boltin:

Infrastruktuurin rakentaminen koodilla

Toteutettu yhteistyössä Turku Business Regionin kanssa 5.5.2020.

Webinaari: etäyhteydet tietoturvallisesti kuntoon VPN:llä

Tue, 14 Apr 2020 00:00:00 +0000

Turku Business Region webinaari 22.4.2020 kello 13–13.30, osana ICT-webinaarisarjaa.

Webinaarinaarissa kerromme lyhyesti mitä VPN (“Virtual Private Network”) tarkoittaa ja miksi VPN:n käyttö on käytännössä välttämätöntä turvallisten etäyhteyksien luomisessa. Lisäksi käymme lyhyesti läpi VPN-yhteyksien käyttöönoton yleiset vaatimukset.

Tämän jälkeen esittelemme OpenVPN:n, avoimen lähdekoodin VPN-sovelluksen, jota käytetään erittäin laajalti ympäri maailmaa. Sitten siirrymme OpenVPN:ään pohjautuvaan kaupalliseen OpenVPN Access Serveriin, joka tekee VPN-yhteyksien luomisesta ja ylläpidosta merkittävästi helpompaa. Esittelyn jälkeen teemme OpenVPN Access Serverin käyttödemon:

Foreman ja puppetserverin environment cache

Wed, 07 Aug 2019 00:00:00 +0000

Kun käytetään r10k:ta ja Foremania yhdessä on uusien luokkien tuonti kaksivaiheinen prosessi. Oletetaan vaikka, että “production” environmentiin on luotu uusi luokka, esim. “role::ipa_server”. Ilman Foremania riittäisi tuoda muutos puppetmasterille r10k:lla:

$ r10k deploy environment production -vp

Foreman ei kuitenkaan vielä tiedä uudesta luokasta mitään:

$ hammer puppet-class list --environment production|grep ipa_server

Foremanin komponentti, joka hakee Puppetmasterilta uudet luokat on nimeltään “Smart proxy”, joka tunnetaan myös nimellä “foreman-proxy”. Uusimpien Puppetin versioiden kanssa se hakee luokat Puppetserverin API:a käyttäen. Luokat saa päivitettyä komentoriviltä melko triviaalisti:

Neulan erottaminen Git-muutosten heinäsuovasta

Mon, 15 Jul 2019 00:00:00 +0000

Toisinaan käy niin, että on tarpeen varmistua siitä aiheuttaako iso kasa Git-committeja jotain sivuvaikutuksia esimerkiksi Puppet-tuotantoympäristössä. Hyvistä commit-viesteistä on aina toki apua, mutta toisinaan commitit eivät ole täysin atomisia, eli tekevät enemmän kuin yhden (dokumentoidun) asian. Lisäksi esimerkiksi Puppet control reposta saattaa löytyä paitsi Puppet-koodia, myös Terraformia ja Ansiblea. Tälläisessä tapauksessa on kätevää näyttää vain muutokset, jotka ovat oikeasti relevantteja. Ensin tarkistetaan, mikä “production”-ympäristön viimeisin commit on:

$ ssh puppet$ cd /etc/puppetlabs/code/environments/production$ git rev-parse --short HEAD86c2152

Tämän jälkeen voidaan tarkista control reposta muutokset Puppetin kannalta oleellisiin kansioihin ja tiedostoihin:

FreeIPA:an liitettyjen hostien SSH-avaimien päivitys

Thu, 07 Feb 2019 00:00:00 +0000

FreeIPA on Linux-verkkojen “Active Directory”, jossa on integroitu lukuisia eri komponentteja (mm. LDAP, Kerberos, CA, sssd) siten, että Linux-koneet saadaan liitettyä domainiin. Domainiin liittäminen mahdollistaa mm. keskitetyt käyttäjätunnukset, kertakirjautumisen ja SSH-avaimien ja SSH host-avaimien jakelun. FreeIPA:n voi pystyttää sen omalla asennusohjelmalla, johon iso osa myös puppet-ipa moduulin toiminnallisuudesta perustuu.

FreeIPA:ssa on kuitenkin yksi pieni ärsyttävyys: mikäli noodi (esim. palvelin) rakennetaan (esim. AWS EC2 snapshotista) tai provisioidaan (esim. PXE boot) uudelleen, saattavat FreeIPA:ssa säilytettävät SSH host-avaimet mennä epäsynkkaan todellisuuden kanssa. Käytännössä koneelle ei enää silloin pääse kirjautumaan ilman SSH:n tietoturvamekanismien härskiä kiertämistä:

Puppeteersin Puppetmaster installer-tuote nyt AWS:ssä

Mon, 07 Jan 2019 00:00:00 +0000

HUOM: Tuote on poistunut!

Pitkällisen kehitystyön tuloksena saimme kuin saimmekin tehtyä Puppetmasterin Kafo-pohjaisesta asentimestamme oikean AWS Marketplace-tuotteen: Configuration Manager By Puppeteers Oy.

Tuotteen hinnoittelu perustuu käyttötunteihin. Tuote tukee kolmea eri skenaariota:

Pelkkä Puppetserver
Puppetserver ja PuppetDB
Puppetserver, PuppetDB ja Puppetboard

Installer tekee aiemmin jokseenkin rasittavasti Puppetmasterien asentelusta suorastaan naurettavan helppoa:

$ ssh -i ~/.ssh/mykey.pem ubuntu@instance-ip
 $ sudo -i
 $ puppetmaster-installer -i

Tämän jälkeen valitaan skenaario ja mahdollisesti muutetaan joitain parametreja ja ajetaan asennin. PuppetDB:n ja Puppetboardin salasanat luodaan automaattisesti jos niitä ei ole määritetty.

Puppet-moduulien dokumentaation automaattinen päivittäminen

Mon, 19 Nov 2018 00:00:00 +0000

Puppet-moduulien dokumentaation saa helposti päivitettyä “puppet strings”-työkalulla, jonka käyttö yleisellä tasolla on dokumentoitu varsin hyvin. Kun komento vielä yhdistetään Gitin pre-commit -hookiin, saadaan dokumentaatio päivitettyä automaattisesti joka commitilla. Alla näytetään, miten tämä saadaan toteutettua niin Linuxissa kuin Windowsissa. Oletuksena on, että molemmissa tapauksissa Puppet Agent 5.x on asennettu virallisista Puppetlabsin paketeista.

Aloitan helpommasta eli Linuxista käyttäen esimerkkinä Debian 9:iä: ohjeiden pitäisi kuitenkin toimia myös Ubuntuissa aivan samalla tavoin. Ensin asennetaan Git:

$ sudo -s
 $ apt-get update && apt-get install git

Sen jälkeen asennetaan tarvittavat gemmit käyttäen Puppetin gem-komentoa:

Kansioiden siistiminen turhasta tauhkasta Powershellillä

Wed, 08 Aug 2018 00:00:00 +0000

Toisinaan voi tulla tarve säilyttää jonkin kansion hakemistorakenne, mutta poistaa sieltä suuria määriä tiedostoja. Näin voi käydä esimerkiksi silloin, kun halutaan säästää käännösprosessin tulokset, esim. exe-tiedostot, mutta päästä eroon lähdekoodista ja käännöksen tuottamista väliaikaistiedostoista. Tämä onnistuu kätevästi Powershellin Where-Object CmdLetillä. Alla oletetaan, että komennot ajetaan kansiosta, jonka sisältö halutaan siistiä. Lähtötilanteessa kansiossa on 91 tiedostoa ja hakemistoa:

PS> Get-Childitem -Recurse|Measure-Object|Select Count|Format-List
 Count : 91

Seuraavaksi poistetaan ne ei-hakemistot (~tiedostot), joiden tiedostopääte ei ole .exe:

Zip-arkistojen käsittely Powershellillä

Wed, 08 Aug 2018 00:00:00 +0000

Powershell 5:n myötä myös ZIP-arkistoja voi käsitellä Powershellillä. Tätä aiemmin piti käyttää jos jonkinmoisia kikkoja arkistojen purkamiseen, mikä etenkin komentoriviltä työskenneltäessä oli erittäin ärsyttävää. Arkisto luodaan tähän tapaan:

PS> Compress-Archive -LiteralPath tap-windows6 -DestinationPath tap-windows6-9.22.3.zip

Yleensä ottaen kohdetiedoston nimeen ei tarvitse lisätä tiedostopäätettä (.zip). Tässä tapauksessa Compress-Archive CmdLet kuitenkin hämmentyy, jos sitä ei ole:

PS> Compress-Archive -LiteralPath tap-windows6 -DestinationPath tap-windows6-9.22.3
 Compress-Archive : .3 is not a supported archive file format. .zip is the only supported archive file format.
 --- snip ---

Syynä ovat tietenkin kohdetiedoston nimessä olevat pisteet. Compress-Archive CmdLetissä on dokumentoimaton ja jokseenkin ärsyttävä bugi tai ominaisuus: se ei lisää pisteellä alkavia piilohakemistoja arkistoon paitsi jos ne määritellään eksplisiittisesti lähdetiedostolistauksessa (-LiteralPath). Lisäksi kaikki lähdetiedostolistauksen tiedostot ja kansiot lisätään suoraan arkiston juureen, eikä niiden polkua kunnioiteta. Siis esimerkiksi

Windows-ajurien tietojen näyttäminen Powershellillä

Thu, 26 Jul 2018 00:00:00 +0000

Windowsissa on useita komentorivityökaluja asennettujen ajurien tietojen selvittämiseen. Usein törmää seuraavaan komentoon:

PS> Get-WmiObject Win32_PnPSignedDriver

Luokka Win32_PnpSignedDriver sisältää tiedot ajurien digitaalisista allekirjoituksista sekä lisätietoja, kuten ajurin version. Useimmissa tapauksissa tämä komento riittää, sillä Windows ei ole Windows Vistan jälkeen suostunut lataamaan kuin kaupallisin varmentein allekirjoitettuja ajureita ilman, että se on test-signing -tilassa. Windows 10:n mukana tuli vaatimus siitä, että ajuri sisältää Microsoftin digitaalisen allekirjoituksen. Windows Server 2016 vaatii myöskin Microsoftin allekirjoituksen, mutta sen saaminen ajurille vaatii lisäksi, että Windows Hardware Lab Kit -testit on läpäisty. Käytännössä kehitys- ja testikoneita lukuun ottamatta kaikkien ajurien voidaan siis olettaa olevan kaupallisin varmentein allekirjoitettuja.

Select-Stringin käyttö grepin korvikkeena

Thu, 07 Jun 2018 00:00:00 +0000

Kun unixeissa pitää etsiä neula tekstimuotoisen datan heinäsuovasta, käytetään yleensä grep-komentoa. Jos tekstirivi täsmää annettuun hakuparametriin tulostetaan se oletustulostevirtaan (stdout). Grepin kanssa voidaan käyttää hakuparametreina yksinkertaisten merkkijonojen lisäksi säännöllisiä lausekkeita ja käyttää vaikka mitä muita hienoja kikkoja.

Powershellissä ei (ilmeisesti) ole mitään näin hienoa työkalua, mutta onneksi tekstimassasta saa useimmiten seulottua esille oleellisen Select-Stringin merkkijonohaulla. Esimerkiksi Windowsissa on oletuksena palomuurisääntöjä niin valtavat määrät, että niiden kaikkien läpikäynti jonkin tietyn säännön löytämiseksi on hullun hommaa. Hommaa voi helpottaa Select-Stringillä:

Funktioiden kirjoittaminen Puppet-kielellä

Wed, 23 May 2018 00:00:00 +0000

Puppetissa on suuri määrä erilaisia rakenteita, joilla turhaa toistoa koodissa voidaan vähentää. Aiemmin käsiteltiin jo resurssien oletusarvoja ja each-funktiota, joilla toistoa voidaan vähentää yksittäisessä manifest-tiedostossa. Funktiolla samalle koodilohkolle voidaan välittää parametreja, joiden perusteella se laskee mekaanisesti jonkin paluuarvon. Kuten Puppetin virallisten funktioiden listasta näkyy, tätä funktioiden ominaisuutta hyödynnetään mitä erilaisimpiin käyttötarkoituksiin. Funktioita voi paitsi käyttää eri manifesteissa, myös eri moduuleissa kuin missä ne on määritetty.

Perinteisesti funktioita kirjoitettiin Ruby-kielellä. Sittemmin on tullut mahdolliseksi kirjoittaa niitä myös Puppet-kielellä. Alla yksinkertainen esimerkki puppetfinland/openvpn-moduulista:

Windowsien palomuurin hallinta Puppetilla

Wed, 23 May 2018 00:00:00 +0000

Linuxissa palomuurina - tai tarkemmin pakettisuodattimena - käytetään netfilteriä, jota hallitaan yleensä iptables (IPv4) ja ip6tables (IPv6) komennoilla. Iptables-sääntöjen määritys Puppetissa onnistuu helpoiten puppetlabs/firewall -moduulilla. Tyypillinen käyttötapaus on portin avaaminen palomuuriin; tästä tyypillisenä esimerkkinä Puppet-Finland-projektin ::snmp::packetfilter -luokka, jossa avataan pääsy UDP-portiin 161 määritetyistä IPv4 ja IPv6-osoitteista.

Myös Windowsin palomuurisääntöjä voi muokata Puppetilla käyttämällä puppet/windows_firewall -moduulia. Kyseinen moduuli on melko yksinkertainen kääre “netsh advfirewall”-komennon ympärillä, mutta se hoitaa hommansa hyvin.

Linuxissa koko palomuurisäännöstö on helppo pitää ruodussa Puppetilla (ks. esim. puppetfinland/packetfilter moduuli), mutta Windowsissa on pitkälti tyytyminen sääntöjen kevyeen lisäämiseen ja muokkaamiseen. Tämä käy ilmeiseksi, kun listaa tuoreen Windows-koneen palomuurisäännöt:

Puppet-moduulien julkaisu Puppet Forgessa

Wed, 02 May 2018 00:00:00 +0000

Puppet Forge on Puppetlabsin tarjoama repo Puppet-moduuleille. Forge-moduuleja voi asentaa “puppet module install”-komennolla, mutta niihin voi viitata myös r10k:n tai librarian-puppetin Puppetfilessä. Nykyisin Puppet Forge on ensimmäinen paikka, josta katson, onko joku muu jo ratkaissut käsilläni olevan ongelman Puppetilla - pyörää kun on toisinaan turha keksiä uudelleen.

Olen itse käyttänyt vuosia Git Submoduleja, koska niiden avulla Puppet-moduuleihin ulkopuolelta tulevat muutokset on helppo tarkistaa Gitin lokeista ja diffeistä. Niiden käyttö menee kuitenkin kankeaksi kun moduulien määrä kasvaa suureksi: sekä päärepo että submodulet vaativat jatkuvaa paapomista. Tuloksena on turhanpäiväisiä, samankaltaisina toistuvia commit-viestejä kuten “Update Git submodule pointers”, joilla ei ole mitään muuta käytännön merkitystä kuin Gitin pitäminen tyytyväisenä.

Bashin ja Powershellin komentohistorian käyttö

Mon, 23 Apr 2018 00:00:00 +0000

Unix-komentotulkeissa kuten Bashissa on ollut vuosikaudet varsin monipuoliset tavat palata komentotulkin historiasta löytyviin komentoihin. Nuoli ylös palaa komentohistoriassa taaksepäin ja nuoli alas vie eteenpäin. Koko historian näkee komennolla “history”:

$ history
 1257 git remote -v
 1258 cd /tmp/
 --- snip ---
 2242 id -un 0
 2243 id -gn 0

Tämän voi yhdistää grepin kanssa:

$ history|grep remote
 1264 git remote -v
 --- snip --

Yksi kätevimmistä on haku historiasta: ensin painetaan Ctrl-R ja sen jälkeen syötetään hakusana (alla “gpg”):

RAL ja järjestelmän tilan muuntaminen puppet-koodiksi

Mon, 23 Apr 2018 00:00:00 +0000

Joskus käy niin että verkosta löytyy huolellisesti vuosien mittaan käsin säädetty, mahdollisesti jo edesmenneeltä sysadminilta peritty taideteos, jonka sielunelämästä ei kukaan enää ymmärrä, ja joka uhkaa romahtaa jos hengittää kohti liian kovaa. Se tuottaa mahdollisesti vielä jotakin yritykselle merkityksellistä palveluakin. Mikä avuksi?

Jos näin on päässyt käymään, tai odotetaan suoritettavan muun toistaiseksi villinä ja vapaana ajelevan järjestelmän hallinta puppetilla, on hyvä palauttaa mieleen, että puppet sisältää RAL-kuoren (Resource Abstraction Layer), jonka avulla voidaan tarkastella sitä miten puppet näkee järjestelmän. RAL-kuoren avulla voidaan järjestelmän tila muuntaa puppet-koodiksi pienellä vaivalla. Esimerkiksi hakemistopuun muuntaminen:

Puppet-koodin tiivistäminen each-funktiolla ja resurssien oletusarvoilla

Tue, 13 Mar 2018 00:00:00 +0000

Puppet-koodissa on monia tapoja vähentää koodiin määrää. Silloin, kun pitää luoda useita hyvin samankaltaisia resursseja, on each-funktio erittäin kätevä työkalu. Jos luotavien resurssien erot rajoittuvat yhden parametrin arvoon, riittää seuraava:

# testfiles.pp
 $testfiles = ['/tmp/foo','/tmp/bar']
 $testfiles.each |$testfile| {
 file { $testfile:
 ensure => 'present',
 }
 }

Yllä oleva koodi luo molemmat tiedostot:

$ puppet apply testfiles.pp
 Notice: Compiled catalog for computer.example.org in environment production in 0.13 seconds
 Notice: /Stage[main]/Main/File[/tmp/foo]/ensure: created
 Notice: /Stage[main]/Main/File[/tmp/bar]/ensure: created
 Notice: Applied catalog in 0.03 seconds

Each-funktio on erityisen voimallinen, kun sen käyttämä data määritetään Hash-tyyppisessä muuttujassa. Alla esimerkki ini-tiedoston muokkauksesta gitdaemon-moduulissa:

Ulkoisten faktojen perusteet

Wed, 28 Feb 2018 00:00:00 +0000

Aiemmassa blogikirjoituksessa käsittelin custom faktojen luontia dynaamisesti. Tällä kertaa käsittelemme ulkoisten faktojen (“external facts”) perusteita. Puppetlabsin oma dokumentaatio aiheesta on varsin laadukasta, kunhan sen vain malttaa lukea ajatuksen kanssa (toisin kuin allekirjoittanut).

Ulkoisilla faktoilla tarkoitetaan faktoja, joiden arvon Facter päättelee niiden tulosteesta ja joita ei tyypillisesti ole kirjoitettu Rubyllä vaan esim. Bashilla, Pythonilla tai PowerShellillä. Ne toimivat muutoin kuin “oikeat” faktat, mutta niissä ei voida viitata muihin faktoihin, eikä niitä voi rajata (“confine”) toimimaan vain jossain käyttöjärjestelmässä.

Custom faktojen luonti ohjelmallisesti

Wed, 21 Feb 2018 00:00:00 +0000

Staattisten faktojen kirjoittaminen on varsin helppoa melko vähäisinkin Ruby-taidoin. Alla esimerkki faktasta, joka palauttaa true tai false riippuen siitä, onko noodilla /boot-osiota:

Facter.add(:has_bootfs) do
 setcode do
 if Facter.value(:mountpoints)['/boot'].nil?
 false
 else
 true
 end
 end
 end

Kuten yltä näkyy, itse tieto löytyi jo valmiiksi Facterin “mountpoints”-faktan sisältä: yllä sen sisältöä vain muunnettiin erilliseksi, helposti käsiteltäväksi faktaksi visualisointia ja skriptausta helpottamaan.

Mountpoints-fakta sisältää myös paljon muuta kiinnostaa tietoa, kuten sen, miten suuri osio on ja paljonko siellä on tilaa vapaana. Jos näistäkin tiedoista halutaan luoda samaan tapaan erilliset faktat, voidaan ne helposti luoda dynaamisesti:

XML-tiedostojen muokkaus Puppetin Augeas-resurssilla

Sun, 18 Feb 2018 00:00:00 +0000

NOTE: this article is now also available in English (here).

Aiemmassa blogikirjoituksessa käsittelin Augeaksen käyttöä Puppetin kanssa esimerkkinä PostgreSQL:n pg_hba.conf -tiedoston muokkaus. Tässä kirjoituksessa käsitellään XML-tiedostojen muokkausta Augeaksella, mikä on luultavasti siistein ratkaisu silloin, kun ei haluta hallita koko tiedostoa esimerkiksi ERB-templatena. Alla muokataan Pwm:n web.xml-tiedostoa, johon on määritettävä asetushakemiston polku.

Ennen itse Augeas-resurssin kirjoitusta kannattaa tarkistaa, mikä Augeaksen käsitys muokattavan tiedoston rakenteesta on. Ensin augtoolille pitää kertoa, mistä hallittava tiedosto löytyy:

Lisää läskiä työnkulkuun, osa 5: Hiera ja sisällön kryptaaminen

Mon, 05 Feb 2018 00:00:00 +0000

Puppet-moduulien ja manifestien uudelleenkäytettävyyden vuoksi on suositeltavaa pitää data niistä erillään. Tämä tapahtuu käyttämällä hieraa. Moduulit voivat esimerkiksi tuottaa erilaisia asetuksia käyttämällä hieran perusteella organisaatiohin tai sijainteihin määriteltyä dataa

Hieraan tallennetaan tyypillisesti myös sellaista yksityistä dataa mikä pitää olla suojattua, ja minkä ei haluta joutuvan ulkopuolisten saataville. Tyypillisesti data tallennetaan muun koodin ohella versionhallintajärjestelmään, joka voi olla organisaation rajojen ulkopuolella. Tällöin on käytettävä hieran encryptionta.

Aiemmin yleisesti käytetty hieran salauksen menetelmä oli hiera-gpg. Hiera-gpg:n avulla salattiin koko tiedosto. Hiera-eyaml parantaa tilannetta sallimalla hieratiedoston sisällä haluttujen datalohkojen salaamisen, mikä parantaa käytettävyyttä.

Yleiskatsaus moderniin Puppet 5 ympäristöön

Mon, 05 Feb 2018 00:00:00 +0000

Puppetin palvelinpuoleen kuuluu on nykyisin aikamoinen tukku palvelinsovelluksia, työkaluja ja suositeltuja työnkulkuja:

Palvelinkomponentit
- Puppetserver: Varsinainen Puppet-palvelin, johon Puppet agentit ottavat yhteyttä. Toimii myös itsenäisesti ilman PuppetDB:tä ja Puppetboardia
- PuppetDB: Datasäilö, johon Puppet agentit tallentavat faktojaan ja raporttejaan. Dataan päästään haluttaessa käsin ohjelmallisesti.
- PostgreSQL: PuppetDB:n taustalla oleva tietokantapalvelin
- Puppetboard: PuppetDB:n datan visualisoitiin tarkoitettu webbisovellus.
- Apache 2: Puppetboardin taustalla oleva webbipalvelin
Työkalut
- Git: versionhallintajärjestelmä, josta hallintarepo, r10k ja monien Puppet moduulien käyttö on riippuvaista.
- Hiera: hierarkinen datasäilö Puppet-moduulien, esim. profiilien, parametreille. Voidaan käyttää asiakaskoneiden asetusten räätälöintiin eri luokitteluperustein. Luokittelu voi perustua faktoihin (esim. käyttöjärjestelmäversio, datakeskus) tai asiakaskoneelle erikseen määritettyihin arvoihin (esim. asiakas, koneen kriittisyys liiketoiminnan kannalta).
- Eyaml: Hieran datatiedostossa (yaml) olevan datan kryptaukseen tarkoitettu työkalu. Tärkeä erityisesti silloin, kun Hieran dataa säilötään organisaation ulkopuolella kuten esimerkiksi GitLabissa.
- R10k: työkalu dynaamisten Puppet environmentien hallintaan. Käytännössä r10k luo kustakin hallintarepon haarasta Puppet environmentin. Kukin haara sisältää environmentin vaatimat Puppet-moduulit sekä niiden tarvitsemat parametrit.
Suositellut työnkulut
- Komponenttimoduulien, roolien ja profiilien käyttö
- Hallintarepon ja r10k:n käyttö
- Versionhallinnan (Gitin) käyttö on perusoletus

Lisää läskiä työnkulkuun, osa 1: Hallintarepo

Wed, 31 Jan 2018 00:00:00 +0000

Mikäli muutosten tekeminen Puppet-koodiin ja Hieraan suoraan puppetmasterilla tuntuu liian kevyeltä ja helpolta, voi Puppet-työnkulusta tehdä asteittain vaikeammaksi oman sietokyvyn mukaan lisäämällä palettiin lisää komponentteja. Esimerkiksi ns. control repon ja r10k:n käyttö Puppetin environmentien ylläpitoon lisää heti useita vaiheita aiemmin yksinkertaiseen työnkulkuun. Toki tällä saavutetaan myös ihan oikeita etuja, joista lisää tuonnempana.

Control repo - tästä lähtien osin suomennettuna “hallintarepo” - on käytännössä Git repository, jonka jokaisesta haarasta (branch) luodaan (tai ainakin voidaan luoda) dynaamisesti Puppet masterille vastaava Puppet-environment. Hallintarepon oletushaaran nimi, “production”, on tästä syystä sama, kuin Puppet agenttien oletuksena käyttämä environment. Hallintarepon haaroissa on pitkälti sama sisältö kuin tavanomaisessa /etc/puppetlabs/code/environments/production -kansiossakin olisi:

Lisää läskiä työnkulkuun, osa 2: r10k

Wed, 31 Jan 2018 00:00:00 +0000

Edellisessä blogipostauksessa esiteltiin tyypillinen hallintarepon rakenne. Tässä artikkelissa käsitellään r10k:ta, jolla hallintarepon haaroista muodostetaan Puppet-palvelimelle vastaavat Puppet-environmentit. R10k:n asennus Puppet 4:een tai uudempaan on suoraviivaista Puppet-pakettien mukana tulevalla gem-ohjelmalla:

$ /opt/puppetlabs/puppet/bin/gem install r10k

Tämän jälkeen luodaan r10k:lle asetustiedosto /etc/puppetlabs/r10k/r10k.yaml:

---
 :cachedir: /opt/puppetlabs/puppet/cache/r10k
 :sources:
 control:
 basedir: /etc/puppetlabs/code/environments
 prefix: false
 remote: git@gitlab.com:myorg/control-repo.git

Yllä oletetaan, että hallintarepo (“control repo”) on jo olemassa GitLabissa tai vastaavassa, ja että SSH-avaimet on luotu ja lisätty hallintarepoon sekä mahdollisiin yksityisiin Puppet-moduulirepoihin, joihin Puppetfilessä viitataan.

Lisää läskiä työnkulkuun, osa 3: GitLab ja vastaavat

Wed, 31 Jan 2018 00:00:00 +0000

Edellisissä artikkeleissa käsiteltiin hallintarepoa ja r10k:ta. Vaikka mikään ei estäkään hallintarepon pitämistä Puppetmaster-koneella ja r10k.yaml:n osoittamista siihen, menetettäisiin silloin monta työvaihetta eikä ratkaisu siten sopisi tämän artikkelisarjan teemaan. Viimeinen puuttuva komponentti työnkulun läskiyttämisessä onkin GitLab tai vastaava, kuten GitHub tai Bitbucket. Näistä ensimmäinen soveltuu parhaiten tilanteeseen, jossa halutaan luoda paljon yksityisiä Git-repoja, joista ei haluta maksaa, eikä GitLabin edistyneemmille ominaisuuksille ole käyttöä. GitHubissa jokainen yksityinen repository maksaa, joten se on kallis ratkaisu yksityisten puppet-moduulien säilömiseen. Bitbucket sallii GitLabin tavoin rajoittamattomasti yksityisiä repositoryjä, mutta rajoittaa käyttäjien määrän tällä hetkellä viiteen, eikä tarjoa merkittävästi etuja, paitsi ehkä Trello-integraation, jos Kanbania haluaa käytellä. GitLabilla on puolellaan vielä se etu, että se on avointa lähdekoodia, joten sen voi asentaa myös omaan sisäverkkoon ja käyttää sieltä.

Lisää läskiä työnkulkuun, osa 4: Roolit ja profiilit

Wed, 31 Jan 2018 00:00:00 +0000

Mikäli hallintarepon, r10k:n ja GitLab:in sisältävä työnkulku tuntuu vielä liian kevyeltä, on läskiä ja abstraktiotasoja lisättävissä onneksi toisaalla, nimittäin itse Puppet-moduuleissa. Pelastuksen tarjoaa ns. “Roles and Profiles pattern”, jonka kehitti alunperin Craig Dunn, ja joka löi läpi todennäköisesti Gary Larizzan blogikirjoitusten myötä. Alla käytämme englanninkielisen termin sijaan lähes suomenkielistä termiä “roolit ja profiilit”.

Roolit ja profiilit ovat aivan tavallisia Puppet-luokkia. Ne eivät ole kuitenkaan ole Gary Larizzan termiä käyttäen ns. komponenttimoduuleja, jotka on suunniteltu jonkin yksittäisen asian tekoon, ja jotka olisivat siten (ainakin periaatteessa) jaettavissa muiden käyttäjien kesken esim. Puppet Forgessa.

Windows hallintaan Puppetilla

Tue, 16 Jan 2018 00:00:00 +0000

Puppet on jo pitkään tukenut Windowsia. Monet natiivit Puppet-resurssit, kuten File, Package ja Service ovat jo pitkään toimineet sekä *NIX-käyttöjärjestelmissä että Windowsissa. Lisäksi osa natiiveista Puppet-resursseista, kuten Registry on suunniteltu pelkästään Windows-käyttöön.

Puppetin käyttömukavuus Windows-järjestelmien ylläpidossa on parantunut mutkan kautta muutamien uusien teknologioiden myötä:

Powershell DSC perustuu resurssien tilan hallintaan, aivan kuten Puppetkin. Mikä parasta, Puppet-koodissa voi käyttää natiivien Puppet-resurssien lisäksi Powershell DSC-resursseja. Puppetlabsin blogikirjoitus on hyvä alustus tähän aiheeseen. DSC vaatii toimiakseen Powershell 5.0:n, joka tulee Windows Management Framework 5.0:n mukana.

Powershell ja Windows hosts-tiedoston muokkaaminen

Mon, 15 Jan 2018 00:00:00 +0000

Windowsissa voidaan käyttää hosts-tiedostoa ip-osoitteiden ja nimien liittämiseen toisiinsa, aivan kuten Linuxissakin. Linuxissa tiedoston sijainti on /etc/hosts, Windowsissa se on c:windowssystem32driversetchosts, tai oikeastaan $env:windirsystem32driversetchosts.

Hosts-tiedoston käyttäminen tulee ajankohtaiseksi silloin kun sovellus tarvitsee DNS-nimen, eikä DNS-palvelinta ole käytettävissä, tai sitä ei voida jostakin syystä käyttää.

Jos Puppet agentille ei ole määritetty palvelinta, se yrittää oletuksena yhteyttä palvelimeen jonka DNS-nimi on ‘puppet’, eli jos palvelimelle on määritetty domain ’example.com’, agent hakee palvelinta jonka DNS-nimi on ‘puppet.example.com’ Määrittämällä server-asetuksella palvelimen DNS-nimi, voidaan Puppet agent osoittaa haluttuun palvelimeen. Tämä määritetään Linuxeissa tyypillisesti uusimmissa puppet-versioissa tiedostossa /etc/puppetlabs/puppet/puppet.conf osiossa main tai agent.

Powershell-provisiointiskriptien käyttö Vagrantissa

Mon, 15 Jan 2018 00:00:00 +0000

Vagrantin shell-provisioner tukee suoraan Powershell-skriptejä. Toisin sanoen Windows-virtuaalikoneen asetuksia voi muokata Powershellillä ilman, että tarvitsee rakentaa uusi virtuaalikonekuva. Tyypillinen esimerkki on Windows liittäminen konfiguraationhallintajärjestelmään kuten Puppetiin.

Vagrantin dokumentaatiossa mainitaan, että Powershell-skriptille voi välittää parametreja powershell_args -valinnalla joko merkkijonona (string) tai listana (array). Esimerkkejä etenkin Powershell-provisioinnista on kuitenkin heikosti, mistä syystä tämäkin blogipostaus on kirjoitettu. Otetaan esimerkkinä skripti bootstrap_windows.ps1_,_ joka liittää Windows-virtuaalikoneen olemassa olevaan Puppetserveriin. Sitä käytetään käsin Powershellistä seuraavasti:

> .bootstrap_windows.ps1 -certName win2012r2.local
 -ServerName puppet.local
 -puppetServerAddress 192.168.137.10

Rivinvaihdot on lisätty selvyyden vuoksi.

Vagrant ja Windows-boxien rakentaminen

Mon, 15 Jan 2018 00:00:00 +0000

Vagrant on erittäin kätevä työkalu kehitys- ja testausympäristöjen rakentamiseen. Sillä voidaan helposti ja toistettavasti luoda virtuaalikoneita, joiden asetukset säädetään halutunlaisiksi provisioning-vaiheessa esimerkiksi skripteillä (shell, powershell) tai konfiguraationhallintatyökaluilla kuten Puppetilla. Vagrantin taustalla on yleensä käytössä Oraclen Virtuabox, mutta myös muita virtualisointialustoja tuetaan ns. providerien avulla.

Vagrantilla luodut virtuaalikoneen on myös helppo verkottaa keskenään. Vagrant toimiikin siten hyvin palvelinympäristöjen testauksessa; hyvänä esimerkkinä käy puppet-ipa -moduuli, jossa Vagrantilla luodaan FreeIPA multi-master -palvelinympäristö sekä useita asiakaskoneita eri käyttöjärjestelmillä. Toinen hyvä esimerkki on puppet-bacula -moduuli, jossa Vagrantilla luodaan täydellinen Bacula-varmuuskopiointiympäristö.

Vagrant ja Windows-virtuaalikoneet

Mon, 15 Jan 2018 00:00:00 +0000

Edellisessä artikkelissa rakennettiin Packerilla ja Boxcutter-templateilla Windows box Vagrant-käyttöön. Tässä artikkelissa näytetään, miten Vagrantilla rakennetaan varsinaisia Windows-virtuaalikoneita.

Vagrantia ohjataan Vagrantfile-tiedostolla, joka usein sijaitsee projektin (esim. Puppet-moduuli) päähakemistossa. Jopa hyvin yksinkertainen Vagrantfile riittää Windows-virtuaalikoneen pystyttämiseen:

# -*- mode: ruby -*-
 # vi: set ft=ruby :
 
 Vagrant.configure("2") do |config|
 config.vm.define "win2012r2" do |box|
 box.vm.box = "mwrock/Windows2012R2"
 box.vm.box_version = "0.6.1"
 box.vm.hostname = "windows2012r2a"
 box.vm.network "private_network", ip: "192.168.31.101"
 box.vm.provider "virtualbox" do |vb|
 # Poistetaan Virtualboxin konsolinäkymä käytöstä
 vb.gui = false
 vb.memory = 2048
 end
 end
 end

Yllä käytetään erästä julkista Windows 2012r2 boxia. Aivan yhtä hyvin voitaisiin käyttää aiemmassa artikkelissa Packerilla luotua boxia tähän tapaan:

Puppet-pohjaisten asennusohjelmien luonti Kafolla

Wed, 29 Nov 2017 00:00:00 +0000

Puppet on erittäin kätevä erityisesti hyvin monimutkaisten järjestelmien rakentamisessa ja ylläpidossa. Sen avulla on helppoa myös häivyttää suuriakin käyttöjärjestelmäeroja yhden luokkarajapinnan taakse. Hyvänä esimerkkinä käyvät Puppet-Finland-projektin thunderbird- ja openvpn-moduulit, jotka toimivat useilla eri Linux-jakeluilla ja Windowsilla.

Yleensä Puppettia varten rakennetaan palvelinympäristö, joka koostuu puppetserveristä, yleensä puppetdb:stä sekä mahdollisesti myös puppetboardista tai foremanista. Kullekin hallittavalle koneelle asennettu puppet-agent ottaa yhteyden puppetserveriin esim. kerran puolessa tunnissa, päivittää konfiguraationsa vastaamaan puppetserverillä määriteltyä tilaa ja lähettää raportin puppetserverin kautta puppetdb:lle.

Puppettia voidaan ajaa myös paikallisesti ilman puppetserveriä käyttämällä puppet apply-komentoa esimerkiksi seuraavasti:

Vagrant, Powershell ja parametrien välittäminen

Mon, 13 Nov 2017 00:00:00 +0000

Vagrant on näppärä väline myös Windows-virtuaalikoneiden luontiin esim. Puppet-resurssien testauksessa. Windows-virtuaalikoneille on luontevaa käyttää Powershell-provisiointia, minkä Vagrant tekee melkoisen yksinkertaiseksi. Aika nopeasti ilmenee tarve välittää Powershell-skriptille parametrejä Vagrantin kautta. Tästä on hieman hankalaa löytää esimerkkejä, joten tässä yksi.

Oletetaan että meillä on Powershell-skripti nimeltä bootstrap_windows.ps1 Vagrant-projektin alihakemistossa ‘provision’. Skripti asentaa ja konfiguroi Puppet-agentin Windows-virtuaalikoneelle. Skriptille pitää välittää kaksi parametria: Puppetserverin FQDN (serverName) ja mukavuusbonuksena virtuaalikoneelle haluttu FQDN (certName). (Käytän itse Vagrantille yaml-muotoista ns. data-driven vagrant-tiedostoa, joten syntaksi on hieman erilainen vakiomuotoiseen Vagrant-tiedostoon verrattuna).

Debian 9 automaattisen asennuksen tekeminen muistitikulta

Thu, 21 Sep 2017 00:00:00 +0000

Tässä artikkelissa näytetään kaksi tapaa Debianin asentamiseksi muistitikulta. Ensimmäisessä CD/DVD-asennin yksinkertaisesti kopioidaan muistitikulla, jolloin siitä tulee kätevämpi ja nopeampi CD-levyn korvike. Toinen tapa on monimutkaisempi, mutta mahdollistaa asennusten automatisoinnin helposti. Alla oletetaan, että muistitikun laitetiedosto on /dev/sdb ja että komennot ajetaan pääkäyttäjän oikeuksin esim. sudoa käyttämällä.

Koska väärän laitetiedoston käyttäminen voi ylikirjoittaa koko järjestelmälevyn, on muistitikun laitetiedosto syytä tarkistaa esimerkiksi “dmesg”-komennolla:

[79499.127904] usb 2-1.2: new high-speed USB device number 13 using ehci-pci
 [79499.230913] usb 2-1.2: New USB device found, idVendor=0951, idProduct=1607
 [79499.230918] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 [79499.230920] usb 2-1.2: Product: DataTraveler 2.0
 [79499.230921] usb 2-1.2: Manufacturer: Kingston
 [79499.230923] usb 2-1.2: SerialNumber: 5B840D0001DA
 [79499.231294] usb-storage 2-1.2:1.0: USB Mass Storage device detected
 [79499.231633] scsi16 : usb-storage 2-1.2:1.0
 [79500.230217] scsi 16:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
 [79500.230722] sd 16:0:0:0: Attached scsi generic sg1 type 0
 [79500.460385] sd 16:0:0:0: [sdb] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
 [79500.461321] sd 16:0:0:0: [sdb] Write Protect is off
 [79500.461327] sd 16:0:0:0: [sdb] Mode Sense: 23 00 00 00
 [79500.462022] sd 16:0:0:0: [sdb] No Caching mode page found
 [79500.462028] sd 16:0:0:0: [sdb] Assuming drive cache: write through
 [79500.465797] sdb: sdb1
 [79500.468449] sd 16:0:0:0: [sdb] Attached SCSI removable disk

Lisäksi on syytä vamistaa, että kyseiseltä muistitikulta on ylipäätään mahdollista bootata käyttöjärjestelmä tai sen asennin; kaikilta ei nimittäin voi.

Debian snapshots

Tue, 20 Dec 2016 00:00:00 +0000

Törmäsin eilen varsin hyödylliseen sivustoon nimeltään snapshot.debian.org. Sieltä löytyvät kaikki julkaistut Debian-projektin pakettien versiot. Tämä mahdollistaa pakettien päivittämisen sekä vanhempiin että uudempiin versioihin, mistä on hyötyä mm. selvitettäessä onko jonkin ongelman syy ohjelmistovirhe vai konfiguraatiovirhe.

Ohjelmistolähteenä snapshots.debian.org ei toimi, toisin kuin esim. backports.debian.org.

Sekalaisia komentoja Samban debuggaukseen

Tue, 20 Dec 2016 00:00:00 +0000

Alla tukku hyödyllisiä komentoja Samban debuggaukseen. Oletus on, että Samba AD DC ja Domain Member-palvelinten konfiguraatiot ovat pääosin kunnossa. Tähän pisteeseen päästään helpohkosti Puppet-Finland -projektin samba4-moduulilla. Täysin hands off -asennus on varsin haastava, joten debuggaustyökaluille tulee väistämättä tarvetta.

Tarkistetaan, onko member-nimisellä koneella jo machine account Samban LDAP:ssa, eli onko se jo liitetty domainiin:

$ net ads dn 'CN=member,CN=Computers,DC=smb,DC=domain,dc=com' cn -U administrator%password
 Got 1 replies
 
 cn: member

Tässä eräs toinen tapa selvittää, onko member-kone liitetty domainiin. Tähän vaaditaan Debianissa ldb-tools -paketin asentaminen ja komento on ajettava DC-koneella:

Prosessien tietojen etsiminen Powershellillä

Wed, 09 Nov 2016 00:00:00 +0000

UNIX-tyyppissä järjestelmissä prosessitaulun tarkastelu on helppoa ps-komennolla. Samainen komento löytyy Powershellistäkin, mutta se on vain alias Get-Process CmdLetille, jolla saadaan helposti selville, mitä prosesseja järjestelmässä on käynnissä (alla typistetty tuloste):

> Get-Process
 
 Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
 ------- ------ ----- ----- ----- ------ -- -----------
 136 8 6428 8084 569 0.08 916 bash
 26 3 1496 2272 16 0.02 1560 cmd
 57 7 1096 5852 57 0.03 2144 firefox
 0 0 0 4 0 0 openvpn
 88 7 988 3668 50 0.02 2676 openvpnserv
 34 3 500 2332 14 0.00 4940 openvpnserv
 562 27 151992 161440 615 4.27 2388 powershell

Jos prosessin nimi on jo tiedossa, voidaan se antaa -Name -parametrilla - huomaa, että .exe jätetään pois lopusta:

Cobbler autodetect system name

Wed, 05 Oct 2016 00:00:00 +0000

Cobblerissa on eräs varsin heikosti dokumentoitu ominaisuus, jonka avulla on mahdollista selvittää, mikä kyselyn tekevän koneen nimi Cobblerissa on. Tästä on hyötyä esimerkiksi Windowsin bootstrappauksessa, jotta saadaan noudettua oikeaan Cobbler System-olioon liittyvä Unattended.xml -tiedosto. Linuxien tapauksessa tähän kikkailuun ei ole tarvetta, koska Cobblerin parametrit välittyvät käyttöjärjestelmän asentimelle suoraan kickstart- tai preseed tiedoston mukana.

Itse ominaisuus on erittäin yksinkertainen käyttää, kunhan muistaa ajaa sen siltä koneelta, jonka System name halutaan tietää:

Cobbler templatet

Wed, 05 Oct 2016 00:00:00 +0000

Käytämme työasemien ja osin myös palvelimien provisioinnissa Cobbleria. Se on vahvimmillaan juuri fyysisten laitteiden provisionnissa, vaikka perustason tuki myös virtuaalikoneiden provisioinnille löytyykin. Cobbler nitoo yhteen lukuisia eri palveluita (dhcp, dns, tftp) Python-koodin avulla, joten aivojen vääntäminen sen vaatimiin asetuksiin vie aikansa. Cobblerin perusdokumentaatio on RedHatille tyypilliseen tyyliin varsin hyvää, mutta ongelmiin joutuu helposti, kun halua tehdä jotain virallisen dokumentaation ulkopuolelta. Esimerkiksi Cobblerin web-API on dokumentoitu varsin heikosti, lähinnä tässä Wiki-artikkelissa. Tässä ja tulevissa blogikirjoituksissa pyritään paikkaamaan Cobblerin dokumentaation puutetta.

Hieran debuggauksesta

Wed, 15 Jun 2016 00:00:00 +0000

Toisinaan Puppet-koodissa on tarve tehdä haku Hierasta, mutta se ei toimi odotetulla tavalla. Näissä tapauksissa auttaa “puppet lookup”-komento:

$ puppet lookup --node www.domain.com --explain bacula::filedaemon::backup_files
 Data Binding "hiera"
 Found key: "bacula::filedaemon::backup_files" value: [
 "/etc",
 "/var/lib/puppet/ssl",
 "/var/backups/local"
 ]

Erikoista kyllä, tämä komento löytää ainoastaan ne Hieran hierarkian tasot, jotka perustuvat faktoihin:

---
 :backends:
 - yaml
 :hierarchy:
 - "nodes/%{::trusted.certname}"
 - "roles/%{::role}"
 - "lsbdistcodename/%{::lsbdistcodename}"
 - "osfamily/%{::osfamily}"
 - "kernel/%{::kernel}"
 - common
 
 :yaml:
 :datadir:

Yllä muuttuja role ei siis ole fakta, vaan se on oikeastaan parametri tai käytänne, joka määritetään noodin yaml-tiedostossa:

Windowsin järjestelmätiedostojen ylikirjoittaminen Puppetilla

Sat, 09 Apr 2016 00:00:00 +0000

Windowsin järjestelmätiedostoja ei useinkaan pysty muuttamaan käsin - tai Puppetilla - ilman niiden suojaustason alentamista. Ongelma on siinä, että järjestelmätiedostojen omistaja on usein (pseudo)käyttäjä “TrustedInstaller”, eikä edes administrator-tason käyttäjillä ole niihin kirjoitusoikeutta. Onneksi rajoitukset voi kiertää melko suoraviivaisesti käyttämällä takeown.exe -komentoa sekä puppetlabs/acl -moduulia. Alla on muokattu erästä Group Policyn XML-tiedostoa, jonka merkistökoodaus oli siinä määrin poikkeuksellinen, että sen lukeminen Rubyn reXML -kirjastolla ei onnistunut:

include ::acl
 
 # Vaihda tiedoston omistaja
 exec { 'takeown-Search.admx':
 command => 'C:WindowsSystem32takeown.exe /f C:WindowsPolicyDefinitionsSearch.admx',
 }
 
 # Määritä uudet oikeudet
 acl { 'Search.admx':
 target => 'C:/Windows/PolicyDefinitions/Search.admx',
 permissions => [
 { identity => 'Järjestelmänvalvojat', rights => ['full'] },
 { identity => 'SYSTEM', rights => ['full'] }
 ],
 require => Exec['takeown-Search.admx'],
 }
 
 # Korvaa tiedosto
 file { 'C:/Windows/PolicyDefinitions/Search.admx':
 source => 'puppet:///modules/winpolicydefinitions/Search.admx',
 require => Acl['Search.admx'], 
 }

Tästä prosessista kannattaisi muokata oma määritelty resurssinsa, tai jopa peräti oma tyyppinsä, mikäli sille löytyisi runsaasti käyttöä. Takeown-komentoon kannattaisi lisätä myös “unless”-parametri, jotta sitä ei ajeta turhaan joka kerta. Jos Execissä olisi “provider => ‘powershell’”, niin tarkistuksen voisi tehdä muutamin eri tavoin.

Windowsin paikallisten ryhmäkäytäntöjen muokkaus Puppetilla

Sat, 09 Apr 2016 00:00:00 +0000

Monia Windowsien asetuksia on perinteisesti muokattu ryhmäkäytänteillä (“Group Policy”). Vaikka ryhmäkäytänteiden teho onkin melko rajallinen, pystyy niillä tekemään yhtä ja toista. Microsoft on kuitenkin Powershell DSC:n kuitenkin siirtymässä tilan hallintaan perustuviin modernimpiin ratkaisuja, joten Group Policyt jäänevät lähivuosina historiaan.

Tästä huolimatta ryhmäkäytänteitä hyödynnetään yhä erityisesti Active Directory -toimialueiden (“domain”) kanssa silloin, kun halutaan standardisoida työasemien asetuksia. Myös Samba 4 tukee ryhmäkäytänteiden jakelua työasemille. Ryhmäkäytänteet eivät kuitenkaan vaadi Active Directoryn tai Samba 4:n käyttöä, sillä käytänteitä voidaan määrittää paitsi verkkoalueelle, myös paikallisesti (“Local Group Policy”). Käytänteet voidaan lisäksi jakaa käyttäjäkohtaisiin (“User policy”) ja tietokonekohtaisiin (“Machine policy”).

Powershelliä UNIX-ylläpitäjille, osa 12

Wed, 06 Apr 2016 00:00:00 +0000

Toisinaan tulee tarpeelliseksi etsiä yhdestä tai useammasta tiedostosta jotakin merkkijonoa ja tulostaa täsmäävä rivi sekä tiedosto, jossa se on, sekä rivinumero. GNU grepillä tämä onnistuu triviaalisti komennolla “grep -HN pattern”:

$ grep -Hn REXML *.rb
 group_policy.rb:71: dFile = REXML::Document.new( File.new("#{dDir}\#{array[0][0]}.admx"))
 group_policy.rb:72: eFile = REXML::Document.new( File.new("#{eDir}\#{array[0][0]}.adml"))
 group_policy.rb:154: dFile = REXML::Document.new( File.new("#{dDir}\#{sys_tShort}.admx"))
 group_policy.rb:155: eFile = REXML::Document.new( File.new("#{eDir}\#{sys_tShort}.adml"))
 group_policy.rb:428: dFile = REXML::Document.new( File.new("#{dDir}\#{tShort}.admx"))
 group_policy.rb:429: eFile = REXML::Document.new( File.new("#{dDir}\#{adml}"))

Sama homma onnistuu myös Powershellissä, mutta hieman vaikeammin:

Powershelliä UNIX-ylläpitäjille, osa 10

Thu, 10 Mar 2016 00:00:00 +0000

Windowsin käynnistyviin ohjelma- ja kirjastotiedostoihin liittyy paljon erilaista metatietoa, esimerkiksi ohjelman versionumero, julkaisija yms. Näiden metatietojen tarkastelu on toisinaan hyödyllistä, etenkin ohjelmistoja testattaessa. Alla OpenVPN:n bin -kansion sisältö kokonaisuudessaan:

PS C:Program FilesOpenVPNbin> Get-ChildItem 
 
 Directory: C:Program FilesOpenVPNbin 
 
 Mode LastWriteTime Length Name
 ---- ------------- ------ ----
 -a--- 7.3.2016 16:40 1753440 libeay32.dll 
 -a--- 7.3.2016 16:40 226432 liblzo2-2.dll
 -a--- 7.3.2016 16:40 123000 libpkcs11-helper-1.dll 
 -a--- 7.3.2016 16:40 465760 openvpn-gui.exe
 -a--- 7.3.2016 16:40 965984 openvpn.exe 
 -a--- 7.3.2016 16:40 65888 openvpnserv.exe 
 -a--- 7.3.2016 16:40 396640 ssleay32.dll

Metatiedot on tallennettu tiedosto-objektin VersionInfo-parametriin - alla tarkastellaan openvpn.exe -tiedoston metatietoja:

Powershelliä UNIX-ylläpitäjille, osa 11

Thu, 10 Mar 2016 00:00:00 +0000

Windowsin tuoteavain (“Product Key”) löytyy esiasennetuissa koneissa usein koneen pohjasta, mutta entäpä jos Windows onkin jälkiasennettu, tai koneen pohjassa oleva tarra ei edustakaan todellisuutta? Jos tällainen kone soseutuu, ei tuoteavainta löydy tietenkään mistään fyysisestä paikasta, ja tuloksena on kone ilman Windowsia; tämä voi toki olla toivottavakin asiaintila, mutta lähdetään siitä oletuksesta, ettei näin ole.

Tuoteavain on onneksi tallennettu Windowsin rekisteriin, mistä sen saa otettua talteen useilla eri tavoilla. Koska tässä blogissa keskitytään automaatioon ja Powershellin, mitkään graafiset kikkareet eivät luonnollisestikaan tule kyseeseen. Onneksi homma hoituu myös alla olevalla Powershell-skriptillä (lähde):

Powershelliä UNIX-ylläpitäjille, osa 9

Sun, 03 Jan 2016 00:00:00 +0000

Toisinaan on tarpeen lisätä tekstitiedoston loppuun rivejä. UNIX:ssa tämä onnistuu helposti echo-komennolla:

$ echo matti >> vpn.pass
 $ echo salasana >> vpn.pass
 $ cat vpn.pass
 matti
 salasana

Sama onnistuu Powershellissä, mutta ei suinkaan Write-Host -komennolla, joka olisi echo-komennon lähin vastine, vaan Add-Content -komennolla:

> Add-Content vpn.pass -Value matti
 > Add-Content vpn.pass -Value salasana
 > Get-Content vpn.pass
 matti
 salasana

Toinen melko yleinen tarve on tiedostojen lataaminen verkosta suoraan komentoriviltä. UNIX:ssa tämä onnistuu helpoiten wget-komennolla:

Powershelliä UNIX-ylläpitäjille, osa 8

Mon, 22 Jun 2015 00:00:00 +0000

Tietyn nimisten tiedostojen (tai tyyppisten) poistaminen hakemistosta on melko suoraviivaista GNU findilla:

$ ls
 README.txt stderr.log stdout.log
 $ find . -maxdepth 1 -type f -name "*.log" -exec rm -f {} +
 $ ls
 README.txt

Valinta “maxdepth 1” estää findia poistamasta tiedostoja mahdollisista alihakemistoista.

Toinen vaihtoehto on putkittaa tiedostolistaus xargsille:

$ ls
 README.txt stderr.log stdout.log
 $ ls *.log|xargs rm -f
 $ ls
 README.txt

Tässä ei kuitenkaan erotella toisistaan tiedostoja ja hakemistoja, joten myös mahdolliset .log -päätteiset hakemistot yrittäisiin poistaa siinä epäonnistuen.

Powershelliä UNIX-ylläpitäjille, osa 6

Wed, 17 Jun 2015 00:00:00 +0000

UNIX-tyyppisissä käyttöjärjestelmissä on tulee usein tarve etsiä jostain hakemistosta lähiaikoina (alla minuutin sisällä) muuttuneet tiedostot:

$ find /var/log/ -mmin -1
 /var/log/debug
 /var/log/user.log
 /var/log/auth.log
 /var/log/syslog

Sama onnistuu myös Powershellissä ainakin kahdella tavalla, joista ensimmäinen on toiminnallisesti identtinen yllä olevan komennon kanssa:

PS C:UsersAdministratorDownloads> Get-ChildItem . -Recurse|Where-Object { $_.LastWriteTime -ge $(Get-Date).AddMinutes(-120) }|Select LastWriteTime, Name
 
 LastWriteTime Name 
 ------------- ----
 6/18/2015 install.bat

Yllä oleva komento käy läpi koko hakemiston rekursiivisesti tarkistaen jokaisen tiedoston kohdalla viimeisimmän kirjoitusajan ja verraten sitä Date-objektiin, jossa nykyisestä kellonajasta on vähennetty 120 minuuttia. Toisin sanoen komento näyttää ne tiedostot tai hakemistot, joita on muokattu viimeisen 120 minuutin sisällä. Selkeyden vuoksi tiedostojen tiedoista näytetään selkeyden vuoksi vain nimi ja kirjoitusaika.

Powershelliä UNIX-ylläpitäjille, osa 7

Wed, 17 Jun 2015 00:00:00 +0000

Tulosteiden uudelleenohjaus ja paluuarvojen käsittely toimii lähes samoin *NIX-shelleissä ja Windowsin Powershellissä. Alla tarkistetaan Linuxin systemctl-komennolla olemassa olevan (“openvpn”) ja olemattoman (“fake”) palvelun tila, ohjataan sekä tuloste että virhetuloste bittitaivaaseen ja tulostetaan komennon paluuarvo:

$ systemctl status openvpn > /dev/null 2>&1
 $ echo $?
 0
 $ systemctl status fake > /dev/null 2>&1
 $ echo $?
 3

Kuten näkyy, paluuarvo on 0 jos palvelu on olemassa ja 3 jos sitä ei löydy.

Useiden resurssien luonti lista-parametrien avulla

Mon, 15 Jun 2015 00:00:00 +0000

Toisinaan tulee tarve luoda useita samankaltaisia resursseja, joissa vain jonkin yksittäisen ominaisuuden arvo muuttuu. Esimerkiksi intranetin webbipalvelimeen voi joutua sallimaan yhteydet palomuurin läpi sekä sisäverkon että VPN:n osoiteavaruudesta. Vaikka Puppet ei suoraan tuekaan iteraatiota, sitä voi emuloida antamalla resurssin nimeksi ($title) listan merkkijonon sijaan.

Esimerkiksi Puppet-Finlandin webserver-moduulissa on parametrit $allow_address_ipv4 ja $allow_address_ipv6. Ne voivat saada arvokseen joko merkkijonon (‘192.168.55.0/24’) tai listan ([‘192.168.55.0/24’, ‘10.69.0.0/16’]):

class webserver::packetfilter
 (
 $allow_address_ipv4,
 $allow_address_ipv6
 
 ) inherits webserver::params

Kummankin parametrin arvo annetaan ::webserver::packetfilter::allow_ip -resurssin nimeksi ($title):

Powershelliä UNIX-ylläpitäjille, osa 5

Wed, 13 May 2015 00:00:00 +0000

Windowsissa tekstimuotoisia lokitiedostoja UNIX:in tapaan ole, vaan niitä vastaa EventLog, jonka sisältöä voi tutkia kätevästi PowerShellillä. EventLogin lokit (Logs) voi listata seuraavasti:

PS C:> Get-EventLog -List 
 
 Max(K) Retain OverflowAction Entries Log 
 ------ ------ -------------- ------- --- 
 20 480 0 OverwriteAsNeeded 3 787 Application 
 20 480 0 OverwriteAsNeeded 0 HardwareEvents 
 512 7 OverwriteOlder 0 Internet Explorer 
 20 480 0 OverwriteAsNeeded 0 Key Management Service 
 20 480 0 OverwriteAsNeeded 2 606 Security 
 20 480 0 OverwriteAsNeeded 1 684 System 
 15 360 0 OverwriteAsNeeded 4 823 Windows PowerShell

Halutun lokin (alla System) viimeisimmät kirjaukset (alla 10) saa näytettyä -Newest -vivulla:

Puppet-moduulien laadunvarmistus, osa 1: automaattiset tarkistustyökalut

Mon, 27 Apr 2015 00:00:00 +0000

Puppet-moduulien laatu pysyy korkeana, kun syntaksi- ja tyylivirheitä päästetä edes versionhallintaan asti. Puppet-koodin syntaksivirheet löytyvät helposti:

$ puppet parser validate tiedosto

ERB-templateiden virheet saa selvitettyä seuraavalla tavalla:

$ erb -P -x -T '-' tiedosto|ruby -c

JSON-tiedostojen (metadata.json) virheet etsiminen vaatii hieman kikkailua:

$ cat tiedosto|json_pp -f json -t null

Tyylivirheitä voi etsiä puppet-lint -työkalulla:

$ puppet-lint tiedosto
 $ puppet-lint .

Puppet-lint tunnistaa myös puppet-koodin, joka on eteenpäin tai taaksepäin epäyhteensopivaa. Onkin hyvin järkevää ajaa puppet-koodi aina puppet-lintin läpi ennen suuria Puppet-ympäristön päivityksiä.

Käyttöjärjestelmäerojen hallinta Puppetissa, osa 1

Sun, 26 Apr 2015 00:00:00 +0000

Puppet-moduulit on melko helppo rakentaa siten, että ne saa helposti toimimaan eri käyttöjärjestelmissä ja käyttöjärjestelmäversioissa. Alla ovat itse hyväksi toteamani kolme korkea tason tapaa käyttöjärjestelmäerojen hallintaan kevyimmästä raskaimpaan:

Params-luokan käyttö
Käyttöjärjestelmäriippuvaisten aliluokkien käyttö
Uuden moduulin rakentaminen

Menetelmillä 1 ja 2 pystyy käytännössä hallitsemaan kaikki Unix-tyyppisten käyttöjärjestelmien väliset erot. Menetelmää 3 ei juuri tarvita, paitsi jos jokin käyttöjärjestelmä (lue: Windows) eroa muista käytössä olevista huomattavan paljon.

Pieniin eroihin riittää siis params-luokan käyttö. Otetaan esimerkiksi vaikkapa Puppet-Finlandin ntp-moduuli:

Augeas-resurssien luonnista ja debuggaamisesta

Tue, 14 Apr 2015 00:00:00 +0000

NOTE: this article is now also available in English.

Puppetin Augeas-resurssilla voidaan muokata konfiguraatiotiedostojen osia sen sijaan, että hallittaisiin koko tiedostoa esim. templatella tai staattisella tiedostolla. Koko tiedoston hallinta tuottaa yleensä varmemmin ja vähemmällä vaivalla halutun lopputuloksen, mutta erityisesti luettelomaisten konfiguraatiotiedostojen tapauksessa Augeas-resurssi on erittäin käyttökelpoinen. Augeaksen käyttö ei-triviaaleissa tapauksissa on kuitenkin varsin haastavaa, ja usein onkin hyödyllistä rakentaa oikeat komennot käsin “augtool”-kehotteessa ja vasta sitten muuntaa ne Puppetin Augeas-resurssiksi.

Aluksi kannattaa tutkia, mikä Augeaksen näkemys jonkin konfiguraatiotiedoston rakenteesta on (ylimääräisiä rivejä on poistettu):

Powershelliä UNIX-ylläpitäjille, osa 3

Thu, 19 Mar 2015 00:00:00 +0000

Powershelliä konffatessa on tullut taas törmättyä useisiin varsin käyttökelpoisiin komentoihin. Alla ei-kattava lista, sillä lisää on luvassa sopivalla hetkellä.

Hakemiston poistaminen rekursiivisesti:

$ rm -rf hakemisto
 > Remove-Item -Recurse -Path hakemisto

Tiedoston viimeisten rivien näyttäminen:

$ cat tiedosto|tail -n <rivien_määrä>
 > Get-Content tiedosto -Last <rivien_määrä>

Tiedoston ensimmäisten rivien näyttäminen

$ cat tiedosto|head -n <rivien_määrä>
 > Get-Content tiedosto -First <rivien_määrä>

Tiedoston rivien määrän laskeminen:

Powershelliä UNIX-ylläpitäjille, osa 4

Thu, 19 Mar 2015 00:00:00 +0000

Lisävinkkejä tuli keksittyä nopeammin kuin alunperin osasin uumoillakaan. Näille on ollut käyttöä jo useaan kertaan.

Prosessin ID:n löytäminen:

$ ps aux|grep nimi
 > Get-Process -Name nimi

Prosessin tappaminen PID:n perusteella

$ kill pid
 > Stop-Process -Id pid

Prosessin tappaminen nimen perusteella

$ pkill nimi
 > Stop-Process -Name nimi

Powershelliä UNIX-ylläpitäjille -artikkelisarjan muut osat:

Powershelliä UNIX-ylläpitäjille, osa 2

Mon, 23 Feb 2015 00:00:00 +0000

Alla on varsin hyvä vertailu Bashin ja Powershellin komennoista englanniksi (EDIT: sivu on sittemmin valitettavasti poistunut):

BASH and PowerShell Quick Reference

Kuten näkyy, Powershellissä on valmiina melko suuri määrä UNIX-tyyppisiä komentojen aliaksia. Aliakset viittaavat kuitenkin Powershell-komentoihin, joten esimerkiksi niiden valitsimet poikkeavat merkittävästi UNIX-komentojen vastaavista.

Powershelliä UNIX-ylläpitäjille -artikkelisarjan muut osat:

Powershelliä UNIX-ylläpitäjille, osa 1

Wed, 18 Feb 2015 00:00:00 +0000

Windows-työasemien ja -palvelinten ylläpidosta voi tehdä huomattavasti tehokkaampaa ja hauskempaa Windows Powershellillä. Aiempaan Windowsin komentoriviin (cmd.exe) verrattuna Powershell on varsin ylivoimainen. Tietyt toimet ovat Powershellissä jopa helpompia kuin Unixin komentorivissä kuten Bashissa.

Powershellissä käsitellään tekstirivien tai binääridatan sijaan objekteja. joita voidaan putkittaa komennolta toiselle. Objektien käsittely on usein huomattavasti yksinkertaisempaa kuin tekstin, koska komennoissa voidaan viitata objektien ominaisuuksiin, eikä syötettä tarvitse UNIX:in komentorivien tapaan ensin siistiä ja pilkkoa lukuisilla komennoilla (esim. sed, cut, tr ja awk) oleellisen tiedon erottelemiseksi.

Määriteltyjen resurssien luonti suoraan Puppet-luokista

Mon, 02 Feb 2015 00:00:00 +0000

Jotkin Puppet ENC:t (External Node Classifier), hyvänä esimerkkinä Foreman, eivät tue määriteltyjen resurssien (Defined Resource Types) käyttöä suoraan, vaan kaikki konfiguraatiot pitää sisällyttää Puppet-luokkiin.

Myös Hieran kanssa määritellyt resurssit ovat hieman ongelmallisia, koska ne pitää erikseen luoda create_resources funktiolla. Eräs ratkaisu on määrittää kaikki create_resources -funktiot site.pp-tiedostossa (sovellettu täältä):

create_resources('mysqldump::backup',hiera('mysqldump_backups', {}))

Tämän lähestymistavan ongelma on se, että uudet määritellyt resurssit pitää muistaa lisätä site.pp-tiedostoon.

Yksinkertaisempi ja myös Foremanin kanssa toimiva ratkaisu on luoda määritellyt resurssit suoraan Puppet-moduulin pääluokasta (sovellettu täältä):

Hakemistorakenteen luonti rekursiivisesti Puppetilla

Tue, 20 Jan 2015 00:00:00 +0000

Puppetin File-resurssilla hallitaan tyypillisesti yksittäisiä tiedostoja, hakemistoja tai linkkejä. Tämä on ongelmallista, jos hallittava tiedosto on syvän hakemistorakenteen alla, eikä hakemistorakennetta ole luotu esimerkiksi ohjelman asennuksen yhteydessä. File-resurssi osaa kuitenkin luoda useita tiedostoja, kun sen otsakkeelle ($title) annetaan merkkijonon sijaan lista-tyyppinen muuttuja. Alla esimerkki bind-moduulista

file { [ '/var/named/chroot',
 '/var/named/chroot/var',
 '/var/named/chroot/var/named',
 '/var/named/chroot/Var/named/data' ]:
 ensure => directory,
 owner => root,
 group => "${::os::params::admingroup}",
 mode => 755,
 require => Class['bind::install'],
 }

Bindin zone-tiedostoja ei voi asentaa, ennen kuin hakemisto /var/named/chroot/var/named/data on olemassa. Siis zone-tiedostoon pitää lisätä riippuvuus (Require) yllä olevan luettelon viimeiseen tiedostoon: