Mis en place de Puppet avec Unboud

Puppet est-ce que l’on peut appeler un gestionnaire de configuration.
C’est un outil qui facilite le contrôle et la mise à jour de configurations tout en offrant la possibilité de faire abstraction de l’OS et de l’architecture concernée. Puppet va permettre de déployer des fichiers, des services, des packages, des commandes et même un cron au travers de clients qui deviendront des Serveurs (exemple : BIND, UNBOUND).

/!\ LORSQUE J’EXÉCUTE MES COMMANDES JE PRENDS EN CONSIDÉRATION QUE JE SUIS CONNECTÉ EN TANT QUE ROOT AINSI QUE SUR DES MACHINES VIRTUELLES DE TYPE DEBIAN8, PLUS COMPLIQUE AVEC DEBIAN9 /!\

0) Prérequis

Nous prenons l’exemple que notre serveur Puppet à pour hostname : puppetmaster, et nos clients portent le nom de puppetcli1, puppetcli2.
Comme nom de domaine nous prenons l’exemple de l’université de DonSalmon : univ-donsalmon.fr. .
Et les adresses IP sont donc :

HOSTNAME	ADRESSE IP
puppetmaster	10.0.99.4
puppetcli1	10.0.99.5
puppetcli2	10.0.99.6

On va aussi installer le paquet net-tools. Ce paquet contient des outils importants pour contrôler le sous-système réseau du noyau Linux. Cela inclut arp, ifconfig, netstat, rarp, nameif et route.

1) Installation de Puppet

On va commencer par ajouter le dépôt debian de Puppet puis on va installer Puppet sur les clients et Puppetmaster sur le serveur:

apt-get install puppetmaster
apt-get install puppet

Tout d’abord il faut que le fichier hosts de chaque client référence l’adresse IP, le hostname et le FQDN du serveur. Ainsi il
faut rajouter dans /etc/hosts :

nano /etc/hosts
10.0.99.4 puppetmaster puppetmaster.univ-donsalmon.fr 

De même sur le serveur, il faut rajouter les noms des 2 machines clientes de la même façon.

nano /etc/hosts
10.0.99.5 puppetcli1 puppetcli1.univ-donsalmon.fr 
10.0.99.6 puppetcli2 puppetcli2.univ-donsalmon.fr

2) Configuration de Puppet

DEMANDE DE CERTIFICAT

Serveur:

Il faut modifier ce fichier:

nano /etc/puppet/puppet.conf

Clients:

Ici il faut rajouter le FQDN (ou Hostname s’il n’y a pas de domaine) du serveur, ainsi dans ce fichier, une fois encore:

nano /etc/puppet/puppet.conf

Une fois cette modification faite, il n’y pas plus qu’à demander au serveur Puppet de signer notre certificat, car rappelons que Puppet utilise le SSL, il est donc plus sécurisé qu’un NFS.
De cette façon:

puppetcli1# puppetd --waitforcert 60 --test
ou
puppetcli1# puppet agent --waitforcert 60 --test

Le serveur va ensuite visualiser les demandes :

puppetmaster#puppetca --list
puppetmaster#puppet cert --list

Puis il va signer les demandes :

puppetmaster#puppetca --sign puppetcli1
ou
puppetmaster#puppetca --sign --all  #Pour tous d'un coup
puppetmaster#puppet cert --sign --all

Le serveur est prêt à l’emploi, et les clients ont un certificat signé.

3) Configuration de UNBOUND via PUPPET:

Afin d’utiliser Puppet un minimum, nous allons lui demander de déployer UNBOUND sur une machine cliente (puppetcli1).
Il va falloir configurer le serveur, ainsi /etc/puppet/fileserver.conf :

nano /etc/puppet/fileserver.conf

Nous venons d’autoriser seulement les machines provenant du domaine, à pouvoir recevoir des fichiers du répertoire /etc/puppet/files/.

Il faut également créer le fichier /etc/puppet/namespaceauth.conf et y rajouter :

nano /etc/puppet/namespaceauth.conf

Le daemon du client va initialement interroger le fichier /etc/puppet/manifests/site.pp du serveur, c’est pourquoi dans ce fichier nous allons importer tous les fichiers .pp (spécialement conçu pour Puppet):
/etc/puppet/manifests/site.pp :

nano /etc/puppet/manifests/site.pp

Ensuite pour éviter de déployer UNBOUND sur tous les nodes, nous allons spécifier lesquels vont recevoir la classe UNBOUND que nous créerons (dans le fichier init.pp du module Unbound). Ainsi dans le fichier /etc/puppet/manifests/node.pp :

nano /etc/puppet/manifests/node.pp

Ici nous créons un faux node (client puppet) nommé basenode en lui incluant la classe « crontab », et les nodes puppetli1 et puppetcli2 héritent de basenode (autrement dit de la classe crontab). Ensuite nous leurs attribuons la classe unbound et resolv pour puppetcli1 puis bind et resolv pour puppetcli2.

Il faut également créer le fichier /etc/puppet/manifests/modules.pp qui va référencer les modules du serveur :

nano /etc/puppet/manifests/modules.pp

