Workstation Management via Puppet

Zur einheitlichen Konfiguration und Software-Ausstattung bei Workstations wird die Software puppet verwendet. Die Software auf dem Steuerungs-Server wird als Puppet-Master bezeichnet. Die Software auf den verwalteten Maschinen ist der Puppet-Agent.

Installation des Puppet-Masters (auf tjener.intern)

Die Installation des Puppet-Master-Dienstes erfolgt auf dem jeweiligen TJENER einer Schule.

$ sudo apt-get install puppetmaster

Die Puppet-Konfigurationen der betreuten Schulen werden auf https://code.it-zukunft-schule.de verwaltet / gepflegt: https://code.it-zukunft-schule.de/cgit/

Puppet-Konfiguration des Puppet-Masters

Server-seitig konfigurieren wir die Puppet-Agents via tjener.intern (/etc/puppet/manifests/site.pp).

Der ganze Ordner /etc/puppet liegt im Git:

$  git clone gitolite@code.it-zukunft-schule.de:puppet.<SCHULE>.git

Das Git Repository ist public. Schreibzugriff haben alle Mitarbeiter.

Änderungen am puppet.<SCHULE>.git werden auf dem eigenen Rechner des Admins gemacht. Von dort wird gepushed ins Git.

Die Änderungen werden daraufhin auf tjener.intern der entsprechenden Schule aktualisiert, via:

$ ssh-add (einmalig pro Session auf dem eigenen Rechner)
$ ssh -lroot tjener.<schule> -A
# cd /etc/puppet
# git pull
### falls git pull fehlschlägt... (Vorsicht, verwirft lokale Änderungen)
# git reset --hard && git pull

Installation eines Puppet-Agents (auf <myhost>.intern)

Auf den Puppet-Agents wird das Tool Puppet installiert und eine erste Verbindung zum Puppet-Master wird aufgebaut. Es erfolgt hierbei noch keine Konfigurations-Änderung auf dem Client:

$ sudo apt-get install puppet
$ sudo puppet agent --test
$ sudo puppet agent --enable

Anbindung eines Puppet-Agents an den Puppet-Master

Nach erster Kontaktaufnahme eines Puppet-Agents mit dem Puppet-Master, muss das Client-Zertifikat signiert werden. Dadurch wird der Puppet-Agent gegenüber dem Puppet-Master registriert und authorisiert.

Mit diesem Befehl werden alle (neuen) Clients gelistet:

$ sudo puppet cert --list

Dort sollte also der Rechner <myhost>.intern nun gelistet sein.

Mit

$ sudo puppet cert --sign <myhost>.intern

wird der Puppet-Agent des Clients dann authorisiert.

Erster Puppet-Lauf auf Puppet-Client

Um den ersten Puppet-Agent Durchlauf auf dem Client zu triggern, muss nochmal der Puppet-Agent mit der Option --test aufgerufen werden:

$ sudo puppet agent --test

Eine einfach Überprüfung, ob der Lauf erfolgreich war: Es sollten die SSH pubkeys der ITZkS-Admins nach /root/.ssh/authorized_keys deployed worden sein.

Weiter Hinweise

Notebooks mit LAN/WLAN NIC wechseln ihre Hostname (via DHCP). Puppet ist da recht strikt. Der Hostname muss dem CN Feld im Zertifikat entsprechen.

Beispiel:

Einrichtung von Puppet-Agent mit Hostname (verbunden über LAN). Das Zertifikat wurde für diesen Rechner ausgestellt.

Wenn man jetzt diesen Rechner via WLAN verbindet, wechselt der Rechner ($irgendwann) seinen Hostnamen auf (so wie in LDAP konfiguriert).

Das ist suboptimal, denn ab jetzt funktioniert der Puppet-Agent nicht mehr (weil Hostname != CN Feld im Zertifikat).

D.h.

• Zertifikate immer ausstellen auf <myhost>.intern (nicht <myhost>-w.intern)

• häufigste Verbindungsart ermitteln, z.Bsp. via WiFi

  • - in LDAP: <myhost>.intern -> MAC-Adresse der WiFi-NIC hinterlegen - in LDAP: <myhost>-lan.intern -> MAC-Adresse von eth0 hinterlegen (RJ-45)

• häufigste Verbindungsart z.Bsp. LAN:

  • - in LDAP: <myhost>.intern -> MAC-Adresse von eth0 hinterlegen (RJ-45) - in LDAP: <myhost>.intern-w -> MAC-Adresse der WiFi-NIC hinterlegen

Puppet-Master: Verwaltung der Cert-Request-Queue

Falls man mal einen Rechner mit puppet agent --test registriert, aber der Hostname nicht ok ist, kann man diese Rechner später mit folgendem Befehl aus der certrequest Queue wieder entfernen:

$ sudo puppet ca destroy <mybadhostname>.intern