Upgrading your infrastructure to Puppet 4

Immer noch Puppet v3.x im Einsatz? Langsam wird es höchste Zeit auch deine letzten Systeme auf Puppet 4 umzustellen. Puppet 3 ist mittlerweile schon seit dem 31.12.2016 End of Life und viele Module aus der Forge sind längt nur mehr für Puppet 4 und aufwärts verfügbar.

In der Regel bedeutet die Umstellung von Puppet 3 auf Puppet 4 zwar eine Menge Arbeit, es lohnt sich aber definitiv. Welchen Performance Boost mit Puppet 4 beim Compiling eines Catalogs herausholen kann zeigt der folgende Auszug (aus Foreman) aus einem meiner aktuellen Projekte (ein Kunde mit ca. 1000 Puppet Nodes).

Upgrade zu Puppet 4

Die Grafik zeigt die Dauer eines Puppet Laufs – vor und nach dem Upgrade auf Puppet 4 der Node. Ein weiterer Boost mit dem nachgelagerten Upgrade auf Puppet 5.x steht noch aus.

Die Basis für das Upgrade auf Puppet 4 war dort insbesondere das weitreichende Testing des Codes via Jenkins CI Jobs und verschiedenen Tools. Dadurch konnten alle problematischen Stellen im Code gefunden und direkt ausgebessert werden. Einen ersten Überblick über die nötigen Änderungen kann der Puppet 4 Upgrade Guide geben.

Ein großartiges Tool für den Vergleich zwischen Katalogen („was passiert bei einem Upgrade auf v4?“) ist octocatalog-diff von GitHub.

Noch keine Strategie für das Upgrade auf Puppet 4.x? Setzt euch gerne mit mir in Verbindung und wir besprechen wie ich euch unterstützen kann.

Puppet: Distributing external facts (facts.d)

Am Montag habe ich bereits zum dritten mal mal meine Zertifizierung zum Certified Puppet Professional verlängert.

Puppet Certified Professional 2017

Eine Sache an die ich während des Tests wieder erinnert wurde, ist das Facter ab Version 3.9 auch die Möglichkeit bietet externe Facts komplett automatisch via Pluginsync zu verteilen.

[root@web01 ~]# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Notice: /File[/opt/puppetlabs/puppet/cache/facts.d/external_fact.sh]/content: 
--- /opt/puppetlabs/puppet/cache/facts.d/external_fact.sh	2017-11-01 23:27:31.049639111 +0100
+++ /tmp/puppet-file20171102-1070-p2fybh	2017-11-02 13:26:22.145274644 +0100
@@ -1,2 +1,3 @@
+ #!/bin/bash
+ echo "my_external_fact=true"

Notice: /File[/opt/puppetlabs/puppet/cache/facts.d/external_fact.sh]/content: content changed '{md5}5f133e40e41936739c335f63ec44537f' to '{md5}a752548b79b45d178df35d9b585e85fe'
Info: Retrieving plugin

External Facts sind Facts, die nicht direkt in Ruby geschrieben wurden. Dies ist eine schöne Möglichkeit eigene Facts zu entwicklen, ohne das man Kenntnisse in der Sprache Ruby benötigt. Die Facts müssen ledeglich in einem beliebigen Modul im Ordner „facts.d“ abgelegt werden. Möglich sind dabei alle denkbaren Sprachen (*.sh, *.pl, …) sowie statische Textdateien.

Auch Structured Facts sind möglich, wenn das Script die Ausgabe z.B. im JSON Format zurückliefert.

In früheren Versionen von Puppet musste man die External Facts als Dateien händisch via File Resource auf die Systeme verteilen. Dies hat allerdings den großen Nachteil das der Fact erst ab dem zweiten Puppetlauf zur Verfügung steht.

Ab Puppet 4 kann dies noch problematischer werden werden. Puppet 4 verhält sich in vielen Dingen deutlicher strikter und zwingt den User zu sauberen Puppet Code. Der Zugriff auf eine undefinierte Variable etwa wirft einen Catalog Error beim kompilieren.
Das ist zum Beispiel der Fall, wenn man im Puppet Manifest auf einen vermeintlich verfügbaren externen Fact referenziert, der allerdings erst über Puppet ausgerollt werden muss. Damit hat man sich dann unter Puppet 4 einen Deadlock geschaffen.

Zu beachten ist natürlich das External Facts langsamer abgearbeitet werden als jene Facts, die direkt in Ruby geschrieben wurden. Der Grund hierfür ist das für jeden Fact der entsprechende Shell Interpreter als eigener Subprozess unterhalb von Puppet geöffnet werden muss.

SAN Zertifikate mit der Microsoft CA

Auch mit der Microsoft CA (Certificate Authority) ist es möglich SAN Zertifikate über das Webenrollment (auch bekannt als „certsrv“ bekannt) auszustellen.

Hierzu muss jedoch vorher einmalig über die CMD folgender Befehl (mit anschließendem Neustart des Services) auf dem Host mit der PKI Rolle ausgeführt werden.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Das Attribut für einen AltName kann direkt beim einreichen des Requests im Webinterface über das dafür vorhergesehene Feld angegeben werden. Der Syntax ist dabei wie folgt.

Microsoft CA - SAN Zertifikat

san:dns=name1.example.com[&dns=name2.example.com]

Ohne den vorherigen CMD Befehl wird der Parameter für einen AltName komplett ignoriert.

AWX – Ansible Tower wird OpenSource

Im Jahr 2015 hat RedHat das Unternehmen Ansible für rund 150 Millionen US Dollar übernommen, das seinerzeit die schlanke Automatisierungslösung Ansible ins Leben gerufen hat.

Anfang September wurde nun der Quellcode von der „Zentrale“ Ansible Tower als Projekt AWX (Ansible Works) unter die Apache License gestellt und auf GitHub gestellt. AWX dient fortan als Upstream für das weiterhin kostenpflichte Ansible Tower, wobei das Produkt nun den Namen gewechselt hat und jetzt als „Ansible Engine“ vermarktet wird.

Wie bei anderen RedHat Produkten (Satellite/Katello, OpenShift) wird die primäre, schnelle Entwicklung im Upstream liegen. Zu gegebener Zeit wird aus dem Code dann eine „stabile“ Version von Ansible veröffentlicht. Ansible Tower bleibt weiterhin kostenpflichtig, womit man sich aber auch den Support seitens RedHat einkaufen kann.

Das GitHub Repository von AWX befindet sich hier. Die Installation selbst ist natürlich auch via Ansible gescriptet. AWX lässt sich entweder in ein OpenShift Cluster oder auf einem einem Standalone Docker Host installieren.

Critical Citrix NetScaler Security Issue

Derzeit sind bei Citrix alle Firmware Downloads für den Citrix NetScaler Offline geschaltet. Hintergrund ist eine größere Sicherheitslücke, über die derzeit noch nicht viel bekannt ist.
Citrix hat bereits den Artikel CTX227893 veröffentlicht und alle Kunden via E-Mail informiert.

Due to an issue found in the builds, NetScaler 10.1, 10.5, 11.0, 11.1 and 12.0 builds are not available for download temporarily. Currently, we are testing replacement builds, which we expect to release in the coming days.

In the meantime, our guidance is to make sure your NetScaler is configured following our best practices guides found at https://support.citrix.com/article/CTX121149 and https://docs.citrix.com/content/dam/docs/en-us/netscaler/media/secure-deployment-guide/NetScaler-Secure-Deployment-Guide.pdf.

Aus dem Artikel lässt sich entnehmen das die Lücke wohl nur ausgenutzt werden kann wenn Zugriff auf eine NSIP oder SNIP (dann mit aktiviertem Management) besteht.

Betroffen sind alle bisher veröffentlichten NetScaler Versionen ab Version 10.1. Der Patch für die Lücke sollte hoffentlich noch in dieser Woche erscheinen.

Update vom 25.09.2017: der CTX-Artikel CTX227928 wurde veröffentlicht. Es handelt sich um ein Sicherheitsproblem, das einen Authentication Bypass auf das NetScaler Management ermöglicht (CVE-2017-14602).