Pakete

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Der Bereich Pakete ist die Startseite von oPBWeb. Hier siehst du alle Pakete mit ihrer neuesten Version, prüfst in den Paketdetails, auf welchen Depots sie installiert sind, und legst neue Pakete an. Die Werkzeugleiste bietet dafür Workbench …, Übernehmen …, Importieren, Meta-Paket …, Aus Installer … und Neues Paket; Aus Installer … erzeugt ein Paket direkt aus einem Installer, siehe Paket aus Installer erzeugen . Als Leser kannst du die Liste und die Details ansehen; Anlegen, Importieren und alle ändernden Aktionen brauchen mindestens die Rolle Packager.

Die Paketliste

Die Tabelle zeigt pro Paket die neueste Version:

Ein Klick wählt ein Paket aus und zeigt rechts seine Details. Ein Doppelklick öffnet es im Paket-Editor .

Filtern

• Die Schaltflächen Alle, Entwürfe und Freigegeben filtern nach dem Status der neuesten Version. Die Zahl dahinter zeigt, wie viele Pakete jeweils passen.
• Archiv zeigt statt der aktiven Pakete die archivierten (siehe Paket archivieren ). Gibt es keine, erscheint „Keine archivierten Pakete.“
• Im Feld „Filtern …“ suchst du nach Product-ID oder Name.

Passt kein Paket, erscheint „Kein Paket passt zum Filter.“

Paketdetails

Im rechten Bereich siehst du zum ausgewählten Paket:

• Kopf: Produktlogo (falls vorhanden), Product-ID, Version, Status, Name und die erste Zeile der Beschreibung.
• Schaltflächen: Im Editor öffnen und Quelltext (öffnet den Editor direkt in der Quelltext-Ansicht). Als Packager zusätzlich Bauen (nur bei Entwürfen) und Installieren … (nur, wenn die neueste Version aktuell gebaut ist). Ist der Build veraltet, steht dort „seit dem Bauen geändert“.
• Eckdaten: Typ, Priorität, setup- und uninstall-Script, Abhängigkeiten, Properties, Anzahl der Dateien und Scripte, Format (zum Beispiel „INI · Changelog eingebettet“) und Herkunft („neu angelegt“, „importiert“, „kopiert von …“ oder „aus der Workbench“).
• Verteilung: Für jedes Depot die Stufe (Produktion, Staging oder Test) und die dort installierte Version, gruppiert nach Configserver (siehe Verteilung ). Als Packager übernimmst du das Paket mit Auf andere Stufe übernehmen … von einer Stufe auf die nächste (siehe Auf andere Stufe übernehmen ). Ist das Produkt irgendwo installiert, kannst du es mit Deinstallieren … entfernen.
• Workbench: Auf welcher Workbench das Paket liegt, siehe Workbench .
• Versionen: Alle Versionen des Pakets mit Status und Datum. Ein Klick öffnet die jeweilige Version im Editor.
• Paket (ab Packager): Archivieren bzw. bei archivierten Paketen Wiederherstellen und Paket löschen …, siehe Paket archivieren und Paket löschen .

Verteilung

Die Tabelle Verteilung fasst die Depots je Configserver zusammen. Die Kopfzeile eines Servers nennt, auf wie vielen seiner Depots das Paket installiert ist („1 von 3 installiert“). Darunter steht je Depot die Stufe und die installierte Version:

• Eine kursive Stufe hat das Depot von seinem Configserver geerbt.
• Weicht die installierte Version von der neuesten ab, ist sie orange markiert.
• Ein Klick auf die Kopfzeile eines Configservers klappt seine Depots zu oder auf. oPBWeb merkt sich das in diesem Browser.
• „Depot suchen“ grenzt die Depots nach Depot-ID oder Name des Configservers ein; während der Suche sind alle Gruppen aufgeklappt.
• Der Chip Nur installierte blendet alle Depots aus, auf denen das Paket nicht installiert ist. Die Zahl im Chip nennt die Depots mit Installation.

