opsi Getting Started opsi-Version 4.1

Jede aktive Samba Connection macht einen eigenen Samba Prozess auf. Für diesen sind je nach Quelle zwischen 800 kB und 4 MB zu kalkulieren. Wieviele opsi-clients gleichzeitig auf einen opsi Server zugreifen, hängt stark von den Tagesabläufen in Ihrer Umgebung ab.

Für Samba 3 wurden folgende Werte empfohlen:

Da uns keine Werte für aktuelle Samba-Versionen vorliegen, können die vorgenannten Zahlen lediglich als grobe Schätzung angesehen werden und sollten mit einem Sicherheitszuschlag von 50% versehen werden.

Der Speicherverbrauch des opsiconfd hängt stark (aber nicht nur) von der Anzahl der Clients ab. Aus bestehenden Installationen kann der folgende Minimalverbrauch abgeleitet werden. Bei den angegebenen Userzahlen handelt es sich hierbei nicht um gleichzeitig aktive User, sondern um die Gesamtzahl.

Auch hier sollten Sie einen Sicherheitszuschlag haben.

Der opsiconfd nutzt derzeit nur einen Kern. Dieser eine Kern wird auch nur dann ausgelastet, wenn viele opsi-clients (>100) exakt gleichzeitig auf den Server zugreifen. Aber das Betriebsystem, Samba, die Datenbank usw. benötigen ebenfalls Rechenzeit.

D.h. bei 500 Clients sollten zwei CPU-Kerne hinreichend sein, bei 1000 Clients sollten sie vier CPU-Kerne zur Verfügung stellen.

Beachten Sie auch, dass opsi-Depots Last auf den opsi-Configserver bringen, die zudem deutlich größer ist, als die eines einzelnen Clients.

VMware

Sofern Sie bereits über einen Gastrechner verfügen, auf dem die VMware-Vollversion oder ein VMware-Player installiert ist, erledigen Sie die Grundinstallation des 'opsi-servers' mit wenigen Mausklicks:

ESXi-Server

Virtualbox

Allgemein

Den VMware-Player können Sie für alle gängigen Betriebssysteme kostenfrei bei vmware.com beziehen. Er lässt sich in der Regel problemlos installieren, sofern die Ausstattung des Wirtsrechners, insbesondere mit Speicher, den Bedarf mehrerer parallel laufender Betriebssysteme abdeckt.

Nach dem Start des Systems müssen Sie die gewünschte Sprache auswählen:

Zur Arbeit mit dem opsi-server ist es von sehr großem Vorteil, wenn dieser direkt mit dem Internet verbunden ist. Zur Netzwerkkonfiguration wird beim ersten Start der Appliance automatisch das Skript 1stboot.py aufgerufen.
Wenn Sie das System anders aufgesetzt haben oder einen neuen Anlauf nehmen wollen, können sie 1stboot.py bzw. /usr/local/bin/1stboot.py auch auf der Kommandozeile aufrufen.

Die Logdatei von 1stboot.py ist /var/lib/1stboot/1stboot.log.

Sie werden dann zur Eingabe von Informationen zur Konfiguration des Netzwerkes aufgefordert. Beantworten Sie die Fragen.

Im Folgenden werden Sie gefragt nach:

Nach Abschluss des Programms 1stboot.py wird die virtuelle Maschine, sofern Sie automatisch gestartet war, auch automatisch neu gebootet.

Nach dem Neustart bzw. nach Fertigstellen der Netzwerkkonfiguration loggen Sie sich als adminuser mit dem von Ihnen vergebenen Passwort ein.

Sie befinden sich direkt auf der graphischen Oberfläche des 'opsi-servers' (für diese wird ein Ressourcen schonender Windowsmanager verwendet). Zur Begrüßung erscheint ein „Firefox“-Browser-Fenster mit dem Verweis auf das vorliegende Handbuch und weiteren Hinweisen.

Wenn die Meldung erscheint, dass keine Netzwerkverbindung verfügbar ist, kann dies mit der speziellen Start-Konfiguration der virtuellen Appliance zusammenhängen. Vor einer weiteren Fehlersuche sollten Sie zunächst probieren, den Server nochmals zu rebooten (z.B. mit dem Ausschaltknopf in der Bedienleiste unten auf der graphischen Oberfläche).

Sobald die Netzwerkkonfiguration funktioniert, können Sie auch remote auf den opsi-server zugreifen:

Im Folgenden müssen einige Befehle auf der Kommandozeile eingegeben werden. Bei anderen ist die Eingabe der Befehle auf der Kommandozeile der schnellere Weg zum gewünschten Ergebnis.

Ein Fenster zur Text-Eingabe von Befehlen, d.h. ein Terminalfenster, erhält man auf verschiedenen Wegen:

Besonders vorteilhaft ist es, Befehle aus den Anleitungen, z.B. diesem Handbuch, direkt per Kopieren & Einfügen in ein Terminalfenster zu übertragen, soweit die entsprechende Anwendungsumgebung dies unterstützt.

Beispiele aus Konfigurationsdateien sind in den Dokumentationen wie folgt formatiert:

Befehle sind folgendermaßen hervorgehoben:

In '<spitzen Klammern>' werden Namen dargestellt, die durch ihre Bedeutung ersetzt werden müssen.
Beispiel: Der Fileshare, auf dem die opsi Softwarepakete liegen, wird '<opsi-depot-share>' genannt und liegt auf einem realen Server in der Regel in '/var/lib/opsi/depot'.
Das Softwarepaket: <opsi-depot-share>/ooffice liegt dann tatsächlich unter /var/lib/opsi/depot/ooffice.

Wenn die Netzwerkkonfiguration korrekt ist und der Rechner Anbindung an das Internet hat, können Sie mit dem Browser im Startfenster bereits auf eine beliebige Adresse im Internet zugreifen.

Sofern nicht alles funktioniert, öffnen Sie am besten ein Terminalfenster (möglicherweise geht es dann noch nicht remote, sondern nur auf der Server-Oberfläche), und prüfen die Netzwerkanbindung mit den üblichen, hier nicht zu erklärenden Checks.

Sie können im Terminalfenster auch das Kommando

aufrufen und die Netzwerkkonfiguration neu eingeben.

Ein Systemneustart wird dann durch den Befehl

erzwungen.

Wenn die Netzwerkanbindung funktioniert, setzen Sie die Konfiguration des opsi-servers fort, um dann mit ersten Installationstest beginnen zu können.

Bringen Sie den opsi-Server auf den aktuellen Stand, indem Sie das Icon 'Update OS' auf dem Desktop doppelt klicken. Geben Sie das Passwort für den adminuser ein und bestätigen gegebenfalls mit 'Y' falls erforderlich.

Sofern für Ihren Internet-Zugang erforderlich, passen Sie die Datei /etc/apt/apt.conf an Ihre Netzwerkgegebenheiten an (richtigen Proxy eintragen oder Zeile auskommentieren / löschen). Diese Datei können Sie mit einem beliebigen Texteditor editieren, bspw. mit 'midnight commander':

Installieren Sie die Standard opsi-Produkte durch Doppelklick auf das Icon 'First package installation'. Bitte geben Sie das Passwort für den adminuser ein. Hierdurch werden automatisiert die aktuellen opsi-Pakete, incl. Templates für Betriebssysteminstallationen, aus den opsi-Repositories geholt und auf dem Server installiert.

Für weitere Informationen siehe auch Abschnitt 5.3, “Einspielen der minimalen opsi-Produkte”.

Die Management-Oberfläche können Sie durch einen Doppelklick auf das Icon 'opsi Management GUI' aufrufen. Zur Beschreibung der Management-Oberfläche gehen Sie zu Abschnitt 6.2, “Start der Management-Oberfläche opsi-configed”.

Damit ist die grundlegende Server-Konfiguration beendet.

Sie können nun fortfahren mit

Über das Univention App-Center steht eine automatisierte Installation des opsi-servers zur Verfügung. Die Installations-App für opsi befindet sich in der UCS-Management-Oberfläche in der Kategorie 'System'. Über das App-Center kann opsi nur auf den Rollen 'Master', 'Backup' und 'Slave' installiert werden.

Falls Sie ein Update einer vorhandenen opsi-Umgebung durchführen möchten, lesen Sie bitte auch das darauf folgende Kapitel.

Zur Installation des opsi-servers werden automatisch weitere Pakete installiert: 'opsi-tftpd-hpa', 'opsi-windows-support', 'univention-mariadb' bzw. 'univention-mysql'.

Falls ein existierender opsi-server entdeckt wird, so wird 'opsi-package-updater' so konfiguriert, dass er die Pakete von diesem Server bezieht. Der 'opsi-package-updater' wird bei der Installation - nicht bei einer Aktualisierung - zum Einspielen der minimalen opsi-Produkte aufgerufen. Im Rahmen eines Major- oder Minor-Update werden Paketaktualisierungen eingespielt.

Bitte beachten Sie, dass anschließend kein automatischer Transfer von Clients nach opsi stattfindet. Mehr Informationen unter Abschnitt 5.1.3.6, “LDAP-Daten nach opsi überführen”.

Die opsi-Installation auf einem UCS-Server über das Univention App-Center ist damit abgeschlossen. Weiter geht es mit Abschnitt 7.2, “Integration vorhandener Windows-Clients in opsi”

Eine der wichtigsten Änderungen, die mit dem Update für opsi 4.0.5 gekommen ist, ist die Unterstützung der Gruppe 'opsifileadmins'. Diese Gruppe ersetzt in UCS zukünftig die Gruppe 'pcpatch'. 'Opsifileadmins' wurde zwar schon mit der Unterstützung von UCS 3.0 eingeführt, es wurde allerdings nur auf Installationen eingerichtet, die mit Samba 4 und den Univention Directory Services (Samba4-AD) installiert wurden. Auf allen anderen Varianten und Rollen, wurde bisher die Gruppe als 'pcpatch' angelegt.
Da dieser Umstand nicht nur im Installationshandling ein Problem darstellt, sondern auch Probleme bei möglichen Migrationen (besonders von Samba3 auf Samba4) verursachen kann, wird seit opsi 4.0.5 die Gruppe 'pcpatch' als 'opsifileadmins' angelegt.

