Per sua stessa natura, Nagios funziona generalmente in maniera “attiva”, andando ad eseguire lui stesso i check verso gli host remoti, tramite script già forniti o custom, oppure interrogando direttamente un demone NRPE presente sulla macchina remota, e che in genere esegue check locali.

Nagios, però, può essere configurato per eseguire dei check “passivi”, ovvero fare in modo che un check che giri, possa essere messo in stati particolari da programmi estetrni. Questo è quello che normalmente succede quando si lavora sull’interfaccia web e si imposta, per esempio, un Acknowledge su un servizio, o si disabilitano le notifiche.

La cosa interessante che andremo a fare in questo tutorial è un’ulteriore step. In pratica faremo in modo che non solo il server su cui gira Nagios possa ricevere delle trap SNMP, ma che Nagios stesso reagisca, in maniera predeterminata, a queste trap.

Facciamo un’esempio pratico (sarà poi quello utilizzato nel tutorial, e che è stato personalmente testato da me): un bilanciatore hardware F5 è stato configurato per lanciare delle trap verso una macchina Nagios. Questo bilanciatore invia non solo trap relative al suo stato, ma anche delle trap che indicano lo stato di un host reale bilanciato.
In pratica, quello che si otterrà è il seguente flusso di eventi:

1. L’host reale ha qualche problema, e va in down (fisicamente, o anche il solo servizio bilanciato dall’F5)
2. Il bilanciatore se ne accorge, disabilita il reale dal pool legato al VIP (Virtual IP)
3. Il bilanciatore manda una trap verso il server su cui gira Nagios, identificando che un particolare host va in down
4. Il server cattura la trap, la interpreta, ed inietta direttamente in Nagios un comando
5. Nagios mette un particolare servizio in stato CRITICO, scatenando anche le notifiche del caso

In questo caso vediamo che non ci sono latenze dovute al timeslice di check di Nagios, ma la notifica è immediata alla verifica del problema.

Prima di entrare nel vivo del tutorial, tengo a precisare non verrà trattata l’installazione e/o la configurazione di Nagios (se non per quanto riguarda le parti relative al tutorial stesso), e l’ambiente su cui è stato testato il tutto gira attualmente con questo OS/questi software:

• Debian GNU/Linux 6.0
• Nagios3 presente sui repository Debian (Nagios 3.2.1-2)

Quindi farò riferimento ai path di default di questo sistema.
Bando alle ciance, andiamo ad incominciare

Configurare il sistema per ricevere le trap SNMP

Il primo passo è quello di far si che il nostro server (sul quale già sta girando Nagios) possa ricevere delle trap SNMP.
Niente di più semplice, dovreste avere già installato il pacchetto snmpd, nel caso in cui non lo fosse, un semplice

# apt-get install snmpd

vi risolverà il problema.
Questo pacchetto contiene un demone in grado di ricevere delle trap snmp. Per configurarlo editate il file /etc/default/snmpd aggiungendo/modificando le seguenti variabili:

TRAPDRUN=yes
TRAPDOPTS='-On -u snmptt -p /var/run/snmptrapd.pid'

Facendola breve diciamo di far partire il demone per le trap (TRAPDRUN=yes) e lo facciamo lanciare con le seguenti opzioni:

• -On     Fa si che il demone usi gli OID in formato numerico, ed evita che il traduttore debba eseguire la traduzione dal formato testuale a quello numerico
• -u snmptt     Fa girare il demone con l’utente snmptt
• -p /var/run/snmptrapd.pid     Definisce il PIDfile in cui andare a scrivere il pid del processo

Andiamo quindi a definire cosa il demone snmptrapd deve fare alla ricezione di una trap. Modifichiamo quindi il file
/etc/snmp/snmptrapd.conf inserendo le seguenti direttive alla fine:

disableAuthorization yes
traphandle default /usr/sbin/smptt

In questo caso, diciamo al demone di disattivare l’autenticazione per l’invio delle trap (per questo tutorial useremo il metodo KISS: Keep It Simple and Stupid), e diciamo al demone di prendere tutte le trap e girarle al software /usr/sbin/smptt (di cui parleremo a breve).
Aspettiamo a riavviare il demone poiché dobbiamo prima assicurarci di aver installato SNMPTT.

Configurare il traduttore di trap SNMPTT

Il traduttore è una parte fondamentale. E’ quel software che si occupa, una volta ricevuta la trap, di interpretarla, tradurla e scriverla da qualche parte.
La traduzione viene fatta utilizzando dei file .MIB che altro non sono che dizionari contenenti un riferimento TRAP -> MESSAGGIO.
Praticamente tutti i produttori di hardware che emettono trap SNMP forniscono i file .MIB necessari alla traduzione, e la F5 non è da meno.

Intanto installiamo il traduttore:

# apt-get install snmptt

Una volta installato, andiamo a modificare il file di configurazione /etc/snmp/snmptt.ini con i seguenti parametri:

mode = standalone          # Questo perché viene invocato da snmptrapd e non deve girare come demone
dns_enable = 0             # Evitiamo che risolva l'hostname per ogni trap che gli arriva
strip_domain = 0           # Diciamogli di non rimuovere il dominio dall'eventuale hostname
net_snmp_perl_enable = 1   # Può utilizzare il perl la traduzione
translate_value_oids = 1   # Traduce gli OID in formato testuale leggibile breve
translate_enterprise_oid_format = 1   # come sopra
translate_trap_oid_format = 1         # come sopra
translate_varname_oid_format = 1      # come sopra
log_enable = 1             # Abilita il logging delle trap
syslog_enable = 1          # Abilita il logging delle trap sul syslog
syslog_level = info        # Definisce il livello di logging per le trap su syslog

