== 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/ === 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. ./puppet }}} Die ITZkS-Admins können diese Repository mit Schreibrechten via SSH clonen: {{{ $ git clone gitolite@code.it-zukunft-schule.de:puppet..git }}} Das Git Repository ist public. Schreibzugriff haben alle Mitarbeiter. Änderungen am {{{puppet..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. -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.}}}, 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 .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 {{{.intern}}} nun gelistet sein. Mit {{{ $ sudo puppet cert --sign .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 .intern }}} === Erster Puppet-Lauf auf Puppet-Client (auf .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/manifests/site.pp}}} gesetzt. Bsp.: 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. {{{ node client.name inherits "all_hosts" { class { 'software': } } }}} Jetzt kann Puppet dem korrekten Client die korrekte Aufgabe zuordnen. === 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 .intern (nicht -w.intern) * häufigste Verbindungsart ermitteln, z.Bsp. via WiFi - in LDAP: .intern -> MAC-Adresse der WiFi-NIC hinterlegen - in LDAP: -lan.intern -> MAC-Adresse von eth0 hinterlegen (RJ-45) * häufigste Verbindungsart z.Bsp. LAN: - in LDAP: .intern -> MAC-Adresse von eth0 hinterlegen (RJ-45) - in LDAP: .intern-w -> MAC-Adresse der WiFi-NIC hinterlegen