Notwendige Vorbereitungen:

Die Installation von opsi ist möglich auf den Rollen 'Master', 'Backup', 'Slave' und 'Member'. Für die Installation auf einem 'Member' beachten Sie unbedingt Abschnitt 5.1.3.4, “Hinweise zur opsi-Installation auf einem UCS-Server in der Rolle 'Member'”!

Die folgende Dokumentation geht von einer Installation auf der Rolle 'Master' mit Samba 4 aus.

Die klassischen Installationsvariante mit dem Benutzer: 'pcpatch' mit der primären Gruppe 'pcpatch' kann unter UCS nicht eingehalten werden. Da Samba4 den grundlegenden Restriktionen von Active-Directory unterliegt, sind Gruppen mit der gleichen Bezeichnung wie User (wie in Unix/Linux üblich) nicht mehr erlaubt. Aus diesem Grund wurde für UCS 3 die neue Konfigurationsdatei /etc/opsi/opsi.conf eingeführt, über welche gesteuert wird, wie die Gruppe für den Samba-Zugriff auf die Freigaben bestimmt wird. Seit UCS 3 wird über diese Datei der Gruppenname 'pcpatch' umbenannt und heißt von nun an: 'opsifileadmins'. Das bedeutet, dass die User, die Zugriffsrechte für die Freigaben von opsi erhalten müssen (opsi-Paketierer) nicht Mitglied der Gruppe 'pcpatch', sondern Mitglied der Gruppe 'opsifileadmins' sein müssen. Diese Besonderheit gilt nur für UCS und unterscheidet sich von den anderen Distributionen und in weiterführenden Kapiteln der opsi-Dokumentationen. Unter UCS wird der User 'pcpatch' als vollwertiger Domänenbenutzer angelegt. Nähere Informationen über diese neue Konfigurationsdatei können Sie dem Handbuch entnehmen.

UCS 4.4:

UCS 4.3:

Nun muss noch der Schlüssel des Repositories ins System importiert werden:

UCS 4.4:

UCS 4.3:

Für die Installation führen Sie nun folgende Befehle aus:

UCS 4.4:

UCS 4.3:

Ist die Rolle des Zielsystems eine andere als 'Master' oder 'Backup', muss nun noch das opsi4ucs Join-Skript ausgeführt werden:

Unter der URL https://<servername>:4447 finden Sie nun einen Link zur opsi Management Oberfläche.

Um den opsi-Konfigurations-Editor verwenden zu können, muss ein Benutzer Mitglied der Gruppe opsiadmin sein. Die Gruppenzugehörigkeit eines Users kann über Univention-Admin bearbeitet werden. Der Benutzer Administrator wird während der Installation automatisch in diese Gruppe aufgenommen.

Abschliessend muss noch im UDM unter dem Punkt Freigaben für die 'opsi_depot' -Freigabe unter Erweiterte Einstellungen → Erweiterte Samba-Einstellungen: Die Option: 'follow symlinks' auf 'yes' gesetzt werden. Das gleiche sollte man am besten auch für die 'opsi_depot_rw' -Freigabe erledigen, damit später die Treiberintegration keine Probleme verursacht. Sollte sich das /var/lib/opsi/depot -Verzeichnis auf einer extra Partition oder Festplatte befinden, muss man noch zusätzlich für diese Freigaben die Option wide links auf 'yes' setzen.

Um sicher zu stellen, dass alle Einstellungen von opsi nun korrekt übernommen wurden, sollte man noch folgende Befehle ausführen:

Bei samba4 handelt es sich um einen zentralen Dienst, daher wird dieser nicht automatisch vom Paket neugestartet, sondern muss nachträglich manuell durchgeführt werden. Nach dem Neustart von samba kann es zu einer kleinen Verzögerung beim Zugriff auf die neuen Freigaben kommen, wir bitten dies zu berücksichtigen.

Da es keinen direkten Kontakt zwischen Univention-LDAP und dem opsi-Backend gibt, müssen alle Clients erst im LDAP über udm angelegt werden und danach nochmal mit opsi im opsi-System mit allen Informationen (insbesondere der MAC-Addresse) angelegt werden. Das Löschen des Clients im Univention-LDAP sorgt nicht dafür, dass der Client unter opsi auch gelöscht wird. Dieses Problem wird in Abschnitt 5.1.3.6, “LDAP-Daten nach opsi überführen” genauer beleuchtet.

Da Sie opsi auf einer existierenden Maschine eingespielt haben, gehen wir davon aus, dass Ihre Netzwerkkonfiguration korrekt ist.
Machen Sie daher mit dem Punkt Abschnitt 5.2, “Konfigurieren des opsi-servers” weiter.

Die Installation von opsi auf einem Server in der Rolle 'Member' ist möglich. Eine automatisierte Installation über das Univention App Center kann jedoch aktuell nicht vorgenommen werden.

Nach einer Installation muss sicher gestellt werden, dass der für den Depotzugriff verwendete Benutzer mitsamt Domäne aufgeführt ist. Dazu muss der Hostparameter clientconfig.depot.user kontrolliert werden. Ist die Domäne backstage, so muss der Wert backstage\pcpatch lauten. Lautet er memberserver\pcpatch, so muss der Wert korrigiert werden.