A questo punto portiamo sulla macchina i vari files .MIB relativi all’hardware che andrà a scatenare le trap e traduciamo questi file in formato comprensibile con snmptt. Nulla di più semplice:

# mkdir /etc/snmp/mibs    # In questa directory metteremo tutti i mib tradotti
# snmpttconvertmib --in=F5-BIGIP-COMMON.mib --out=F5-BIGIP-COMMON.conf
# mv F5-BIGIP-COMMON.conf /etc/snmp/mibs/

Lanciamo il comando per tutti i MIB che ci fornisce il produttore.
A questo punto, riapriamo il file di configurazione di snmptt (/etc/snmp/snmptt.ini) e terminiamo la configurazione aggiungendo/modificando alla fine:

snmptt_conf_files = <<END
/etc/snmp/snmptt.conf
/etc/snmp/mibs/F5-BIGIP-COMMON.conf
END

Riga per riga, andiamo a mettere tutti i file .conf che abbiamo generato con smpttconvertmib. A questo punto possiamo restartare il demone SNMPD (così da far partire il gestore di trap) e verificare che sia effettivamente partito:

# /etc/init.d/snmpd restart
# cat /var/run/snmptrapd.pid
7464

Perfetto, mettiamoci in tali sul file del syslog (per default il /var/log/messages) e dovremmo iniziare a veder passare le trap:

# tail -f /var/log/messages
Sep 20 11:23:40 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.29 Normal "Status Events" 192.168.0.1 - The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30 2011\".

Ottimo, riceviamo le trap, ora dobbiamo trovare il modo di dire a Nagios che questa trap ha un significato, dirgli quale, e di scatenare un evento… procediamo

Catturare le trap

Ci viene in aiuto un’ottimo tool di nome SEC. Questo tool, in maniera generale, permette di analizzare live il contenuto di un file (quindi resta in ascolto ed analizza i nuovi contenuti) e di eseguire determinate operazioni a verificarsi di particolari eventi.
Nel nostro caso, lo metteremo in ascolto sul file in cui vengono slogate le trap /var/log/messages e, con il match su di una particolare RegExp, viene lanciato uno script con determinati parametri.
SEC è uno script in perl, ma ne esiste comunque una versione pacchettizzata per debian, dunque:

# apt-get install sec

Una volta installato, andiamo a modificare il file di configurazione /etc/sec.conf, inserendo i seguenti parametri:

type=Single
ptype=RegExp
pattern=.*(Normal|INFORMATIONAL|MINOR|WARNING|SEVERE|MAJOR|CRITICAL)\ \"Status Events\"\ (\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b)\ \-\ (A service is detected (UP|DOWN)\.\ Pool\ member\ (\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b)(.*)|(.*))
desc=snmptrap received from $2
action=shellcmd /usr/lib/nagios/eventhandlers/snmptraphandling.sh $2 $1 "$3" $4 $5

In pratica viene detto a SEC di eseguire la “action” quando un testo fa match con la regular expression definita in pattern. Senza stare li a parlare di regular expression (potremmo andare avanti per giorni e giorni), se arriva una trap SNMP con il seguente testo:

Sep 20 11:23:40 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.29 Normal "Status Events" 192.168.0.1 - The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30 2011\".

otteniamo in output le seguenti variabili:

$1 = Normal
$2 = 192.168.0.1
$3 = The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30
$4 =
$5 =

Come vediamo le ultime due variabili sono vuote. Nel caso, invece, ci arrivi una trap formata in quest’altra maniera (che indica lo stato UP/DOWN di un server fisico controllato dal bilanciatore):

Sep 20 11:47:33 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.10 Normal "Status Events" 192.168.0.1 - A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100 18009

otteniamo, invece, in output le seguenti variabili:

$1 = Normal
$2 = 192.168.0.1
$3 = A service is detected DOWN. Pool member
$4 = DOWN
$5 = 192.168.0.100

In quest’altro caso le ultime due variabili sono valorizzate ed identificano, rispettivamente, lo stato del reale (UP o DOWN) ed il reale in question (192.168.0.100).

Ovviamente, questa RegExp è stata costruita in funzione di come SNMPTT, con i MIB forniti da F5, traduce le trap. Hardware differente, con MIB differenti, tradurranno le trap in maniera differente, e sarà quindi necessario andare a trovare una RegExp funzionante per quella casistica.

Ne approfitto per segnalare il link http://gskinner.com/RegExr/ veramente molto comodo per scrivere e testare le RegExp.

Quindi, abbiamo intercettato le trap con SEC, ed eseguiamo questo script /usr/lib/nagios/eventhandlers/snmptraphandling.sh passandogli le 5 variabili ottenute dalla RegExp, siano esse valorizzate o meno. Ma cosa fa questo script?

snmptraphandling.sh

Ho scritto personalmente questo script, basandomi su un’idea di Francois Meehan, autore di uno script python simile ma meno specializzato.

Potete scaricarlo da qui: snmptraphandling.zip

Questa versione in bash accetta in ingresso le seguenti variabili (nel seguente ordine):

