Seite wählen

NETWAYS Blog

Kritischer Fehler in Puppet Version 7.29.0 und 8.5.0

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
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.

Schulungsnotebooks in neuem Gewand

In diesem Jahr konnten wir endlich wieder mehr Vor-Ort Trainings durchführen als in den vergangenen Jahren und sogar vereinzelte Inhouse-Trainings bei Kunden waren möglich. Bisher haben wir bei unseren Präsenztrainings oder auch -workshops auf Notebooks mit CentOS 7 gesetzt, und zwar deshalb weil die automatische Provisionierung durch unseren sog. „Event“-Foreman in Kombination mit Puppet seit langer Zeit gut funktioniert.

Recovery-Eintrag

Da es in der Vergangenheit für die Kollegen allerdings sehr aufwändig war die Notebooks nach jedem Training wieder ins Büro zu schleppen, sie zu verkabeln und sie dann von Grund auf neu zu installieren, haben wir uns einen Trick einfallen lassen: Nach der automatischen Grundinstallation des Betriebssystems wird ein LVM-Snapshot des Base Images erstellt. Grob gesagt heißt das der Stand des Base Images wird eingefroren und alles was neu hinzukommt bzw. verändert wird (z.B. individuelle Schulungsvorbereitungen für verschiedene Trainings) belegt zusätzlichen Plattenplatz. Damit lässt sich das ursprüngliche Base Image ohne Neuinstallation eines Notebooks schnell wieder herstellen und kann so auf das nächste Training angepasst werden.

Ein weiterer Vorteil des Ganzen ist das die Schulungsteilnehmer ihre Arbeitsumgebung so gestalten können wie sie möchten und beispielsweise auch uns nicht bekannte Passwörter setzen können, mit dem Löschen des LVM-Snapshots ist alles wieder vergessen. Um es auch technisch nicht so affinen Kollegen einfach möglich zu machen Notebooks „zurückzusetzen“, gibt es hierfür beim Booten unser Schulungsnotebooks einen „Recovery“-Eintrag im GRUB-Bootloader der den LVM-Snapshot des Base Images ohne jedes Zutun zurückspielt und das Notebook anschließend neu startet.

Wie kommen aber nun die individuellen Schulungsvorbereitungen auf die Notebooks? Ist die Frage die wir uns auch gestellt haben. Individuelle Schulungsvorbereitungen können z.B. die virtuelle Maschine(n) für das Training sein, meistens auf Basis von Virtual Box, SSH Keys, Hosteinträge, bestimmte Browser oder andere Applikationen um den Schulungsteilnehmern die praktischen Übungen überhaupt möglich bzw. so einfach wie nur denkbar zu machen. Sie in den Provisionierungsprozess einzubauen scheidet ja aus, da die Notebooks wenn überhaupt nur unregelmäßig neu installiert werden sollen.

Also haben wir uns auch hier etwas überlegt: Wir haben im allgemeinem Base Image ein Bash-Skript mit einem statischen Link zur Nextcloud abgelegt. Dort findet sich ein weiteres Skript das auf die aktuell angebotenen Trainings und die jeweils dafür benötigten Schulungsvorbereitungen verweist. D.h. hier liegen beispielsweise dann auch die aktuellen virtuellen Maschinen. Um das Ganze auf den Notebooks umzusetzen verwenden wir wieder Puppet, hier war die Transition leichter da wir das in der Vergangenheit so ähnlich eh schon im Foreman hatten. Damit auch jeder der Kollegen ein Notebook individualisieren kann, gibt’s hierfür natürlich auch einfache Auswahldialoge. Wurde ein Notebook für ein bestimmtes Training vorbereitet, so löscht sich das Skript zur Vorbereitung und kann erst nach dem Recovery wieder ausgeführt werden.

Beispielhafter Auswahldialog für individuelle Schulungsvorbereitung (teils mit historischen Trainings)

Das alles sollte nun natürlich auch weiterhin funktionieren. Da CentOS 7 ab 2024 keine Maintenance Updates mehr bekommt und wir bei manchen Schulungen die nativ auf den Notebooks durchgeführt werden auch etwas mit den veralteten Versionsständen zu kämpfen haben, fiel unsere Entscheidung auf CentOS Stream 9 als neues Betriebssystem für unsere Schulungsnotebooks. Damit wir überhaupt dran denken konnten CentOS Stream zu provisionieren musste erstmal das Debian auf unserem „Event“-Foreman angehoben werden, danach folgten viele kleine Updates von Foreman 1.22 bis zum aktuellen Release 3.4.0 und auch Puppet bzw. die Puppetmodule mussten aktualisiert werden. Im Foreman selbst waren die Mirrors für CentOS Stream einzurichten, Bereitstellungsvorlagen anzupassen und auch die Partitionierung haben wir aufgrund der gestiegenen Plattenkapazität der Notebooks adaptiert. Für einen automatischen Ablauf der Provisionierung nutzen wir das Foreman Discovery Plugin.

