Puppet è una infrastruttura per l’automatizzazione della gestione e amministrazione di un parco macchine UNIX-like.
Il framework è composto da un puppet master che è il server centrale incaricato di raccogliere tutte le azioni e i file di configurazione utilizzati e da svariati puppet, agenti che vengono installati sulle macchine che si vogliono controllare e periodicamente contattano il master per conoscere nuove configurazioni e controllare se il proprio stato è in linea con quanto richiesto dal server centrale. Per ultime ci sono le recipe, le ricette, file di testo che descrivono le azioni da intraprendere sui puppet e i file di configurazione da utilizzare.

Puppet è disponibile già pacchettizzato per la maggior parte delle distribuzioni Linux, vediamo come è possibile eseguire un setup di prova di un puppet master e di un singolo client su macchine Debian Etch. Prima di proseguire, però, una piccola nota: la versione inclusa in Etch è piuttosto vecchia e non implementa alcune feature interessanti, come la gestione delle ricette via moduli, presenti in versioni più recenti del programma. Se si vuole sperimentare con queste nuove caratteristiche è comunque sempre possibile installare senza problemi i pacchetti dal repository Testing, in quanto gli sviluppatori si assicurano che tali pacchetti siano sempre compatibili con la versione Stable della distribuzione.

1. Il puppet master
Raggiungete la macchina prescelta come puppet master che chiameremo, senza troppa fantasia, master e installate i programmi necessari:

root@master:~# apt-get install puppetmaster

Questa operazione installerà anche le dipendenze, compreso il pacchetto per l’agent puppet.
L’installazione terminerà con uno sconfortante errore: niente paura! Il master non è ancora stato configurato a dovere e gli script di init non sono in grado di avviarlo correttamente.
Preoccupiamoci innanzitutto di permettere l’accesso ai file che verranno serviti dal nostro master, editate il file /etc/puppet/fileserver.conf e aggiungete una riga per permettere l’accesso alla sottorete 192.168.0.0/24 (per esempio):

[files]
  path /etc/puppet/files
  allow 192.168.0.0/24

A questo punto creiamo una configurazione iniziale, editate il file /etc/puppet/manifests/site.pp con il seguente contenuto:

# Main puppet master configuration
import "classes/*.pp"
 
node default {
  import sudo
}

La prima riga richiede l’inclusione dei file .pp (le ricette) presenti nella cartella classes, vedremo tra poco come crearli, le successive definiscono la configurazione di default da servire ai nodi e questa richiede l’implementazione della ricetta “sudo”.
Vediamo, dunque, la nostra prima ricetta: “sudo”, questa ricetta si preoccupa di controllare che i permessi del file /etc/sudoers siano corretti. Creiamo la cartella per le ricette:

root@master:~# mkdir /etc/puppet/manifests/classes

Dopo di che scriviamo il file /etc/puppet/manifests/classes/sudo.pp:

# Testing class for sudoers permissions
class sudo {
 
        file { "/etc/sudoers":
                owner => "root",
                group => "root",
                mode => 440,
        }
 
}

Il master è stato configurato correttamente, occupiamoci ora del client locale, editate /etc/puppet/puppetd.conf con i seguenti contenuti:

[puppetd]
# Make sure all log messages are sent to the right directory
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
server=master

Fatto! Master e puppet (locale) sono stati configurati correttamente, proviamo quindi la configurazione in locale, come prima azione simuliamo un guasto cambiando i permessi di sudoers:

root@master:~# chmod 700 /etc/sudoers

Ora, riavviamo i servizi del master e del puppet locale:

root@master:~# /etc/init.d/puppetmaster restart
root@master:~# /etc/init.d/puppet restart

Se ora controlliamo nuovamente sudoers dovremmo trovare i suoi permessi originali a 440

2. I puppet
Un puppet master senza alcun puppet client non ha alcun senso di esistere, vediamo quindi come è possibile configurare un ipotetico client che ripsponda all’indirizzo puppet1 come client per il master configurato in precedenza. Il pacchetto necessario è puppet, quindi installiamolo:

root@puppet1:~# apt-get install puppet

Ed editiamo il suo file di configurazione, /etc/puppet/puppetd.conf, usando lo stesso identico contenuto già riportato in precedenza:

[puppetd]
# Make sure all log messages are sent to the right directory
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
server=master

Il client è configurato e pronto a ricevere istruzioni. Prima di poter ricevere istruzioni, però, è necessario che il master conosca il client e lo autorizzi a ricevere le istruzioni registrate. Per fare ciò cominciamo ad avviare il client:

root@puppet1:~# /etc/init.d/puppet restart

Spostiamoci sul server e controlliamo la coda di richieste:

root@master:~# puppetca --list

Dovrebbe apparire il nome del client, nel nostro esempio è puppet1, firmiamo quindi il suo certificato e abilitiamolo a ricevere le configurazioni:

root@master:~# puppetca --sign puppet1

Fine! Master e puppet sono ora configurati correttamente, facciamo un ultima prova simulando lo stesso guasto provato in precedenza sul nostro client: alterate i permessi di /etc/sudoers nel client, dopo di che riavviate il servizio:

root@puppet1:~# /etc/init.d/puppet restart

E il file sudoers verrà corretto, di nuovo

Puppet non si limita a sistemare permessi sui files ma si occupa anche di trasferire contenuti e assicurare l’installazione di pacchetti o l’esecuzione di comandi, il wiki raccoglie documentazione in quantità per creare le proprie ricette ed è un ottimo punto di partenza per ottenere più informazioni.