Das Setzen des Kennworts für den Benutzer pcpatch über opsi-admin scheitert auf Grund der fehlenden AD-Schreibberechtigungen eines 'Member'-Servers. Daher muss die Änderung des Kennworts des technischen Benutzers pcpatch zusätzlich auf einem Server mit Schreibrechten im AD vorgenommen werden - ein 'Master', 'Backup' oder 'Slave'.

Wenn der PXE-Boot für die Betriebssysteminstallation eingesetzt werden soll, muss der DHCP-Dienst auf dem entsprechenden UCS-System umkonfiguriert werden. Hier gibt es zwei Besonderheiten, die UCS von den anderen unterstützten Distributionen unterscheidet.

Um die oben genannte Konfigurationen um zu setzen, muss im UCS-System eine Richtlinie erstellt werden. Diese Einstellung ist abhängig von den schon vorhandenen Richtlinien und müssen entsprechend umgesetzt werden. Wenn opsi auf einem UCS-Testsystem installiert wurde und keine Richtlinien entsprechend existieren, sollte erst geprüft werden ob der DHCP-Dienst installiert ist, wenn nicht muss das noch nachgeholt werden. Wenn der DHCP-Dienst schon installiert wurde, ist der einfachste Weg die Richtlinie in der UMC-Webschnittstelle (Univention Management Console) vom UCS-Server zu erstellen. Dazu wählt man den die Kategorie "Domäne" und darunter das Modul DHCP-Server. Als nächstes muss man den Service wählen (Bei einem Testsystem gibt es in der Regel nur einen Eintrag). In der folgenden Detailansicht wählt man den Menüpunkt Richtlinien. Die Richtlinie, die hier benötigt wird ist eine DHCP-Boot Richtlinie. Bei der Richtlinienkonfiguration wählt man nun den Defaulteintrag cn=default-settings (sollte der einzige Eintrag sein) und wählt bearbeiten. Unter Grundeinstellungen - DHCP Boot für die Option Bootserver die IP vom opsi-server ein und bei Boot-Dateiname muss pxelinux.0 eingetragen werden.

Optional lassen sich diese Einstellungen auch auf der Konsole mit dem udm-Kommando erledigen. Nähere Informationen dazu entnehmen Sie bitte der entsprechenden UCS-Dokumentation.

In einer opsi4ucs-Installation müssen die Windows-Clients erst im UDM angelegt werden und können erst im folgenden Schritt im opsi-configed erstellt werden. Änderungen von Clients im UDM werden nicht an opsi weitergegeben. Wenn ein Client zum Beispiel im LDAP eine neue Mac-Addresse bekommt, wird dies im opsi-System nicht bemerkt. Wenn man nun versucht ein Netboot-Produkt für diesen Client auf setup zu setzen, würde opsi die Bootkonfiguration mit der falschen Mac-Addresse im Bootsystem hinterlegen.

Die Lösung hierzu ist die Erweiterung 'opsi-directory-connector'. Weitere Informationen hierzu enthält das Handbuch.

In der vorkonfigurieren opsi VM ist bereits ein DHCP-Server installiert.
Der DHCP-Server auf der opsi-server VM ist so konfiguriert, das er keine freien leases hat, also keine IP-Nummern an unbekannte Rechner vergibt. Wenn Sie im opsi-configed einen Client erzeugen, müssen Sie daher IP-Nummer und MAC-Adresse angeben, da diese in die /etc/dhcp/dhcpd.conf eingetragen und danach der DHCP Dienst neu gestartet wird.

Wenn Sie den opsi-Server als DHCP-Server verwenden möchten, müssen Sie daher das entsprechende Paket manuell nachinstallieren

z.B. mit

Nach der Installation muss die Konfigurationsdatei noch angepasst werden mit dem Befehl:

Um den DHCP Server neu zu starten, so wie in /etc/opsi/backends/dhcpd.conf beschrieben, ist ein entsprechender Eintrag in der /etc/sudoers notwendig. Dieser wird mit folgendem Befehl erstellt.

Die Rechte der /etc/dhcp/dhcpd.conf sollten wie folgt aussehen.

Wenn Sie die opsi-VM verwenden dann können Sie den DHCP-Server deinstallieren.

Dazu führen Sie den folgenden Befehl aus:

Bei einer eigenen Installation wird seit opsi 4.0.3 nicht mehr automatisch ein DHCP-Server installiert.

Nun müssen Sie den externen DHCP-Server so konfigurieren, dass er ein PXE-Boot über den opsi-server ermöglicht. Wenn Ihr DHCP-Server auf einem Linux läuft, sind folgende Einträge in der Konfigurationsdatei des dhcpd (z.B. /etc/dhcp/dhcpd.conf) für die Clients notwendig:

Wobei '<ip of opsi-server>' durch die IP-Adresse des opsi-servers zu ersetzen ist.

Läuft der opsi-Server auf openSUSE oder SLES, so ist filename=opsi/pxelinux.0.
Läuft der opsi-Server auf UCS, so ist filename=pxelinux.0.

