Puppet: configurazione dettagliata server

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.

Info about author

Marco Mornati