Eigene Autoconf-Rolle erstellen

Zuletzt geändert von Tom Altenbrunn am 2023/03/17 08:03

Allgemeines
Beispielaufbau einer logodidact.yml
- Beispiel zur Deklaration einer Autoconf Variable in logodidact.yml
Neue AutoConf-Rollen nach Fertigstellung freigeben
Funktionsfertiges Beispiel: Rolle „WLAN Profil mit PSK anlegen“
- Struktureller Aufbau der logodidact.yml
- Inhalt des PowerShell-Skripts main.ps1, das die Variablen entgegennimmt
Weiteres Beispiel: eigene AutoConf-Rolle zur „Deaktivierung der Suchhervorhebung in Windows“

Allgemeines

Autoconf liegt wie der Vorgänger Ansible im ctrl-g1 Container und dient dazu, individuelle Einstellungen während des Deployments auf Rechner zu übertragen. Es können über diesen Mechanismus nachträglich auch kleinere Anpassungen an Clients übertragen werden, ohne dafür ein neues Image auf den Server hochzuladen. Somit lassen sich relativ einfach und flexibel diverse Anpassungen an bestehenden Clients vornehmen.

LogoDIDACT ist standardmäßig bereits mit zahlreichen Autoconf-Rollen bestückt, die mitgeliefert werden, um ein möglichst breites Spektrum verschiedenster Anforderungen des allgemeinen Schulbetriebs abzudecken.
Diese fest integrierten Rollen befinden sich im LXC-Container ctrl-g1 im Pfad /usr/lib/ld-autoconf/logodidact/roles/.

Darüber hinaus ist es Partnern und Kunden möglich, für spezielle / anwendungsspezifische Anforderungen eigene AutoConf-Rollen zu erstellen und im LD Control Center mit Clients zu verknüpfen. Dafür steht am LD-Server ein eigenes Verzeichnis zur Verfügung, welches sich ebenfalls im LXC-Container ctrl-g1 befindet und nicht durch Server-Updates beeinflusst oder überschrieben wird. Der genaue Speicherpfad hängt von der Puppet-Version des Servers ab:

bis Puppet-Version 1.4.x : /var/lib/ld-autoconf/custom/
ab Puppet-Version 1.5.x : /data/ld/autoconf/custom/

Der Aufbau einer Autoconf-Rolle unterliegt einer vordefinierten Struktur, bestehend aus einer Beschreibungsdatei meta/logodidact.yml, welche die Informationen zu Namen, Beschreibung, Ersteller, Variablen, usw. definiert, sowie zugehörige Skript-Dateien (PowerShell). Diese Skript-Dateien müssen - abhängig vom vorgesehen Ziel-Betriebssystem - in einem Unterordner win/ (Windows) oder lin/ (Linux) abgespeichert sein. Zusätzlich besteht auch die Möglichkeit, in einem weiteren Unterordner files/ beliebige Dateien in der Autoconf-Rolle mitzuliefern, wie zum Beispiel Bilder, Videos, etc.

Der strukturelle Aufbau eines AutoConf-Verzeichnisses grafisch dargestellt:

Für die Funktionalität der Autoconf-Rolle ist es also nötig, PowerShell-Skripte am Server abzuspeichern, die die Instruktionen an den Arbeitsstationen ausführen. Für diese Skripte sind folgende Dateinamen zulässig:

main.ps1 - Skript wird in allen Phasen ausgeführt, die innerhalb der Beschreibungsdatei meta/logodidact.yml festgelegt sind. Eine solche Datei folgt dem Prinzip „in jeder Phase soll genau das gleiche stattfinden“.
setup.ps1 - Skript wird ausschließlich in der SETUP-Phase während des Deployments ausgeführt. In der Setup-Phase ist der Client noch veränderlich und besitzt noch keine Schutzfunktion, selbst wenn der Schutz aktiviert ist.
custom.ps1 - Skript wird ausschließlich in der CUSTOM-Phase ausgeführt. Dies geschieht sowohl 1x während des Deployments als auch später nach jedem Hochfahren des PCs 1x im Hintergrund.
user.ps1 - Skript wird ausschließlich in der USER-Phase ausgeführt. Diese Phase wird nicht direkt während des Deployments durchlaufen, sondern erst später während der Benutzeranmeldung an betriebsbereiten PCs.
audit.ps1 - Skript wird ausschließlich in der AUDIT-Phase ausgeführt. Das bedeutet erst dann, wenn man an einem Client in den Audit-Modus zur Imagebearbeitung wechselt.
collect.ps1 - Sonderfall. Dieses Skript wird ausgeführt, wenn durch einen Anwender aktiv die Phase COLLECT zum Einsammeln von Einstellungen am Client aufgerufen wird.