Bei einem Windows-Server sind die entsprechenden Einträge 'Startserver (Option 66)' und 'Startfile (Option 67)'.

Wenn Sie im opsi-configed einen Client erzeugen, müssen Sie die MAC-Adresse angeben, aber keine IP-Nummer.

Je nachdem ob der interne oder ein externer DHCP-Server verwendet wird, muss die Konfiguration von opsi angepasst werden.

In der Datei /etc/opsi/backendManager/dispatch.conf ist festgelegt, welche Backends von opsi zum Einsatz kommen (bspw. 'file', 'mysql').

In den Zeilen backend_. und host_. wird u.a. gesteuert, ob der opsi-server auch die lokale DHCP-Konfiguration – also die Zuweisung von Internet-Adressen zu den Hardware-Adressen der Netzwerkkarten – mit übernimmt. Dies muss so eingerichtet sein, wenn für die opsi-clients die DHCP-Einträge durch die opsi-Konfigurationsaufrufe erzeugt werden sollen. Der entsprechende Eintrag mit file Backend muss dann z.B. lauten:

Wenn der opsi-server den DHCP-Dienst nicht bereitstellen soll (weil ein anderer Server im lokalen Netz diese Aufgabe übernimmt und auch für die opsi-clients gepflegt wird), so wird das Backend dhcpd nicht benötigt:

Nach Anpassung der Backendkonfiguration muss die Konfiguration initialisiert und der opsiconfd neu gestartet werden:

Die Befehle für 32- und 64-Bit sind nahezu identisch, nur müssen die Einträge <ARCH> mit entweder x86 , amd64 oder ia64 ersetzt werden.

Führen Sie Start ⇒ Programme ⇒ Windows Kits ⇒ Windows ADK ⇒ "Umgebung für Bereitstellungs- und Imageerstellungstools" aus; eine Eingabe-Aufforderung erscheint (in dieser sind in der Folge benötigte Umgebungsvariablen gesetzt)

(Hinweis: c:\opsi\startnet.cmd wird vom opsi-linuxbootimage in der setup.py erstellt nebst dem oben entfernten wpeinit-Aufruf).

Die Befehle für 32- und 64-Bit sind nahezu identisch, nur müssen die Einträge <ARCH> mit entweder x86 , amd64 oder ia64 ersetzt werden.

Alles als Administrator aus der Eingabeaufforderung mit erweiterten Rechten ausführen (Start ⇒ Programme ⇒ Zubehör ⇒mit rechter Maustaste auf "Eingabeaufforderung" ⇒ Ausführen als …​ ⇒ Administrator)

(Hinweis: c:\opsi\startnet.cmd wird vom opsi-linuxbootimage in der setup.py erstellt nebst dem oben entfernten wpeinit-Aufruf).

Beispiel:

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

Beispiel:

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

Beispiel:

Syntax:

Beim „unattended“ oder „silent setup“ wird das Original-Setup-Programm über Kommandozeilen-Argumente in einen nicht interaktiven Modus gestellt.

Das Problem dieser Installationsmethode ist es die geeigneten Kommandozeilenargumente zu finden.

Bevor man sich in Forschungen stürzt, ist dringend zu empfehlen bei opsi.org zu schauen, ob jemand das Problem bereits gelöst hat:

Fertige opsi-winst-Skripte aus der Community gibt es im opsi community Wiki.

Eine Sammlung von Weblinks zu Schaltersammlungen im Internet findet sich im opsi Wiki: Software integration web-links.

Die meisten Setupprogramme sind auf Basis von Frameworks wie 'Inno', 'NSIS', 'Installshield' oder 'Wise' gebaut. Jedes dieser Frameworks hat eigene typische Setupschalter. Um das Framework zu ermitteln kann unter anderem folgende Methode verwendet werden: Mit dem Kommandozeilen Programm strings werden die Strings aus der setup.exe extrahiert und danach mit grep bzw. findstr nach den Namen der Frameworks gesucht.

Unter Linux sieht der dazu nötige Befehl wie folgt aus (setzen Sie für <mysetup.exe> den Namen Ihrer setup.exe ein):

Unter Windows muss der Befehl strings.exe erst installiert werden. Einen entsprechenden Download findet man hier: http://technet.microsoft.com/en-us/sysinternals/bb897439

Unter Verwendung dieses Programms, sieht der Befehl unter Windows dann wie folgt aus (setzen Sie für <mysetup.exe> den Namen Ihrer setup.exe ein):

Die selbe Methode verwendet der opsi-setup-detector.

Dieses grafisch-interaktive Programm lässt sich zudem in das Kontextmenü des Explorers Einbinden.

Der 'opsi setup detector' ist Bestandteil der opsi-Repositories für Windows und kann über diese bezogen werden.

Setup-Programme werden in der Regel von den Herstellern der diversen Softwareprodukte nicht selbst geschrieben. In den meisten Fällen bedienen sich vielmehr die Produkthersteller selbst spezieller Softwareprodukte, mit denen Setup-Programme relativ einfach erstellt werden können. Die verwendbaren Kommandozeilenargumente sind daher zumeist typisch für das verwendete Produkt zur Erstellung von Setup-Programmen.

