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.
Cobblerin templateja voi käyttää yksinkertaiseen konfiguraationhallintaan Cobblerilla asennetuilla koneilla. Muita konfiguraationhallintajärjestelmiä (esim. Puppet) käytettäessä Cobblerin templateista on hyötyä kuitenkin toisaalla: niiden avulla voidaan luoda esimerkiksi dynaamisesti luotuja skriptejä käyttöjärjestelmäasennuksia varten. Alla yksinkertainen esimerkki.
Ensin luodaan template-tiedosto, esimerkiksi /var/lib/cobbler/templates/test1:
#set $hostname = $getVar("hostname","")
Hostname: $hostname
Template hakee siis Cobblerilta arvon "hostname" ja tulostaa sen tekstin "Hostname:" perään. Tämän jälkeen template liitetään profiiliin (kuten alla) tai systemiin:
$ cobbler profile edit --name=centos7 --template-files="/var/lib/cobbler/templates/test1=1"
Parametrin --template-files arvo koostuu kahdesta osasta:
Seuraavaksi tarkistetaan vielä, että template todellakin liitettiin profiiliin:
$ cobbler profile report --name=centos7|grep "Template Files"
Template Files : {'/var/lib/cobbler/templates/test1': '1'}
Nyt template on olemassa ja sen pohjalta luotu tiedosto voidaan noutaa esim. curl-komennolla Cobbler-palvelimelta:
$ curl -s http://127.0.0.1/cblr/svc/op/template/system/web.domain.com/path/1 Hostname: web.domain.com
Oleellista tässä on paitsi se, että test1-templaten sisältö luodaan dynaamisesti, myös se, että tiedosto voidaan ladata Cobblerin webbipalvelimelta. Tämä on kätevää esimerkiksi Windowsia provisioitaessa, sillä Cobbler ei pysty välittämään mitään System-olion parametrien arvoja WinPE:lle suoraan sen käynnistyksen yhteydessä, vaan parametrit on selvitettävä jälkikäteen.
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ää:
$ curl -s http://cobbler.domain.com/cblr/svc/op/autodetect/ web.domain.com
Jos sama komento ajetaan esimerkiksi Cobbler-palvelimelta itseltään, saadaan vastaukseksi vain tämä:
$ curl -s http://127.0.0.1/cblr/svc/op/autodetect/ FAILED: no match (127.0.0.1,None)
Yllä oleva virhe johtuu siitä, että Cobbler (services.py) käy läpi Cobblerin System-oliot ja etsii niiden verkkoliitännöistä kyselyn tehneen koneen MAC-osoitetta. Koska Cobbler-konetta ei ole luotu Cobblerilla, ei sille ole myöskään vastaavaa System-oliota, ja lopputulos on "FAILED: no match".
Sama asia on tehty eri tavoin ja huomattavasti vaikeammin Cobbler and Windows -artikkelissa, joka on valitettavasti yksi harvoista Windowsien provisiointia Cobblerilla käsittelevistä lähteistä. Omien testieni perusteella em. artikkelin lähestymistapa ei itse asiassa toimi ainakaan käyttämällämme Cobblerin versiolla.
