De manière générale, quand j’installe une machine, je lance un script de bootstrap sur mon serveur d’admin, celui qui a la clé ssh qui va bien. Ce script (bash) comporte entre autres le bout de code suivant :

[ -d BY-HOST/$host ] || ./gen-host $host

( cd BY-HOST/$host && tar cf - . ) \
  | ssh $host '( mkdir -p /var/lib/puppet/ssl && \
    cd /var/lib/puppet/ssl && rm -f *.pem */*.pem && \
    tar xvf - && \
    /usr/sbin/puppetd --no-daemonize --onetime --no-splay --verbose && \
    touch /var/run/puppet/run-often )'

En résumé, ça efface les éventuels certificats et autres clés déjà présents sur la machine, ça les remplace par la version «qui fait autorité» et ça lance puppet pour amorcer la pompe. Pour le touch à la fin, c’est expliqué là : http://blogs.glou.org/arnaud/2011/02/24/lancer-puppet-depuis-cron/

Et si le serveur d’admin n’a pas les données en local ? Bah il les génère, tiens ! C’est le rôle de la première ligne. Le script gen-host fait moralement ça :

mkdir -p BY-HOST/${host}/{certs,private_keys}
cp ca-${puppetmaster}.pem BY-HOST/${host}/certs/ca.pem
ssh $puppetmaster "puppetca --clean $host ; puppetca --generate $host"
scp ${puppetmaster}:/var/lib/puppet/ssl/private_keys/${host}.pem BY-HOST/${host}/private_keys/
scp ${puppetmaster}:/var/lib/puppet/ssl/ca/signed/${host}.pem BY-HOST/${host}/certs/

Moralement, parce qu’il bosse un peu avant pour générer les variables $host et $puppetmaster. La première contient $1 éventuellement qualifié (j’utilise systématiquement le FQDN comme identifiant) ; la seconde est déterminée par une variable dans la fiche LDAP du client.

Voilà, c’est un peu bricolé mais ça marche bien.

Et je me rends compte qu’il faudrait que je migre vers la syntaxe de puppet 2.x un de ces jours.

J’ai donc pondu un petit bout de script shell pour lancer puppetd uniquement quand on a besoin de lui. J’en ai profité pour améliorer un peu la gestion de la périodicité. En gros,

• par défaut, puppetd tourne une fois par heure,
• si le fichier /var/run/puppet/run-often existe, il tourne toutes les 5 minutes pendant une heure au plus (il supprime le fichier après ce délai),
• si le fichier /var/run/puppet/never-auto-run existe, il refuse de tourner (pratique pour les maintenances où on ne veut pas se battre contre puppet).

Tout ça, c’est géré par cron de cette façon :

*/5 * * * * /usr/local/sbin/run-puppet -often
42 * * * * /usr/local/sbin/run-puppet

Notez que ces deux invocations ne lancent pas puppetd immédiatement ; elles attendent «un certain temps» (calculé en fonction de l’adresse IPv4 de la machine, je voulais des intervalles fixes entre deux passages de Puppet).

Le script accepte aussi une option -now qui lui indique de lancer puppet immédiatement ; cette option est conçue pour invoquer le script directement en ligne de commande.

Finalement, le script lui-même :

#!/bin/bash
#
# Arnaud Gomes 2010
#
# Trigger a puppet run.
#
# Usage:
#
#   run-puppet
#       Run sometime in the next hour.
#
#   run-puppet -often
#       Run sometime in the next 5 minutes if $runoftenfile exists.
#
#   run-puppet -now
#       Run now.
#
# This script will exit immediately if $dontrunfile exists.
#
# Needs /usr/bin/lockfile (from procmail).

flagdir="/var/run/puppet"
runoftenfile=${flagdir}"/run-often"
dontrunfile=${flagdir}"/never-auto-run"
lockfile=${flagdir}"/lock"
puppetd="/usr/sbin/puppetd"
flags="--no-daemonize --onetime --no-splay"

usage () {
        echo "Usage: $0 [ -often | -now ]"
        exit 1
}

dontrun () {
        echo "$dontrunfile present, skipping this run."
        exit 0
}

run () {
        lockfile $lockfile
        $puppetd $flags
        rm -f $lockfile
}

