4205
Kommentar:
|
← Revision 31 vom 2018-09-10 14:48:01 ⇥
10248
|
Gelöschter Text ist auf diese Art markiert. | Hinzugefügter Text ist auf diese Art markiert. |
Zeile 1: | Zeile 1: |
=== Workstation Management via Puppet === | #acl AdminGroup:read,write,delete,revert,admin All:read <<TableOfContents(4)>> == Workstation Management via Puppet == |
Zeile 5: | Zeile 11: |
==== Installation des Puppet-Masters (auf tjener.intern) ==== | === Installation des Puppet-Masters (auf tjener.intern) === |
Zeile 13: | Zeile 19: |
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: |
Die Puppet-Konfigurationen der betreuten Schulen werden auf https://code.it-zukunft-schule.de verwaltet / gepflegt: https://code.it-zukunft-schule.de/cgit/ Hinweis: Eine kurze Anleitung für das Umstellen von Puppet 3.x auf Puppet 4.x auf einem jessie TJENER findet sich [[https://wiki.it-zukunft-schule.de/Technik/Wartung/PuppetUpgradeTo4.x|hier]]. === Puppet-Konfiguration des Puppet-Masters (auf tjener.intern) === Server-seitig konfigurieren wir die Puppet-Agents via {{{tjener.intern}}} ({{{/etc/puppet/code/environments/production/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: |
Zeile 25: | Zeile 43: |
Zeile 27: | Zeile 46: |
Ä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 49: |
Die Änderungen werden darauf auf tjener.intern aktualisiert, via: | Die Änderungen werden daraufhin auf {{{tjener.intern}}} der entsprechenden Schule aktualisiert, via: |
Zeile 41: | Zeile 60: |
==== 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: |
=== 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: |
Zeile 52: | Zeile 74: |
==== Anbindung eines Puppet-Agents an den Puppet-Master ==== | === Anbindung eines Puppet-Agents an den Puppet-Master (auf tjener.intern) === |
Zeile 56: | Zeile 78: |
Mit diesem Befehl werden alle (neuen) Clients gelistet: | Auf dem Puppet-Master (TJENER): Mit diesem Befehl werden alle (neuen) Clients gelistet: |
Zeile 62: | Zeile 84: |
Dort sollte also der Rechner <myhost>.intern nun gelistet sein. | Dort sollte also der Rechner {{{<myhost>.intern}}} nun gelistet sein. |
Zeile 72: | Zeile 94: |
==== 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: |
=== 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 111: |
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 ==== |
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. === Anpassungsbeispiele für Puppet === Anpassungen an den Arbeitsanweisungen, welche der Puppet-Master auf dem Tjener ausführen und anhand derer Änderungen/Aktionen auf den Puppet-Clients vorgenommen/gestartet werden sollen werden im Git in der Datei {{{../puppet.SCHULE/code/environments/production/manifests/site.pp}}} gesetzt. '''Hinweis:''' Ab Version 4.8.x von Puppet dürfen keine Bindestriche mehr in den Klassen-Bezeichnungen vorkommen. Also würde {{{itzks-systems-workstation}}} nicht korrekt sein und müsste umgeändert werden in {{{itzks_systems_workstation}}}. ==== Für einen Puppet-Client ("Node") soll eine bestimmte Version einer Software installiert werden ==== Zuerst muss der Vorgang definiert werden (Beispiel mit der Software {{{idle3}}}: {{{ class software { package { 'idle3': ensure => '3.4.2-2', require => Exec['apt-get update'], } } }}} Die Zeile {{{require => Exec['apt-get update']}}} sorgt hier dafür, dass vor dem Versuch, die Software mit der gewünschten Versionsnummer zu installieren ein {{{apt-get update}}} ausgeführt wird, um die Wahrscheinlichkeit zu verringern, dass die Installation fehlschlägt, weil der Client das Softwarepacket nicht kennt. (Natürlich muss trotzdem darauf geachtet werden, dass die Packetquelle für die zu installierende Software bekannt ist.) Nun, dass die auszuführende Aufgabe für Puppet definiert ist, muss sie noch dem korrekten Client zugeordnet werden. Der korrekte Client muss erstellt (oder wenn schon vorhanden, muss das folgende dort korrekt eingetragen) werden. '''Hinweis:''' Ab Version 4.8.x von Puppet können Klassen nicht mehr via {{{inherits}}} weitervererbt werden. {{{ node client.name { class { 'software': } } }}} Jetzt kann Puppet dem korrekten Client die korrekte Aufgabe zuordnen. Hinweis: Dieses Beispiel ist als Definitionsbeispiel zu sehen, da eigentliche Softwareverwaltung durch die {{{itzks-systems-*}}}-Pakte vorgenommen wird. ==== Ein bestimmtes Software-Paket soll immer auf dem neusten Stand gehalten werden ==== Beispiel anhand des Paketes {{{itzks-systems-workstation}}}: Zuerst muss die auszuführende Aufgabe für Puppet definiert werden: {{{ class itzks_systems_workstation { package { 'itzks-systems-workstation': ensure => 'latest', } } }}} Diese Aufgabe muss nun den gewünschten Clients zugewiesen werden: {{{ node client.name { class { 'itzks-systems-workstation': } } }}} Puppet wird nun sicherstellen, dass das Paket {{{itzks-systems-workstation}}} auf dem Client "client.name" immer auf dem neusten Stand ist. Dies ist besonders hilfreich, wenn in dem Software-Paket Software hinzugefügt oder entfernt wird; mit {{{unattendes Upgrades}}} ist nur ein Aktuell-Halten gleichbleibender Software-Pakete nötig. ==== Für einen Puppet-Client ("Node") soll eine bestimmte Datei angelegt werden ==== Beispiel anhand der Datei {{{fsautoresizetab}}}: Zuerst muss die auszuführende Aufgabe angelegt werden: {{{ class fsautoresizetab { file { 'fsautoresizetab': path => '/etc/', ensure => present, replace => 'no', source => '/usr/share/debian-edu-config/fsautoresizetab', } } }}} Die Aufgabe ist so geschrieben, dass {{{fsautoresizetab}}} einmalig angelegt wird, wenn die Datei nicht vorhanden ist, danach allerdings nicht wieder neu erstellt wird, solange die Datei vorhanden ist. Als Quelle der Datei wird die mit den {{{itzks-systems-*}}}-Paketen verteilte Datei {{{/usr/share/debian-edu-config/fsautoresizetab}}} genutzt. Nun wird die auszuführend Aufgabe dem gewünschten Client zugewiesen: {{{ node client.name { class { 'fsautoresizetab': } } }}} ==== Für einen Puppet-Client ("Node") sollen Teile einer bestimmten Datei geändert werden ==== Beispiel anhand von Anpassungen an der Datei {{{fsautoresizetab}}}: Zuerst muss die auszuführende Aufgabe definiert werden (hier für eine Anpassunge an der gewünschten Partitionsvergrößerung für {{{/var}}}): {{{ class fsautoresizetab_change_var { file_line { '/var': path => '/etc/fsautoresizetab', line => '/var 10% 30g defaults', match => '^/var\ .*', } } }}} Hier wird die zu Ändernde Zeile via {{{match =>}}} definiert und die Zeile, welche dort eingefügt werden soll via {{{line =>}}}. Nun wird die auszuführend Aufgabe dem gewünschten Client zugewiesen: {{{ node client.name { class { 'fsautoresizetab_change_var': } } }}} Hinweis: Für manche Clients ist eine Vergrößerung der {{{/ (root fs)}}}-Partition gewünscht. Da diese in {{{fsautoresizetab}}} bereits als Regex definiert ist, ist hier folgende Ausdrucksweise (zu beachten ist die Änderung in {{{match =>}}}) nötig: {{{ class fsautoresizetab_change_root_fs { file_line { '/.*': path => '/etc/fsautoresizetab', line => '/.* 10% 30g defaults', match => '^/\.\*\ .*', } } }}} === Weiter Hinweise zu Hostnamen von Clients === |
Zeile 88: | Zeile 249: |
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). |
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). |
Zeile 97: | Zeile 258: |
* häufigste Verbindungsart ermitteln, z.Bsp. via WiFi - in LDAP: <myhost>.intern -> MAC-Adresse der WiFi-NIC hinterlegen |
* häufigste Verbindungsart ermitteln, z.Bsp. via !WiFi - in LDAP: <myhost>.intern -> MAC-Adresse der !WiFi-NIC hinterlegen |
Zeile 102: | Zeile 263: |
- 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 }}} |
- in LDAP: <myhost>.intern-w -> MAC-Adresse der !WiFi-NIC hinterlegen |
Inhaltsverzeichnis
-
Workstation Management via Puppet
- Installation des Puppet-Masters (auf tjener.intern)
- Puppet-Konfiguration des Puppet-Masters (auf tjener.intern)
- DNS-Eintrag: puppet.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)
-
Anpassungsbeispiele für Puppet
- Für einen Puppet-Client ("Node") soll eine bestimmte Version einer Software installiert werden
- Ein bestimmtes Software-Paket soll immer auf dem neusten Stand gehalten werden
- Für einen Puppet-Client ("Node") soll eine bestimmte Datei angelegt werden
- Für einen Puppet-Client ("Node") sollen Teile einer bestimmten Datei geändert werden
- Weiter Hinweise zu Hostnamen von Clients
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 https://code.it-zukunft-schule.de verwaltet / gepflegt: https://code.it-zukunft-schule.de/cgit/
Hinweis: Eine kurze Anleitung für das Umstellen von Puppet 3.x auf Puppet 4.x auf einem jessie TJENER findet sich hier.
Puppet-Konfiguration des Puppet-Masters (auf tjener.intern)
Server-seitig konfigurieren wir die Puppet-Agents via tjener.intern (/etc/puppet/code/environments/production/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.
Anpassungsbeispiele für Puppet
Anpassungen an den Arbeitsanweisungen, welche der Puppet-Master auf dem Tjener ausführen und anhand derer Änderungen/Aktionen auf den Puppet-Clients vorgenommen/gestartet werden sollen werden im Git in der Datei ../puppet.SCHULE/code/environments/production/manifests/site.pp gesetzt.
Hinweis: Ab Version 4.8.x von Puppet dürfen keine Bindestriche mehr in den Klassen-Bezeichnungen vorkommen. Also würde itzks-systems-workstation nicht korrekt sein und müsste umgeändert werden in itzks_systems_workstation.
Für einen Puppet-Client ("Node") soll eine bestimmte Version einer Software installiert werden
Zuerst muss der Vorgang definiert werden (Beispiel mit der Software idle3:
class software { package { 'idle3': ensure => '3.4.2-2', require => Exec['apt-get update'], } }
Die Zeile require => Exec['apt-get update'] sorgt hier dafür, dass vor dem Versuch, die Software mit der gewünschten Versionsnummer zu installieren ein apt-get update ausgeführt wird, um die Wahrscheinlichkeit zu verringern, dass die Installation fehlschlägt, weil der Client das Softwarepacket nicht kennt. (Natürlich muss trotzdem darauf geachtet werden, dass die Packetquelle für die zu installierende Software bekannt ist.)
Nun, dass die auszuführende Aufgabe für Puppet definiert ist, muss sie noch dem korrekten Client zugeordnet werden.
Der korrekte Client muss erstellt (oder wenn schon vorhanden, muss das folgende dort korrekt eingetragen) werden.
Hinweis: Ab Version 4.8.x von Puppet können Klassen nicht mehr via inherits weitervererbt werden.
node client.name { class { 'software': } }
Jetzt kann Puppet dem korrekten Client die korrekte Aufgabe zuordnen.
Hinweis: Dieses Beispiel ist als Definitionsbeispiel zu sehen, da eigentliche Softwareverwaltung durch die itzks-systems-*-Pakte vorgenommen wird.
Ein bestimmtes Software-Paket soll immer auf dem neusten Stand gehalten werden
Beispiel anhand des Paketes itzks-systems-workstation:
Zuerst muss die auszuführende Aufgabe für Puppet definiert werden:
class itzks_systems_workstation { package { 'itzks-systems-workstation': ensure => 'latest', } }
Diese Aufgabe muss nun den gewünschten Clients zugewiesen werden:
node client.name { class { 'itzks-systems-workstation': } }
Puppet wird nun sicherstellen, dass das Paket itzks-systems-workstation auf dem Client "client.name" immer auf dem neusten Stand ist. Dies ist besonders hilfreich, wenn in dem Software-Paket Software hinzugefügt oder entfernt wird; mit unattendes Upgrades ist nur ein Aktuell-Halten gleichbleibender Software-Pakete nötig.
Für einen Puppet-Client ("Node") soll eine bestimmte Datei angelegt werden
Beispiel anhand der Datei fsautoresizetab:
Zuerst muss die auszuführende Aufgabe angelegt werden:
class fsautoresizetab { file { 'fsautoresizetab': path => '/etc/', ensure => present, replace => 'no', source => '/usr/share/debian-edu-config/fsautoresizetab', } }
Die Aufgabe ist so geschrieben, dass fsautoresizetab einmalig angelegt wird, wenn die Datei nicht vorhanden ist, danach allerdings nicht wieder neu erstellt wird, solange die Datei vorhanden ist. Als Quelle der Datei wird die mit den itzks-systems-*-Paketen verteilte Datei /usr/share/debian-edu-config/fsautoresizetab genutzt.
Nun wird die auszuführend Aufgabe dem gewünschten Client zugewiesen:
node client.name { class { 'fsautoresizetab': } }
Für einen Puppet-Client ("Node") sollen Teile einer bestimmten Datei geändert werden
Beispiel anhand von Anpassungen an der Datei fsautoresizetab:
Zuerst muss die auszuführende Aufgabe definiert werden (hier für eine Anpassunge an der gewünschten Partitionsvergrößerung für /var):
class fsautoresizetab_change_var { file_line { '/var': path => '/etc/fsautoresizetab', line => '/var 10% 30g defaults', match => '^/var\ .*', } }
Hier wird die zu Ändernde Zeile via match => definiert und die Zeile, welche dort eingefügt werden soll via line =>.
Nun wird die auszuführend Aufgabe dem gewünschten Client zugewiesen:
node client.name { class { 'fsautoresizetab_change_var': } }
Hinweis: Für manche Clients ist eine Vergrößerung der / (root fs)-Partition gewünscht. Da diese in fsautoresizetab bereits als Regex definiert ist, ist hier folgende Ausdrucksweise (zu beachten ist die Änderung in match =>) nötig:
class fsautoresizetab_change_root_fs { file_line { '/.*': path => '/etc/fsautoresizetab', line => '/.* 10% 30g defaults', match => '^/\.\*\ .*', } }
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