=== Workstation Management via Puppet ===

<<TableOfContents(4)>>

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:

{{{
$  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 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.

==== 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