Workbench

Der Abschnitt Workbench zeigt, in welchen Projektordnern der Workbenches das Paket liegt: Configserver, Projektordner (mit Pfad, wenn er in einem Gruppenordner liegt, zum Beispiel develop/firefox) und Version. Weicht die Version von der neuesten in oPBWeb ab, ist sie orange markiert. Liegt das Paket auf keiner Workbench, steht dort „Auf keiner Workbench.“

oPBWeb liest die Workbench nicht bei jedem Öffnen, sondern merkt sich, was es zuletzt gesehen hat. Aktuell wird die Angabe

• beim Einlesen im Dialog Workbench … ,
• bei jedem Export in die Workbench ,
• bei jedem Abgleich über Abgleichen oder ⟳ in Depots und
• automatisch durch den Worker, standardmäßig stündlich (einstellbar unter Einstellungen → Worker ).

Ignorierte Ordner lässt jedes Einlesen aus; beim Ignorieren verschwinden die Projektordner darunter sofort aus diesem Abschnitt.

Die Zeile „Stand:“ darunter nennt je Configserver, wann seine Workbench zuletzt vollständig gelesen wurde, oder „nie gelesen“. Hast du die Workbench direkt auf dem Server geändert, gleich vorher ab.

Bauen, Installieren und Deinstallieren sind in Bauen und verteilen beschrieben. Mehrere Pakete auf einmal von einer Stufe auf die nächste bringst du mit Übernehmen … in der Werkzeugleiste der Paketliste, siehe Auf andere Stufe übernehmen .

Neues Paket anlegen

Rollen: Packager, Releaser, Administrator

1. Klick in der Paketliste auf Neues Paket.

   

2. Füll die Felder aus:

   • Product-ID (Pflicht): nur Kleinbuchstaben, Ziffern, Punkt, Binde- und Unterstrich. Das erste Zeichen muss ein Kleinbuchstabe oder eine Ziffer sein, insgesamt höchstens 128 Zeichen. Beispiel: firefox-esr.
   • Name: Anzeigename. Lässt du ihn leer, übernimmt oPBWeb die Product-ID.
   • Produktversion (Pflicht): Version der Software, vorbelegt aus den Einstellungen (Standard 1.0).
   • Paketversion (Pflicht): Version des Pakets, vorbelegt aus den Einstellungen (Standard 1).

3. Klick auf Anlegen. Solange die Product-ID ungültig ist, bleibt die Schaltfläche deaktiviert.

oPBWeb legt das Paket als Entwurf an und öffnet es im Paket-Editor. Das neue Paket enthält bereits ein setup- und ein uninstall-Script als Vorlage (CLIENT_DATA/setup.opsiscript, CLIENT_DATA/uninstall.opsiscript) und einen leeren Ordner SERVER_DATA/. Priorität, control-Format und Ablage des Changelogs kommen aus den Einstellungen für neue Pakete .

.opsi-Dateien importieren

Rollen: Packager, Releaser, Administrator

Vorhandene Pakete übernimmst du, indem du ihre .opsi-Dateien importierst. Jede importierte Version wird ein Entwurf.

1. Klick auf Importieren. Der Dialog „Pakete importieren“ öffnet sich.

   

2. Zieh eine oder mehrere .opsi-Dateien in das Feld „.opsi-Dateien hierher ziehen oder auswählen“ oder klick auf Dateien auswählen. Andere Dateitypen und doppelt gewählte Dateien werden ignoriert.

3. Optional: Aktivier Vorhandene Entwurfsversion gleicher Nummer überschreiben, wenn eine schon vorhandene Version ersetzt werden soll.

4. Klick auf Import starten.

oPBWeb lädt die Dateien nacheinander hoch und importiert sie. Jede Zeile zeigt den Zustand: „bereit“, „lädt hoch“, „wird importiert“, „importiert“ oder „fehlgeschlagen“. Unter der Liste läuft das Protokoll aller Importe in einem gemeinsamen Feld mit. Solange der Import läuft, ist Schließen deaktiviert.

