=== 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 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 darauf auf tjener.intern 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 {{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

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