Hinweis: Skripte, die durch ihren Dateinamen auf einzelne Phasen eingeschränkt sind (lila eingefärbt), dürfen sich inhaltlich zueinander unterscheiden. Dadurch kann eine Autoconf-Rolle sehr flexibel gestaltet werden und in den verschiedenen Phasen des Deployments unterschiedliche Aktionen ausführen.

Nachfolgend sind grafisch die diversen Deploy-Phasen dargestellt, welche ein Client während des Imaging-Vorgangs durchläuft. Die Abarbeitung von AutoConf-Rollen beginnen ab der Phase "Re-Setup" . Anhand der Deploy-Phase kann somit auf die Verarbeitungsphase der Rolle rückgeschlossen werden.

Beispielaufbau einer logodidact.yml

Eine Autoconf-Beispielvorlage liegt serverseitig im Unterordner /data/ld/autoconf/custom/example/ abgespeichert. Darin wird die Verwendung verschiedener Variablentypen aufgezeigt, die als Parameter an die Skript-Dateien weitergegeben werden können. Die Verwendung solcher Variablen innerhalb einer Autoconf-Rolle ist optional, je nach Zweck jedoch häufig sinnvoll.

Beispiel zur Deklaration einer Autoconf Variable in logodidact.yml

ld_info:
  display_name: Meine eigene Autoconf-Rolle 1
  # [...]

  vars:
    globalLogLevel:
      display_name: Loglevel
      optional: true
      type: ENUM
      values:
        - none
        - compact
        - detailed
        - verbose

  # [...]

Tipp: Der Variablentyp ENUM aus dem Beispiel ergibt ein Dropdown-Menü, in dem man aus den vordefinierten 4 Werten (none / compact / detailed / verbose) auswählen kann.

Neue AutoConf-Rollen nach Fertigstellung freigeben

Neue Autoconf-Rollen können am Server durch Aufruf des Befehls update-autoconf-archive im LXC ctrl-g1 aktualisiert werden. Der Aufruf dieses Kommandos ist auch nach Änderungen an Autoconf-Rollen nötig.
Alternativ werden alle Autoconf-Rollen auch zeitbasiert alle 4 Stunden am Server eingelesen. Dies passiert automatisch im Hintergrund.

Über den Button "AutoConf Rollen neu einlesen" im LD Control Center (mit aktiviertem Expertenmodus) werden die neu erstellten Rollen im Anschluss sichtbar und sind wie gewohnt Betriebssystemen zuordenbar.

Der Expertenmodus wird in den Einstellungen (Zahnrad oben rechts) -> Entwickleroptionen -> Expertenmodus aktivieren aktiv geschaltet.

Funktionsfertiges Beispiel: Rolle „WLAN Profil mit PSK anlegen“

Zum besseren Verständnis wird nachfolgend eine feste Autoconf-Rolle zur Konfiguration eines WLAN-Profils (SSID inkl. PSK) an Clients näher beleuchtet.

root@ctrl-g1:~ # cat /usr/lib/ld-autoconf/logodidact/roles/ld_wlan_psk/meta/logodidact.yml

Struktureller Aufbau der logodidact.yml

ld_info:
  authors:
    - Marcel Petersen
  company: SBE network solutions GmbH
  display_name: WLAN Profil mit PSK anlegen
  license: SBE
  uuid: 52318636-c4f5-11ea-baf9-0bff00c66ff4
  visible: true
  priority: 0
  apply_always: false
  tags:
    - CUSTOM
  vars:
    ssid:
      display_name: SSID
      optional: false
      type: STRING
    psk:
      display_name: Passwort
      optional: false
      type: PASSWORD
  systems:
    - WINDOWS
    - LINUX

display_name = Anzeigename der Autoconf-Rolle im LD Control Center