Beim Import übernimmt oPBWeb die control-Daten und den Changelog in seine Datenbank. Das Format der control-Datei (INI oder TOML) und die Ablage des Changelogs bleiben erhalten. Alte Sicherungen control-*.bak des opsiPackageBuilders übernimmt oPBWeb nicht; das Job-Protokoll nennt ihre Anzahl.

Aus der Workbench importieren

Rollen: Packager, Releaser, Administrator

Liegen Paketquellen als Projektordner in der Workbench eines Configservers, kannst du sie direkt übernehmen – einzeln, mehrere oder alle auf einmal.

1. Klick auf Workbench …. Der Dialog „Import aus der Workbench“ öffnet sich.

2. Wähl oben unter Configserver den Server, dessen Workbench du lesen willst. Die Liste zeigt jeden Server mit Name und Stufe. oPBWeb merkt sich deine Wahl in diesem Browser; ohne frühere Wahl ist der erste Server der Stufe Test vorbelegt, sonst der erste Server. Der Dialog liest die Workbench automatisch ein („Lese Workbench …“), auch nach jedem Wechsel des Servers.

3. Prüf die Tabelle. Sie zeigt die Workbench als Baum: Ordner ohne OPSI-Ordner gelten als Gruppen (fett, mit / am Ende) und lassen sich mit dem Pfeil davor zu- und aufklappen; oPBWeb durchsucht sie bis vier Ebenen tief. Projektordner stehen darunter eingerückt mit Product-ID, Version, Format und Zustand:

   Zustand	Bedeutung
   „neues Paket“	Die Product-ID gibt es in oPBWeb noch nicht.
   „neue Version“	Das Paket gibt es, diese Version noch nicht.
   „Entwurf vorhanden“	Die Version gibt es schon als Entwurf.
   „freigegeben vorhanden“	Die Version gibt es schon und sie ist freigegeben.
   „archiviert“	Das Paket ist archiviert und lässt sich nicht importieren.
   „… · installiert“	Zusatz, wenn genau diese Version auf einem Depot des gewählten Configservers installiert ist (der Tooltip nennt die Depots). Der Import gibt sie frei, siehe Installierte Versionen freigeben .

   Projektordner mit unlesbarer control-Datei zeigen den Grund in der Spalte Format und haben kein Häkchen. Mit dem Filterfeld grenzt du die Liste ein; dann erscheinen nur die passenden Projekte mit ihrem vollen Pfad (zum Beispiel develop/firefox).

4. Setz die Häkchen bei den Projektordnern, die du importieren willst. Das Häkchen im Tabellenkopf wählt alle aus, Alle neuen auswählen wählt alle Ordner, deren Version es in oPBWeb noch nicht gibt.

5. Leg unter Vorhandene Versionen fest, was mit Ordnern geschehen soll, deren Version es schon gibt:

   • „überspringen“ (voreingestellt): Der Ordner wird nicht importiert.
   • „Entwürfe überschreiben“: Ein vorhandener Entwurf wird ersetzt. Freigegebene Versionen werden übersprungen.
   • „als nächste Paketversion importieren“: oPBWeb legt die Version mit der nächsten freien Paketversion an (höchste numerische Paketversion dieser Produktversion + 1).

6. Klick auf Ausgewählte importieren (n).

Der Import läuft als ein einziger Job „Import aus Workbench (Server), Projekte: n“ und arbeitet die Ordner nacheinander ab. Den Fortschritt siehst du als „Importiere … 40 %“. Schließt du den Dialog, läuft der Job trotzdem weiter. Schlägt ein Ordner fehl, macht oPBWeb mit den übrigen weiter.

Danach zeigt jede Zeile ihr Ergebnis: „importiert als 1.0-2“, „übersprungen“ oder „fehlgeschlagen“ (den Grund zeigt der Tooltip). Unten steht eine Zusammenfassung wie „3 importiert, 1 übersprungen, 0 fehlgeschlagen“. Das Job-Protokoll unter Jobs enthält eine Zeile pro Projekt.

