Heterogenes Client-Management

Warum ein weiteres Managementwerkzeug für Linux?

• Linux hat ein Paketverwaltungssystem, aber das erledigt nicht alles was zu tun ist…
  • Konfiguration der Installation
  • Zentrale Steuerung, zentrales Logging
  • Nicht jede benötigte Software befindet sich in den Standard-Repos
  • Und wenn, dann meistens nicht in der Version, die gerade gebraucht wird
• Jede Distribution arbeitet im Patchbereich anders:
  • Was auf Debian funktioniert, sieht in Redhat anders aus.
  • Paketverwaltungen haben starke Grenzen

Es gibt doch bereits Linux-Managementsysteme: FAI, M23, Puppet, Ansible, Chef, CFEngine… Was ist anders in opsi?

• Admins realisieren seit Jahren das Windows-Clientmanagement mit opsi
• Da die Clientkomponenten des Linux-Supports auf dem selben Code wie Linux basieren, ist der Einstieg für die Admins "leichter"
• Es kann, muss aber nicht über ein System Erfolgen
• Vorhandene Managementsysteme können mit opsi gemeinsam genutzt werden
• Anders als bei den genannten Systemen kam Linux bei opsi auf der Clientseite später hinzu und befindet sich noch in Entwicklung!!!

Beispiel einer Infrastruktur mit opsi

Wo sind wir gerade?

• GetOS [W/L]: Liefert "Windows_NT" (NT-Win10) oder "Linux"

Architektur

• GetSystemType [W/L]: Liefert "64 Bit System" oder "x86 System" zurück

Windows

• GetMsVersionInfo [W]: Windows Version Information

Linux

• getLinuxDistroType [L]: Liefert "debian", "redhat", "suse"

getMsVersionInfo [W]

getMsVersionMap [W]

Set  $INST_Resultlist$ = getMSVersionMap

(string   0)major_version=5
(string   1)minor_version=1
(string   2)build_number=2600
(string   3)platform_id=2
....

Abholen eines Wertes mit getValue:

DefVar $result$
set $result$ = getValue("build_number", $INST_Resultlist$)

• ProTip: Man kann sich auch eigene Mappings bauen… addToStringList("key=value")

getLinuxVersionMap [L]

Set  $INST_Resultlist$ = getLinuxVersionMap

Ergebnis als Stringliste

(string   0)Distributor ID=Ubuntu
(string   1)Description=Ubuntu 16.04.3 LTS
(string   2)Release=16.04
(string   3)Codename=xenial
(string   4)SubRelease=
(string   5)kernel name=Linux
...

shellCall [W/L]

shellCall("echo Hallo Welt")

• Liefert nichts zurück

shellCall Magic

set $string$ = shellCall("echo Hallo Welt")

• Liefert den Rückgabewert der Shell zurück.

set $stringlist$ = shellCall("echo Hallo Welt")

• Liefert die Ausgabe der Shell als Stringliste zurück.

shellCall [W/L]

shellCall(’net start’)

DosInAnIcon_netstart winst /sysnative

[DosInAnIcon_netstart]
net start

shellCall [W/L]

DefVar $exitcode$
set $exitcode$ = shellCall(’net start’)

DefVar $exitcode$
DosInAnIcon_netstart winst /sysnative
set $exitcode$ = getLastExitcode

[DosInAnIcon_netstart]
net start

shellCall [W/L]

DefStringList $list$
set $list$ = shellCall(’net start’)

DefStringList $list$
set $list$ = getOutStreamFromSection (’DosInAnIcon_netstart winst /sysnative’)

[DosInAnIcon_netstart]
net start

processCall [W/L]

processCall(<string>) :string (exitcode)  [W/L]

Startet das Programm <string> als Prozess und liefert den Exitcode zurück.

processCall [W/L] Erläuterung:

set $exitcode$ = processCall('setup.exe /S')

Winbatch_setup
set $exitcode$ = getLastExitcode

[Winbatch_setup]
setup.exe /S

Nutzung der OS-Paketverwaltung [L]