Foreman Discovery der Schulungsnotebooks

Wer sich nun selbst ein Bild von unseren Schulungsnotebooks machen möchte, dem kann ich natürlich auch nicht nur deswegen eines unserer Trainings oder einen unserer angebotenen Workshops ans Herz legen. Vielleicht auch im Zuge der diesjährigen OSMC (Open Source Monitoring Conference).

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Orchestration-Automation in einem Rutsch

Gerade für Testzwecke ist es von Vorteil, wenn man z.B. in der Cloud virtuelle Maschinen (VM’s) ohne großen Aufwand installieren und verwalten kann. Nur kommt noch die Installation von Programmen und Tools dazu, um die Testumgebung fertig zu bekommen, damit Test-Szenarien abgebildet werden können. Tools wie Terraform, Ansible oder Puppet und Bolt kommen da meistens zum Einsatz. Aber wie wäre es, wenn zum Beispiel sein Terraform-Deployment Verzeichnis  mit den .tf files schon vorhanden ist und nur alles in einem Rutsch ausrollen möchte. Da ich mich mit puppet-bolt schon mal auseinander gesetzt hatte, suchte ich nach einer Lösung und wurde fündig, denn Bolt kann terraform apply  ausführen, puppet-agent darauf installieren und der anschließend ein Puppet Manifest ausrollen. In meinem Kurz-Beispiel wird eine Ubuntu  VM erzeugt, Apache2 installiert und eine Webseite erstellt.

Wie das funktioniert erkläre ich in diesem Post:
Voraussetzung:
Terraform, puppet-agent und puppet-bolt müssen installiert sein.

Ich habe mir ein Verzeichnis angelegt z.B. terraform_puppet und in diesem sind folgende Dateien abgelegt:

├── bolt-project.yaml
├── data
│   └── common.yaml
├── files
│   └── site.html
├── hiera.yaml
├── inventory.yaml
├── manifests
├── plans
│   └── init.pp

Wichtig von den Dateien ist die bolt-project.yaml, die inventory.yaml und die init.pp, deren Inhalt sieht folgendermaßen aus:

bolt-project.yaml
---
name: terraform_puppet
modulepath: ~/puppet/modules

inventory.yaml
---
groups:
- name: terraform
targets: []
config:
transport: ssh
ssh:
private-key: ~/.ssh/passwordlesskey/id_rsa
user: ubuntu
host-key-check: false

Die ganze Magie passiert aber in dem Skript init.pp

plan terraform_puppet(String $tf_path) {
$localhost = get_targets('localhost')

# Create infrastructure with terraform apply
run_command("cd ${tf_path} && terraform apply --auto-approve && sleep 20", $localhost)
$ip_string = run_command("cd ${$tf_path} && terraform output instance_ips",
$localhost).map |$r| { $r['stdout'] }
$ips = Array($ip_string).map |$ip| { $ip.strip }

# Turn IPs into Bolt targets, and add to inventory
$targets = $ips.map |$ip| {
Target.new("${$ip}").add_to_group('terraform')
}

# Deploy website
apply_prep($targets, _run_as => 'root', _required_modules => ['apache'])

apply($targets, _run_as => 'root') {
include apache
file { '/var/www/html/index.html':
ensure => 'file',
source => 'puppet:///modules/terraform_puppet/site.html',
}
}
return $ips
# Or diagnose issues across your terraform infrastructure
run_command('uptime', $targets)
}

Ich habe das ganz bei uns im Openstack umgesetzt, es kann aber auch in anderen Cloud Umgebungen übernommen werden und muss diesbezüglich angepasst werden.

So um das ganze jetzt in Gang zu setzen führt man folgendes Kommando in diesem terraform_puppet Verzeichnis aus:

bolt plan run terraform_puppet -i inventory.yaml tf_path=~/terraform/vmdir

Für alle die, die Puppet und Ruby Wissen haben, sollte das selbsterklärend sein, ansonsten grobe kurze Erklärung:

Bolt führt ein Skript aus das ein Terraform apply triggert und die IP als Variable speichert und als inventory Host-Target zu den groups hinzufügt,
damit diese als $target Variable vom Bolt inventory und dann per puppet apply genutzt werden kann. Das puppet Module Apache wird dazwischen auch mit eingelesen und genutzt.
Das schöne ist, die Funktion von bolt apply_prep, diese sorgt dafür, das für das per terraform installierte VM-OS der puppet-agent installiert und ausgeführt werden kann, wenn man das ganze laufen lässt sieht man es als command durchlaufen.
Anschließend wird per bolt apply ein puppet code  per puppet apply ausgeführt, der in unserem Fall den Apache2 installiert und einen index.html an die entsprechende Stelle kopiert (die man vorher unter files selber anlegen muss) und dann den Apache2 Service startet.