Übernommen werden nur die Ordner OPSI, CLIENT_DATA und SERVER_DATA; andere Inhalte der Projektordner bleiben unberührt. Mit Neu einlesen aktualisierst du die Liste. Freigegebene Versionen überschreibt der Import nie.

Installierte Versionen freigeben

Normalerweise wird eine Version erst freigegeben, wenn du sie aus oPBWeb heraus installierst. Ein Projektordner, dessen Version bereits auf einem Depot des gewählten Configservers installiert ist, wurde aber dort schon gebaut und installiert (zum Beispiel mit opsi-makepackage und opsi-package-manager). Solche Versionen gibt der Import direkt frei, statt sie als Entwurf anzulegen:

• Liegt im Projektordner die passende Datei <product-id>_<version>.opsi (zum Beispiel firefox_128.0-1.opsi), übernimmt oPBWeb sie als Build der Version. Die Zeile zeigt danach „importiert als 128.0-1“ und „freigegeben“. oPBWeb prüft nur, dass die Datei dieses Produkt in dieser Version enthält; dass sie mit dem installierten Paket übereinstimmt, kann es nicht nachweisen.
• Fehlt die Datei oder ist sie nicht lesbar, entscheidet die Einstellung Workbench : Die Version bleibt Entwurf („bleibt Entwurf“, Standard), oder oPBWeb baut sie selbst und gibt sie frei („gebaut und freigegeben“).

Welche Depots zählen, bestimmt der letzte Depot-Abgleich des Configservers. Das Repository eines Depots spielt keine Rolle: opsi-package-manager -i legt ein Paket dort nur mit der Option -d ab.

Entwürfe, die schon vor dieser Prüfung importiert wurden oder bei denen die Einstellung inzwischen anders lautet, holst du mit Mit Depots abgleichen (n) nach. Die Schaltfläche fasst alle sichtbaren Zeilen mit „Entwurf vorhanden · installiert“ zusammen und startet den Job „Workbench mit Depots abgleichen (Server), Projekte: n“. Er importiert nichts erneut, sondern übernimmt nur die .opsi-Datei aus dem Projektordner beziehungsweise baut die Version gemäß Einstellung und gibt sie frei. Jede Zeile zeigt danach „freigegeben“, „gebaut und freigegeben“, „bleibt Entwurf“ oder „übersprungen“ (Tooltip mit Grund, etwa wenn die Version inzwischen kein Entwurf mehr ist). Die Freigabe steht im Protokoll als version.released mit den Depots und der Herkunft des Builds.

Ordner ignorieren

Enthält die Workbench Ordner, deren Inhalt oPBWeb nicht kennen soll (zum Beispiel to_review oder develop/deprecated mit Altpaketen), klick in der Zeile des Ordners rechts auf Ignorieren. Das geht für Gruppen- und für Projektordner. Der Ordner bleibt ausgegraut und zugeklappt mit der Markierung „ignoriert“ in der Liste; sein Inhalt verschwindet aus der Tabelle und aus dem Abschnitt Workbench der Paketansicht.

Die Liste der ignorierten Ordner gilt je Configserver und für jedes Einlesen: im Dialog, zeitgesteuert und beim Depot-Abgleich. Mit Wieder berücksichtigen nimmst du einen Ordner wieder auf; der Dialog liest die Workbench dann neu ein. Beide Schritte stehen im Protokoll .

Einzelne Ordner kannst du auch unter Depots im Reiter Dateien mit In oPBWeb importieren übernehmen, siehe Depots . Wurde eine importierte Version später direkt auf der Workbench geändert, holst du die Änderungen mit Mit Workbench abgleichen … im Paket-Editor nach, siehe Paket-Editor .

Übergabe vom opsi-setup-detector

Rollen: Packager, Releaser, Administrator