• Oftmals wird der Packagemanager von der Distro verwendet
• Wenn die Paketverwaltung gerade aktiv ist, kommt es zu einem Fehler
• Abhilfe schafft waitForPackageLock(<seconds timeout string>,<bool should we kill>)

waitForPackageLock (Snippet aus l-opsi-server)

Message "Try to get Package Lock..."
if waitForPackageLock("300","false")
        comment "we got the package lock."
        if $distroName$ = 'Univention'
                comment "UCS: Extra check if package lock is available."
                ...
        endif
else
        LogError "could not get Package Lock"
        isFatalError "package lock failed"
endif

opsi-script: Internal flow

• Warum ist das folgende wichtig?
• Fehler Erkennung
• Fehler in externen Scripten
  • bash
  • cmd.exe
  • powershell
• Fehler Behandlung

Warum ist das folgende wichtig?

• Fehler im Skript werden im Produktivbetrieb ausgeblendet
• Lässt sich aus ScriptErrorMessages beeinflussen.
• Der Zustand Failed erfolgt nur automatisch bei einem Syntaxfehler im Skript
• Alle anderen Fälle müssen manuell herbeigeführt werden.

Methoden:

getLastExitCode :string (exitcode) [W/L]

markErrorNumber / errorsOccurredSinceMark [W/L]
LogError

getLastExitCode

getLastExitCode :string (exitcode) [W/L]

• Die String-Funktion getLastExitCode gibt den ExitCode des letzten Prozessaufrufs der vorausgehenden WinBatch / DosBatch[ShellBatch] / ExecWith Sektion aus.
• Der Aufruf anderer opsi-winst Befehle ( wie z.B. einer Files Sektion) verändert den gefundenen ExitCode nicht.
• Bei DosBatch und ExecWith Sektionen erhalten wir den Exitcode des Interpreters. Daher muss in der Regel der gewünschte Exitcode in der Sektion explizit übergeben werden.

Problem an einem bash-Beispiel

[ShellInAnIcon_Upgrade_deb]
set -x
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get --yes dist-upgrade
exit $?

• Wenn apt-get update schief läuft erhalten wir trotzdem Exitcode 0

Lösung

[ShellInAnIcon_Upgrade_deb]
set -x
export DEBIAN_FRONTEND=noninteractive
EXITCODE=0
apt-get update
EC=$?; if [ $EC -ne 0 ]; then EXITCODE=$EC; fi
apt-get --yes dist-upgrade
EC=$?; if [ $EC -ne 0 ]; then EXITCODE=$EC; fi
exit $EXITCODE

Lösung mit shellCall ohne sekundäre Sektion (NOT TESTED)

set $exitcode$ = shellCall("apt-get update")
if $exitcode$ = 0
  set $exitcode$ = shellCall("apt-get --yes dist-upgrade")
  if NOT ($exitcode$ = 0)
    logError("dist-updrade failed with exitcode: " + $exitcode)
  endif
else
  logError("apt-get update failed with exitcode: " + $exitcode)
endif

Errordetection: markErrorNumber

Beispiel:

markErrorNumber
logError "test error"
if errorsOccurredSinceMark > 0
    comment "error occured"
else
    comment "no error occured"
endif

• Mit markErrorNumber lässt sich der interne Fehlerzähler für einen Skriptabschnitt zurücksetzen.
• Mit errorsOccurredSinceMark lässt sich der Fehlercount seit dem zurücksetzen abfragen.

Errordetection: Fehlerauswertung Methoden

isFatalError [W/L]
isSuspended [W/L]
isSuccess [W/L]
noUpdateScript [W/L]

Errordetection: Fehlerauswertung isFatalError

isFatalError
isFatalError "short message"

• Nach dem der Befehl aufgerufen wurde, werden keine Anweisungen mehr ausgeführt und als Skriptergebnis wird failed zurückgeliefert. Wird dieser Befehl nicht aufgerufen, so ist das Skriptergebnis success.

Errordetection: Weitere Methoden für Fehlerauswertung

• isSuccess //since 4.11.3.7 [W/L]
  Abort the script as successful.
