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
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. :)
‒ Elle en avait vraiment dans le froc.
‒ Dans le froc… Pourquoi est-ce que les couilles reviennent systématiquement sur la table quand on parle de quelqu'un qui a du cran comme elle ? Ces petits trucs tout fragiles qui restent là, bien au chaud, confortablement installés dans leur fine couverture de peau toute ridée. Quelle connerie !
Dans le jeu vidéo Wolfenstein II: The New Colossus.