uuid = ID der Autoconf-Regel. Muss einmalig sein. Bei einer eigenen Autoconf-Rolle sollte der Wert am besten neu generiert werden. https://www.uuidgenerator.net/

priority = Legt die Verarbeitungsreihenfolge der Autoconf-Rolle gegenüber weiteren Rollen fest, die in derselben Phase ausgeführt werden. Bei gleicher Priorität findet die Abarbeitung alphabetisch statt. Eine höhere Priorität führt zu früherer Ausführung.

tags = beschreibt, in welchen Phasen die Autoconf-Regel ausgeführt wird.

vars = definiert mögliche Variablen, die den Skripten übergeben werden

display_name = Name der konfigurierbaren Variable im Control Center
optional = bestimmt, ob die Variable zwingend mit einem Wert belegt werden muss
type = bestimmt den Typ der Variable. Gültige Typen sind: STRING, PASSWORD, BOOLEAN, ENUM, ARRAY, INTEGER
example = Zeigt einen grau eingefärbten Beispieltext innerhalb der definierten Variable an, ohne dass dieser als Wert festgelegt ist (Hilfsmittel für Anwender).

systems = Legt fest, welche Betriebssystem-Typen durch die Autoconf-Rolle unterstützt werden. Gültige Systeme sind WINDOWS / LINUX. Die Rolle aus dem Beispiel unterstützt beide Betriebssysteme gleichzeitig.

Inhalt des PowerShell-Skripts main.ps1, das die Variablen entgegennimmt

Im Unterverzeichnis win/ oder lin/ der Autoconf-Rolle können sich wie erläutert unterschiedliche PowerShell-Skripte zur Ausführung in den verschiedenen Phasen befinden.
In dieser Rolle liegt konkret das allgemeingültige Skript main.ps1 vor, welches die Variablen als Parameter $ssid und $psk intern verwendet.

Windows Variante

root@ctrl-g1:~ # cat /usr/lib/ld-autoconf/logodidact/roles/ld_wlan_psk/win/main.ps1

Param
(
[parameter(Mandatory=$false)]
[String]
$ssid,
[parameter(Mandatory=$false)]
[String]
$psk
)

if ($ssid -ne '' -and $psk -ne '') {
$profile = @'
<WLANProfile xmlns="http://www.microsoft.com/networking/WLAN/profile/v1">
        <name>{0}</name>
        <SSIDConfig>
                <SSID>
                        <name>{0}</name>
                </SSID>
        </SSIDConfig>
        <connectionType>ESS</connectionType>
        <connectionMode>auto</connectionMode>
        <MSM>
                <security>
                        <authEncryption>
                                <authentication>WPA2PSK</authentication>
                                <encryption>AES</encryption>
                                <useOneX>false</useOneX>
                        </authEncryption>
                        <sharedKey>
                                <keyType>passPhrase</keyType>
                                <protected>false</protected>
                                <keyMaterial>{1}</keyMaterial>
                        </sharedKey>
                </security>
        </MSM>
</WLANProfile>
'@ -f $ssid, $psk

$file = "$AUTOCONF_TEMP_DIR\ld_wlan_psk\wlan.xml"

$profile | Out-File (New-Item $file -Force)

Get-NetAdapter | Where-Object { $_.PhysicalMediaType -eq 'Native 802.11' -or `
  $_.PhysicalMediaType -eq 'Wireless LAN' -or `
  $_.PhysicalMediaType -eq 'Wireless WAN' } | ForEach-Object {

   Write-Verbose "Creating wlan profile for '$ssid' on interface '$($_.Name)'"
    netsh wlan add profile filename= "$file" interface= "$($_.Name)"
}

Remove-Item -Path $file -Force
}

Linux Variante (Network Manager)

root@ctrl-g1:~ # cat /usr/lib/ld-autoconf/logodidact/roles/ld_wlan_psk/lin/main.ps1

Param
(
  [parameter(Mandatory=$false)]
[String]
$ssid,
  [parameter(Mandatory=$false)]
[String]
$psk
)

