Puppet / Teil 1 – Installation und Einrichtung

Sobald euer Netzwerk mehr als nur eine handvoll Maschinen umfasst ist der Zeitpunkt gekommen, sich um eine Orchestrierungslösung Gedanken zu machen. Das Orchester ist dabei als Metapher zu betrachten. Der Dirigent (der Server) schwingt den Taktstock und die Trompeter und Geiger (die Clients) werden geleitet … so grob die Theorie. Es handelt sich also in aller Regel um ein Client-Server Modell. Nun stellt sich allerdings noch die Frage, was es auf dem Markt denn so gibt und was das geeignete ist?!
Prominente Vertreter findet man in aller Regel folgende: Ansible, Puppet, Chef.
Da man bei der Auswahl ja irgendwo anfangen muss, legt dieser Beitrag den Fokus auf Puppet und wird die Installation und Ersteinrichtung von Server und einem Client behandeln. In einem weiteren Beitrag werde ich dann den ersten Regelsatz (oder nach Puppet-Sprech auch “Manifest” genannt) erstellen sowie einen groben Überblick über die Inventarisierung von Clients geben.

Installation des Servers

Unser Prozedere beginnt nicht etwa mit der Installation eines Pakets, sondern mit dem setzen einer festen IP Adresse der Maschine, die den Puppet-Server spielen darf. Diese Einstellung kann beispielsweise euer Router für euch übernehmen (Stichwort: “always assign same IP-address”).
Ferner ist die korrekte Auflösung des Puppet-Server Hostnamens im Netzwerk von großer Wichtigkeit. Ansonsten verbindet sich alles erdenkliche an Puppet-Clients mit der Adresse, die sich hinter ebenjenem Zauberwort “puppet” verbirgt. Kann keine Ressource gefunden werden, fährt hinterher die Namensauflösung gegen die Wand. Abhilfe kann hier die Hauptkonfig-Datei der Clients schaffen, über die sich ein alternativer Hostname ansteuern lässt, aber dazu später mehr.
In unserem Fall wird zunächst einmal die Namensauflösung auf dem Server eingerichtet:

sudo nano /etc/hosts

Hier tragt ihr die (fixe) IP-Adresse des Puppetservers ein und den Namen puppet

Als nächstes geht es an die Installation. Unpraktischerweise ist die Software nicht in den Standard-Repos enthalten und möchte zunächst hinzugefügt werden.
Für APT-basierte Distros (Beispiel Ubuntu 20.04):

wget https://apt.puppetlabs.com/puppet7-release-focal.deb

Für YUM-basierte Distros (Beispiel Fedora 34):

wget https://yum.puppetlabs.com/puppet7-release-fedora-34.noarch.rpm

Falls eure Distribution nicht aufgelistet ist, sucht euch über die URL einfach den passenden Eintrag aus. Es mag sein, dass dort nur LTS releases aufgelistet sind. Orientiert euch in dem Fall an die letzte aktuelle Version eurer Distribution.

Nun installiert ihr das heruntergeladene Paket, aktualisiert den Cache eures Paketmanagers und installiert letztlich den Puppetserver:
Debian und co.:

sudo dpkg -i puppet7-release-focal.deb
sudo apt-get update -y
sudo apt-get install puppetserver

und Fedora und Konsorten:

sudo rpm -i puppet7-release-fedora-34.noarch.rpm
sudo yum makecache
sudo yum install puppetserver

Der Puppetserver ist installiert! Startet ihn nun und sorgt dafür, dass er es auch nach einem Neustart automatisch tut:

sudo systemctl start puppetserver.service
sudo systemctl enable puppetserver.service

Schaut sicherheitshalber nochmal nach, ob der Puppet-Dienst tatsächlich am leben ist:

sudo systemctl status puppetserver

Installation und Konfiguration des Clients

Nun nehmen wir uns einen Client zur Brust. Die Ehre wird in meinem Fall einer Xubuntu Installation zuteil, es eignet sich aber auch jede X-beliebige andere Linux Distribution. Puppet macht sogar vor Windows nicht halt (was aber in diesem Beitrag nicht behandelt wird).
Wie bereits beim Server zuvor, wird die Installationsquelle vom Hersteller bezogen, der Paketmanager Cache aktualisiert und Puppet, diesmal allerdings in der Client-Variante, installiert.
Für Debian … :

sudo dpkg -i puppet7-release-focal.deb
sudo apt-get update -y
sudo apt-get install puppet-agent

… und Fedora:

sudo rpm -i puppet7-release-fedora-34.noarch.rpm
sudo yum makecache
sudo yum install puppet-agent

Da die Installation uns ungnädigerweise keinen Eintrag in die PATH Variable setzt, übernehmen wir das im Anschluß noch:

sudo ln -s /opt/puppetlabs/bin/puppet /usr/bin/puppet

Die Agentensoftware ist nun einsatzbereit. Wie eingangs erwähnt funkt sie Standardmäßig an das Ziel puppet. Dies lässt sich in der “/etc/puppetlabs/puppet/puppet.conf” anpassen. Legt hier die Kategorie [main] an und benennt darunter den anzusprechenden Puppet-Server samt fqdn. In unserem Fall “puppetserver.fritz.box”:

sudo nano /etc/puppetlabs/puppet/puppet.conf

Falls ihr euch nicht sicher seid, welcher der richtige fqdn-Servername ist, lässt sich dies auf dem Puppetserver mit dem Befehl “puppetserver ca list –all” nachschlagen.

Schlußendlich haben wir die Voraussetzungen geschaffen, um mit dem Puppet-Client eine Zertifikatsanfrage zu erzeugen und diese an unseren Puppetserver zu senden.

Führt folgenden Befehl auf der Client-Seite aus:

sudo puppet agent --test

Der Agent bittet uns auf der Gegenseite sein Zertifikat zu signieren.
Diese Anfrage möchten wir nun auf der Serverseite in Empfang nehmen und bearbeiten:

Führt folgenden Befehl auf der Server-Seite aus:

sudo puppetserver ca sign --all

Sieht die Ausgabe in etwa so aus

Steht die Verbindung zwischen Server und Client! Nur wie geht es weiter?

Da der Puppet-Agent ein eigenständig agierender Dienst ist, der seinerseits den Server kontaktiert und um neue Regeln bittet, müssen wir von ihm aus auch die Software steuern.
Eine bewährte und einfach einzurichtende Methode ist dabei der Cronjob.

Auf dem Client:

echo "*/15 * * * * root puppet agent --test" > /etc/cron.d/puppet

Dieser Einzeiler lässt den Puppet-Client alle 15 Minuten loslaufen und sich die neuesten Regeln vom Puppet-Server holen.

Alles klar, das solls fürs erste gewesen sein. Die grundsätzliche Installation und Einrichtung des Puppet-Servers sowie die Einrichtung eines Clients wurde durchgeführt.
Die Fortsetzung folgt im nächsten Artikel und soll ein erstes Manifest behandeln und auf die Inventarisierung der Clients eingehen.