• noUpdateScript //since 4.11.3.7 [W/L]
  Do not run a update script after setup even if there is one.
• isSuspended //since 4.11.4.1 [W/L]
  Abort the script without notice to the server. The action request remain unchanged.

Was ist das Problem

• Globale Variablen
• Räumliche Trennung von Aufruf und Deklarartion von Sektionen

Vorstellung: Local Functions in opsi-script

• Seit Version 4.12 kennt opsi-script auch lokale Funktionen.

Ein Beispiel:

DefFunc myFunc(val $str1$ : string, $str2$ : string) : string
        set $result$ = $str1$ + $str2$
endfunc

Konzept und Ziel dieser Erweiterung

• Funktionen mit Rückgabewert:
  Die Funktionen haben einen Rückgabewert welche vom Typ string oder stringlist ist. Der Aufruf eine solchen Funktion kann überall da Erfolgen, wo ein Stringausdruck bzw.eine Stringliste erwartet wird.
• Frei definierbare Aufrufparameter: Einer Funktion können Parameter übergeben werden. Diese Parameter werden bei der Deklaration der Funktion definiert. Die Aufrufparameter können vom Typ string oder stringlist sein.
  

CallByValue vs. CallByReference

• Die Aufrufparameter können als CallByValue oder per callByReference übergeben werden. CallByValue ist der Default.
  • Soll CallByValue explizit angegen werden, so erfolgt dies über das Schlüsselwort val. CallByValue bedeutet, das beim Aufruf der Inhalt einer beim Aufruf verwendeten Variable auf die Aufrufvariable kopiert wird.
  • callByReference (über das Schlüsselwort ref) bedeutet, dass beim Aufruf eine Verbindung zwischen der aufrufenden Varibalen und des lokalen Aufrufparameters erstellt wird. Eine Änderung der lokalen Variable des Aufrufparameters, wirkt sich direkt auf die beim Aufruf verwendete Variable aus.
    
• Die Übergabeparameter stehen innerhalb der Funktion als lokale Variablen zur Verfügung.

Konzept und Ziel dieser Erweiterung Fortsetzung

• Lokale Variablen:
  
  • Eine Funktion enthält lokale Variablen. Implizit gibt es die Aufrufparameter als lokale Variablen und die Variable $result$ welche vom Typ des Rückgabewertes ist. Darüberhinaus können weitere Variablen innerhalb der Funktion definiert werden.
    
  • All dies Variablen sind lokal, d.h. sie sind nur innerhalb dieser Funktion sichtbar. Eine lokale Variable mit dem selben Namen einer globalen Variable verdeckt innerhalb der Funktion die entsprechende globale Variable.
• Geschachtelte Funktionen:
  
  • Eine lokale Funktion kann wiederum eine oder mehrerr Definitionen von lokalen Funktionen enthalten. Diese Funktionen sind nur innerhalb der Funktion sichtbar in der sie definiert sind.

Konzept und Ziel dieser Erweiterung Fortsetzung

• Rekursive Aufrufe:
  • Eine Funktion kann sich selbst rekursiv aufrufen.
• Primäre und sekundäre Sektionen innerhalb von Funktionen
  • Der Funktionskörper kann eigene Sektionen enthalten. Diese sind lokal zu dieser Funktion also nur innerhalb der Sektion sichtbar.

Syntax

DefFunc <func name>([calltype parameter type][,[calltype parameter type]]) : type
<function body>
endfunc

• DefFunc das Schlüsselwort zur Beginn der Definition einer lokalen Funktion.
• <func name> der frei gewählte Name der Funktion.
• calltype ist der Aufruftyp [val | ref]. Wird kein Aufruftyp angegeben, so gilt val als gesetzt.
• parameter ist der freigewählte Name des Aufrufparameters, welcher unter diesem Namen innerhalb der Funktion als lokale Variable zur Verfügung steht.

Syntax

DefFunc <func name>([calltype parameter type][,[calltype parameter type]]) : type
<function body>
endfunc