Das Ergebnis sollte dann die Webseite der index.html sein , wenn man die IP-Adresse der VM im Browser (http://$ipaddress_vm eingibt.

Das ist natürlich nur ein ganz vereinfachtes Beispiel, aber die Möglichkeiten die man damit hat, finde ich genial.

Natürlich bieten wir zum Thema Puppet auch Trainings an, wo man die Grundlagen der Automatisierung mit Puppet vermittelt bekommt.

Viel Spaß und Erfolg beim Ausprobieren.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

NETWAYS wird Puppet Authorized Reseller

Seit vielen Jahren unterstützt NETWAYS bereits erfolgreich Kunden bei der Konzeptionierung, dem Aufbau, der Erweiterung sowie der Migration von Puppet Umgebungen. Dabei lag der Schwerpunkt bislang auf der Open Source Variante, obwohl es im Puppet ENTERPRISE Segment viele interessante und hilfreiche Erweiterungen gibt, die wir im Rahmen der Dienstleistung nicht direkt anbieten konnten.

Diesen Zustand wollten wir ändern! Wir freuen wir uns, dass wir seit Kurzem offizieller Authorized Reseller von Puppet sind. Für unsere Kunden ändert sich an unseren bestehenden Leistungen dadurch nichts. Wir bieten weiterhin die professionellen Dienstleistungen im Open Source Bereich an, die sie von uns gewohnt sind. Der Vorteil dieser Partnerschaft ist eine Erweiterung unseres Portfolios. Anforderungen unserer Kunden können wir jetzt noch besser umsetzen, da wir nun in der Lage sind, ENTERPRISE Lizenzen selbst anzubieten und sämtliche Leistungen damit direkt von uns beziehbar sind.

Puppet als starker Partner

Für unsere Kunden ergibt sich aus dieser Partnerschaft zudem ein zusätzlicher deutlicher Vorteil: Neben den Open Source Themen können wir nun nicht nur die ENTERPRISE Lösungen anbieten, sondern auch mit Puppet und unseren Kunden gemeinsam in den Dialog treten können, um das Configuration Management passgenau beim Kunden zu installieren und zu konfigurieren.

Durch das breite Partner Netzwerk von Puppet können wir auf bisherige Erfahrungen von Puppet in ähnlichen Umgebungen zurückgreifen und mögliche Herausforderungen sowie Anforderungen frühzeitig identifizieren.

Nächster Halt: Solution Provider

Als nächster Schritt steht bei uns jetzt noch aus, dass wir Puppet Solution Provider werden. Damit ergibt sich für unsere Kunden noch eine Vielzahl an weiteren Vorteilen, da unsere Kollegen in diesem Fall offiziell von Puppet zertifiziert werden und somit auch ein Nachweis darüber vorhanden ist. Hierdurch können wir dann auch unser langjähriges Engagement und Know-How, das wir mit Puppet gesammelt haben, schriftlich unter Beweis stellen.

Habt Ihr Interesse an unseren Puppet Dienstleistungen oder Puppet ENTERPRISE? Dann nutzt doch einfach unser Kontaktformular und nehmt Kontakt mit uns auf! Wir freuen uns auf eure Anfragen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Config Management Camp Ghent 2019

Ich habe dieses Jahr die erste Gelegenheit bekommen, mich mit meinen Kollegen und meinem Chef am Configuration Management Camp im Ghent zwischen 4. und 6. Februar zu beteiligen. Wir sind am 3. Februar am Abend in Ghent angekommen und durch die Stadt spazieren gegangen. Ghent hat uns sehr beeindruckt: Nicht nur die Sauberkeit der Straßen, sondern auch die Verbindung von alten und neuen Gebäuden haben Ghent besonders schön wirken lassen.

DevOps und Konfigurationsmanagement

Aber der Höhepunkt war das Camp: Es gab fast 1000 Teilnehmer aus der ganzen Welt. Die Vorträge waren sehr informativ und gingen hauptsächlich um DevOps und Konfigurationsmanagement ( Puppet, Ansible, Chef, Foreman). Viele Referenten haben sowohl ihre Erfahrungen sowie zuletzt aufgekommene und gelöste Probleme in ihrer Firma geteilt, als auch neue Features im Automation- und Konfigurationsmanagement-Feld vorgestellt. Am dritten Tag nahm ich mit meinem Kollegen und Ausbilder auf dem Foreman Construction Day Workshop teil. Wir haben uns in Gruppen praktisch mit „Foreman“ beschäftigt. Am Ende des Tages haben einige Foreman-Entwickler und Teilnehmer über Wünsche, Verbesserungen und kommende Features gesprochen.

Ich empfehle jedem, der Interesse am Konfigurationsmanagement hat, das nächste Camp zu besuchen und belgische Waffeln und Bier auf jeden Fall zu probieren. Die sind sehr, sehr lecker.

 

 

 

 

 

 

 

Afeef Ghannam
Afeef Ghannam
Systems Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kolleg:innen im Operations Team der NETWAYS Professional Services bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.