Unterschiede zwischen den Revisionen 9 und 19 (über 10 Versionen hinweg)
⇤ ← Revision 9 vom 2016-12-15 22:07:27 →
Größe: 4325
Autor: MikeGabriel
Kommentar:
← Revision 19 vom 2016-12-20 14:13:04 → ⇥
Größe: 4981
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 ==
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 24: Zeile 24:
$ sudo -i
# cd /etc
# mv puppet puppet.orig
# 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 26: Zeile 35:
Zeile 43: Zeile 53:
=== DNS-Eintrag: puppet.intern ===
Zeile 44: Zeile 55:
==== Installation eines Puppet-Agents (auf <myhost>.intern) ==== Die Puppet Agents suchen per default nach einem Host mit Namen {{{puppet.<DOMAIN>}}}, d.h. im Fall von Debian Edu Systemen nach {{{puppet.intern}}}. Dieser Eintrag muss als CNAME in der DNS-Konfiguration von TJENER via GOsa² hinterlegt werden.

=== Installation eines Puppet-Agents (auf <myhost>.intern) ===
Zeile 54: Zeile 67:
==== Anbindung eines Puppet-Agents an den Puppet-Master ==== === Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern) ===
Zeile 58: Zeile 71:
Mit diesem Befehl werden alle (neuen) Clients gelistet: Auf dem Puppet-Master (TJENER): Mit diesem Befehl werden alle (neuen) Clients gelistet:
Zeile 74: Zeile 87:
==== Erster Puppet-Lauf auf Puppet-Client ====
Zeile 76: Zeile 88:
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 104:
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 106:
==== Weiter Hinweise ==== === Weiter Hinweise zu Hostnamen von Clients ===
Zeile 90: Zeile 112:
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 114:
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 127:

==== 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. DNS-Eintrag: puppet.intern
    4. Installation eines Puppet-Agents (auf <myhost>.intern)
    5. Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern)
    6. Puppet-Master: Verwaltung der Cert-Request-Queue (auf tjener.intern)
    7. Erster Puppet-Lauf auf Puppet-Client (auf <myhost>.intern)
    8. 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.orig
# 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

DNS-Eintrag: puppet.intern

Die Puppet Agents suchen per default nach einem Host mit Namen puppet.<DOMAIN>, d.h. im Fall von Debian Edu Systemen nach puppet.intern. Dieser Eintrag muss als CNAME in der DNS-Konfiguration von TJENER via GOsa² hinterlegt werden.

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)