HOST: Obbligatoria, identifica l’host che ha inviato la trap
SEVERITY: Obbligatoria, identifica il “peso” della trap (Normal, critical, etc.) così come viene definita da F5
“DATA”: Obbligatoria dentro i doppi apici. Contiene un testo che identifica meglio la trap, una descrizione
UP|DOWN: Opzionale, identifica lo stato di un reale
ALARMEDHOST: Opzionale, identifica l’host al quale viene applicata la variabile precedente.

Intanto lo script definisce, a seconda della SEVERITY, che valori applicare al Nagios.
Inoltre, nel caso vengano specificate anche le ultime due variabili, esegue operazioni differenti per scatenare allarmi specifici.

Ma come dialoga con Nagios? Semplicissimo, costruisce un comando ad-hoc interpretabile da Nagios, e lo inetta nel file

/var/lib/nagios3/rw/nagios.cmd

Questo file è specializzato per inviare segnali a Nagios e fargli eseguire operazioni particolari.

In pratica, all’arrivo di una trap viene scatenato un evento indirizzato all’host $HOST, per un servizio chiamato:

snmp_trap_handling_$HOST-…. Nel caso in cui non siano specificate le ultime 2 variabili
snmp_trap_handling_$ALARMED_HOST Nel caso in cui siano specificate le ultime 2 variabili.

Ma prendiamo in mano un’esempio completo, così da essere più chiari.
Ci arriva dal bilanciatore, per esempio, una trap SNMP che ci identifica che un’host è andato giù; all’interno del file
/var/log/messages verrà scritto (da SNMPTT) il seguente messaggio:

Sep 20 11:47:33 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.10 Normal "Status Events" 192.168.0.1 - A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100 18009

SEC vedrà che questo testo fa match con la RegExp che gli abbiamo applicato, e lancerà questo comando:

/usr/lib/nagios/eventhandlers/snmptraphandling.sh 192.168.0.1 Normal \
"A service is detected DOWN. Pool member" DOWN 192.168.0.100

Lo script prenderà questi valori, li andrà ad elaborare (per esempio, cercando nelle configurazioni di nagios, andrà a tradurre 192.168.0.1 con bil-f5, che altro non è che il nome dell’host specificato in nagios) ed inietterà il seguente testo nel file
/var/lib/nagios3/rw/nagios.cmd:

[1316513822] PROCESS_SERVICE_CHECK_RESULT;bil-f5;snmp_trap_handling_192.168.0.100;2;A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100

Questo testo fa si che il servizio “snmp_trap_handling_192.168.0.100″ venga applicato lo stato 2, ovvero il CRITICAL per Nagios.

Configurare Nagios

Per configurare il Nagios, andremo a creare 3 strutture nuove: la prima è un servizio template che funziona in passivo e che viene usato per creare qualsiasi servizio relativo alle trap snmp; la seconda è l’host che identifica il bilanciatore; la terza è il servizio vero e proprio che verrà messo in critical o meno all’arrivo della trap.
Quindi:

define service {
name generic-snmptrap
active_checks_enabled 1
passive_checks_enabled 1 ; Passive service checks are enabled
is_volatile 1
initial_state o
check_period never
notification_interval 120
notification_options w,u,c,r
notification_period 24x7
check_command return-ok
max_check_attempts 1
check_freshness 0
stalking_options o,w,u,c
register 0 ; Not register. Its just a template
}

Notiamo alcune configurazioni particolari:

passive_checks_enabled 1 Determina che il servizio risponde a check passivi

active_checks_enabled 1 Attiva anche i check attivi. Questo è stato fatto solo perché personalmente trovo che
Nagios debba sempre mostrare uno stato completamente verde. Disattivando i
check attivi, nel TacticalOverview di Nagios avremmo un host segnalato in rosso.

check_period never Non vengono mai schedati check per questo servizio (questo perché il servizio
risponde a delle trap e non esegue direttamente i check)

check_command return-ok Attivando i check attivi, è necessario definite un check_command. Ho usato
return-ok che è un check standard di Nagios che ritorna sempre un stato OK

stalking_options o,w,u,c Questo serve per evitare che mille trap dello stesso tipo vadano a saturare il
Nagios

A questo punto definiamo l’host:

define host{
use generic-host
host_name bil-f5
alias bil-f5
address 192.168.0.1
}

ed infine il servizio:

define service{
use generic-snmptrap
host_name bil-f5
service_description snmp_trap_handling_192.168.0.100
}

Vediamo quindi che, il match che esegue il Nagios, è sulla descrizione del servizio.

Conclusioni

Abbiamo infine visto il giro del fumo. Sembrano tante parole ed il tutto molto complicato, ma vi assicuro che, una volta implementato, va tutto liscio come l’olio.

Buon lavoro

Chi usa openLDAP si sara’ accorto che dalla versione 2.4 la configurazione e’ stata completamente stravolta passando dall’avere tutto in un unico file di configurazione, slapd.conf, ad una struttura ad albero tipica del database ldap.
Di seguito sono riportati i passi per configurare un consumer/proxy utilizzando il nuovo formato di configurazione cn=config.

Topologia.

Il sistema descritto in questo articolo consta di 3 server ldap, due di questi si trovano in rete di tipo trust (quindi affidabile) ed uno in dmz (ossia una rete demilitarizzata, che non contiene cioè dati sensibili).

Tali macchine verranno nominate server1, server2 e server3:

• server1 sarà il master, che, usando la nuova terminologia di openldap, diventa provider;
• server2 sarà il consumer, colui cioè che chiede aggiornamenti al provider e funzionerà da proxy, comunicando gli aggiornamenti al server3 che risiede in dmz;
• server3 risiederà in dmz;

Perché utilizzare un proxy? Per simulare il comportamento del vecchio slurpd, la componente che garantiva la replica del database ldap mediante una connessione dal provider al consumer. Il sistema di replica e’ cambiato, ora e’ il consumer che inizia la connessione col provider per avere gli aggiornamenti.
Finché i server stanno nella stessa rete non esiste nessun problema, ma se un server risiede in dmz e uno è nella rete trust non e’ opportuno aprire un passaggio tra le due reti, si dovrà quindi simulare il comportamento del vecchio slurpd e cioè sarà il consumer/proxy ad iniziare la connessione col server in dmz. Il traffico sarà quindi dalla rete trust alla rete dmz, come e’ gusto che sia, e non dalla rete dmz alla rete trust.

server1 e server3 montano una distribuzione Debian Lenny quindi la configurazione di slapd non è cambiata, mentre nel server2 invece è stato effettuato un aggiornamento da Debian Lenny a Debian Squeeze, che ha quindi implicato l’aggiornamento all’ultima versione del pacchetto openldap, che ha imposto il riadattamento della vecchia configurazione nel nuovo formato.

Opzionale: importare gli schema.

Se, oltre agli schema già inclusi di default, si volessero includere degli altri schema, come ad esempio phamm.schema bisognerà operare come segue:

• All’interno della directory /etc/ldap/schema sarà necessario creare un file, ad esempio schema_convert.conf ed inserire le seguenti righe:

  include core.schema
  include cosine.schema
  include inetorgperson.schema
  include phamm.schema

• Creare una directory di appoggio, ad esempio ldif_out, ed utilizzare il comando slaptest per popolare la directory:

  # mkdir ldif_out
  # slaptest -f  schema_convert.conf -F ldif_out.

• All’interno della directory ldif_out/cn=config/cn=schema modificare il file cn={x}phamm.ldif (al posto di x ci sarà un numero) eseguendo le seguenti modifiche:

  dn: cn={x}phamm

  verrà modificato in:

  dn: cn=phamm,cn=schema,cn=config, cn={x}phamm diventa cn=phamm

  infine, le ultime righe del file andranno cancellate:

  structuralObjectClass: olcSchemaConfig
  entryUUID: dded7120-64a0-102f-86a3-0507262554d4
  creatorsName: cn=config
  createTimestamp: 20101005074946Z
  entryCSN: 20101005074946.106061Z#000000#000#000000
  modifiersName: cn=config
  modifyTimestamp: 20101005074946Z

  Salvando quindi il file.

A questo punto sarà necessario lanciare il comando ldapadd:

# ldapadd -Y EXTERNAL -H ldapi:/// -f ldif_out/cn\=config/cn\=schema/cn\=\{x\}phamm.ldif

In modo da importare definitivamente lo schema.

Configurazione consumer per la replica:

Per configurare il server2 (consumer) sarà necessario creare un file nominato, ad esempio, syncpreplDbHdb.ldif all’interno della directory /etc/slapd.d con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001 provider=ldap://server1:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxx” keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"

Come si può notare è stata utilizzata un’utenza ad hoc per la replica: cn=replicant,dc=example,dc=com. Attraverso il comando slapadd, sarà possibile includere la nuova configurazione all’interno del database ldap:

ldapadd -Y external -H ldapi:/// -f syncreplDbHdb.ldif.

La configurazione prosegue con l’aggiunta dei moduli necessari alla replica e la creazione degli indici.

Per aggiungere i moduli syncprov.la e back_ldap.la, necessari alla replica, basterà creare un file nominato, ad esempio, modules.ldif il cui contenuto dovrà essere:

n.b. il modulo back_ldap e’ necessario solo al consumer che opera anche come proxy.

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
-
add: olcModuleLoad
olcModuleLoad: back_ldap.la

Aggiungendo, come già fatto, il file ldif attraverso il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f modules.ldif.

L’aggiunta degli indici prevede la creazione di un file nominato, ad esempio, indexes.ldif con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq

per poi lanciare, come di consueto, il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f indexes.ldif.

Overlay syncprov (sync provider)

Gli overlay sono componenti software che servono per aggiungere funzionalità al database senza che sia necessario riscrivere un nuovo backend per gestirle, è possibile pensarlo come ad una sorta di plugin.

L’overlay syncprov deve essere definito per ogni macchina che funge da provider, siccome il consumer definito nell’articolo e’ anche il provider di se stesso, in quanto comunica gli aggiornamenti al database ldap che e’ il proxy (definito sotto), è necessario definire l’overlay synprov anche per il consumer.

Creare un file, ad esempio overlayDbHdb.ldif, con il seguente contenuto:

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

come ormai chiaro, sarà necessario lanciare nuovamente il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f overlayDbHdb.ldif

Aggiunta del database ldap:

Per completare la configurazione sarà necessario aggiungere il database ldap. Il database ldap serve per fare in modo che il server agisca da proxy ed effettui il forward delle richieste ad un altro server ldap, in questo caso verso server3 in dmz.

Il database ldap verrà creato come di consueto attraverso un file nominato databaseLdap.ldif con il seguente contenuto:

dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcHidden: TRUE
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRestrict: bind
olcRestrict: add
olcRestrict: modify
olcRestrict: rename
olcRestrict: delete
olcRestrict: search
olcRestrict: compare
olcRestrict: extended
olcRootDN: cn=admin,dc=example,dc=com
olcSyncrepl: rid=002 provider=ldap://localhost:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"
olcDbURI: "ldap://server3:389"
olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0

ed importato quindi con ldapadd:

# ldapadd -Y external -H ldapi:/// -f databaseLdap.ldif

Infine sarà necessario aggiungere l’overlay syncprov anche al database ldap, creando un file overlayDbLdap.ldif:

dn: olcOverlay=syncprov,olcDatabase={2}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

eseguendo nuovamente il comando ldapadd:

# ldapadd -Y EXTERNAL -H ldapi:/// -f overlayDbLdap.ldif

Si completa così la configurazione di un consumer/proxy.

Conclusioni

Sulla base delle informazioni di questo articolo è possibile ricavare in autonomia la procedura per aggiornare anche il provider ed il server in dmz.
Nei successivi articoli verranno illustrate le configurazione complete degli altri server, in modo da completare l’argomento dell’upgrade di openldap.

Debian e le distribuzioni da lei derivate, utilizzano l’accoppiata apt-get e dpkg per installare e mantenere aggiornati i programmi. Mentre dpkg si preoccupa di lavorare esclusivamente in locale, scompattanto i pacchetti ed assicurandosi che la loro installazione sia portata a buon fine, è apt-get il vero cavallo da lavoro: si preoccupa di mantenere aggiornati gli indici per il reperimento dei pacchetti, calcola e risolve le dipendenze al momento dell’installazione di un nuovo programma e si preoccupa di scaricare il deb dai repository remoti.
Quest’ultima azione, il download, può incidere notevolmente sulle performance della rete, specialmente se si è scelto di installare diversi pacchetti (si pensi agli effetti di un apt-get install ubuntu-desktop sopra un Ubuntu base system) e se questa operazione viene effettuata da più di un computer della stessa rete.

Una prima soluzione potrebbe essere quella di tenere un repository locale e scaricare i pacchetti necessari da quel repository, sfortunamente questa soluzione richiede un notevole consumo di spazio ed ogni giorno è necessario scaricare gli aggiornamenti al repository anche se alcuni o tutti dei programmi scaricati non sono necessari.
Per ovviare a questi effetti entrano in gioco i proxy apt: risolvono il problema di consumo di banda tenendo nella cache locale i pacchetti richiesti e sono meglio della presenza di un repository personale in quanto non si devono sprecare spazio e banda per avere tutti i pacchetti salvati nella cache in ogni momento.
La soluzione più semplice per installare un proxy apt è quella di eleggere, se già presente, il proxy della rete a fare anche da proxy per i deb scaricati: da un lato si ha un immediato vantaggio di configurazione, con poche righe uno squid è in grado di tenere in cache pure i pacchetti dei programmi, dall’altro si hanno delle limitazioni sulla flessibilità di configurazione e sui protocolli supportati per il download dai repository.
Per superare anche queste limitazioni è sufficiente utilizzare un programma dedicato al caching dei deb, quello storico è apt-proxy seguito, in ordine cronologico, da approx, apt-cacher e apt-cacher-ng. In questo articolo parleremo dell’utilizzo di approx perchè è il più vecchio proxy apt funzionante, in quanto il povero apt-proxy mostra i segni dell’età non risultando affatto scalabile su larga scala.
Il comportamento dei proxy apt è molto semplice: vengono configurati per fornire la cache di alcuni repository, quando un client li contatta e richiede un pacchetto, i proxy controllano la presenza del pacchetto nella loro cache, se questo manca verrà scaricato dal repository e passato al client altrimenti verrà servita la copia locale, risultando così estremamente veloce e risparmiando un download extra inutile. L’installazione di approx è immediata:

root@proxy:~# apt-get install approx

una volta finito il processo, si deve editare il file /etc/default/approx solamente nel caso sia necessario fornire al nostro proxy apt… un proxy per uscire! Per esempio:

# Default settings for approx, included by the /etc/init.d/approx shell script
 
# Uncomment and edit this definition to have approx use a proxy server
export http_proxy=il-mio-proxy:porta

A questo punto si può procedere alla vera configurazione di approx, il file /etc/approx/approx.conf:

# Here are some examples of remote repository mappings.
# See http://www.debian.org/mirror/list for mirror sites.
 
debian          http://mi.mirror.garr.it/mirrors/debian
security        http://security.debian.org/debian-security
volatile        http://volatile.debian.org/debian-volatile
 
# The following are the default parameter values, so there is
# no need to uncomment them unless you want a different value.
# See approx.conf(5) for details.
 
#$interface      any
$port          80
#$max_wait      10
#$max_rate      unlimited
#$user          approx
#$group         approx
#$syslog         daemon
#$pdiffs        true
#$verbose        false
#$debug         false

La prima sezione specifica a quale nome faranno riferimento i repository proxati, la sintassi è molto semplice:

nome_repo      url_repo

così facendo, all’indirizzo http://proxy/nome_repo risponderà la cache di url_repo o, come accade nella prima riga del nostro file di configurazione, http://proxy/debian/ è una cache per http://mi.mirror.garr.it/mirrors/debian.
A questo punto basta modificare il /etc/apt/sources.list delle macchine della propria rete e del proxy stesso, utilizzando i nuovi url:

http://proxy/debian/   lenny main contrib non-free
http://proxy/security/   lenny/updates main contrib non-free
http://proxy/volatile/   lenny/volatile main contrib non-free

La seconda sezione, invece, si occupa della gestione delle opzioni di configurazione del comportamento di approx stesso, nel nostro esempio abbiamo configurato come porta di ascolto la 80, al contrario del default storico di apt-proxy: la 9999. Se non avessimo cambiato la configurazione, il proxy avrebbe comunque funzionato ma nei client si doveva configurare esplicitamente la porta di ascolto del server usando, per esempio, una riga come http://proxy:9999/debian/ lenny main contrib non-free.
Il proxy è ora in piedi, sta venendo utilizzato dai client e possiamo anche dimenticarci della sua presenza! Se però vogliamo provare a verificare manualmente il suo comportamento, approx ci fornisce due ulteriori programmi che vengono usati esclusivamente da cron per mantenere in forma il proxy ma che il sistemista curioso può provare a lanciare manualmente.
Il primo programma è update_approx che viene schedulato come giornaliero al momento dell’installazione, questo programma si preoccupa di aggiornare la lista e le versioni dei programmi reperibili dai repository remoti.
Il secondo è gc_approx, il garbage collector: come dice il nome, questo programma si preoccupa di tenere pulita la cache di approx, eliminando i pacchetti superfli e non più disponibili dai repository remoti. Al momento dell’installazione questo programma viene schedulato come settimanale.
Credo che valga veramente la pena installare approx o un altro proxy apt: il risparmio di banda è notevole già da quando si utilizzano solo due macchine e la vostra connessione vi ringrazierà

Sulla scia del precedente articolo di Raoul Scarazzini “RPM: Panoramica ed opzioni particolari”, ho deciso di ampliare il discorso e proporre qui una panoramica di DPKG, il package manager nato e progettato per Debian e usato da tutte le sue derivate (Ubuntu, Mepis, Knoppix e tante altre).

Stati dei pacchetti

Prima di addentrarci nella spiegazione delle numerose opzioni di dpkg, è necessario introdurre il concetto di “stato” di un pacchetto.

Su Debian, non ci si limita ad avere i classici due stati per un pacchetto “non installato” ed “installato”, sarebbe troppo semplice e semplicistico!

La necessità di avere diversi stati è data dal fatto che l’installazione di un pacchetto non può essere un’operazione atomica (cioè che viene eseguita tutta), ma si compone di varie fasi, dalla decompressione del pacchetto deb (che è un file compresso in formato ‘ar’) fino al lancio degli script contenuti nel pacchetto necessari alla corretta installazione.

Di seguito l’elenco dei possibili stati con una loro spiegazione sommaria:

• not-installed: il più semplice, lo stato di un pacchetto che non è ancora stato installato…
• half-installed: l’installazione del pacchetto è iniziata ma per qualche motivo non è stata completata (errori vari oppure interruzione del processo da parte dell’utente)
• unpacked: il pacchetto è stato correttamente decompresso e i suoi file sono stati posizionati nelle varie directory di destinazione, ma la configurazione del pacchetto non è ancora avvenuta
• half-configured: il pacchetto ha già raggiunto lo stato di “unpacked”, ed è iniziata la fase di configurazione che non è giunta a termine (anche in questo caso per colpa di errori vari o a causa dell’interruzione da parte dell’utente)
• triggers-awaited: il pacchetto è installato e configurato, ma sta attendendo l’esecuzione dei ‘trigger’ di un altro pacchetto. I ‘Trigger’ di dpkg sono un modo per posticipare l’esecuzione di alcune operazioni comuni, pensate ad esempio al lancio del comando ‘ldconfig’, che deve essere lanciato dopo l’installazione di un pacchetto che contiene librerie… Un trigger su ldconfig è utile, nel caso di installazione di molti pacchetti, per eseguire l’operazione solo una volta al termine dell’installazione di tutti i pacchetti, anzichè lanciare ldconfig al termine dell’installazione di ogni pacchetto… il risparmio di tempo e di risorse è notevole!
• trigger-pending: i trigger del pacchetto sono in fase di esecuzione
• installed: il pacchetto è stato decompresso, configurato e ‘triggerato’, è finalmente disponibile per il sistema.

Oltre agli stati dei pacchetti bisogna distinguere anche lo ‘Stato di selezione dei pacchetti’ e le ‘Flag dei pacchetti’;

Stato di Selezione Dei Pacchetti

Dpkg lavora su collezioni di pacchetti, e ne processa uno alla volta, lo ‘seleziona’ appunto. Ogni pacchetto che deve venire processato ha uno stato target, al termine del lavoro di dpkg si spera che il pacchetto possa essere lasciato nello stato desiderato. Gli stati di selezione dei pacchetti sono tre:

• install: il pacchetto è stato selezionato per essere installato, al termine dell’operazione il suo stato sarà “installed”
• deinstall: il pacchetto è stato selezionato per essere rimosso dal sistema, verranno rimossi tutti i suoi files tranne i file di configurazione posti in /etc
• purge: il pacchetto è stato selezionato per la rimozione completa dal sistema, verranno rimossi anche i file di configurazione posti in /etc

Flag dei pacchetti

