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.
When it comes to configuration management and applications people try to adopt the config management also to application rollout or upgrades. Usually, people will struggle hard to get the things done right – especially when it comes to server or service dependencies. In Martin’s talk he shows how you can integrate Puppet declarative configuration management with task based workflows and plan based Orchestration using Puppet Bolt. He also gives an overview on Puppet limitations and how Puppet Bolt helps you to add the missing parts of Puppet. He further explains the differences between workflows and the according tasks, and orchestration and the plans. You will receive an overview of the integration between Puppet and Puppet Bolt and how to develop and use Bolt Tasks and Plans.
