Das Copyright an diesem Handbuch liegt bei der uib gmbh in Mainz.

Dieses Handbuch ist veröffentlicht unter der creative commons Lizenz
'Namensnennung - Weitergabe unter gleichen Bedingungen' (by-sa).

CC by sa

Eine Beschreibung der Lizenz finden Sie hier:
https://creativecommons.org/licenses/by-sa/3.0/de/

Der rechtsverbindliche Text der Lizenz ist hier:
https://creativecommons.org/licenses/by-sa/3.0/de/legalcode

Die Software von opsi ist in weiten Teilen Open Source.
Nicht Open Source sind die Teile des Quellcodes, welche neue Erweiterungen enthalten die noch unter Kofinanzierung stehen, also noch nicht bezahlt sind.
siehe auch: opsi-Erweiterungen als Kofinanzierungsprojekte

Der restliche Quellcode ist veröffentlicht unter der AGPLv3:

agplv3

Der rechtsverbindliche Text der AGPLv3 Lizenz ist hier:
http://www.gnu.org/licenses/agpl-3.0-standalone.html

Für Lizenzen zur Nutzung von opsi im Zusammenhang mit Closed Source Software kontaktieren Sie bitte die uib gmbh.

Die Namen 'opsi', 'opsi.org', 'open pc server integration' und das opsi-logo sind eingetragene Marken der uib gmbh.

2. Einführung MacOS Clients in opsi

Diese Anleitung beschreibt den Betrieb von MacOS Clients in opsi.

Es wird voraus gesetzt, das die Installation und Inbetriebnahme eines opsi-servers bereits erfolgt ist.

Wesentliche Themen dieser Anleitung:

  1. Aufnahme und Einbindung von Mac-Rechnern in opsi (Installation des opsi-mac-client-agent)

  2. Bereitstellung von opsi Standardsoftware für Mac auf dem opsi-server

  3. Installation von Standard Software auf den Mac-Clients

  4. opsi-Standardsoftware für Mac unter opsi

  5. Paketierung eigener Software

  6. Erstellung von opsi-Paketen

  7. Hinweise zu Mac Clients

    1. Spezielle Befehle für MacOS

    2. Directories die Sie verwenden dürfen

    3. Der pseudo user opsisetupadmin

3. Konventionen dieses Dokuments

Befehle werden gesondert hervorgehoben:

dies ist ein Befehl

Im Rahmen der Installation und Konfiguration können Sie die Befehle aus diesen Feldern in der Regel der Reihe nach per copy & paste aus diesem Dokument kopieren und ausführen.

Das ist ein opsi-script Code:

Message "Installing "+ $ProductId$ +" ..."

Kapitel welche den Namen einer bestimmten Plattform enthalten sind spezifisch für diese Plattform. Die unterstützen Plattformen sind:

  • Windows

  • Linux

  • MacOS

4. Voraussetzungen für MacOS Clients

Nachfolgend werden die Voraussetzungen für das Management von MacOS Clients unter opsi beschrieben.

Der opsi-mac-client-agent ist eine kofinanzierte opsi Erweiterung.
Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in
https://download.uib.de/opsi_stable/doc/html/opsi-manual/opsi-manual.html#opsi-manual-modules

Technische Voraussetzungen ist ein opsi-server mit opsi 4.1.

Als Mac-Clients werden unterstützt:

  • MacOS Versionen von 10.13 bis 11.0
    (High Sierra bis Big Sur) in der intel x64 Architektur

  • Bei Verwendung der arm64 Architektur (Apple Silicium, M1) ist derzeit die Installation des opsi-client-agent der 'Dynamic Binary Translators' namens rosetta2 notwendig. Diesen können Sie Installieren mit:
    softwareupdate --install-rosetta --agree-to-license Die erfolgreiche Installation können Sie Überprüfen mit:
    pkgutil --pkgs | grep Rosetta
    com.apple.pkg.RosettaUpdateAuto.

Die native Unterstützung der arm64 Architektur (Apple Silicium) ist in Planung. Hierzu sind die notwendigen Referenz Geräte bestellt. Aussagen wann die Bereitstellung für diese Plattform erfolgt können im Moment (Januar 2021) noch nicht getroffen werden.

5. Einspielen der minimalen MacOS opsi-Produkte

Zur Verteilung von Software mit opsi stehen fertige Produkte zur Installation bereit. Diese beinhalten unter anderem den Agent ('opsi-client-agent'), welcher für das Management auf Clients installiert werden muss.

Es gibt eine automatische und manuelle Möglichkeit dies zu tun. Der automatisierte Weg wird empfohlen.

5.1. opsi-Standardsoftware für MacOS unter opsi

Folgende Produkte werden von opsi für macos als Standard zur Verfügung gestellt:

  • opsi-mac-client-agent

  • swaudit

  • hwaudit

  • m-homebrew (siehe auch: Das opsi Produkt m-homebrew

  • m-system-update

  • opsi-configed

  • opsi-logviewer

  • opsi-auto-update

  • m-javavm

  • opsi-setup-detector

  • windomain

5.2. Automatisches Einspielen der minimalen MacOS opsi-Produkte

Zur automatischen Installation der opsi-Produkte gibt es das Werkzeug opsi-package-updater, welches wie in '/etc/opsi/opsi-package-updater.conf' bzw. /etc/opsi/package-updater.repos.d/ konfiguriert, automatisch die aktuellen Pakete vom opsi Repository holt und auf dem Server installiert.

Die Konfiguration der opsi Repositories für Mac-Clients findet sich im Verzeichnis /etc/opsi/package-updater.repos.d/ in den Dateien uib-mac-testing.repo und uib-mac.repo.

Sollten diese Dateien bei Ihnen noch nicht installiert sein, so finden Sie diese unter:

Aktivieren Sie die gewünschten repos in dem Sie in der gewünschten *.repo Datei den Eintrag active = true setzen.

/etc/opsi/package-updater.repos.d/uib-mac-testing.repo
; This repository provides testing opsi products for managing MacOS
; clients with opsi.

[repository_uib_macos_testing]
description = opsi macos packages in testing
active = true
baseUrl = http://download.uib.de
dirs = opsi4.1/testing/packages/macos/localboot/
autoInstall = false
autoUpdate = true
autoSetup = false
; Set Proxy handler like: http://10.10.10.1:8080
proxy =
/etc/opsi/package-updater.repos.d/uib-mac.repo
; This repository provides table opsi roducts for managing MacOS
; clients with opsi.

[repository_uib_macos_stable]
description = opsi macos packages in stable
active = true
baseUrl = http://download.uib.de
dirs = opsi4.1/stable/packages/macos/localboot/
autoInstall = false
autoUpdate = true
autoSetup = false
; Set Proxy handler like: http://10.10.10.1:8080
proxy =

Installieren Sie die Pakete auf dem Server durch die Ausführung des Befehls als root:

opsi-package-updater -v --repo uib_macos_stable install

bzw.

opsi-package-updater -v --repo uib_macos_testing install

Nach erfolgreicher Installation müssen Sie beim opsi-configed ein erneutes laden aller Daten ausführen, damit die neuen Produkte dort sichtbar werden.

Muss für den Zugriff auf das Internet die Verbindung über einen Proxy geleitet werden, so muss dieser in den .repo-Konfigurationsdateien unter /etc/opsi/package-updater.repos.d/ als Wert für proxy eingetragen werden. Ab Version 4.1.1.33 von opsi-utils kann ein globaler Proxy in /etc/opsi/opsi-package-updater.conf konfiguriert werden.

[repository_uib_macos_stable]
…
proxy =

Sollen später installierte Pakete aktualisiert werden, so kann dies mit dem folgenden Befehl gemacht werden:

opsi-package-updater -v update

Weitere Informationen zum opsi-package-updater können im Handbuch gefunden werden.

5.3. Manuelles Einspielen der MacOS opsi-Produkte

Es gibt auch die Möglichkeit manuell die Pakete herunter zu laden und zu installieren.

Holen Sie sich die aktuellen opsi-Pakete im .opsi-Paketformat. Die Pakete finden Sie unter https://download.uib.de/opsi4.1/stable/packages/macos/localboot bzw. unter https://download.uib.de/opsi4.1/testing/packages/macos/localboot.

Wir empfehlen die .opsi-Dateien unter /var/lib/opsi/repository zu speichern. Zum Sicherstellen, dass opsiconfd auf die Dateien zugreifen kann, sollte opsi-set-rights /var/lib/opsi/repository ausgeführt werden.

Nach dem Download müssen Sie die Pakete auf dem Server mit dem Befehl opsi-package-manager -i <paketname>.opsi installieren.

6. Integration vorhandener MacOS-Clients in opsi

Um vorhandene MacOS-Clients in opsi aufzunehmen, muss auf diesen der opsi-client-agent installiert werden. Dies kann auf mehrere Arten durchgeführt werden. Nachdem Sie, wie im Folgenden beschrieben, den opsi-client-agent installiert haben, erscheint der Client auch in der Client-Liste des opsi-configed, sofern Sie ihn dort noch nicht hinzugefügt hatten.

Grundsätzlich gibt es die Möglichkeit die Installation des Agenten auf dem Client auszuführen oder vom Server aus die Installation anzustoßen.

Das Ausführen der Installation direkt auf dem Client eignet sich für einzelne Rechner. Für einen Massen-Rollout des Agenten eignet sich grundsätzlich der opsi-deploy-client-agent besser, wenn die dazu nötigen Freischaltungen auf den Mac-Clients vorhanden sind.

Falls bereits eine andere Möglichkeit existiert Software zu verteilen, so ist es ebenfalls möglich darüber den opsi-client-agent zu verteilen und das im Paket mitgelieferte Script silent_setup.sh auszuführen.

Sobald der Agent installiert ist, können vorhandene opsi-Produkte auf diesen Clients installiert werden.

6.1. Verwendung von service_setup.sh auf MacOS

6.1.1. Verwendung von service_setup.sh auf MacOS (Erstinstallation)

Aufgrund der Sicherheitsrestriktionen von MacOS ist die Möglichkeit Scripte von gemounteten shares auszuführen eingeschränkt. Der Versuch den im folgenden beschriebenen Vorgang mit über den Finder nach /Volumes (oder so) gemounteten share zu machen wird daher (je nach MacOS Version) scheitern.

  • Loggen Sie sich auf dem Client ein.

  • Starten Sie das Terminal-Programm

  • Für die folgenden Befehle müssen Sie die folgenden Platzhalter ersetzen:

    • <username> mit Ihrem login Namen

    • <mnt> durch ein Verzeichnisnamen der noch nicht existiert z.B. 'mnt'

    • <serviceuser> durch einen Usernamen der auf dem opsi-server bekannt ist.

    • <servicepass> durch das Passwort des <serviceuser>. Sie können :<servicepass> zusammen mit der mount-Option -N auch weglassen, dann werden Sie nach dem Passwort gefragt

    • <opsi-server> durch den Namen oder die IP-Nummer des opsi-servers

sudo su
cd /Users/<username>
mkdir <mnt>
mount_smbfs //<serviceuser>@<opsi-server>/opsi_depot /Users/<username>/<mnt>
cd /Users/<username>/<mnt>/opsi-mac-client-agent
./service_setup.sh
cd
umount /Users/<username>/<mnt>

bzw. ohne Passwortabfrage

sudo su
cd /Users/<username>
mkdir <mnt>
mount_smbfs -N //<serviceuser>:<servicepass>@<opsi-server>/opsi_depot /Users/<username>/<mnt>
cd /Users/<username>/<mnt>/opsi-mac-client-agent
./service_setup.sh
cd
umount /Users/<username>/<mnt>

Beispiel:

sudo su
cd /Users/uib
mkdir mnt
mount_smbfs  //adminuser@sepia/opsi_depot /Users/uib/mnt
cd /Users/uib/mnt/opsi-mac-client-agent
./service_setup.sh
cd
umount /Users/uib/mnt
  1. Starten Sie von dem gemounteten share das Script opsi-mac-client-agent\service_setup.sh
    Bestätigen Sie mit 2 x Enter

  2. Das Skript kopiert die notwendigen Dateien in ein temporäres lokales Verzeichnis und startet dann zur eigentlichen Installation opsi-script.

  3. Das Skript nimmt per opsi-Webservice Kontakt zum Server auf um serverseitig den Client zu erzeugen und den pckey zu erfahren. Dies erfolgt zunächst mit der in der config.ini eingetragenen user/password Kombination. Schlägt dies fehl, so erscheint ein Login-Fenster mit Service-URL (opsi-configserver), Benutzername und Passwort. Hier wird ein Benutzer benötigt, der Mitglied der Gruppe 'opsiadmin' ist. Möglich ist auch ein Benutzer, welcher nur die Methode host_createOpsiClient ausführen darf.

Der Client benötigt nach der Installation ein Reboot um aktiv zu werden.
Der Reboot wird nicht automatisch ausgelöst.

6.1.2. Verwendung von service_setup.sh auf MacOS (Reperaturinstallation)

  • Loggen Sie sich auf dem Client ein.

  • Starten Sie das Terminal-Programm

  • Für die folgenden Befehle müssen Sie die folgenden Platzhalter ersetzen:

    • <serviceuser> durch einen Usernamen der auf dem opsi-server bekannt ist.

    • <servicepass> durch das Passwort des <serviceuser>. Sie können :<servicepass> auch weglassen, dann werden Sie nach dem Passwort gefragt

    • <opsi-server> durch den Namen oder die IP-Nummer des opsi-servers

  • Bei der Erstinstallation hat opsi einen Versteckten Pseudo user Namens opsisetupadmin angelegt, in dessen 'Heimatverzeichnis' /var/opsisetupadmin sich auch das mount directory befindet.

sudo su
mount_smbfs -N //<serviceuser>:<servicepass>@<opsi-server>/opsi_depot /var/opsisetupadmin/opsi_depot
cd /var/opsisetupadmin/opsi_depot/opsi-mac-client-agent
./service_setup.sh
cd
umount /var/opsisetupadmin/opsi_depot

Beispiel:

sudo su
mount_smbfs -N //adminuser:linux123@sepia/opsi_depot /var/opsisetupadmin/opsi_depot
cd /var/opsisetupadmin/opsi_depot/opsi-mac-client-agent
./service_setup.sh
cd
umount /var/opsisetupadmin/opsi_depot
  1. Starten Sie das Script opsi-mac-client-agent\service_setup.sh
    Bestätigen Sie mit 2 x Enter

  2. Das Skript kopiert die notwendigen Dateien in ein temporäres lokales Verzeichnis und startet dann zur eigentlichen Installation opsi-script.

  3. Das Skript nimmt per opsi-Webservice Kontakt zum Server auf um serverseitig den Client zu erzeugen und den pckey zu erfahren. Dies erfolgt zunächst mit der in der config.ini eingetragenen user/password Kombination. Schlägt dies fehl, so erscheint ein Login-Fenster mit Service-URL (opsi-configserver), Benutzername und Passwort. Hier wird ein Benutzer benötigt, der Mitglied der Gruppe 'opsiadmin' ist. Möglich ist auch ein Benutzer, welcher nur die Methode host_createOpsiClient ausführen darf.

Der Client benötigt nach der Installation ein Reboot um aktiv zu werden.
Der Reboot wird nicht automatisch ausgelöst.

6.2. Verwendung von opsi-deploy-client-agent für MacOS

Das opsi-deploy-client-agent Skript verteilt den opsi-client-agent direkt vom opsi-server auf die Clients. Es ist hiermit einfach möglich eine große Menge an Clients vom Server aus in eine opsi-Umgebung zu integrieren. Voraussetzung hierfür sind bei den Clients:

  • Administrativer User mit Passwort

  • ein aktivierter ssh Zugang

Leider sind bei MacOS die ssh Zugänge per default deaktiviert. Zur Verwendung des opsi-deploy-client-agent Befehls müssen diese Zugange daher erst aktiviert werden.

Die kann interaktiv in den 'System preferences / sharing' gemacht werden:

Aktivierung des ssh Zugangs

Auf der Kommandozeile kann dies wie folgt gemacht werden:

sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

Eine Konrolle des aktuellen Status des ssh Zugangs ist möglich mit dem Befehl:

sudo systemsetup -getremotelogin

Die Deaktivierung des ssh Zugangs auf der Kommandozeile sieht wie folgt aus:

sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist

Das opsi-deploy-client-agent Skript findet sich unter /var/lib/opsi/depot/opsi-client-agent
Führen Sie das Script mit 'root' Rechten aus. Falls das Script nicht ausführbar ist, so können Sie dieses Problem mit dem folgenden Befehl beheben:
opsi-set-rights /var/lib/opsi/depot/opsi-client-agent/opsi-deploy-client-agent

Das Skript erzeugt serverseitig den Client, kopiert die Installations-Dateien und Konfigurationsinformationen, wie bspw. den pckey, auf den Client und startet dort die Installation.
Die Installation läuft im Hintergrund ohne das ein User davon etwas bemerken muß.

Der Befehl opsi-deploy-client-agent hat eine Fülle von Aufrufparametern.
Bei allen nachfolgenden Beispielen wird davon ausgegangen, das Sie in das Stammverzeichnis des opsi-client-agent Produktes gewechselt sind:

cd /var/lib/opsi/depot/opsi-mac-client-agent

Typische Aufrufe sind:

  • Für einen einzelnen Client:

./opsi-deploy-client-agent -v --user=uib uib-mmini1

Ergibt folgende Ausgabe:

Password is required for deployment.
Password:
[5] [2021-02-04 16:43:43.121] [               ] Starting deployment to host uib-mmini1.uib.local   (posix.py:84)
[5] [2021-02-04 16:43:43.121] [               ] Querying for ip address of host uib-mmini1.uib.local   (common.py:158)
[5] [2021-02-04 16:43:43.122] [               ] Got ip address 192.168.10.70 from syscall   (common.py:167)
[5] [2021-02-04 16:43:43.123] [               ] Pinging host 192.168.10.70 ...   (common.py:183)
[5] [2021-02-04 16:43:44.146] [               ] Host 192.168.10.70 is up   (common.py:194)
[5] [2021-02-04 16:43:44.153] [               ] Patching config.ini   (posix.py:91)
[5] [2021-02-04 16:43:44.157] [               ] Copying installation scripts...   (posix.py:107)
[5] [2021-02-04 16:43:48.316] [               ] Running installation script...   (posix.py:147)
[5] [2021-02-04 16:43:53.382] [               ] opsi-client-agent successfully installed on uib-mmini1.uib.local   (posix.py:176)
[5] [2021-02-04 16:43:53.395] [               ] Restarting opsiclientd service on computer: uib-mmini1   (posix.py:331)
[5] [2021-02-04 16:43:55.620] [               ] 1/1 deployments successfully   (__init__.py:210)
  • Für eine Liste von Clients:

./opsi-deploy-client-agent -v --user=uib --hosts-from-file HOSTFILE.TXT  --skip-existing-clients

Hier ist HOSTFILE.TXT eine Datei mit einem Clientnamen (FQDN) pro Zeile. Soweit die Clients dem opsi-server noch nicht bekannt sind, wird versucht den opsi-mac-client-agent auf dieser Maschine zu installieren

  • Anzeigen alle Kommandozeilen Parameter:

./opsi-deploy-client-agent --help

7. Rollout existierender Produkte auf MacOS

Für den Rollout von Software auf Clients muss auf diesen der 'opsi-client-agent' installiert sein. Dieser kann auf bestehende Rechner ausgerollt werden.

Nachfolgend wird die Management-Oberfläche opsi-configed verwendet, um Software auf Clients zu verteilen.

7.1. Inventarisierung mit dem localboot-Produkten hwaudit und swaudit

Wählen Sie im 'opsi-configed', Modus 'Client-Konfiguration', unter dem Reiter 'Clients' den betreffenden Client aus.

Wenn noch nicht geschehen, aktualisieren Sie den Datenbestand des opsi-configeds mittels 'Datei/Daten neu laden' bzw. Anklicken des entsprechenden Icons.

Wechseln Sie zum Reiter 'Produktkonfiguration', klicken Sie in die Spalte 'Angefordert' für das Produkt hwaudit, daraufhin öffnet sich eine Liste/Dropdown-Menü und dort wählen Sie die Aktion 'setup'. Wiederholen Sie das für das Produkt swaudit.

Der Haken in der Icon-Menüleiste sollte seine Farbe auf Rot wechseln. Wenn Sie ihn anklicken, werden die neuen Einstellungen zum opsi-server übermittelt, im Anschluss ist seine Farbe wieder grün.

Starten Sie dann den Client (neu). Er sollte jetzt den opsi-client-agent starten und die Produkte hwaudit und swaudit installieren. Bei hwaudit und swaudit werden Hard- bzw. Softwareinformationen erhoben und zum opsi-server übermittelt. Die gesammelten Informationen werden unter den Tabs 'Hardwareinformationen' bzw. 'Software-Inventur' angezeigt.

7.2. Verteilung von opsi Standard Produkten: m-homebrew

Dieses Produkt installiert das Paketverwaltungsprogramm homebrew welches von verschiedenen anderen opsi-Produkten für MacOS verwendet wird, z.B. zur Installation von Java.

Wählen Sie im 'opsi-configed', Modus 'Client-Konfiguration', unter dem Reiter 'Clients' den betreffenden Client aus.

Wechseln Sie zum Reiter 'Produktkonfiguration', klicken Sie in die Spalte 'Angefordert' für das Produkt m-homebrew, daraufhin öffnet sich eine Liste/Dropdown-Menü und dort wählen Sie die Aktion 'setup'.

Der Haken in der Icon-Menüleiste sollte seine Farbe auf Rot wechseln. Wenn Sie ihn anklicken, werden die neuen Einstellungen zum opsi-server übermittelt, im Anschluss ist seine Farbe wieder grün.

Starten Sie dann den Client (neu) oder pushen Sie die Installation per 'on_demand' Er sollte jetzt den opsi-client-agent starten und das Produkt m-homebrew installieren.

7.3. Verteilung von opsi Standard Produkten: m-javavm

Dieses Produkt installiert die Java Runtime Umgebung welche von verschiedenen anderen opsi-Produkten für MacOS verwendet wird, z.B. opsi-configed, opsi-logviewer

Wählen Sie im 'opsi-configed', Modus 'Client-Konfiguration', unter dem Reiter 'Clients' den betreffenden Client aus.

Wechseln Sie zum Reiter 'Produktkonfiguration', klicken Sie in die Spalte 'Angefordert' für das Produkt m-javavm, daraufhin öffnet sich eine Liste/Dropdown-Menü und dort wählen Sie die Aktion 'setup'.

Der Haken in der Icon-Menüleiste sollte seine Farbe auf Rot wechseln. Wenn Sie ihn anklicken, werden die neuen Einstellungen zum opsi-server übermittelt, im Anschluss ist seine Farbe wieder grün.

Starten Sie dann den Client (neu) oder pushen Sie die Installation per 'on_demand' Er sollte jetzt den opsi-client-agent starten und das Produkt m-javavm installieren.

7.4. Verteilung von opsi Standard Produkten: opsi-configed

Achtung: m-homebrew und m-javavm müssen bereits installiert sein!

Zu den Standard-Produkten gehört das Produkt opsi-configed welches das opsi Management Interface als Anwendung auf einem Rechner installiert. Da diese Anwendung eine Java-Anwendung ist, wird ein JavaRE mitgeliefert.

Wählen Sie im 'opsi-configed', Modus 'Client-Konfiguration', unter dem Reiter 'Clients' den betreffenden Client aus.

Wenn noch nicht geschehen, aktualisieren Sie den Datenbestand des opsi-configeds mittels 'Datei/Daten neu laden' bzw. Anklicken des entsprechenden Icons.

Wechseln Sie zum Reiter 'Produktkonfiguration', klicken Sie in die Spalte 'Angefordert' für das Produkt opsi-configed, daraufhin öffnet sich eine Liste/Dropdown-Menü und dort wählen Sie die Aktion 'setup'.

Der Haken in der Icon-Menüleiste sollte seine Farbe auf Rot wechseln. Wenn Sie ihn anklicken, werden die neuen Einstellungen zum opsi-server übermittelt, im Anschluss ist seine Farbe wieder grün.

Starten Sie dann den Client (neu). Er sollte jetzt den opsi-client-agent starten und das Produkt opsi-configed installieren. Nach Abschluß der Installation sollten Sie unter Applications den Punkt opsi-configed finden.

8. Einbindung eigener Software in die Softwareverteilung von opsi

Die Installation von Software erfolgt bei opsi durch den opsi-client-agent und insbesondere durch das Script gesteuerte Setup Programm opsi-script. Daher muss zu jedem opsi-Produkt ein opsi-script-Script erstellt werden. Danach werden dieses Script, die Installationsdateien und die Metadaten zu einem opsi-Produkt gepackt, welches sich schließlich auf dem opsi-server installieren lässt.

8.1. Ein kleines Tutorial zur Erstellung eines opsi-script Scriptes

8.1.1. Einführung

Dieses Tutorial kann keine Schulung oder das Studium der Handbücher ersetzen. Es dient nur dazu eine Einführung zu bekommen. Daher als erstes der Verweis auf weiterführende Quellen:

Schulungen:

Die uib GmbH bietet opsi-Schulungen in Mainz und Inhouse Schulungen an:
https://uib.de/de/support-schulung/schulung/

Handbücher:

https://uib.de/de/opsi-dokumentation/dokumentationen/
Besonders wichtig:
opsi-winst-Reference-Card und opsi-script-Handbuch

Wiki (Scripte, Tipps, Links):

https://forum.opsi.org/wiki

Support Forum:

siehe https://forum.opsi.org

8.1.2. Methoden der nicht interaktiven Softwareinstallation bei MacOS

Apple hat (im Gegensatz zu Microsoft) sehr früh die Methoden zur Software Installation standardisiert. Im Kern gibt es zwei Methoden:

  • application Directory:
    Es handelt sich um ein Verzeichnis nach dem Muster: <Application name>.app Ein solches Verzeichnis wird aber im Finder nicht als Verzeichnis angezeigt, sondern als 'Anwendung'. Innerhalb dieses Verzeichnisses müssen sich nach einem bestimmten Muster die Dateien der Anwendung befinden. Ein typischer Aufbau wäre:

opsi-script-gui.app
  |--Contents
       |-Info.plist
       |-PkgInfo
       |-MacOS
       |  |-opsi-script-gui
       |
       |-Resources
          |- (....)

Ein solches Verzeichnis muß zur Installation nur in das Verzeichnis /Applications kopiert werden. Evtl. müssen noch Dateien im Verzeichnis MacOS ausführbar gemacht werden.
Solche *.app Verzeichnisse werden zum Download zumeist gepackt angeboten.

  • PKG file:
    Diese Dateien enthalten Software die über einen speziellen Befehl installiert werden müssen.

In beiden Fällen ist eine unattended (also nicht interaktive) Installation kein Problem.

Häufig wird MacOS Software in gepackten Formaten angeboten wie *.zip, *.dmg oder auch *.tgz.

Alle bisher genannten Varianten können per opsi-script direkt installiert werden, außer *.tgz welches vorher ausgepackt werden muß.

8.1.3. Struktur eines opsi-script Skripts

Zunächst ein Beispiel für ein einfaches opsi-winst-Skript:

[Actions]
WinBatch_tightvnc_silent_install

[WinBatch_tightvnc_silent_install]
"%ScriptPath%\tightvnc-1.3.9-setup.exe" /silent

Ein opsi-winst-Skript besteht aus primären und sekundären Sektionen. Sektionen werden, wie von ini-Dateien bekannt, mit einem Sektions-Namen in eckigen Klammern eingeleitet.
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 „Themen-spezifisch“ und verfügen jeweils über eine spezielle Syntax.
Der Sektionsname einer sekundären Sektion beginnt mit deren Typ, gefolgt von einem frei definierbaren Namen.

Im Beispiel ruft die primären Sektion [Actions] eine sekundäre Sektion [WinBatch_7z_silent_install] auf.
Die sekundäre Sektion ist vom Typ WinBatch. Der Inhalt einer WinBatch-Sektion wird über die Windows-API ausgeführt.
In diesem Fall wird also das Setup-Programm 7z.exe mit dem Parameter /S gestartet.

8.1.4. 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. Es besteht die Möglichkeit Sub-Sektionen in externe Dateien auszulagern.

Die primären Sektionen sind das Hauptprogramm in dem der Ablauf des Skripts gesteuert wird. Hierzu gibt es:

  • Variablen: Strings und Stringlisten

  • if else endif Anweisungen

  • for Schleifen über Stringlisten

  • Funktionen

Abbildung: Vermeidung doppelten Codes über ausgegliederte Sub
Abbildung 1. Vermeidung doppelten Codes über ausgegliederte Sub

8.1.5. Wichtige sekundäre Sektionen

Files

Datei-Operationen, wie:

  • kopieren (mit Versionskontrolle, rekursiv …​)

  • löschen

  • Verzeichnisse anlegen

  • …​

WinBatch

Dient zum Aufrufen von Programmen über die Windows-API. Beispielsweise werden Aufrufe von Setup-Programmen im silent mode in diesen Sektionen durchgeführt.

ShellInAnIcon

Der Inhalt dieser Sektion wird der Betriebssystemtypischen 'shell' zur Ausführung übergeben. Diese 'shell’ist bei Windows die 'cmd.exe', bei Linux und bei MacOS die bash. Hier können also normale Batch-Skripte abgelegt werden.
Namensvarianten von ShellInAnIcon mit identischem Verhalten sind Shellbatch, DOSBatch und DOSInAnIcon.

ExecWith

Der Inhalt dieser Sektionen wird einem externen Programm (Interpreter) zur Ausführung übergeben. Beispielsweise können über 'ExecWith' AutoIt-Skripte http://www.autoitscript.com direkt in das opsi-winst-Skript integriert werden.

Registry

Die 'Registry-Sektionen' dienen dem Bearbeiten der Registry.

LinkFolder

'LinkFolder-Sektionen' dienen dem Erstellen und Entfernen von Verknüpfungen. Es können beispielsweise Verknüpfungen auf dem Desktop oder im Startmenü erstellt werden.

8.1.6. Globale Konstanten

Globale Konstanten sind Text-Platzhalter, die in primären und sekundären Sektionen eingesetzt werden können und zur Laufzeit textuell durch ihre Werte ersetzt werden.
Über die Verwendung von Platzhaltern kann sichergestellt werden, dass Pfade in unterschiedlichen Umgebungen (z.B. auf System mit unterschiedlichen Sprachen oder Betriebssystem-Versionen) richtig gesetzt sind.

Beispiele:

%ProgramFiles32Dir%

c:\programme

%Systemroot%

c:\windows

%System%

c:\windows\system32

%opsiTmpDir%

c:\

%Scriptpath%

<Pfad zu laufenden Script>

8.1.7. Zweites Beispiel: tightvnc

Zur Erläuterung nun ein einfaches Script zur Installation von 'tightvnc'. Eigentlich würde dieses Script mit dem Aufruf der Silent-Installation in der Winbatch-Sektion auskommen. Bei einer wiederholten Installation erscheint hier (wegen des Neustarts eines laufenden Services) jedoch ein interaktiver Dialog. Dieses Dialog-Fenster wird (so es auftaucht) 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")

8.1.8. Elementare Befehle für primäre Sektionen

String-Variable
Variablen-Deklaration

'DefVar <variable name>'

Variablen-Zuweisung

'Set <variable name> = <value>'

Beispiel:

DefVar $ProductId$
Set $ProductId$ = "firefox"
Stringvariablen werden in primären und sekundären Sektionen unterschiedlich behandelt. In primären Sektionen sind Stringvariablen eigenständige Objekte. Nur hier können sie deklariert und ihnen Werte zugewiesen werden. Entsprechend ist die Verbindung von Variablen und Strings zu einem Stringausdruck mit einem Operator "+" durchzuführen.
Beispiel: "Installing "+ $ProductId$ +" …​"
In sekundären Sektionen werden Stringvariablen vor der Ausführung der Sektion durch den Inhalt der Variable ersetzt.
Beispiel: "Installing $ProductId$ …​"
Dies ist zu beachten, wenn entsprechende Stringausdrücke per Cut&Paste im Skript kopiert werden.
Der Vorteil dieser Konstruktion ist, dass in Sektionen die außerhalb des 'opsi-winst' ausgeführt werden (DosBatch / Execwith) problemlos mit opsi-winst-Variablen gearbeitet werden kann.
Message / ShowBitmap

Zur Textausgabe während der Installation:
Message <string>

Beispiel:

Message "Installing "+ $ProductId$ +" ..."

Zur Ausgabe einer Grafik während der Installation:
ShowBitmap <filename> <subtitle>

Beispiel:

ShowBitmap "%ScriptPath%\python.png" "Python"
if [else] endif

Syntax:

if <condition>
	;statement(s)
[
else
	;statement(s)
]
endif
Funktionen
HasMinimumSpace

Prüft auf freien Platz auf der Festplatte.

FileExists

Prüft auf Existenz einer Datei oder eines Verzeichnisses.

Fehler, Logging und Kommentare
Kommentarzeichen ';'

Zeilen, die mit einem Semikolon (';') beginnen, werden nicht interpretiert.

Comment

Schreibt eine Kommentar-Meldung in die Log-Datei.

LogError

Schreibt eine Fehlermeldung in die Log-Datei.

IsFatalError

Bricht die Ausführung des laufenden Skriptes ab und meldet die Installation als gescheitert zurück.

Bedingung zur Ausführung
requiredWinstVersion

gibt die (mindestens) benötigte opsi-winst Version an.

Weitere wichtige opsi-winst Funktionen

Einen Überblick über die opsi-winst Funktionen gibt die Referencecard:
http://download.uib.de/opsi4.0/doc/opsi-winst-reference-card-en.pdf

Eine detaillierte Dokumentation ist im opsi-winst Handbuch zu finden:
http://download.uib.de/opsi4.0/doc/opsi-winst-manual-de.pdf

Hier noch einige Hinweise auf besonders wichtige Elemente:

Stringlisten:

Stringlisten sind sehr mächtig, insbesondere zur Auswertung von Ausgaben externer Programme. Lesen Sie dazu die opsi-winst-Dokus.

ExitWindows:

Neustart/Herunterfahren des Systems und Beendung des opsi-winst.

  • ExitWindows /Reboot
    Rechner-Neustart nach Abschluss des laufenden Skriptes.

  • ExitWindows /ImmediateReboot
    Sofortiger Neustart.

  • ExitWindows /ImmediateLogout
    Sofortige Beendigung der Skript-Bearbeitung und Beendung des opsi-winst.

Product-Properties:

Für manche Produkte ist es erforderlich, Optionen zur Verfügung zu stellen. Diese werden zur Laufzeit Client-spezifisch ausgewertet. Wie solche Properties erstellt werden, ist im Kapitel Erstellen eines opsi-Produkt-Pakets beschrieben.

Der Zugriff auf die Werte der Properties geschieht über die Funktion GetProductProperty:

if GetProductProperty("example-property", "no") = "yes"
	Files_copy_extra_files
endif
Encoding:

Schreiben Sie Ihre Scripte in UTF-8 Encoding und setzen sie die Zeile
encoding=utf8 an den Anfang der Datei-

Spezielle Kommandos für MacOS
  • GetOS // liefert: Linux or Windows_NT or macos [W/L/M]

  • getMacosVersionInfo [M]

  • getMacosVersionMap [M]

In den folgenden Kapiteln werden spezielle opsi MacOS Befehle zur Installation von Software vorgestellt welche aus der opsi-script Library uib_macosinstalllib stammen. Diese Dokumentation ist in Englisch, da sie direkt aus dem Quellcode automatisch generiert wurde.

Documentation of opsi library: uib_macosinstalllib.opsiscript

Documentation of local function install_macos_app
Definition

install_macos_app($myapp$ : string) : string

Description

try to install the app given by $myapp$

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"
endif

Documentation of local function install_macos_pkg
Definition

install_macos_pkg($mypkg$ : string) : string

Description

try to install the pkg file given by $mypkg$

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"
endif

Documentation of local function install_macos_dmg
Definition

install_macos_dmg($mydmg$ : string) : string

Description

try to install the dmg file given by $mydmg$

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"
endif

Documentation of local 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

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"
endif

Documentation of local 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

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"
endif

8.1.9. Drittes Beispiel: MacOS-Template 'm-opsi-template'

Dieses Template können Sie sich mit dem opsi-setup-detector erstellen.

setup.opsiscript: Installationsscript
; ----------------------------------------------------------------
; Copyright (c) uib gmbh (www.uib.de)
; This sourcecode is owned by uib
; and published under the Terms of the General Public License.
; ----------------------------------------------------------------
encoding=utf8

[Actions]
requiredWinstVersion >= "4.12.0.28"
ScriptErrorMessages = false

DefVar $ProductId$
DefVar $InstallDir$
DefVar $MinimumSpace$
DefVar $ExitCode$
DefVar $ErrorString$
DefVar $LicenseRequired$
DefVar $LicenseKey$
DefVar $LicensePool$
DefVar $OS$
DefVar $oldProgFound$
DefVar $installSuccess$


; import complete file !
importlib "uib_exitcode.opsiscript"
importlib "%scriptpath%\osd-lib.opsiscript"
importlib "%scriptpath%\uib_macosinstalllib.opsiscript"


; ----------------------------------------------------------------
; $ProductId$ is the name of the product in opsi, only lower letters, no umlauts, no white spaces, use '-' as a seperator
Set $ProductId$		 = "m-opsi-template"
Set $MinimumSpace$	 = "1 MB"
; the path were we find the product after the installation
;Set $InstallDir$		= "/Applications/<path to the product>"
Set $InstallDir$		= "/Applications/<productid.app>"
Set $LicenseRequired$ = "false"
Set $LicensePool$	  = ""
; ----------------------------------------------------------------

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%\delsub.opsiscript")
	comment "Start uninstall sub section"
	Sub "%ScriptPath%\delsub.opsiscript"
endif

Message "Installing " + $ProductId$ + " ..."

if $LicenseRequired$ = "true"
	comment "Licensing required, reserve license and get license key"
	set $LicenseKey$ = get_licensekey_byPool($LicensePool$)
endif


comment "Start setup "
ChangeDirectory "%SCRIPTPATH%/files1"
;----------------------------------------------
set $installSuccess$ = install_macos_generic("%SCRIPTPATH%/files1/<my macos install file>")
;----------------------------------------------
Sub_check_installSuccess


comment "Copy files"
Files_install

[Sub_check_installSuccess]
if $installSuccess$  = "false"
	LogError "Installation failed"
	isfatalerror "Installation failed"
else
	Comment "Installation success"
endif


[Files_install]
; Example of recursively copying some files into the installation directory:
;
; copy -s "%ScriptPath%\files\*.*" "$InstallDir$"
delsub.opsiscript: Ausgelagerte Deinstallations-Sub-Sektion
; Copyright (c) uib gmbh (www.uib.de)
; This sourcecode is owned by uib gmbh
; and published under the Terms of the Affero General Public License v3.
; ----------------------------------------------------------------
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"
	Message "Uninstalling " + $ProductId$ + " ..."
	if not(($InstallDir$ = '') or ($InstallDir$ = 'unknown') or ($InstallDir$ = '/Applications/'))
		Files_uninstall
	endif
endif


[Files_uninstall]
del -sf "$InstallDir$\"

;-----------------------------------------------------

[Linkfolder_remove_desktop_icon]
; check delete_element
set_basefolder common_desktopdirectory
set_subfolder ""
delete_element $productId$

;-----------------------------------------------------
uninstall.opsiscript: Deinstallations-Skript
; ----------------------------------------------------------------
; Copyright (c) uib gmbh (www.uib.de)
; This sourcecode is owned by uib
; and published under the Terms of the Affero General Public License v3.
; ----------------------------------------------------------------
encoding=utf8


[Actions]
requiredWinstVersion >= "4.12.0.28"
ScriptErrorMessages = false

DefVar $ProductId$
DefVar $InstallDir$
DefVar $MinimumSpace$
DefVar $ExitCode$
DefVar $ErrorString$
DefVar $LicenseRequired$
DefVar $LicenseKey$
DefVar $LicensePool$
DefVar $OS$
DefVar $oldProgFound$


; import complete file !
importlib "uib_exitcode.opsiscript"
importlib "%scriptpath%\osd-lib.opsiscript"


; ----------------------------------------------------------------
; $ProductId$ is the name of the product in opsi, only lower letters, no umlauts, no white spaces, use '-' as a seperator
Set $ProductId$		 = "m-opsi-template"
; the path were we find the product after the installation
;Set $InstallDir$	= "/Applications/<product.app>"
Set $InstallDir$	= "unknown"
Set $LicenseRequired$ = "False"
Set $LicensePool$	  = ""
; ----------------------------------------------------------------

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$



Message "Uninstalling " + $ProductId$ + " ..."

if FileExists("%ScriptPath%\delsub.opsiscript")
	comment "Start uninstall sub section"
	Sub "%ScriptPath%\delsub.opsiscript"
endif

if $LicenseRequired$ = "true"
	comment "Licensing required, free license used"
	Sub_free_license
endif

[Sub_free_license]
comment "License management is enabled and will be used"

comment "Trying to free license used for the product"
DefVar $result$
Set $result$ = FreeLicense($LicensePool$)
; If there is an assignment of a license pool to the product, it is possible to use
; Set $result$ = FreeLicense("", $ProductId$)
;
; If there is an assignment of a license pool to a windows software id, it is possible to use
; DefVar $WindowsSoftwareId$
; $WindowsSoftwareId$ = "..."
; set $result$ = FreeLicense("", "", $WindowsSoftwareId$)

8.2. Erstellen eines opsi-Produkt-Pakets

8.2.1. Installation des opsi-setup-detector, opsi PackageBuilder und opsi-logviewer

Installation des opsi PackageBuilder

Den opsi PackageBuilder gibt es derzeit für Windows, Linux und MacOS.

Die Installations-Dateien / Pakete des opsi PackageBuilder finden Sie hier:
https://forum.opsi.org/viewtopic.php?p=32473#p32473
Dort findet sich im oberen Teil die Links auf die Installationspakete für Windows, Linux und MacOS.
Der opsi PackageBuilder kommt nicht von 'uib' sondern aus der opsi-community von Holger Pandel (Danke!).

Der opsi PackageBuilder unterliegt einer OpenSource Lizenz:
https://github.com/pandel/opsiPackageBuilder/blob/master/LICENSE_DE

Der opsi PackageBuilder hat eine eigene Dokumentation welche mit installiert wird.

Installation des opsi-setup-detector

Den opsi-setup-detector gibt es derzeit für Windows und Linux.

Sie können den opsi-setup-detector per opsi installieren:

Das Paket opsi-setup-detector gehört zu den opsi Standardprodukten und sollte auf Ihrem opsi-server installiert sein. Falls nicht, mit:

opsi-package-updater install opsi-setup-detector

können Sie es auf dem opsi-server installieren.

Ein Setup-Programm um den opsi-setup-detector auf Windows auch ohne opsi zu installieren, finden sie unter :
https://download.uib.de/opsi4.1/misc/helper/

Die Funktionalität der Linux-Version ist in folgen Features eingeschränkt, da bestimmte Programm zur Analyse von Setup-Programmen aus bestimmten Frameworks nicht für Linux zur Verfügung stehen:

  • Genauere Analyse von Inno-Setups mangels innounpack.exe für Linux

  • Genauere Analyse von wix-setups mangels dark.exe für Linux

Das opsi-Produkt opsi-setup-detector hat eine Abhängigkeit zu dem opsi-Produkt opsi PackageBuilder. Der opsi-setup-detector verwendet den opsi PackageBuilder wenn vorhanden, funktioniert in weiten Teilen aber auch ohne. Die Installation des opsi PackageBuilder ist aber empfohlen.

Installation des opsi-logviewer

Den opsi-logviewer gibt es derzeit für Windows, Linux und MacOS.

Sie können den opsi-logviewer per opsi installieren:

Das Paket opsi-logviewer gehört zu den opsi Standardprodukten und sollte auf Ihrem opsi-server installiert sein. Falls nicht, mit:

opsi-package-updater install opsi-logviewer

können Sie es auf dem opsi-server installieren.

Ein Setup-Programm um den opsi-setup-detector auf Windows auch ohne opsi zu installieren, finden sie unter :
https://download.uib.de/opsi4.1/misc/helper/

Das opsi-produkt opsi-logviewer hat eine Abhängigkeit zu dem opsi-Produkt javavm.

8.2.2. Das Programm opsi-setup-detector zum Erstellen eines MacOS Scriptes

Opsi-setup-detector Start und notwendige Konfigurationen

Der opsi-setup-detector kann gestartet werden aus der Programm Menü und findet sich dort unter opsi.org. Der opsi-setup-detector wird unter Windows auch in das Kontextmenü des Explorers eingebunden, um so per Rechte Maustaste Setup-Programm direkt zur Analyse aufrufen zu können.

Konfigurationsdialog
Abbildung 2. opsi-setup-detector Notwendige Konfiguration beim ersten Start

Nach dem erstmaligen Start des opsi-setup-detector erscheint ein Konfigurationsmaske. Hier sind die folgenden Angaben erforderlich:

  • fullname : (Wird verwendet für Einträge in die changelog.txt)

  • email_address (Wird verwendet für Einträge in die changelog.txt)

  • workbench_path : Pfad zum Verzeichnis in dem die opsi-Pakete erstellt werden sollen. Dies ist idealerweise der Pfad zu der Stelle an der die opsi_workbench Ihres opsi-servers gemountet ist.

Nachdem Sie die notwendigen Konfigurationsangaben gemacht und gespeichert haben, erscheint die Startseite.

Startpage
Abbildung 3. opsi-setup-detector Start

Auf der Startseite wählen Sie die gewünschte Aufgabe und folgen den Dialogen bzw. wählen den Button 'Nächster Schritt'.

Die angebotenen Aufgaben sind gruppiert nach:

  • Windows

  • Linux

  • MacOS

  • Multiplattform

Die Angebotenen Aufgaben für MacOS:

  1. Analysiere einzelne MacOS Installer Datei und erzeuge ein opsi Paket
    Hier wird von einer MacOS Installer-Datei ausgegangen und der gesamte Ablauf bis zur Erzeugung eines opsi-Paketes durchlaufen. Dieser Prozeß ist im nächsten Kapitel beschrieben.

  2. Eine opsi Paketvorlage (Template) für MacOS erzeugen
    Dieser Punkt fragt nicht nach einer Setup-Datei, sondern erstellt ein Template analog dem opsi-Produkt opsi-template nur das hier die Angaben aus der Produktkonfiguration bereits übernommen werden.

Die nun folgenden Screenshots zeigen zwar die Verwendung von Windows-Installer Dateien, sie sehen aber analog aus bei der Verwendung von MacOS Installer Dateien wie *.app, *.dmg, *.zip.

Opsi-setup-detector: Analysiere einzelne Setup Datei und erzeuge ein opsi Paket

Im folgenden wird der Ablauf anhand des Punktes Analysiere einzelne Setup Datei und erzeuge ein opsi Paket erläutert.

Startpage
Abbildung 4. opsi-setup-detector Start

Nach der Auswahl der Aufgabe erscheint ein Dateiauswahl-Dialog zur Auswahl der zu analysierenden Setup Datei. Nach der Auswahl beginnt direkt die Analyse.

Opsi-setup-detector: Analyse
Analyse
Abbildung 5. opsi-setup-detector Analyse

War die Analyse nicht erfolgreich, endet sie hier mit Sorry unknown Installer. Bei einer erfolgreichen Analyse wird direkt zum Ergebnis gewechselt.

Ergebnis der Analyse
Abbildung 6. opsi-setup-detector Ergebnis der Analyse
  • Erkannter Setup Typ: Typ des erkannten Installer

  • MST allowed:

  • Link mit Infos zum Installer

  • Setup Datei: Pfad und Name der analysierten Setup-Datei

  • MST Datei: Bei MSI-Installern oder Installern welche MSI enthalten, kann hier eine MST-Datei angegeben werden welche in den MSI Aufruf integriert wird.

  • MsiId: Bei MSI-Installern oder Installern welche MSI enthalten, der MSI-Produktcode

  • Software Version: Die Version der zu installierenden Software soweit ermittelbar

  • Setup Datei Größe MB: Größe der Setup Datei in MB

  • Benötigter Platz MB: Dieser Wert ist eine Schätzung aus sechsmal die Größe der Setup-Datei und kann gegebenenfalls angepasst werden

  • InstallDir: Soweit erkannt das Verzeichnis in das die Software installiert werden wird

  • Unattended Installationskommando: Das ermittelte Kommando zu einer nicht interaktiven Installation

  • Unattended Deinstallationskommando: Das ermittelte Kommando zu einer nicht interaktiven Deinstallation

  • Deinstallations Programm: Das ermittelte Deinstallations Programm

Die hier ermittelten Werte können nun bei Bedarf korrigiert oder ergänzt werden. Der Button Nächster Schritt führt zur ersten Seite der Produktkonfiguration. Hier werden die Metadaten des zu erstellenden opsi Produktes eingegeben.

Die hier ermittelten Werte können falsch sein und sind wahrscheinlich unvollständig !
Nach einer ersten Installation sollten Sie unbedingt die Werte von InstallDir, Deinstallations Programm und Software Version überprüfen und gegebenenfalls in Ihrem Script anpassen.
Opsi-setup-detector: Produktkonfiguration 1
Produktkonfiguration 1
Abbildung 7. opsi-setup-detector Produktkonfiguration 1
  • opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein '-' ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.

  • Produkt Name: der Name der zu installierenden Software. Dieser muss evtl. händig korrigiert werden

  • Produkt Version: die aus dem Name der Setup-Datei ermittelte Versionsnummer muss wahrscheinlich händig korrigiert werden. Sie darf nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.

  • Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.

  • Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts '$LicenseRequired$=true' gesetzt.

Opsi-setup-detector: Priorität und Abhängigkeiten
Produktkonfiguration 2
Abbildung 8. opsi-setup-detector Produktkonfiguration 2

Für normale Anwendungssoftware müssen Sie hier nichts tun, da die Voreinstellungen 'passen'. Sie können auf den Button Nächster Schritt drücken.

Ansonsten sei hier erläutert, welche Einstellungen hier möglich sind:

Priorität

beeinflusst die Installationsreihenfolge. Empfohlen für Anwendungssoftware: 0
Mögliche Werte liegen zwischen 100 (ganz am Anfang) und -100 (ganz am Ende). Existieren auch Produktabhängigkeiten, so beeinflussen diese zusätzlich die Installationsreihenfolge.

Abhängigkeiten

Hier können Abhängigkeiten zwischen Podukten definiert werden.

Dependency Editor
Abbildung 9. opsi-setup-detector Dependency Editor
Productid

Productid (Bezeichner) des Produkts zu dem eine Abhängigkeit besteht.

Abhängigkeits Modus

Sie können entweder die Aktion setup anfordern oder (siehe unten) den Status (installed).

Aktion oder Status

Für Status: Status den das Produkt, zu dem eine Abhängigkeit besteht, haben soll (installed). Liegt ein anderer Status vor, so wird das Produkt auf setup gestellt.
Für Aktion: Aktionsanforderung welche bei dem Produkt, zu dem eine Abhängigkeit besteht, gesetzt werden soll (setup)

Abhängigkeits typ

Installationsreihenfolge. Wenn das Produkt, zu dem eine Abhängigkeit besteht, installiert sein muss bevor mit der Installation des aktuellen Produkts begonnen werden kann, dann ist dies before. Muss es nach dem aktuellen Produkt installiert werden so ist dies after. Ist die Reihenfolge egal so muss hier nichts eingetragen werden.

Hinweis:

Leider gibt es derzeit keinen generischen Mechanismus für Deinstallations-Produktabhängigkeiten. Zuverlässig ist der ProductDependency-Mechanismus nur für action: setup und die hierbei zu triggernden (before- oder after-) setup Aktionen und installed Status. Ein requiredAction: uninstall führt leider definitiv zu Fehlern.

Noch ein Hinweis:

Die tatsächliche Installationsreihenfolge ermittelt sich aus einer Kombination von Produktabhängigkeiten und Produktpriorisierung. Details hierzu finden Sie im opsi-Handbuch im Kapitel 'Beeinflussung der Installationsreihenfolge durch Prioritäten und Produktabhängigkeiten'

Opsi-setup-detector: Poperties

Hier können veränderbare Eigenschaften (Produktvariablen) für das Produkt definiert werden.

Property Editor
Abbildung 10. opsi-setup-detector Property Editor

Feld / Funktion

Beschreibung

Hinweise

Property Name

Name der Produktvariable

Dieser Bezeichner wird in der Produktkonfiguration im opsi-configed angezeigt und ist innerhalb der Skripte mit der Funktion GetProductProperty auslesbar.

Property Type

Variablentyp

Mögliche Werte: Text / bool

Multivalue

Bestimmt, ob die Produktvariable nur genau einen oder mehrere Werte annehmen kann

Nur bei Typ Text verfügbar

Editierbar

Bestimmt, ob die Vorgabewerte mit neuen oder zusätzlichen Werten überschrieben werden können oder nicht

Nur bei Typ Text verfügbar

Beschreibung

Beschreibung der Variablenfunktion

Wird im opsi-configed als Tooltip angezeigt

Possible Werte

Komma-separiert Liste der möglichen Eingabewerte

Falls Editierbar auf “True” gesetzt wurde, kann die Liste später innerhalb von opsi-configed ergänzt werden.
Nur bei Typ Text verfügbar

Default Wert

Vorgabewert

Auswahlliste; Nur bei Typ Text verfügbar: Freitextfeld. Nur bei Typ Multivalue verfügbar: Mehrfachauswahl

Produktkonfiguration 3 (Icon)
Abbildung 11. opsi-setup-detector Produktkonfiguration 3 (Icon)

Hier kann ein Icon für die Anzeige während der Installation ausgewählt werden oder Sie übernehmen mit Nächster Schritt das DefaultIcon (Zahnrad) und wechseln zum nächsten Reiter..

Um ein anderes Icon auszuwählen wählen Sie über den Button Öffne Icon Verzeichnis in Verzeichnis aus in dem Sie Icons erwarten. Als Vorauswahl bekommen Sie einbeim opsi-setup-detector mitgeliefertes Verzeichnis von 'open source' Icons: 128x128. Wählen Sie ein Unterverzeichnis und die Icons werden angezeigt.
Nun können Sie aus der Anzeige ein Icon auswählen.

Nachdem die Produktkonfiguration vollständig ist, kann nun das Produkt erzeugt werden.

Opsi-setup-detector: Produkt erzeugen
Produkt erzeugen
Abbildung 12. opsi-setup-detector Produkt erzeugen
  • 'Pfad zur opsi-workbench' ist ein Laufwerksbuchstabe oder UNC Pfad auf dem der share opsi_workbench Ihres opsi-servers gemounted ist.

  • aus Sicherheitsgründen kann ein opsi Paket nur dann neu erzeugt werden, wenn es noch nicht vorhanden ist. Falls ein bestehendes Paket überschrieben werden soll, muss zuerst das Verzeichnis von der opsi Workbench gelöscht werden.

  • Links neben dem Button 'Erzeuge opsi Paket' befinden sich drei mögliche Auswahl Optionen, die sich auf die Funktion des Buttons beziehen:

  • Erstellungs-Modus ist ein Auswahlbereich bei dem die Vorgänge bei der Paketerstellung bestimmt werden können:

  • Erstelle opsi Produkt Dateien erzeugt falls noch nicht vorhanden, den Verzeichnisbaum für das neue opsi Paket auf der gewählten opsi-Workbench. Die für das Pakte benötigten Dateien werden erzeugt bzw. kopiert.

  • Erstelle opsi Produkt Dateien und baue opsi Paket führt die im ersten Punkt angeführten Vorgänge durch.
    Zusätzlich wird der opsi PackageBuilder aufgerufen um aus dem erstellen Verzeichnisbaum das opsi-Paket zu erstellen. Die genauen Abläufe werden dabei durch das Auswahlfeld Baumodus bestimmt:

    • nur bauen startet den opsi PackageBuilder ohne interaktive GUI, erstellt aus dem Verzeichnisbaum per Server Befehl opsi-makepackage ein opsi Paket und beendet den opsi PackageBuilder nach getaner Arbeit wieder.

    • bauen und installieren startet den opsi PackageBuilder ohne interaktive GUI, erstellt aus dem Verzeichnisbaum per Server Befehl opsi-makepackage ein opsi Paket installiert das Paket per Server Befehl opsi-package-manager und beendet den opsi PackageBuilder nach getaner Arbeit wieder.

  • Erstelle opsi Produkt Dateien und starte interaktiven Packagebuilder führt die im ersten Punkt angeführten Vorgänge durch.
    Zusätzlich wird der opsi PackageBuilder interaktiv aufgerufen.
    Sie müssen diesen selbst beenden um zu dem opsi-setup-detector zurückzukehren Zu Installation, Konfiguration und Bedienung des Community Projektes 'opsi PackageBuilder' siehe https://forum.opsi.org/viewforum.php?f=22

  • opsi-Paket erstellen ist der Button welcher die Paketerstellung veranlasst. Aus Sicherheitsgründen kann ein opsi Paket nur dann neu erzeugt werden, wenn es noch nicht vorhanden ist. Ist bereits ein Paket mit diesem Namen vorhanden, so erscheint eine Rückfrage ob das vorhandene Verzeichnis gelöscht werden darf.

8.2.3. Das Programm opsi PackageBuilder zum modifizieren eines Scriptes

Beim ersten Start nach der Installation startet der opsi PackageBuilder im Offline Modus, da noch wichtige Konfigurationsdaten für die Verbindung mit dem opsi-server fehlen.

Erster Start
Abbildung 13. opsi PackageBuilder Erster Start: Offline Modus

Sollte der der Start auf diese Weise nicht funktionieren und das Startmenü nicht reagieren (beobachtet unter Linux / KDE), so probieren sie es von der Kommandozeile unter Angabe irgend eines Pfades und bestätigen die Fehlermeldung das der Pfad nicht gefunden wurde:

opsipackagebuilder --path /home
Initiale Konfiguration des opsi PackageBuilder

Um die fehlenden Konfigurationsdaten einzugeben öffnen Sie die 'Einstellungen'.

Einstellungen: Allgemein
Abbildung 14. opsi PackageBuilder Einstellungen: Allgemein

Im Reiter 'Allgemein' machen Sie bitte folgende Einstellungen:

  • 'Konfigserver' : Vollständiger Name (FQDN) Ihres opsi-configservers (z.B. opsi.mycompany.org)

  • 'opsiadmin Benutzer': username eines Mitglieds der Gruppe opsiadmin (Am besten Ihr username)

  • 'opsiadmin Passwort': das Passwort des oben angegeben Benutzers. Dieses wird nicht angezeigt und verschlüsselt gespeichert. Es ist notwendig damit der opsi PackageBuilder mit dem opsi-server kommunizieren kann.

  • 'opsi Server Version': opsi 4.1 oder höher

  • 'opsi Workbench' : /var/lib/opsi/workbench

  • 'Kompatibilität der Befehlsausführung' : opsi 4.0.4 oder neuer / Sudo ohne Passwort

  • 'Benutzer' : Ihr voller Name (wird in changelogs verwendet)

  • 'EMail' : Ihre eMail Adresse (wird in changelogs verwendet)

Einstellungen: Programm
Abbildung 15. opsi PackageBuilder Einstellungen: Programm

Im Reiter 'Programm' machen Sie bitte folgende Einstellungen:

  • 'Bestehendes Netzlaufwerk verwenden' : Häkchen setzen

  • 'Entwicklungsordner' : Pfad zum Verzeichnis in dem die opsi-Pakete erstellt werden sollen. Dies ist idealerweise der Pfad zu der Stelle an der die opsi_workbench Ihres opsi-servers gemountet ist.

  • 'Skripteditor' :
    Den Skripteditor des opsi PackageBuilder gibt es leider nur für Windows.

    • Unter Windows belassen Sie es bei den Voreinstellungen

    • Unter Linux: Externer Editor: /usr/local/bin/jedit
      Kommandozeilenoptionen: (leer)

    • Unter MacOS: Externer Editor: /Application/jedit
      Kommandozeilenoptionen: (leer)

Einstellungen: Verwaltung
Abbildung 16. opsi PackageBuilder Einstellungen: Verwaltung

Im Reiter 'Verwaltung' empfehlen wir folgende Einstellung abweichend vom Default

  • 'Paketieren' : opsi-makepackage -v

Speichern Sie die Einstellungen und starten Sie den opsi PackageBuilder neu. Der opsi PackageBuilder sollte nun nicht mehr 'Offline Modus' melden.

Mit dem opsi PackageBuilder Pakete modifizieren, packen und Installieren
Start
Abbildung 17. opsi PackageBuilder Start

Verwenden Sie 'Paket öffnen (F2)' und wählen Sie das Verzeichnis in dem das Sie mit dem opsi-setup-detector erstellt haben. (z.B.: w:\newprod2 )
Dann öffnet sich das Produktfenster mit verschiedenen Reitern. Der default Reiter ist 'Paket'.

Reiter Packet
Abbildung 18. opsi PackageBuilder Reiter Packet

In desem Reiter sehen auf der Linken Seite die allgemeinen Metadaten des opsi-Produktes wie Sie auch schon in Abschnitt 8.2.2.4, “Opsi-setup-detector: Produktkonfiguration 1” erläutert wurden.

Auf der rechten Seite sehen Sie die Scriptdateien und daneben den Button:

Button Edit
Abbildung 19. opsi PackageBuilder Button Edit

Mit dem Button können Sie die Datei in dem in der Konfiguration angegebenen Scripteditor aufrufen und das Script modifizieren. Unter Windows ist das der Scripteditor des opsi PackageBuilder.

Scripteditor
Abbildung 20. opsi PackageBuilder Scripteditor unter Windows

Wesentliche Merkmale:

  • Farbige Syntaxhervorhebung

  • “Falten” des Quellcodes (optional: kompakt, mit Kommentaren)

  • Lexerdefinition anpassbar (dazu muss der Editor per Startmenü Eintrag aufgerufen werden)

  • Autocomplete für Syntaxelemente und Variablen

  • Frei definierbare und wiederverwendbare Codeblöcke (“Snippets”)

Die Kernkomponente des Editors bildet das Modul Scintilla, welches auch in andere bekannten Editoren, wie bspw. Notepad++, verwendet wird. Die lexikalischen Elemente (Syntaxhervorhebung und Faltung) zur Darstellung der für opsi gültigen Scriptsprache sind allerdings komplett in AutoIt geschrieben, da Scintilla für opsi Skripte kein eigenes Darstellungsmodul mitliefert. Dadurch, dass AutoIt eine Interpretersprache ist, ist er damit langsamer als andere Editoren und eignet sich daher nur bedingt zur Bearbeitung sehr großer Skripte, vor allem bei eingeschalteter Quellcode Faltung. In den Einstellungen lässt sich jedoch vorgeben, ob der Editor mit diesen Funktionen überhaupt aufgerufen wird oder nicht, sofern der Aufruf direkt über den Skriptbaum erfolgt. Bei einem Aufruf über den Link im Startmenü sind Syntaxhervorhebung und Faltung generell beim Start ausgeschaltet und können über das Editormenü “Ansicht” aktiviert werden.

(Der Editor kann auch über die Kommandozeile aufgerufen werden. Weitere Informationen zu den möglichen Kommandozeilenparametern können mit der Option “–help” aufgerufen werden.)

Reiter Produktvariablen (Properties)
Abbildung 21. opsi PackageBuilder Reiter Produktvariablen (Properties)

In desem Reiter sehen auf der Linken Seite die Produkt Properties des opsi-Produktes wie Sie auch schon in Abschnitt 8.2.2.6, “Opsi-setup-detector: Poperties” erläutert wurden.

Reiter Abhängigkeiten
Abbildung 22. opsi PackageBuilder Reiter Abhängigkeiten

In desem Reiter sehen auf der Linken Seite die Produkt Abhängigkeiten des opsi-Produktes wie Sie auch schon in Abschnitt 8.2.2.5, “Opsi-setup-detector: Priorität und Abhängigkeiten” erläutert wurden.

Button: Packen
Abbildung 23. opsi PackageBuilder Button: Packen

Dieser Button startet eine SSH-Verbindung vom Server und ruft dort den Paketierungsbefehl auf.
Sie können das selbe auch in einem Terminal selber machen wie in Packen mit opsi-makepackage beschrieben.

Button: Installieren
Abbildung 24. opsi PackageBuilder Button: Installieren

Dieser Button startet eine SSH-Verbindung vom Server und ruft dort den Installationsbefehl auf um das Produkt auf dem Server zu installieren.
Sie können das selbe auch in einem Terminal selber machen wie in Installieren mit opsi-package-manager beschrieben.

Button: Installieren + Setup
Abbildung 25. opsi PackageBuilder Button: Installieren + Setup

Finger weg

8.2.4. Testen und verbessern eines opsi-script Skriptes

Zum Testen und Verbessern eines Scriptes / Produktes gibt es zwei verschiedene Varianten:

  • Testen des erstellten Scriptes 'Standalone' also ohne es auf dem opsi-server zu installieren und es von dort auf den Client auszurollen

  • 'Integrierte' Tests des kompletten Produktes mit Installation auf dem Server und Ausrollen auf einem Client

In beiden Fällen gehen wir hier davon aus, das Sie ein Projekt mit dem opsi-setup-detector erstellt haben.

'Standalone' Tests

Starten Sie die Anwendung opsi-script-gui: per Doppelklick.

  • Windows: Die Datei opsi-script.exe per Doppelklick.
    (Beim Starten des Programms auf einem Windows 7 / 10 Client muss "ausführen als Administrator" über die rechte Maustaste verwendet werden.) Wenn der opsi-client-agent bereits auf Ihrem Rechner installiert ist, finden Sie diese unter C:\Program files (x86)\opsi.org\opsi-client-agent\opsi-winst\winst32.exe Wenn nicht, kopieren Sie sich das Verzeichnis opsi-winst vom share \\<opsiserver\opsi_depot, aus dem Verzeichnis opsi-winst\files.

  • Linux: Starten sie Datei /usr/bin/opsi-script-gui

  • MacOS: Starten sie die Anwendung /Applications/opsi-script-gui

Sie sehen dann folgendes Fenster:

Screenshot: opsi-script-gui im interaktiven Modus
Abbildung 26. opsi-script-gui im interaktiven Modus
  • Über 'Select Script' können Sie das Skript auswählen, dass Sie ausführen möchten.

  • Mit 'Start' können Sie das Script starten. Dabei wird das Script auf diesem Rechner ausgeführt.

  • Öffnen Sie nun mit dem opsi-logviewer die Log-Datei an, um nachzuvollziehen, wie der opsi-script das Skript interpretiert.
    Achten Sie dabei darauf, das Sie hier mit dem Schieberegler rechts unten den angezeigten Loglevel einstellen können.

  • Öffenen Sie das Script setup.opsiscript in einem Editor und führen Sie gewünschte Änderungen durch (Speichern nicht vergessen). Dazu gibt es mehrere Möglichkeiten:

    • Öffnen Sie das Projekt im opsi PackageBuilder und öffnen von dort den Editor.

    • Im Prinzip können Sie auch jeden anderen beliebigen Editor verwenden.
      Wir empfehlen den Editor 'jEdit' mit opsi-script Syntax-Highlighting, wie Sie ihn in der Grundausstattung der opsi-Produkte finden.

jEdit with a opsi script
Abbildung 27. jEdit mit einem opsi script
  • Sie können nun das Skript im Editor anpassen und speichern (Sie können den Editor geöffnet lassen).
    Wechseln Sie zum opsi-script-Fenster und starten Sie das Skript erneut über den Knopf 'Start' (das Skript muss nicht neu ausgewählt werden).
    Schauen Sie sich das auf Basis Ihrer Änderungen im Skript veränderte Log über opsi-logviewer an. (Neu laden über Kontext Menü oder Button in der Symbolleiste nicht vergessen).

  • Auf diese Art und Weise, also über die Wiederholung der Punkte:

    • Anpassung des Skriptes und speichern

    • Skript ausführen

    • Log überprüfen
      können Sie nach und nach Ihre Skripte so anpassen, dass sie das tun, was Sie wünschen.

Hinweise zur Lösung von Detail-Problemen finden Sie im nächsten Kapitel. Im übernächsten Kapitel wird erklärt, wie Sie aus den so erstellten Skripten ein opsi-Produkt erstellen, das Sie auf dem opsi-server installieren können.

'Integrierte' Tests

Bei den 'integrierten Test' wird immer gleich das ganze Projekt per opsi auf einem Testclient ausgeführt. Gehen Sie dazu wie folgt vor:

  • Öffnen Sie das Script setup.opsiscript in einem Editor und führen Sie gewünschte Änderungen durch (Speichern nicht vergessen). Dazu gibt es mehrere Möglichkeiten:

    • Öffnen Sie das Projekt im `opsi PackageBuilder' und öffnen von dort den Editor.

    • Im Prinzip können Sie auch jeden anderen beliebigen Editor verwenden.
      Wir empfehlen den Editor 'jEdit' mit opsi-script Syntax-Highlighting, wie Sie ihn in der Grundausstattung der opsi-Produkte finden.

  • Produkt Packen

    • Variante 1: Öffnen Sie das Projekt im opsi PackageBuilder und starten Sie das Packen über den Button Packen.

    • Variante 2: Melden Sie sich per Terminal (z.B. Putty) auf dem opsi-server an und wechseln Sie in das Projektverzeichnis auf der Workbench. Packen Sie das Produkt per Befehl opsi-makepackage.

  • Produkt auf dem opsi-server installieren.

    • Variante 1: Starten Sie das Installieren im opsi PackageBuilder über den Button Installieren.

    • Variante 2: Starten Sie das Installieren im Terminal im Projektverzeichnis mit dem Befehl opsi-package-manager -i <myproctid_version.opsi>. Dabei ist <myproctid_version.opsi> der Dateiname der im vorherigen Schritt beim packen ausgegeben wurde.

  • Produkt über opsi-configed auswählen und starten

    1. Im Tab Clients den Testclient auswählen

    2. Im Tab Produktkonfiguration das Produkt auswählen. Sollte das Produkt nicht sichtbar sein (was nach dem ersten Installieren normal ist) einmal über das Menü 'Datei / Alle Daten neu laden' bzw. den Button ganz links in der Symbolleiste die Daten neu laden

    3. Für das gewählte Produkt die Aktionsanforderung setup setzen und speichern.

    4. Den Client starten oder bei laufenden Client per Kontextmenü on_demand starten.

    5. Abwarten bis das Produkt auf dem Client durchgelaufen ist.

      • Im Tab 'Logfiles / instlog' die Log-Datei inspizieren, um nachzuvollziehen, wie der opsi-script das Skript interpretiert.
        Achten Sie dabei darauf, das Sie hier mit dem Schieberegler rechts unten den angezeigten Loglevel einstellen können.

  • Auf diese Art und Weise, also über die Wiederholung der Punkte:

    • Anpassung des Skriptes und speichern

    • Produkt packen

    • Produkt auf dem Server installieren

    • Produkt auf dem Client ausführen

    • Log überprüfen
      können Sie nach und nach Ihre Skripte so anpassen, dass sie das tun, was Sie wünschen.

8.2.5. Packen mit opsi-makepackage

Danach können Sie das Produkt packen. Gehen Sie dazu in das Stammverzeichnis des Produkts und rufen Sie 'opsi-makepackage' auf. Es wird nun das Produkt gepackt.

Es ist zu empfehlen die Pakete gleich mit einer zugehörigen md5-Prüfsummendatei zu erstellen. Diese Datei wird unter anderem vom opsi-package-updater genutzt, um nach der Paketübertragung die Paketintegrität sicher zu stellen. Eine solche Datei wird automatisch erstellt, aber für besondere Einsatzszenarien kann die Erstellung unterdrückt werden.

Bei der Übertragung von Paketen auf opsi-depotserver kann auf 'zsync' zurück gegriffen werden, um nur Unterschiede zwischen verschiedenen Paketen zu übertragen. Damit dieses Verfahren verwendet werde kann, wird eine Datei besondere .zsync-Datei benötigt. Eine solche Datei wird automatisch erstellt, aber für besondere Einsatzszenarien kann die Erstellung unterdrückt werden.

Wenn es beim Erstellen großer Pakete zu Platzproblemen im temporären Verzeichnis /tmp kommt, ist es möglich mittels --temp-directory ein abweichendes temporäres Verzeichnis anzugeben.

Wenn schon ein Paket dieser Version existiert, so zeigt opsi-makepackage eine Rückfrage:

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:

Mit o wählen Sie überschreiben, mit c brechen Sie den Vorgang ab und mit n können Sie wählen, dass Sie nach einer neuen Product- bzw. Package-Version gefragt werden.

Das gepackte Paket können Sie mit opsi-package-manager --install <paketdatei> auf dem Server installieren.

8.2.6. Installieren mit opsi-package-manager

Um das gepackte Produkt zu installieren gibt es den Befehl opsi-package-manager . Gehen Sie dazu in das Stammverzeichnis des Produkts und rufen Sie folgenden Befehl auf.

opsi-package-manager -i <myproductid_version.opsi>

8.2.7. Beispiel einer 'control' Datei

[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

8.2.8. Erstellen eines opsi-paketes mit dem CLI tool opsi-newprod

opsi-newprod ist ein Kommandozeilen Werkzeug zum Erstellen eines opsi-product Gerüstes.

Zum Erstellen wechselt man in dieses Verzeichnis und ruft opsi-newprod auf. Das Programm fragt daraufhin nach dem Typ des zu erstellenden Paketes. Dies ist üblicherweise der Typ localboot für Produkte, die über den 'opsi-client-agent'/'opsi-winst' installiert werden. Der Typ netboot steht für Produkte, die über das opsi-Linux-Bootimage ausgeführt werden (wie z.B. die Betriebssystem-Installationen).

Screenshot: Auswahl des Produkttyps: localboot
Abbildung 28. Auswahl des Produkttyps: localboot

Wählen Sie nun mit Tab OK (oder bestätigen mit F12). Nun müssen Sie die wesentlichen Produktdaten eingeben. Am oberen Rand ist hierzu eine Hilfe, die erläutert was die Felder bedeuten.

Screenshot: Eingabe der Produktinformationen
Abbildung 29. Eingabe der Produktinformationen
Product Id

ist ein eindeutiger Bezeichner für das Produkt in der Regel unabhängig von der Version
Bitte nur Kleinbuchstaben verwenden, keine Umlaute, keine Leerzeichen, keine Sonderzeichen - '-' ist als Trenner erlaubt.

Product name

ist der Klartextname des Produkts (wir empfehlen die Vermeidung von Umlauten, '-' ist erlaubt, keine Leerzeichen).

Description

ist eine ergänzende Beschreibung zum Produkt, die z.B. im opsi-Configeditor unter Beschreibung angezeigt wird.

Advice

ist eine ergänzende Beschreibung, in der Regel zum Umgang mit dem Produkt, die zu beachten ist und im opsi-Configeditor unter Notiz angezeigt wird.

Product version

ist die Version der eingepackten Software (max. 32 Zeichen).

Package Version

ist die Version des Paketes für die Produktversion. Sie dient dazu, Pakete mit gleicher Produktversion, aber z.B. korrigiertem opsi-winst-Skript zu unterscheiden.

License required

hat bei localboot Produkten keinen Einfluss. Bei netboot Produkten entscheidet diese Option, ob ein Lizenzkey aus dem Lizenzmanagement geholt wird.

Priority

beeinflusst die Installationsreihenfolge. Mögliche Werte liegen zwischen 100 (ganz am Anfang) und -100 (ganz am Ende). Existieren auch Produktabhängigkeiten, so beeinflussen diese zusätzlich die Installationsreihenfolge.

Screenshot: Eingabe der opsi-winst-Skript Namen für unterschiedliche Aktionen
Abbildung 30. Eingabe der opsi-winst-Skript Namen für unterschiedliche Aktionen

Nach Eingabe der Produktinformationen werden Sie aufgefordert, die Skripte anzugeben, die Sie für die unterschiedlichen möglichen Aktionen bereit stellen werden.

Üblicherweise heißt das Setup script gleich setup.opsiscript.

Üblicherweise heißt das Uninstall script gleich uninstall.ins.

Ein Update-Script dient zur geringfügigen Veränderung einer existierenden großen Installation. Wird das Produkt auf setup gestellt, so wird nach dem Abarbeiten des Setup-Skriptes automatisch auch das Update-Skript ausgeführt.

Ein Always-Script wird bei jedem aktiv werden des opsi-Clientagenten ausgeführt (z.B. bei jedem Boot).

Ein Once-Script hat den Folgestatus not_installed. Es handelt sich hierbei um einen sehr selten verwendeten Schalter, den Sie ignorieren sollten, wenn Sie nicht genau wissen, was Sie damit tun wollen.

Ein Custom-Script verändert weder Folgeaktion noch 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.

Ein userLoginScript dient dazu nach dem Login des users Modifikationen am Profil des eingeloggten users vorzunehmen. Dies Funktioniert nur im Zusammenhang mit der opsi Erweiterung 'User Profile Management' und ist im entsprechenden Kapitel des opsi-Handbuchs beschrieben.

Typ

Folgestatus

Folgeaktion

setup

installed

none

uninstall

not_installed

none

update

installed

none

always

installed

always

once

not_installed

none

custom

unverändert

unverändert

User login

unverändert

unverändert

Nachdem nun das Produkt selber beschrieben ist, können Sie eine oder mehrere Produktabhängigkeiten definieren. Wollen Sie keine Produktabhängigkeit definieren so geben Sie No ein.

Screenshot: Eine (weitere) Produktabhängigkeit definieren: Ja / Nein
Abbildung 31. Eine (weitere) Produktabhängigkeit definieren: Ja / Nein

Zur Erstellung einer Produktabhängigkeit geben Sie die folgenden Daten an. Beachten Sie auch die Hilfe im oberen Teil des Fensters:

Screenshot: Eingabe der Daten zur Erstellung einer Produktabhängigkeit
Abbildung 32. Eingabe der Daten zur Erstellung einer Produktabhängigkeit
Dependency for Action

Für welche Aktion des Produktes, welches Sie gerade erstellen, soll die Abhängigkeit gelten (nur setup implementiert).

Required product id

Productid (Bezeichner) des Produkts zu dem eine Abhängigkeit besteht.

Required action

Sie können entweder die Aktion setup anfordern oder (siehe unten) den Status (installed).

Required installation status

Status den das Produkt, zu dem eine Abhängigkeit besteht, haben soll (installed). Liegt ein anderer Status vor, so wird das Produkt auf setup gestellt.

Requirement type

Installationsreihenfolge. Wenn das Produkt, zu dem eine Abhängigkeit besteht, installiert sein muss bevor mit der Installation des aktuellen Produkts begonnen werden kann, dann ist dies before. Muss es nach dem aktuellen Produkt installiert werden so ist dies after. Ist die Reihenfolge egal so muss hier nichts eingetragen werden.

Hinweis:

Leider gibt es derzeit keinen generischen Mechanismus für Deinstallations-Produktabhängigkeiten. Zuverlässig ist der ProductDependency-Mechanismus nur für action: setup und die hierbei zu triggernden (before- oder after-) setup Aktionen und installed Status. Ein requiredAction: uninstall führt leider definitiv zu Fehlern.

Nachdem eine Produktabhängigkeit definiert ist, werden Sie wieder gefragt, ob Sie eine (weitere) Produktabhängigkeit definieren wollen. Wenn ja, wiederholt sich der Vorgang; wenn nein, so werden Sie gefragt, ob Sie eine Produkteigenschaft (Zusatzschalter) definieren wollen mit dem Sie die Installation des Produktes modifizieren können.

Noch ein Hinweis:

Die tatsächliche Installationsreihenfolge ermittelt sich aus einer Kombination von Produktabhängigkeiten und Produktpriorisierung. Details hierzu finden Sie im opsi-Handbuch im Kapitel 'Beeinflussung der Installationsreihenfolge durch Prioritäten und Produktabhängigkeiten'

Screenshot: Eine (weitere) Produkteigenschaft definieren
Abbildung 33. Eine (weitere) Produkteigenschaft definieren

Antworten Sie ja, so müssen Sie die Produkteigenschaft beschreiben:

Die Produkteigenschaft wird clientspezifisch gespeichert und besteht aus einem Namen (key) der verschiedene Werte (Values) zugeordnet bekommen kann und die dann vom opsi-winst-Skript abgefragt werden können.

Zunächst müssen Sie angeben, ob es sich um ein Textwert (unicode) oder um einen logische Wert also wahr/falsch (boolean) handelt. Wenn Sie unsicher sind, wählen Sie unicode.

Screenshot: Datentyp der Produkteigenschaft wählen
Abbildung 34. Datentyp der Produkteigenschaft wählen

Weiterhin wird eine Beschreibung benötigt, die im opsi-configed als Hilfe angezeigt wird. Weiterhin müssen Sie, durch Kommas getrennt, alle Werte angeben, die der Key annehmen darf. Wird hier nichts angegeben, so kann später im opsi-Configeditor ein beliebiger Wert eingegeben werden. Über Editable (true/false) können Sie entscheiden, ob neben der vorgegebenen Liste auch andere Werte eingegeben werden dürfen.

Enthält ein Wert einen Backslash \, so muss dieser doppelt angegeben werden.
Eine Pfadangabe kann beispielsweise wie folgt aussehen: C:\\temp
Screenshot: Beschreibung der Produkteigenschaft
Abbildung 35. Beschreibung der Produkteigenschaft

Im Folgefenster müssen Sie festlegen, was der Defaultwert dieser Produkteigenschaft ist.

Screenshot: Festlegung des Defaultwerts der Produkteigenschaft
Abbildung 36. Festlegung des Defaultwerts der Produkteigenschaft

Wenn Sie als Typ 'boolean' wählen, so reduziert sich die Beschreibung auf 'Property name' und 'Property description'.

Screenshot: Beschreibung eines boolschen Properties
Abbildung 37. Beschreibung eines boolschen Properties

Nachdem eine Produkteigenschaft definiert ist, werden Sie wieder gefragt, ob Sie eine (weitere) Produkteigenschaft definieren wollen. Wenn ja, wiederholt sich der Vorgang; wenn nein, so werden Sie als nächstes nach Name und Mail-Adresse gefragt. Diese werden im Changelog des Paketes verwendet und müssen angegeben werden.

Screenshot: Eingabe der Maintainer Daten
Abbildung 38. Eingabe der Maintainer Daten

Danach ist das Grundgerüst des Produktes fertig gestellt.

Mit Hilfe des ls Befehls finden Sie die oben beschriebene Verzeichnis Struktur. Wechseln Sie in den OPSI-Ordner und setzen Sie erneut den ls Befehl ab. Hier befindet sich unter anderem die 'control'-Datei, welche die eben eingegebenen Daten enthält und Ihnen auch die Möglichkeit bietet, diese im Editor zu kontrollieren oder zu modifizieren.

9. Allgemeine Hinweise zu MacOS

9.1. Das Keyboard unter MacOS

Tabelle 1. Apple Tasten

Befehlstaste

Wahltaste

Umschalttaste

"command"

"option"

"shift"

CMD

CTRL

Tabelle 2. Sonderzeichen

Sonderzeichen

Bezeichnung

Tastenkombination

@

At

cmd + L

Euro

alt + E

$

Dollar

shift + 4

£

Britisches Pfund

alt + shift + 4

©

Copyright

alt + G

®

Registered

alt + R

Trademark

alt + shift + D

?

Apple

alt + shift + +

§

Paragraph

shift + 3

~

Tilde

alt + N (dann Leertaste)

(

Klammer auf

shift + 8

)

Klammer zu

shift + 9

[

eckige Klammer auf

alt + 5

]

eckige Klammer zu

alt + 6

{

geschwungene Klammer auf

alt + 8

}

geschwungene Klammer zu

alt + 9

/

Slash

shift + 7

\

Backslash

alt + shift + 7

|

Pipe (senkrechter Strich)

alt + 7

dt. Anführungszeichen unten

alt + ^

dt. Anführungszeichen oben

alt + shift + ^

einfaches dt. Anführungszeichen unten

alt + S

einfaches dt. Anführungszeichen oben

alt + #

»

frz. Anführungszeichen auf

alt + shift + Q

«

frz. Anführungszeichen zu

alt + Q

einfaches frz. Anführungszeichen auf

alt + shift + N

einfaches frz. Anführungszeichen zu

alt + shift + B

=

Gleich

shift + 0

Ungleich

alt + 0

Kleiner gleich

alt + >

Größer gleich

alt + shift + >

>

Größer

shift + >

<

Kleiner

fn + >

±

Plusminus

alt + +

Ungefähr

alt + X

ø

Durchschnitt

alt + O

Unendlich

alt + ,

%

Prozent

shift + 5

π

Pi

alt + P

Haken

alt + V

9.2. Das opsi Produkt m-homebrew

Es gibt für MacOS eine Reihe von Paketverwaltungsprogrammen, welche es erlauben gängige Unix Programme unter MacOS bereitzustellen. Typische Vertreter dieser Paketverwaltungsprogramme sind:

Das opsi Produkt m-homebrew installiert das homebrew System auf einem MacOS System.

homebrew installiert den Befehl brew auf dem System mit dem sich dann aus dem Internet Programme herunterladen lassen. Dabei wird entweder direkt ein Binary installiert oder die Sourcen heruntergeladen und das Programm auf der Maschine kompiliert. Daher braucht homebrew auch die Entwicklungs Kommandozeilen Tools um Programme zu kompilieren (xcode-select --install)

homebrew ist aus Sicherheitsgründen so konzipiert, das es nicht als root aufgerufen werden darf, sondern nur mit usaer Rechten. Um dies im opsi Kontext zu gewähreisten wird bei der Installation des opsi-client-agent ein 'hidden user' Namens opsisetupadmin erzeugt (siehe auch Der MacOS pseudo user opsisetupadmin).
Diesem user gehört das ganze homebrew System auf der Maschine und daher sollte auch nur dieser user verwendet werden um über den Befehl brew Software auf der Maschine zu installieren.
D.h. Der Befehl brew sollte wie folgt als root aufgerufen werden:

sudo -H -u opsisetupadmin /usr/local/bin/brew

Die Installation von Java im Produkt m-javavm ist z.B. wie folgt implementiert:

[ShellInAnIcon_brew_install_java]
; https://github.com/SAP/SapMachine/wiki/Installation
EXITCODE=0
sudo -H -u opsisetupadmin /usr/local/bin/brew tap sap/sapmachine
EC=$?; if [ $EC -ne 0 ]; then EXITCODE=$EC; fi
sudo -H -u opsisetupadmin /usr/local/bin/brew install --cask sapmachine-jdk
EC=$?; if [ $EC -ne 0 ]; then EXITCODE=$EC; fi
exit $EXITCODE

Um herauszufinden ob die Installation eines gewünschten Produktes per homebrew unterstützt wird, verwenden Sie am besten die folgende Webseite:
https://formulae.brew.sh/

Hilfreiche Links zu homebrew:
https://docs.brew.sh/
https://devhints.io/homebrew

9.3. Der MacOS pseudo user opsisetupadmin

Bei der Installation des opsi-client-agent ein 'hidden user' Namens opsisetupadmin erzeugt. Dieser user hat kein Passwort und kann nicht für ein Login verwendet werden.

Das Heimatverzeichnis dieses Users ist /var/opsisetupadmin

Dieser User dient zu folgenden Zwecken:

  • Bedienung des homebrew Systems (siehe Das opsi Produkt m-homebrew

  • Das Verzeichnis /var/lib/opsisetupadmin/opsi_depot ist der mountpoint auf dem der opsiclientd den Depotshare mounted.
    Dies wir so gemacht weil ein Zugriff auf Networkshares welche nicht in einem Userverzeichnis gemountet werden stark eingeschränkt ist.

9.4. Die opsi Verzeichnisse auf MacOS

Wesentliche opsi Verzeichnisse und Dateien auf dem MacOS-Client

  • /var/log/opsi-script (Log files opsi-script)

  • /var/log/opsi-client-agent (sonstige opsi Log files)

  • /usr/local/bin/opsi* (Kommandozeilen Programme)

  • /Applications/opsi-script-gui.app

  • /Applications/opsi-notifier.app

  • /etc/opsi-client-agent (Konfiguration opsi-client-agent)

  • /etc/opsi-script (Konfiguration opsi-script)

  • /usr/local/lib (Hilfslibraries z.B. ssl)

  • /usr/local/lib/opsiclientd

  • /usr/local/bin/locale (locale opsi-script)

  • /usr/local/share/opsi-client-agent

  • /usr/local/share/opsi-script

  • /usr/local/share/notifier.d

  • /var/opsisetupadmin (Heimatverzeichnis opsisetupadmin)

  • /var/lib/opsi-client-agent

  • /Library/LaunchDaemons/ (Start Konfiguration für opsi deamons)

  • /Library/LaunchAgents/ (Start Konfiguration für opsi-systray)

9.5. MacOS Directory Struktur mit 'go' und 'nogo'

MacOS basiert auf BSD-Unix und hat damit eine typische Unix Filesystemstruktur. Es gibt aber aus Sicherheitsgründen etliche Bereich die ausschließlich Apple vorbehalten sind und noch ein paar weiter Spezifika welche für den Paketierer wichtig sind:

  • /Applications
    Das ist das Verzeichnis in dem die grafischen Anwendungen liegen. Eine Anwendung besteht dabei aus eine Verzeichnis <Application name>.app. Ein solches Verzeichnis wird aber im Finder nicht als Verzeichnis angezeigt, sondern als 'Anwendung'. Innerhalb dieses Verzeichnisses müssen sich nach einem bestimmten Muster die Dateien der Anwendung befinden.

  • /sbin, /bin, /usr/bin, /usr/share, /usr/lib
    Dies sind 'apple only' Verzeichnisse in die sonst niemand etwas reinkopieren darf. Verwenden Sie stattdessen die local Varianten:
    /usr/local/bin, /usr/local/share, /usr/local/lib

10. Weitere Informationen

Das opsi-Handbuch enthält eine Fülle von weiteren Informationen, die für den produktiven Betrieb wichtig sind. Wenn Sie ihren opsi-Server produktiv einsetzen empfehlen wir Ihnen besonders sich mit dem Werkzeug 'opsi-backup' vertraut zu machen, um eine Sicherung Ihrer Daten erstellen zu können.

Wenn Sie dort nicht fündig werden oder Hilfe benötigen, wenden Sie sich an die opsi Community.

Für produktive Installationen empfehlen wir professionelle Unterstützung durch uib im Rahmen eines Pflege- und Supportvertrages.