Puppet ist eine Möglichkeit, wie ich zentralisiert ein Management von Windows, Linux und auf Wunsch auch Mac-Systeme durchführen kann und hat sich neben Tools wie Chef, Ansible und Saltstack seit vielen Jahren am Markt etabliert. Mit Hilfe von Puppet kann nahezu alles erreicht werden: Die Installation von Software, die Konfiguration von Systemen, die Definition von einem gewünschten Zustand, ….
Grundsätzlich gibt es einen oder mehrere Puppet Master-Server, auf dem die Konfiguration gehalten und betrieben wird. Auf den zu verwaltenden Systemen wird ein Puppet Agent installiert, der mit dem Master-Server spricht und nach einer Konfiguration fragt. Ist solch eine Konfiguration vorhanden (z.B. soll immer ein gewünschtes Paket installiert sein), setzt der Agent die gewünschte Konfiguration um. Befindet sich der Server bereits im gewünschten Zustand, wird nichts gemacht. Ändert sich ein Paket, die Version von einem Paket oder es kommt ein zweites hinzu, kann dies zentral auf dem Master konfiguriert werden und nach kurzer Zeit befinden sich alle Server im gewünschten Zustand.
In dieser Blogpost-Reihe beschreibe ich die Installation des Master-Servers, die Installation von dem Puppet-Agent auf einem Demo-System sowie eine Beschreibung, wie man mit der Erstellung und Nutzung der ersten Ressourcen beginnen kann.
Installation des Puppet Master Server
Zur Installation laden wir uns die benötigte Paket-Quelle von apt.puppetlabs.com herunter.
wget https://apt.puppetlabs.com/puppet6-release-stretch.deb
Nach dem Download installieren wir das Paket und aktualisieren unsere Paketquellen.
dpkg -i puppet6-release-stretch.deb
apt update
Nach dem Upate können wir den Puppet Master installieren.
apt install puppetmaster-passenger
Durch die Installation von dem Passenger-Paket wird direkt Apache2 als Webserver mit installiert.
Version statisch halten
Wenn man möchte, kann man die Version seiner Puppet-Installation beibehalten. Dies hat den Vorteil, dass ein Update nicht die gesamte Konfiguration zerlegt und man das alles aus einem Backup wiederherstellen muss. Soll solch ein festpinnen auf die gerade installierte Version gemacht werden, kann dies in den Einstellungen des apt-Paketmanagers gemacht werden. Dazu muss man die aktuelle Version auslesen
puppet help | tail -n 1
Nun muss man unter /etc/apt/preferences.d eine neue Datei anlegen, die apt dazu zwingt, nur die gewünschte Paket-Version zu installieren.
nano /etc/apt/preferences.d/00-puppet.pref
Hier muss der folgende Inhalt eingetragen werden:
Package: puppet puppet-common puppetmaster-passenger
Pin: version 4.8*
Pin-Priority: 501
Optional: Zertifikat mit alternativen Namen erstellen
Bei der Installation wird automatisch ein Zertifikat erstellt, welches unter /var/lib/puppet/ssl abgelegt wird.
Möchte man noch alternative Namen in seinem Zertifikat verwenden, müssen die Zertifikate entfernt werden, danach muss die Konfiguration angepasst werden.
rm -rf /var/lib/puppet/ssl
nano /etc/puppet/puppet.conf
Der Eintrag dns_alt_names könnte noch mit weiteren Namen ergänzt werden.
Wäre dies notwendig, können die Zertifikate danach wieder neu erstellt werden. Hierzu müsste der Befehl
puppet master --verbose --no-daemonize
aufgerufen werden. Ich in meinem Fall belasse es erstmal bei dem Standard-Namen und Zertifikat. Möchte man sich den aktuellen Stand der Zertifikate (sowohl vom Master-Server als auch von den Puppet-Clients) anschauen, geht dies immer mit dem Befehl
puppet cert list -all
Wenn der Parameter -all nicht genutzt wird, werden lediglich ausstehende Client-Zertifikate angefragt, die noch nicht für eine Verbindung mit dem Master autorisiert wurden. Befindet sich ein “+” vor dem Zertifikat, ist dies ein bekannter und vertrauenswürdiges Zertifikat.
Besitzt der Master-Server ein Zertifikat, kann dies im weiteren Verlauf für die Signierung von Puppet-Clients genutzt werden.
Eine weitere Beschreibung der Haupt-Konfigurationsdatei puppet.conf befindet sich hier: Config files: The main config file (puppet.conf)
Wir sind nun an dieser Stelle erst einmal mit der Konfiguration und Installation des Puppet Masters fertig, weiter geht es im zweiten Beitrag mit der Installation des Clients.
Pingback:Dynamische Palo Alto Firewall-Regeln basierend auf Minemeld - Teil 1 - Jans Blog