SaltStack: Unterschied zwischen den Versionen
Fabian (Diskussion | Beiträge) |
Fabian (Diskussion | Beiträge) |
||
Zeile 64: | Zeile 64: | ||
==Windows Softwarepakete== | ==Windows Softwarepakete== | ||
− | Unter Windows gibt es kein einheitliches Paketverwaltung in dem Sinne, wie das unter Linux mit zypper, rpm oder aptget existiert. Es gibt zwar einige "standard" Paketformate wie msi oder nsis ... aber viele Softwarehersteller gehen ihre eigene Wege. Deshalb gibt es nie eine 100-ige Garantie dafür, dass ein Windows-Programm mit Salt installiert werden | + | Unter Windows gibt es kein einheitliches Paketverwaltung in dem Sinne, wie das unter Linux mit zypper, rpm oder aptget existiert. Es gibt zwar einige "standard" Paketformate wie msi oder nsis ... aber viele Softwarehersteller gehen ihre eigene Wege. Deshalb gibt es nie eine 100-ige Garantie dafür, dass ein Windows-Programm mit Salt installiert werden kann. |
− | Ein großes Problem ist, dass die Windows-Paket-Installer meistens keine | + | Ein großes Problem ist, dass die Windows-Paket-Installer meistens keine Abhängigkeitsüberprüfung durchführen. D.h. z.B. dass man ein Java-Programm installieren kann, ohne dass Java auf dem Rechner überhaupt installiert ist. Mit OSS haben wir dieses Problem dadurch gelöst, indem die Softwarepakete über eigene Software-State-Dateien in die State-Dateien der Rechner eingebunden werden. Diese befinden sich auf dem Server unter '/srv/salt/packages'. In den Software-State-Dateien ist beschrieben, was erforderlich ist um ein Softwarepaket zu installieren. Das kann ein anderes Softwarepaket oder eine Konfiguration oder Lizenzdatei sein. Hier sehen Sie 3 verschieden Software-State-Dateien: |
===Software-State-Dateien ohne Abhängigkeiten=== | ===Software-State-Dateien ohne Abhängigkeiten=== | ||
− | Das | + | Das Paket NotePad hat keine Abhängigkeiten. In der Software-State-Dateien von NotePadPP steht nur das Paket NotePadPP als installiert. |
'/srv/salt/packages/NotePadPP.sls' | '/srv/salt/packages/NotePadPP.sls' | ||
NotePadPP: | NotePadPP: | ||
Zeile 83: | Zeile 83: | ||
- installed | - installed | ||
− | ===Software-State-Dateien mit | + | ===Software-State-Dateien mit angepasster Konfigurationsdatei=== |
− | Wenn man UltranVNC installiert muss auf den Clients ein Passwort gesetzt werden. Dieses Passwort kann man in | + | Wenn man UltranVNC installiert muss auf den Clients ein Passwort gesetzt werden. Dieses Passwort kann man in einer Konfigrationsdatei hinterlegen. Wenn das Paket UltranVNC installiert wurde, sorgt Salt dafür das diese Datei auf den Clients an der richtigen Stelle hinterlegt wird. Damit das funktioniert sieht die Software-State-Datei von UltraVNC folgendermaßen aus: |
'/srv/salt/packages/UltraVNC.sls' | '/srv/salt/packages/UltraVNC.sls' | ||
UltranVNC | UltranVNC | ||
Zeile 98: | Zeile 98: | ||
===D i e Softwarepakete=== | ===D i e Softwarepakete=== | ||
− | Die eigentlichen Softwarepakete befinden sich auf dem Server unter '/srv/salt/win/repo-ng/'. In diesem Verzeichnis hat jedes Softwarepaket ein Verzeichnis mit dem Namen des Paketes. In jedem dieser Verzeichnissen muss | + | Die eigentlichen Softwarepakete befinden sich auf dem Server unter '/srv/salt/win/repo-ng/'. In diesem Verzeichnis hat jedes Softwarepaket ein Verzeichnis mit dem Namen des Paketes. In jedem dieser Verzeichnissen muss eine Datei init.sls existieren. Diese Datei beschreibt unter anderem wie das Programm installiert und ggf. lizenziert werden kann. Hier finden Sie ein detaillierte Beschreibung wie Windows-Pakete aus zu sehen haben: [https://docs.saltstack.com/en/latest/topics/windows/windows-package-manager.html#creating-a-package-definition-sls-file Windows-Pakete]. Hier gehen wir |
==Windows Updates== | ==Windows Updates== |
Version vom 5. November 2024, 23:01 Uhr
Inhaltsverzeichnis
1 Einführung
Saltstack (kurz: Salt) ist eine Open-Source-Software zur Automatisierung der Konfiguration von Betriebssystemen. Mit Salt lassen sich beispielsweise Software-Pakete installieren und konfigurieren sowie beliebige Konfigurationsbefehle von einem zentralen Rechner aus auf einer Vielzahl verwalteter Server ausführen. Der OSS verwendet Salt um die OSS-Clients zu verwalten. Folgende Managementfunktionen werden zur Zeit über Salt abgewickelt:
- Umbenennung von Windows-Clients nach dem Clonen.
- Ggf. Aufnahme von Windows-Clients in die AD-Domäne.
- Installation und Deinstallation von Softwarepaketen.
- Auslesen von installierten Softwarepaketen.
- Installation von Updates.
- Anpassung von GPOs und Registry-Einträgen.
- Rechner ausschalten und neustarten.
2 CRANIX Salt-Modul
Der CRANIX liefert ein eigenes Salt-Modul (cranix_client). Das Backend von CRANIX (cranix-api) benutzt dieses Modul, kann jedoch auch von der Kommandozeile aus benutzt werden:
salt <MinionName> cranix_client.<Funktion>
Dieses Modul erweitert Salt mit folgenden Funktionalitäten:
- lockClient Rechner sperren: Bildschirm und Tastatur.
- unLockClient Rechner entsperren: Bildschirm und Tastatur.
- blockInput Tastatur sperren.
- unBlockInput Tastatur entsperren.
- loggedIn Liefert den Benutzernamen des lokal angemeldeten Benutzers. Funktioniert nicht mit Benutzern die per Remote Desktop angemeldet sind.
- logOff Meldet den lokal angemeldeten Benutzer ab. Funktioniert nicht mit Benutzern die per Remote Desktop angemeldet sind.
- disableUpdates Schaltet das Windows-Update-Service (wuauserv) ab und deaktiviert es.
- enableUpdates Schaltet das Windows-Update-Service (wuauserv) ein und aktiviert es.
- applyRegs Wendet Windows Registrydateien an, die auf dem Server unter /srv/salt/REGS hinterlegt worden sind.
- executeCommands Führt Programme aus die auf dem Server unter /srv/salt/COMMANDS hinterlegt worden sind.
2 State-Files sorgen dafür, dass die Files aus den oben genannten Verzeichnissen auf den Clients kopiert und bei Bedarf ausgeführt werden. Bei Bedarf heißt: wenn der Inhalt der o.g. Verzeichnisse geändert wurde.
/srv/salt/ApplyREGS.sls copy_regs: file.recurse: - source: salt://REGS - name: "C:\\salt\\var\\REGS\\" apply_regs: oss_client.applyRegs: - onchanges: - copy_regs
/srv/salt/ExecuteCommands.sls copy_commands: file.recurse: - source: salt://COMMANDS - name: "C:\\salt\\var\\COMMANDS\\" execute_commands: oss_client.executeCommands: - onchanges: - copy_commands
Bitte beachten Sie, dass diese State-Files zu keinen Clients zugewiesen sind, also nicht automatisch angewendet werden. Um die in /srv/salt/REGS hinterlegten Registry-Dateien auf allen eingeschalteten Rechnern anzuwenden müssen Sie folgenden Befehl von der Konsole ausführen:
salt '*' sate.apply ApplyREGS
Analog dazu führen Sie alle Befehle die unter /srv/salt/COMMANDS hinterlegt sind auf dem im Raum "infeg" eingeschalteten Rechnern mit folgendem Befehl aus:
salt -N room-infeg state.apply ExecuteCommands
Will man, dass beim Hochfahren auf den Rechnern die Registriepatches angewendet werden, muss ein neues Pluginscript in /usr/share/oss/plugins/clients/start/ mit Folgendem erstellt werden:
#!/bin/bash MINION=$1 salt "$MINION" state.apply ApplyREGS
Das Selbe gilt natürlich, wenn man die unter /srv/salt/COMMANDS liegenden Programme beim Hochfahren ausführen möchte. WICHTIG Bitte beachten Sie, dass die Programme nur bei einer Änderung ausgeführt werden!!
#!/bin/bash MINION=$1 salt "$MINION" state.apply ExecuteCommands
3 Windows Softwarepakete
Unter Windows gibt es kein einheitliches Paketverwaltung in dem Sinne, wie das unter Linux mit zypper, rpm oder aptget existiert. Es gibt zwar einige "standard" Paketformate wie msi oder nsis ... aber viele Softwarehersteller gehen ihre eigene Wege. Deshalb gibt es nie eine 100-ige Garantie dafür, dass ein Windows-Programm mit Salt installiert werden kann. Ein großes Problem ist, dass die Windows-Paket-Installer meistens keine Abhängigkeitsüberprüfung durchführen. D.h. z.B. dass man ein Java-Programm installieren kann, ohne dass Java auf dem Rechner überhaupt installiert ist. Mit OSS haben wir dieses Problem dadurch gelöst, indem die Softwarepakete über eigene Software-State-Dateien in die State-Dateien der Rechner eingebunden werden. Diese befinden sich auf dem Server unter '/srv/salt/packages'. In den Software-State-Dateien ist beschrieben, was erforderlich ist um ein Softwarepaket zu installieren. Das kann ein anderes Softwarepaket oder eine Konfiguration oder Lizenzdatei sein. Hier sehen Sie 3 verschieden Software-State-Dateien:
3.1 Software-State-Dateien ohne Abhängigkeiten
Das Paket NotePad hat keine Abhängigkeiten. In der Software-State-Dateien von NotePadPP steht nur das Paket NotePadPP als installiert.
'/srv/salt/packages/NotePadPP.sls' NotePadPP: pkg: - installed
3.2 Software-State-Dateien mit Softwareabhängigkeit(en)
Um das Programm Amaya benutzen zu können muss AdobeFlashPlayerNPAPI installiert sein. Deshalb sieht die Software-State-Dateien von Amaya so aus:
'/srv/salt/packages/Amay.sls' AdobeFlashPlayerNPAPI: pkg: - installed Amaya: pkg: - installed
3.3 Software-State-Dateien mit angepasster Konfigurationsdatei
Wenn man UltranVNC installiert muss auf den Clients ein Passwort gesetzt werden. Dieses Passwort kann man in einer Konfigrationsdatei hinterlegen. Wenn das Paket UltranVNC installiert wurde, sorgt Salt dafür das diese Datei auf den Clients an der richtigen Stelle hinterlegt wird. Damit das funktioniert sieht die Software-State-Datei von UltraVNC folgendermaßen aus:
'/srv/salt/packages/UltraVNC.sls' UltranVNC pkg: - installed copy_file: file.managed: - source: salt://win/repo-ng/UltraVnc/ultravnc.ini - name: 'C:\Program Files\UltraVNC\ultravnc.ini' - replace: True - require: - pkg: UltraVnc
3.4 D i e Softwarepakete
Die eigentlichen Softwarepakete befinden sich auf dem Server unter '/srv/salt/win/repo-ng/'. In diesem Verzeichnis hat jedes Softwarepaket ein Verzeichnis mit dem Namen des Paketes. In jedem dieser Verzeichnissen muss eine Datei init.sls existieren. Diese Datei beschreibt unter anderem wie das Programm installiert und ggf. lizenziert werden kann. Hier finden Sie ein detaillierte Beschreibung wie Windows-Pakete aus zu sehen haben: Windows-Pakete. Hier gehen wir
4 Windows Updates
Das Salt Paket beinhaltet ein Modul womit man auf Windows-Clients die Updates verwalten kann. Eine detaillierte Beschreibung finden Sie unter WIN_WUA. Hier Zeigen wir Ihnen die wichtigsten Befehle:
Installierte Updates anzeigen:
salt '<Minionname>' win_wua.installed
Ausstehende Updates auf einem Client anzeigen:
salt '<Minionname>' win_wua.list
Installation der Updates starten:
salt '<Minionname>' win_wua.list install=True
Wenn Sie beim Hochfahren von Klients die Updates einspielen möchten, legen Sie die Datei /usr/share/cranix/plugins/clients/start/110_install-updates.sh mit folgendem Inhalt an:
#!/bin/bash MINION=$1 salt "$MINION" win_wua.list install=True
Vergessen Sie nicht die Datei ausführbar zu machen:
chmod 755 /usr/share/cranix/plugins/clients/start/110_install-updates.sh