Puppet

Puppet est un outil de gestion de la configuration de serveurs, il permet le télédéploiement de configuration sur un ensemble de serveurs en quelques minutes. L'intérêt de cette solution open source réside dans son support multi-plateformes (basé sur Ruby), sa sécurité (TLS), son développement actif et sa relative simplicité à mettre en œuvre.

Systèmes supportés : Puppet fonctionne sur la plupart des systèmes Unix et sur Windows. voir ici pour plus de détails.

  • Disposer d'une connexion à Internet configurée et activée.
  • Disposez de plusieurs serveurs à administrer sans quoi le gain de temps et d'énergie ne sera pas effectif.
  • Notions en administration système.

Puppet est présent dans les dépôts, installez les paquets puppet, facter et puppetmaster (pour le serveur maître) :

  • Sur le client :
    apt-get install puppet
  • Sur le master :
    apt-get install puppetmaster

Cependant si vous souhaitez une version différente rendez-vous sur la page de téléchargement officielle pour obtenir un package .tar.gz. Autre solution installer puppet sous forme de gem (le système de paquet ruby). Dans ce cas l'installation est tout aussi simple :

apt-get install rubygems
gem install facter
gem install puppet

Maître

Fichiers de configuration

Les fichiers de configuration sont donnés à titre d'exemple. Vous êtes libre d'indiquer d'autres paramètres.

On modifie le fichier /etc/puppet/puppet.conf :

[main]
logdir =        /var/log/puppet
vardir =        /var/lib/puppet
ssldir =        $vardir/ssl
rundir =        /var/run/puppet
confdir =       $vardir
factpath =      $vardir/lib/facter
pluginsync =    false
server =        hostnameduserveur
report =        true
reports =       log,store

[master]
templatedir =   $vardir/templates
modulepath =    $vardir/modules
libdir  =       $vardir/plugins
syslogfacility = user

Pare-feu

On modifie également notre pare-feu afin de laisser passer les flux :

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -s ipdumaster --sport 8140 -d ipduclient -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -s ipduclient -d ipdumaster --dport 8140 -j ACCEPT

Esclave

Configuration de l'agent Puppet

On modifie le fichier /etc/puppet/puppet.conf :

[main]
server =        hostnamedevotremaster
report =        true
rundir =        /var/run/puppet/
runinterval =   50

[agent]
listen=true

Le runinterval permet de spécifier, en secondes, l'intervalle entre deux connexions que fera le client, vers le serveur. Pour qu'elles soient vraiment lancées régulièrement, il faut que le daemon puppet soit lancé (/etc/init.d/puppet start).

Le paramètre listen et les fichiers auth.conf et namespaceauth.conf sont nécessaires pour activer le déploiement à partir du master (puppet kick ou puppetrun) si vous ne souhaitez pas utiliser ces commandes, ces fichiers sont inutiles.

/etc/puppet/auth.conf

path /run
method save
allow *
Attention le fichier auth.conf donné en exemple est dédié à des phases de tests, il autorise par défaut toutes les connexions sur l'ensemble des éléments

/etc/puppet/namespaceauth.conf

[puppetrunner]
allow *
[puppetbucket]
allow *
[puppetreports]
allow *
[resource]
allow *
[kick]
allow *

Pare-feu

Si vous disposez d'un pare-feu actif il faut songer à ouvrir le port 8139 :

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -s ipduclient --sport 8139 -d ipdumaster -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -s ipdumaster -d ipduclient --dport 8139 -j ACCEPT

Avant de pouvoir utiliser un client il faut préalablement le valider auprès du master. Pour cela sur le client lancer la commande :

puppetd --test

Cela va générer un certificat que l'on nous demandera de valider. Pour cela sur le serveur :

puppetca --list
nomduclient

doit nous retourner le nom du serveur en attente de validation ensuite on signe le certificat en attente :

puppetca --sign nomduclient

ou bien

puppetca -s nomduclient

Via la commande Puppetrun

Pour lancer le puppetd –test sans devoir être connecté à chaque client on lance

puppet kick nomduclient

ou encore

puppetrun nomduclient
Si cela ne fonctionne pas vérifiez bien qu'un déploiement sur le client est fonctionnel ainsi que l'ouverture des ports du parefeu.

Via l'API REST (conseillé)

L'API REST permet à une requête HTTP d'envoyer un équivalent du puppetrun mais permet en plus le passage d'arguments tel que l'environnement. Il suffira ainsi de passer la commande suivante via CURL pour lancer un puppetrun sur l'environnement de production. Cette dernière renverra alors le retour du déploiement au format Yaml

curl -k -X PUT -H "Content-Type: text/pson" -d "{}" https://puppetclient:8139/production/run/no_key

L'utilisation de l'API est explicitée [en] ici

Désactivez le déploiement automatique d'un client

Un client puppetd qui tourne en daemon à la fâcheuse tendance d'être configuré pour exécuter un puppetd –test à intervalles réguliers. Pour solutionner ce problème tout en gardant un daemon à l'écoute du puppetrun du master il faut lancer le process puppetd avec l'option –no-client soit :

puppetd --no-client

pour automatiser l'ensemble on pourra le rajouter dans le fichier /etc/init.d/puppet

err: Could not retrieve catalog: Could not parse for environment development: Could not match ''

Ce problème peut survenir au cours d'un déploiement, il s'agit d'un mauvais encodage du/des fichier(s) de scripts puppet lorsqu'ils ont été créés à partir d'un poste sous Windows, pour résoudre ce souci un petit coup de dos2unix fera l'affaire =) :

dos2unix le/fichier/de/script

no certificate found and waitforcert is disabled

warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled

Le certificat n'a pas encore été signé sur le master.

Run of Puppet configuration client already in progress

notice: Run of Puppet configuration client already in progress; skipping

Indique que Puppet est déjà en cours d'exécution sur la machine.

certificate verify failed

err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

indique que le certificat que possède le client diffère de celui du master, aussi la solution la plus simple est de régénérer un certificat sur le client puis de le signer sur le master. Pour ce faire on supprime le certificat précédent.

rm -rf /etc/puppet/ssl
Le répertoire peut différer en fonction de votre configuration, il s'agit de la valeur de la variable ssldir dans le fichier /etc/puppet/puppet.conf

On effectue une nouvelle tentative de déploiement qui va générer un nouveau certificat

puppetd --test
info: Creating a new SSL key for votreserveur.fr
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for votreserveur.fr
info: Certificate Request fingerprint (md5): 80:AE:23:1C:03:DF:5D:65:0D:8F:04:82:AC:D2:BF:C1

On peut ensuite signer le certificat sur le puppetmaster et déployer de nouveau.

Si le problème persiste toujours il s'agit alors sans doute d'une mauvaise synchronisation horaire entre le client et le master.

err: Could not request certificate: Neither PUB key nor PRIV key:: header too long

Si lors du lancement de la commande puppetd –test vous obtenez cette erreur :

puppetd --test
info: Creating a new SSL key for hostnameduserveur
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Caching certificate_request for hostnameduserveur
err: Cached certificate for ca failed: header too long
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
err: Cached certificate for ca failed: header too long
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled

puppetd --test
err: Could not request certificate: Neither PUB key nor PRIV key:: header too long
Exiting; failed to retrieve certificate and waitforcert is disabled

Ce problème survient lorsque le système de fichier sur lequel Puppet essaye de créer le certificat est plein.

Processus fantôme

Si le déploiement renvoie une erreur de ce type :

puppetd --test
notice: Run of Puppet configuration client already in progress; skipping

mais qu'il n'existe aucun processus ou fichier .pid sous /var/run/puppet, c'est qu'il existe probablement un fichier verrou qui n'a pas été correctement supprimé. Pour ce faire passer la commande suivante :

rm /var/lib/puppet/state/puppetdlock

Pour supprimer cette application, il suffit de supprimer son paquet. Si vous avez choisi l'option des gems il vous suffira de faire :

gem uninstall puppet
gem uninstall facter

.

  • puppet.txt
  • Dernière modification: Le 24/04/2018, 19:04
  • (modification externe)