Der opsi-setup-detector kann nach dem Erzeugen der Produktdateien den alten opsiPackageBuilder starten. Mit dem Launcher von oPBWeb öffnet sich an dieser Stelle stattdessen oPBWeb im Browser und fragt, ob du den neuen Workbench-Ordner importieren willst.

Du kannst den Launcher von Hand einrichten (nächster Abschnitt) oder als opsi-Paket über deine Depots verteilen, siehe Launcher als opsi-Paket verteilen .

Launcher von Hand einrichten

1. Lade den Launcher für dein System herunter: im Dialog „Import aus der Workbench“ über Launcher für den opsi-setup-detector herunterladen oder direkt unter /downloads/ deiner oPBWeb-Adresse. Es gibt je eine ZIP-Datei für Windows, macOS und Linux (amd64 und arm64).

2. Entpack die Datei. Sie heißt opsipackagebuilder.exe (Windows) bzw. opsipackagebuilder. Den Namen darfst du nicht ändern, der opsi-setup-detector akzeptiert nur diesen.

3. Leg sie an einen Ort, an dem der opsi-setup-detector sie findet, oder trag den Pfad in dessen Konfiguration unter PathToOpsiPackageBuilder ein:

   System	Standardpfad
   Windows	C:\Program Files (x86)\opsi PackageBuilderNG\opsipackagebuilder.exe
   macOS	/Applications/opsiPackageBuilder.app/Contents/MacOS/opsipackagebuilder
   Linux	/usr/bin/opsipackagebuilder

4. Hinterleg einmalig die Adresse von oPBWeb:

   opsipackagebuilder --set-url https://opbweb.example.org
   

   Alternativ legst du neben dem Launcher eine Datei opb-launcher.conf mit der Zeile url = https://opbweb.example.org an (gilt dann für alle Benutzer des Rechners) oder setzt die Umgebungsvariable OPBWEB_URL.

5. Arbeitet der opsi-setup-detector mit einem verbundenen Laufwerk (zum Beispiel W:\) statt mit einem UNC-Pfad, hinterleg zusätzlich den Configserver dieser Workbench:

   opsipackagebuilder --set-server opsi-test.example.org
   

   Alternativ trägst du in opb-launcher.conf die Zeile server = opsi-test.example.org ein oder setzt die Umgebungsvariable OPBWEB_SERVER.

Der opsi-setup-detector und oPBWeb müssen dieselbe Workbench verwenden: Der opsi-setup-detector schreibt in die Workbench-Freigabe eines Configservers, und dieser Server muss in oPBWeb eingerichtet sein. Der Projektordner darf in Gruppenordnern liegen (\\opsi-test.example.org\opsi_workbench\develop\firefox ergibt develop/firefox); zeigt die Freigabe nicht auf die Workbench selbst, sucht oPBWeb den Ordner anhand des Pfadendes. Der Launcher teilt oPBWeb mit, um welchen Configserver es geht: Bei einem UNC-Pfad wie \\opsi-test.example.org\opsi_workbench\firefox ist es der Hostname aus dem Pfad, sonst der mit --set-server hinterlegte Server.

Launcher als opsi-Paket verteilen

Laufen die Rechner mit dem opsi-setup-detector selbst als opsi-Clients, verteilst du den Launcher am einfachsten als opsi-Produkt. oPBWeb bringt das Paket opb-launcher fertig mit: ein Localboot-Produkt für Windows, Linux und macOS (amd64 und arm64), dessen Produktversion der Launcher-Version entspricht.

1. Klick im Dialog „Import aus der Workbench“ unten auf Launcher als opsi-Paket anlegen ….
2. Unter Adresse von oPBWeb steht die Adresse, unter der du oPBWeb gerade aufrufst. Sie wird Standardwert der Property url. Ändere sie, wenn deine Anwender oPBWeb unter einer anderen Adresse erreichen.
3. Configserver für Workbench-Pfade ohne Hostnamen brauchst du nur, wenn der opsi-setup-detector mit einem verbundenen Laufwerk statt einem UNC-Pfad arbeitet. Der Wert wird Standardwert der Property server; die Hostnamen deiner Configserver werden vorgeschlagen.
4. Klick auf Paket anlegen. Gibt es das Paket schon, bietet der Dialog wie bei der Übergabe Neue Version anlegen, Als … anlegen (nächste freie Paketversion) oder Entwurf überschreiben an.
5. Das Paket entsteht als Entwurf und öffnet sich im Editor. Baue es und installiere es auf deine Depots, siehe Paket-Editor und Depots . Danach setzt du es auf den Rechnern mit dem opsi-setup-detector auf setup.

