Eine Warnung an alle Nutzer von Puppet, aber auch Foreman oder dem Icinga-Installer, die Version 7.29.0 und 8.5.0 von Puppet enthält einen kritischen Fehler, der die Erstellung eines Katalogs und somit die Anwendung der Konfiguration verhindert. Daher stellt bitte sicher diese Version nicht bei euch einzuspielen!

Was genau ist das Problem?

Durch eine Änderung in den Versionen werden Klassenparameter mit einem Integer mit negativem Minimum nicht mehr als solche erkannt und stattdessen kommt es zu dem Fehler „The parameter ‚$parameter_name‘ must be a literal type, not a Puppet::Pops::Model::AccessExpression“. Da viele Module diesen Default verwenden, um den Wert „-1“ nutzen zu können wenn etwas unlimitiert sein soll, ist es sehr wahrscheinlich, dass eine Umgebung davon betroffen ist.

Ein Beispiel hierfür ist das Puppet-Modul zum Management von Redis, welches auch zu dem öffentlich einsehbaren Issue „puppet 7.29.0 sinks my arithmetic battleship!“ geführt hat. Tatsächlich ist auch bereits ein möglicher Fix dafür als Pull-Request „Accept UnaryMinusExpression as class parameter type“ in Arbeit, so dass hoffentlich bald eine Bugfix-Version releast werden kann.

Bis zu dem Bugfix-Release sind aber nicht nur direkte Puppet-Nutzer betroffen! Auch wenn ein Installer darauf aufbaut wie dies bei Foreman oder dem Icinga-Installer der Fall ist und ein entsprechendes Modul hierbei benötigt wird, ist es wichtig diese Versionen nicht einzuspielen!

Wie verhindere ich nun am sinnvollsten, dass diese Version eingespielt wird?

In einem geeigneten Softwaremanagement wie Katello lässt sich die fehlerhafte Version herausfiltern und somit gar nicht erst den Systemen zur Verfügung zu stellen. Ohne diese Möglichkeit muss mit den Mitteln des Paketmanagers unter Linux gearbeitet werden.

Bei DNF in der Betriebssystemfamilie „Red Hat“ lässt sich bei manuellen Updates --excludepkgs puppet-agent* angeben, um das Paket temporär auszuschließen. Wenn dies längerfristig benötigt wird oder gar ein automatische Update das Paket mitbringen könnte, lässt sich in der Haupt-Konfiguration oder im Puppet-Repository eine Zeile excludepkgs=puppet-agent-7.29.0*,puppet-agent-8.5.0* hinzufügen. Hierbei ist die genauere Versionsangabe wichtig, denn so kann die Konfiguration auch langfristig so verbleiben, ohne dass man daran denken muss die Zeile wieder zu entfernen. Wer noch ältere Versionen mit YUM nutzt kann dies genauso nutzen.

Auf der Betriebssystemfamilie „Debian“ kann mittels apt-mark hold puppet-agent kurzfristig das Update des Paktes blockiert werden. Dieses muss dann mit apt-mark unhold puppet-agent wieder aufgehoben werden, was mittels apt-mark showhold sichtbar wird. Auch hier empfiehlt sich bei Bedarf eine Lösung über die Konfiguration. Dafür muss innerhalb der Präferenzen von APT eine Konfiguration im folgenden Format angelegt werden.

Package: puppet-agent
Pin: version 1:7.29.0*
Pin-Priority: -1

Package: puppet-agent
Pin: version 1:8.5.0*
Pin-Priority: -1

Für Zypper auf SUSE-Systemen ist mir leider keine so elegante Lösung bekannt. Hier hilft temporär auch der Parameter --exclude puppet-agent oder zypper addlock puppet-agent.

Für den oder die zentralen Puppetserver bitte auch das Paket „puppetserver“ so behandeln.

Was wenn die Version schon installiert ist?

Der Agent aber auch der Puppetserver sollten sich problemlos über das Paketmanagement downgraden lassen. Zumindest hatte ich damit in der Vergangenheit keine Probleme. Also hilft hier dnf downgrade puppet-agent, apt install puppet-agent=VERSION oder zypper install --oldpackage puppet-agent=VERSION wobei man die letzte getestete Version angeben sollte.

Ich hoffe wie in solchen Fällen immer die Warnung wurde rechtzeitig gelesen und wir konnten euch damit ein paar Probleme ersparen!

Das Beitragsbild besteht aus dem Bild „Insects Collection 11“ von Openclipart-User GDJ sowie dem offiziellen Puppet-Logo.

Dirk Götz

Principal Consultant

---

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Lies mehr von Dirk und triff unser Team