[ $# -le 1 ] || usage
[ -f $dontrunfile ] && dontrun

# $seed is used for computing splay time. We do not make it random
# as we want each machine to run puppet every hour (or whatever), not
# "more or less randomely averaging to once every hour".
#
# This horrible perl thing just means "last two bytes from IPv4 address,
# reversed". We reverse them as the last byte probably is more evenly
# distributed.
seed=$(($(facter ipaddress | perl -pe 's/^([0-9]+\.){2}([0-9]+)\.([0-9]+)$/$3 * 256 + $2/')))
splay=$(($seed % 3600))

# Exit if called with -often and no $runoftenfile.
# If $runoftenfile is here, we run within 5 minutes instead of within
# an hour.
if [ "$1" = "-often" ]
then
        [ -f $runoftenfile ] || exit 0
        splay=$(($seed % 300))
fi

# Of course option -now removes any splay time.
if [ "$1" = "-now" ]
then
        splay=0
        flags="$flags --verbose"
fi

sleep $splay
run

# Remove $runoftenfile after an hour. We don't want to run every 5 minutes
# for ever, only when needed.
[ -f $runoftenfile ] && find $runoftenfile -cmin +60 -exec rm -f {} \;

J’utilise linux-vserver sur une poignée de machines qui hébergent chacune quelques dizaines d’instances d’OS. Dans mon installation de base (CentOS), chaque isolateur fait tourner sendmail pour envoyer le mail local vers l’extérieur ; je parle essentiellement des rapports de logwatch et autres cronneries. Avec tous les problèmes habituels en cas de forte charge, ce qui arrive assez facilement dans ce genre de configuration.

Solution : installer un /usr/sbin/sendmail un peu plus léger, en l’occurrence ssmtp, sur toutes les machines sauf les vrais serveurs SMTP, qui eux font tourner Postfix.

La configuration puppet

Un petit extrait de ma config (nettement plus complète mais pas publiable en l’état) :

class mail{
}

class mail::smtp inherits mail {

package { "ssmtp": ensure => installed, }

file { "/etc/ssmtp/ssmtp.conf":
source => [
"puppet:///files/mail/ssmtp.conf.$hostname",
"puppet:///mail/ssmtp.conf",
],
owner => root,
group => root,
mode => 0644,
require => Package["ssmtp"],
}

exec { "setup_mta":
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.ssmtp",
subscribe => Package["ssmtp"],
refreshonly => true,
}

}

class mail::postfix inherits mail::smtp {

package { ["postfix", "postfix-pflogsumm"]: ensure => installed }

service { "postfix":
enable => true,
ensure => running,
hasstatus => true,
subscribe => Package["postfix"],
}

Exec["setup_mta"] {
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.postfix",
subscribe => Package["postfix"],
}

}

L’intérêt de la chose : toutes les machines sont dans la classe mail::smtp, et Postfix est installé uniquement là où il faut, et surtout une même machine peut cumuler les rôles « serveur SMTP » et « autre chose » et tout se passera comme il faut.

Pour le moment, ça installe ssmtp même sur les machines où il n’est pas nécessaire, on verra à corriger ça dans la prochaine version.

Après avoir passé pas mal de temps à potasser la doc et à demander plein de trucs à Google, voici donc les quelques points qui m’ont posé problème. Attention, tout ceci concerne une infrastructure à base de CentOS 4 et 5, avec le serveur sous CentOS 5. Puppet lui-même est installé depuis EPEL.

Organisation

Dans le fichier site.pp, on définit juste des classes « conteneurs » comme suit :

class lamp {
  include php
  include mysql
}

Les autres classes sont définies dans des fichiers à part (php dans classes/php.pp et ainsi de suite). Ça, c’est une convention plus qu’autre chose mais en pratique ça aide à avoir les idées claires.

LDAP

J’utilise LDAP pour stocker les infos relatives aux clients. Pour que ça fonctionne, il faut :

• installer ruby-ldap sur le serveur
• ajouter, toujours sur le serveur, un fichier /etc/puppet/puppetmasterd.conf avec le contenu suivant :

[main]
    vardir = /var/lib/puppet
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    ssldir = $vardir/ssl

[puppermasterd]
    node_terminus = ldap
    ldapserver = ldap.ircam.fr
    ldapbase = ou=Hosts,dc=ircam,dc=fr

Pour les clients, tout se passe dans l’annuaire lui-même : on leur ajoute la classe puppetClient et un champ puppetclass qui contient la liste des classes.

dn: cn=system.ircam.fr,ou=virtuels,ou=Hosts,dc=ircam,dc=fr
puppetclass: lamp

Pour le moment, le noeud default est encore en dur dans site.pp, ça râle dans les logs de puppetmasterd, il faudra le pousser dans LDAP un jour ou l’autre.