opsi-setup-detector (frei)
opsi-setup-detector Quickstart
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_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
Installation des opsi PackageBuilder
Den opsi PackageBuilder gibt es derzeit für Windows, Linux und MacOS.
Die Installations-Dateien / Pakete des opsi PackageBuilder finden Sie hier:
https://forum.opsi.org/viewtopic.php?p=32473#p32473
Dort findet sich im oberen Teil die Links auf die Installationspakete für Windows, Linux und MacOS.
Der opsi PackageBuilder kommt nicht von 'uib' sondern aus der opsi-community von Holger Pandel (Danke!).
Der opsi PackageBuilder unterliegt einer OpenSource Lizenz:
https://github.com/pandel/opsiPackageBuilder/blob/master/LICENSE_DE
Der opsi PackageBuilder hat eine eigene Dokumentation welche mit installiert wird.
Sie können den opsi PackageBuilder auch per opsi installieren:
Das Paket opsipackagebuilder_wlm gehört zu den opsi Standardprodukten und sollte auf Ihrem opsi-server installiert sein. Falls nicht, mit:
opsi-package-updater install opsipackagebuilder_wlmkönnen Sie es auf dem opsi-server installieren.
Installation des opsi-setup-detector
Den opsi-setup-detector gibt es derzeit für Windows, Linux und MacOS.
Sie können den opsi-setup-detector per opsi installieren:
Das Paket opsi-setup-detector gehört zu den opsi Standardprodukten und sollte auf Ihrem opsi-server installiert sein. Falls nicht, mit:
opsi-package-updater install opsi-setup-detectorkönnen Sie es auf dem opsi-server installieren.
Ein Setup-Programm um den opsi-setup-detector auf Windows auch ohne opsi zu installieren, finden sie unter :
https://download.uib.de/opsi4.2/misc/helper/
Die Basis Funktionalität des opsi-setup-detector auf den unterschiedlichen Betriebssystemen ist gleich. Bei der Analyse einer Installationsdatei werden aber eventuell Hilfprogramme aufgerufen, welche nicht überall verfügbar bzw. lauffähig sind.
-
Genauere Analyse von Inno-Setups verwendet innounpack.exe unter Windows.
-
Genauere Analyse von wix-setups verwendet dark.exe unter Windows.
-
.debbzw..rpmDateien werden mit den entsprechenden Linux Werkzeugen analysiert.
Das opsi-Produkt opsi-setup-detector hat eine Abhängigkeit zu dem opsi-Produkt opsipackagebuilder_wlm. Der opsi-setup-detector verwendet den opsi PackageBuilder wenn vorhanden, funktioniert in weiten Teilen aber auch ohne. Die Installation des opsi PackageBuilder ist aber empfohlen.
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
Opsi-setup-detector: Start und notwendige Konfigurationen
Der opsi-setup-detector kann gestartet werden aus der Programm Menü und findet sich dort unter opsi.org. Der opsi-setup-detector wird unter Windows auch in das Kontextmenü des Explorers eingebunden, um so per Rechte Maustaste Setup-Programm direkt zur Analyse aufrufen zu können.
Opsi-setup-detector: Notwendige Konfigurationen
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_workbenchIhres opsi-servers gemountet ist.
Optional: Verbindungsdaten zu dem opsi-webservice:
-
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.
Optional:
-
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.
Alle Details zur Konfiguration finden Sie hier:
https://docs.opsi.org/opsi-docs-de/4.2/manual/modules/setup-detector.html#opsi-setup-detector-configuration
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.
Die angebotenen Aufgaben für Windows:
-
Analysiere Datei und erzeuge ein opsi Paket
Hier wird von einer Setup-Datei ausgegangen und der gesamte Ablauf bis zur Erzeugung eines opsi-Paketes durchlaufen. Dieser Prozess ist im nächsten Kapitel beschrieben. -
Analysiere 2 Dateien (32 / 64 Bit) und erzeuge ein opsi Paket
Verläuft analog zu dem obigen Punkt 1 mit folgenden Unterschieden:
Es werden zwei Setupprogramme 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. -
Analysiere Datei und erzeuge ein Paket 'with user'
Verläuft analog zu dem obigen Punkt 1. Das Paket wird erstellt für eine Installation bei eingeloggtem User.
Das Produkt bekommt zusätzliche Properties: Das Property execution_method mit den möglichen Werten: (loginOpsiSetupUser, runAsOpsiSetupUser, runOpsiScriptAsOpsiSetupUser) und die boolschen Properties uninstall_before_install, copy_files_locally, debug.
Für weitere Details siehe : opsi_template_with_userlogin -
Eine opsi Paketvorlage (Template) erzeugen
Dieser Punkt fragt nicht nach einer Setup-Datei, sondern erstellt ein opsi template Produkt für Windows bei dem die Angaben aus der Produktkonfiguration bereits übernommen werden. -
Eine Datei nur analysieren
Verläuft analog zu dem obigen Punkt 1 nur das nach der Analyse des Setup-Programms abgebrochen wird.
Die Angebotenen Aufgaben für Linux:
-
Analysiere einzelne Linux Installer-Datei und erzeuge ein opsi Paket
Hier wird von einer Installer-Datei ausgegangen und der gesamte Ablauf bis zur Erzeugung eines opsi-Paketes durchlaufen. Dieser Prozess ist im nächsten Kapitel beschrieben. -
Eine opsi Paketvorlage (Template) für Linux erzeugen
Dieser Punkt fragt nicht nach einer Installer-Datei, sondern erstellt ein Template analog dem opsi-Produktopsi-templatenur das hier die Angaben aus der Produktkonfiguration bereits übernommen werden.
Die angebotenen Aufgaben für macOS:
-
Analysiere Datei und erzeuge ein opsi Paket
Hier wird von einer macOS Installer-Datei ausgegangen und der gesamte Ablauf bis zur Erzeugung eines opsi-Paketes durchlaufen. Dieser Prozeß ist 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 opsi template Produkt für macOS bei dem die Angaben aus der Produktkonfiguration bereits übernommen werden.
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.
opsi-setup-detector: Analysiere eine Datei und erzeuge ein opsi Paket
Im folgenden wird der Ablauf anhand des Punktes Analysiere eine Datei und erzeuge ein opsi Paket erläutert.
Nach der Auswahl der Aufgabe erscheint ein Dateiauswahl-Dialog zur Auswahl der zu analysierenden Setup Datei. Nach der Auswahl beginnt direkt die Analyse.
opsi-setup-detector: Analyse
War die Analyse nicht erfolgreich, endet sie hier mit Sorry unknown Installer.
In diesem Dialog kann gewählt werden, ob die Erzeugung abgebrochen wird, oder ob die Erzeugung nach dem Muster eines wählbaren bekannten Installerstyps fortgesetzt werden soll.
Bei einer erfolgreichen Analyse wird direkt zum Ergebnis gewechselt.
opsi-setup-detector: Ergebnis der Analyse
-
Erkannter Setup Typ: Typ des erkannten Installer
-
Bevorzuge Silent Installation:
Wird (wenn möglich) eine 'silent' Installation einer 'unattended' vorgezogen. -
MST erlaubt: Sollen auch zusätzliche 'mst' Dateien verwendet werden ? (Nur bei msi)
-
Hilfe anzeigen: image::osd_help-circle20.png["Hilfe anzeigen", pdfwidth=10%]
-
Info Link mit Infos zum Installer
-
Setup Datei: Pfad und Name der analysierten Setup-Datei
-
MST Datei: Bei MSI-Installern oder Installern welche MSI enthalten, kann hier eine MST-Datei angegeben werden welche in den MSI Aufruf integriert wird.
-
MsiId: Bei MSI-Installern oder Installern welche MSI enthalten, der MSI-Produktcode
-
MsiName: Bei MSI-Installern oder Installern welche MSI enthalten, der MSI-Produktname welcher in der Registry als 'Displayname' hinterlegt wird.
-
Software Version: Die Version der zu installierenden Software soweit ermittelbar
-
Setup Datei Größe MB: Größe der Setup Datei in MB
-
Benötigter Platz MB: Dieser Wert ist eine Schätzung aus sechsmal die Größe der Setup-Datei und kann gegebenenfalls angepasst werden
-
InstallDir: Soweit erkannt das Verzeichnis in das die Software installiert werden wird.
Wenn nicht korrekt erkannt, so kann über den Auswahlbutton rechts neben dem Feld das Verzeichnis gewählt werden. (Wenn das Produkt bereits auf dem Rechner installiert ist.)
Pfade wie 'C:\program Files' bzw. 'C:\program Files (x86)' werden automatisch durch die entsprechenden opsi-script Konstanten (z.B. '%ProgramFiles32Dir%') ersetzt. -
Kommando zur Installation: Das ermittelte Kommando zu einer nicht interaktiven Installation. Die genaue Form des Kommandos kann abhängig von der Checkbox
Bevorzuge Silent Installationunterschiedlich ausfallen. -
Kommando zur Deinstallation: Das ermittelte Kommando zu einer nicht interaktiven Deinstallation. Die genaue Form des Kommandos kann abhängig von der Checkbox
Bevorzuge Silent Installationunterschiedlich ausfallen. -
Deinstallations Programm: Das ermittelte Deinstallations Programm.
Wenn nicht korrekt erkannt, so kann über den Auswahlbutton rechts neben dem Feld die Datei gewählt werden. (Wenn das Produkt bereits auf dem Rechner installiert ist.).
MSI-Dateien haben (üblicherweise) kein Deinstalltions Programm. -
Hauptrogramm: Das Hauptrogramm der zu installierenden Software.
Wir verwendet um z.B. DesktopIcons oder Starmenüeinträge zu erzeugen. Wird nicht automatisch erkannt und kann über den Auswahlbutton rechts neben dem Feld die Datei gewählt werden. (Wenn das Produkt bereits auf dem Rechner installiert ist.)
Die hier ermittelten Werte können nun bei Bedarf korrigiert oder ergänzt werden. Der Button Nächster Schritt führt zur ersten Seite der Produktkonfiguration. Hier werden die Metadaten des zu erstellenden opsi Produktes eingegeben.
|
Die hier ermittelten Werte können falsch sein und sind wahrscheinlich unvollständig ! Nach einer ersten Installation sollten Sie unbedingt die Werte von InstallDir, Deinstallations Programm, Hauptrogramm und Software Version überprüfen und gegebenenfalls in Ihrem Script anpassen. |
opsi-setup-detector: Produktkonfiguration 1
-
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein '-' ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
-
Importiere control Datei: Mit diesem Button können ausgewählte Daten aus einer bestehenden opsi control Datei (
control, control.toml) in das laufende Projekt importiert werden. Nicht importiert werden dabei Versionsnummern, Scriptnamen, Benötigter Platz. -
Produkt Name: der Name der zu installierenden Software. Dieser muss evtl. händig korrigiert werden
-
Produkt Version: die aus dem Name der Setup-Datei ermittelte Versionsnummer muss wahrscheinlich händig korrigiert werden. Sie darf nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
-
Paket-Version: Die Versionsnummer des opsi Paketes. Diese dient datz Pakete zu unterscheiden, welche dieselbe Software in der selben Version enthalten aber z.B. unterschiedliche Scripte oder Properties. Sie darf nur Ziffern, da sie für die Versionierung des opsi Paketes verwendet wird.
-
Beschreibung: Üblicherweise ein Kurzbeschreibung was die Software macht.
-
Hinweis: Ergänzende Hinweise zur Software, wie z.B. Herkunft, Link zum Download, Hinweise zur Lizenz
-
Template Channel: Hier kann zwischen verschiedenen Quellen der Templates gewählt werden, welche für die Erstellung der Skripte verwendet werden. Die folgenden 'Template Channel' sind verfügbar:
-
Default: Dies ist der default und auch der Fallback. Wenn Sie einen anderen 'Template Channel' wählen und dieser die notwendigen Dateien für Ihren Task nicht bereitstellt, so werden die Dateien aus default verwendet.
Die wesentlichen Skriptdateien eines Produktes sind: setup.opsiscript, uninstall.opsiscript, declarations.opsiinc, sections.opsiinc, delinc.opsiinc -
Training: Das Ziel ist hier ein einfacherer Aufbau mit ausführlicher Kommentierung.
Die wesentlichen Skriptdateien eines Produktes sind: setup.opsiscript, uninstall.opsiscript, delinc.opsiinc -
Structured: In der Version 4.2.2 nicht verwendet (fallback zu default)
-
Custom: Ist per default leer. Sie können hier eigene Templatedateien bereitstellen. Um dies zu tun, müssen Sie Ihre Templates in das Verzeichnis 'opsi-setup-detector/custom/template-files/' auf Ihrem opsi-depot kopieren und dann den opsi-setup-detector neu auf dem Client installieren.
-
Checkboxen zur Codeergänzung
Die folgenden Checkboxen fügen zusätzlichen Code und zusätzliche Einstellungen für bestimmte Aufgaben hinzu:
-
Unterstütze custom directory : Das Produkt erhält ein zusätzliches Verzeichnis 'custom' welches Kunden spezifische Dateien enthalten kann. Bei der Installation einer neuen Version des Paketes auf dem Server wird das vorhandene custom Verzeichnis erhalten. Der Code enthält Vorlagen um Dateien aus diesem Verzeichnis in die Installation einzufügen.
Mehr Details: [opsi-setup-detector-support_custom_directory] -
Installiere von lokalem, temporären Verzeichnis : Die installationsdateien werden zunächst in ein lokales, temporäres Verzeichnis kopiert und dann aus diesem Verzeichnis heraus installiert. Insbesondere sinnvoll für alles was bei der Installation die Netzwerkverbindung beeinträchtigen könnte (z.B. Treiber).
Mehr Details: [opsi-setup-detector-install_from_local_temp_dir] -
Behandle Lizenzkeys : Fügt Property und Code zur Behandlung von Lizenzkeys hinzu.
Mehr Details: [opsi-setup-detector-handle_license_key] -
DesktopIcon : Fügt Property und Code zur Behandlung von Desktop Icons hinzu.
Mehr Details: [opsi-setup-detector-desktopicon] -
Customize Profile : Ergänzt den Code um eine 'Profileactions' Sektion um Anpassungen in den lokalen Userprofilen durchzuführen. Diese Funktionalität wird auch über ein loginscript für 'Roaming Profiles' bereitgestellt.
xref:osd-checkboxes-subtasks.adoc#opsi-setup-detector-customize_profile
Mehr Details: [opsi-setup-detector-customize_profile]
opsi-setup-detector: Priorität und Abhängigkeiten
Für normale Anwendungssoftware müssen Sie hier nichts tun, da die Voreinstellungen 'passen'. Sie können auf den Button Nächster Schritt drücken.
Ansonsten sei hier erläutert, welche Einstellungen hier möglich sind:
- Priorität
-
beeinflusst die Installationsreihenfolge. Empfohlen für Anwendungssoftware: 0
Mögliche Werte liegen zwischen 100 (ganz am Anfang) und -100 (ganz am Ende). Existieren auch Produktabhängigkeiten, so beeinflussen diese zusätzlich die Installationsreihenfolge.
Abhängigkeiten
Hier können Abhängigkeiten zwischen Produkten definiert werden.
Wenn in der Konfiguration die Zugangsdaten zu Ihrem opsi-server hinterlegt sind, so wird versucht eine Verbindung zum opsi-server aufzubauen. Wenn das Passwort aus Sicherheitsgründen nicht hinterlegt ist, wird hier nach dem Passwort gefragt:
- Actionrequest
-
Actionrequest zu dem eine Abhängigkeit erzeugt werden soll. Dies ist üblicherweise
setup. Ab opsi 4.3 sind auch andere Actionrequests erlaubt. Diese Möglichkeit ist mit Bedacht zu verwenden um nicht Bedingungen zu erzeugen welche nicht ohne Widersprüche auflösbar sind.
Dieser Bereich ist nur enabled, wenn In der Konfigurationdependencies_for_all_actionrequests = truegesetzt ist. - Productid
-
Productid (Bezeichner) des Produkts zu dem eine Abhängigkeit besteht.
Wenn es eine Verbindung zum opsi-server gibt, so wird dies hier in grüner Schrift angezeigt und die bekannten productIds können über das Auswahlfeld gewählt werden. Gibt es keine Verbindung zum opsi-server, so wird dies in roter Schrift angezeigt und die productId muss eingegeben werden. - Abhängigkeits Modus
-
Sie können entweder die Aktion setup anfordern oder (siehe unten) den Status (installed).
- Aktion oder Status
-
Für Status: Status den das Produkt, zu dem eine Abhängigkeit besteht, haben soll (installed). Liegt ein anderer Status vor, so wird das Produkt auf setup gestellt.
Für Aktion: Aktionsanforderung welche bei dem Produkt, zu dem eine Abhängigkeit besteht, gesetzt werden soll (setup)
Bei der Erzeugung eines Meta Produkts ist dieser Bereich disabled um unsinnige Einstellungen zu vermeiden. - Abhängigkeits Typ
-
Installationsreihenfolge. Wenn das Produkt, zu dem eine Abhängigkeit besteht, installiert sein muss bevor mit der Installation des aktuellen Produkts begonnen werden kann, dann ist dies before. Muss es nach dem aktuellen Produkt installiert werden so ist dies after. Ist die Reihenfolge egal so muss hier nichts eingetragen werden.
Bei der Erzeugung eines Meta Produkts ist dieser Bereich disabled um unsinnige Einstellungen zu vermeiden.
Hinweis:
Die tatsächliche Installationsreihenfolge ermittelt sich aus einer Kombination von Produktabhängigkeiten und Produktpriorisierung. Details hierzu finden Sie im opsi-Handbuch im Kapitel Beeinflussung der Installationsreihenfolge durch Prioritäten und Produktabhängigkeiten
opsi-setup-detector: Properties
Hier können veränderbare Eigenschaften (Produktvariablen) für das Produkt definiert werden.
Feld / Funktion |
Beschreibung |
Hinweise |
Property Name |
Name der Produktvariable |
Dieser Bezeichner wird in der Produktkonfiguration im opsi-configed angezeigt und ist innerhalb der Skripte mit der Funktion |
Beschreibung |
Beschreibung der Variablenfunktion |
Wird im opsi-configed als Tooltip angezeigt |
Property Type |
Variablentyp |
Mögliche Werte: Text / bool |
Multivalue |
Bestimmt, ob die Produktvariable nur genau einen oder mehrere Werte annehmen kann |
Nur bei Typ Text verfügbar |
Editierbar |
Bestimmt, ob die Vorgabewerte mit neuen oder zusätzlichen Werten überschrieben werden können oder nicht |
Nur bei Typ Text verfügbar |
Mögliche Werte |
Komma-separiert Liste der möglichen Eingabewerte |
Falls Editierbar auf “True” gesetzt wurde, kann die Liste später innerhalb von opsi-configed ergänzt werden. |
Default Wert |
Vorgabewert |
Auswahlliste; Nur bei Typ Text verfügbar: Freitextfeld. Nur bei Typ Multivalue verfügbar: Mehrfachauswahl |
opsi-setup-detector: Produkt Icon
Hier kann ein Icon für die Anzeige während der Installation ausgewählt werden oder Sie übernehmen mit Nächster Schritt das DefaultIcon (Zahnrad) und wechseln zum nächsten Reiter..
Um ein anderes Icon auszuwählen wählen Sie über den Button Öffne Icon Verzeichnis in Verzeichnis aus in dem Sie Icons erwarten. Als Vorauswahl bekommen Sie ein beim opsi-setup-detector mitgeliefertes Verzeichnis von 'open source' Icons: 128x128. Wählen Sie ein Unterverzeichnis und die Icons werden angezeigt.
Nun können Sie aus der Anzeige ein Icon auswählen.
Nachdem die Produktkonfiguration vollständig ist, kann nun das Produkt erzeugt werden.
opsi-setup-detector: Produkt erzeugen
-
Pfad zur opsi-workbench ist ein Laufwerksbuchstabe oder UNC Pfad auf dem der share opsi_workbench Ihres opsi-servers gemounted ist.
-
Links neben dem Button opsi Paket erstellen befinden sich drei mögliche Auswahl Optionen, die sich auf die Funktion des Buttons beziehen:
-
Erstellungs Modus ist ein Auswahlbereich bei dem die Vorgänge bei der Paketerstellung bestimmt werden können:
-
Erstelle opsi Produkt Dateien erzeugt falls noch nicht vorhanden, den Verzeichnisbaum für das neue opsi Paket auf der gewählten opsi-Workbench. Die für das Pakte benötigten Dateien werden erzeugt bzw. kopiert.
-
Erstelle opsi Produkt Dateien und baue opsi Paket führt die im ersten Punkt angeführten Vorgänge durch.
Zusätzlich wird versucht das Paket auf dem opsi-server zubauen und gegebenenfalls zu installieren (siehe unten: Auswahlfeld Bau Modus).
Wenn in der Konfiguration Verbindungsdaten zum opsi-webservice hinterlegt sind (siehe auch: Opsi-setup-detector Start und notwendige Konfigurationen) wird dieser kontaktiert. Ist kein Service Passwort gespeichert, wird nach dem Passwort gefragt. Ist die opsi-service Version größer gleich 4.2.0.287 dann wird das bauen und installieren über den opsi-service ausgeführt.
Ist der Service nicht erreichbar oder zu alt, wird der opsi PackageBuilder ohne interaktive GUI aufgerufen um aus dem erstellten Verzeichnisbaum das opsi-Paket zu erstellen und danach wieder beendet. Die genauen Abläufe werden dabei durch das Auswahlfeld Bau Modus bestimmt:-
nur bauen erzeugt das opsi Paket so wie der Server Befehl
opsi-makepackage. -
bauen und installieren erzeugt das opsi Paket so wie der Server Befehl
opsi-makepackage. Danach wird das erzeugte Paket installiert wie mit dem Server Befehlopsi-package-manager --install <package name>.
-
-
Erstelle opsi Produkt Dateien und starte interaktiven Packagebuilder führt die im ersten Punkt angeführten Vorgänge durch.
Zusätzlich wird der opsi PackageBuilder interaktiv aufgerufen.
Sie müssen diesen selbst beenden um zu dem opsi-setup-detector zurückzukehren.
Zu Installation, Konfiguration und Bedienung des Community Projektes opsi PackageBuilder siehe https://forum.opsi.org/viewforum.php?f=22 -
opsi Paket erstellen ist der Button welcher die Paketerstellung veranlasst.
Ist bereits ein Paket mit diesem Namen vorhanden, so erscheint eine Rückfrage ob die Dateien im vorhandene Verzeichnis gesichert oder gelöscht werden sollen:
Wenn bei der Erstellung der Produktdateien auf der Workbench ein vorhandenes Verzeichnis mit dem Namen <productId> gefunden wird, gibt es eine Rückfrage was mit den alten Dateien geschehen soll.
-
Nur Paket neu bauen ist ein Button mit dem das bauen des opsi Paketes veranlasst wird ohne vorher die opsi Dateien neu zu erzeugen.
Damit kann das Paket neu gebaut werden nach dem per Editor Änderungen an den Scripten durchgeführt wurden ohne diese Änderungen zu verlieren.
Bei der Erstellung der Produktdateien werden auch alle Informationen welche in den Masken eingegeben wurden, in die Datei opsi-project.osd im 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.
opsi-setup-detector: Vorhandenes Projekt öffnen
Eine existierende Projektstruktur kann auf zwei Arten durch den opsi-setup-detector als Projekt geöffnet werden:
-
Wenn das Produkt durch den opsi-setup-detector erzeugt wurde, können Sie dazu den Menüpunkt:
Datei / Projektdatei öffnenverwenden um die Dateiopsi-project.osdim Basisverzeichnis des Produktes zu öffnen. -
Wenn das Produkt nicht durch den opsi-setup-detector erzeugt wurde, können Sie dazu den Menüpunkt:
Datei / Controldatei öffnenverwenden um die Dateicontrolbzw.control.tomlimOPSIVerzeichnis des Produktes zu öffnen.
In diesem Fall haben Sie weniger Informationen insbesondere über die verwendete Installerdatei.
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 Setupprogramme 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
-
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. -
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.
-
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, das 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/
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 Setupprogramm
-
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.