• type ist der Datentyp des Parameters bzw. der Funktion und entweder string oder stringlist.
• <function body>: ist der Körper der Funktion, welcher dem opsi-script syntax genügen muß. In diesem Teil gibt es die automatisch erzeugte lokale Variable $result$, welche den Datentyp der Funktion hat (String/Stringliste) und dazu dient den Rückgabewert aufzunehmen.
• endfunc zeigt als Schlüsselwort das Ende einer Funktionsdefinition an.

Beispiel1: Local Functions in opsi-script

[actions]
DefVar $mystr$
DefVar $str1$
set $str1$ = 'ha'

DefFunc myFunc(val $str1$ : string, $str2$ : string) : string
        set $result$ = $str1$ + $str2$
endfunc

set $mystr$ = myFunc("he","ho")
set $mystr$ = myFunc("he",timeStampAsFloatStr)
set $mystr$ = myFunc("he",$str1$)

Beispiel1: Local Functions in opsi-script

....
set $mystr$ = myFunc("he","ho")
set $mystr$ = myFunc("he",timeStampAsFloatStr)
set $mystr$ = myFunc("he",$str1$)
....

Beispiel2: Local Functions in opsi-script

[actions]
DefVar $mystr$
DefVar $str1$
DefStringlist $list1$
DefStringlist $list2$

set $str1$ = 'ha'

DefFunc myFunc1(val $str1$ : string, $list1$ : stringlist) : stringlist
        set $result$ = createStringlist($str1$ , takeString(2,$list1$))
endfunc

set $list2$ = splitstring("/etc/opsi/huhu","/")
set $list1$ = myFunc1("hi",$list2$)

• Erwartete Ergebnisse: $list1$ = [hi,opsi]

Beispiel3: Local Functions in opsi-script

[actions]
DefFunc myFunc2($str1$ : string) : string
        if $str1$ > "0"
                set $result$ = "true"
        else
                set $result$ = "false"
        endif
endfunc
if stringtobool(myfunc2("1"))
        comment "true"
else
        comment "false"
endif

• Erwartete Ergebnisse: true

Beispiel4: Local Functions in opsi-script

(defined_functions3.opsiscript)

[actions]
DefVar $mystr$

DefFunc myFunc3($str1$ : string) : string
        DefVar $locstr1$
        set $locstr1$ = '123'
        set $result$ = $locstr1$ + $str1$
endfunc

set $mystr$ = myFunc3("he")

• Erwartete Ergenisse: 123he

Beispiel5: Local Functions in opsi-script

[actions]
DefVar $mystr$

DefFunc myFunc4($str1$ : string) : string
        DefVar $locstr1$

        DefFunc myFunc5($str1$ : string) : string
                set $result$ = 'inner' + $str1$
        endfunc

        set $locstr1$ = '123'
        set $result$ = $str1$ + myFunc5($locstr1$)
endfunc

set $mystr$ = myFunc4("outer")

• Erwartete Ergebnisse: outerinner123

Beispiel6: Local Functions in opsi-script

[actions]
DefStringlist $list1$
DefFunc myFunc8($str1$ : string) : stringlist
        DefStringlist $loclist1$
        set $loclist1$ = getoutstreamfromsection("shellInAnIcon_test")
        set $result$ = $loclist1$

        [shellinanicon_test]
        set -x
        $str1$
endfunc
if GetOS = 'Linux'
        set $list1$ = myFunc8('set -x ; pwd')
else
        set $list1$ = myFunc8('echo %cd%')
endif

Beispiel6: Erwartete Ergebnisse:

The value of the variable "$list1$" is now:
(string   0)
(string   1)W:\opsi-script-test\CLIENT_DATA\standalone-tests>echo W:\opsi-script-test\CLIENT_DATA\standalone-tests
(string   2)W:\opsi-script-test\CLIENT_DATA\standalone-tests

Importlib

• Die Auslagerung von local functions in externe Dateien und um die Möglichkeit diese aus unterschiedlichen Scripten heraus aufzurufen.