Das Paket legt den Launcher dort ab, wo der opsi-setup-detector den alten opsiPackageBuilder sucht (Tabelle oben), und schreibt opb-launcher.conf mit url und server daneben. Unter Linux liegt der Launcher in /opt/opb-launcher/, /usr/bin/opsipackagebuilder ist ein Link darauf.

Das Paket hat die Abhängigkeiten uninstall/before auf die Produkte opsipackagebuilder und opsipackagebuilder_wlm: Ist eines davon über opsi installiert, wird es vorher deinstalliert. Fehlt ein Produkt auf dem Depot, ignoriert opsi die Abhängigkeit.

Bei der Deinstallation entfernt das Paket nur den Launcher und seine Konfigurationsdatei; Ordner werden nur gelöscht, wenn sie leer sind.

Übergabe nutzen

1. Wähl im opsi-setup-detector als Modus create opsi product files and start the interactive PackageBuilder und erzeuge das Produkt.

2. oPBWeb öffnet sich im Browser. Bist du nicht angemeldet, meldest du dich zuerst an.

3. Der Dialog „Übergabe vom opsi-setup-detector“ liest den Workbench-Ordner. Sind mehrere Configserver eingerichtet, ist unter Configserver der Server vorgewählt, den der Launcher übergeben hat (Hostname oder Kurzname). Kennt oPBWeb diesen Server nicht, erscheint ein Hinweis und vorbelegt ist der zuletzt gewählte; dann wählst du den passenden Server aus. Danach fragt der Dialog je nach Lage:

   Lage	Auswahl
   Das Paket gibt es in oPBWeb noch nicht	Importieren oder Abbrechen
   Das Paket gibt es, die Version noch nicht	Neue Version anlegen oder Abbrechen
   Die Version gibt es schon	Als … anlegen (nächste freie Paketversion, zum Beispiel 1.0-3 statt 1.0-2), Entwurf überschreiben (nur wenn die vorhandene Version ein Entwurf ist) oder Abbrechen
   Das Paket ist archiviert	nur Abbrechen; stell das Paket erst wieder her

4. Nach dem Import öffnet sich die neue Version im Editor.

Die Modi Bauen und Bauen + Installieren des opsi-setup-detectors brauchen den Launcher nicht: Ab opsi 4.2.0.311 baut der opsi-setup-detector dann direkt über den opsi-Service. Ruft er den Launcher trotzdem zum Bauen auf, meldet der Launcher einen Fehler, denn oPBWeb baut nicht über die Kommandozeile.

In diesen Modi erfährt oPBWeb nichts vom neuen Paket. Importiere es danach über Workbench … oder im Dateimanager der Depots mit In oPBWeb importieren. Der regelmäßige Workbench-Scan des Workers importiert nicht, er merkt sich nur, welche Projektordner es gibt.

Meta-Paket anlegen

Rollen: Packager, Releaser, Administrator

Ein Meta-Paket installiert eine Reihe anderer Produkte. Es enthält selbst kein Programm, sondern nur Abhängigkeiten: Jedes gewählte Produkt wird zur Abhängigkeit „setup, installiert, vorher“. Das Script des Meta-Pakets tut nichts.

1. Klick auf Meta-Paket …. Der Dialog „Neues Meta-Paket“ öffnet sich.

   