Una volta che un pacchetto risulta in stato ‘installed‘può avere due flags, che contraddistinguono in maniera più particolare ciò che dpkg deve fare con lui:

• hold: il pacchetto è installato, ma non viene più gestito da dpkg, deve rimanere così com’è. L’unica maniera per far eseguire a dpkg operazioni su quel pacchetto è usare l’opzione –force-hold
• reinst-required: il pacchetto è rovinato (sono stati cancellati dei file oppure la rimozione non è andata a buon fine) e deve per tanto essere reinstallato. I pacchetti con questa flag non possono essere rimossi senza specificare l’opzione –force-remove-reinstreq

Operazioni comuni con i pacchetti DEB

E siamo finalmente arrivati alle operazioni più comuni che si fanno con dpkg…

Interrogazioni sul database di DPKG

Per ottenere la lista di tutti i pacchetti (in qualsiasi stato) presenti sul sistema è sufficiente lanciare dpkg passando l’opzione ‘-l’, che produrrà un output simile al seguente

$ dpkg -l
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  adduser        3.110          add and remove users and groups
ii  aircrack-ng    1:1.0~rc1-2    wireless WEP/WPA cracking utilities
ii  akregator      4:3.5.9-5      RSS feed aggregator for KDE
ii  alsa-base      1.0.17.dfsg-4  ALSA driver configuration files
ii  alsa-tools     1.0.16-2       Console based ALSA utilities for specific ha
ii  alsa-utils     1.0.16-2       ALSA utilities
...
ii  zlib1g         1:1.2.3.3.dfsg compression library - runtime
ii  zlib1g-dev     1:1.2.3.3.dfsg compression library - development
ii  zsh            4.3.9-1        A shell with lots of features

A parte l’intestazione iniziale che serve giusto a ricordare gli stati possibili per i pacchetti, la parte interessante è l’elenco, andiamo ad analizzare la struttura dell’output:

La prima colonna mostra appunto lo stato dei pacchetti, ‘ii’ identifica appunto i pacchetti installati, è lo stato più comune nell’output di dpkg.

Un altro stato che è facile incontrare è lo stato ‘rc’, che identifica i pacchetti che sono stati disinstallati, tali pacchetti non sono più presenti sul sistema, ma vengono mantenuti tutti i file di configurazione.

Quello che identifichiamo come ‘prima colonna’ identifica in realtà due dati, il primo è lo stato desiderato, cioè cosa è stato chiesto dall’utente ed è il primo carattere, il secondo è lo stato effettivo del pacchetto sul sistema.

Ad esempio quando un pacchetto è marcato come ‘ii‘, significa che l’installazione è stata richiesta dall’utente e che esso è effettivamente installato, mentre un pacchetto ‘rc‘ è stato rimosso, ma sono rimasti i file di configurazione (cioè non è stata richiesta un’operazione di ‘purge’).

La seconda colonna invece indica il nome del pacchetto, la terza la versione di tale pacchetto e l’ultima la descrizione breve associata ad ogni pacchetto.

Per ottenere invece, la lista dei pacchetti installati possiamo usare il seguente comando:

$ dpkg --get-selections | awk '/tinstall$/

La lista generata dall’opzione –get-selections è comoda anche per replicare un sistema su un’altro, l’operazione è abbastanza semplice:

Sul sistema sorgente:

$ dpkg --get-selections > package_list
scp package_list user@target:

Sul sistema di destinazione:

$ dpkg --set-selection< package_list
apt-get dselect-upgrade

In questo modo, apt (il principale frontend a dpkg, che si occupa di scaricare e risolvere le dipendenze dei vari pacchetti) andrà a cercare la lista di pacchetti da scaricare non sullo standard input ma direttamente sul database di dpkg.

Per ottenere informazioni su un pacchetto installato è disponibile l’opzione -p:

$ dpkg -p coreutils
Package: coreutils
Essential: yes
Priority: required
Section: utils
Installed-Size: 10368
Maintainer: Michael Stone <mstone@debian.org>
Architecture: powerpc
Version: 6.10-6
Replaces: debianutils (<= 2.3.1), dpkg (<< 1.13.2), fileutils, shellutils, stat, textutils
Provides: fileutils, shellutils, textutils
Pre-Depends: libacl1 (>= 2.2.11-1), libc6 (>= 2.7-1), libselinux1 (>= 2.0.59)
Conflicts: stat
Size: 3649670
Description: The GNU core utilities
 This package contains the essential basic system utilities.
 .
 Specifically, this package includes:
 basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir
 dircolors dirname du echo env expand expr factor false fmt fold groups head
 hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mv nice nl
 nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir
 sha1sum seq shred sleep sort split stat stty sum sync tac tail tee test touch
 tr true tsort tty uname unexpand uniq unlink users vdir wc who whoami yes

Per ottenere invece la lista dei files contenuti all’interno di un pacchetto installato è possibile usare l’opzione -L:

$ dpkg -L coreutils
/.
/bin
/bin/cat
/bin/chgrp
/bin/chmod
/bin/chown
/bin/cp
/bin/date
...
/usr/share/locale/vi/LC_TIME/coreutils.mo
/usr/share/locale/zh_CN/LC_TIME/coreutils.mo
/usr/share/locale/zh_TW/LC_TIME/coreutils.mo
/usr/bin/touch
/usr/bin/md5sum.textutils

Nel caso invece si disponga di un pacchetto deb non installato è possibile usare l’opzione -c:

$ dpkg -c /var/cache/apt/archive/coreutils_6.10-6_powerpc.deb
drwxr-xr-x root/root         0 2008-04-04 17:08 ./
drwxr-xr-x root/root         0 2008-04-04 17:08 ./bin/
-rwxr-xr-x root/root     20780 2008-04-04 17:08 ./bin/cat
-rwxr-xr-x root/root     44992 2008-04-04 17:08 ./bin/chgrp
-rwxr-xr-x root/root     40596 2008-04-04 17:08 ./bin/chmod
-rwxr-xr-x root/root     47060 2008-04-04 17:08 ./bin/chown
...
lrwxr-xr-x root/root         0 2008-04-04 17:08 ./usr/share/locale/vi/LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo
lrwxr-xr-x root/root         0 2008-04-04 17:08 ./usr/share/locale/zh_CN/LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo
lrwxr-xr-x root/root         0 2008-04-04 17:08 ./usr/share/locale/zh_TW/LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo
lrwxr-xr-x root/root         0 2008-04-04 17:08 ./usr/bin/touch -> /bin/touch
lrwxr-xr-x root/root         0 2008-04-04 17:08 ./usr/bin/md5sum.textutils -> md5sum

Installazione e aggiornamento di un pacchetto

Per l’installazione di un pacchetto scaricato localmente è possibile utilizzare l’opzione -i (o –install):

$ dpkg -i /var/cache/apt/archives/coreutils_6.10-6_powerpc.deb
(Reading database ... 259576 files and directories currently installed.)
Preparing to replace coreutils 6.10-6 (using .../coreutils_6.10-6_powerpc.deb) ...
Unpacking replacement coreutils ...
Setting up coreutils (6.10-6) ...
Processing triggers for man-db ...

Nel caso di aggiornamento di un pacchetto precedentemente installato, dpkg si occuperà da solo di rimuovere la versione più vecchia e sovrascriverla con la nuova versione (o con la stessa versione nel caso di una reinstallazione, come nel caso precedente).

Nel caso si vogliano installare ricorsivamente i pacchetti contenuti in una struttura di directory è possibile usare l’opzione -R ( o –recursive) passando come parametro il path di tale directory, in questo modo dpkg eseguirà l’operazione ricorsivamente su tutti i file contenuti all’interno della dir:

dpkg -Ri /var/cache/apt/archives

Rimozione di un pacchetto

Dpkg mette a disposizione due metodi per rimuovere i pacchetti: la semplice rimozione che rimuove tutti i file del pacchetto tranne che la configurazione nelle directory di sistema (quindi in /etc) e il ‘purge‘ del pacchetto, che elimina qualsiasi traccia del pacchetto, compresi i file di configurazione globali. Ovviamente tutti i file creati dalle varie applicazioni nelle home directory di utenti non verranno toccati.

Per rimuovere semplicemente un pacchetto bisogna usare l’opzione -r (o –remove):

dpkg -r alsa-utils

Per purgare un pacchetto invece si utilizza l’opzione -P (o –purge):

dpkg -P alsa-utils

Risoluzione delle dipendenze

Dpkg non è mai stato progettato per risolvere in autonomia le dipendenze, l’unica cosa che è in grado di fare è verificare se esse sono soddisfatte, mentre la risoluzione è affidata a tool di più alto livello come Apt o Aptitude. Questi tool oltre a risolvere le dipendenze si occupano anche di scaricare i file dai repository ufficiali di Debian (o della distribuzione derivata, come Ubuntu).

Apt fornisce un wrapper per quasi tutte le opzioni di dpkg, le più comuni sono comunque quelle di ricerca, installazione e rimozione:

$ apt-get install coreutils  #installa il pacchetto specificato
$ apt-get instal --reinstall coreutils  #reinstalla il pacchetto specificato
 
$ apt-get remove coreutils  #rimuove il pacchetto specificato
$ apt-get remove --purge coreutils  #rimuove il pacchetto specificato e ne effettua il purge
 
$ apt-cache search coreuti  #cerca tutti i pacchetti il cui nome è simile a 'coreuti'
$ apt-cache show coreutils  #mostra le informazioni relative al pacchetto coreutils

Estrazione di un pacchetto

Con dpkg è anche possibile estrarre un pacchetto senza installarlo, giusto a scopo di analisi, si deve usare l’opzione -x (o –extract):

$ dpkg -x /var/cache/apt/archives/coreutils_6.10-6_powerpc.deb directory_target

All’interno di ‘directory_target’ sarà presente tutta la struttura del pacchetto deb.

È anche possibile estrarre un singolo file dal pacchetto utilizzando l’opzione –fsys-tarfile, che fa produrre a dpkg l’output sotto forma di tarfile, una volta ottenuto quel file è possibile estrarre tutto grazie al comando tar:

$ dpkg --fsys-tarfile /var/cache/apt/archives/coreutils_6.10-6_powerpc.deb | tar -tvf -

Conclusioni

Ciò che è stato illustrato in questa panoramica corrisponde solo alla punta dell’iceberg delle potenzialità di dpkg, che tra le varie cose è anche in grado di creare da solo pacchetti .deb (a differenza di rpm che si appoggia a tool come rpmbuild). Per una lista completa ed esauriente di tutte le opzioni e le possibilità offerte da dpkg consiglio la lettura del fine manual di dpkg.

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.