Puppet-Agenten erzeugen zahlreiche Fehlermeldungen: "Could not set 'file' on ensure: incorrect header check"

Kürzlich hatte ich in meiner Homelab-Umgebung den Fall, dass meine über Puppet verwalteten Linux-Systeme zahlreiche Fehlermeldungen beim Aktualisieren des Katalogs generierten:

1# puppet agent --test
2Error: /File[/var/lib/puppet/lib/puppet/parser/functions/load_module_metadata.rb]/ensure: change from absent to file failed: Could not set 'file' on ensure: incorrect header check
3Error: Could not set 'file' on ensure: incorrect header check
4Error: Could not set 'file' on ensure: incorrect header check
5Wrapped exception:
6incorrect header check
7...

Der Fehler trat zuerst nach dem letzten Katello-Upgrade auf 3.5 auf. Ich hatte damals auch Puppet von Version 3 auf 4 angehoben:

1katello# puppet --version
24.10.12

Gemäß der Dokumentation werden Puppet 3-Clients weiterhin unterstützt. Nach zahlreichen Agent-Neuinstallationen und weiteren Analysen wusste ich nicht wirklich weiter.

Mein Arbeitskollege Mirko Schmidt gab mir den Tipp, den Puppet-Agenten unabhängig der offiziellen Support-Matrix zu aktualisieren. Auf meinen Systemen entstammte Puppet dem EPEL-Repository - in einer stark veralteten Version:

1# rpm -qa | grep puppet
2puppet-3.6.2-3.el7.noarch
3# yum info puppet|grep -i "from repo"
4From repo   : EPEL7 x86_64

Puppet bietet in Form von Puppet Collections ein entsprechendes Software-Repository mit aktuellen Paketen:

1# yum localinstall http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

Die Aktualisierung des Agenten verlief problemfrei - das Paket puppet wird dabei durch puppet-agent ersetzt:

1# systemctl stop puppet
2# kill $(cat /var/run/puppet/agent.pid) ; killall puppet
3# yum update -y puppet

Hierbei ändern sich auch die Pfade der Konfigurationsdateien. Die Dateien unterhalb /etc/puppet sind nach der Aktualisierung unterhalb /etc/puppetlabs/puppet zu finden.

Da der komplette Agent ersetzt wurde, muss dieser auch neukonfiguriert werden. Vorherige Konfigurationsdateien lassen sich in der Regel weiter verwenden. Ich empfehle jedoch, ein Backup der ursprünglichen Konfigurationsdatei des neuen Agenten zu erstellen, bevor die alte Konfiguration übernommen wird:

1# cp /etc/puppetlabs/puppet/puppet.conf /etc/puppetlabs/puppet/puppet.conf.initial
2# cp /etc/puppet/puppet.conf.rpmsave /etc/puppetlabs/puppet/puppet.conf

Bevor der neue Agent gestartet wird, muss das bisherige Zertifikat im entsprechenden Smart Proxy entfernt werden. Hierzu genügen Klicks in der Foreman-Oberfläche auf Infrastructure -> Smart Proxies -> Proxy -> Puppet CA -> Certificates -> Revoke.

Anschließend wird der Puppet-Agent ausgeführt, um ein neues SSL-Zertifikat zu erstellen und dieses beim Smart Proxy einzureichen.

1# /opt/puppetlabs/bin/puppet agent --test --noop
2...
3Exiting; no certificate found and waitforcert disabled

Mit einem Klick auf Sign in der Foreman-Oberfläche wird dieses importiert und der Agent kann aktiviert werden:

1# systemctl enable puppet ; systemctl start puppet

Anschließend verschwanden die Fehlermeldung und der Infrastruktur-Zustand normalisierte sich: