Abbiamo già visto, nel precedente articolo, come sia possibile installare puppet su EL/Centos. Quindi supponiamo che il server (puppetmaster) e i client siano correttamente configurati e visibili fra loro.

Vediamo ora più nel dettaglio come possiamo configurare i nostri server singolarmente attraverso puppet.

Nel file site.pp, gà descritto in precedenza, possiamo descrivere la nostra farm di server e dettagliare le configurazioni da inviare ad ogni nodo (server della farm).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

node default {
    include sudo
    include ssh
}
 
node 'web.extraordy.com' inherits default {
    include apache
}
 
node 'samba.extraordy.com' inherits default {
    class {'samba::server':
      workgroup => 'EXTRAORDY',
      server_string => "Samba Share Server",
      interfaces => "eth0 lo",
      security => 'share'
    }
 
    samba::server::share {'Public':
      comment => 'Public Documents',
      path => '/var/samba/public',
      guest_only => false,
      guest_ok => true,
      guest_account => "guest",
      browsable => true,
  }
}

Nel file di esempio mostrato qui sopra, creaiamo uno nodo default che usiamo per le configurazioni comuni a tutti i server (per esempio la lista di sudoers e la configurazione ssh). Nella definizione di ogni server, possiamo poi dire che il nodo che stiamo configurando eredita la configurazione da nodo default (ma non é obbligatorio farlo), e specificare poi i dettagli di configurazione del server specifico. Per esempio installare apache sul server web e samba sul server di condivisione file.

Nota: il nome del server supporta una lista o una regular expression. Es: /^(foo|bar)\.example\.com$/

Nell’esempio vengono inoltre messi in evidenza due possibili tipi di configurazione: normale inclusioni di moduli (consigliato), inclusione di classi con valorizzazione di parametri (esistono metodi migliori che vedremo in un prossimo articolo).

I moduli che includo nella configurazione di un server dovranno ovviamente esistere sul puppetmaster, installati all’interno della cartella modules.
Essendo oggi puppet un prodotto maturo, opensource e soprattutto molto usato, non é praticamente più necessario crearsi alla mano i propri moduli. Se andiamo su github/bitbucket e lanciamo una ricerca “puppet” possiamo trovare di tutto.
Nel caso pero non troviate esattamente il modulo che state cercando, vediamo la descrizione della struttura di un modulo:

custom_module — Cartella del modulo. Il nome deve corrispondere al nome della classe (init.pp)
|— manifests/ — Contiene i file .pp con le “azioni” del modulo
|— init.pp — Definizioni della classe (nome = nome cartella modulo). Il file é obbligatorio e descrive le azioni base della configurazione.
|— other_class.pp — Se necessario posso difinire altri file/classi il cui nome sarà custom_module::other_class (per facilitarne l’identificazione).

|— files/ — Lista di file statici che saranno copiati per configurare il server
|— example.conf — File di configurazione che potro installare mettendo come source puppet:///modules/custom_module/example.conf.
|— templates/ — Lista di template da installare. Un template é un file statico contenente delle variabili (esempio ‘hostname’). Che quindi configureranno differentemente il file installato in base al server sul quale verrà copiato.
|— ex_template.erb — In modulo posso usare questo template richiamandolo con template(‘custom_module/ex_template.erb’).

Vediamo per esempio il modulo sudo usato nel nodo default (https://github.com/lofic/puppet-sudo).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

class sudo {
 
    case $::osfamily {
        'Debian' : { $sudoersfile = 'sudoers.debian' }
        'RedHat' : { $sudoersfile = 'sudoers.redhat' }
        default  : { $sudoersfile = 'sudoers.debian' }
    }
 
    package { 'sudo' : ensure => present }
 
    file { '/etc/sudoers' :
        owner    => 'root',
        group    => 'root',
        mode     => '0440',
        content  => template("sudo/${sudoersfile}"),
        require  => Package[ 'sudo' ],
    }
 
    file { '/etc/sudoers.d' :
        ensure => directory,
        owner  => 'root',
        group  => 'root',
        mode   => '0755',
    }
 
    file { '/etc/sudoers.d/lofic' :
        ensure  => present,
        owner   => 'root',
        group   => 'root',
        mode    => '0440',
        source  => 'puppet:///modules/sudo/sudoers.lofic',
        require => File[ '/etc/sudoers.d' ],
    }
 
    file { '/etc/sudoers.d/bob' :
        ensure  => present,
        owner   => 'root',
        group   => 'root',
        mode    => '0440',
        source  => 'puppet:///modules/sudo/sudoers.bob',
        require => File[ '/etc/sudoers.d' ],
    }
 
}

Facendo quindi un include di questo modulo, tutte le “azioni” elencate nell’init saranno eseguite: verifica del pacchetto sudo, verifica della presenza del file /etc/sudoers con il contenuto specificato in template(“sudo/${sudoersfile}”) (che dipende dalla distribuzione linux usata), …
Questo significa che, se un utente modifica il file sudoers (contenuto, owner, mode, …) puppet rimetterà quello configurato sul puppetmaster, assicurandoci quindi un’integrità constante nella configurazione dei miei server.