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 (auf tjener.intern)

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

Der ganze Ordner /etc/puppet liegt im Git:

$ sudo -i
# cd /etc
# mv puppet puppet.orig
# git clone https://code.it-zukunft-schule.de/cgit/puppet.<SCHULE> ./puppet

Die ITZkS-Admins können diese Repository mit Schreibrechten via SSH clonen:

$  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

DNS-Eintrag: puppet.intern

Die Puppet Agents suchen per default nach einem Host mit Namen puppet.<DOMAIN>, d.h. im Fall von Debian Edu Systemen nach puppet.intern. Dieser Eintrag muss als CNAME in der DNS-Konfiguration von TJENER via GOsa² hinterlegt werden.

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

Auf den mit Puppet zu wartenden Rechnern (Clients) wird dann der Puppet-Agent installiert. 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 (auf tjener.intern)

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.

Auf dem Puppet-Master (TJENER): 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.

Puppet-Master: Verwaltung der Cert-Request-Queue (auf tjener.intern)

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

Erster Puppet-Lauf auf Puppet-Client (auf <myhost>.intern)

Um den ersten Puppet-Agent Durchlauf auf dem Client zu triggern, muss nochmal auf dem Client 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.

Anpassungsbeispiele für Puppet

Anpassungen an den Arbeitsanweisungen, welche der Puppet-Master auf dem Tjener ausführen und anhand derer Änderungen/Aktionen auf den Puppet-Clients vorgenommen/gestartet werden sollen werden im Git in der Datei ../puppet.SCHULE/manifests/site.pp gesetzt.

Bsp.:

Für einen Puppet-Client ("Node") soll eine bestimmte Version einer Software installiert werden.

Zuerst muss der Vorgang definiert werden (Beispiel mit der Software idle3:

class software {
    package { 'idle3':
        ensure => '3.4.2-2',
        require => Exec['apt-get update'],
    }
}

Die Zeile require => Exec['apt-get update'] sorgt hier dafür, dass vor dem Versuch, die Software mit der gewünschten Versionsnummer zu installieren ein apt-get update ausgeführt wird, um die Wahrscheinlichkeit zu verringern, dass die Installation fehlschlägt, weil der Client das Softwarepacket nicht kennt. (Natürlich muss trotzdem darauf geachtet werden, dass die Packetquelle für die zu installierende Software bekannt ist.)

Nun, dass die auszuführende Aufgabe für Puppet definiert ist, muss sie noch dem korrekten Client zugeordnet werden.

Der korrekte Client muss erstellt (oder wenn schon vorhanden, muss das folgende dort korrekt eingetragen) werden.

node client.name inherits "all_hosts" {
    class { 'software': }
}

Jetzt kann Puppet dem korrekten Client die korrekte Aufgabe zuordnen.

Weiter Hinweise zu Hostnamen von Clients

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 notebook.intern (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 notebook-w.intern (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