opsi-setup-detector (frei)
opsi-setup-detector Quick 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 dieopsi_workbenchIhres opsi-servers gemountet ist.
Auf der Startseite wählen Sie die gewünschte Aufgabe und folgen den Dialogen bzw. wählen den Button Nächster Schritt.
Einführung: opsi-setup-detector - Was ist das ?
Die Erstellung von opsi-Paketen aus verfügbaren Setup-Programmen ist eine wiederkehrende Aufgabe beim Betrieb von opsi. Der opsi-setup-detector soll Ihnen auf zwei Weisen helfen dies zu vereinfachen:
-
Erkennung des Typ des Setup-Programms und die Ermittlung der dafür nötigen Kommandozeilen Parameter
-
Erstellung eins opsi-Paketes mit den nötigen Skripten für Installation und Deinstallation.
-
Gegenbefalls Einbindung des opsi-package-builders zur weiteren Bearbeitung des erstellten Paketes bzw. um das Paket zu bauen und zu installieren
Die meisten Setup-Programme werden von den Entwicklern nicht selbst geschrieben, sondern basieren auf unterschiedlichen Frameworks. Der opsi-setup-detector versucht nun in dem Setup-Programm Muster zu finden welche für bestimmte Frameworks spezifisch sind und anhand von diesen das Framework zu erkennen und damit die notwendigen Informationen zu ermitteln.
Das kann dazu führen, dass Sie mit wenigen Klicks ein fertiges opsi-Paket bekommen. Häufig bekommen Sie ein opsi-Paket dem nach erstmaliger installation der Programms (z.B. mit dem erstelleten opsi-Paket) noch weite Informationen hinzugefügt werden müssen.
Natürlich kann es auch zu Problemen kommen. Die gängigsten sind im Kapitel opsi-setup-detector: Probleme und Lösungen beschrieben.
Dort ist auch beschrieben, wie Sie uns helfen können nach der Lösung eines aufgetretenen Problems den opsi-setup-detector besser zu machen.
Installation des opsi-setup-detector und opsi-package-builder
Vorbereitungen
Zum Erstellen von opsi-Paketen benötigen Sie die folgenden Werkzeuge:
opsi-setup-detector installieren
Den opsi-setup-detector gibt es derzeit für Windows, Linux und macOS. Sie können das Programm direkt über opsi installieren. Es gehört zu den Standard-Localboot-Produkten und sollte bereits auf dem opsi-Server vorhanden sein. Ist das nicht der Fall, stellen Sie das Produkt über den folgenden Befehl bereit:
opsi-package-updater install opsi-setup-detector
Das Localboot-Produkt opsi-setup-detector erfordert ebenfalls die Installation des Produktes opsipackagebuilder_wlm, denn der Setup-Detector verwendet den PackageBuilder (sofern dieser vorhanden ist).
|
Installieren Sie daher ebenfalls das Produkt opsipackagebuilder_wlm:
opsi-package-updater install opsipackagebuilder_wlmAnschließend rollen Sie die beiden Produkte auf den gewünschten Clients aus, beispielsweise über die Management-Oberfläche opsi-configed.
| Für Windows-Rechner bieten wir den Setup-Detector auch als eigenständiges Paket an, das Sie unabhängig von opsi installieren können: https://tools.43.opsi.org/stable/ |
Unterschiede unter Windows, Linux, Mac
Grundsätzlich funktioniert der opsi-setup-detector auf allen drei Betriebssystemen ähnlich. Zur Analyse einer Installationsdatei ruft das Programm aber unterschiedliche Hilfsprogramme auf:
-
Genaue Analysen von Inno Setups unter Windows verwenden das integrierte Tool
innounpack.exe. Diese Detailanalyse ist daher nur unter Windows möglich. -
Zur Arbeit mit dem Windows Installer XML (kurz WiX Toolset) wird unter Windows das integrierte Werkzeug
Dark.exeverwendet. Diese Detailanalyse ist daher nur unter Windows möglich. -
.deb- bzw..rpm-Pakete analysieren die entsprechenden Standard Paketverwaltungstools unter Linux. Diese Detailanalyse ist daher nur auf Linux-Rechnern möglich.
opsi PackageBuilder installieren
Der opsi PackageBuilder (oPB) steht für Windows, Linux und macOS zur Verfügung.
Das Produkt opsipackagebuilder_wlm gehört zu den opsi-Standardprodukten. Falls es noch nicht auf Ihrem Server installiert ist, spielen Sie es über diesen Befehl ein:
opsi-package-updater install opsipackagebuilder_wlmAnschließend können Sie das Localboot-Produkt auf den Clients ausrollen, beispielsweise über die Management-Oberfläche opsi-configed.
Alternativer Weg zum Produkt:
Sie können opsi PackageBuilder (oPB) entweder als opsi-Produkt auf dem opsi-Server installieren und dann über opsi-configed ausrollen oder eines der im forum.opsi.org - opsi PackageBuilder verlinkten Installationspakete verwenden.
| Der opsi PackageBuilder (oPB) ist ein Community-Produkt und wird von Holger Pandel entwickelt — vielen Dank! |
Die Quellen und Lizenz finden sie hier: GitHub: opsi PackageBuilder (oPB)
opsi-logviewer installieren
Den opsi-logviewer gibt es derzeit für Windows, Linux und macOS. Er gehört zur Management-Oberfläche opsi-configed und wird mit dieser zusammen ausgeliefert.
Das Paket opsi-configed gehört zu den opsi-Standardprodukten und sollte auf Ihrem opsi-Server installiert sein. Falls nicht, spielen Sie es mit diesem Kommando ein:
opsi-package-updater install opsi-configed
Eine ausführbare Version der Management-Oberfläche opsi-configed für Windows, Linux und macOS finden Sie auf unserer Website opsi-Tools.
|
Vorbereitung zur Verwendung des opsi-setup-detector
Empfehlung:
-
Sie sollten den share
opsi_workbenchihres opsi-servers auf Ihrem Rechner gemountet haben. -
Sie sollten idealer weise den opsi-package-builder auf Ihrem Rechner installiert haben
Integration des opsi-package-builders durch den opsi-setup-detector
Auf dem Tab Erstellungs Modus finden Sie eine Auswahl für den Erstellungsmodus.
Der Default ist Erstelle opsi Produkt Dateien
Wählen sie eines der anderen Modi, so wird ein installierter opsi-package-builder mit aufgerufen.
Im Falle von … und baue opsi Paket wird der opb im Hintergrund aufgerufen um das vom opsi-setup-detector erstellte Verzeichnis mit den opsi Dateien zu einem Paket zu bauen. Dabei kann über die Checkboxen 'Bau Modus' ausgewählt werden, ob die Bau 'still' sein soll, ob das Paket gebaut werden soll und ob das gebaute Paket installiert werden soll.
Ohne eine dieser Optionen entspricht dieser Aufruf dem letzten Erstell-Modus: '… und starte interaktiven opsi-package-builder'
Verwendung des opsi-setup-detector
Start und Konfiguration
Unter Windows starten Sie den opsi-setup-detector aus dem Startmenü heraus; Sie finden das Werkzeug unter opsi.org / opsi-setup-detector. Unter macOS finden Sie den opsi-setup-detector über Programme und unter Linux in den Startmenüs unter Systemwerkzeuge. Auf den meisten Linux-Desktopumgebungen können Sie außerdem den vollen Pfad zur ausführbaren Datei (/opt/opsi-setup-detector/opsisetupdetector) in ein Schnellstartfenster ([Alt]+[F2]) oder Terminal eingeben.
Unter Windows können Sie den opsi-setup-detector direkt aus dem Explorer heraus starten. Wenn Sie mit der rechten Maustaste auf ein Setup-Programm einer Applikation klicken, finden Sie im Kontextmenü einen Eintrag, über den Sie das Tool zur Analyse starten.
|
Nach dem ersten Start erscheint ein Dialog, der Sie zur Konfiguration führt. Die folgenden drei Angaben sind unbedingt erforderlich:
-
fullName: Tragen Sie Ihren Namen ein, wie er später in der Dateichangelog.txtauftauchen soll. -
email_address: Tragen Sie Ihre Mailadresse ein, wie sie später in der Dateichangelog.txtauftauchen soll. -
workbench_Path: Hier geben Sie den Pfad zum Verzeichnis an, in dem Sie die opsi-Pakete erstellen.
Idealerweise ist das der Pfad zur Freigabe, an der die Workbench Ihres opsi-Servers gemountet ist (siehe Kapitel Samba).
Darüber hinaus können Sie optional weitere Einstellungen vornehmen. Für den opsi-Webservice opsiconfd (https://<opsi-server>:4447, siehe Kapitel Der Dienst opsiconfd) füllen Sie die folgenden Felder aus:
-
Service_URL: URL des opsi-Webservices (im Formathttps://<opsi-server>:4447) -
Service_user: Benutzername für die Verbindung zum opsi-Webservice -
Service_pass: Passwort des unterService_usereingetragenen Benutzers für die Verbindung zum opsi-Webservice: lassen Sie das Feld leer, dann fragt deropsi-setup-detectorbei Bedarf nach.
| Mögliches Sicherheitsrisiko: Auch wenn das Passwort verschlüsselt abgespeichert wird, so lässt es sich doch nach einer Analyse des (offenen) Quellcodes entschlüsseln. |
Weitere optionale Einstellungen sind:
-
control_in_toml_format: Checkbox aktivieren, um einecontrol-Datei im TOML-Format zu erzeugen (siehe Abschnitt Beispiel: control-Datei);
Achtung: Dazu ist mindestens opsi 4.3 erforderlich! -
dependencies_for_all_actionrequests: Sollen Abhängigkeiten auch für andere Action Requests (aussersetup) erlaubt sein?
Achtung: Dazu ist mindestens opsi 4.3 erforderlich, bitte mit äußerster Vorsicht verwenden! -
preferMsiUninstall: Soll wenn in einem Setupprogramm ein MSI gefunden wird, die Uninstallroutine des MSI statt der des Setupprogramms verwendet werden ?
| Eine ausführliche Beschreibung aller Einstellungen finden Sie im Kapitel opsi-setup-detector Konfiguration. |
Nach dem Speichern der Konfiguration erscheint die Startseite.
Onlinehilfe
Klicken Sie auf das Fragezeichen, um die Onlinehilfe zum opsi-setup-detector einzublenden.
Wählen Sie die gewünschte Aufgabe aus. Sie finden hier Tasks für Windows, Linux und macOS sowie vom Betriebssystem unabhängige Aufgaben und eine eigene Abteilung für Multiplattform-Pakete.
Die angebotenen Aufgaben für OS unabhängig:
-
Ein opsi Meta Produkt erzeugen
Ein Meta Produkt ist ein opsi Produkt, welches nichts installiert aber eine ganze Reihe von Abhängigkeiten enthalten kann. Wird bei einem solchen Produkt die Anforderung auf setup gestellt, so werden die Abhängigkeiten aufgelöst. Daher kann ein Meta Produkt verwendet werden um den Zielzustand einer Installation zu beschreiben.
Meta Produkte können auch geschachtelt werden, d.h. ein Meta Produkt kann eine Abhängigkeit auf ein anderes haben.
Der Ablauf ist analog dem für Windows im nächsten Kapitel beschrieben, nur das sie nach keiner Datei zum Analysieren gefragt werden.
Alle Informationen welche eingegeben wurden, werden bei der Produkterzeugung auch in die Dateiopsi-project.osdim Basisverzeichnis des Produktes geschrieben. Diese Datei kann zu einem späteren Zeitpunkt wieder mit dem opsi-setup-detector geöffnet werden um das Produkt zu modifizieren.
Unter Windows stehen folgende Funktionen zur Verfügung:
-
Analysiere Datei und erzeuge ein opsi Paket: Ausgehend von einer Setup-Datei wird hier der gesamte Prozess durchlaufen bis zum Erzeugen eines opsi-Paketes (siehe Abschnitt Datei analysieren und Paket erzeugen).
-
Analysiere 2 Dateien (32 / 64 Bit) und erzeuge ein O. Paket: Verläuft ähnlich, allerdings werden hier zwei Setup-Programme für die beiden Architekturen (32 Bit und 64 Bit) abgefragt und analysiert. Das Produkt bekommt ein zusätzliches Property:
install_architecture(mögliche Werte:32bitonly,64bitonly,bothundsystemspecific). -
Eine opsi Paketvorlage (Template) erzeugen: Fragt nicht nach einer Setup-Datei, sondern erstellt ein opsi-Template-Produkt für Windows und übernimmt dazu die Angaben aus der Produkt-Konfiguration.
-
Analysiere Datei und erzeuge ein Paket 'with user': Ähnlich wie Analysiere Datei und erzeuge ein opsi Paket, erstellt das Paket für eine Installation bei angemeldetem Benutzer (siehe Abschnitt opsi_template_with_userlogin). Das Produkt bekommt zusätzliche Propertys:
-
execution_method, mögliche Werte:loginOpsiSetupUser,runAsOpsiSetupUserundrunOpsiScriptAsOpsiSetupUser -
boolesche Propertys:
uninstall_before_install,copy_files_locallyunddebug
-
-
Erzeuge ein opsi Paket Template 'with user': Fragt nicht nach einer Setup-Datei, sondern erstellt ein opsi-Template-Produkt für eine Installation bei angemeldetem Benutzer und übernimmt dazu die Angaben aus der Produkt-Konfiguration.
-
Erzeuge ein opsi winget Paket: Fragt nicht nach einer Setup-Datei, sondern springt zur 'winget' Maske. Dort müssen die
wingetIdund diewingetSourceeingetragen werden.
(see the section Erzeuge ein opsi winget Paket).
Unter Linux stehen folgende Funktionen zur Verfügung:
-
Analysiere eine Datei und erzeuge ein opsi Paket: Ausgehend von einer Linux-Installer-Datei wird hier der gesamte Prozess durchlaufen bis zum Erzeugen eines opsi-Paketes. Das funktioniert genauso, wie für Windows beschrieben (siehe Abschnitt Datei analysieren und Paket erzeugen).
-
Eine opsi Paketvorlage (Template) erzeugen: Fragt nicht nach einer Installer-Datei, sondern erstellt ein opsi-Template-Produkt für Linux und übernimmt dazu die Angaben aus der Produkt-Konfiguration.
Unter macOS stehen folgende Funktionen zur Verfügung:
-
Analysiere Datei und erzeuge ein opsi Paket: Ausgehend von einer macOS-Installer-Datei wird hier der gesamte Prozess durchlaufen bis zum Erzeugen eines opsi-Paketes. Das funktioniert genauso, wie für Windows beschrieben (siehe Abschnitt clients:windows-client/softwareintegration.adoc#opsi-setup-detector-use-single-analyze-and-create).
-
Eine opsi Paketvorlage (Template) erzeugen: Fragt nicht nach einer Setup-Datei, sondern erstellt ein opsi-Template-Produkt für macOS und übernimmt dazu die Angaben aus der Produkt-Konfiguration.
Die angebotenen Aufgaben für Multiplattform:
-
Analysiere Datei und erzeuge ein opsi Paket
Hier wird für Windows, Linux und macOS nach einer Setup / Installer Datei gefragt, diese dann analysiert und der gesamte Ablauf bis zur Erzeugung eines Multiplattform opsi-Paketes durchlaufen. Dieser Prozeß ist analog dem für Windows im nächsten Kapitel beschrieben. -
Eine opsi Paketvorlage (Template) erzeugen
Dieser Punkt fragt nicht nach einer Setup-Datei, sondern erstellt ein Multiplattform opsi template Produkt für Windows, Linux und macOS bei dem die Angaben aus der Produktkonfiguration bereits übernommen werden.
Datei analysieren und Paket erzeugen
Die folgenden Abschnitte beschreiben, wie Sie eine Setup-Datei analysieren und daraus ein opsi-Produkt erstellen. Klicken Sie dazu auf der Startseite (Abbildung 8, “Die opsi-setup-detector-Startseite”) auf die Schaltfläche Analysiere eine Datei und erzeuge ein opsi Paket. Danach navigieren Sie im Dateiauswahldialog zur gewünschten Installerdatei. Der opsi-setup-detector beginnt direkt mit der Analyse.
Analyse
Der opsi-setup-detector analysiert dabei die Datei mit seiner eigenen Methode und unter Verwendung des Werkzeugs Detect it Easy (DIE). Dateien welche an Ihrer Dateinamenerweiterung erkannt werden, werden nicht weiter analysiert.
Nach der Analyse einer Setup-Datei sehen Sie diesen Dialog:
War die Analyse nicht erfolgreich, sehen Sie stattdessen entweder diesen Dialog:
Der Typ der Installerdatei konnte nicht ermittelt werden.
Sie können jetzt den Vorgang per Klick auf Cancel abbrechen oder aus dem Drop-down-Menü einen Installertyp auswählen und die Paketerstellung fortsetzen.
oder Sie sehen diesen Dialog:
Der Typ der Installerdatei konnte zwar ermittelt werden aber der opsi-setup-detector hat keine weiteren Informationen zu diesem Typ.
Sie können jetzt den Vorgang per Klick auf Cancel abbrechen oder aus dem Drop-down-Menü einen Installertyp auswählen und die Paketerstellung fortsetzen.
Ist die Analyse erfolgreich verlaufen, öffnet sich in einzelnen Fällen ein Fenster mit ergänzenden Informationen zum erkannten Installertyp. Das ist beispielsweise bei Anwendungen wie InstallShield, dem Qt-Installer oder InstallAnywhere der Fall.
Ist die Analyse erfolgreich verlaufen, zeigt der opsi-setup-detector auf jeden Fall das Ergebnis an:
Im Detail finden Sie auf dem Reiter 1. Setup die folgenden Informationen und Funktionen:
-
Erkannter Setup Typ: Typ des erkannten Installers
-
Bevorzuge Silent Installation: Aktivieren Sie diese Checkbox, um (wenn möglich) eine Silent-Installation einer Unattended-Installation vorzuziehen.
-
MST erlaubt: Sollen zusätzliche
mst-Dateien zum Anpassen der Einstellungen für Microsoft-Windows-Installer-Anwendungen (MSI) verwendet werden? -
Info: Link, der weiterführende Informationen zum Installer anzeigt
-
Setup Datei: Pfad und Name der analysierten Setup-Datei
-
MST Datei: Zur Angabe der MST-Datei, die in den Installer-Aufruf integriert werden soll
-
MsiId: Produktcode bei MSI-Installern oder Installern, die MSI enthalten
-
MsiName: Produktname bei MSI-Installern oder Installern, die MSI enthalten; in der Registry als DisplayName hinterlegt
-
MsiUpgrade: Upgradecode bei MSI-Installern oder Installern, die MSI enthalten
-
Software Version: Version der zu installierenden Software (falls diese ermittelt werden kann)
-
Setup Datei Größe MB: Größe der Setup-Datei in MByte
-
Benötigter Platz MB: geschätzter Wert (Größe der Setup-Datei mal 6), kann gegebenenfalls angepasst werden
-
InstallDir: Verzeichnis, in das die Software installiert werden wird (sofern dieses erkannt wird); falls nicht korrekt erkannt, können Sie über das Ordner-Icon neben dem Feld einen Dateiauswahl-Dialog öffnen und das Verzeichnis festlegen. Pfade wie
C:\program Filesbzw.C:\program Files (x86)werden automatisch durch die entsprechendenopsi-script-Konstanten (z. B.%ProgramFiles32Dir%) ersetzt. -
Kommando zur Installation: ermitteltes Kommando zur nicht-interaktiven Installation; kann abhängig von der Checkbox Bevorzuge Silent Installation unterschiedlich ausfallen
-
Kommando zur Deinstallation: ermitteltes Kommando zur nicht-interaktiven Deinstallation; kann abhängig von der Checkbox Bevorzuge Silent Installation unterschiedlich ausfallen
Siehe auch: Konfiguration: preferMsiUninstall -
Deinstallations Programm: ermitteltes Programm zur Deinstallation; falls nicht korrekt erkannt, können Sie über das Ordner-Icon neben dem Feld einen Dateiauswahl-Dialog öffnen und zur gewünschten Anwendung navigieren. MSI-Dateien haben (üblicherweise) kein Deinstallations-Programm.
-
Hauptrogramm: Hauptrogramm der zu installierenden Software; wird verwendet, um z. B. Desktopsymbole oder Einträge fürs Starmenü zu erzeugen. Wird nicht automatisch erkannt. Wenn das Produkt bereits auf dem Rechner installiert ist, können Sie über das Ordner-Icon einen Auswahldialog öffnen.
Alle nach der Analyse ermittelten Werte können Sie bei Bedarf korrigieren und/oder ergänzen. Klicken Sie danach auf die Schaltfläche Nächster Schritt, um den ersten Reiter der Produkt-Konfiguration zu öffnen.
| Es ist sehr wahrscheinlich, dass die ermittelten Werte unvollständig oder sogar teilweise falsch sind. Überprüfen Sie nach einer ersten Installation unbedingt die Werte von InstallDir, Deinstallations Programm, Hauptrogramm und Software Version und passen Sie diese gegebenenfalls in Ihrem Skript an! |
Produkt-Konfiguration 1
Auf diesem Reiter nehmen Sie die folgenden Einstellungen vor:
-
opsi Product ID: Das ist der Name des neuen opsi-Paketes. Er wird aus dem Produktnamen (Feld opsi Product Name) erzeugt, wobei Leer- und Sonderzeichen durch Bindestriche ersetzt werden. Die vorgeschlagene Produkt-ID können Sie verändern.
-
Import control File: Öffnet einen Dateiauswahl-Dialog, um Daten aus einer bestehenden
control-Datei (control, control.toml) ins aktuelle Projekt zu importieren. Nicht importiert werden Angaben zu Versionsnummern, Skriptnamen oder dem benötigten Platz. -
opsi Product Name: Den Namen der zu installierenden Software können Sie hier korrigieren.
-
Produkt Version: Die aus dem Namen der Setup-Datei ermittelte Versionsnummer können Sie hier korrigieren; sie darf nur Ziffern und Punkte enthalten, da sie zur Versionierung des opsi-Paketes verwendet wird.
-
Paket-Version: Die Versionsnummer des opsi-Paketes dient zur Unterscheidung von opsi-Produkten, die dieselbe Software in derselben Version enthalten, aber unterschiedliche Skripte oder Propertys haben. Sie darf nur Ziffern und Punkte enthalten, da sie zur Versionierung des opsi-Paketes verwendet wird.
-
Beschreibung: Tragen Sie in dieses Feld eine kurze Beschreibung der Anwendung ein. Seit opsi 4.3 können Sie Markdown für diesen Text verwenden. Links ist der Editierbereich und auf der rechten Seite die Vorschau.
-
Hinweis: Hier ist Platz für ergänzende Hinweise zur Software, wie z. B. Herkunft, Downloadlink, Lizenz usw. Seit opsi 4.3 können Sie Markdown für diesen Text verwenden. Links ist der Editierbereich und auf der rechten Seite die Vorschau.
-
Template Channel: Wählen Sie aus dem Drop-down-Menü eines der folgenden Templates zur Erstellung der Skripte aus:
-
default: Standard und Fallback; wählen Sie ein anderes Template aus, das die notwendigen Dateien für Ihren Task nicht bereitstellt, so wird automatisch default verwendet. Wesentliche Skripte des Produktes sind:
setup.opsiscript,uninstall.opsiscript,declarations.opsiinc,sections.opsiincunddelinc.opsiinc. -
training: einfacher Aufbau mit ausführlichen Kommentaren; wesentliche Skripte des Produktes sind:
setup.opsiscript,uninstall.opsiscriptunddelinc.opsiinc -
structured: Fallback zu default; in Version 4.2.2 und darüber nicht verwendet
-
custom: Ist in der Voreinstellung leer und bietet Platz für eigene Template-Dateien. Dazu kopieren Sie Ihre Templates ins Verzeichnis
opsi-setup-detector/custom/template-files/auf dem Depotserver und installieren danach denopsi-setup-detectorneu auf den entsprechenden Clients.
-
Im unteren Fensterbereich finden Sie außerdem einige Checkboxen, über die Sie zusätzlichen Code und Einstellungen für bestimmte Aufgaben ergänzen:
-
Unterstütze custom directory: Das Produkt bekommt ein zusätzliches Verzeichnis namens
custom, das (kundenspezifische) Anpassungen enthalten kann. Bei der Installation einer neuen Version des Paketes auf dem Server wird ein solchescustom-Verzeichnis nicht überschrieben. Der Code enthält Vorlagen, um Dateien aus diesem Verzeichnis hinzuzufügen (siehe Abschnitt Custom-Verzeichnis).) -
Installiere von lokalem, temporären Verzeichnis: Die Installations-Dateien werden zunächst in ein lokales, temporäres Verzeichnis kopiert und dann von dort aus installiert. Das ist vor allem sinnvoll für alle Komponenten, die während der Installation die Netzwerkverbindung beeinträchtigen könnten, z. B. Treiber (siehe Abschnitt Lokales, temporäres Verzeichnis).
-
Behandle Lizenzkeys: Erzeugt ein zusätzliches Property zur Behandlung von Lizenzschlüsseln hinzu (siehe Abschnitt Lizenzschlüssel).
-
Desktopicon: Erzeugt ein zusätzliches, boolesches Property (Voreinstellung
false) zur Behandlung von Desktopsymbolen hinzu (siehe Abschnitt Desktop-Icon). -
Customize Profile: Ergänzt den Code um einen Abschnitt
ProfileActionsfür Anpassungen in den lokalen Benutzerprofilen (siehe Abschnitt Lokale Benutzerprofile anpassen). -
Uninstall_before_install: Erzeugt ein zusätzliches, boolesches Property (Voreinstellung
true) zur Steuerung ob vor einer Installation eine Deinstallation durchgeführt werden soll. (siehe Abschnitt Uninstall_before_install).
Priorität und Abhängigkeiten
Auf dem Reiter Produkt Konfiguration 2 können Sie Prioritäten und Abhängigkeiten genauer definieren:
| Bei "normaler" Anwendungssoftware müssen Sie hier in der Regel nichts konfigurieren und können auf Nächster Schritt klicken. |
Auf diesem Reiter können Sie folgende Einstellungen vornehmen:
-
Priorität: Beeinflusst die Reihenfolge der Installation; mögliche Werte liegen zwischen 100 (ganz am Anfang) und -100 (ganz am Ende). Für Anwendungssoftware empfohlen: 0. Wenn außerdem Abhängigkeiten existieren, dann beeinflussen diese ebenfalls die Reihenfolge bei der Installation.
-
Abhängigkeiten: Hier können Sie Abhängigkeiten zwischen Produkten definieren. Wenn in der Konfiguration die Zugangsdaten zu Ihrem opsi-Server hinterlegt sind, wird versucht, eine Verbindung zum Server aufzubauen. Haben Sie das Kennwort aus Sicherheitsgründen nicht hinterlegt, dann erfolgt an dieser Stelle die Passwortabfrage (siehe Abschnitt Abhängigkeiten definieren).
-
Properties: Hier definieren Sie (veränderbare) Eigenschaften des Produktes (siehe Abschnitt Propertys definieren).
Abhängigkeiten definieren
Klicken Sie auf die Schaltfläche Dependency hinzufügen, um den Dialog Depency Editor zu öffnen:
Hier können Sie die folgenden Einstellungen vornehmen:
-
Actionrequest zu dem die Abhängigkeit erzeugt werden soll: In der Voreinstellung ist hier setup ausgewählt. Ab opsi 4.3 sind auch andere ActionRequests erlaubt (
uninstall,update,always,customundonce). Verwenden Sie diese Einstellung mit Vorsicht, um nicht Bedingungen zu erzeugen, die ohne Widersprüche nicht auflösbar sind!
Das Drop-down-Menü ist nur dann aktiv, wenn Sie in der opsi-setup-detector-Konfiguration die Option dependencies_for_all_actionrequests aktiviert haben (siehe Abschnitt Start und Konfiguration).
|
-
productId des abhängigen Produkts: Aus dem Drop-down-Menü können Sie das Produkt auswählen, zu dem eine Abhängigkeit besteht. Wenn es eine Verbindung zum opsi-Server gibt, dann zeigt der Dialog dies in grüner Schrift an und listet die installierten Produkte im Menü auf. Besteht die Verbindung nicht, dann sehen Sie einen Hinweis in roter Schrift und müssen die Produkt-ID von Hand eingeben.
-
Abhängigkeits Modus: Wenn Sie ein Meta-Produkt erzeugen, ist dieser Bereich deaktiviert, um unsinnige Einstellungen zu vermeiden. Hier gibt es zwei Optionen zur Auswahl:
-
Aktion: Anforderung für einen ActionRequest, der beim Produkt gesetzt werden soll, zu dem eine Abhängigkeit besteht (setup).
-
Status: Status, den das Produkt haben soll, zu dem eine Abhängigkeit besteht (installed). Liegt ein anderer Status vor, so wird das Produkt auf setup gesetzt.
-
| Die tatsächliche Installations-Reihenfolge ergibt sich aus einer Kombination von Abhängigkeiten und Priorität der Produkte (siehe Abschnitt Abhängigkeiten und Reihenfolge). |
Propertys definieren
Auf dem Reiter Produkt Konfiguration 2 können Sie im unteren Bereich veränderbare Eigenschaften (Variablen) für das Produkt definieren. Klicken Sie dazu auf Property hinzufügen:
| Feld/Funktion | Beschreibung | Hinweise |
|---|---|---|
Property Name |
Name der Produkt-Variable |
Der |
Property Type |
Typ der Variable |
Mögliche Werte sind Text und Boolean. |
Multivalue |
Anzahl der Werte |
Bestimmt, ob die Variable nur genau einen oder mehrere Werte annehmen kann; nur bei Typ Text verfügbar. |
Editierbar |
Werte überschreibbar |
Bestimmt, ob die Vorgabewerte mit neuen oder zusätzlichen Werten überschrieben werden können oder nicht, nur bei Typ Text verfügbar. |
Mögliche Werte |
Eingabewerte |
Durch Kommata getrennte Liste der möglichen Eingabewerte. Falls hier True gesetzt ist, können Sie die Liste später im |
Default Wert |
Vorgabewert |
Auswahlliste; nur bei Typ Text verfügbar: Freitextfeld. Nur bei Typ Multivalue verfügbar: Mehrfachauswahl. |
Produkt-Icon auswählen
Auf diesem Reiter können Sie ein Symbol für das Produkt auswählen, das während der Installation angezeigt wird:
Wenn Sie diesen optionalen Schritt überspringen, wählt der opsi-setup-detector automatisch ein Zahnrad als Icon aus (Default) und wechselt zum nächsten Reiter.
|
Klicken Sie in der rechten Fensterhälfte auf die Schaltfläche Öffne Icon Verzeichnis und navigieren Sie im Auswahldialog zum Ordner mit den gewünschten Icons. Als Vorauswahl sehen Sie ein mit dem opsi-setup-detector mitgeliefertes Verzeichnis 128x128 mit Symbolen, die unter einer freien Lizenz stehen. Nach dem Öffnen des Ordners erscheinen in der linken Hälfte alle Symbole, und Sie können eines für Ihr Produkt auswählen.
Produkt erzeugen
Nachdem die Konfiguration des Produktes abgeschlossen ist, können Sie es auf dem letzten Reiter erzeugen:
Hier stehen die folgenden Optionen zur Verfügung:
-
Pfad zur opsi-work-bench: Hier sehen Sie das bei der Einrichtung konfigurierte Verzeichnis zur Workbench-Freigabe auf Ihrem opsi-Server (Laufwerksbuchstabe oder UNC-Pfad).
-
Über die Schaltfläche Workbench Pfad prüfen können Sie überprüfen, ob die Freigabe erreichbar ist.
-
Im Bereich Erstellungs Modus wählen Sie aus, wie das Paket erstellt wird:
-
Erstelle opsi Produkt Dateien erzeugt (falls noch nicht vorhanden) den Verzeichnisbaum für das neue opsi-Produkt auf der Workbench. Die für das Paket benötigten Dateien werden erzeugt bzw. kopiert.
-
Erstelle opsi Produkt Dateien und baue opsi Paket erzeugt den Verzeichnisbaum und versucht außerdem, das Paket auf dem opsi-Server zu bauen. Ist auf der rechten Seite (Bau Modus) die Checkbox bauen und installieren aktiviert, wird das Produkt nach dem Bauen auch auf dem Server installiert. Wenn Sie in der Konfiguration die Verbindung zum opsi-Webservice eingerichtet haben, wird der Dienst kontaktiert und ggf. nach dem Passwort gefragt.
-
Das Bauen und Installieren über den Webservice gelingt nur, wenn der opsiconfd in Version 4.2.0.287 oder neuer vorliegt. Ist der Service nicht erreichbar oder zu alt, dann übernimmt der opsi PackageBuilder (ohne GUI) und erstellt das Paket.
|
-
Erstelle opsi Produkt Dateien und starte interaktiven Packagebuilder erzeugt (falls noch nicht vorhanden) den Verzeichnisbaum für das neue opsi-Produkt auf der Workbench und startet den opsi PackageBuilder im interaktiven Modus. Diesen müssen Sie explizit beenden, um zum
opsi-setup-detectorzurückzukehren.-
Bau Modus: Die beiden Optionen bestimmen, was bei einem Klick auf opsi Paket erstellen tatsächlich passiert:
-
-
nur bauen erzeugt das opsi-Paket (entspricht dem Befehl
opsi-makepackage). -
bauen und installieren erzeugt das opsi-Paket (
opsi-makepackage) und installiert dieses (entspricht dem Befehlopsi-package-manager --install <paket>).-
opsi Paket erstellen: Per Klick auf diesen Button starten Sie die Paketerstellung. Gibt es bereits ein opsi-Produkt mit demselben Namen, dann erscheint eine Sicherheitsabfrage:
-
-
Nur Paket neu bauen: Dieser Button startet das Bauen des opsi-Paketes, ohne vorher die opsi-Dateien neu zu erzeugen. Die Option eignet sich also dazu, ein Paket neu zu bauen, nachdem Sie in einem Editor Änderungen am Skript vorgenommen haben.
Beim Erstellen des opsi-Produktes schreibt der opsi-setup-detector alle Informationen, die Sie dort hinterlegt haben, in die Datei opsi-project.osd im Hauptverzeichnis des Produktes.
Eine solche opsi-project.osd-Datei können Sie zu einem späteren Zeitpunkt wieder mit dem opsi-setup-detector öffnen, um ein vorhandenes Paket zu modifizieren.
|
Vorhandenes Projekt öffnen
Es gibt zwei Möglichkeiten, eine bestehende Projektstruktur mit dem opsi-setup-detector als Projekt zu öffnen:
-
Wenn das Produkt mit dem
opsi-setup-detectorerstellt wurde, dann können Sie aus dem Menü Datei / Öffnen und die Dateiopsi-project.osdaus dem Hauptverzeichnis des Projektes öffnen. -
Bei Produkten, die nicht mit dem
opsi-setup-detectorerstellt wurden, können Sie stattdessen diecontrol-Datei (control, control.toml) öffnen. Wählen Sie dazu aus dem Menü Datei / Controldatei öffnen und navigieren zurcontrol-Datei im VerzeichnisOPSIdes Produktes.
Letzteres bietet weniger Informationen, insbesondere in Bezug auf die verwendete Setup-Datei des Installers.
opsi-setup-detector: Analysiere 2 Dateien (32 / 64 Bit) und erzeuge ein opsi Paket
Dieser Punkt entspricht dem oben beschriebenen Analysiere eine Datei und erzeuge ein opsi Paket mit der folgenden Ergänzung:
Es werden zwei Setup-Programme für die Architekturen 32 und 64 Bit abgefragt und analysiert. Das Produkt bekommt ein zusätzliches Property: install_architecture mit den möglichen Werten: 32bitonly, 64bitonly, both, systemspecific.
opsi-setup-detector: Eine opsi Paketvorlage (Template) erzeugen
Dieser Punkt entspricht dem oben beschriebenen Analysiere eine Datei und erzeuge ein opsi Paket mit der folgenden Einschränkung:
es wird nicht nach einer Setup Datei gefragt und damit entfällt auch die Analyse. Vielmehr wird eine allgemeine Scriptvorlage erzeugt.
Opsi winget Paket erzeugen
Der folgenden Abschnitt beschreibt, wie Sie ein winget basiertes opsi-Produkt erstellen.
winget ist ein Windows Kommandozeilen Befehl mit dem Sie Software direkt aus dem Internet auf den Rechner installieren können.
In der Regel muß winget zunächst auf dem Rechner installiert werden. Dazu stellen wir das opsi Paket ms-winget-cli zur Verfügung.
Um ein winget basiertes Paket zu erstellen klicken Sie auf der Startseite (Abbildung 8, “Die opsi-setup-detector-Startseite”) auf die Schaltfläche Erzeuge ein opsi winget Paket. Danach bekommen Sie die folgenden Hinweis zu sehen:
Nach dem Sie den Hinweis bestätigt haben, bekommen Sie die folgende Maske zu sehen:
Hier geben Sie die wingetId und die wingetSource ein.
In den Feldern 'Kommando zur Installation' und 'Kommando zur Deinstallation' können Sie sehen mit welchem Kommando die Software dann (De-)Installiert wird.
Über den Button Nächster Schritt kommen Sie dann zur Produktkonfiguration 1 die Sie wie bei den anderen Tasks verwenden.
Typische wingetSource sind winget und msstore.
Werkzeuge zur Ermittlung von wingetId und wingetSource finden Sie hier:
Unigetui ist ein lokal zu Installierendes Werkzeug mit dem Sie nach im Netz verfügbaren Paketen aus unterschiedlichen Quellen suchen können. Bei gefundenen Paketen können Sie über das Kontextmenü / Paketdetails umfangreiche Informationen über das Paket erhalten. (Runterscrollen nicht vergessen).
Evtl. finden Sie hier auch einen Link wo der ursprüngliche Installer heruntergeladen werden kann.
Siehe: unigetui
winget.run ist eine webseite mit der die wingetId von Paketen aus der Quelle winget ermittelt werden kann (also keien Pakete aus dem MS-Store).
Siehe: winget.run
Weiter Seiten mit Detailinformationen zum Befehl winget finden Sie bei learn.microsoft
und bei wikipedia
opsi-setup-detector: Konfiguration
-
Name:
(Wird verwendet für Einträge in die changelog.txt) -
eMail:
(Wird verwendet für Einträge in die changelog.txt) -
Pfad zur opsi-work-bench:
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. -
Pfad zum opsi-package-builder:
Der opsi-package-builder wird verwendet um via ssh die opsi Pakete auf dem opsi-server zu bauen. siehe auch: \n" "https://forum.opsi.org/viewtopic.php?f=22&t=7573\n"
-
Service_URL:
Die URL des opsi webservice (wie: https://<opsi-server>:4447) -
Service_user:
Der user name für die Verbindung zum opsi Webservice -
Service_pass:
Das Passwort des angegebenen users für die Verbindung zum opsi webservice.
ACHTUNG SICHERHEITSRISIKO: Auch wenn das Passwort verschlüsselt abgespeichert wird, so läßt es sich doch nach einer Analyse des (offenen) Quellcodes entschlüsseln. Es wird nach dem Passwort gefragt, wenn hier nichts steht.
-
BuildRadioIndex :
Auswahl des RadioButtonsBau Modus. -
CreateRadioIndex :
Auswahl des RadioButtonsErstellungs Modus. -
control_in_toml_format :
Control Datei im TOML Format erzeugen ?
Hierfür wird mind. opsi 4.3 benötigt.
Gibt es eine control.toml, so ist diese maßgeblich und muss gepflegt werden. -
dependencies_for_all_actionrequests :
Sollen Abhängigkeiten auch für andere Actionrequests (ausser 'setup') erlaubt sein ?
Für 'true' ist opsi 4.3 Voraussetzung.
Nur sehr vorsichtig verwenden. -
preferSilent :
Defaultwert fürBevorzuge Silent Installation: Sollen stille (silent) Installationen (ohne jede Ausgabe) bevorzugt werden ? Der Default ist false = Eine unattended Installation wird bevorzugt.
-
preferMsiUninstall : Soll wenn in einem Setupprogramm ein MSI gefunden wird, die Uninstallroutine des MSI statt der des Setupprogramms verwendet werden ?
-
Readme_txt_templ :
Pfad zur Readme Template Textdatei. -
registerInFilemanager :
Soll dieses Programm für das Kontextmenü des Dateimanagers (Explorer) registriert werden ? -
templateChannel :
Defaultwert für den zu verwendenden 'Template Channel'. -
UsePropDesktopicon :
Defaultwert für:
Soll ein "Desktopicon" erzeugt und Code zur Manipulation von Desktopicons hinzugefügt werden? -
UsePropLicenseOrPool :
Defaultwert für:
Soll ein "LicenseOrPool" Property erzeugt und Code zur Manipulation von Lizenzkeys hinzugefügt werden? -
workbench_mounted :
Automatisch erkannt. Ist die opsi_workbench unter dem angegebenen Pfad 'workbench_path' erreichbar.
-
import_libraries:
Liste der opsi-script Bibliotheken.
Eine pro Zeile. Darf leer sein. Beispiel:
myInstallhelperlib.opsiscript
Konfigurationen bei denen Sie opsi-script code für bestimmte Stellen eingeben können:
opsi-script code Zeilen welche eingefügt werden.
Ein opsi-script Befehl pro Zeile. Darf leer sein.
Beispiel:
comment "Installation finished…"
-
preinstalllines:
opsi-script code Zeilen welche vor dem Beginn der Installation eingefügt werden. -
postinstalllines:
Zeilen welche nach dem Ende der Installation eingefügt werden. -
preuninstalllines:
opsi-script code Zeilen welche vor dem Beginn der Deinstallation eingefügt werden. -
postuninstalllines:
opsi-script code Zeilen welche nach dem Ende der Deinstallation eingefügt werden.
Automatisch gewartete Konfigurationen (nicht ändern):
-
config_filled :
Automatisch erkannt. Sind alle nötigen Konfigurationen bekannt ? -
config_version :
Nicht ändern. Version der Konfigurationsstruktur. -
LasticonFileDir :
Letztes Verzeichnis von dem eine Icondatei geöffnet wurde. -
LastProjectFileDir :
Letztes Verzeichnis von dem ein Projekt geöffnet wurde. -
LastSetupFileDir :
Letztes Verzeichnis von dem eine Installerdatei (Setup) geöffnet wurde. -
Show2StepMacSeletionWarn :
Nicht hier ändern - wird von einem internen Dialog gesetzt. -
ShowCheckEntryWarning :
Nicht hier ändern - wird von einem internen Dialog gesetzt.
opsi-setup-detector: Probleme und Lösungen
Der opsi-setup-detector ist so designt, dass es möglichst einfach ist ihn kontinuierlich weiter zupflegen und zu erweitern.
Bestimmte Anpassungsmöglichkeiten und Hilfen bei Problemen werden Ihnen im Folgenden vorgestellt.
Haben Sie Ideen und / oder Wünsche darüberhinaus, so nehmen Sie bitte zu uns Kontakt auf (info@uib.de) - wir freuen uns über jede Anregung.
Logging
Der opsi-setup-detector erzeugt Logdateien unter
c:\opsi.org\applog\opsisetupdetector.log.
Ältere Logdateien liegen im selben Verzeichnis als opsisetupdetector_0.log bis opsisetupdetector_8.log.
Die Logdatei wird sehr groß, weil sie die kompletten Daten der Analyse der Setupdatei(en) enthält. Zur Analyse der Logdatei empfehlen wir den opsi-log-viewer oder einen anderen Editor welcher die nicht benötigten Loglevel ausblenden kann, da die im Setup gefundenen Textmuster (auf Loglevel 8) in vielen Fällen nicht intressieren.
Sprachunterstützung
Beim Start des Programmes wird automatisch ermittelt, unter welcher Sprache das Windows System läuft. Wenn für die Sprache eine passende Sprachdatei gefunden wird, wird diese verwendet. Wird keine unterstützte Sprache gefunden, so wird Englisch verwendet.
Sie können die Sprache wählen über den Menüpunkt Languages bzw. beim Aufruf über den Kommandozeilen Parameter --lang=xx wobei xx für die gewählte Sprache steht.
Derzeit unterstützt der 'opsi setup detector' :
-
Deutsch
-
Englisch
-
Französisch
-
Spanisch (unvollständig)
Weitere Sprachen können recht einfach über eine entsprechend zu übersetzende Sprachdatei nachgerüstet werden.
Die Übersetzungen erfolgen über das Portal:
https://www.transifex.com/opsi-org/
Wir freuen uns über Ihre Unterstützung
Unknown Installer
Sicher werden Sie im Rahmen der Arbeit mit dem opsi-setup-detector mal auf die Meldung Unknown Installer stoßen. Dann hat der opsi-setup-detector das Installer-Framework mit dem dieser Installer gemacht ist nicht erkannt.
Vorschläge:
-
Prüfen Sie ob es tatsächlich ein Installer ist. (Klingt blöd, ist mir aber selbst schon mal so gegangen)
-
Suchen Sie im Internet nach den Stichwörtern 'silent' und Produktname
-
Vielleicht helfen die Links auf dieser Seite weiter:
https://wiki.opsi.org/userspace:software_integration_web_links
Wenn Sie das Problem gelöst haben, lassen Sie uns (und die opsi Community) an Ihrem Wissen und Erfahrung teilhaben.
Das neue (interne) Design des opsi-setup-detector macht es möglich, vergleichweise leicht neue Installer aufzunehmen. Was wir benötigen ist :
-
Beispiel Setup-Programm
-
Hersteller bzw. typische Kommandozeilen Schalte für Installation und Deinstalltion
-
Informative Links zu dem Problem
Falsch Erkennung
Gerade im Rahmen der zunehmenden Anzahl von unterstützten (also erkannten) Installern führt auch schonmal zu einer Falscherkennung.
Die passiert insbesondere dann gerne wenn ein Installer mehrere Softwarekomponenten umfasst, welche wiederum mit unterschiedlichen Installern gepackt sind.
Sollten Sie ein solches Problem entdecken, so informieren Sie uns bitte und halten das entsprechende Beispiel und die richtige Lösung bereit.
Programmfehler
Sollte der opsi-setup-detector Dinge tun, die er nicht sollte, so sichern Sie bitte die dazu passendende Logdatei aus c:\opsi.org\applog\ (siehe auch: Logging) und informieren Sie uns über das Problem auf info@uib.de. Halten Sie auch die Beispieldatei bereit, da wir diese eventuell benötigen um das Problem nachzuvollziehen.