Soit un puppetmaster fonctionnel installé dans une machine virtuelle. Le nom « puppet.domain.example » pointe sur cette machine. Dans une nouvelle machine virtuelle, on installe un nouveau puppetmaster, plus récent et on importe nos catalogues existants. Le nom « puppet-test.domain.example » pointe sur cette machine.

Afin de faire des tests, on installe un puppet agent dans une nouvelle machine virtuelle. On le configure pour fonctionner de pair avec le nouveau puppetmaster (server = puppet-test.domain.example dans /etc/puppet/puppet.conf). On déroule un catalogue, il s'exécute, mais, pour chaque action réalisée, une erreur « Error: Could not back up : SSL_connect returned=1 errno=0 state=error: certificate verify failed: [self signed certificate in certificate chain for /CN=Puppet CA: puppet.domain.example] » se produit et les fichiers ne sont pas modifiés par le puppet agent comme ils le devraient.

Pourquoi donc notre puppet agent récupère-t-il un certificat x509 du puppetmaster legacy quand il cause avec notre puppetmaster de test (« self signed certificate in certificate chain for /CN=Puppet CA: puppet.domain.example ») ? Un tcpdump nous montre que l'agent discute avec le puppetmaster de test puis qu'il discute plusieurs fois avec le puppetmaster de production.

Cela provient de filebucket, une fonctionnalité qui permet de sauvegarder, sur le puppetmaster (ou ailleurs) les fichiers qui vont être modifiés par les agents. La configuration de cette fonctionnalité se fait dans le catalogue, sur le puppetmaster. Et dans mon cas, j'avais le bout de conf' suivant :

filebucket { "main":
    server => "puppet",
    path   => false,
}

Ce bout de config' demande explicitement à l'agent de contacter le puppetmaster de prod' pour y stocker les fichiers qui seront modifiés… On corrige cette config' avec le nom du puppetmaster de test et tout fonctionne. :)