On peut appeler un module, le nom d’un répertoire, en effet il est recommandé de créer des modules pour chaque service afin de rendre la configuration plus souple.
Pour finir sur la configuration de base, nous allons mettre en place un cron qui se déploiera sur les clients afin de lancer une synchronisation avec le serveur, ainsi quand le cron arrive à son échéance (15 minutes) il va permettre de checker toutes modifications du client puppet.

Donc on va créer le fichier /etc/puppet/manifests/cron.pp :

nano /etc/puppet/manifests/cron.pp

Passons à la configuration des modules :

Création des modules :

mkdir -p /etc/puppet/modules/unbound/{files,manifests,templates}
mkdir -p /etc/puppet/modules/bind/{files,manifests,templates}

Le dossier MANIFESTS permet de répertorier le fichier init.pp qui défini le coeur du module.
Le dossier FILES contient les fichiers statiques, ceux qui ne changent pas d’un node à l’autre.
Le dossier TEMPLATES contient les fichiers de configurations variant d’un hôte à l’autre.

Maintenant que les modules sont crées, nous plaçons le fichier de configuration d’Unbound que voici, /etc/puppet/modules/unbound/files/unbound.conf :

Ici nous faisons la résolution du domaine : univ-perp.fr avec pour serveur DNS : puppetcli1

### Simple recursive caching DNS
## /etc/unbound.conf
#
server:
verbosity: 1
outgoing-range: 60
interface: 10.0.99.5
do-ip4: yes
do-udp: yes
do-tcp: yes
access-control: 10.0.99.0/24 allow #On autorise le réseau 10.0.99.0/24 à interroger le DNS
chroot: "" #Pas de chroot par défaut
logfile: "/var/log/unbound.log" #On défini le fichier de log
use-syslog: no #Log par défaut dans syslog
hide-identity: yes
hide-version: yes
harden-glue: yes #On dit que le serveur fait autorité sur la zone
private-domain: "univ-donsalmon.fr." #On définit le suffix dns du réseau local
local-zone: "univ-donsalmon.fr." static #on définit qui s'occupe de quoi dans le
domaine
local-data: "univ-donsalmon.fr. IN MX 10 puppetcli2.univ-donsalmon.fr." #service de messagerie
local-data: "univ-donsalmon.fr. IN NS puppetcli1.univ-donsalmon.fr." #service DNS
local-data: "puppetmaster.univ-donsalmon.fr. IN A 10.0.99.4" #résolution : nom -> adresse
local-data: "puppetcli1.univ-donsalmon.fr. IN A 10.0.99.5"
local-data: "puppetcli2.univ-donsalmon.fr. IN A 10.0.99.6"
local-data-ptr: "10.0.99.4 puppetmaster.univ-donsalmon.fr." #résolution inverse : adresse -> nom
local-data-ptr: "10.0.99.5 puppetcli1.univ-donsalmon.fr."
local-data-ptr: "10.0.99.6 puppetcli2.univ-donsalmon.fr."
python:
remote-control:
forward-zone:
name: "."
forward-addr: 10.0.255.254 # DNS de la Box

Passons à la configuration du fichier principal, nano /etc/puppet/modules/unbound/manifests/init.pp :

class unbound {
        package { unbound: ensure => installed }
        file { "/etc/unbound/unbound.conf":
                notify => Service["unbound"],
                mode => 644,
                owner => "root",
                group => "root",
                source => "puppet:///modules/unbound/unbound.conf"
                }
        service { unbound: ensure => running,
                        enable => true
        }       }
class resolv {
        file { "/etc/resolv.conf":
                ensure => present,
                content => "domain univ-donsalmon.fr
search univ-donsalmon.fr
nameserver $ipaddress"
        }
}

Pour la classe « unbound », nous venons de lui permettre d’installer le paquet UNBOUND, de lui déployer le fichier de configuration sur /etc/unbound/unbound.conf afin de remplacer l’existant et ensuite nous lui avons forçer le démarrage du daemon UNBOUND. Lors du déploiement d’un fichier, dans le paramètre SOURCE, remarquons qu’il n’est pas nécessaire de référencer le répertoire « files » dans le module, grâce au protocole qui est défini ici : puppet:///
Quant à la classe « resolv » est de type TEMPLATES, c’est à dire qu’elle est dynamique, elle s’adapte à l’hôte grâce à son adresse IP qui est remonté grâce aux facts (outils facter qui est compréhensible par PUPPET). En effet Facter est un outil associé à puppet, chargé d’énumérer les paramètres locaux d’un système :
– Adresse IP
– Hostname
– Distribution et version
– Toutes autres variables locales définies par l’utilisateur.
Il est disponible sur les noeuds utilisant Puppetd, il fournit des variables utilisables dans les templates puppet.

4) Configuration du module BIND:

Voici le fichier de configuration /etc/puppet/modules/bind/manifests/init.pp :

