|
Größe: 4213
Kommentar:
|
Größe: 4325
Kommentar:
|
| Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
| Zeile 2: | Zeile 2: |
<<TableOfContents(4)>> |
|
| Zeile 17: | Zeile 19: |
| Server-seitig konfigurieren wir die Puppet-Agents via {{tjener.intern}} ({{/etc/puppet/manifests/site.pp}}). | Server-seitig konfigurieren wir die Puppet-Agents via {{{tjener.intern}}} ({{{/etc/puppet/manifests/site.pp}}}). |
| Zeile 19: | Zeile 21: |
| Der ganze Ordner {{/etc/puppet}} liegt im Git: | Der ganze Ordner {{{/etc/puppet}}} liegt im Git: |
| Zeile 27: | Zeile 29: |
| Änderungen am puppet.<SCHULE>.git werden auf dem eigenen Rechner des Admins gemacht. Von | Änderungen am {{{puppet.<SCHULE>.git}}} werden auf dem eigenen Rechner des Admins gemacht. Von |
| Zeile 30: | Zeile 32: |
| Die Änderungen werden darauf auf tjener.intern aktualisiert, via: | Die Änderungen werden daraufhin auf {{{tjener.intern}}} der entsprechenden Schule aktualisiert, via: |
| Zeile 44: | Zeile 46: |
| 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: | 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: |
| Zeile 62: | Zeile 64: |
| Dort sollte also der Rechner <myhost>.intern nun gelistet sein. | Dort sollte also der Rechner {{{<myhost>.intern}}} nun gelistet sein. |
| Zeile 72: | Zeile 74: |
| ==== Erster Puppet-Lauf auf Puppet-Client ==== | ==== Erster Puppet-Lauf auf Puppet-Client ==== |
| Zeile 74: | Zeile 76: |
| Um den ersten Puppet-Agent Durchlauf auf dem Client zu triggern, muss nochmal der Puppet-Agent mit der Option {{--test}} aufgerufen werden: | Um den ersten Puppet-Agent Durchlauf auf dem Client zu triggern, muss nochmal der Puppet-Agent mit der Option {{{--test}}} aufgerufen werden: |
Workstation Management via Puppet
Inhaltsverzeichnis
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 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
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