Paket aus Installer erzeugen
Rollen: Packager, Releaser, Administrator
Überblick
Der Assistent Aus Installer … in der Paketliste macht in oPBWeb, was sonst der opsi-setup-detector auf deinem Rechner erledigt: Er analysiert einen Installer, schlägt Product-ID, Version, Installations- und Deinstallationsbefehl vor und erzeugt aus den Script-Vorlagen des opsi-setup-detectors ein vollständiges Paket. Das Paket landet als Entwurf in oPBWeb, der Installer liegt schon in CLIENT_DATA/files1.
Du brauchst dafür weder den opsi-setup-detector noch eine Workbench-Freigabe auf deinem Rechner. Wer lieber mit dem opsi-setup-detector arbeitet, nutzt weiter die Übergabe über den Launcher ; beide Wege führen zum selben Ergebnis, einem Entwurf in oPBWeb.
Die Analyse und das Erzeugen laufen als Jobs im Worker. Den Fortschritt siehst du im Assistenten und unter Jobs („Installer analysieren: …“, „Paket aus Installer anlegen: …“).
Der Assistent im Überblick
Klick in der Werkzeugleiste der Paketliste auf Aus Installer …. Der Dialog „Neues Paket aus Installer“ führt dich durch vier Schritte:
| Schritt | Was du tust |
|---|---|
| Quelle | Art des Pakets, Ziel-Betriebssystem und Vorlagenkanal wählen, Installer hochladen oder in der Workbench angeben |
| Analyse | Ergebnis der Analyse prüfen und korrigieren |
| Produkt | Product-ID, Versionen, Beschreibung, Optionen, Properties, Abhängigkeiten, Changelog und Produktbild festlegen |
| Erzeugen | Zusammenfassung prüfen, Paket anlegen, im Editor öffnen |
Mit Zurück gehst du einen Schritt zurück, ein Klick auf einen erledigten Schritt oben springt direkt dorthin. Bei den Vorlagen-Arten ohne Installer entfällt der Schritt Analyse.
Beim ersten Öffnen des Assistenten erscheint vorher einmalig der Hinweis „Hinweis zum Funktionsumfang“: Der Assistent kann weniger als der originale opsi-setup-detector, die Unterschiede stehen unter Einschränkungen . Derselbe Hinweis erscheint auch vor dem ersten Installer analysieren im Paket-Editor, falls du ihn noch nicht bestätigt hast. Nach Verstanden merkt sich oPBWeb das an deinem Benutzerkonto; der Hinweis kommt also auch in einem anderen Browser nicht wieder. Unter Mein Konto kannst du ihn mit Wieder anzeigen wieder einschalten.
Schritt 1: Quelle
- Wähl unter Art des Pakets, was entstehen soll (Tabelle unten). Unter dem Feld steht jeweils ein kurzer Hinweis zur gewählten Art.
- Wähl das Ziel-Betriebssystem (Windows, Linux oder macOS). Das Feld ist nur bei den Arten aktiv, die für ein einzelnes Betriebssystem gelten.
- Wähl den Vorlagenkanal. Vorbelegt ist der Kanal aus den Einstellungen
:
- Training (ausführlich kommentiert): Scripte mit vielen Erklärungen, gut zum Lernen.
- Standard: die Vorlagen, die der opsi-setup-detector normalerweise verwendet.
- Strukturiert: Scripte, die stärker in einzelne Dateien aufgeteilt sind.
- Eigene (custom): eure eigenen Vorlagen. Was dort fehlt, nimmt der Generator aus Standard, siehe Vorlagen .
- Gib für jeden Installer an, woher er kommt:
- Hochladen: Zieh die Datei in das Feld „Installer hierher ziehen oder auswählen“ oder klick auf Datei auswählen ….
- Aus der Workbench: Gib unter Pfad relativ zur Workbench den Pfad ab dem Projektordner an, zum Beispiel
firefox/CLIENT_DATA/files1/setup.exe. Sind mehrere Configserver eingerichtet, wählst du darüber den Configserver. Mit Ganzen Ordner übernehmen kopiert oPBWeb beim Erzeugen alle Dateien aus dem Ordner des Installers (mit Unterordnern) nachfiles1bzw.files2,files3, etwa für Installer mit Zusatzdateien.
- Bei einer
.msi-Datei kannst du eine MST-Datei (optional) angeben: beim Hochladen in einem zweiten Feld, bei der Workbench nur mit ihrem Namen (sie muss im selben Ordner liegen). Der Installationsbefehl bekommt dannTRANSFORMS=…. - Stell bei Bedarf die beiden Analyseoptionen um (vorbelegt aus den Einstellungen):
- Silent- statt Unattended-Parameter verwenden: Der Installer läuft ganz ohne Fenster statt mit Fortschrittsanzeige.
- MSI-Wrapper über msiexec deinstallieren, wenn die MSI-Daten bekannt sind: Bei Installern mit eingebettetem MSI deinstalliert das Paket über
msiexec /xmit dem ProductCode.
- Klick auf Analysieren. Bei den Vorlagen-Arten heißt die Schaltfläche Weiter.
Fehlt etwas, nennt der Dialog es unter den Feldern, zum Beispiel „Installer: Datei oder Workbench-Pfad fehlt.“
Arten von Paketen
| Art des Pakets | Installer | Ergebnis |
|---|---|---|
| Einzelner Installer | einer | Paket für ein Betriebssystem; das Ziel-Betriebssystem richtet sich nach dem Installer |
| 32- und 64-Bit-Installer | zwei (Windows) | Paket mit beiden Installern und der Property install_architecture (32 only, 64 only, system specific, both) |
| Mehrere Betriebssysteme | je einer für Windows, Linux, macOS, jeder optional, mindestens einer | Paket mit Scripten für alle drei Betriebssysteme; ohne Installer bekommt ein Betriebssystem nur die Vorlagenscripte |
| Nur Vorlage | keiner | nur die Scripte aus den Vorlagen; die Installationsbefehle trägst du danach im Editor ein |
| Vorlage für mehrere Betriebssysteme | keiner | Scripte für Windows, Linux und macOS ohne Installer |
| Installation im Benutzerkontext | einer (Windows) | der Installer läuft in einer Sitzung des Benutzers opsisetupuser, die Scripte liegen unter localsetup |
| Vorlage für Installation im Benutzerkontext | keiner | Scripte für eine Installation im Benutzerkontext ohne Installer |
| winget | keiner | Produkt, das der Client über winget installiert; statt einer Datei gibst du die winget-ID (zum Beispiel Mozilla.Firefox) und die Quelle an (Standard winget) |
Schritt 2: Analyse
oPBWeb lädt die Installer hoch und startet für jeden einen Analyse-Job. Neben dem Dateinamen zeigt ein Abzeichen den Stand: „lädt hoch“, „analysiert“ mit Prozentangabe, „analysiert ✓“ oder „fehlgeschlagen“. Unter Protokoll steht das Job-Protokoll. Weiter wird erst aktiv, wenn alle Analysen fertig sind.
Für jeden Installer zeigt der Dialog:
- Typ: der erkannte Installertyp, zum Beispiel „Inno Setup“ oder „Nullsoft Install System“. Haben die Regeln mehrere Typen gefunden, steht darunter „Ebenfalls erkannt: …“. Erkennt oPBWeb den Typ falsch oder gar nicht, wählst du ihn hier aus; das startet eine neue Analyse mit diesem Typ („Typ von Hand gewählt“). automatisch erkennen schaltet zurück.
- Hinweis des Detectors: die Erklärung des opsi-setup-detectors zu diesem Installertyp, oft mit Link zur Dokumentation des Herstellers.
- Fundstellen: die Erkennungsmuster, die in der Datei gefunden wurden.
- Ergebnis von Detect-It-Easy: nur, wenn Detect-It-Easy im Worker installiert ist (siehe Grenzen ).
- Hinweise der Analyse, zum Beispiel „Installertyp nicht erkannt. Bitte den Typ von Hand wählen.“
- Die Felder, die der Generator verwendet: Product-ID, Produktname, Produktversion, Installationsverzeichnis, Architektur, Hauptprogramm (für das Desktop-Icon), Installationsbefehl, Deinstallationsbefehl, Deinstallationsprogramm, Über msiexec deinstallieren, Platzbedarf, bei MSI MSI-ProductCode und MSI-UpgradeCode sowie Prüfung „installiert?“ (opsi-script-Zeilen, die prüfen, ob die Software schon installiert ist).
Alle Felder kannst du ändern; der Generator übernimmt deine Werte. Mit Erneut analysieren startest du die Analyse noch einmal, etwa nachdem du Silent- statt Unattended-Parameter verwenden umgestellt hast.
Was die Analyse je Installertyp findet
Den Typ erkennt oPBWeb wie der opsi-setup-detector an Textmustern in der Datei. Grundlage ist die Installertabelle des opsi-setup-detectors mit rund 30 Typen; aus ihr kommen auch die Silent- und Unattended-Parameter, das Deinstallationsprogramm und die Funktion, die Exit-Codes bewertet. Danach liest oPBWeb je nach Typ weitere Angaben aus:
| Installer | Was zusätzlich gelesen wird |
|---|---|
Windows-Programme allgemein (.exe) | Versionsressource: Produktname und Dateiversion, Architektur des Installers |
MSI (.msi) | ProductName, ProductVersion, ProductCode, UpgradeCode und das Installationsverzeichnis aus der MSI-Datenbank; Deinstallation über msiexec /x |
| Inno Setup | aus dem Setup-Header: Name und Version der Anwendung, Standard-Installationsverzeichnis, 32/64 Bit, Ort des Deinstallationsprogramms |
| InstallShield mit MSI, Advanced Installer, WiX-Bundles | das eingebettete MSI, sofern 7-Zip es auspacken kann; dann wie bei MSI |
| InstallAware | Name des Deinstallationsprogramms aus den Fundstellen |
| MSIX / APPX (auch Bundles) | Name, Version, Architektur und Beschreibung aus dem Manifest; Deinstallation und Prüfung über PowerShell. Die Option Vor Installation deinstallieren ist vorausgewählt („Für MSIX/APPX empfiehlt der Detector …“) |
Debian-Pakete (.deb) | Paketname, Version, Beschreibung, Hersteller, Lizenz, Architektur, Homepage, Platzbedarf |
RPM-Pakete (.rpm) | dieselben Angaben aus dem RPM-Header |
macOS (.dmg, .pkg, .app, .zip mit Ziel macOS) | Name und Version aus dem Dateinamen; ein ZIP muss eine .app, .dmg oder .pkg enthalten |
| andere erkannte Typen (NSIS, InstallShield klassisch, Wise, Bitrock …) | Parameter und Deinstallationsprogramm aus der Installertabelle, Name und Version aus der Versionsressource oder dem Dateinamen |
Grenzen der Analyse
- Inno Setup: Den Setup-Header liest das Werkzeug innoextract. Neue Inno-Versionen, die innoextract noch nicht kennt, liefern „Der Inno-Setup-Header konnte nicht gelesen werden (innoextract).“ Installationsverzeichnis und Deinstallationsprogramm sind dann Standardannahmen; prüf sie.
- MSI in Wrapper-Installern: Der opsi-setup-detector führt solche Installer unter Windows aus, um das MSI auszupacken. oPBWeb führt keine Installer aus, sondern versucht es mit 7-Zip. Findet 7-Zip kein MSI („7-Zip hat kein eingebettetes MSI gefunden …“), fehlen die MSI-Angaben, und das Paket deinstalliert über das Deinstallationsprogramm des Installers. Sind mehrere MSI-Dateien drin, wertet oPBWeb die erste aus und nennt alle.
- Detect-It-Easy: Der opsi-setup-detector holt sich bei unbekannten Dateien eine zweite Meinung von Detect-It-Easy. Im Image von oPBWeb ist es nicht enthalten; ohne Detect-It-Easy bleibt es bei der Erkennung über die Muster. Wie man es nachrüstet, steht in der Konfiguration .
- Nur unter Windows: Was der opsi-setup-detector durch Ausführen des Installers auf einem Windows-Rechner herausfindet, kann oPBWeb nicht ermitteln. Prüf deshalb vor allem bei unbekannten Typen Installationsverzeichnis, Deinstallationsprogramm und die Prüfung „installiert?“.
Die Analyse ist ein Vorschlag. Teste jedes erzeugte Paket auf einem Test-Client, bevor du es auf Produktions-Depots bringst.
Schritt 3: Produkt
Product-ID, Name, Produktversion und Beschreibung sind aus der Analyse vorbelegt, Paketversion, Priorität, Format control und Changelog aus den Einstellungen für neue Pakete . Für die Felder gelten dieselben Regeln wie bei Neues Paket. Unter den Feldern zeigt oPBWeb, ob es die Product-ID oder die Version schon gibt, zum Beispiel „firefox gibt es in oPBWeb bereits; die Version wird neu angelegt.“
Optionen
Die Optionen schalten zusätzliche Bausteine der Vorlagen ein:
| Option | Wirkung |
|---|---|
| Lizenzpflichtig | setzt im control die Lizenzpflicht |
| Desktop-Icon (Property desktopicon) | Property desktopicon und Scriptteile, die eine Verknüpfung auf das Hauptprogramm anlegen bzw. entfernen |
| Lizenzschlüssel-Property (SecretLicense_or_Pool) | Property secretlicense_or_pool für einen Lizenzschlüssel oder einen opsi-Lizenzpool, dazu die Scriptteile zum Holen und Freigeben der Lizenz |
| Aus lokalem Verzeichnis installieren | Property install_from_local_tmpdir: Der Client kopiert die Installationsdateien erst lokal und installiert von dort |
| Custom-Verzeichnis | Ordner CLIENT_DATA/custom/ für eigene Dateien, die das Script mitkopiert |
| Profilanpassung | Ordner CLIENT_DATA/profile_files/ und Scriptteile, die Benutzerprofile anpassen |
| Vor Installation deinstallieren | Property uninstall_before_install: entfernt eine vorhandene Installation vor dem Setup |
Desktop-Icon und Lizenzschlüssel-Property sind vorausgewählt, wenn ein Administrator das in den Einstellungen so festgelegt hat.
Properties und Standard-Properties
Unter Properties stehen die vorbelegten Properties aus den Einstellungen. Du kannst sie ändern, löschen und mit Property hinzufügen ergänzen (Name, Typ, Standardwert, Mögliche Werte kommagetrennt, Beschreibung, Frei). Jeder Name darf nur einmal vorkommen.
Die Properties, die zu den gewählten Optionen und zur Art des Pakets gehören, ergänzt der Generator selbst. Du musst sie nicht anlegen:
| Property | Wann |
|---|---|
desktopicon | Option Desktop-Icon |
secretlicense_or_pool | Option Lizenzschlüssel-Property |
install_from_local_tmpdir | Option Aus lokalem Verzeichnis installieren |
install_architecture | Art 32- und 64-Bit-Installer |
uninstall_before_install | Option Vor Installation deinstallieren und Installation im Benutzerkontext |
copy_files_locally, debug, execution_method, install_at_safe_mode_boot | Installation im Benutzerkontext |
Abhängigkeiten, Changelog und Produktbild
- Abhängigkeiten: Mit Abhängigkeit hinzufügen trägst du je Zeile unter Benötigtes Produkt das Produkt ein, unter Benötigt eine Aktion oder einen Zustand dieses Produkts und unter Reihenfolge
before,afteroder „egal“. Die Abhängigkeiten gelten für die Aktionsetup; ändern kannst du sie später im Paket-Editor . - Changelog-Eintrag: Text des ersten Changelog-Eintrags. Leer lassen ergibt den Standardtext des Generators.
- Produktbild (PNG): Mit PNG auswählen … lädst du ein eigenes Bild hoch. Ohne eigenes Bild bekommt das Paket das Standardbild des Betriebssystems aus den Vorlagen.
Schritt 4: Erzeugen
Der letzte Schritt fasst Art, Vorlagenkanal, Product-ID, Version, Installer und die Zahl der Properties zusammen und prüft, ob es das Paket schon gibt. Je nach Lage bietet er an:
| Lage | Auswahl |
|---|---|
| Das Paket gibt es in oPBWeb noch nicht | Paket anlegen |
| Das Paket gibt es, die Version noch nicht | Neue Version anlegen |
| Die Version gibt es schon | Als … anlegen (nächste freie Paketversion, zum Beispiel 1.0-3 statt 1.0-2) und, wenn die vorhandene Version ein Entwurf ist, Entwurf überschreiben |
| Die Version gibt es schon, sie ist freigegeben und die Paketversion lässt sich nicht hochzählen | keine; ändere die Version im Schritt Produkt |
| Das Paket ist archiviert | keine; stell das Paket erst wieder her, siehe Paket archivieren |
Nach dem Klick zeigt der Dialog den Fortschritt („Erzeuge das Paket … 40 %“) und das Job-Protokoll. Der Job erzeugt die Produktdateien aus den Vorlagen, kopiert die Installer nach CLIENT_DATA/files1 (bzw. files2, files3) und legt alles als neue Entwurfsversion an. Danach meldet er „firefox 128.0-1 ist als Entwurf angelegt.“ Klick auf Im Editor öffnen, um das Paket zu prüfen, zu bauen und zu testen.
In den Paketdetails steht als Herkunft „opsi-setup-detector“.
Warnungen des Jobs stehen unter der Erfolgsmeldung:
- „Vorlage … fehlt, der Baustein wird ausgelassen“: Im gewählten Kanal, in Standard und in
default/genericgibt es die Datei nicht, etwa weil ein Administrator sie gelöscht hat. - „Nicht ersetzte Platzhalter in den erzeugten Dateien: …“: Eine Vorlage enthält einen Platzhalter, für den der Generator keinen Wert hat. Such ihn im Editor und ersetz ihn von Hand.
Installer im Paket analysieren
Liegt ein Installer schon in einem Paket, analysierst du ihn im Paket-Editor über das Kontextmenü des Dateibaums mit Installer analysieren, siehe Dateien des Pakets . Das Ergebnis ist dort nur eine Anzeige, es ändert das Paket nicht. Hast du den „Hinweis zum Funktionsumfang“ noch nicht bestätigt, erscheint er vor der ersten Analyse; die Einschränkungen gelten auch hier.
Einschränkungen gegenüber dem opsi-setup-detector
Der Assistent übernimmt Analyse und Paketerzeugung des opsi-setup-detectors, läuft aber im Worker-Container unter Linux und nicht auf einem Windows-Rechner. Daraus und aus dem Umfang der Portierung ergeben sich diese Unterschiede:
| Bereich | opsi-setup-detector | oPBWeb |
|---|---|---|
| MSI in Wrapper-Installern | packt das MSI unter Windows durch Ausführen des Installers aus: InstallShield mit MSI (extractMSI.cmd), Advanced Installer (/extract), WiX-Bundles (dark.exe) | führt keine Installer aus und versucht es nur mit 7-Zip. Klappt das nicht, bleiben MSI-ProductCode, Produktname und Installationsverzeichnis unbekannt („7-Zip hat kein eingebettetes MSI gefunden …“). Mit echten InstallShield-, Advanced-Installer- und WiX-Installern ist das noch nicht getestet. |
| Detect-It-Easy | holt sich bei unbekannten Dateien eine zweite Meinung | nicht im Image, nur nachrüstbar (DIEC_PATH, siehe Konfiguration
). Ohne Detect-It-Easy bleiben Installer, die nur Detect-It-Easy erkennt (etwa Squirrel oder Microsoft-.NET-Installer), „unbekannt“, und du wählst den Typ von Hand. |
| Inno Setup | liest das Setup mit innounp bzw. innounp-2 | liest den Setup-Header mit innoextract (Fork von crazy-max, kennt Inno Setup bis 7.1). Für neuere Inno-Versionen gelten Standardannahmen („Der Inno-Setup-Header konnte nicht gelesen werden …“). |
| Quelle des Installers | lokale Datei oder lokaler Ordner | Upload oder Datei in einem Projektordner der Workbench. Große Installer musst du erst hochladen. Ganzen Ordner übernehmen gibt es nur bei der Workbench. Ein .app-Bundle ist ein Ordner und lässt sich nicht hochladen; pack es als ZIP. |
| Projektdatei | speichert opsi-project.osd und öffnet sie wieder, kann ein Produkt aus einer vorhandenen control-Datei vorbelegen | keine Projektdatei, kein Vorbelegen aus einer control-Datei. Was bleibt, ist das erzeugte Paket; Änderungen machst du danach im Paket-Editor . |
| Kommandozeile | Batch-Betrieb mit --filename, --nogui, --targetOS, --productID, --mode, --template-channel | nur der Assistent in der Oberfläche |
| Metadaten für Hintergrundinstallation | Reiter „Product Configuration 3“: Prozesse und zu prüfende Verzeichnisse bearbeitbar | opsi-meta-data.toml nur aus der Analyse (Einstellung Metadaten schreiben (CLIENT_DATA/opsi-meta-data.toml)): Prozessliste leer, geprüft wird nur das Installationsverzeichnis. Ob der opsi-Dienst die Datei so akzeptiert, ist ungeprüft. |
| Bauen und Installieren | Modus „build and install“ in einem Durchgang | Der Assistent endet mit einem Entwurf. Bauen und Installieren erledigst du danach im Editor. |
| Arten winget und Installation im Benutzerkontext | winget-Vorlagen werden referenziert, fehlen aber im Repository des Detectors | eigene winget-Vorlagen von oPBWeb. Weder winget- noch with-user-Pakete aus oPBWeb sind bisher auf einem Windows-Client getestet. |
| Vorlagenkanal Eigene (custom) | keine Vorlagen im Repository | ebenfalls leer; füll ihn in der Ansicht Vorlagen oder per ZIP-Import . |
Wann der opsi-setup-detector die bessere Wahl ist
Nimm den opsi-setup-detector unter Windows, wenn
- ein Wrapper-Installer sein MSI nur beim Ausführen herausgibt und du die MSI-Angaben brauchst,
- der Installer exotisch ist und nur Detect-It-Easy ihn erkennt (und es in deinem oPBWeb nicht nachgerüstet ist),
- ein Inno-Setup-Installer so neu ist, dass oPBWeb seinen Header nicht lesen kann,
- die Dateien lokal liegen und du sie nicht erst hochladen oder in die Workbench legen willst, oder ein
.app-Bundle als Ordner vorliegt, - du mit Projektdateien oder im Batch-Betrieb arbeitest,
- du ein winget-Paket oder ein Paket mit Installation im Benutzerkontext brauchst, solange diese Arten in oPBWeb nicht auf einem Client geprüft sind.
Das Ergebnis des opsi-setup-detectors landet trotzdem in oPBWeb: Über den Launcher übernimmt oPBWeb den erzeugten Projektordner aus der Workbench, siehe Übergabe vom opsi-setup-detector .