Im opsi Wiki: Software integration web-links finden weitere Weblinks zu Seiten, die erläutern, wie man Setupprogramme erkennt und wie Ihre typischen Schalter sind.

Auf der Homepage des Herstellers des Setupprogramms wird man zumeist mit der Suche nach Stichworten wie "silent", "silent Install" oder "unattended" fündig.

Da die Anforderung einer automatischen Installation inzwischen vielen Herstellern bewusst ist, finden sich häufig in der Produkt-Dokumentation oder auf der Homepage des Herstellers Anleitungen oder Hinweise hierzu.

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 sind sehr mächtig, insbesondere zur Auswertung von Ausgaben externer Programme. Lesen Sie dazu die opsi-winst-Dokus.

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

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:

Vereinzelt taucht das Problem auf, dass sich Installationen nur bei angemeldetem Benutzer durchführen lassen. Ein Hinweis auf diese Problematik ist es, wenn ein opsi-winst-Skript das eine unattended Installation enthält, beim manuellen Aufruf durch einen administrativen Benutzer funktioniert, im Rahmen der automatischen Installation über opsi jedoch scheitert.

Eine mögliche Ursache ist dann, dass dieses Setupprogramm einen angemeldetem Benutzer bzw. den Zugriff auf ein Benutzer-Profil benötigt. Handelt es sich um eine MSI-Installation, hilft eventuell die Option ALLUSERS=1.

Eine weitere Möglichkeit ist, dass sich das Installationsprogramm zu früh beendet, z.B. weil ein ein Sub-Prozess gestartet wird. In diesem Fall können die Parameter /WaitSeconds <Anzahl Sekunden> oder /WaitForProcessEnding "program.exe" /TimeOutSeconds "<Anzahl Sekunden>" für den WinBatch-Aufruf helfen.

Eine andere, wenn auch aufwendigere, Möglichkeit dieses Problem zu lösen ist, einen administrativen Benutzer temporär anzulegen und diesen zur Installation der Software zu verwenden. Dies können Sie auf Basis des Templates 'opsi-template-with-admin' durchführen.

Microsoft hat mit Windows 2000 ein eigenes Installationskonzept vorgestellt, das auf dem Microsoft Installer Service, kurz „MSI“ beruht. Inzwischen sind viele Setup-Programme MSI-konform.

MSI-Konformität bedeutet, dass die eigentliche Installation darin besteht, dass an den MSI ein Paket von Installations-Anweisungen übergeben wird (im Prinzip eine Datei mit einen Namen der Form „produkt.msi“) und der MSI dieses Paket dann ausführt.

In der Praxis sieht dies meist so aus, dass die zu einem Produkt gehörige „setup.exe“ eine Datei „produkt.msi“ und ein zusätzliches Steuerprogramm für die Installation enthält. Das Steuerprogramm packt „produkt.msi“ aus und fragt, ob eine Installation starten soll. Wird dies bestätigt, prüft das Steuerprogramm, ob der MSI schon eingerichtet ist und übergibt bei positivem Ergebnis der Prüfung diesem die „produkt.msi“. Ist der MSI nicht eingerichtet und wird insbesondere das Programm „msiexec.exe“ nicht gefunden, so startet das Steuerprogramm zuerst eine Installationsprogramm für den MSI.

Klickt man bei der Frage, ob die Installation starten soll, nicht auf „weiter“, sondern ruft den Explorer auf, so findet sich das ausgepackte MSI-Paket meist in einem temporären Verzeichnis.

Dieses Paket kann nun dazu verwendet werden, eine Installation „unattended“ - also „unbewacht“, d.h. ohne dass ein Benutzereingriff erforderlich ist - auszuführen. Dazu ist bei vorhandener msiexec.exe aufzurufen:

Häufig will man nach einer erfolgreichen Silent-Installation Anpassungen an der Installation vornehmen. Hierzu bietet der opsi-winst ein mächtiges Werkzeug. Doch bevor dies eingesetzt werden kann muss oft ermittelt werden, welche in der graphischen Oberfläche getätigten Änderungen zu welchen Veränderungen in Dateien und der Registry führen.

Hierzu können die unter Abschnitt 10.1.11.7, “Analyse und Neu-Paketieren” vorgestellten Werkzeuge eingesetzt werden. Häufig führen aber auch kleinere Werkzeuge schneller zum Erfolg.

Einige beliebte Werkzeuge sind:

Eine weitere schnelle Möglichkeit zur Einbindung in die automatische Softwareverteilung ist das 'Setup mit automatisierten Antworten'. Hierzu wird eine Steuerungs-Software verwendet, die über ein Skript die Interaktion eines Anwenders mit den erscheinenden Dialog-Fenstern automatisiert.
Wir empfehlen hierfür den Einsatz der Software AutoHotkey oder AutoIt.

'AutoIt' bietet eine ganze Reihe zusätzlicher Möglichkeiten, den Setup-Prozess zu steuern. Auch eventuelle Fehlerzustände können (so vorher bekannt) mit dem Einsatz von [ADLIB]-Sektionen im Skript abgefangen werden.