class bind {
package { bind9: ensure => installed }
file { "/etc/bind/named.conf.local":
ensure => present,
mode => 644,
owner => "root",
group => "bind",
source => "puppet:///modules/bind/named.conf.local" }
file { "/etc/bind/named.conf.options":
ensure => present,
mode => 644,
owner => "root",
group => "bind",
source => "puppet:///modules/bind/named.conf.options" }
file { "/var/cache/bind/db.univ-donsalmon.fr":
ensure => present,
mode => 644,
owner => "root",
group => "bind",
source => "puppet:///modules/bind/db.univ-perp.fr" }
file { "/var/cache/bind/rev.univ-donsalmon.fr":
ensure => present,
mode => 644,
owner => "root",
group => "bind",
source => "puppet:///modules/bind/rev.univ-donsalmon.fr" }
service { bind9: ensure => running,
enable => true
}
}

Ici nous installons (si BIND n’est pas installé) le paquet, puis lui déployons les fichiers de configurations, puis le forçons à être démarré. Nous lui attribuons les droits 644 (par défaut sur Bind), puis le propriétaire root et le groupe bind.
Pareillement, ici nous remarquons que pour déployer le fichier, il n’est pas nécessaire de référencer le répertoire « files » dans le module, grâce au protocole qui est défini ici : puppet:///

Passons aux fichiers de configurations, /etc/puppet/modules/bind/files/named.conf.local :

// La zone primaire univ-donsalmon.fr
zone "univ-donsalmon.fr" {
type master;
file "/var/cache/bind/db.univ-donsalmon.fr";
};
// La zone inverse
zone "99.0.10.in-addr.arpa" {
type master;
file "/var/cache/bind/rev.univ-donsalmon.fr";
};

Puis le fichier, /etc/puppet/modules/bind/files/named.conf.options :

options {
directory "/var/cache/bind";
forwarders {
10.0.255.254;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Le fichier de zone primaire univ-donsalmon.fr, /etc/puppet/modules/bind/files/db.univ-donsalmon.fr :

;
; BIND data file for univ-donsalmon.fr
;
$TTL 604800
@ IN SOA puppetcli2.univ-donsalmon.fr. admin.univ-donsalmon.fr. (
201205091 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS puppetcli2.univ-donsalmon.fr.
puppetcli2 IN A 10.0.99.6
puppetcli1 IN A 10.0.99.5
puppetmaster IN A 10.0.99.4

Et pour finir le fichier de zone inverse ARPA, /etc/puppet/modules/bind/rev.univ-donsalmon.fr :

;
; BIND data file for 10.0.99
;
$TTL 604800
@ IN SOA puppetcli2.univ-donsalmon.fr. (
201209051 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS puppetcli2.univ-donsalmon.fr.
5 IN PTR puppetcli1.univ-donsalmon.fr.
4 IN PTR puppetmaster.univ-donsalmon.fr.

Configuration des templates

Variables prédéfinie:

Ici nous allons vous montrer comment on peut adapter les fichiers de configurations que nous déployons suivant le node.
Ainsi chaque node aura un paramètre différent d’un autre node, il s’agit du template. Nous allons prendre le cas du fichier de configuration d’Unbound. Sur le serveur Puppet il faut renommer le fichier /etc/puppet/modules/unbound/files/unbound.conf en /etc/puppet/modules/unbound/files/unbound.conf.erb.

cp /etc/puppet/modules/unbound/files/unbound.conf /etc/puppet/modules/unbound/files/unbound.conf.erb

En effet lorsqu’on créé un template, il doit être sous l’extension « erb ». En effet nous allons nous servir de la variable « ipaddress » disponible grâce à l’outil facter, ainsi en étant sur le client, il suffit de lancer la commande : puppetcli1 # facter pour obtenir les informations des variables de la machine locale.
Nous allons renseigner la variable « ipaddress » grâce aux balises de début: <%= et aux balises de fin: %>
Ainsi : Puppetmaster # head /etc/puppet/modules/unbound/files/unbound.conf.erb

La mise en place de templates permet de gagner sensiblement du temps sur la configuration des postes, c’est d’ailleurs pour cette utilisation que l’outil facter a été développé. En effet Puppet sert surtout pour les déploiements massifs, le gain de temps et d’énergie est ainsi effectif.

5) LANCEMENT DE LA SYNCHRONISATION :

Sur le serveur, il faut initier la connexion :

puppetmasterd --no-daemonize --debug
ou
puppet master --no-daemonize --debug 

Nous lançon le daemon en mode test, c’est à dire non-démon afin de débugger et vérifier que tout se déroule convenablement.
Si on rencontre un problème tel que :
Could not run: Could not create PID file: /var/run/puppet/master.pid
Il faut alors tuer le processus Puppet sur le serveur :

killall puppet

Et relancer la commande :

puppetmasterd --no-daemonize –debug
ou
puppet master --no-daemonize --debug

Attention : Cette commande ne doit jamais être interrompu !
Sur les clients on va vérifier le fichier du serveur /etc/puppet/site.pp avec la commande :

puppetd --test --server=puppetmaster.univ-donsalmon.fr
puppet agent --test --server=puppetmaster.univ-donsalmon.fr

A savoir qu’un cron est mis en place afin d’éviter aux clients de renouveler cette commande manuellement, il faut noter que la commande du serveur : « puppetmasterd –no-daemonize -d » ne doit pas être arrêtée.