if ($ssid -ne '' -and $psk -ne '') {
if (Get-Command "nmcli" -ErrorAction SilentlyContinue) {
   # Check if kernel modules are up
    nmcli dev wifi rescan
if ($LASTEXITCODE -ne 0) {
  Start-Sleep -Seconds 30
}

# Check again
nmcli dev wifi rescan
if ($LASTEXITCODE -ne 0) {
  Write-Verbose "Skipping role. There might be no WiFi device installed."
   exit 0
}

   $config = "/etc/NetworkManager/system-connections/$ssid"

   if (Test-Path -Path $config) {
     Write-Verbose "Removing '$config'"
     Remove-Item -Path $config -Recurse -Force
    }

   Write-Verbose "Connecting to '$ssid'"

    nmcli device wifi connect """$ssid""" password """$psk"""

   if ($LASTEXITCODE -eq 0) {
     Start-Sleep -Seconds 5
      nmcli con up """$ssid"""

     if ($LASTEXITCODE -ne 0) {
       Write-Verbose "Error: Credentials wrong?"

       if (Test-Path -Path $config) {
         Write-Verbose "Removing '$config'"
         Remove-Item -Path $config -Recurse -Force
        }
      }
    }

   Write-Verbose "Exiting with code: $LASTEXITCODE"
    exit $LASTEXITCODE
  }

Write-Verbose "No suitable implementation found"
  exit 1
}

Weiteres Beispiel: eigene AutoConf-Rolle zur „Deaktivierung der Suchhervorhebung in Windows“

Im nachfolgenden Beispiel wird eine einfache Rolle zur Deaktivierung der Suchvorhebung in Windows deklariert.

Aufbau der logodidact.yml

Neben den allgemeinen Informationen über die Autoren (authors), Unternehmen (company), einer Beschreibung (description), dem Anzeigenamen (display_name) im LD Control Center, usw, beginnt im Abschnitt vars die eigentliche Definition der Variable
"disableSearchHighlight".

#logodidact.yml

ld_info:
authors:
    - Tom Altenbrunn
    - Olav Krapp
    - Marcel Petersen
    - Kerim Ekin
company: SBE network solutions GmbH
description: |   #Beschreibung
  Die Suchhervorhebung in der Windows Suchleiste wird deaktiviert
display_name: Windows Suchhervorhebung #Anzeigename im LD Control Center
license: SBE
uuid: fec4ff30-b2a6-407f-a6b3-0a621cd7eaf7 #einmalige UUID
vars: #Deklaration der Variablen
  disableSearchHighlight: #Name der Variable
    display_name: Suchhervorhebung im Suchfeld deaktivieren #Anzeigename im LD Control Center
    optional: true #Auswahl optional
    type: BOOLEAN #Variablentyp Boolean = True/False
    value: false #Standardwert false
visible: true #Sichtbarkeit der Variable im LD Control Center
priority: 0 #Abarbeitungspriorität
apply_always: false
tags:
    - CUSTOM #Ausführungszeitpunkt während der/den Phase(n)
systems:
    - WINDOWS #Betriebssystem

Aufbau der main.ps1

Danach erfolgt die Erstellung des ausführbaren Codes per Powershell. Im ersten Abschnitt Param werden die in der im vorigen Abschnitt definierten Variablen vars aus der logodidact.yml aufgeführt und definiert. Bei der Variable "disableSearchHighlight" handelt es sich um ein Boolean (True/False). Die Bedingung "[parameter(Mandatory=$false)]" setzt das Vorhandensein der Variable während dem Ablauf des Skriptes nicht als zwingend notwendig voraus, sodass bei einem darauffolgenden Verarbeitungsfehler o.ä. die Abarbeitung weiter erfolgt.

#main.ps1

Param
(
[parameter(Mandatory=$false)] #Variable zwingend erforderlich?
[bool] #Variablentyp
$disableSearchHighlight #Name der def. Variable aus logodidact.yml
)

$SystemVersion=[System.Environment]::OSVersion.Version #Hole Windows Systemversion

#Beginn des eigentlichen Codes
if ($SystemVersion.Major -eq 10 -and $SystemVersion.Build -ge 19044) {
$val = [int]!$disableSearchHighlight
Write-Verbose "Setting EnableDynamicContentInWSB to '$val'"
[Microsoft.Win32.Registry]::SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search","EnableDynamicContentInWSB",$val,[Microsoft.Win32.RegistryValueKind]::DWord)
} else {
Write-Host "Feature ist erst ab dem Release 21H2 verfügbar."
}