Ein prinzipielles Problem bleibt bestehen: Nicht vorhergesehene (und im Skript berücksichtigte) Fenster können das Skript zum Stoppen bringen.

Außerdem kann der Anwender mittels Maus und Tastatur (wenn diese nicht gesperrt sind) in den automatisierten Prozess eingreifen und den Ablauf damit verändern. Ein Unattended- oder Silent-Setup ist daher immer die bessere Lösung.

Sehr gut kann auch eine Kombination aus beiden Ansätzen funktionieren: Das Silent-Setup übernimmt die eigentliche Installation und ein AutoIt-Skript fängt bekannte Sonderbedingungen ab.

Wenn das Ausführen von Installationen in der opsi-client-agent Konfiguration auf einen anderen Desktop verlegt wird oder der Desktop gesperrt wird, haben verschiedene autoit Funktionen Probleme.

Daher sollten in 'opsi-winst' Skripten die folgenden Funktionen gemieden werden:

Das sind leider genau die 3 am meisten verwendeten.

winwait()
kann ersetzt werden durch die Funktion
opsiwinwait($title, $text, $maxseconds, $logname)
welche in der folgenden Weise definiert wird:

Dabei ist:

Send()
kann ersetzt werden durch die Funktion
opsiControlClick($title, $text, $id, $maxseconds, $logname)
bzw. durch
opsiControlSetText($title, $text, $id,$sendtext, $maxseconds, $logname)
welche in der folgenden Weise definiert werden:

Dabei ist:

Dabei muss mit der Au3info.exe die 'ControlId' ermittelt werden. Bitte die numerische 'ControlId' verwenden, andere Varianten scheinen Probleme zu machen:

Hier ein Auszug aus einem script.
In diesem wird dann noch eine Logdatei angelegt, die mit folgenden Befehlen in die Logdatei des 'opsi-winst' integriert wird:

Das Beispiel:

siehe auch:
http://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F
http://www.autoitscript.com/autoit3/docs/
http://www.autoitscript.com/autoit3/docs/intro/controls.htm
http://www.autoitscript.com/autoit3/docs/functions.htm

Wenn der Entwickler einer Anwendung ein Paket zur Auslieferung der Anwendung schnürt, kennt er die benötigten Komponenten. Im Nachhinein, wenn schon ein Paket existiert, das mittels eines Setup-Programm zu installieren ist, kann die Kenntnis, welche Komponenten installiert werden müssen, damit eine Anwendung wie gewünscht auf einem Arbeitsplatzrechner lauffähig ist, aus der Studie der Effekte bei der Ausführung des vorhandenen Setup-Programms gewonnen werden.

Eine Reihe von Werkzeuge zum Analysieren von Setup-Programmen kommen hierbei in Frage. So z.B.:

Um eine installierte Software von einem Rechner zu entfernen, kann ein Deinstallations-Skript erstellt werden. Grundsätzlich besteht bei einer Deinstallation die Schwierigkeit, dass nicht immer klar ist, wie das Produkt auf dem Rechner vorliegt und was alles entfernt werden muss. Auch nach der Installation können neue Dateien oder Registry-Einträge, die die Software betreffen, hinzugekommen sein. Weiterhin muss darauf geachtet werden nicht zu viel zu entfernen, um die Systemstabilität nicht zu gefährden. Meist weiß nur der Hersteller genau, wie mit seinem Produkt bei der Deinstallation umzugehen ist. Ähnlich wie bei der Installation, existieren zu diesem Zweck Deinstallations-Routinen, die dem Produkt beiliegen. Wenn es die Möglichkeit gibt, diese ohne Benutzer-Interaktion auszuführen, kann dies schon ein entscheidender Schritt sein. Ist eine solche Routine nicht vorhanden oder muss diese erweitert werden, so existieren viele opsi-winst-Befehle, die zur Deinstallation nützlich sein können. Im Folgenden soll nun ein Überblick über Möglichkeiten zur Deinstallation gegeben werden, die durch Beispiele verdeutlicht werden.

Liefert der Hersteller des Produkts ein Programm (oder ein MSI-Paket) zur Deinstallation, so muss zunächst geprüft werden, ob dies auch ohne Benutzer-Interaktion ausgeführt werden kann (silent-mode). Sollte dies nicht von Hause aus möglich sein, kann der Einsatz eines AutoIt-Skriptes in Verbindung mit der Deinstallations-Routine hilfreich sein. Der Aufruf der ausführbaren Datei kann im opsi-winst-Skript in einer Winbatch-Sektion geschehen, z.B.:

Trotz dieser Unterstützung des Herstellers sollte man sich jedoch nicht auf die korrekte Beseitigung des Produkts verlassen und auf einem Testsystem zusätzlich prüfen, ob das System nach der Deinstallation weiter stabil läuft und ob Dateien oder Registry-Einträge zurückgeblieben sind.

Falls das Produkt als MSI-Paket bereitgestellt und mittels 'msiexec' installiert wurde, ist es in der Regel auch eine Deinstallation mittels 'msiexec' möglich. Dazu ruft man den msiexec.exe mit dem Parameter /x auf und übergibt zusätzlich den MSI-Paket oder dessen 'GUID' an. Um die Benutzer-Interaktion zu deaktivieren, kann zusätzlich der Parameter /qb-! übergeben werden.
Dies ergibt nun den folgenden Aufruf:

Statt das MSI-Paket zu übergeben, gibt es auch die Möglichkeit die 'GUID' an msiexec.exe zu übergeben. Diese ID ist eindeutig, Produkt-spezifisch und auf allen Systemen, auf denen das MSI-Paket installiert ist, gleich. Sie findet sich zum Beispiel im Zweig HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall der Registry.
Ein Beispiel einer Deinstallation mittels dieser GUID sieht folgendermaßen aus:

Sollten diese Methoden nicht oder nicht vollständig funktionieren, so muss mit einem opsi-winst-Skript nachgeholfen werden, wie es im nächsten Abschnitt beschrieben ist.

Wurde ein Produkt mit den opsi-winst-Funktionen installiert oder gibt es keine Deinstallation vom Hersteller, so muss ein eigenes opsi-winst-Skript zu Deinstallation geschrieben werden. Um den Programmierer bei dieser Arbeit zu unterstützen stellt der 'opsi-winst' einige Funktionen bereit, die speziell bei der Deinstallation notwendig oder hilfreich sind. Es soll an dieser Stelle nur ein kurzer Überblick gegeben werden, eine genaue Beschreibung der Befehle und deren Parameter findet sich im opsi-winst-Handbuch.

Der einfachste Fall ist das Löschen einer oder mehrerer Dateien vom System. Dies geschieht in einer Files-Sektion mittels des Befehls

oder für ein Verzeichnis mit Unterverzeichnissen

Der Parameter f steht dabei für force, um die Datei wirklich zu löschen, auch wenn diese schreibgeschützt ist, der Parameter s für subdirectories (mit Unterverzeichnissen/rekursiv). Soll eine Datei oder ein Verzeichnis aus allen Benutzer-Profilen gelöscht werden, so kann diese Files-Sektion mit dem Parameter /AllNTUserProfiles aufgerufen werden. (siehe opsi-winst-Handbuch)

Möchte man einen Verzeichnisbaum löschen, in dem sich auch Dateien mit dem Attribut „versteckt“ oder „systemdatei“ befinden, muss momentan ein Umweg über den Befehl rmdir gegangen werden, der über eine 'DosInAnIcon'-Sektion aufgerufen werden kann.

Muss vor dem Löschen evtl. ein laufender Prozess beendet werden, so kann dies mit dem Namen des Prozesses (zu sehen im Task-Manager) und dem opsi-winst-Befehl KillTask geschehen:

Sollte das Produkt – oder Teile davon – als Service laufen, so muss dieser vor der Deinstallation beendet werden. Man kann dazu den Service in der Registry auf “inaktiv“ schalten und den Rechner neu starten oder aber man benutzt den System-Befehl net mit dem Parameter stop, um den Service sofort zu stoppen und anschließend – ohne Neustart – die zugehörigen Dateien zu löschen.

Besondere Vorsicht ist beim Löschen von .dll-Dateien geboten, die noch von anderen Produkten verwendet werden könnten. Sie müssen individuell behandelt werden, weshalb hier leider kein allgemein gültiges Rezept gegeben werden kann.

Um einzelne Einträge aus der Registry mittels opsi-winst zu löschen, kommt der Befehl DeleteVar zum Einsatz, der innerhalb einer 'Registry'-Sektion eines opsi-winst-Skripts verwendet werden kann. Er löscht Einträge aus dem momentan geöffneten Key:

Möchte man einen Registry-Key samt seiner Unterschlüssel und Registry-Variablen löschen, so geschieht dies mittels des opsi-winst-Befehls DeleteKey, z.B.:

Der opsi-winst ist ein 32-Bit Programm. Skripte zur Installation von 32-Bit Programmen funktionieren in der Regel auch auf 64-Bit Systemen korrekt. Einige Konstanten, wie %ProgramFilesDir%, liefern Werte, die für die Verwendung mit 64-Bit-Programmen nicht richtig sind. Neuere opsi-winst-Versionen kennen spezielle Befehle und Konstanten für 64-Bit-Systeme. Beachten Sie beim Arbeiten auf 64-Bit-Systemen das entsprechende Kapitel im opsi-winst-Handbuch.

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).

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.

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.ins.

Ü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.

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.

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

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'

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.

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.

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

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

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.

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.

Als nächstes müssen Sie das, für das Produkt erstellte, opsi-winst-Skript und die entsprechenden Dateien nach 'CLIENT_DATA' kopieren.

Wenn Sie z.B. das erstellte Skript unter 'c:\test' liegen haben, so mounten Sie '\\<opsiserver\opsi_workbench' z.B. nach 'w:' und kopieren den Inhalt von 'c:\test' in das Verzeichnis 'CLIENT_DATA'.

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.

opsi-makepackage kennt einige Optionen, die sein Verhalten modifizieren:

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:

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.

Weitere Informationen zum opsi-packet-manager siehe opsi-Handbuch.