Unterschiede zwischen den Revisionen 4 und 16 (über 12 Versionen hinweg)
⇤ ← Revision 4 vom 2016-12-15 22:02:58 →
Größe: 4213
Autor: MikeGabriel
Kommentar:
← Revision 16 vom 2016-12-20 14:08:19 → ⇥
Größe: 4696
Autor: MikeGabriel
Kommentar:
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 ==

<<TableOfContents(4)>>
Zeile 5: Zeile 7:
==== Installation des Puppet-Masters (auf tjener.intern) ==== === Installation des Puppet-Masters (auf tjener.intern) ===
Zeile 15: Zeile 17:
==== Puppet-Konfiguration des Puppet-Masters ==== === Puppet-Konfiguration des Puppet-Masters (auf tjener.intern) ===
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:

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

Die ITZkS-Admins können diese Repository mit Schreibrechten via SSH clonen:
Zeile 25: Zeile 36:
Zeile 27: Zeile 39:
Ä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 42:
Die Änderungen werden darauf auf tjener.intern aktualisiert, via: Die Änderungen werden daraufhin auf {{{tjener.intern}}} der entsprechenden Schule aktualisiert, via:
Zeile 42: Zeile 54:
==== Installation eines Puppet-Agents (auf <myhost>.intern) ==== === Installation eines Puppet-Agents (auf <myhost>.intern) ===
Zeile 44: Zeile 56:
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 52: Zeile 64:
==== Anbindung eines Puppet-Agents an den Puppet-Master ==== === Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern) ===
Zeile 56: Zeile 68:
Mit diesem Befehl werden alle (neuen) Clients gelistet: Auf dem Puppet-Master (TJENER): Mit diesem Befehl werden alle (neuen) Clients gelistet:
Zeile 62: Zeile 74:
Dort sollte also der Rechner <myhost>.intern nun gelistet sein. Dort sollte also der Rechner {{{<myhost>.intern}}} nun gelistet sein.
Zeile 72: Zeile 84:
==== Erster Puppet-Lauf auf Puppet-Client ====
Zeile 74: Zeile 85:
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 80: Zeile 101:
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 82: Zeile 103:
==== Weiter Hinweise ==== === Weiter Hinweise zu Hostnamen von Clients ===
Zeile 88: Zeile 109:
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 90: Zeile 111:
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 103: Zeile 124:

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

  1. Workstation Management via Puppet
    1. Installation des Puppet-Masters (auf tjener.intern)
    2. Puppet-Konfiguration des Puppet-Masters (auf tjener.intern)
    3. Installation eines Puppet-Agents (auf <myhost>.intern)
    4. Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern)
    5. Puppet-Master: Verwaltung der Cert-Request-Queue (auf tjener.intern)
    6. Erster Puppet-Lauf auf Puppet-Client (auf <myhost>.intern)
    7. 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: 

$ sudo -i
# cd /etc
# mv puppet puppet.org
# 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

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

IT-Zukunft Schule: Technik/Wartung/Puppet (zuletzt geändert am 2018-09-10 14:48:01 durch BenjaminSchlueter)