2. Füll links die Felder aus:

   • Product-ID: vorbelegt mit dem Präfix aus den Einstellungen (Standard meta-). Es gelten dieselben Regeln wie bei einem neuen Paket.
   • Name, Beschreibung: optional.
   • Produktversion, Paketversion: vorbelegt aus den Einstellungen.

3. Wähl rechts die Produkte aus. Mit „Produkte filtern …“ grenzt du die Liste ein. Zur Auswahl stehen alle Pakete in oPBWeb und alle Produkte, die auf den Depots gefunden wurden; Produkte, die es nur auf einem Depot gibt, sind mit „nur im Depot“ markiert.

4. Bring die Produkte unter Reihenfolge mit ↑ und ↓ in die gewünschte Installationsreihenfolge. Mit × entfernst du ein Produkt aus der Auswahl.

5. Klick auf Anlegen. Die Schaltfläche ist aktiv, sobald die Product-ID gültig ist und mindestens ein Produkt gewählt ist.

oPBWeb öffnet das neue Meta-Paket im Editor. Es bekommt die Priorität und den Namen des Setup-Scripts aus den Einstellungen (Standard: Priorität −100, Script dummy.opsiscript) und kein uninstall-Script. Ein Meta-Paket kann sich nicht selbst enthalten; maximal sind 200 Produkte möglich.

Version löschen

Rollen: Packager, Releaser, Administrator

Eine einzelne Version löschst du im Paket-Editor:

1. Öffne die Version im Paket-Editor und wähl den Abschnitt Produkt.
2. Klick unten auf Diese Version löschen.
3. Bestätige die Rückfrage „Version … endgültig löschen?“.

Das Löschen ist auch bei freigegebenen Versionen möglich und lässt sich nicht rückgängig machen. Ist die Version auf einem Produktions-Depot installiert, darf sie nur ein Releaser löschen (siehe Stufenregel ). Die gebaute .opsi-Datei der Version wird mit gelöscht. Ist es die letzte Version, verschwindet das ganze Paket aus der Liste. Danach öffnet oPBWeb eine andere Version des Pakets oder die Paketliste.

Paket archivieren

Rollen: Packager, Releaser, Administrator

Ein Paket, das du nicht mehr brauchst, aber behalten willst, archivierst du:

1. Wähl das Paket in der Paketliste aus.
2. Klick in den Details unter Paket auf Archivieren.
3. Bestätige die Rückfrage „… archivieren? Das Paket verschwindet aus der Liste und wird schreibgeschützt, die gebauten .opsi-Dateien werden gelöscht.“

Ein archiviertes Paket

• erscheint nur noch unter dem Filter Archiv und nicht in der Suche,
• ist schreibgeschützt: Du kannst es im Editor ansehen, aber nicht bearbeiten, bauen, keine neue Version anlegen und keine Version löschen; auch ein Import in das Paket wird abgelehnt,
• hat keine Build-Ergebnisse mehr und lässt sich deshalb nicht installieren.

Laufen für das Paket noch Jobs oder warten welche, lehnt oPBWeb das Archivieren ab. Auf den Depots installierte Produkte bleiben erhalten; du kannst sie in den Details weiterhin mit Deinstallieren … entfernen.

Zum Zurückholen wählst du das Paket unter Archiv aus und klickst auf Wiederherstellen. Die Versionen behalten ihren Status. Vor dem nächsten Installieren musst du das Paket neu bauen.

Paket löschen

Rollen: Packager, Releaser, Administrator

Ein ganzes Paket mit allen Versionen löschst du in der Paketliste, auch wenn es archiviert ist:

1. Wähl das Paket aus.
2. Klick in den Details unter Paket auf Paket löschen ….
3. Gib zur Bestätigung die Product-ID ein und klick auf Endgültig löschen. Die Schaltfläche ist erst aktiv, wenn die Eingabe genau stimmt.

Gelöscht werden alle Versionen, ihre Dateien und Build-Ergebnisse. Das lässt sich nicht rückgängig machen. Ist irgendeine Version des Produkts auf einem Produktions-Depot installiert, darf nur ein Releaser das Paket löschen.