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.