`importLib` <string expr>  ; import library // since 4.12.0.0
<string expr> : <file name>[.<file extension>][`::`<function name>]
Wenn keine '.<file extension>' (Dateierweiterung übergeben wird, so wird `.opsiscript` als Default verwendet.
Wenn kein '::<function name>' über geben wird, so werden alle Funktionen der angegebenen Datei importiert.

Importlib Erläuterung

• <file name> ist:
  • Ein kompletter Pfad zu einer Datei. [W/L]
  • Eine Datei in %ScriptPath% [W/L]
  • Eine Datei in %opsiScriptHelperPath%\lib [W] (Entspricht: %ProgramFiles32Dir%\opsi.org\opsiScriptHelper\lib)
  • Eine Datei in %ScriptPath%/../lib //since 4.11.5.2 [W/L]
  • Eine Datei in %WinstDir%\lib [W]
• Die Prüfung erfolgt in dieser Reihenfolge. Die erste Datei die gefunden wird, wird genommen.

Importlib Beispiel

DefFunc myFunc(val $str1$ : string, $str2$ : string) : string
        set $result$ = $str1$ + $str2$
endfunc

Importlib Beispiel

[actions]
DefVar $mystr$
DefVar $str1$

importLib "%scriptpath%\myfirstlib.opsiscript"

set $str1$ = 'ha'


set $mystr$ = myFunc("he","ho")
set $mystr$ = myFunc("he",timeStampAsFloatStr)
set $mystr$ = myFunc("he",$str1$)

Importlib Beispiel Varianten

Die Zeile
importLib "%scriptpath%\myfirstlib.opsiscript"
könnte auch folgende Form haben:

• importLib "myfirstlib.opsiscript"
  denn %scriptpath% ist im Suchpfad;
  
• importLib "myfirstlib"
  denn die extension .opsiscript ist der Default;
  
• importLib "myfirstlib.opsiscript::myFunc"
  Würde gezielt nur diese Funktion importieren.

opsi-script: Local Functions / Libraries: Missing Features (Roadmap)

• proceduren (void functions): Funktionen die keinen Rückgabewert haben
• function(): Funktionen die keine Parameter haben
• boolean functions: Funktionen die (true / false) zurückliefern
  
  • Workaround: Stringfunktion welche ("true"/"false") zurückliefert und diese mit stringToBool() wandeln.
• config: debug_lib: Das Ausschalten des Logging für Libraries funktioniert noch nicht
• syntax Fehlermeldungen mit richtiger Quellenangabe
  
  • Bei Syntax Fehlern in Libraries wird noch nicht die korrekte Zeile in der korrekten Datei angezeigt
• importlib innerhalb von functions: Lädt momentan die Library als lokale Funktion

Übersicht und Anforderungen

• Struktur: Gliederung in Dateien nach Funktionsgruppen
• Namespace
• Dokumentation der Funktionen
• Zentrale Versionskontrolle, Bereitstellung und Download
• Test der Funktionen

Struktur: Gliederung in Dateien nach Funktionsgruppen

• Gliederung in Dateien nach Funktionsgruppen

Namespace

Namespace:

Ob und wie sollen die Funktionen aus dieser Library am Namen erkennbar sein ?
z.B. opsi als Post- oder Prefix ?

Dokumentation der Funktionen

Damit Funktionen einer Library auch verwendet werden, müssen sie nach Funktion und Syntax auffindbar sein.
D.h. sie müssen dokumentiert und in einer zentralen Dokumentation aufgefürt sein. Dazu wird zur Zeit ein Werkzeug entwickelt, welches auf Basis von Kommentaren innerhalb der Funktion eine Dokumentation in den Formaten HTML, PDF, ASCIIDOC erstellen kann.

Zentrale Versionskontrolle, Bereitstellung und Download

Wir planen die Bereitstellung der Library in unserem öffentlichen Versionskontrollsystem GIT.
Zur Verteilung soll die Library natürlich auch als opsi-Paket Bereitgestellt werden

Test der Funktionen

Für die Funktionen müssen Tests bereit stehen:

• Diese sind als Beispiele der Dokumentation hilfreich
• Überprüfung für die Entwicklenden der Funktionen
• Überprüfung für die zentrale opsi-script Entwicklung