Eigene Software einbinden
Für die Installation von Software ist bei opsi der Client-Agent bzw. das Setup-Programm opsi-script zuständig. Wenn Sie also eigene Software paketieren, müssen Sie zu jedem Produkt auch ein opsi-script-Skript erstellen. Dieses packen Sie anschließend zusammen mit den Installationsdateien und den Metadaten zu einem opsi-Produkt, das Sie auf dem opsi-Server installieren (siehe Kapitel Produkte auf opsi-Server bereitstellen).
Tutorial: opsi-script-Skript erstellen
Dieses Tutorial kann eine Schulung oder das Studium der Handbücher nicht vollständig ersetzen. Es soll lediglich eine Einführung bieten. Daher verweisen wir zuerst auf weiterführende Quellen:
-
Schulungen:
Die uib GmbH bietet opsi-Schulungen in Mainz, bei Ihnen vor Ort und online an:
https://uib.de/de/support-schulung/schulung/ -
Handbücher:
-
Wir stellen mehrere Handbücher für unterschiedliche opsi-Versionen auf Deutsch und auf Englisch bereit:
https://docs.opsi.org/ -
Für dieses Tutorial empfehlen wir besonders das opsi-script-Kapitel.
-
-
Blog:
Aktuelle Neuigkeiten zu opsi, Ankündigungen, Release Notes, Tipps und Tricks lesen Sie im opsi-Blog:
https://opsi.org/de/blog/ -
Wiki:
Unser opsi-Wiki finden Sie hier: https://wiki.opsi.org/ -
Support-Forum:
Das opsi-Forum (Community-Support, Ankündigungen und News) finden Sie hier: https://forum.opsi.org
Nicht-interaktive Software-Installation (macOS)
Apple hat (im Gegensatz zu Microsoft) sehr früh die Methoden zur Software-Installation standardisiert. Im Wesentlichen gibt es diese zwei Methoden:
-
Programm-Verzeichnis:
Im Ordner/Applicationsliegen Verzeichnisse für macOS-Programme; sie heißen<Programm>.app. Der Finder zeigt solche Verzeichnisse allerdings nicht als Ordner an, sondern stellt sie als Programmstarter im Verzeichnis Programme dar. In einem solchen<Programm>.app-Verzeichnis befinden sich Daten (Dateien und Unterverzeichnisse) für die jeweilige Anwendung. Zur Installation muss ein solches Verzeichnis nur in den Ordner/Applicationskopiert werden. Unter Umständen müssen Sie Dateien im UnterverzeichnisMacOSausführbar machen. Solche.app-Verzeichnisse werden meist gepackt zum Download angeboten. Ein typischer Aufbau sieht so aus:
opsi-script-gui.app
|--Contents
|-Info.plist
|-PkgInfo
|-MacOS
| |-opsi-script-gui
| |-opsi-script
| |- […]
|
|-Resources
|- […]-
PKG-Datei:
Apples Paketformat; solche Dateien enthalten die Software und die vorher beschriebene Ordnerstruktur, Installations-Skripte und andere Ressourcen.
Für beide Varianten ist eine Unattended-Installation ohne Interaktion der Benutzer problemlos möglich.
macOS-Software steht häufig in gepackten Formaten als .zip-, .dmg- oder .tgz-Datei zur Verfügung. opsi-script kann diese Applikationen ebenfalls installieren. .tgz-Dateien müssen Sie vorher entpacken.
|
Struktur eines opsi-script-Skriptes
Die nächsten Abschnitte erläutern die wesentlichen Elemente eines opsi-script-Skriptes für Windows-Rechner. So sieht beispielsweise ein einfaches Skript aus:
[Actions]
WinBatch_tightvnc_silent_install
[WinBatch_tightvnc_silent_install]
"%ScriptPath%\tightvnc-1.3.9-setup.exe" /silentEin opsi-script-Skript besteht aus primären und sekundären Sektionen. Genau wie bei INI-Dateien leitet der Name in eckigen Klammern eine Sektion ein.
Die eigentlichen Arbeiten zur Software-Installation finden in den sekundären Sektionen statt, die von den primären Sektionen aufgerufen werden. Die sekundären Sektionen sind themenspezifisch und folgen einer speziellen Syntax: Der Name beginnt mit mit dem Typ, gefolgt von einem frei definierbaren Namen.
Im letzten Beispiel ruft die primäre Sektion [Actions] eine sekundäre Sektion [WinBatch_tightvnc_silent_install] auf; diese ist vom vom Typ WinBatch. Der Inhalt einer WinBatch-Sektion wird über die Windows-API ausgeführt. In diesem Fall wird das angegebene Setupprogramm tightvnc-1.3.9-setup.exe mit dem Parameter /silent gestartet.
Primäre Sektionen
-
Actions/Aktionen: Die
[Actions]-Sektion ist das eigentliche Hauptprogramm. Hier beginnt die Skript-Verarbeitung. -
Sub-Sektionen: Programmabschnitte, die wiederholt benötigt werden, können in Sub-Sektionen (Unterprogramme) ausgelagert werden. Sie können Sub-Sektionen auch in externe Dateien auslagern.
Die primären Sektionen (also die Hauptprogramme) steuern den Ablauf des Skriptes. Hier können Sie Variablen, bedingte Anweisungen, Funktionen usw. verwenden. Lesen Sie dazu auch den Abschnitt Elementare Befehle für primäre Sektionen.
Sekundäre Sektionen
-
Files: Für Datei-Operationen, wie beispielsweise
-
Kopieren (mit Versionskontrolle, rekursiv, usw.)
-
Löschen
-
Verzeichnisse anlegen
-
usw.
-
-
WinBatch: Dient zum Aufrufen von Programmen über die Windows-API. So werden in diesen Sektionen beispielsweise Setup-Programme im nicht-interaktiven Modus ausgeführt.
-
ShellScript: Der Inhalt dieser Sektion wird der Standard-Shell des jeweiligen Betriebssystems zur Ausführung übergeben. Bei Windows ist das die
cmd.exe, bei Linux und bei macOS diebash. Hier können also normale Batch-Skripte abgelegt werden. -
ExecWith: Der Inhalt dieser Sektionen wird einem externen Programm (wie einem Interpreter) zur Ausführung übergeben. Beispielsweise können über
ExecWithAutoIt-Skripte direkt insopsi-script-Skript integriert werden. -
Registry: In diesen Sektionen stehen Anweisungen zum Bearbeiten der Windows-Registry.
-
LinkFolder: In diesen Sektionen erstellen bzw. entfernen Sie Verknüpfungen, z. B. zum Desktop oder ins Startmenü.
Globale Konstanten
opsi-script unterstützt ebenfalls globale Konstanten. Es handelt sich um Platzhalter, die Sie in primären und sekundären Sektionen einsetzen können. Mit solchen Konstanten stellen Sie sicher, dass Pfade in unterschiedlichen Umgebungen (z. B. auf Systemen mit unterschiedlichen Sprachen oder Betriebssystem-Versionen) richtig gesetzt sind.
Hier ein paar Beispiele:
-
%ProgramFiles64Dir%:
c:\program files(auf einem 64 Bit System) -
%ProgramFiles32Dir%:
c:\program files (x86)(auf einem 64 Bit System) -
%SystemRoot%:
c:\windows -
%System%:
c:\windows\system32 -
%opsiTmpDir%:
c:\opsi.org\tmp -
%ScriptPath%: <Pfad zu laufendem Skript>
Beispiel: TightVNC installieren
Zur Erläuterung drucken wir hier ein weiteres Beispiel-Skript ab. Zur Installation des Programms wäre hier der Silent-Aufruf der setup.exe in der sekundären Sektion WinBatch_tightvnc_silent_install ausreichend; bei einer wiederholten Installation erscheint jetzt aber (wegen eines laufenden Services) ein interaktiver Dialog. Wenn das Dialogfenster auftaucht, wird es mit Hilfe von AutoIt geschlossen:
[Actions]
Message "Installiere TightVNC 1.3.9 ..."
ExecWith_autoit_confirm "%ScriptPath%\autoit3.exe" WINST /letThemGo
WinBatch_tightvnc_silent_install
KillTask "autoit3.exe"
[WinBatch_tightvnc_silent_install]
"%ScriptPath%\tightvnc-1.3.9-setup.exe" /silent
[ExecWith_autoit_confirm]
; Wait for the confirm dialog which only appears if tightvnc was installed before as service
; Waiting for the window to appear
WinWait("Confirm")
; Activate (move focus to) window
WinActivate("Confirm")
; Choose answer no
Send("N")Weitere Details zur Verwendung von AutoIt finden Sie hier:
Setup mit automatisierten Antworten.
Elementare Befehle für primäre Sektionen
Die nächsten Abschnitte erklären kurz die elementaren Befehle für primäre Sektionen in opsi-script-Skripten, darunter Variablen, Anweisungen, bedingte Anweisungen, Funktionen usw. Eine vollständige Referenz finden Sie im opsi-script-Kapitel.
String-Variablen
- Variablen-Deklaration
-
DefVar <variable name> [= <initial value>] - Variablen-Zuweisung
-
Set <variable name> = <value>
Im folgenden Beispiel wird eine Variable $ProductId$ deklariert und ihr der Wert "firefox" zugewiesen:
DefVar $ProductId$
Set $ProductId$ = "firefox"Alternativ geht es auch kürzer:
DefVar $ProductId$ = "firefox"| String-Variablen werden in primären und sekundären Sektionen unterschiedlich behandelt. In primären Sektionen sind es eigenständige Objekte, in sekundären Sektionen werden sie vor der Ausführung der Sektion durch den Inhalt der Variable ersetzt. Achten Sie besonders darauf, wenn Sie entsprechende String-Ausdrücke im Skript mit Copy & Paste kopieren/einfügen. |
Demzufolge können Sie String-Variablen nur in primären Sektionen deklarieren und ihnen Werte zuweisen. Die Verbindung von Variablen und Strings zu einem String-Ausdruck benötigt den Operator "+":
"Installing "+ $ProductId$ +" ..."In sekundären Sektionen werden String-Variablen vor der Ausführung der Sektion durch den Inhalt der Variable ersetzt:
"Installing $ProductId$ ..."Das hat den Vorteil, dass Sie in Sektionen, die außerhalb des Skriptes ausgeführt werden (ExecWith, ShellScript), problemlos mit opsi-script-Variablen arbeiten können.
Anweisungen: Message und ShowBitmap
Zur Textausgabe während der Installation verwenden Sie Message <string>; <string> ersetzen Sie durch den tatsächlichen Text, den Sie anzeigen möchten:
Message "Installing "+ $ProductId$ +" ..."Anstelle von Textnachrichten können Sie auch Grafiken (ShowBitmap) in den Formaten während der Installation anzeigen. Die Bilder müssen als BMP-, JPG- oder PNG-Datei im Format 160 x 160 Pixel vorliegen. Optional ist über subtitle eine Beschriftung möglich:
ShowBitmap "%ScriptPath%\python.png" "Python"Bedingte Anweisungen: if, elseif/else und endif
Sie können auch Code abhängig von einer bestimmten Bedingung ausführen:
-
if: Das ist die erste Bedingung. Ist sie wahr (true), werden die im folgenden Block eingeschlossenen Anweisungen ausgeführt. Ist sie falsch (false), wird dieser Block übersprungen. -
;statement(s): Das ist der Codeblock, der ausgeführt wird, wenn die Bedingung imif-Teil wahr ist. Hier können eine oder mehrere Anweisungen stehen, die ausgeführt werden, wenn die Bedingung erfüllt ist. -
elseif <condition>: Dieser Teil ist optional. Wenn die Bedingung imif-Teil nicht erfüllt ist, wird die Bedingung hier überprüft. Wenn diese Bedingung wahr ist, werden die im folgenden Block eingeschlossenen Anweisungen ausgeführt. Dies ermöglicht das Hinzufügen zusätzlicher Bedingungen, die überprüft werden, wenn die vorherigen Bedingungen nicht erfüllt sind. -
else: Dieser Teil ist ebenfalls optional. Wenn keine der vorherigen Bedingungen wahr ist, werden die Anweisungen imelse-Block ausgeführt. Der Block ist also eine Art Fallback und wird dann ausgeführt, wenn keine der vorherigen Bedingungen zutrifft. -
endif: Dass markiert das Ende des bedingten Konstrukts. Es zeigt an, dass die bedingte Überprüfung hier endet.
if <condition>
;statement(s)
[elseif <condition>
;statement(s)]
[
else
;statement(s)
]
endifFunktionen
-
HasMinimumSpace: Prüft auf freien Platz auf der Festplatte.
-
FileExists: Prüft auf Existenz einer Datei oder eines Verzeichnisses.
Kommentare, Fehler und Logging
-
Kommentarzeichen: Zeilen, die mit einem Semikolon (
;) beginnen, werden nicht interpretiert. -
Comment: Schreibt einen Kommentar in die Logdatei.
-
LogError: Schreibt eine Fehlermeldung in die Logdatei.
-
IsFatalError: Bricht die Ausführung des laufenden Skriptes ab und meldet die Installation als gescheitert zurück.
Bedingung zur Ausführung
-
requiredOpsiscriptVersion: Gibt die (mindestens) benötigte
opsi-script-Version an:
requiredOpsiscriptVersion >= "4.12.3.6"Weitere wichtige opsi-script-Funktionen
-
String-Listen: String-Listen sind sehr mächtig, insbesondere zur Auswertung von Ausgaben externer Programme (siehe Abschnitt Verarbeitung von String-Listen).
-
Funktion
ExitWindows: Neustart/Herunterfahren des Systems undopsi-scriptbeenden-
ExitWindows /Reboot: Neustart des Rechners nach Abschluss des laufenden Skriptes -
ExitWindows /ImmediateReboot: sofortiger Neustart -
ExitWindows /ImmediateLogout: Skript-Bearbeitung undopsi-scriptsofort beenden
-
-
Produkteigenschaften: Für manche Produkte ist es erforderlich, Optionen zur Verfügung zu stellen. Diese werden zur Laufzeit Client-spezifisch ausgewertet (siehe Abschnitt opsi-Produkte erstellen).
Der Zugriff auf die Werte der Propertys geschieht über die Funktion GetProductProperty:
if GetProductProperty("example-property", "no") = "yes"
Files_copy_extra_files
endif-
Encoding: Schreiben Sie Ihre Skripte in UTF-8-Kodierung und setzen Sie dazu an den Anfang der Datei die Anweisung:
encoding=utf8Spezielle macOS-Kommandos
-
GetOS: Gibt das Betriebssystem aus, z. B.Linux,Windows_NT(Windows NT bis Windows 11) odermacOS. -
getMacosVersionInfo: Gibt die macOS-Version aus. -
getMacosVersionMap: Gibt eine Liste von Informationen aus, darunter die Build-Version, den Kernel-Namen, Prozessortyp usw.
| Weiterführende Informationen zu diesen String-Funktionen lesen Sie im Abschnitt String-Funktionen (Betriebssystem ermitteln). |
macOS-Befehle zur Installation
Die nächsten Abschnitte stellen spezielle macOS-Befehle zur Installation von Software vor. Sie stammen aus der opsi-script-Bibliothek uib_macosinstalllib. Dieser Teil der Dokumentation ist in Englisch, da er automatisch aus dem Quellcode generiert wurde.
|
opsi Library uib_macosinstalllib.opsiscript
Local Function install_macos_app
- Definition
-
install_macos_app($myapp$ : string) : string - Description
-
try to install the app given by $myapp$
-
Parameter:
$myapp$-
Type:
String- Calltype:CallByValue -
Parameter
$myapp$Description:
string with path to app to install
-
-
Returns: Returns string "true" if all is ok
-
OnError: Returns string "false"; error counter increased ; Error messages in the log
-
References: Local Function install_macos_pkg,
Local Function install_macos_dmg,
Local Function install_macos_zip,
Local Function install_macos_generic -
Author: Detlef Oertel
-
Date: 28.12.2020
-
Example:
[Actions]
importlib "uib_macosinstalllib"
DefVar $installfile$
DefVar $installresult$
comment "we have a *.app (directory) and install with install_macos_app"
set $installfile$ = "%scriptpath%/files/my_macos_app.app"
set $installresult$ = install_macos_app($installfile$)
if stringtobool($installresult$)
comment "installation succseeded"
else
LogError "installation failed"
endifLocal Function install_macos_pkg
- Definition
-
install_macos_pkg($mypkg$ : string) : string - Description
-
try to install the pkg file given by $mypkg$
-
Parameter:
$mypkg$-
Type:
String- Calltype:CallByValue -
Parameter
$mypkg$Description:
string with path to pkg file to install
-
-
Returns: Returns string "true" if all is ok
-
OnError: Returns string "false"; error counter increased ; Error messages in the log
-
References: Local Function install_macos_app,
Local Function install_macos_dmg,
Local Function install_macos_zip,
Local Function install_macos_generic -
Author: Detlef Oertel
-
Date: 28.12.2020
-
Example:
[Actions]
importlib "uib_macosinstalllib"
DefVar $installfile$
DefVar $installresult$
comment "we have a *.pkg and install with install_macos_pkg"
set $installfile$ = "%scriptpath%/files/my_macos_app.pkg"
set $installresult$ = install_macos_pkg($installfile$)
if stringtobool($installresult$)
comment "installation succseeded"
else
LogError "installation failed"
endifLocal Function install_macos_dmg
- Definition
-
install_macos_dmg($mydmg$ : string) : string - Description
-
try to install the dmg file given by $mydmg$
-
Parameter:
$mydmg$-
Type:
String- Calltype:CallByValue -
Parameter
$mydmg$Description:
string with path to dmg file to install
-
-
Returns: Returns string "true" if all is ok
-
OnError: Returns string "false"; error counter increased ; Error messages in the log
-
References: Local Function install_macos_app,
Local Function install_macos_pkg,
Local Function install_macos_zip,
Local Function install_macos_generic -
Author: Detlef Oertel
-
Date: 28.12.2020
-
Example:
[Actions]
importlib "uib_macosinstalllib"
DefVar $installfile$
DefVar $installresult$
comment "we have a *.dmg and install with install_macos_dmg"
set $installfile$ = "%scriptpath%/files/my_macos_app.dmg"
set $installresult$ = install_macos_dmg($installfile$)
if stringtobool($installresult$)
comment "installation succseeded"
else
LogError "installation failed"
endifLocal Function install_macos_zip
- Definition
-
install_macos_zip($myzip$ : string) : string - Description
-
try to install the zip file given by $myzip$ unzips the file and try to find a installable part (*.app, *.pkg, *.dmg) and try to install this
-
Parameter:
$myzip$-
Type:
String- Calltype:CallByValue -
Parameter
$myzip$Description:
string with path to zip file to install
-
-
Returns: Returns string "true" if all is ok
-
OnError: Returns string "false"; error counter increased ; Error messages in the log
-
References: Local Function install_macos_app,
Local Function install_macos_dmg,
Local Function install_macos_pkg,
Local Function install_macos_generic -
Author: Detlef Oertel
-
Date: 28.12.2020
-
Example:
[Actions]
importlib "uib_macosinstalllib"
DefVar $installfile$
DefVar $installresult$
comment "we have a *.zip and install with install_macos_zip"
set $installfile$ = "%scriptpath%/files/my_macos_app.zip"
set $installresult$ = install_macos_zip($installfile$)
if stringtobool($installresult$)
comment "installation succseeded"
else
LogError "installation failed"
endifLocal Function install_macos_generic
- Definition
-
install_macos_generic($myfile$ : string) : string - Description
-
try to install the file given by $myfile$ Checks if the file is a well known installable (*.app, *.pkg, *.dmg, *.zip) and try to install this
-
Parameter:
$myfile$-
Type:
String- Calltype:CallByValue -
Parameter
$myfile$Description:
string with path to pkg file to install
-
-
Returns: Returns string "true" if all is ok
-
OnError: Returns string "false"; error counter increased ; Error messages in the log
-
References: Local Function install_macos_app,
Local Function install_macos_dmg,
Local Function install_macos_zip,
Local Function install_macos_pkg -
Author: Detlef Oertel
-
Date: 28.12.2020
-
Example:
see: install_macos_generic
[Actions]
importlib "uib_macosinstalllib"
DefVar $installfile$
DefVar $installresult$
comment "we have a *.* and install with install_macos_generic"
set $installfile$ = "%scriptpath%/files/opsi-script.app"
set $installresult$ = install_macos_generic($installfile$)
if stringtobool($installresult$)
comment "installation succseeded"
else
Error "installation failed"
endifBeispiel: macOS-Template m-opsi-template
Dieses Template können Sie mit dem opsi-setup-detector erstellen (siehe Abschnitt opsi-setup-detector: Skript erstellen).
declarations.opsiinc: Variablen-Deklaration/Declaration of Variables; ----------------------------------------------------------------
; This is a opsi-script file.
; See https://opsi.org https://uib.de
; This code was originally created by opsi-setup-detector 4.2.2.3
; ----------------------------------------------------------------
encoding=utf8
; -------------------------------------
; include file for opsi-setup-detector products
; Define all variables here
;---------------------------
DefVar $arch$
DefVar $errorstring$
DefVar $exitcode$
DefVar $iconfile$
DefVar $installerSourceDir$
DefVar $installCommand$
DefVar $installSuccess$
DefVar $installdir$
DefVar $installdir1$
DefVar $installdir2$
DefVar $installerfile$
DefVar $minimumspace$
DefVar $oldProgFound$
DefVar $os$
DefVar $osshort$
DefVar $ProdVersion$
DefVar $productid$
DefVar $targetfile$
DefVar $tmpstr$
DefVar $targetprogram$setup.opsiscript: Installations-Skript/Script for Installation; ----------------------------------------------------------------
; This is a opsi-script file.
; See https://opsi.org https://uib.de
; This code was originally created by opsi-setup-detector 4.2.2.3
; ----------------------------------------------------------------
encoding=utf8
[Actions]
requiredOpsiscriptVersion >= "4.12.4.23"
importlib "uib_exitcode.opsiscript"
importlib "osd-lib.opsiscript"
importlib "uib_macosinstalllib.opsiscript"
; All variables are defined here:
include_insert "declarations.opsiinc"
; ----------------------------------------------------------------
; Please edit the following values:
; ----------------------------------------------------------------
; $ProductId$ is the name of the product in opsi, only lower letters, no umlauts, no white spaces, use '-' as a separator
Set $ProductId$ = "m-opsi-template"
; the path were we find the product after the installation
;Set $InstallDir$ = "/Applications/<product.app>"
Set $InstallDir$ = "/Applications/<productid.app>"
; ----------------------------------------------------------------
Message "Installing " + $ProductId$ + " ..."
set $OS$ = GetOS
if not(($OS$ = "macos"))
logError "Installation aborted: wrong OS version: only MacOS"
isFatalError "wrong OS"
endif
comment "Show product picture"
ShowBitmap "%ScriptPath%/" + $ProductId$ + ".png" $ProductId$
if FileExists("%ScriptPath%\delinc.opsiinc")
comment "Start uninstall part"
include_insert "%ScriptPath%\delinc.opsiinc"
endif
Message "Installing " + $ProductId$ + " ..."
set $installerSourceDir$ = ""
comment "Start installer "
ChangeDirectory $installerSourceDir$
;----------------------------------------------
set $installSuccess$ = install_macos_generic("%SCRIPTPATH%/files1/<my macos install file>")
;----------------------------------------------
if $installSuccess$ = "false"
LogError "Installation failed"
isfatalerror "Installation failed"
else
Comment "Installation success"
endif
comment "Copy files"
Files_install
[Files_uninstall]
del -sf "$InstallDir$/"
[Files_install]
; Example of recursively copying some files into the installation directory:
;
; copy -s "%ScriptPath%\files\*.*" "$InstallDir$"
; ----------------------------------------------------------------
; ----------------------------------------------------------------delinc.opsiinc: Deinstallations-Skript (Include)/Script for Deinstallation (Include); ----------------------------------------------------------------
; This is a opsi-script file.
; See https://opsi.org https://uib.de
; This code was originally created by opsi-setup-detector 4.2.2.3
; ----------------------------------------------------------------
encoding=utf8
Message "Check for existing installation of " + $ProductId$ + " ..."
comment "Start the Uninstall check:"
set $oldProgFound$ = "false"
if directoryExists($InstallDir$)
set $oldProgFound$ = "true"
endif
if $oldProgFound$ = "true"
comment "Is the Installdir in the Applications directory ?"
if "1" = strPos(lower($InstallDir$),lower("/Applications/"))
comment "Do not delete the whole /Applications dir ..."
if not(lower($InstallDir$) = lower('/Applications/'))
Message "Uninstalling " + $ProductId$ + " ..."
Files_uninstall
endif
endif
endif
;-----------------------------------------------------uninstall.opsiscript: Deinstallations-Skript/Script for Deinstallation; ----------------------------------------------------------------
; This is a opsi-script file.
; See https://opsi.org https://uib.de
; This code was originally created by opsi-setup-detector 4.2.2.3
; ----------------------------------------------------------------
encoding=utf8
[Actions]
requiredOpsiscriptVersion >= "4.12.4.23"
importlib "uib_exitcode.opsiscript"
importlib "osd-lib.opsiscript"
importlib "uib_macosinstalllib.opsiscript"
; All variables are defined here:
include_insert "declarations.opsiinc"
; ----------------------------------------------------------------
; Please edit the following values:
; ----------------------------------------------------------------
; $ProductId$ is the name of the product in opsi, only lower letters, no umlauts, no white spaces, use '-' as a separator
Set $ProductId$ = "m-opsi-template"
; the path were we find the product after the installation
;Set $InstallDir$ = "/Applications/<product.app>"
Set $InstallDir$ = "/Applications/<productid.app>"
; ----------------------------------------------------------------
Message "Uninstalling " + $ProductId$ + " ..."
set $OS$ = GetOS
if not(($OS$ = "macos"))
logError "Installation aborted: wrong OS version: only macos"
isFatalError "wrong OS"
endif
comment "Show product picture"
ShowBitmap "%ScriptPath%/" + $ProductId$ + ".png" $ProductId$
if FileExists("%ScriptPath%\delinc.opsiinc")
comment "Start uninstall part"
include_insert "%ScriptPath%\delinc.opsiinc"
endif
[Files_uninstall]
del -sf "$InstallDir$/"
; ----------------------------------------------------------------
; ----------------------------------------------------------------opsi-Produkte erstellen
Die nächsten Abschnitte erklären, wie Sie Software paketieren, also opsi-Produkte erstellen. Der grundlegende Ablauf sieht so aus:
-
Den "Rohbau" eines Paketes erstellen Sie mit dem
opsi-setup-detector(siehe Abschnitt opsi-setup-detector: Skript erstellen). -
Danach testen Sie das
opsi-script-Skript (siehe Abschnitt Skript testen und verbessern). -
Mit dem opsi PackageBuilder (oPB) erstellen Sie aus der Rohform ein opsi-Paket und hinterlegen es auf dem opsi-Server.
Vorbereitungen
Zum Erstellen von opsi-Paketen benötigen Sie die folgenden Werkzeuge:
opsi-setup-detector installieren
Den opsi-setup-detector gibt es derzeit für Windows, Linux und macOS. Sie können das Programm direkt über opsi installieren. Es gehört zu den Standard-Localboot-Produkten und sollte bereits auf dem opsi-Server vorhanden sein. Ist das nicht der Fall, stellen Sie das Produkt über den folgenden Befehl bereit:
opsi-package-updater install opsi-setup-detector
Das Localboot-Produkt opsi-setup-detector erfordert ebenfalls die Installation des Produktes opsipackagebuilder_wlm, denn der Setup-Detector verwendet den PackageBuilder (sofern dieser vorhanden ist).
|
Installieren Sie daher ebenfalls das Produkt opsipackagebuilder_wlm:
opsi-package-updater install opsipackagebuilder_wlmAnschließend rollen Sie die beiden Produkte auf den gewünschten Clients aus, beispielsweise über die Management-Oberfläche opsi-configed.
| Für Windows-Rechner bieten wir den Setup-Detector auch als eigenständiges Paket an, das Sie unabhängig von opsi installieren können: https://tools.43.opsi.org/stable/ |
Unterschiede unter Windows, Linux, Mac
Grundsätzlich funktioniert der opsi-setup-detector auf allen drei Betriebssystemen ähnlich. Zur Analyse einer Installationsdatei ruft das Programm aber unterschiedliche Hilfsprogramme auf:
-
Genaue Analysen von Inno Setups unter Windows verwenden das integrierte Tool
innounpack.exe. Diese Detailanalyse ist daher nur unter Windows möglich. -
Zur Arbeit mit dem Windows Installer XML (kurz WiX Toolset) wird unter Windows das integrierte Werkzeug
Dark.exeverwendet. Diese Detailanalyse ist daher nur unter Windows möglich. -
.deb- bzw..rpm-Pakete analysieren die entsprechenden Standard Paketverwaltungstools unter Linux. Diese Detailanalyse ist daher nur auf Linux-Rechnern möglich.
opsi PackageBuilder installieren
Der opsi PackageBuilder (oPB) steht für Windows, Linux und macOS zur Verfügung.
Das Produkt opsipackagebuilder_wlm gehört zu den opsi-Standardprodukten. Falls es noch nicht auf Ihrem Server installiert ist, spielen Sie es über diesen Befehl ein:
opsi-package-updater install opsipackagebuilder_wlmAnschließend können Sie das Localboot-Produkt auf den Clients ausrollen, beispielsweise über die Management-Oberfläche opsi-configed.
Alternativer Weg zum Produkt:
Sie können opsi PackageBuilder (oPB) entweder als opsi-Produkt auf dem opsi-Server installieren und dann über opsi-configed ausrollen oder eines der im forum.opsi.org - opsi PackageBuilder verlinkten Installationspakete verwenden.
| Der opsi PackageBuilder (oPB) ist ein Community-Produkt und wird von Holger Pandel entwickelt — vielen Dank! |
Die Quellen und Lizenz finden sie hier: GitHub: opsi PackageBuilder (oPB)
opsi-logviewer installieren
Den opsi-logviewer gibt es derzeit für Windows, Linux und macOS. Er gehört zur Management-Oberfläche opsi-configed und wird mit dieser zusammen ausgeliefert.
Das Paket opsi-configed gehört zu den opsi-Standardprodukten und sollte auf Ihrem opsi-Server installiert sein. Falls nicht, spielen Sie es mit diesem Kommando ein:
opsi-package-updater install opsi-configed
Eine ausführbare Version der Management-Oberfläche opsi-configed für Windows, Linux und macOS finden Sie auf unserer Website opsi-Tools.
|
opsi-setup-detector: Skript erstellen
Die folgenden Abschnitte erklären detailliert, wie Sie mit dem opsi-setup-detector ein opsi-Produkt eine Setup-Datei analysieren und ein opsi-Produkt erstellen.
Start und Konfiguration
Unter Windows starten Sie den opsi-setup-detector aus dem Startmenü heraus; Sie finden das Werkzeug unter opsi.org / opsi-setup-detector. Unter macOS finden Sie den opsi-setup-detector über Programme und unter Linux in den Startmenüs unter Systemwerkzeuge. Auf den meisten Linux-Desktopumgebungen können Sie außerdem den vollen Pfad zur ausführbaren Datei (/opt/opsi-setup-detector/opsisetupdetector) in ein Schnellstartfenster ([Alt]+[F2]) oder Terminal eingeben.
Unter Windows können Sie den opsi-setup-detector direkt aus dem Explorer heraus starten. Wenn Sie mit der rechten Maustaste auf ein Setup-Programm einer Applikation klicken, finden Sie im Kontextmenü einen Eintrag, über den Sie das Tool zur Analyse starten.
|
Nach dem ersten Start erscheint ein Dialog, der Sie zur Konfiguration führt. Die folgenden drei Angaben sind unbedingt erforderlich:
-
fullName: Tragen Sie Ihren Namen ein, wie er später in der Dateichangelog.txtauftauchen soll. -
email_address: Tragen Sie Ihre Mailadresse ein, wie sie später in der Dateichangelog.txtauftauchen soll. -
workbench_Path: Hier geben Sie den Pfad zum Verzeichnis an, in dem Sie die opsi-Pakete erstellen.
Idealerweise ist das der Pfad zur Freigabe, an der die Workbench Ihres opsi-Servers gemountet ist (siehe Kapitel Samba).
Darüber hinaus können Sie optional weitere Einstellungen vornehmen. Für den opsi-Webservice opsiconfd (https://<opsi-server>:4447, siehe Kapitel Der Dienst opsiconfd) füllen Sie die folgenden Felder aus:
-
Service_URL: URL des opsi-Webservices (im Formathttps://<opsi-server>:4447) -
Service_user: Benutzername für die Verbindung zum opsi-Webservice -
Service_pass: Passwort des unterService_usereingetragenen Benutzers für die Verbindung zum opsi-Webservice: lassen Sie das Feld leer, dann fragt deropsi-setup-detectorbei Bedarf nach.
| Mögliches Sicherheitsrisiko: Auch wenn das Passwort verschlüsselt abgespeichert wird, so lässt es sich doch nach einer Analyse des (offenen) Quellcodes entschlüsseln. |
Weitere optionale Einstellungen sind:
-
control_in_toml_format: Checkbox aktivieren, um einecontrol-Datei im TOML-Format zu erzeugen (siehe Abschnitt Beispiel: control-Datei);
Achtung: Dazu ist mindestens opsi 4.3 erforderlich! -
dependencies_for_all_actionrequests: Sollen Abhängigkeiten auch für andere Action Requests (aussersetup) erlaubt sein?
Achtung: Dazu ist mindestens opsi 4.3 erforderlich, bitte mit äußerster Vorsicht verwenden!
| Eine ausführliche Beschreibung aller Einstellungen finden Sie im Kapitel opsi-setup-detector (frei). |
Nach dem Speichern der Konfiguration erscheint die Startseite.
Onlinehilfe
Klicken Sie auf das Fragezeichen, um die Onlinehilfe zum opsi-setup-detector einzublenden.
Wählen Sie die gewünschte Aufgabe aus. Sie finden hier Tasks für Windows, Linux und macOS sowie vom Betriebssystem unabhängige Aufgaben und eine eigene Abteilung für Multiplattform-Pakete.
Unter macOS stehen folgende Funktionen zur Verfügung:
-
Analysiere Datei und erzeuge ein opsi Paket: Ausgehend von einer macOS-Installer-Datei wird hier der gesamte Prozess durchlaufen bis zum Erzeugen eines opsi-Paketes. Das funktioniert genauso, wie für Windows beschrieben (siehe Abschnitt clients:windows-client/softwareintegration.adoc#opsi-setup-detector-use-single-analyze-and-create).
-
Eine opsi Paketvorlage (Template) erzeugen: Fragt nicht nach einer Setup-Datei, sondern erstellt ein opsi-Template-Produkt für macOS und übernimmt dazu die Angaben aus der Produkt-Konfiguration.
Die folgenden Screenshots zeigen die Abläufe für Windows-Installer Dateien, sie sehen unter macOS aber ähnlich aus, wenn Sie Installer-Dateien wie .app, .dmg oder .zip verwenden.
|
Datei analysieren und Paket erzeugen
Die folgenden Abschnitte beschreiben, wie Sie eine Setup-Datei analysieren und daraus ein opsi-Produkt erstellen. Klicken Sie dazu auf der Startseite (Abbildung 6, “Die opsi-setup-detector-Startseite”) auf die Schaltfläche Analysiere eine Datei und erzeuge ein opsi Paket. Danach navigieren Sie im Dateiauswahldialog zur gewünschten .exe- oder .msi-Datei. Der opsi-setup-detector beginnt direkt mit der Analyse.
Analyse
Nach erfolgreicher Analyse einer Setup-Datei sehen Sie diesen Dialog:
War die Analyse nicht erfolgreich, sehen Sie stattdessen diesen Dialog:
Sie können jetzt den Vorgang per Klick auf Cancel abbrechen oder aus dem Drop-down-Menü einen Installertyp auswählen und die Analyse fortsetzen.
Ist die Analyse erfolgreich verlaufen, öffnet sich in einzelnen Fällen ein Fenster mit ergänzenden Informationen zum erkannten Installertyp. Das ist beispielsweise bei Anwendungen wie InstallShield, dem Qt-Installer oder InstallAnywhere der Fall.
Ist die Analyse erfolgreich verlaufen, zeigt der opsi-setup-detector auf jeden Fall das Ergebnis an:
Im Detail finden Sie auf dem Reiter 1. Setup die folgenden Informationen und Funktionen:
-
Erkannter Setup Typ: Typ des erkannten Installers
-
Bevorzuge Silent Installation: Aktivieren Sie diese Checkbox, um (wenn möglich) eine Silent-Installation einer Unattended-Installation vorzuziehen.
-
MST erlaubt: Sollen zusätzliche
mst-Dateien zum Anpassen der Einstellungen für Microsoft-Windows-Installer-Anwendungen (MSI) verwendet werden? -
Info: Link, der weiterführende Informationen zum Installer anzeigt
-
Setup Datei: Pfad und Name der analysierten Setup-Datei
-
MST Datei: Zur Angabe der MST-Datei, die in den Installer-Aufruf integriert werden soll
-
MsiId: Produktcode bei MSI-Installern oder Installern, die MSI enthalten
-
MsiName: Produktname bei MSI-Installern oder Installern, die MSI enthalten; in der Registry als DisplayName hinterlegt
-
Software Version: Version der zu installierenden Software (falls diese ermittelt werden kann)
-
Setup Datei Größe MB: Größe der Setup-Datei in MByte
-
Benötigter Platz MB: geschätzter Wert (Größe der Setup-Datei mal 6), kann gegebenenfalls angepasst werden
-
InstallDir: Verzeichnis, in das die Software installiert werden wird (sofern dieses erkannt wird); falls nicht korrekt erkannt, können Sie über das Ordner-Icon neben dem Feld einen Dateiauswahl-Dialog öffnen und das Verzeichnis festlegen. Pfade wie
C:\program Filesbzw.C:\program Files (x86)werden automatisch durch die entsprechendenopsi-script-Konstanten (z. B.%ProgramFiles32Dir%) ersetzt. -
Kommando zur Installation: ermitteltes Kommando zur nicht-interaktiven Installation; kann abhängig von der Checkbox Bevorzuge Silent Installation unterschiedlich ausfallen
-
Kommando zur Deinstallation: ermitteltes Kommando zur nicht-interaktiven Deinstallation; kann abhängig von der Checkbox Bevorzuge Silent Installation unterschiedlich ausfallen
-
Deinstallations Programm: ermitteltes Programm zur Deinstallation; falls nicht korrekt erkannt, können Sie über das Ordner-Icon neben dem Feld einen Dateiauswahl-Dialog öffnen und zur gewünschten Anwendung navigieren. MSI-Dateien haben (üblicherweise) kein Deinstallations-Programm.
-
Hauptrogramm: Hauptrogramm der zu installierenden Software; wird verwendet, um z. B. Desktopsymbole oder Einträge fürs Starmenü zu erzeugen. Wird nicht automatisch erkannt. Wenn das Produkt bereits auf dem Rechner installiert ist, können Sie über das Ordner-Icon einen Auswahldialog öffnen.
Alle nach der Analyse ermittelten Werte können Sie bei Bedarf korrigieren und/oder ergänzen. Klicken Sie danach auf die Schaltfläche Nächster Schritt, um den ersten Reiter der Produkt-Konfiguration zu öffnen.
| Es ist sehr wahrscheinlich, dass die ermittelten Werte unvollständig oder sogar teilweise falsch sind. Überprüfen Sie nach einer ersten Installation unbedingt die Werte von InstallDir, Deinstallations Programm, Hauptrogramm und Software Version und passen Sie diese gegebenenfalls in Ihrem Skript an! |
Produkt-Konfiguration 1
Auf diesem Reiter nehmen Sie die folgenden Einstellungen vor:
-
opsi Product ID: Das ist der Name des neuen opsi-Paketes. Er wird aus dem Produktnamen (Feld opsi Product Name) erzeugt, wobei Leer- und Sonderzeichen durch Bindestriche ersetzt werden. Die vorgeschlagene Produkt-ID können Sie verändern.
-
Import control File: Öffnet einen Dateiauswahl-Dialog, um Daten aus einer bestehenden
control-Datei (control, control.toml) ins aktuelle Projekt zu importieren. Nicht importiert werden Angaben zu Versionsnummern, Skriptnamen oder dem benötigten Platz. -
opsi Product Name: Den Namen der zu installierenden Software können Sie hier korrigieren.
-
Produkt Version: Die aus dem Namen der Setup-Datei ermittelte Versionsnummer können Sie hier korrigieren; sie darf nur Ziffern und Punkte enthalten, da sie zur Versionierung des opsi-Paketes verwendet wird.
-
Paket-Version: Die Versionsnummer des opsi-Paketes dient zur Unterscheidung von opsi-Produkten, die dieselbe Software in derselben Version enthalten, aber unterschiedliche Skripte oder Propertys haben. Sie darf nur Ziffern und Punkte enthalten, da sie zur Versionierung des opsi-Paketes verwendet wird.
-
Beschreibung: Tragen Sie in dieses Feld eine kurze Beschreibung der Anwendung ein. Seit opsi 4.3 können Sie Markdown für diesen Text verwenden. Links ist der Editierbereich und auf der rechten Seite die Vorschau.
-
Hinweis: Hier ist Platz für ergänzende Hinweise zur Software, wie z. B. Herkunft, Downloadlink, Lizenz usw. Seit opsi 4.3 können Sie Markdown für diesen Text verwenden. Links ist der Editierbereich und auf der rechten Seite die Vorschau.
-
Template Channel: Wählen Sie aus dem Drop-down-Menü eines der folgenden Templates zur Erstellung der Skripte aus:
-
default: Standard und Fallback; wählen Sie ein anderes Template aus, das die notwendigen Dateien für Ihren Task nicht bereitstellt, so wird automatisch default verwendet. Wesentliche Skripte des Produktes sind:
setup.opsiscript,uninstall.opsiscript,declarations.opsiinc,sections.opsiincunddelinc.opsiinc. -
training: einfacher Aufbau mit ausführlichen Kommentaren; wesentliche Skripte des Produktes sind:
setup.opsiscript,uninstall.opsiscriptunddelinc.opsiinc -
structured: Fallback zu default; in Version 4.2.2 und darüber nicht verwendet
-
custom: Ist in der Voreinstellung leer und bietet Platz für eigene Template-Dateien. Dazu kopieren Sie Ihre Templates ins Verzeichnis
opsi-setup-detector/custom/template-files/auf dem Depotserver und installieren danach denopsi-setup-detectorneu auf den entsprechenden Clients.
-
Im unteren Fensterbereich finden Sie außerdem einige Checkboxen, über die Sie zusätzlichen Code und Einstellungen für bestimmte Aufgaben ergänzen:
-
Unterstütze custom directory: Das Produkt bekommt ein zusätzliches Verzeichnis namens
custom, das (kundenspezifische) Anpassungen enthalten kann. Bei der Installation einer neuen Version des Paketes auf dem Server wird ein solchescustom-Verzeichnis nicht überschrieben. Der Code enthält Vorlagen, um Dateien aus diesem Verzeichnis hinzuzufügen (siehe Abschnitt Custom-Verzeichnis).) -
Installiere von lokalem, temporären Verzeichnis: Die Installations-Dateien werden zunächst in ein lokales, temporäres Verzeichnis kopiert und dann von dort aus installiert. Das ist vor allem sinnvoll für alle Komponenten, die während der Installation die Netzwerkverbindung beeinträchtigen könnten, z. B. Treiber (siehe Abschnitt Lokales, temporäres Verzeichnis).
-
Behandle Lizenzkeys: Erzeugt ein zusätzliches Property zur Behandlung von Lizenzschlüsseln hinzu (siehe Abschnitt Lizenzschlüssel).
-
Desktopicon: Erzeugt ein zusätzliches, boolesches Property (Voreinstellung
false) zur Behandlung von Desktopsymbolen hinzu (siehe Abschnitt Desktop-Icon). -
Customize Profile: Ergänzt den Code um einen Abschnitt
ProfileActionsfür Anpassungen in den lokalen Benutzerprofilen (siehe Abschnitt Lokale Benutzerprofile anpassen).
Priorität und Abhängigkeiten
Auf dem Reiter Produkt Konfiguration 2 können Sie Prioritäten und Abhängigkeiten genauer definieren:
| Bei "normaler" Anwendungssoftware müssen Sie hier in der Regel nichts konfigurieren und können auf Nächster Schritt klicken. |
Auf diesem Reiter können Sie folgende Einstellungen vornehmen:
-
Priorität: Beeinflusst die Reihenfolge der Installation; mögliche Werte liegen zwischen 100 (ganz am Anfang) und -100 (ganz am Ende). Für Anwendungssoftware empfohlen: 0. Wenn außerdem Abhängigkeiten existieren, dann beeinflussen diese ebenfalls die Reihenfolge bei der Installation.
-
Abhängigkeiten: Hier können Sie Abhängigkeiten zwischen Produkten definieren. Wenn in der Konfiguration die Zugangsdaten zu Ihrem opsi-Server hinterlegt sind, wird versucht, eine Verbindung zum Server aufzubauen. Haben Sie das Kennwort aus Sicherheitsgründen nicht hinterlegt, dann erfolgt an dieser Stelle die Passwortabfrage (siehe Abschnitt Abhängigkeiten definieren).
-
Properties: Hier definieren Sie (veränderbare) Eigenschaften des Produktes (siehe Abschnitt Propertys definieren).
Abhängigkeiten definieren
Klicken Sie auf die Schaltfläche Dependency hinzufügen, um den Dialog Depency Editor zu öffnen:
Hier können Sie die folgenden Einstellungen vornehmen:
-
Actionrequest zu dem die Abhängigkeit erzeugt werden soll: In der Voreinstellung ist hier setup ausgewählt. Ab opsi 4.3 sind auch andere ActionRequests erlaubt (
uninstall,update,always,customundonce). Verwenden Sie diese Einstellung mit Vorsicht, um nicht Bedingungen zu erzeugen, die ohne Widersprüche nicht auflösbar sind!
Das Drop-down-Menü ist nur dann aktiv, wenn Sie in der opsi-setup-detector-Konfiguration die Option dependencies_for_all_actionrequests aktiviert haben (siehe Abschnitt Start und Konfiguration).
|
-
productId des abhängigen Produkts: Aus dem Drop-down-Menü können Sie das Produkt auswählen, zu dem eine Abhängigkeit besteht. Wenn es eine Verbindung zum opsi-Server gibt, dann zeigt der Dialog dies in grüner Schrift an und listet die installierten Produkte im Menü auf. Besteht die Verbindung nicht, dann sehen Sie einen Hinweis in roter Schrift und müssen die Produkt-ID von Hand eingeben.
-
Abhängigkeits Modus: Wenn Sie ein Meta-Produkt erzeugen, ist dieser Bereich deaktiviert, um unsinnige Einstellungen zu vermeiden. Hier gibt es zwei Optionen zur Auswahl:
-
Aktion: Anforderung für einen ActionRequest, der beim Produkt gesetzt werden soll, zu dem eine Abhängigkeit besteht (setup).
-
Status: Status, den das Produkt haben soll, zu dem eine Abhängigkeit besteht (installed). Liegt ein anderer Status vor, so wird das Produkt auf setup gesetzt.
-
| Die tatsächliche Installations-Reihenfolge ergibt sich aus einer Kombination von Abhängigkeiten und Priorität der Produkte (siehe Abschnitt Abhängigkeiten und Reihenfolge). |
Propertys definieren
Auf dem Reiter Produkt Konfiguration 2 können Sie im unteren Bereich veränderbare Eigenschaften (Variablen) für das Produkt definieren. Klicken Sie dazu auf Property hinzufügen:
| Feld/Funktion | Beschreibung | Hinweise |
|---|---|---|
Property Name |
Name der Produkt-Variable |
Der |
Property Type |
Typ der Variable |
Mögliche Werte sind Text und Boolean. |
Multivalue |
Anzahl der Werte |
Bestimmt, ob die Variable nur genau einen oder mehrere Werte annehmen kann; nur bei Typ Text verfügbar. |
Editierbar |
Werte überschreibbar |
Bestimmt, ob die Vorgabewerte mit neuen oder zusätzlichen Werten überschrieben werden können oder nicht, nur bei Typ Text verfügbar. |
Mögliche Werte |
Eingabewerte |
Durch Kommata getrennte Liste der möglichen Eingabewerte. Falls hier True gesetzt ist, können Sie die Liste später im |
Default Wert |
Vorgabewert |
Auswahlliste; nur bei Typ Text verfügbar: Freitextfeld. Nur bei Typ Multivalue verfügbar: Mehrfachauswahl. |
Produkt-Icon auswählen
Auf diesem Reiter können Sie ein Symbol für das Produkt auswählen, das während der Installation angezeigt wird:
Wenn Sie diesen optionalen Schritt überspringen, wählt der opsi-setup-detector automatisch ein Zahnrad als Icon aus (Default) und wechselt zum nächsten Reiter.
|
Klicken Sie in der rechten Fensterhälfte auf die Schaltfläche Öffne Icon Verzeichnis und navigieren Sie im Auswahldialog zum Ordner mit den gewünschten Icons. Als Vorauswahl sehen Sie ein mit dem opsi-setup-detector mitgeliefertes Verzeichnis 128x128 mit Symbolen, die unter einer freien Lizenz stehen. Nach dem Öffnen des Ordners erscheinen in der linken Hälfte alle Symbole, und Sie können eines für Ihr Produkt auswählen.
Produkt erzeugen
Nachdem die Konfiguration des Produktes abgeschlossen ist, können Sie es auf dem letzten Reiter erzeugen:
Hier stehen die folgenden Optionen zur Verfügung:
-
Pfad zur opsi-work-bench: Hier sehen Sie das bei der Einrichtung konfigurierte Verzeichnis zur Workbench-Freigabe auf Ihrem opsi-Server (Laufwerksbuchstabe oder UNC-Pfad).
-
Über die Schaltfläche Workbench Pfad prüfen können Sie überprüfen, ob die Freigabe erreichbar ist.
-
Im Bereich Erstellungs Modus wählen Sie aus, wie das Paket erstellt wird:
-
Erstelle opsi Produkt Dateien erzeugt (falls noch nicht vorhanden) den Verzeichnisbaum für das neue opsi-Produkt auf der Workbench. Die für das Paket benötigten Dateien werden erzeugt bzw. kopiert.
-
Erstelle opsi Produkt Dateien und baue opsi Paket erzeugt den Verzeichnisbaum und versucht außerdem, das Paket auf dem opsi-Server zu bauen. Ist auf der rechten Seite (Bau Modus) die Checkbox bauen und installieren aktiviert, wird das Produkt nach dem Bauen auch auf dem Server installiert. Wenn Sie in der Konfiguration die Verbindung zum opsi-Webservice eingerichtet haben, wird der Dienst kontaktiert und ggf. nach dem Passwort gefragt.
-
Das Bauen und Installieren über den Webservice gelingt nur, wenn der opsiconfd in Version 4.2.0.287 oder neuer vorliegt. Ist der Service nicht erreichbar oder zu alt, dann übernimmt der opsi PackageBuilder (ohne GUI) und erstellt das Paket.
|
-
Erstelle opsi Produkt Dateien und starte interaktiven Packagebuilder erzeugt (falls noch nicht vorhanden) den Verzeichnisbaum für das neue opsi-Produkt auf der Workbench und startet den opsi PackageBuilder im interaktiven Modus. Diesen müssen Sie explizit beenden, um zum
opsi-setup-detectorzurückzukehren.-
Bau Modus: Die beiden Optionen bestimmen, was bei einem Klick auf opsi Paket erstellen tatsächlich passiert:
-
-
nur bauen erzeugt das opsi-Paket (entspricht dem Befehl
opsi-makepackage). -
bauen und installieren erzeugt das opsi-Paket (
opsi-makepackage) und installiert dieses (entspricht dem Befehlopsi-package-manager --install <paket>).-
opsi Paket erstellen: Per Klick auf diesen Button starten Sie die Paketerstellung. Gibt es bereits ein opsi-Produkt mit demselben Namen, dann erscheint eine Sicherheitsabfrage:
-
-
Nur Paket neu bauen: Dieser Button startet das Bauen des opsi-Paketes, ohne vorher die opsi-Dateien neu zu erzeugen. Die Option eignet sich also dazu, ein Paket neu zu bauen, nachdem Sie in einem Editor Änderungen am Skript vorgenommen haben.
Beim Erstellen des opsi-Produktes schreibt der opsi-setup-detector alle Informationen, die Sie dort hinterlegt haben, in die Datei opsi-project.osd im Hauptverzeichnis des Produktes.
Eine solche opsi-project.osd-Datei können Sie zu einem späteren Zeitpunkt wieder mit dem opsi-setup-detector öffnen, um ein vorhandenes Paket zu modifizieren.
|
Vorhandenes Projekt öffnen
Es gibt zwei Möglichkeiten, eine bestehende Projektstruktur mit dem opsi-setup-detector als Projekt zu öffnen:
-
Wenn das Produkt mit dem
opsi-setup-detectorerstellt wurde, dann können Sie aus dem Menü Datei / Öffnen und die Dateiopsi-project.osdaus dem Hauptverzeichnis des Projektes öffnen. -
Bei Produkten, die nicht mit dem
opsi-setup-detectorerstellt wurden, können Sie stattdessen diecontrol-Datei (control, control.toml) öffnen. Wählen Sie dazu aus dem Menü Datei / Controldatei öffnen und navigieren zurcontrol-Datei im VerzeichnisOPSIdes Produktes.
Letzteres bietet weniger Informationen, insbesondere in Bezug auf die verwendete Setup-Datei des Installers.
Skript testen und verbessern
Zum Testen und Verbessern eines Produktes gibt es zwei verschiedene Varianten:
-
Sie testen das erstellte Skript, ohne es auf dem opsi-Server zu installieren und auf dem Client auszurollen (Standalone-Tests).
-
Sie testen das komplette Produkt, indem Sie es auf dem Server installieren und auf einem Client ausrollen (Integrierte Tests).
Wir gehen im Folgenden davon aus, dass Sie das zu testende Produkt mit dem opsi-setup-detector erstellt haben.
|
Standalone-Tests
Starten Sie die Anwendung opsi-script-gui:
-
Windows: Öffnen Sie
opsi-script.exeper Doppelklick. Wenn der Client-Agent auf dem Rechner installiert ist, finden Sie das Programm unter C:\Program files (x86)\opsi.org\opsi-client-agent\opsi-script\opsi-script.exe. Andernfalls kopieren Sie den Inhalt des Verzeichnissesopsi-script\windows\x86\von der Freigabe\\<opsiserver>\opsi_depotauf den Windows-Rechner.
Unter Windows 10 klicken Sie die Datei opsi-script.exe mit der rechten Maustaste im Explorer an und wählen aus dem Kontextmenü den Eintrag Ausführen als Administrator.
|
-
Linux: Starten Sie
/opt/opsi-script/opsi-script-gui. -
macOS: Starten Sie die Anwendung über das Menü /Applications/opsi-script.
Nach dem Start sehen Sie das folgende Fenster:
Wählen Sie über Select Script das Skript, das Sie testen möchten. Klicken Sie anschließend auf Start. Das Skript wird nun auf diesem Rechner ausgeführt. Alternativ klicken Sie auf Test_Syntax, um das Skript auf Syntaxfehler zu prüfen. Es wird dabei nicht auf dem Rechner ausgeführt (siehe Abschnitt Skript-Syntax prüfen).
Mit dem opsi-logviewer können Sie nun nachvollziehen, wie opsi-script das Skript interpretiert.
Über den Schieberegler rechts unten im opsi-logviewer können Sie den Loglevel verändern und damit mehr oder weniger Details einblenden.
|
Falls Sie das Skript verändern möchten, können Sie es in einem Texteditor bearbeiten:
-
Öffnen Sie das Projekt im opsi PackageBuilder und rufen den Editor auf.
-
Verwenden Sie einen Texteditor wie beispielsweise jEdit mit
opsi-script-Syntax-Highlighting, wie Sie ihn in der Grundausstattung der opsi-Produkte finden.
Sie können die Änderungen nun speichern (und den Editor geöffnet lassen). Wechseln Sie zum opsi-script-Fenster zurück und drücken Sie erneut den Start_Button; Sie müssen das Skript nicht erneut auswählen. Schauen Sie sich die Änderungen im opsi-logviewer an; dazu wählen Sie _Neu laden aus dem Kontextmenü der rechten Maustaste oder über den Button in der Symbolleiste.
Um Ihre Skripte weiter anzupassen, können Sie die Punkte wiederholen:
-
Skript im Editor bearbeiten und Änderungen speichern
-
Skript (erneut) in
opsi-scriptausführen -
Logdatei kontrollieren
Integrierte Tests
Bei den integrierten Tests rollen Sie das Produkt auf einem Testclient aus:
-
Öffnen Sie das Skript
setup.opsiscriptin einem Editor und nehmen Sie ggf. Änderungen vor; speichern Sie die Änderungen:-
Öffnen Sie das Projekt im opsi PackageBuilder und rufen den Editor auf.
-
Verwenden Sie einen Texteditor wie beispielsweise jEdit mit
opsi-script-Syntax-Highlighting, wie Sie ihn in der Grundausstattung der opsi-Produkte finden.
-
-
Packen Sie das Produkt:
-
Variante 1: Öffnen Sie das Projekt im opsi PackageBuilder und klicken auf den Button Packen.
-
Variante 2: Öffnen Sie ein Terminal auf dem opsi-Server oder melden sich per SSH an, z. B. mit PuTTY. Wechseln Sie zur Workbench (
/var/lib/opsi/workbench) und dann ins Verzeichnis des Projektes. Rufen Sie den folgenden Befehl zum Packen auf:
opsi-makepackage
-
-
Installieren Sie das Produkt auf dem opsi-Server:
-
Variante 1: Klicken Sie auf den Button Installieren im opsi PackageBuilder.
-
Variante 2: Rufen Sie im Projektverzeichnis im Terminal den folgenden Befehl auf:
opsi-package-manager -i <myproctid_version.opsi>
Ersetzen Sie<myproctid_version.opsi>durch den Namen des opsi-Paketes (wie er beim Packen ausgegeben wurde).
-
-
Rollen Sie das Produkt über die Management-Oberfläche
opsi-configedaus:-
Wählen Sie auf dem Reiter Clients den Testclient aus.
-
Wählen Sie auf dem Reiter Localboot-Produkte das Produkt aus. Sollte Ihr opsi-Paket dort nicht auftauchen (was nach dem ersten Installieren normal ist), drücken Sie den Button ganz links in der Symbolleiste oder wählen Sie aus dem Menü Datei / Alle Daten neu laden.
-
Setzen Sie das Produkt auf setup und speichern Sie die Änderungen.
-
Starten Sie den Client oder rufen Sie für laufende Clients aus dem Kontextmenü on_demand auf.
-
Warten Sie, bis die Installation des Produktes auf dem Client durchgelaufen ist.
-
Wechseln Sie zum Reiter Logfiles und dort zu instlog und betrachten Sie die Logdatei.
-
| Über den Schieberegler rechts unten können Sie den Loglevel verändern und damit mehr oder weniger Details einblenden. |
Um Ihre Skripte weiter anzupassen, können Sie die Punkte wiederholen:
-
Skript im Editor bearbeiten und Änderungen speichern
-
Produkt packen
-
Produkt auf dem Server installieren
-
Produkt auf dem Client ausrollen
-
Logdatei kontrollieren
opsi PackageBuilder: Skript modifizieren
Starten Sie den opsi PackageBuilder (oPB) aus dem Startmenü. Sollte das nicht funktionieren (beobachtet unter Linux mit KDE-Desktopumgebung), starten Sie das Programm aus einem Terminal heraus. Geben Sie einen beliebigen Pfad an und bestätigen die Fehlermeldung, dass der Pfad nicht gefunden wurde:
opsipackagebuilder --path /homeBeim ersten Start befindet sich der opsi PackageBuilder im Offlinemodus, da die Verbindung zum opsi-Server noch fehlt:
Initiale Konfiguration
Klicken Sie auf die Schaltfläche Einstellungen, um das Programm opsi PackageBuilder zu konfigurieren.
Auf dem Reiter Allgemein nehmen Sie die folgenden Einstellungen vor:
-
Konfigserver: Tragen Sie den vollständigen Namen (FQDN) Ihres opsi-Configservers ein (z. B.
opsi.mycompany.org). -
opsiadmin Benutzer: Hier steht der Name eines Benutzers, der administrativ auf den opsi-Service zugreifen darf; der Account muss Mitglied der Gruppe
opsiadminsein (siehe Abschnitt Benutzer und Gruppen). -
opsiadmin Passwort: Tragen Sie hier das dazugehörige Passwort ein. Dieses wird nicht angezeigt und verschlüsselt gespeichert. Das Kennwort ist zwingend erforderlich, damit der opsi PackageBuilder mit dem opsi-Server kommunizieren kann.
-
4.0.4 oder neuer: Aktivieren Sie diese Checkbox.
-
SUDO ohne Passwort: Das ist die Voreinstellung; übernehmen Sie diese.
-
Betreuer: Tragen Sie hier Ihren vollständigen Namen ein; er wird in den Changelogs verwendet.
-
EMail: Hier gehört Ihre Mailadresse hin, sie wird in den Changelogs verwendet.
Auf dem Reiter Programm nehmen Sie die folgenden Einstellungen vor:
-
Aktivieren Sie die Checkbox Erweiterten Changelog Editor verwenden.
-
Wählen Sie einen Entwicklungsordner aus; tragen Sie den vollständigen Pfad zum Verzeichnis ein, in dem die opsi-Pakete erstellt werden sollen. Idealerweise ist das der Pfad zur gemounteten Freigabe mit der opsi-Workbench. Optional können Sie dazu ein Bestehendes Netzlaufwerk verwenden.
-
Skripteditor: Wählen Sie den Texteditor zur Bearbeitung der Skripte aus:
-
Windows: übernehmen Sie die Voreinstellung (Pfad zum oPB-ScriptEditor)
-
Linux: Pfad zum Editor, z. B.
/usr/bin/jedit; Feld Kommandozeilenoption bleibt leer -
macOS: Pfad zum Editor, z. B.
/Application/jedit; Feld Kommandozeilenoption bleibt leer
-
Auf dem Reiter opsi Verwaltungsbefehle nehmen Sie die folgende Einstellungenq (abweichend von den Voreinstellungen) vor:
-
Paketieren: Tragen Sie in dieses Feld den Befehl zum Bauen des Paketes ein:
opsi-makepackage -v -
Aktivieren Sie die Checkbox Depotfunktionen aktivieren.
Speichern Sie die Einstellungen und starten Sie den opsi PackageBuilder neu. Das Programm sollte sich nun im Onlinemodus befinden.
Pakete modifizieren, packen und Installieren
Zum Modifizieren eines Paketes klicken Sie auf den Button Paket öffnen (F2) und navigieren zum Verzeichnis, das der opsi-setup-detector erstellt hat (z. B. w:\develop\newprod2). Es öffnet sich der folgende Dialog:
Auf dem Reiter Paket sehen Sie die Metadaten des opsi-Produktes in der linken Spalte (siehe Abschnitt Produkt-Konfiguration 1). Auf der rechten Seite stehen die Skriptdateien. Daneben befindet sich jeweils dieser Button:
Wenn Sie diesen Button anklicken, öffnet sich der in der Konfiguration definierte Editor zum Modifizieren des Skriptes. Unter Windows ist das der oPB-ScriptEditor, der unter anderem farbige Syntax-Hervorhebung, Falten des Quellcodes (optional: kompakt, mit Kommentaren), anpassbare Lexerdefinition (dazu muss der Editor über das Startmenü aufgerufen werden), automatische Vervollständigung für Syntax-Elemente und Variablen und frei definierbare und wiederverwendbare Codeblöcke (Snippets) unterstützt.
Die Kernkomponente des Editors ist das Modul Scintilla, das auch andere bekannte Texteditoren (Notepad\++, CodeLite usw.) verwenden. Die lexikalischen Elemente (Syntax-Hervorhebung und Faltung) für opsi-Skripte sind allerdings in AutoIt geschrieben, da Scintilla für diese kein eigenes Highlighting mitbringt. Da AutoIt eine Interpreter-Sprache ist, ist der ScriptEditor langsamer als andere Editoren und eignet sich daher nur bedingt zur Bearbeitung sehr großer Skripte (vor allem bei aktivierter Faltung des Codes).
In den Einstellungen können Sie vorgeben, ob der Editor mit diesen Funktionen aufgerufen wird oder nicht (sofern er aus dem oPB heraus gestartet wird). Bei einem Aufruf über das Startmenü sind Syntax-Hervorhebung und Faltung deaktiviert. Sie können diese bei Bedarf über das Menü Ansicht einschalten.
Den Editor können Sie über die Kommandozeile aufrufen und dabei bestimmte Optionen direkt vorgeben. Weitere Informationen zu den möglichen Parametern blenden Sie über die Option --help ein.
|
Auf dem Reiter Abhängigkeiten sehen Sie die definierten Abhängigkeiten zu anderen opsi-Produkten (siehe Abschnitt Priorität und Abhängigkeiten):
Auf dem Reiter Produktvariablen stehen links jeweils die Produkt-Propertys, inklusive Typ, Wert usw:
Am unteren Fensterrand sehen Sie die folgenden Schaltflächen:
| Button | Bedeutung |
|---|---|
|
Startet eine eine SSH-Verbindung zum opsi-Server und ruft dort das Kommando zum Paketieren auf (siehe Abschnitt opsi-makepackage: Produkt packen). |
|
Startet eine eine SSH-Verbindung zum opsi-Server und ruft dort das Kommando zum Installieren auf (siehe Abschnitt opsi-package-manager: Produkt installieren). |
|
Ähnlich wie Installieren, allerdings wird das Paket zusätzlich auf allen Clients, auf denen es als installed gekennzeichnet ist, auf setup gesetzt. |
| Verwenden Sie die Schaltfläche Inst.+Setup ist nur mit äußerster Vorsicht und wenn Sie genau wissen, was Sie tun! |
opsi-makepackage: Produkt packen
Um das Produkt zu packen, wechseln Sie ins Hauptverzeichnis des Produktes und rufen das Kommando opsi-makepackage.
Es ist empfehlenswert, gleichzeitig eine dazugehörige MD5-Prüfsummendatei zu erzeugen. Diese Datei nutzen unter anderem Tools wie opsi-package-updater, um die Integrität des Paketes nach einer Übertragung sicherzustellen.
|
In der Voreinstellung erzeugt opsi-makepackage eine solche MD5-Prüfsummendatei. Falls Sie die Funktion deaktivieren möchten, verwenden Sie diesen Parameter beim Aufruf:
opsi-makepackage --no-md5Beim Übertragen von Paketen auf opsi-Depotserver nutzt opsi-makepackage das Tool zsync. Es überträgt lediglich die Unterschiede der Pakete und spart damit Bandbreite. Dazu ist eine .zsync-Datei erforderlich, die opsi-makepackage automatisch erstellt. Falls das nicht gewünscht ist, deaktivieren sie das Feature so:
opsi-makepackage --no-zsyncWenn es beim Erstellen großer Pakete zu Platzproblemen im temporären Verzeichnis /tmp kommt, können Sie hinter --temp-directory ein abweichendes temporäres Verzeichnis angeben.
opsi-makepackage schaut außerdem vor dem Bauen nach, ob es im Verzeichnis schon ein Paket mit gleichem Namen bzw. mit derselben Versionsnummer gibt. Das Tool fragt in dem Fall nach, wie Sie weiter vorgehen möchten:
Package file '/var/lib/opsi/workbench/mytest/mytest_3.14-1.opsi' already exists.
Press <O> to overwrite, <C> to abort or <N> to specify a new version:Drücken Sie [O], um das Paket zu überschreiben; mit [C] brechen Sie den Vorgang ab, und wenn Sie [N] drücken, können Sie anschließend eine neue Versionsnummer angeben.
Weitere Informationen zum Tool opsi-makepackage und seinen Parametern finden Sie in Abschnitt opsi-makepackage.
|
opsi-package-manager: Produkt installieren
Mit dem Befehl opsi-package-manager installieren Sie opsi-Produkte. Wechseln Sie dazu ins Hauptverzeichnis des Produktes und rufen Sie dieses Kommando auf:
opsi-package-manager -i <myproductid_version.opsi>
Weitere Informationen zum Tool opsi-package-manager und seinen Parametern finden Sie in Abschnitt opsi-package-manager.
|
Beispiel: control-Datei
Seit opsi 4.3 ist es möglich, eine control-Datei im TOML-Format zu erzeugen. Gibt es eine solche Datei control.toml, dann ist diese maßgeblich und muss gepflegt werden.
[Package]
version: 1
depends:
[Product]
type: localboot
id: mytest
name: My Test
description: A test product
advice:
version: 3.14
priority: 10
licenseRequired: False
productClasses:
setupScript: setup.ins
uninstallScript:
updateScript:
alwaysScript:
onceScript:
customScript:
userLoginScript:
[ProductDependency]
action: setup
requiredProduct: javavm
requiredStatus: installed
[ProductProperty]
type: unicode
name: mytextprop
multivalue: False
editable: True
description: hint
values: ["off", "on"]
default: ["off"]
[ProductProperty]
type: bool
name: myboolprop
description: yes or no
default: False
[Changelog]
mytest (3.14-1) testing; urgency=low
* Initial package
-- jane doe <j.doe@opsi.org> Mi, 14 Jul 2010 12:47:53 +0000[Package]
version = "1"
depends = []
[Product]
type = "localboot"
id = "mytest"
name = "My Test"
description = """A test product"""
advice = """"""
version = "3.14"
priority = 0
licenseRequired = false
productClasses = []
setupScript = "setup.opsiscript"
uninstallScript = "uninstall.opsiscript"
updateScript = ""
alwaysScript = ""
onceScript = ""
customScript = ""
userLoginScript = ""
windowsSoftwareIds = []
[[ProductDependency]]
action = "setup"
requiredProduct = "javavm"
requiredStatus = "installed"
requirementType = ""
[[ProductProperty]]
type = "bool"
name = "myboolprop"
description = "hint"
default = [false]mytest (3.14-1)
* Initial package
-- jane doe <j.doe@opsi.org> Di, 29 Aug 2023 10:36:09opsi-newprod: Produkt erstellen
Außer den in diesem Kapitel vorgestellten grafischen Programmen zum Erstellen von opsi-Produkten gibt es das Kommandozeilentool opsi-newprod, das ein Gerüst für opsi-Produkte erzeugt. Nach dem Start fragt es zuerst nach, ob Sie ein Localboot- oder Netboot-Produkt erstellen möchten.
Für Produkte, die Sie über den Client-Agent bzw. opsi-script installieren, ist localboot die richtige Wahl. Der Typ netboot eignet sich für Produkte, die Sie über das opsi-Linux-Bootimage ausführen, z. B. Betriebssystem-Installationen.
|
Navigieren Sie mit der Taste [Tab] zu OK oder bestätigen Sie Ihre Wahl über [F12]. Im nächsten Dialog geben Sie die Daten zum neuen opsi-Produkt ein:
In die Felder tragen Sie die folgenden Werte ein:
-
Produkt-ID: Das ist ein eindeutiger Bezeichner für das Produkt und in der Regel unabhängig von der Version. Verwenden Sie nur Kleinbuchstaben, keine Umlaute, keine Leer- und Sonderzeichen; der Bindestrich
-ist als Trennzeichen erlaubt. -
Produkt-Name: Hier steht der Name des Produktes; wir empfehlen die Vermeidung von Umlauten.
-
Beschreibung: Hier ist Platz für ergänzende Informationen zum Produkt, die dann beispielsweise der
opsi-configedunter Beschreibung anzeigt. -
Hinweis: Falls Sie weitere Hinweise, etwa zum Umgang mit dem Produkt, unterbringen möchten, ist hier der Ort. Der
opsi-configedzeigt diese unter Notiz an. -
Produkt-Version: Die Version der gepackten Software steht hier; es sind maximal 32 Zeichen erlaubt.
-
Paket-Version: Das ist die Version des Paketes für die Produktversion. Sie dient dazu, Pakete mit gleicher Produktversion, aber z. B. korrigiertem
opsi-script-Skript zu unterscheiden. -
Lizenz benötigt: Das hat bei Localboot-Produkten keinen Einfluss. Bei Netboot-Produkten entscheidet diese Option, ob ein Lizenzschlüssel aus dem Lizenzmanagement geholt wird.
-
Priorität: Der Wert beeinflusst die Installations-Reihenfolge; mögliche Werte liegen zwischen
100(ganz am Anfang) und-100(ganz am Ende). Wenn es zusätzlich Abhängigkeiten zu anderen Produkten gibt, beeinflussen diese ebenfalls die Reihenfolge.
Als Nächstes geben Sie die Skripte an, die Sie für die unterschiedlichen Aktionen bereitstellen:
In die Felder tragen Sie Folgendes ein:
-
Setup-Skript: Normalerweise ist das
setup.ins. -
Uninstall-Skript: Normalerweise ist das
uninstall.ins. -
Update-Skript: Das Skript dient zur geringfügigen Veränderung einer existierenden großen Installation. Wird das Produkt auf
setupgestellt, so wird nach dem Abarbeiten des Setup-Skriptes automatisch das Update-Skript ausgeführt. -
Always-Skript: Dieses Skript läuft bei jeder Aktivierung des Client-Agent, z. B. nach jedem Bootvorgang.
-
Once-Skript: Das Skript hat den Folgestatus
not_installed. Das ist ein sehr selten verwendeter Schalter, den Sie ignorieren sollten, wenn Sie nicht genau wissen, was Sie damit tun wollen. -
Custom-Skript: Ein solches Skript verändert weder die Folgeaktion noch den Folgestatus. Es handelt sich hierbei um einen sehr selten verwendeten Schalter, den Sie ignorieren sollten, wenn Sie nicht genau wissen, was Sie damit tun wollen.
-
Benutzer-Anmeldung-Skript: Es dient dazu, nach der Anmeldung des Benutzers Modifikationen am Profil des eingeloggten Accounts vorzunehmen. Das funktioniert nur, wenn Sie die Erweiterung User Profile Management verwenden.
| Typ | Folgestatus | Folgeaktion |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
unverändert |
unverändert |
|
unverändert |
unverändert |
Nachdem nun das Produkt beschrieben ist, können Sie eine oder mehrere Abhängigkeiten zu anderen Produkten definieren. Andernfalls springen Sie zu Nein.
Wenn Sie Ja gewählt haben, dann erscheint dieser Dialog:
In die Felder tragen Sie Folgendes ein:
-
Abhängigkeit für die Aktion: Hier steht die Aktion des Produktes (das Sie gerade erstellen), für die die Abhängigkeit gilt (Seit opsi 4.3: nicht nur
setup). -
Benötigte Produkt-ID: Tragen Sie die ID (Bezeichner) des Produktes ein, zu dem eine Abhängigkeit besteht.
-
Benötigte Aktion: Sie können entweder die Aktion
setupoder (siehe unten) den Statusinstalledanfordern. -
Benötigter Installations-Zustand: Hier steht der Status, den das Produkt, zu dem eine Abhängigkeit besteht, haben soll (
installed). Liegt ein anderer Status vor, so wird das Produkt aufsetupgesetzt. -
Typ der Abhängigkeit: Hier geht es um die Installations-Reihenfolge: Wenn das Produkt, zu dem eine Abhängigkeit besteht, installiert sein muss, bevor mit der Installation des aktuellen Produktes begonnen werden kann, dann steht hier
before. Muss es nach dem aktuellen Produkt installiert werden, steht hierafter. Lassen Sie das Feld leer, wenn die Reihenfolge egal ist.
| Die tatsächliche Installations-Reihenfolge ergibt sich aus einer Kombination von Produktabhängigkeiten und den Prioritäten (siehe Abschnitt opsi-setup-detector: Priorität und Abhängigkeiten). |
Als Nächstes geht es um die Propertys. opsi-newprod fragt nach:
Die Produkteigenschaft wird clientspezifisch gespeichert und besteht aus einem Namen (Key), der verschiedene Werte (Values) haben kann. Das opsi-script-Skript fragt diese dann ab. Als Erstes entscheiden Sie, ob es sich um einen Textwert (unicode) oder um einen logischen Wert (boolean) handelt:
Wenn Sie unicode gewählt haben, füllen Sie danach die folgenden Felder aus:
-
Eigenschafts-Name (identifier): Tragen Sie den Property-Namen ein.
-
Eigenschafts-Beschreibung: Diesen Text zeigt unter anderem der
opsi-configedals Hilfe an. -
Mögliche Werte: Geben Sie eine durch Kommata getrennte Liste alle Werte an, die der Key annehmen darf. Wenn Sie das Feld leer lassen, dann können Sie später im
opsi-configedeinen beliebigen Wert eingeben. -
Editierbar: Entscheiden Sie, ob neben der von Ihnen vorgegebenen Liste auch andere Werte eingegeben werden dürfen; hier steht True oder False.
Enthält ein Wert einen Backslash \, so muss dieser doppelt angegeben werden. Eine Pfadangabe sieht dann beispielsweise so aus: C:\\temp
|
Im nächsten Fenster legen Sie den Standardwert des Propertys fest.
Wenn Sie anstelle von unicode den Typ boolean ausgewählt haben, sieht der Dialog anders aus. Sie können jetzt lediglich einen Namen und eine Beschreibung eingeben:
Produkt-Propertys können Sie beliebig oft definieren. Erst wenn Sie die Frage Wollen Sie eine Produkt-Eigenschaft definieren? verneinen, dann erscheint der nächste und letzte Dialog. Geben Sie hier Ihren Namen und die Mailadresse ein; diese werden im Changelog verwendet und sind obligatorisch.
Danach ist das Grundgerüst des Produktes fertig. Im neuen Verzeichnis finden Sie im Kapitel bereits beschriebenen Dateien und Verzeichnisse. Wechseln Sie in den Ordner OPSI und listen Sie den Inhalt auf (ls). Die Datei control enthält nun die Daten, die Sie gerade definiert haben, und Sie können die Datei in einem Editor öffnen, um die Einträge anzusehen oder zu ändern.
Bei opsi >= 4.3 erzeugt opsi-newprod eine Kontrolldatei im TOML-Format (.toml) und eine eigenständige Datei changelog.txt.
|
Erweiterte Konfiguration mit opsi-setup-detector
Die folgenden Abschnitte zeigen weitere Konfigurationsmöglichkeiten des opsi-setup-detector. Sie behandeln die Verwendung eines benutzerdefinierten Verzeichnisses, die Installation aus einem lokalen temporären Verzeichnis, die Verwaltung von Lizenzschlüsseln und die Anpassung von Benutzerprofilen und Desktopsymbolen.
Custom-Verzeichnis
Auf dem Reiter Produkt Konfiguration 1 sehen Sie im unteren Bereich die Checkbox Unterstütze custom directory. Aktivieren Sie diese, und das Produkt erhält ein zusätzliches Verzeichnis namens custom. Hier können kundenspezifische Anpassungen landen — bei einem Upgrade auf eine neue Paketversion bleibt das vorhandene Verzeichnis custom unverändert. Der Code enthält Vorlagen, um Dateien aus diesem Verzeichnis in die Installation einzufügen.
In die Datei setup.opsiscript wird Folgendes eingefügt:
; copy custom files to install dir
Files_copy_from_custom_dirDas ruft eine Files-Sektion auf, um Dateien aus einem custom-Verzeichnis auf den Client zu kopieren. Die dazugehörige Sektion sieht so aus:
[Files_copy_from_custom_dir]
copy -s "%scriptPath%\custom\*" "$installdir$"In diesem Beispiel wird der Inhalt das custom-Verzeichnisses in das Installations-Verzeichnis kopiert. Außerdem wird das custom-Verzeichnis selbst erzeugt. Es erhält die beiden Dateien OPSI\preinst und OPSI\postinst. Sie sorgen dafür, dass der Inhalt des Verzeichnisses auf dem Depot auch bei Aktualisierungen erhalten bleibt.
Lokales, temporäres Verzeichnis
Der opsi-setup-detector hat auf dem Reiter Produkt Konfiguration 1 die Checkbox Installiere von lokalem, temporären Verzeichnis. Aktivieren Sie diese, und die Installations-Dateien werden zunächst in ein lokales, temporäres Verzeichnis kopiert und dann aus diesem heraus installiert. Das Feature bietet sich beispielsweise an, wenn eine Installation die Netzwerkverbindung beeinträchtigen könnte, z. B. bei Treibern.
Der opsi-setup-detector erzeugt dann ein zusätzliches boolesches Property install_from_local_tmpdir, das in der Voreinstellung auf false steht und diese Beschreibung erhält: Bestimmt, ob die Installationsdateien nach lokal kopiert werden.
In die Datei setup.opsiscript wird Folgendes eingefügt:
set $Install_from_local_tmpdir$ = GetProductProperty("Install_from_local_tmpdir","False")
; before the installation:
if $Install_from_local_tmpdir$ = "true"
; copy installer files to tempdirectory
Files_copy_installer_to_temp
; set $installerSourceDir$ to tmpdir
set $installerSourceDir$ = forcePathDelims("%opsiTmpDir%\"+$ProductId$)
endif
; do the installation
; after the installation
if $Install_from_local_tmpdir$ = "true"
; cleanup installer tempdirectory
Files_del_installer_from_temp
endifJetzt werden die Installations-Dateien vorübergehend in ein temporäres Verzeichnis verschoben und nach der Installation gelöscht, wenn die Bedingung Install_from_local_tmpdir auf true gesetzt ist.
Die dazugehörigen Sektionen sehen so aus:
; copy installer files to tempdirectory
[Files_copy_installer_to_temp]
copy -s "$installerSourceDir$\*.*" "%opsiTmpDir%\$ProductId$"
; cleanup installer tempdirectory
[Files_del_installer_from_temp]
del -sf "%opsiTmpDir%\$ProductId$\"Lizenzschlüssel
Der opsi-setup-detector enthält auf dem Reiter Produkt Konfiguration 1 die Checkbox Behandle Lizenzkeys. Wenn Sie diese aktivieren, werden Property und Code zur Behandlung von Lizenzschlüsseln hinzugefügt.
Es wird ein zusätzliches Property namens secretlicense_or_pool erzeugt; es ist in der Voreinstellung leer und trägt diese Beschreibung: Lizenzkey oder opsi Lizenzpool. Das Schlüsselwort secret im Property-Namen führt dazu, dass im opsi-configed der Wert des Propertys nur maskiert angezeigt wird.
In die Datei setup.opsiscript wird Folgendes eingefügt:
DefVar $LicenseHandledByScript$ = "true"
set $LicenseOrPool$ = GetConfidentialProductProperty("SecretLicense_or_Pool","")
; before the installation:
; ---------------------------------------------------------------
comment "handle license "
; ----------------------------------------------------------------
if $LicenseHandledByScript$ = "true"
comment "we should handle license"
;reserve license and get license key
set $LicenseKey$ = get_licensekey_byPoolOrKey($LicenseOrPool$)
; here the section or function calls should follow which
; make use of the license key resp the license reservation
endifDer Aufruf von get_licensekey_byPoolOrKey prüft, ob der Wert des Propertys der Name eines Lizenzpools aus der opsi-Erweiterung Lizenzmanagement ist. Falls ja, so wird ein Lizenzschlüssel aus diesem Pool bezogen. Falls nein, so wird der Property-Inhalt als Lizenzschlüssel geliefert.
In die Datei uninstall.opsiscript wird Folgendes eingefügt:
DefVar $LicenseHandledByScript$ = "true"
set $LicenseOrPool$ = GetConfidentialProductProperty("SecretLicense_or_Pool","")
; after the uninstallation
; ---------------------------------------------------------------
comment "handle license "
; ----------------------------------------------------------------
if $LicenseHandledByScript$ = "true"
comment "we should free license used"
Set $tmpstr$ = FreeLicense($LicenseOrPool$)
endifDesktop-Icon
Der opsi-setup-detector enthält auf dem Reiter Produkt Konfiguration 1 die Checkbox DesktopIcon. Aktivieren Sie diese, um Property und Code zur Behandlung von Desktopsymbolen hinzuzufügen.
Es wird dann ein zusätzliches boolesches Property namens desktopicon erzeugt, in der Voreinstellung steht es auf false und hat diese Beschreibung: Soll es ein Desktopicon geben?.
In die Datei setup.opsiscript wird folgender Code eingefügt:
set $desktopicon$ = GetProductProperty("desktopicon", "False")
; after the installation
; handle desktop icon
if $DesktopIcon$ = "true"
comment "Create Desktop Icon"
Linkfolder_create_desktop_icon
else
comment "Remove Desktop Icon"
Linkfolder_remove_desktop_icon
endifFalls desktopicon auf true steht, wird eine Sektion Linkfolder aufgerufen. Der dazugehörige Code (der auch in die Datei uninstall.opsiscript eingefügt wird) sieht so aus:
[Linkfolder_remove_desktop_icon]
; check delete_element
set_basefolder common_desktopdirectory
set_subfolder ""
delete_element $productId$
[Linkfolder_create_desktop_icon]
; check name, target and working_dir
set_basefolder common_desktopdirectory
set_subfolder ""
set_link
name: $productId$
target: $Installdir$\$targetprogram$
parameters:
working_dir: $Installdir$
icon_file:
icon_index:
end_linkIn die Datei delinc.opsiinc werden außerdem diese beiden Zeilen eingefügt:
comment "Start Remove Desktop Icon Handling :"
Linkfolder_remove_desktop_iconLokale Benutzerprofile anpassen
Der opsi-setup-detector enthält auf dem Reiter Produkt Konfiguration 1 die Checkbox Customize Profile. Aktivieren Sie diese, und der Code wird ergänzt um eine Sektion Profileactions. Sie nimmt Anpassungen an den lokalen Benutzerprofilen vor. Diese Funktionalität wird auch über ein Loginskript für Roaming Profiles bereitgestellt.
Über die Datei OPSI/control wird das setup.opsiscript nicht nur als setupScript, sondern auch als userLoginScript bereitgestellt.
In die Datei setup.opsiscript wird Folgendes eingefügt:
; Run the customization for user profiles
ProfileActionsDer Code ruft eine ProfileActions-Sektion auf. Diese wird je nach Aufruftyp für alle lokalen Profile oder für den gerade eingeloggten Benutzer ausgeführt (siehe auch Kapitel User Profile Management).
Die dazugehörigen Sektionen, die als Templates für Aufrufe zur Manipulation der User Profiles dienen, sehen so aus:
[ProfileActions]
; all section that called from [ProfileActions]
; will be executed for all user profiles
;
; if this script runs as loginscript
; only the [ProfileActions] will be executed
; copy some files to every user profile
Files_copy_to_user_profiles
; make entries in every currentuser hive
Registry_current_user
; modify or create ini files in all user profiles
;Patches_in_user_profiles "%UserProfileDir%\Appdata\Roaming\<path_to_ini_file>"
Patches_in_user_profiles "%UserProfileDir%\Appdata\Roaming\osd_profile_example\osd_profile_example.ini"
[Files_copy_to_user_profiles]
; example structure:
;copy "%Scriptpath%\profile_files\*.*" "%UserProfileDir%\Appdata\Roaming\<path_to_application_dir>"
; example:
;copy "%Scriptpath%\profile_files\*.*" "%UserProfileDir%\Appdata\Roaming\osd_profile_example"
[Registry_current_user]
; example structure:
;openkey [HKCU\Software\<application key>]
;set "<var name>" = "<var value>"
; example:
;openkey [HKCU\Software\osd_profile_example]
;set "osd_profile_example_entry" = "example_value"
[Patches_in_user_profiles]
; example structure:
; set [<section name>] <key name>=<value>
; example:
;set [example_section] example_key=example_value