Installation von Puppet (Teil 2) – Agent-Installation unter Debian 9.5

Nachdem wir im ersten Teil der Serie mit der Installation des Puppet Masters begonnen haben, fahren wir nun mit der Installation des ersten Clients fort. Ich habe hierzu eine VM installiert mit einem Debian 9. Ziel soll es sein, dass der Client über den Puppet-Agent verwaltet und konfiguriert werden kann.

Download des Paketquellen

Damit der Agent installiert werden kann, muss auf dem System ebenfalls eine neue Paketquelle heruntergeladen und hinzugefügt werden.

wget https://apt.puppetlabs.com/puppet6-release-stretch.deb

Nach dem Download können wir das Paket installieren und ein Update der Paketquellen durchführen.

dpkg -i puppet6-release-stretch.deb
apt update

Nun kann die Installation durchgeführt werden

apt install puppet

Nun können wir den Agenten starten sowie einen Autostart einrichten, damit der Server jedes Mal nach einem System-Neustart auch automatisch gestartet wird.

systemctl start puppet
systemctl enable puppet

Version festpinnen

Wenn man (wie auf dem Master-Server auch) die Version des Agenten festpinnen möchte, kann und sollte dies ebenfalls auf dem Client-System machen, da sonst der Client gegenüber dem Master-Server versionstechnisch aus dem Ruder läuft. Das wäre übrigens auch eine gute Aufgabe für Puppet selbst nach der Installation 😉

puppet help | tail -n 1
nano /etc/apt/preferences.d/00-puppet.pref

Hier kommt der gleiche Eintrag hinein wie auch auf dem Puppet Master

Package: puppet puppet-common puppetmaster-passenger
Pin: version 4.8*
Pin-Priority: 501

Lokale Konfiguration

Nach der Installation fragt der Client per DNS nach dem Namen puppet. Wird dieser korrekt aufgelöst, meldet er sich auch schon direkt am Master und möchte hier akzeptiert und aufgenommen werden. Wird ein anderer Name verwendet oder das DNS ist (aus Gründen TM)  nicht änderbar, kann eine lokale Konfiguration in der Datei

/etc/puppet/puppet.conf

durchgeführt werden. Hier muss im Bereich agent eine neue Zeile mit dem Namen des Servers eingeführt werden, weiterhin kann der Bereich master komplett entfernt werden.

Vorher
[main]
ssldir = /var/lib/puppet/ssl

[master]
vardir = /var/lib/puppet
cadir  = /var/lib/puppet/ssl/ca
dns_alt_names = puppet
Nachher
[main]
ssldir = /var/lib/puppet/ssl

[agent]
server=servername.domain.local

Danach sollte der Client neugestartet werden.

systemctl restart puppet

Die Signierung und Autorisierung des Clients

Der Client meldet sich nun am Server (zumindest wäre es toll, wenn er das jetzt tun würde) und kann an diesem autorisiert werden.

Wichtig!

Wechsel auf den Puppet Master-Server

Wie schon vorher können wir uns alle Zertifikate anschauen, hier sollte nun ein neues Zertifikat auftauchen.

puppet cert list -all

Wir sehen anhand dem fehlenden “+” vor dem Server bzw. dem Zertifikat, dass diesem aktuell nicht vertraut wird und es keine Gegenzeichnung von unserem Puppet Master gibt. Wenn man sich übrigens nur die offenen Anfragen anschauen möchte, geht dies am einfachsten ohne die Angabe von “-all“.

Den Client bestätigen können wir mit

puppet cert sign server.domain.local

bestätigen. Nun sind die beiden Server miteinander verbunden und es kann eine Konfiguration erfolgen. Um diesen Teil kümmern wir uns im dritten Teil der kleinen Serie zu Puppet.


Sie benötigten persönliche Unterstützung oder haben nicht die richtige Lösung für Ihr Problem gefunden?

Dieser Blog wird von mir, Jan Kappen, in seiner Freizeit betrieben, hier beschreibe ich Lösungen für Probleme aller Art oder technische Anleitungen mit Lösungsansätzen.

Die berufliche Unabhängigkeit

Ich bin seit Januar 2020 vollständig selbstständig und habe meine eigene Firma gegründet, die Building Networks mit Sitz in Winterberg im schönen Sauerland. Hier stehe ich als Dienstleister gerne für Anfragen, Support oder Projekte zur Verfügung.

Die Firma Building Networks bietet Ihnen:

  • Hilfe und Support per Telefon, Fernwartung oder persönlich vor Ort
  • Projekt-Unterstützung
  • Ausgezeichnete Kompetenz zu den Themen
    • Microsoft Hyper-V
    • Microsoft Failover Clustering & HA
    • Storage Spaces Direct (S2D) & Azure Stack HCI
    • Veeam Backup & Recovery
    • Microsoft Exchange
    • Microsoft Exchange Hybrid Infrastruktur
    • Microsoft Active Directory
    • Microsoft Office 365
    • Ubiquiti
    • 3CX VoIP PBX
    • Fortinet Network Security
    • Baramundi Software
    • ...

Ich freue mich über Ihren Kontakt, weitere Informationen finden Sie auf der Webseite meiner Firma unter Building-Networks.de

Jan

Jan Kappen arbeitet seit 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Von September 2018 bis Dezember 2019 war Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. Im Januar 2020 hat er den Sprung in die Selbstständigkeit gewagt und ist seitdem Geschäftsführer der Firma Building Networks in Winterberg. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Ein Kommentar:

  1. Pingback:Dynamische Palo Alto Firewall-Regeln basierend auf Minemeld - Teil 1 - Jans Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert