4293
Kommentar:
|
4479
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 1: | Zeile 1: |
=== Workstation Management via Puppet === | == Workstation Management via Puppet == |
Zeile 7: | Zeile 7: |
==== Installation des Puppet-Masters (auf tjener.intern) ==== | === Installation des Puppet-Masters (auf tjener.intern) === |
Zeile 17: | Zeile 17: |
==== Puppet-Konfiguration des Puppet-Masters ==== | === Puppet-Konfiguration des Puppet-Masters (auf tjener.intern) === |
Zeile 44: | Zeile 44: |
==== Installation eines Puppet-Agents (auf <myhost>.intern) ==== | === Installation eines Puppet-Agents (auf <myhost>.intern) === |
Zeile 46: | 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 54: | Zeile 54: |
==== Anbindung eines Puppet-Agents an den Puppet-Master ==== | === Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern) === |
Zeile 58: | Zeile 58: |
Mit diesem Befehl werden alle (neuen) Clients gelistet: | Auf dem Puppet-Master (TJENER): Mit diesem Befehl werden alle (neuen) Clients gelistet: |
Zeile 74: | Zeile 74: |
==== Erster Puppet-Lauf auf Puppet-Client ==== | |
Zeile 76: | Zeile 75: |
Um den ersten Puppet-Agent Durchlauf auf dem Client zu triggern, muss nochmal der Puppet-Agent mit der Option {{{--test}}} aufgerufen werden: | === 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: |
Zeile 82: | Zeile 91: |
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. | 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. |
Zeile 84: | Zeile 93: |
==== Weiter Hinweise ==== | === Weiter Hinweise zu Hostnamen von Clients === |
Zeile 90: | Zeile 99: |
Einrichtung von Puppet-Agent mit Hostname {{notebook.intern}} (verbunden über LAN). Das Zertifikat wurde für diesen Rechner ausgestellt. | Einrichtung von Puppet-Agent mit Hostname {{{notebook.intern}}} (verbunden über LAN). Das Zertifikat wurde für diesen Rechner ausgestellt. |
Zeile 92: | Zeile 101: |
Wenn man jetzt diesen Rechner via WLAN verbindet, wechselt der Rechner ($irgendwann) seinen Hostnamen auf {{notebook-w.intern}} (so wie in LDAP konfiguriert). | Wenn man jetzt diesen Rechner via WLAN verbindet, wechselt der Rechner ($irgendwann) seinen Hostnamen auf {{{notebook-w.intern}}} (so wie in LDAP konfiguriert). |
Zeile 105: | Zeile 114: |
==== 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 }}} |
Workstation Management via Puppet
Inhaltsverzeichnis
-
Workstation Management via Puppet
- Installation des Puppet-Masters (auf tjener.intern)
- Puppet-Konfiguration des Puppet-Masters (auf tjener.intern)
- Installation eines Puppet-Agents (auf <myhost>.intern)
- Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern)
- Puppet-Master: Verwaltung der Cert-Request-Queue (auf tjener.intern)
- Erster Puppet-Lauf auf Puppet-Client (auf <myhost>.intern)
- Weiter Hinweise zu Hostnamen von Clients
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