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 die opsi_workbench Ihres opsi-servers gemountet ist.

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

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

Startpage
Abbildung 2. opsi-setup-detector Start

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 es ü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_wlm

Anschließ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/
Zusatzprogramme

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 erfordern ein Tool wie innounpack.exe.

  • Zur Arbeit mit dem Windows Installer XML (kurz WiX Toolset) ist ein Werkzeug wie Dark unter Windows erforderlich.

  • .deb- bzw. .rpm-Pakete analysieren die entsprechenden Paketverwaltungstools unter Linux.

opsi PackageBuilder installieren

Der opsi PackageBuilder (oPB) steht ebenfalls für Windows, Linux und macOS zur Verfügung. Sie können ihn entweder als opsi-Produkt auf dem opsi-Server installieren und dann über opsi-configed ausrollen oder eines der im Forum verlinkten Installationspakete verwenden.

Der opsi PackageBuilder (oPB) ist ein Community-Produkt und wird von Holger Pandel entwickelt — vielen Dank!

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_wlm

Anschließend können Sie das Localboot-Produkt auf den Clients ausrollen, beispielsweise über die Management-Oberfläche opsi-configed.

Den opsi PackageBuilder (oPB) können Sie als Localboot-Produkt auf den Clients ausrollen.
Abbildung 3. Den opsi PackageBuilder (oPB) können Sie als Localboot-Produkt auf den Clients ausrollen.

Vorbereitung zur Verwendung des opsi-setup-detector

Empfehlung:

  • Sie sollten den share opsi_workbench ihres 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

Create and Build Modes
Abbildung 4. opsi-setup-detector Create and Build Modes

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

opsi-setup-detector starten und konfigurieren

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.
Den *opsi-setup-detector* starten Sie auch aus dem Explorer heraus.
Abbildung 5. Den opsi-setup-detector starten Sie auch aus dem Explorer heraus.

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 Datei changelog.txt auftauchen soll.

  • email_address: Tragen Sie Ihre Mailadresse ein, wie sie später in der Datei changelog.txt auftauchen 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).

Nach dem ersten Start konfigurieren Sie den *opsi-setup-detector*.
Abbildung 6. Nach dem ersten Start konfigurieren Sie den opsi-setup-detector.

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

  • Service_user: Benutzername für die Verbindung zum opsi-Webservice

  • Service_pass: Passwort des unter Service_user eingetragenen Benutzers für die Verbindung zum opsi-Webservice

Auch wenn das Passwort verschlüsselt abgespeichert wird, so lässt es sich doch nach einer Analyse des (offenen) Quellcodes entschlüsseln. Wenn Sie kein Kennwort im Feld Service_pass eintragen, fragt der opsi-setup-detector bei Bedarf nach.

Weitere optionale Einstellungen sind:

  • control_in_toml_format: Checkbox aktivieren, um eine control-Datei im TOML-Format zu erzeugen (siehe Abschnitt clients:windows-client/softwareintegration.adoc#opsi-softwintegration-example-control); Achtung: dazu ist mindestens opsi 4.3 erforderlich!

  • dependencies_for_all_actionrequests: Sollen Abhängigkeiten auch für andere Action Requests (ausser setup) erlaubt sein? Achtung: dazu ist mindestens opsi 4.3 erforderlich, bitte mit äußerster Vorsicht verwenden!

Eine ausführliche Beschreibung aller Einstellungen finden Sie im Kapitel opsi-setup-detector (frei). Die Onlinehilfe zum opsi-setup-detector können Sie darüber hinaus per Klick auf das Fragezeichen einblenden.
Über dieses Icon zeigen Sie die Onlinehilfe an.
Abbildung 7. Über dieses Icon zeigen Sie die Onlinehilfe an.

Nach dem Speichern der Konfiguration erscheint die Startseite.

Die *opsi-setup-detector*-Startseite
Abbildung 8. Die opsi-setup-detector-Startseite

Wählen Sie die gewünschte Aufgabe aus. Sie finden hier Tasks für Windows, Linux und macOS sowie vom Betriebssystem unabhängige Aufgaben und eine eigene Abteilung für Multiplattform-Pakete.

Unter 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 clients:windows-client/softwareintegration.adoc#opsi-setup-detector-use-single-analyze-and-create).

  • 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, both und systemspecific).

  • 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, runAsOpsiSetupUser und runOpsiScriptAsOpsiSetupUser

    • boolesche Propertys: uninstall_before_install, copy_files_locally und debug

  • Eine Datei nur analysieren: Verläuft ähnlich wie Analysiere Datei und erzeuge ein opsi Paket, allerdings wird nach der Analyse der Vorgang unterbrochen und kein Paket gebaut.

opsi-setup-detector: Analysiere 2 Dateien (32 / 64 Bit) und erzeuge ein opsi Paket

Ergebnis der Analyse 2
Abbildung 9. opsi-setup-detector Ergebnis der Analyse des zweiten Setup-Programms

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 Datei nur analysieren

Dieser Punkt entspricht dem oben beschriebenen Analysiere eine Datei und erzeuge ein opsi Paket mit der folgenden Einschränkung:
Nach der Analyse wird der Vorgang abgebrochen.

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-setup-detector: Konfiguration

Konfigurationsdialog
Abbildung 10. opsi-setup-detector: Konfiguration
Geforderte Konfigurationen:
  • 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"

Verbindung zum opsi-server
  • 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.

Programmverhalten
  • BuildRadioIndex :
    Auswahl des RadioButtons Bau Modus.

  • CreateRadioIndex :
    Auswahl des RadioButtons Erstellungs 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ür Bevorzuge Silent Installation: Sollen stille (silent) Installationen (ohne jede Ausgabe) bevorzugt werden ? Der Default ist false = Eine unattended Installation wird bevorzugt.

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

Modifikation des Produktes:
  • 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:

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.

Source Code und Lizenz

Der opsi-setup-detector ist Lizenziert unter der AGPLv3.

Den Sourcecode finden Sie unter: