Fachliche Administration
Benutzer, Rollen, Configserver, Depots und Einstellungen in der Oberfläche
Rolle: Administrator
Überblick
Dieser Teil richtet sich an Administratoren, die oPBWeb in der Oberfläche einrichten und pflegen. Alles, was hier beschrieben ist, erledigst du im Browser, ohne Zugriff auf den Server oder die Docker-Umgebung. Wie du den Stack installierst, konfigurierst und sicherst, steht in der Technischen Administration
.
Als Administrator hast du alle Rechte der anderen Rollen. Zusätzlich siehst du in der Aktivitätsleiste unten die Bereiche Benutzer und Rollen und Einstellungen und bekommst in Systemstatus und Depots weitere Funktionen, etwa die Verwaltung der Configserver.
Aufgaben im Überblick
| Aufgabe | Wo in der Oberfläche | Kapitel |
|---|
| Konten anlegen, Rollen vergeben, Konten sperren oder löschen | Benutzer und Rollen › Benutzer | Benutzer und Rollen |
| Nachvollziehen, wer was wann geändert hat | Benutzer und Rollen › Protokoll | Protokoll |
| opsi-Configserver hinzufügen, Stufe festlegen, CA-Zertifikat pflegen, Configserver entfernen | Depots › + bzw. Configserver-Zeile | Configserver |
| Vorgaben für neue Pakete und Meta-Pakete festlegen | Einstellungen | Einstellungen für neue Pakete |
| Vorgaben für den Assistenten „Neues Paket aus Installer“ festlegen | Einstellungen › opsi-setup-detector | Einstellungen für neue Pakete |
| Script-Vorlagen des Assistenten ändern, ergänzen, importieren | Vorlagen | Vorlagen für den Installer-Assistenten |
| Depots den Stufen Test, Staging und Produktion zuordnen, deaktivieren oder entfernen | Depots › Einstellungen | Depot-Verwaltung |
| Dienste überwachen, Speicherbelegung prüfen, Objektspeicher bereinigen | Systemstatus | Systemstatus |
Bei der ersten Inbetriebnahme gehst du diese Punkte in einer festen Reihenfolge durch. Die Schritte dafür stehen in der Ersteinrichtung
.
Hinweis
Die Oberfläche blendet Funktionen aus, die deine Rolle nicht erlaubt. Die eigentliche Prüfung macht aber der Server: Auch wer eine Adresse wie /users direkt aufruft, landet ohne Administratorrolle wieder auf der Paketliste.
Benutzer und Rollen
Rollen und Rechte, lokale Konten anlegen und pflegen, Verzeichniskonten aus LDAP
Rolle: Administrator
Überblick
Unter Benutzer und Rollen verwaltest du alle Konten, die sich an oPBWeb anmelden können. Jedes Konto hat genau eine Rolle, die festlegt, was es in der Oberfläche darf. Neben lokalen Konten, die du selbst anlegst, gibt es Verzeichniskonten aus LDAP, deren Rolle sich aus den Gruppen im Verzeichnis ergibt.
Den Bereich öffnest du über das Symbol Benutzer und Rollen unten in der Aktivitätsleiste. Er hat zwei Reiter: Benutzer (mit der Anzahl der Konten) und Protokoll. Das Protokoll ist im Kapitel Protokoll
beschrieben.
Rollen und Rechte
Es gibt vier Rollen. Sie bauen aufeinander auf: Jede Rolle hat alle Rechte der Rollen darüber und bringt eigene dazu.
| Rolle | Kurzbeschreibung in der Oberfläche |
|---|
| Leser | nur lesen |
| Packager | Pakete bearbeiten, bauen, auf Test-Depots installieren |
| Releaser | zusätzlich auf produktive Depots verteilen |
| Administrator | zusätzlich Benutzer, Server und Einstellungen |
Die Oberfläche blendet Schaltflächen aus oder deaktiviert sie, wenn die Rolle nicht reicht. Geprüft wird jedes Recht trotzdem auf dem Server. Fehlt ein Recht, erscheint „Keine Berechtigung für diese Aktion.“
Leser
- Paketliste und Paketdetails ansehen, den Paket-Editor schreibgeschützt öffnen, Quelltext des control ansehen
- gebaute
.opsi- und .md5-Dateien herunterladen - Snippets lesen
- alle Jobs mit Live-Protokoll verfolgen, eigene wartende Jobs abbrechen
- Depots ansehen und Dateien von dort herunterladen
- im Systemstatus die Tabelle der Dienste sehen
- eigene Standardsprache setzen, eigenes Passwort ändern (nur lokale Konten)
Packager
- Pakete anlegen: Neues Paket, Importieren, Workbench …, Meta-Paket …
- Entwürfe bearbeiten und Bauen, Neue Version anlegen, Dateien im Paket anlegen, hochladen, umbenennen und löschen
- Pakete Archivieren und Wiederherstellen
- Diese Version löschen, Zurück auf Entwurf und Paket löschen …, solange das Paket bzw. die Version auf keinem Produktions-Depot installiert ist (siehe Stufenregel
)
- Mit Workbench abgleichen …, In Workbench exportieren …, in
/workbench jedes Configservers schreiben und In oPBWeb importieren - Depots Abgleichen und Repository lesen
- auf Test- und Staging-Depots: Installieren …, Deinstallieren …, Übernehmen … bzw. Auf andere Stufe übernehmen …, Produkte Entsperren, Repository-Dateien löschen
- eigene Snippets und Snippet-Kategorien pflegen
Releaser
- alle Depot-Aktionen des Packagers (Installieren, Deinstallieren, Übernehmen, Entsperren, Repository löschen) auch auf Produktions-Depots
- Versionen und Pakete löschen und Versionen auf Entwurf zurücksetzen, auch wenn sie auf einem Produktions-Depot installiert sind
Administrator
- Bereiche Benutzer und Rollen (inklusive Protokoll) und Einstellungen
- Configserver unter Depots hinzufügen, ändern und entfernen
- Depot-Einstellungen (Stufe, Dienst-URL, Aktiv) und Entfernen von Depots
- globale Snippets pflegen
- wartende Jobs anderer Benutzer abbrechen
- im Systemstatus die Bereiche Datenbank, Objektspeicher, Bereinigen … und Bucket-Inhalt
Die Stufenregel für Depots
Was ein Packager mit einem Paket auf einem Depot tun darf, hängt von der Stufe des Depots ab, nicht nur von seiner Rolle. Die Tabelle zeigt, wer welche Aktion auf welcher Stufe ausführen darf:
| Aktion | Test | Staging | Produktion |
|---|
| Installieren … (auch mit Setup) | ab Packager | ab Packager | ab Releaser |
| Deinstallieren … | ab Packager | ab Packager | ab Releaser |
| Übernehmen … / Auf andere Stufe übernehmen … (Zieldepots) | ab Packager | ab Packager | ab Releaser |
| Produkte Entsperren | ab Packager | ab Packager | ab Releaser |
| Repository-Dateien löschen | ab Packager | ab Packager | ab Releaser |
| Version löschen, Zurück auf Entwurf, Paket löschen …, wenn dort installiert | ab Packager | ab Packager | ab Releaser |
| Depots Abgleichen, Repository lesen | ab Packager | ab Packager | ab Packager |
| Depot ansehen, Dateien herunterladen | ab Leser | ab Leser | ab Leser |
| Stufe, Dienst-URL, Aktiv des Depots ändern | Administrator | Administrator | Administrator |
Für das Löschen und für Zurück auf Entwurf zählt, wo das Paket gerade installiert ist: Liegt die Version (bzw. beim Löschen des Pakets irgendeine Version) auf einem Produktions-Depot, braucht es die Rolle Releaser. Ein Packager bekommt dann die Meldung, auf welchen Depots das Paket installiert ist. Grundlage ist der Stand des letzten Depot-Abgleichs.
Depots erben die Stufe ihres Configservers, solange du ihnen keine eigene gibst. Neue Configserver starten in der Stufe Produktion. Ein Packager kann auf ihren Depots also erst installieren, wenn du den Configserver oder das einzelne Depot auf Test oder Staging stellst. Im Dialog Installieren … erscheint ein gesperrtes Depot mit dem Hinweis „erfordert Rolle Releaser“. Wie du die Stufe änderst, steht in der Depot-Verwaltung
.
Hinweis
Die Workbench eines Configservers gehört nicht zur Stufenregel: Packager dürfen in /workbench jedes Configservers schreiben, auch auf Produktions-Servern.
Die Benutzerliste
Der Reiter Benutzer zeigt alle Konten in einer Tabelle. Rechts daneben öffnet sich der Bereich Benutzerdetails für das ausgewählte Konto.

| Spalte | Bedeutung |
|---|
| Benutzername | Anmeldename des Kontos |
| Name | Anzeigename |
| Rolle | Rolle als farbiges Abzeichen |
| Herkunft | lokal (in oPBWeb angelegt) oder Verzeichnis (LDAP) |
| Status | aktiv, deaktiviert oder gesperrt (nach zu vielen Fehlversuchen) |
| Letzte Anmeldung | Zeitpunkt der letzten erfolgreichen Anmeldung |
Unter den Feldern der Benutzerdetails stehen zusätzlich Herkunft, Angelegt und Letzte Anmeldung.
Lokale Konten
Lokale Konten melden sich mit einem Passwort an, das oPBWeb selbst speichert. Das erste Administratorkonto (admin) entsteht beim ersten Start des Systems; alle weiteren lokalen Konten legst du hier an.
Konto anlegen
Klick in der Werkzeugleiste auf Neuer Benutzer.

Trag den Benutzernamen ein. Erlaubt sind 2 bis 128 Zeichen aus Buchstaben, Ziffern und . _ @ -.
Wähl die Rolle. Der Dialog schlägt Leser vor, die Rolle mit den wenigsten Rechten.
Trag optional Name und E-Mail ein. Die E-Mail-Adresse erscheint in Changelog-Einträgen dieses Benutzers.
Wähl die Standardsprache (Deutsch oder English). Mit dieser Sprache startet die Oberfläche nach jeder Anmeldung.
Vergib im Feld Neues Passwort ein Startpasswort mit mindestens 10 Zeichen.
Klick auf Anlegen.
Das neue Konto erscheint in der Liste und ist sofort ausgewählt. Gib dem Benutzer das Startpasswort auf sicherem Weg weiter; er kann es danach im Avatar-Menü unter Passwort ändern selbst ersetzen.
Hinweis
Ist der Benutzername schon vergeben, meldet der Dialog „Benutzername ist bereits vergeben.“ Das gilt auch für Namen von Verzeichniskonten, die sich schon einmal angemeldet haben.
Konto bearbeiten
- Wähl das Konto in der Liste aus.
- Ändere in den Benutzerdetails Name, E-Mail, Rolle oder Standardsprache.
- Klick auf Speichern. In der Werkzeugleiste erscheint „Gespeichert“.
Die Standardsprache kann jeder Benutzer auch selbst im Avatar-Menü ändern (siehe Konto und Sprache
).
Konto deaktivieren
Ein deaktiviertes Konto bleibt mit allen Angaben erhalten, kann sich aber nicht mehr anmelden. Die Anmeldung scheitert mit „Konto ist deaktiviert.“
- Wähl das Konto aus.
- Entferne das Häkchen bei Konto ist aktiv.
- Klick auf Speichern.
Zum Reaktivieren setzt du das Häkchen wieder und speicherst.
Passwort setzen
Wenn ein Benutzer sein Passwort vergessen hat, vergibst du ein neues:
- Wähl das Konto aus und klick auf Passwort setzen.
- Gib das neue Passwort zweimal ein (mindestens 10 Zeichen).
- Bestätige den Dialog. In der Werkzeugleiste erscheint „Passwort gesetzt“.
Das alte Passwort brauchst du dafür nicht. Das Setzen hebt gleichzeitig eine bestehende Sperre auf.
Sperre aufheben
Nach 5 falschen Passwörtern in Folge sperrt oPBWeb ein lokales Konto für 15 Minuten. Während der Sperre lautet die Meldung bei der Anmeldung „Konto gesperrt bis HH:MM Uhr.“, auch wenn das Passwort stimmt. In der Liste steht das Konto auf gesperrt.
Du musst nicht warten, bis die Sperre abläuft:
- Wähl das gesperrte Konto aus.
- Klick auf Sperre aufheben. Die Schaltfläche erscheint nur bei gesperrten Konten.
Der Benutzer kann sich sofort wieder anmelden. Hat er sein Passwort tatsächlich vergessen, nimm stattdessen Passwort setzen.
Konto löschen
- Wähl das Konto aus.
- Klick auf Benutzer löschen.
- Bestätige die Rückfrage „Benutzer löschen?“ mit Benutzer löschen.
Das Konto wird endgültig entfernt. Einträge im Protokoll
bleiben mit dem Benutzernamen erhalten. Dein eigenes Konto kannst du nicht löschen; die Schaltfläche ist dafür deaktiviert.
Tipp
Wenn du nicht sicher bist, ob ein Konto später noch gebraucht wird, deaktiviere es lieber. Ein deaktiviertes Konto lässt sich jederzeit wieder einschalten.
Schutz des letzten Administrators
oPBWeb verhindert, dass niemand mehr die Administration erreichen kann. Für das letzte aktive Administratorkonto gilt:
- Du kannst ihm keine niedrigere Rolle geben und es nicht deaktivieren. Die Meldung lautet „Der letzte aktive Administrator kann nicht entfernt werden.“
- Du kannst es nicht löschen: „Der letzte aktive Administrator kann nicht gelöscht werden.“
Leg deshalb zuerst ein zweites Administratorkonto an, bevor du das bisherige herabstufst oder entfernst.
Verzeichniskonten (LDAP)
Wenn die technische Administration die LDAP-Anmeldung eingeschaltet hat, können sich auch Benutzer aus dem Verzeichnis (zum Beispiel Active Directory) anmelden. Diese Konten erkennst du an der Herkunft Verzeichnis (LDAP). Die Einrichtung ist in LDAP-Anmeldung
beschrieben.
Für Verzeichniskonten gelten andere Regeln als für lokale Konten:
- Anlegen: Du legst sie nicht selbst an. Das Konto entsteht automatisch bei der ersten erfolgreichen Anmeldung.
- Rolle: Die Rolle ergibt sich bei jeder Anmeldung aus den LDAP-Gruppen des Benutzers. Ist er in mehreren passenden Gruppen, gilt die höchste Rolle. Das Feld Rolle ist gesperrt, darunter steht „Die Rolle von Verzeichniskonten ergibt sich bei jeder Anmeldung aus den LDAP-Gruppen.“ Um die Rolle zu ändern, änderst du die Gruppenmitgliedschaft im Verzeichnis.
- Name und E-Mail: Diese Angaben übernimmt oPBWeb bei jeder Anmeldung aus dem Verzeichnis. Änderungen, die du hier speicherst, werden bei der nächsten Anmeldung überschrieben.
- Passwort: Verzeichniskonten haben kein Passwort in oPBWeb. Passwort setzen fehlt, und der Benutzer ändert sein Passwort im Verzeichnis. Auch die Sperre nach Fehlversuchen gilt nur für lokale Konten.
- Deaktivieren: Funktioniert wie bei lokalen Konten. Ein deaktiviertes Verzeichniskonto kann sich nicht mehr anmelden, auch wenn es im Verzeichnis noch berechtigt ist.
- Löschen: Ein gelöschtes Verzeichniskonto entsteht bei der nächsten Anmeldung neu, solange der Benutzer noch in einer passenden Gruppe ist. Um jemanden dauerhaft auszuschließen, deaktiviere das Konto oder entferne ihn aus den Gruppen.
Hinweis
Ist ein Benutzer im Verzeichnis in keiner der für oPBWeb eingetragenen Gruppen, scheitert die Anmeldung mit „Keine Berechtigung für oPBWeb (keine passende Gruppe).“ In der Benutzerliste taucht er dann gar nicht auf.
Lokale Konten melden sich immer lokal an, auch wenn LDAP eingeschaltet ist. Der lokale Administrator admin bleibt so auch dann erreichbar, wenn das Verzeichnis ausfällt.
Protokoll
Im Protokoll nachvollziehen, wer wann welche Aktion ausgelöst hat
Rolle: Administrator
Überblick
Das Protokoll hält fest, wer wann welche wichtige Aktion in oPBWeb ausgelöst hat: Anmeldungen, Änderungen an Konten, Paketen, Depots und Einstellungen. Du findest es unter Benutzer und Rollen im Reiter Protokoll. Nur Administratoren können es lesen.
Einträge lassen sich in der Oberfläche weder ändern noch löschen. Auch wenn du ein Benutzerkonto löschst, bleiben seine Einträge mit dem Benutzernamen erhalten.
Das Protokoll lesen

Die neuesten Einträge stehen oben. Jede Zeile hat diese Spalten:
| Spalte | Inhalt |
|---|
| Zeitpunkt | Datum und Uhrzeit der Aktion |
| Benutzername | Wer die Aktion ausgelöst hat. Bei fehlgeschlagenen Anmeldungen der eingegebene Name. |
| Aktion | Technischer Schlüssel der Aktion, zum Beispiel user.created (siehe Liste der Aktionen
) |
| Objekt | Art und Kennung des betroffenen Objekts, zum Beispiel depot depot01.example.local |
| Details | Zusätzliche Angaben im JSON-Format, zum Beispiel die geänderten Felder oder der Grund einer abgelehnten Anmeldung |
| IP | IP-Adresse, von der die Anfrage kam |
Über der Tabelle siehst du, wie viele Einträge angezeigt werden, etwa „100 von 2.345 Einträgen“. Es werden jeweils 100 Einträge geladen. Mit Weitere laden unter der Tabelle holst du die nächsten 100.
Hinweis
Aktionsschlüssel und Details erscheinen immer so, wie oPBWeb sie speichert, also auf Englisch und unabhängig von der eingestellten Sprache.
Einträge filtern
- Trag im Feld Aktion den Anfang eines Aktionsschlüssels ein.
user. findet alle Aktionen an Benutzerkonten, auth.login_failed nur die fehlgeschlagenen Anmeldungen. - Trag im Feld Benutzername einen Benutzernamen ein. Hier muss der Name vollständig und genau stimmen.
- Klick auf Filtern.
Du kannst beide Felder kombinieren. Um alle Einträge wieder zu sehen, leere die Felder und klick erneut auf Filtern.
Aufgezeichnete Aktionen
| Aktion | Wann sie entsteht |
|---|
auth.login | erfolgreiche Anmeldung |
auth.login_failed | abgelehnte Anmeldung (Grund in Details) |
auth.logout | Abmeldung |
auth.password_changed | Benutzer ändert sein eigenes Passwort |
user.created | Konto angelegt |
user.updated | Konto bearbeitet (Name, E-Mail, Rolle, Sprache, aktiv) |
user.password_set | Administrator setzt ein Passwort |
user.unlocked | Administrator hebt eine Sperre auf |
user.deleted | Konto gelöscht |
package.created | neues Paket oder Meta-Paket angelegt |
package.deleted | ganzes Paket gelöscht (Paket löschen …) |
package.archived | Paket archiviert; Details nennt die Zahl der gelöschten Build-Ergebnisse |
package.restored | archiviertes Paket wiederhergestellt |
package.import_started | Import einer .opsi-Datei gestartet |
package.install_started | Installation auf Depots gestartet |
package.uninstall_started | Deinstallation auf Depots gestartet |
version.updated | Produktdaten einer Version gespeichert |
version.properties | Properties gespeichert |
version.dependencies | Abhängigkeiten gespeichert |
version.files_uploaded | Dateien ins Paket hochgeladen |
version.build_started | Bauen gestartet |
version.released | Version freigegeben (beim Start der Installation) |
version.reopened | Zurück auf Entwurf |
version.copied | Neue Version angelegt |
version.deleted | Version gelöscht |
depot.updated | Depot-Einstellungen geändert (Stufe, Dienst-URL, Aktiv) |
depot.deleted | Depot aus oPBWeb entfernt |
depot.unlock | Produkte auf einem Depot entsperrt |
depot.repository_delete | Dateien aus dem Repository eines Depots gelöscht |
files.written | Datei auf dem Server gespeichert (Depots › Dateien) |
files.mkdir | Ordner auf dem Server angelegt |
files.moved | Datei oder Ordner auf dem Server umbenannt |
files.deleted | Datei oder Ordner auf dem Server gelöscht |
files.upload_started | Upload auf den Server gestartet |
workbench.import_started | Import aus der Workbench gestartet |
workbench.export_started | Export in die Workbench gestartet |
workbench.ignored | Workbench-Ordner wird bei Scans ignoriert (Server und Ordner in den Details) |
workbench.unignored | Workbench-Ordner wird wieder berücksichtigt |
snippets.imported | Snippets importiert |
detector.analyze_started | Analyse eines Installers gestartet (Assistent Aus Installer … oder Installer analysieren im Dateibaum) |
detector.create_started | Erzeugen eines Pakets im Assistenten gestartet (Product-ID, Version, Art und Kanal in Details) |
detector.template_created | Vorlage angelegt |
detector.template_uploaded | Vorlage hochgeladen oder per Upload ersetzt |
detector.template_updated | Vorlage gespeichert oder umbenannt |
detector.template_reset | Vorlage zurückgesetzt oder wiederhergestellt |
detector.template_deleted | Vorlage gelöscht |
detector.templates_imported | Vorlagen aus einem ZIP importiert (Zahlen in Details) |
settings.updated | Einstellungen geändert (geänderte Schlüssel in Details) |
opsi_server.created | Configserver hinzugefügt |
opsi_server.updated | Verbindungsdaten oder Stufe eines Configservers geändert |
opsi_server.deleted | Configserver mit Entfernen … entfernt |
opsi_server.ca_accepted | Neues Zertifikat übernehmen nach einer CA-Rotation |
storage.cleanup | Bereinigung des Objektspeichers bestätigt (nur der Löschlauf, nicht der Probelauf) |
Bei Aktionen, die einen Job starten (…_started), zeigt das Protokoll nur, wer den Job gestartet hat. Ob er erfolgreich war, siehst du unter Jobs
.
Was nicht aufgezeichnet wird
Einige Aktionen erscheinen bewusst nicht im Protokoll:
- neue Changelog-Einträge
- Speichern von Dateiinhalten im Paket (Scripteditor)
- Anlegen, Verschieben, Umbenennen und Löschen von Dateien und Ordnern im Paket
- Anlegen, Ändern und Löschen einzelner Snippets und Snippet-Kategorien
- Depot-Abgleich
- Lesen des Repositorys und Einlesen der Workbench
- Vom Server holen (CA-Zertifikat) und Verbindung testen
- der Probelauf beim Bereinigen des Objektspeichers
Für viele dieser Aktionen gibt es trotzdem eine Spur: Alles, was als Job läuft, steht mit Auslöser und Log in der Jobliste.
Configserver
opsi-Configserver in der Ansicht Depots anlegen, Stufe festlegen, CA-Zertifikat pflegen und die Verbindung prüfen
Rolle: Administrator
Überblick
oPBWeb arbeitet mit beliebig vielen opsi-Configservern, zum Beispiel einem Test-, einem Staging- und einem Produktivsystem. Über jeden Configserver liest oPBWeb dessen Depots, installiert Pakete und greift auf /repository, /workbench und /depot zu. Jedes Depot gehört zu genau einem Configserver.
Die Configserver verwaltest du in der Ansicht Depots in der Aktivitätsleiste. Solange kein Configserver eingerichtet ist, funktionieren Depots, Installieren und die Workbench nicht, und die Statusleiste zeigt „Kein Configserver eingerichtet“.

Configserver in der Depot-Liste
Die linke Liste der Ansicht Depots ist nach Configservern gegliedert. Jeder Configserver steht als fett gedruckte Zeile, darunter eingerückt seine Depots. Der Pfeil vor dem Namen klappt die Depots eines Servers zu oder auf, das Feld „Depot suchen“ darüber durchsucht die Liste (siehe Depots
).
| Element | Bedeutung |
|---|
| Punkt vor dem Namen | grün: letzte Prüfung in Ordnung, rot: letzte Prüfung fehlgeschlagen, grau: noch nicht geprüft |
| Abzeichen | Stufe des Configservers (Produktion, Staging oder Test) |
| zweite Zeile | „Configserver · 3 Depots“ |
Im Kopf der Liste stehen zwei Schaltflächen:
- + („Neuer Configserver“) legt einen weiteren Configserver an. Nur Administratoren sehen sie.
- ⟳ („Alle Configserver abgleichen“) gleicht die Depots aller Configserver ab. Die Schaltfläche gibt es ab der Rolle Packager.
Ein Klick auf eine Configserver-Zeile öffnet rechts das Formular des Servers. Neben der Überschrift stehen das Stufen-Abzeichen und das Ergebnis der letzten Prüfung: erreichbar oder nicht erreichbar. In der Kopfzeile findest du die Schaltflächen Entfernen …, Verbindung testen, Abgleichen und Speichern.
Benutzer ohne Administratorrolle sehen statt des Formulars eine Karte mit Name, Stufe, URL des Configservers, Zustand (erreichbar oder nicht erreichbar samt Fehlermeldung) und der Gültigkeit des CA-Zertifikats. Ab der Rolle Packager steht dort die Schaltfläche Abgleichen.
Die Felder
| Feld | Inhalt |
|---|
| Name | Frei wählbarer Anzeigename, zum Beispiel Configserver. Bleibt das Feld leer, verwendet oPBWeb den Hostnamen aus der URL. |
| URL des Configservers | Adresse von opsiconfd mit Port, zum Beispiel https://opsi.example.local:4447. Verwende den vollständigen Hostnamen (FQDN), keine IP-Adresse: Das Zertifikat von opsiconfd lautet auf den Namen. Jede URL lässt sich nur einmal einrichten. |
| Technischer Benutzer | opsi-Benutzer, mit dem oPBWeb arbeitet. Vorbelegt ist opsiadm. Der Benutzer braucht opsi-Admin-Rechte. |
| Passwort | Passwort des technischen Benutzers. Es wird verschlüsselt gespeichert und nie wieder angezeigt. Ist bereits eins gespeichert, zeigt das Feld „gespeichert – leer lassen für unverändert“. |
| Stufe | Produktion, Staging oder Test. Die Stufe gilt für alle Depots des Servers, solange ein Depot keine eigene hat. Installieren auf Produktion erfordert die Rolle Releaser. Neue Configserver starten mit Produktion. |
| TLS-Zertifikat des Servers prüfen (empfohlen) | Prüft das Serverzertifikat gegen das hinterlegte CA-Zertifikat. Lass die Option eingeschaltet. |
Bei eingeschalteter TLS-Prüfung vertraut oPBWeb ausschließlich dem CA-Zertifikat, das du unter VERTRAUTES CA-ZERTIFIKAT hinterlegst, nicht den Zertifizierungsstellen des Betriebssystems. Ohne hinterlegtes CA-Zertifikat lässt sich eine https-Verbindung mit TLS-Prüfung nicht speichern („Für die TLS-Prüfung wird ein CA-Zertifikat benötigt.“).
Was die Stufe für die Rechte bedeutet und wie Depots sie erben, steht in der Depot-Verwaltung
.
Configserver hinzufügen
Öffne Depots in der Aktivitätsleiste.
Klick im Kopf der linken Liste auf +. Rechts erscheint das Formular „Neuer Configserver“.
Trag URL des Configservers, Technischer Benutzer und Passwort ein, optional einen Name.
Wähl die Stufe, zum Beispiel Test für einen Testserver.
Klick unter VERTRAUTES CA-ZERTIFIKAT auf Vom Server holen. oPBWeb lädt das CA-Zertifikat des Servers in einem kurzen Job; die Schaltfläche zeigt währenddessen „Lade …“.
Der Dialog CA-Zertifikat des Servers zeigt das Zertifikat mit seinem SHA-256-Fingerabdruck. Vergleiche ihn mit dem Fingerabdruck auf dem Configserver:
openssl x509 -in /etc/opsi/ssl/opsi-ca-cert.pem -noout -fingerprint -sha256
Stimmen beide überein, klick auf Vertrauen. Unter der Zertifikatstabelle erscheint „Geändertes CA-Zertifikat – zum Übernehmen speichern.“
Klick auf Hinzufügen. Die Meldung „Configserver gespeichert“ bestätigt das.
Direkt nach dem Hinzufügen startet oPBWeb für den neuen Server Verbindung testen
. Der Test liest auch die Depots des Servers; sie erscheinen danach in der Liste unter dem Configserver. Mit Abbrechen verwirfst du einen neuen Configserver, bevor er gespeichert ist.
Ist die URL schon eingerichtet, lehnt oPBWeb das Speichern ab: „Ein Configserver mit dieser URL ist bereits eingerichtet: …“.
Achtung
Klick nur auf Vertrauen, wenn der Fingerabdruck wirklich mit dem auf dem Server übereinstimmt. Beim Holen prüft oPBWeb das Zertifikat noch nicht – genau dafür ist der Vergleich da. Stimmt er nicht, schließ den Dialog und kläre die Ursache.
Configserver ändern
Wähl den Configserver in der Liste aus, änder die Felder und klick auf Speichern. Solange es ungespeicherte Änderungen gibt, sind Verbindung testen und Abgleichen gesperrt. Wechselst du mit ungespeicherten Änderungen zu einem anderen Eintrag der Liste, fragt oPBWeb vorher nach.
CA-Zertifikat aus einer Datei laden
Statt das Zertifikat vom Server zu holen, kannst du es als Datei hochladen, zum Beispiel wenn du opsi-ca-cert.pem vorher vom Server kopiert hast:
- Klick auf PEM-Datei laden … und wähl eine Datei mit der Endung
.pem, .crt oder .cer. - Es erscheint „Neue PEM-Datei geladen, wird beim Speichern geprüft.“
- Klick auf Speichern (bei einem neuen Server Hinzufügen). Erst jetzt prüft der Server die Datei. Enthält sie kein gültiges Zertifikat, lautet die Meldung „Kein gültiges PEM-Zertifikat: …“.
Mit Entfernen unter der Zertifikatstabelle löschst du das hinterlegte CA-Zertifikat; auch das wird erst mit Speichern wirksam.
Configserver entfernen
- Wähl den Configserver in der Liste aus.
- Klick in der Kopfzeile auf Entfernen ….
- Bestätige die Rückfrage „Configserver Name entfernen? Seine 3 Depots verschwinden aus oPBWeb (auf dem opsi-Server bleibt alles unverändert).“
Die Meldung „Configserver Name entfernt“ bestätigt das. oPBWeb löscht dabei den Configserver, seine Depots mit ihren Einstellungen und die Produktlisten dieser Depots. Pakete und Jobs bleiben erhalten. Auf dem opsi-Server selbst ändert sich nichts.
Gültigkeit des CA-Zertifikats
Die Tabelle unter VERTRAUTES CA-ZERTIFIKAT listet jedes Zertifikat der hinterlegten Datei mit Zertifikat (Inhaber), Gültigkeit und SHA-256-Fingerabdruck. Enthält die Datei kein CA-Zertifikat, steht hinter dem Inhaber „kein CA-Zertifikat“.
Das Abzeichen in der Spalte Gültigkeit zeigt die Restlaufzeit:
| Abzeichen | Bedeutung |
|---|
| grün, „noch 729 Tage“ | mehr als 60 Tage gültig |
| orange, „noch 45 Tage“ | weniger als 60 Tage gültig |
| rot, „noch 10 Tage“ | weniger als 14 Tage gültig |
| rot, „abgelaufen“ | Zertifikat ist abgelaufen |
Ab 60 Tagen vor Ablauf erscheint zusätzlich in der Statusleiste „Name: CA läuft in {n} Tagen ab“, und die Zeile opsi-Server im Systemstatus
steht auf Fehler.
CA-Rotation
opsi-Server erneuern ihre CA selbst. Danach stimmt das in oPBWeb hinterlegte Zertifikat nicht mehr mit dem des Servers überein, und Verbindungen mit TLS-Prüfung schlagen fehl. oPBWeb erkennt das bei der regelmäßigen Prüfung und meldet es an drei Stellen:
- in der Statusleiste: „Name: neues CA-Zertifikat“ (für Administratoren ein Link zu Depots)
- im Systemstatus in der Zeile opsi-Server
- im Formular des Configservers als Kasten „Der Server liefert ein neues CA-Zertifikat“ über den Feldern
So übernimmst du das neue Zertifikat:
- Öffne Depots und wähl den betroffenen Configserver aus. Der Kasten zeigt das neue Zertifikat mit Ablaufdatum und SHA-256-Fingerabdruck.
- Vergleiche den Fingerabdruck mit
/etc/opsi/ssl/opsi-ca-cert.pem auf dem Server (Befehl wie oben). - Klick auf Neues Zertifikat übernehmen. Die Meldung „Neues CA-Zertifikat übernommen“ bestätigt das; ein weiteres Speichern ist nicht nötig.
Verbleibende Warnungen in Statusleiste und Systemstatus verschwinden mit der nächsten Prüfung, spätestens nach fünf Minuten. Wenn du nicht warten willst, klick auf Verbindung testen.
Verbindung testen
Mit Verbindung testen prüfst du die gespeicherten Einstellungen des ausgewählten Configservers sofort. Die Schaltfläche ist gesperrt, solange es ungespeicherte Änderungen gibt („Bitte zuerst speichern“).
Der Test läuft als Job und prüft nacheinander:
- ob das hinterlegte CA-Zertifikat zum Server passt
- ob die Anmeldung mit technischem Benutzer und Passwort klappt
- ob der technische Benutzer opsi-Admin-Rechte hat
- welche opsi-Version läuft und welche Depots der Server meldet
War der Test erfolgreich, gleicht oPBWeb anschließend die Depots dieses Servers ab. Das Ergebnis erscheint als „Verbindung in Ordnung“ oder als Fehlermeldung. Unter dem Formular steht danach zum Beispiel „Zuletzt geprüft 15.10.26, 09:30 · opsi 4.3.x · 3 Depots“ oder die Fehlermeldung der letzten Prüfung in Rot.
Abgleichen
Abgleichen im Formular des Configservers liest nur die Depots dieses Servers, ihre installierten Produkte und die Projektordner seiner Workbench neu ein; der Job heißt „Depots abgleichen (Name)“. ⟳ im Kopf der Liste gleicht alle Configserver ab („Depots aller Configserver abgleichen“). Ein Abgleich berührt nie die Depots eines anderen Configservers. Was beim Abgleich mit den Depots passiert, steht in der Depot-Verwaltung
.
Automatische Prüfung im Hintergrund
Du musst den Test nicht regelmäßig von Hand starten. Der Worker prüft alle Configserver alle fünf Minuten (Standard, einstellbar unter Einstellungen → Worker) auf dieselbe Weise und gleicht dabei die Depots jedes erreichbaren Servers ab. Das Ergebnis siehst du:
- am Punkt vor dem Servernamen in der Depot-Liste, am Abzeichen erreichbar / nicht erreichbar und in „Zuletzt geprüft …“ im Formular
- in der Zeile opsi-Server im Systemstatus, mit einem Eintrag je Configserver
- als orangen Hinweis in der Statusleiste bei fehlendem Server, CA-Rotation oder bald ablaufender CA
Typische Fehler
| Meldung | Ursache und Lösung |
|---|
| „Benutzer hat keine opsi-Admin-Rechte“ | Der technische Benutzer ist kein opsi-Administrator. Nimm ihn auf dem Configserver in die opsi-Admin-Gruppe auf oder trag einen anderen Benutzer ein. |
| „… HTTP 403“ | opsiconfd lehnt Admin-Aufrufe aus dem Netz von oPBWeb ab. Steht in der opsiconfd-Konfiguration admin-networks, muss das Docker-Netz des oPBWeb-Workers darin enthalten sein. Das passt die technische Administration an (siehe Fehlersuche
). |
| „Der Server liefert ein anderes CA-Zertifikat als hinterlegt (Rotation?)“ | CA-Rotation auf dem Server, siehe CA-Rotation
. |
| „Für den opsi-Server ist kein CA-Zertifikat hinterlegt (Depots → Configserver).“ | TLS-Prüfung ist an, aber kein CA-Zertifikat gespeichert. Hol es mit Vom Server holen und speichere. |
| „CA nicht abrufbar: …“ | Der Server ist unter der eingetragenen URL nicht erreichbar. Prüfe Hostname, Port (normalerweise 4447) und Erreichbarkeit vom oPBWeb-Server aus. |
| „Ein Configserver mit dieser URL ist bereits eingerichtet: …“ | Der Server ist schon angelegt. Wähl ihn in der Liste aus, statt ihn ein zweites Mal hinzuzufügen. |
| „Depot … gehört bereits zum Configserver … und wird übersprungen“ (im Job-Protokoll) | Ein anderer eingerichteter Configserver meldet dasselbe Depot, etwa weil derselbe Server unter zwei URLs angelegt ist. Entferne den doppelten Eintrag. |
| Fehler beim Zertifikat trotz richtiger CA | Wahrscheinlich steht in der URL eine IP-Adresse statt des Hostnamens. Trag den FQDN ein. |
| „Der Server liefert kein abweichendes Zertifikat.“ | Bei Neues Zertifikat übernehmen: Die Rotation wurde inzwischen schon übernommen. Nichts weiter zu tun. |
Einstellungen für neue Pakete
Vorgaben für neue Pakete, Meta-Pakete und den Installer-Assistenten sowie die Mail-Domain für Changelog-Einträge
Rolle: Administrator
Überblick
Unter Einstellungen legst du fest, mit welchen Werten neue Pakete, Meta-Pakete und Pakete aus dem Assistenten Aus Installer … starten und welche Mail-Adresse Changelog-Einträge ohne E-Mail bekommen. Die Werte gelten für alle Benutzer. Ändern dürfen sie nur Administratoren.
Die Vorgaben wirken nur beim Anlegen. Bestehende Pakete und importierte Pakete (.opsi oder Workbench) behalten ihre eigenen Werte, und jeder Packager kann die Vorgaben im Paket-Editor überschreiben.
Die Verbindung zu den opsi-Configservern richtest du nicht hier ein, sondern in der Ansicht Depots, siehe Configserver
.

Einstellungen ändern
- Öffne Einstellungen unten in der Aktivitätsleiste.
- Ändere die gewünschten Werte in den Blöcken Neue Pakete, Meta-Pakete, Changelog, Workbench, Worker oder opsi-setup-detector.
- Klick in der Werkzeugleiste auf Speichern. Die Meldung „Einstellungen gespeichert“ bestätigt das.
Mit Verwerfen stellst du die zuletzt gespeicherten Werte wieder her. Beide Schaltflächen sind nur aktiv, wenn du etwas geändert hast. Verlässt du die Seite mit ungespeicherten Änderungen, fragt oPBWeb nach.
Neue Pakete
Diese Werte trägt oPBWeb in jedes Paket ein, das über Neues Paket entsteht.
| Feld | Standard | Erlaubte Werte | Wirkung |
|---|
| Produktversion | 1.0 | 1–32 Zeichen aus Buchstaben, Ziffern und . + ~ | Produktversion der ersten Version |
| Paketversion | 1 | 1–16 Zeichen aus Buchstaben, Ziffern und . + ~ | Paketversion der ersten Version |
| Priorität | 0 | −100 bis 100 | Priorität im control |
| Format control | INI (Altformat) | INI (Altformat), TOML (control.toml) | Format, in dem das control ins Paket geschrieben wird |
| Changelog | Changelog eingebettet | Changelog eingebettet, changelog.txt, changelog.md | Ob der Changelog im control steht oder als eigene Datei im Paket liegt |
Meta-Pakete fassen mehrere Produkte zusammen. Sie installieren ihre Produkte über Abhängigkeiten (Aktion setup, Reihenfolge vorher); das Setup-Script selbst tut nichts. Die Werte gelten für den Dialog Meta-Paket … in der Paketliste.
| Feld | Standard | Erlaubte Werte | Wirkung |
|---|
| Präfix der Product-ID | meta- | bis 32 Zeichen aus Kleinbuchstaben, Ziffern und . _ -, auch leer | Vorschlag, mit dem das Feld Product-ID im Dialog vorbelegt wird |
| Priorität | -100 | −100 bis 100 | Priorität des Meta-Pakets. |
| Name des Setup-Scripts | dummy.opsiscript | 1–128 Zeichen, ohne / und \ | Dateiname des leeren Setup-Scripts in CLIENT_DATA |
Das Feld für die Produktversion im Dialog Meta-Paket … ist mit der Produktversion aus dem Block Neue Pakete vorbelegt.
Changelog
| Feld | Standard | Erlaubte Werte | Wirkung |
|---|
| Mail-Domain für Benutzer ohne E-Mail | localhost | 1–128 Zeichen | Changelog-Einträge von Benutzern ohne E-Mail-Adresse erhalten benutzername@<Domain>. |
Hat ein Benutzer in seinem Konto eine E-Mail eingetragen, verwendet oPBWeb diese Adresse. Trag hier deshalb eine Domain ein, die zu euren Konten passt, oder pflege die E-Mail-Adressen in Benutzer und Rollen
. Bei Verzeichniskonten kommt die Adresse aus dem LDAP.
Workbench
| Feld | Standard | Erlaubte Werte | Wirkung |
|---|
| Importierte Version ist auf einem Depot installiert, aber ohne .opsi im Projektordner | Entwurf lassen | Entwurf lassen, Bauen und freigeben | Ist die Version eines aus der Workbench importierten Projektordners auf einem Depot desselben Configservers installiert, übernimmt oPBWeb die Datei <product-id>_<version>.opsi aus dem Projektordner als Build und gibt die Version frei. Fehlt die Datei, bleibt die Version mit „Entwurf lassen“ ein Entwurf; mit „Bauen und freigeben“ baut oPBWeb sie aus den importierten Quellen und gibt sie frei. |
Die Einstellung wirkt beim Import und beim Abgleich im Dialog „Workbench …“ (Mit Depots abgleichen), mit dem du früher importierte Entwürfe nachholst, siehe Installierte Versionen freigeben
. Das Job-Protokoll nennt in beiden Fällen, warum eine Version freigegeben wurde oder Entwurf blieb.
Worker
| Feld | Standard | Erlaubte Werte | Wirkung |
|---|
| opsi-Prüfung alle (Minuten) | 5 | 1–1440 | So oft prüft der Worker alle Configserver (Anmeldung, Admin-Rechte, CA-Zertifikat) und gleicht ihre Depots ab. |
| Workbench lesen alle (Minuten) | 60 | 1–1440 | So oft liest der Worker die Workbench aller Configserver und merkt sich, welche Projektordner dort liegen (auch in Gruppenordnern bis vier Ebenen tief, nicht in ignorierten Ordnern
); das zeigt die Paketliste unter Workbench
. Der Takt ist unabhängig von der opsi-Prüfung, weil das Lesen je Projektordner zwei Anfragen an den Server braucht. Ein nicht erreichbarer Server wird übersprungen. |
| Temporäre Dateien aufräumen um | 03:17 | Uhrzeit | Einmal täglich zu dieser Uhrzeit löscht der Worker vorbereitete Downloads und liegengebliebene Uploads, die älter als 24 Stunden sind. Ist die Uhrzeit beim Start des Workers schon vorbei, räumt er sofort auf. |
Änderungen gelten ab der nächsten Minute, der Worker muss dafür nicht neu starten. Den Takt des Lebenszeichens (alle 30 Sekunden) kannst du nicht ändern: An ihm erkennt der Systemstatus
einen ausgefallenen Worker.
opsi-setup-detector
Diese Werte sind die Vorgaben für den Assistenten Paket aus Installer erzeugen
. Sie entsprechen der Konfiguration des opsi-setup-detectors. Die Häkchen und Properties sind im Assistenten nur vorbelegt; der Packager kann sie dort für jedes Paket ändern. Paketversion, Priorität, Format control und Changelog nimmt der Assistent aus dem Block Neue Pakete.
| Feld | Standard | Wirkung |
|---|
| Vorlagenkanal | Standard | Kanal, der im Assistenten vorgewählt ist: Training (ausführlich kommentiert), Standard, Strukturiert oder Eigene (custom), siehe Vorlagen |
| Bibliotheken (importlib) | leer | ein Bibliotheksname pro Zeile (höchstens 20); der Generator fügt für jeden eine importlib-Zeile in die Scripte ein |
| Silent- statt Unattended-Parameter | aus | Installer laufen ganz ohne Fenster statt mit Fortschrittsanzeige |
| MSI-Wrapper über msiexec deinstallieren | an | Installer mit eingebettetem MSI deinstallieren über msiexec /x, wenn die Analyse den ProductCode gefunden hat |
| Option Desktop-Icon vorauswählen | aus | Option Desktop-Icon im Assistenten vorausgewählt |
| Option Lizenzschlüssel-Property vorauswählen | aus | Option Lizenzschlüssel-Property im Assistenten vorausgewählt |
| Metadaten schreiben (CLIENT_DATA/opsi-meta-data.toml) | aus | Windows-Pakete bekommen zusätzlich die Datei CLIENT_DATA/opsi-meta-data.toml mit Produktdaten und Installerangaben, wie sie der opsi-setup-detector schreibt |
Eigene Skriptzeilen
opsi-script-Zeilen, die der Generator in jedes neue Paket einfügt: Vor der Installation, Nach der Installation, Vor der Deinstallation und Nach der Deinstallation, jeweils vor bzw. nach dem Aufruf des Installers oder Deinstallers. Leer heißt: keine eigenen Zeilen.
Vorbelegte Properties
Diese Properties stehen in jedem neuen Paket aus dem Assistenten (höchstens 50). Du legst sie wie im Assistenten an: Name, Typ, Standardwert, Mögliche Werte, Beschreibung, Frei. Properties, die zu den Optionen des Assistenten gehören (etwa desktopicon), musst du hier nicht eintragen; die ergänzt der Generator selbst.
Vorlage für OPSI/readme.txt
Text der Datei OPSI/readme.txt, die der Generator jedem neuen Paket mitgibt. Leer heißt: Pakete bekommen keine readme.txt.
Jede gespeicherte Änderung erscheint im Protokoll
als settings.updated mit den geänderten Feldern.
Vorlagen für den Installer-Assistenten
Die Script-Vorlagen des opsi-setup-detectors in oPBWeb ansehen, ändern, ergänzen, zurücksetzen und aus einem ZIP importieren.
Rolle: Administrator
Überblick
Aus den Vorlagen erzeugt der Assistent Paket aus Installer
die Scripte und Dateien eines neuen Pakets. Es sind die Vorlagen des opsi-setup-detectors (template-files), die oPBWeb mitbringt. Beim ersten Start übernimmt oPBWeb sie in die Datenbank; dort kannst du sie in der Ansicht Vorlagen ändern, eigene hinzufügen, löschen oder eine neuere Fassung aus einem ZIP importieren. Ein neues Image ist dafür nicht nötig.
Die Ansicht Vorlagen in der Aktivitätsleiste sehen alle Benutzer. Ändern dürfen nur Administratoren; alle anderen sehen den Hinweis „Nur lesen: Vorlagen ändern dürfen nur Administratoren.“
Aufbau: Kanäle und Gruppen
Die Vorlagen sind wie beim opsi-setup-detector in Kanäle und Gruppen gegliedert. Jede Datei hat den Pfad <Kanal>/<Gruppe>/<Datei>.
| Kanal | Inhalt |
|---|
Training (ausführlich kommentiert) (training) | Scripte mit vielen Erklärungen |
Standard (default) | die üblichen Vorlagen des opsi-setup-detectors; Rückfallebene für alle anderen Kanäle |
Strukturiert (structured) | Scripte, die stärker in einzelne Dateien aufgeteilt sind |
Eigene (custom) (custom) | leer ausgeliefert; Platz für eure eigenen Vorlagen |
| Gruppe | Verwendet für |
|---|
win, lin, mac | Pakete für ein Betriebssystem |
multi | Pakete für mehrere Betriebssysteme |
with-user | Installation im Benutzerkontext |
generic | Bausteine, die alle Arten einbinden (Desktop-Icon, Lizenz, Custom-Verzeichnis, Profilanpassung, osd-lib.opsiscript …) |
images | Standardbilder der Produkte je Betriebssystem |
Welchen Kanal ein neues Paket verwendet, wählt der Packager im Assistenten; vorbelegt ist der Kanal aus den Einstellungen
.
Reihenfolge der Suche
Der Generator sucht jede Datei in dieser Reihenfolge und nimmt den ersten Treffer:
- im gewählten Kanal in der Gruppe des Pakets, zum Beispiel
custom/win/setup.opsiscript, - im Kanal Standard in derselben Gruppe,
default/win/setup.opsiscript, - in
default/generic.
Im Kanal Eigene (custom) musst du deshalb nur die Dateien anlegen, die von Standard abweichen. Findet der Generator eine Datei nirgends, lässt er den Baustein aus und meldet „Vorlage … fehlt, der Baustein wird ausgelassen“.
Platzhalter
Die Vorlagen enthalten Platzhalter der Form #@name*#, zum Beispiel #@productId*# für die Product-ID oder #@installCommandLine1*# für den Installationsbefehl des ersten Installers. Beim Erzeugen eines Pakets ersetzt der Generator sie durch die Werte aus dem Assistenten; Groß- und Kleinschreibung spielt dabei keine Rolle. Steht ein Platzhalter für mehrere Zeilen, rückt der Generator alle Zeilen wie die Zeile des Platzhalters ein.
Rechts neben dem Editor listet der Bereich Platzhalter alle Platzhalter der geöffneten Datei auf. Bleibt beim Erzeugen ein Platzhalter übrig, für den der Generator keinen Wert kennt, meldet der Job „Nicht ersetzte Platzhalter in den erzeugten Dateien: …“. Eigene Platzhalter kannst du nicht einführen; verwende in eigenen Vorlagen nur die Namen, die in den mitgelieferten Dateien vorkommen.
Die Ansicht Vorlagen
Links steht der Baum mit Kanälen, Gruppen und Dateien, darüber ein Filterfeld. Ein Klick auf einen Kanal oder eine Gruppe klappt ihn zu oder auf; ein Klick auf eine Gruppe wählt sie außerdem als Ziel für neue Dateien und Uploads. Jede Datei trägt ein Abzeichen:
| Abzeichen | Bedeutung |
|---|
| mitgeliefert | unverändert, wie im Image von oPBWeb |
| geändert | mitgelieferte Datei mit geändertem Inhalt; lässt sich zurücksetzen |
| eigene | von einem Administrator angelegt, hochgeladen oder importiert |
| gelöscht | gelöschte mitgelieferte Datei; nur sichtbar mit Gelöschte mitgelieferte Vorlagen |
Ein Klick auf eine Datei öffnet sie rechts im Editor. Textdateien bearbeitest du dort mit denselben Funktionen wie im Scripteditor
; Bilder und andere Binärdateien kannst du nur herunterladen oder per Upload ersetzen.
Vorlage bearbeiten
- Öffne Vorlagen in der Aktivitätsleiste.
- Klick im Baum auf die Datei, zum Beispiel
Standard › win › setup.opsiscript. - Ändere den Text im Editor.
- Klick auf Speichern oder drück
Strg S. Die Meldung „Vorlage gespeichert“ bestätigt das. Eine mitgelieferte Datei trägt danach das Abzeichen geändert.
Die Änderung gilt für alle Pakete, die danach mit dem Assistenten entstehen. Bereits erzeugte Pakete ändern sich nicht.
Weitere Aktionen
| Schaltfläche | Wirkung |
|---|
| Herunterladen | lädt die Datei herunter (alle Rollen) |
| Zurücksetzen | setzt eine geänderte mitgelieferte Datei nach einer Rückfrage auf den mitgelieferten Stand zurück; deine Änderungen gehen verloren |
| Umbenennen | nur bei eigenen Dateien: neuer Dateiname, Unterordner mit /. Mitgelieferte Dateien lassen sich nicht umbenennen; lege stattdessen eine Kopie als eigene Vorlage an |
| Löschen | löscht nach einer Rückfrage die Datei, siehe unten |
| + (Neue Vorlage) | legt eine leere Textdatei an: Kanal, Gruppe, Dateiname |
| Pfeil nach oben (Datei hochladen) | lädt eine Datei in Kanal und Gruppe; mit Vorhandene Datei ersetzen überschreibt sie eine gleichnamige Datei |
| Ordner mit Plus (Vorlagen importieren) | importiert ein ZIP, siehe ZIP importieren |
Dateinamen bestehen aus Buchstaben, Ziffern, Punkt, Plus, Leer-, Binde- und Unterstrich, Unterordner trennst du mit /. Gruppennamen bestehen aus Kleinbuchstaben, Ziffern, Binde- und Unterstrich. Eine Datei darf höchstens 16 MB groß sein.
Löschen und Wiederherstellen
- Eine eigene Datei ist nach dem Löschen weg.
- Eine mitgelieferte oder geänderte Datei bleibt als gelöschter Eintrag erhalten. Der Generator verwendet sie nicht mehr, und auch ein Update von oPBWeb bringt sie nicht zurück. Hake unter dem Baum Gelöschte mitgelieferte Vorlagen an, um diese Einträge zu sehen; Wiederherstellen holt den mitgelieferten Stand zurück.
Löschst du eine Datei im gewählten Kanal, greift beim Erzeugen die Suchreihenfolge
: Der Generator nimmt dann die Datei aus Standard bzw. default/generic, falls es sie dort gibt.
Vorlagen bei einem Update
Ein neues Image von oPBWeb kann neuere Vorlagen mitbringen. Beim Start gleicht die API die Datenbank damit ab:
- Unveränderte mitgelieferte Dateien bekommen den neuen Inhalt.
- Geänderte Dateien behalten deinen Inhalt. Zurücksetzen führt dann auf die neue mitgelieferte Fassung.
- Gelöschte mitgelieferte Dateien bleiben gelöscht.
- Neue Dateien kommen hinzu, eigene Dateien bleiben unberührt.
Vorlagen aus einem ZIP importieren
So übernimmst du eine neuere Fassung der Vorlagen des opsi-setup-detectors, ohne auf ein neues Image zu warten, oder verteilst eure eigenen Vorlagen auf eine zweite oPBWeb-Installation.
- Besorg dir den Ordner
template-files des opsi-setup-detectors: aus dem GitHub-Repository opsi-org/lazarus
(Ordner opsi-misc/opsisetupdetector/template-files) oder aus der Installation eines opsi-setup-detectors. - Pack ihn als ZIP. Erlaubt sind zwei Aufbauten, jeweils auch mit einem zusätzlichen Ordner darüber wie
template-files/:<Kanal>/<Gruppe>/<Datei> mit einem oder mehreren Kanälen (training, default, structured, custom),<Gruppe>/<Datei> für einen einzelnen Kanal; den Kanal wählst du dann beim Import.
- Klick in der Ansicht Vorlagen über dem Baum auf Vorlagen importieren.
- Wähl unter ZIP-Datei die Datei aus.
- Wähl unter In Kanal importieren den Zielkanal oder wie im ZIP.
- Hake Vorhandene Vorlagen ersetzen an, wenn vorhandene Dateien den Inhalt aus dem ZIP bekommen sollen. Ohne Haken kommen nur neue Dateien dazu.
- Klick auf Importieren. Die Meldung nennt das Ergebnis, zum Beispiel „Import: 3 neu, 12 ersetzt, 140 übersprungen“.
Neue Dateien aus dem ZIP werden eigene Vorlagen. Ersetzte mitgelieferte Dateien gelten als geändert und lassen sich weiter zurücksetzen. Gelöschte mitgelieferte Dateien, die im ZIP vorkommen, holt der Import zurück. Übersprungen werden unveränderte Dateien, Ordner, Links, Dateien über 16 MB und Namen, die der Editor nicht annimmt. Ein ZIP darf höchstens 5000 Dateien enthalten.
Hinweis
Die Vorlagen für winget-Pakete (setupwinget.opsiscript, uninstallwinget.opsiscript, delincwinget.opsiinc in default/win, HandleWingetSections.opsiscript und osd-winget-exitcode.opsiscript in default/generic) fehlen im Repository des opsi-setup-detectors. oPBWeb bringt dafür eigene Fassungen mit, im Kopf mit „created for oPBWeb“ markiert. Ein Import aus dem Original lässt sie unverändert, weil das ZIP sie nicht enthält.
Protokoll
Jede Änderung an den Vorlagen erscheint im Protokoll
: detector.template_created, detector.template_uploaded, detector.template_updated, detector.template_reset, detector.template_deleted und detector.templates_imported.
Depot-Verwaltung
Depots den Stufen Test, Staging und Produktion zuordnen, Dienst-URL und Aktiv setzen, verschwundene Depots entfernen
Rolle: Administrator
Überblick
Welche Depots es gibt, liest oPBWeb von den eingerichteten opsi-Configservern. Jedes Depot gehört zu genau einem Configserver. Als Administrator legst du für jedes Depot fest, in welcher Stufe es läuft, unter welcher Dienst-URL oPBWeb es erreicht und ob es überhaupt verwendet wird (Aktiv). Die Stufe entscheidet, welche Rolle auf dem Depot installieren darf.
Du findest die Einstellungen unter Depots. Die linke Liste ist nach Configservern gegliedert: Jeder Configserver steht als fett gedruckte Zeile, darunter eingerückt seine Depots mit Stufen-Abzeichen und der Zahl der Produkte, beim Depot des Configservers selbst zum Beispiel „Configserver · 120 Produkte“. Zusätze wie „deaktiviert“ oder „nicht mehr vorhanden“ stehen ebenfalls in der zweiten Zeile. Wie du Configserver anlegst und pflegst, steht in Configserver
.
Wähl links ein Depot aus, rechts steht oben der Block Einstellungen. Alle anderen Rollen sehen die Werte nur; die Felder sind für sie gesperrt. Die übrigen Funktionen der Depot-Ansicht (Installierte Produkte, Dateien, Repository, Vergleich) beschreibt Depots
im Benutzerhandbuch.

Stufen: Test, Staging und Produktion
Jedes Depot hat eine von drei Stufen. Sie steht als Abzeichen in der Depotliste und in der Kopfzeile des Depots.
| Stufe | Installieren, Deinstallieren, Entsperren, Repository löschen |
|---|
| Test | ab Rolle Packager |
| Staging | ab Rolle Packager |
| Produktion | ab Rolle Releaser |
So können Packager neue Pakete auf Test- und Staging-Depots ausprobieren, während nur Releaser und Administratoren produktive Depots bespielen. Im Dialog Installieren … sieht ein Packager produktive Depots mit dem Hinweis „erfordert Rolle Releaser“ und kann sie nicht auswählen. Die vollständige Rollenübersicht steht in Benutzer und Rollen
.
Geerbte Stufe
Jeder Configserver hat selbst eine Stufe. Seine Depots übernehmen sie, solange du für ein Depot keine eigene Stufe festlegst. Eine geerbte Stufe erkennst du am kursiven, helleren Abzeichen mit dem Tooltip „vom Configserver geerbt“. Änderst du die Stufe des Configservers, ändert sich die Stufe aller Depots mit, die sie erben.
So reicht es meist, die Stufe einmal am Configserver zu setzen: Ein Testserver bekommt Test, und alle seine Depots sind Test-Depots. Eine eigene Stufe brauchst du nur für einzelne Depots, die von ihrem Configserver abweichen sollen.
Achtung
Neue Configserver starten in der Stufe Produktion, und neue Depots erben die Stufe ihres Configservers. Das ist Absicht: Ein Depot, das niemand eingeordnet hat, darf kein Packager versehentlich bespielen. Setz die Stufe eines Test- oder Staging-Servers deshalb gleich beim Anlegen.
Depot-Einstellungen ändern
- Öffne Depots in der Aktivitätsleiste und wähl links das Depot aus.
- Setz im Block Einstellungen die Felder:
- Stufe — „wie Configserver (Stufe)“ (die Stufe wird geerbt), Produktion, Staging oder Test.
- Dienst-URL — Adresse von opsiconfd auf diesem Depot, über die oPBWeb Pakete hochlädt und auf die Dateien des Depots zugreift. Lass das Feld leer, um die Standard-URL zu verwenden: Hostname des Depots mit dem Port des Configservers, zum Beispiel
https://depot01.example.local:4447. Beim Configserver selbst ist die Standard-URL die URL des Configservers aus dessen Formular
. Die Standard-URL steht als grauer Platzhalter im Feld. - Aktiv — ja oder nein. Ein inaktives Depot bleibt in der Liste, ist aber für Installieren, Deinstallieren, Entsperren und Repository-Löschen gesperrt. Im Dialog Installieren … erscheint es als „deaktiviert“.
- Klick auf Speichern. Die Meldung „Einstellungen gespeichert“ bestätigt das.
Unter den Feldern zeigt oPBWeb, was tatsächlich gilt: Verwendete URL ist die Adresse, mit der oPBWeb das Depot anspricht; ein Klick darauf öffnet das Depot in einem neuen Tab. Außerdem siehst du, was opsi selbst meldet, etwa die Pfade Repository und Depot und die URL unter Von opsi gemeldet.
Tipp
Eine eigene Dienst-URL brauchst du nur, wenn das Depot unter seinem Hostnamen nicht erreichbar ist oder opsiconfd dort auf einem anderen Port läuft. Verwende auch hier den Hostnamen, keine IP-Adresse, damit die Zertifikatsprüfung klappt.
Wie Depots in oPBWeb landen
oPBWeb gleicht die Depots mit ihrem Configserver ab:
- bei jeder automatischen Prüfung, also alle fünf Minuten (Standard, einstellbar unter Einstellungen → Worker) für jeden erreichbaren Configserver
- direkt nach dem Hinzufügen eines Configservers und nach Verbindung testen im Formular des Configservers
- wenn ein Packager oder Administrator in Depots auf Abgleichen klickt: in der Kopfzeile eines Depots oder bei einem Configserver gleicht das nur diesen einen Configserver ab („Depots abgleichen (Name)“), ⟳ im Kopf der Liste alle Configserver („Depots aller Configserver abgleichen“)
Ein Abgleich berührt nie die Depots eines anderen Configservers. Ein Abgleich über Abgleichen oder ⟳ liest zusätzlich die Workbench des Configservers ein (für die Angabe „Workbench“ in der Paketliste); der automatische Abgleich tut das nicht, dafür liest der Worker die Workbench in einem eigenen Takt (siehe Einstellungen
). Beim Abgleich gilt:
| Situation | Was oPBWeb macht |
|---|
| Der Configserver meldet ein neues Depot. | Das Depot wird mit geerbter Stufe („wie Configserver“) und Aktiv ja angelegt. |
| Der Configserver meldet ein bekanntes Depot. | Die Angaben von opsi und die installierten Produkte werden aktualisiert. Stufe, Dienst-URL und Aktiv bleiben, wie du sie gesetzt hast. |
| Der Configserver meldet ein Depot nicht mehr. | Das Depot bleibt mit seinen Einstellungen erhalten und ist als „nicht mehr vorhanden“ markiert. Es ist für alle Depot-Aktionen gesperrt. |
| Ein als „nicht mehr vorhanden“ markiertes Depot wird wieder gemeldet. | Die Markierung verschwindet, die bisherigen Einstellungen gelten weiter. |
| Das gemeldete Depot gehört in oPBWeb bereits zu einem anderen Configserver (zum Beispiel weil derselbe Server unter zwei URLs eingerichtet ist). | Das Depot wird übersprungen; das Job-Protokoll meldet „Depot … gehört bereits zum Configserver … und wird übersprungen“. |
Verschwundene Depots entfernen
Ein Depot, das der Configserver nicht mehr meldet, bleibt in oPBWeb stehen, bis du es entfernst. In der Detailansicht steht dann „Der Configserver meldet dieses Depot nicht mehr. Es bleibt mit seinen Einstellungen erhalten, bis ein Admin es entfernt.“
- Wähl das Depot in der Liste aus.
- Klick in der Kopfzeile auf Entfernen. Die Schaltfläche gibt es nur bei Depots, die nicht mehr gemeldet werden.
- Bestätige die Rückfrage „Depot depot01.example.local mit seinen Einstellungen aus oPBWeb entfernen? Auf dem opsi-Server ändert sich nichts.“
Die Meldung „Depot entfernt“ bestätigt das. Depots, die der Configserver noch meldet, kannst du nicht entfernen; setz sie stattdessen auf Aktiv nein. Entfernst du einen ganzen Configserver, verschwinden alle seine Depots mit (siehe Configserver entfernen
).
Weitere Rechte als Administrator
Neben den Depot-Einstellungen hast du in der täglichen Arbeit einige Rechte, die anderen Rollen fehlen:
- Jobs anderer Benutzer abbrechen: Unter Jobs kannst du jeden wartenden Job mit Abbrechen stoppen, nicht nur deine eigenen. Laufende Jobs lassen sich auch von Administratoren nicht abbrechen. Mehr dazu in Jobs
.
- Globale Snippets pflegen: Nur Administratoren legen Snippets mit der Sichtbarkeit „Global (für alle)“ an, ändern und löschen sie oder importieren Snippets in den globalen Bereich. Alle anderen sehen globale Snippets; Packager können sie mit Duplizieren als eigene Kopie übernehmen. Die Bedienung steht in Snippets
.
Systemstatus
Dienste überwachen, Datenbank und Objektspeicher auswerten, den Bucket durchsuchen und nicht mehr verwendete Objekte bereinigen
Rolle: Administrator
Überblick
Der Bereich Systemstatus zeigt, ob alle Dienste von oPBWeb laufen, und gibt Administratoren Einblick in die Belegung von Datenbank und Objektspeicher. Du öffnest ihn über das Symbol Systemstatus unten in der Aktivitätsleiste.
Die Tabelle der Dienste sehen alle Rollen. Die Abschnitte Datenbank, Objektspeicher mit Bereinigen … und Bucket-Inhalt sehen nur Administratoren.
Dienste prüfen

In der Werkzeugleiste fasst ein Abzeichen den Zustand zusammen: „Alle Dienste erreichbar“, „Mindestens ein Dienst ist nicht erreichbar“ oder „API nicht erreichbar“. Daneben steht „Stand HH:MM:SS“. Die Tabelle aktualisiert sich alle zehn Sekunden von selbst; mit Aktualisieren lädst du sofort neu.
| Dienst | Was geprüft wird | Typischer Inhalt von Details |
|---|
| Datenbank | Verbindung zu MariaDB | Version und Schemastand |
| Redis | Verbindung zu Redis (Warteschlange der Jobs) | Redis-Version |
| Objektspeicher | ob der Bucket vorhanden ist | Name des Buckets oder „Bucket ‘…’ fehlt“ |
| Worker | Lebenszeichen des Workers, der alle Jobs ausführt | „Lebenszeichen vor n s“; Fehler bei „kein Lebenszeichen“ oder wenn das letzte länger als 90 Sekunden zurückliegt |
| opsi-Server | Ergebnis der letzten automatischen Prüfung aller Configserver | je Configserver ein Eintrag „Name: opsi-Version · Benutzer@URL · Depots · CA gültig bis …“, getrennt durch „|“; „kein Configserver eingerichtet“, wenn es keinen gibt |
Die Spalte Status zeigt OK oder Fehler, Dauer die Antwortzeit der Prüfung in Millisekunden.
Die Zeile opsi-Server steht auf Fehler, sobald einer der Configserver nicht erreichbar ist, ein neues CA-Zertifikat liefert oder seine CA in weniger als 60 Tagen abläuft – auch wenn alle anderen in Ordnung sind. Der Eintrag des betroffenen Servers nennt den Grund, zum Beispiel „Server liefert ein neues CA-Zertifikat, bitte unter Depots übernehmen“. Was dann zu tun ist, steht in Configserver
. Steht dort „noch nicht geprüft“, hat der Worker noch keine Prüfung abgeschlossen; das Ergebnis kommt spätestens nach fünf Minuten.
Hinweis
Steht Worker auf Fehler, bleiben alle Jobs (Bauen, Installieren, Import, Abgleich) in der Warteschlange hängen. Die Ursache klärt die technische Administration, siehe Fehlersuche
.
Speicherbelegung
Die Abschnitte Datenbank und Objektspeicher werden beim Öffnen der Seite und mit Aktualisieren geladen, nicht alle zehn Sekunden.

Datenbank
Über der Tabelle steht die Gesamtgröße, zum Beispiel „48 MB in 21 Tabellen“. Die Tabelle listet jede Datenbanktabelle, die größte zuerst:
| Spalte | Inhalt |
|---|
| Tabelle | Name der Tabelle |
| Zeilen | Anzahl der Datensätze, exakt gezählt |
| Daten | Speicherplatz der Daten |
| Index | Speicherplatz der Indizes |
| Größe | Daten und Index zusammen |
| Anteil | Anteil an der Gesamtgröße als Balken und Prozentwert |
Die Größen stammen aus der Statistik von MariaDB, die verzögert aktualisiert wird. Nach größeren Änderungen stimmen sie deshalb eine Weile nicht ganz genau.
Objektspeicher
Im Objektspeicher liegen die Dateien der Pakete und die Build-Ergebnisse. Über der Tabelle steht „Bucket „packages“: 4,8 GB in 1.523 Objekten“. Die Tabelle teilt den Inhalt in Bereiche auf:
| Bereich | Inhalt |
|---|
Paketdateien (blobs/) | Inhalte aller Dateien aller Paketversionen. Jeder Inhalt liegt nur einmal da, auch wenn viele Versionen dieselbe Datei enthalten. |
Build-Ergebnisse (artifacts/) | gebaute .opsi-Dateien mit .md5 und .zsync |
Uploads (temporär) (uploads/) | hochgeladene Dateien, die noch verarbeitet werden |
Downloads (temporär) (downloads/) | Dateien, die für einen Download vom Depot bereitliegen |
Bucket-Wurzel (/) | Objekte außerhalb dieser Bereiche |
Uploads und Downloads, die älter als 24 Stunden sind, löscht oPBWeb jede Nacht automatisch.
Unter der Tabelle stehen bis zu drei Kennzahlen:
- Ersparnis durch Deduplizierung: „Paketdateien: 12,6 GB über alle Versionen, davon 4,1 GB tatsächlich gespeichert, Ersparnis durch Deduplizierung 8,5 GB.“ Je mehr Versionen eines Pakets es gibt, desto größer ist die Ersparnis, weil unveränderte Dateien nicht doppelt gespeichert werden.
- Nicht verwendete Blobs: „37 Blobs werden von keiner Paketdatei mehr verwendet.“ Solche Inhalte bleiben nach dem Löschen von Versionen oder Dateien zurück. Du entfernst sie mit Bereinigen …
.
- Fehlende Blobs (rot): „2 Paketdateien verweisen auf fehlende Blobs.“ Das sollte nie vorkommen und deutet auf einen beschädigten oder unvollständig wiederhergestellten Objektspeicher hin. Wende dich an die technische Administration.
Bucket-Inhalt durchsuchen
Unter Bucket-Inhalt kannst du den Objektspeicher wie einen Dateibaum durchsehen. Der Browser ist schreibgeschützt: Du kannst Objekte ansehen und herunterladen, aber nichts ändern oder löschen.

- Klick auf einen Ordner, um ihn zu öffnen. Mit der Pfadleiste über der Tabelle (beginnend mit
/) oder der Zeile „‹ eine Ebene höher“ gehst du zurück. - Grenz die Anzeige mit dem Feld Filtern ein. ⟳ lädt den Ordner neu.
- Zum Herunterladen klick auf ↓ am Zeilenende oder doppelklick auf die Zeile.
Die Tabelle zeigt Name, Größe und Geändert. In den Bereichen blobs/ und artifacts/ gibt es zusätzlich die Spalte Verwendet von:
- Ein Link führt zur Paketversion, die das Objekt verwendet; bei Paketdateien steht der Dateipfad im Paket dahinter.
- „+n“ heißt, dass weitere Versionen oder Dateien dasselbe Objekt verwenden. Fahr mit der Maus über die Zelle, um die Liste zu sehen.
- nicht verwendet heißt, dass keine Paketversion das Objekt mehr braucht. Es ist ein Kandidat für die Bereinigung.
Die Objekte unter blobs/ heißen nach dem SHA-256-Hashwert ihres Inhalts, nicht nach dem Dateinamen im Paket. Welche Datei dahintersteckt, zeigt die Spalte Verwendet von.
Objektspeicher bereinigen
Wenn Versionen oder Dateien gelöscht werden, bleiben ihre Inhalte zunächst im Objektspeicher. Mit Bereinigen … entfernst du Paketdateien (blobs/) und Build-Ergebnisse (artifacts/), die nichts mehr verwendet. Die Bereinigung läuft in zwei Schritten: Ein Probelauf ermittelt, was gelöscht würde, und erst nach deiner Bestätigung wird gelöscht.
- Klick im Abschnitt Objektspeicher auf Bereinigen …. Ein Probelauf startet als Job; die Schaltfläche zeigt „Läuft …“.
- Findet der Probelauf nichts, erscheint neben der Schaltfläche „Nichts zu bereinigen“ oder „Nichts zu bereinigen, 5 nicht verwendete Objekte sind jünger als 24 Stunden“. Du bist fertig.
- Andernfalls öffnet sich der Dialog Objektspeicher bereinigen. Er zeigt:
- die Gesamtzahl und -größe, etwa „Der Probelauf hat 37 nicht verwendete Objekte gefunden (1,2 GB).“
- Anzahl und Größe je Bereich
- eine Liste mit Beispielen; die vollständige Liste steht im Protokoll des Jobs unter Jobs
- wie viele nicht verwendete Objekte jünger als 24 Stunden sind und erhalten bleiben
- Prüf die Angaben und klick auf 37 Objekte löschen. Mit Abbrechen schließt du den Dialog, ohne etwas zu löschen.
- Der Löschlauf startet als zweiter Job. Danach steht neben der Schaltfläche zum Beispiel „37 Objekte gelöscht, 1,2 GB freigegeben“.
Für die Bereinigung gelten mehrere Schutzregeln:
- 24 Stunden Schonfrist: Nur Objekte, die älter als 24 Stunden sind, kommen in Frage. Frisch hochgeladene Inhalte, die gerade erst einer Version zugeordnet werden, bleiben so verschont.
- Probelauf eine Stunde gültig: Gelöscht werden nur Objekte aus dem bestätigten Probelauf. Ist er älter als eine Stunde, lehnt oPBWeb das Löschen ab („Der Probelauf fehlt oder ist älter als eine Stunde. Bitte erneut prüfen.“). Starte dann Bereinigen … neu.
- Erneute Prüfung beim Löschen: Jedes Objekt wird unmittelbar vor dem Löschen noch einmal geprüft. Wird es inzwischen wieder verwendet, bleibt es erhalten.
- Nicht während Importen und Builds: Solange ein Import oder Build wartet oder läuft, startet keine Bereinigung („Es laufen gerade Importe oder Builds. Bitte nach deren Ende erneut starten.“). Beginnt während des Löschens ein Import oder Build, bricht der Löschlauf ab. Bereits gelöschte Objekte bleiben gelöscht, den Rest erwischst du beim nächsten Durchgang.
Der bestätigte Löschlauf steht im Protokoll
als storage.cleanup.
Tipp
Bereinige am besten zu einer Zeit, in der niemand baut oder importiert, zum Beispiel nach Feierabend. Dann läuft der Löschlauf ohne Unterbrechung durch.