Fachliche Administration

• Benutzer und Rollen
• Protokoll
• Configserver
• Einstellungen für neue Pakete
• Depot-Verwaltung
• Systemstatus

Benutzer und Rollen

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.

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:

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 .

Die Benutzerliste

Der Reiter Benutzer zeigt alle Konten in einer Tabelle. Rechts daneben öffnet sich der Bereich Benutzerdetails für das ausgewählte Konto.

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

1. Klick in der Werkzeugleiste auf Neuer Benutzer.

   

2. Trag den Benutzernamen ein. Erlaubt sind 2 bis 128 Zeichen aus Buchstaben, Ziffern und . _ @ -.

3. Wähl die Rolle. Der Dialog schlägt Leser vor, die Rolle mit den wenigsten Rechten.

4. Trag optional Name und E-Mail ein. Die E-Mail-Adresse erscheint in Changelog-Einträgen dieses Benutzers.

5. Wähl die Standardsprache (Deutsch oder English). Mit dieser Sprache startet die Oberfläche nach jeder Anmeldung.

6. Vergib im Feld Neues Passwort ein Startpasswort mit mindestens 10 Zeichen.

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

Konto bearbeiten

1. Wähl das Konto in der Liste aus.
2. Ändere in den Benutzerdetails Name, E-Mail, Rolle oder Standardsprache.
3. 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.“

1. Wähl das Konto aus.
2. Entferne das Häkchen bei Konto ist aktiv.
3. 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:

1. Wähl das Konto aus und klick auf Passwort setzen.
2. Gib das neue Passwort zweimal ein (mindestens 10 Zeichen).
3. 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:

1. Wähl das gesperrte Konto aus.
2. 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

1. Wähl das Konto aus.
2. Klick auf Benutzer löschen.
3. 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.

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.

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

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:

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

Einträge filtern

1. Trag im Feld Aktion den Anfang eines Aktionsschlüssels ein. user. findet alle Aktionen an Benutzerkonten, auth.login_failed nur die fehlgeschlagenen Anmeldungen.
2. Trag im Feld Benutzername einen Benutzernamen ein. Hier muss der Name vollständig und genau stimmen.
3. 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

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

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

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

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

1. Öffne Depots in der Aktivitätsleiste.

2. Klick im Kopf der linken Liste auf +. Rechts erscheint das Formular „Neuer Configserver“.

3. Trag URL des Configservers, Technischer Benutzer und Passwort ein, optional einen Name.

4. Wähl die Stufe, zum Beispiel Test für einen Testserver.

5. 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 …“.

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

7. Stimmen beide überein, klick auf Vertrauen. Unter der Zertifikatstabelle erscheint „Geändertes CA-Zertifikat – zum Übernehmen speichern.“

8. 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: …“.

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:

1. Klick auf PEM-Datei laden … und wähl eine Datei mit der Endung .pem, .crt oder .cer.
2. Es erscheint „Neue PEM-Datei geladen, wird beim Speichern geprüft.“
3. 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

1. Wähl den Configserver in der Liste aus.
2. Klick in der Kopfzeile auf Entfernen ….
3. 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:

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:

1. Öffne Depots und wähl den betroffenen Configserver aus. Der Kasten zeigt das neue Zertifikat mit Ablaufdatum und SHA-256-Fingerabdruck.
2. Vergleiche den Fingerabdruck mit /etc/opsi/ssl/opsi-ca-cert.pem auf dem Server (Befehl wie oben).
3. 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

Einstellungen für neue Pakete

Rolle: Administrator

Überblick

Unter Einstellungen legst du fest, mit welchen Werten neue Pakete und Meta-Pakete 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

1. Öffne Einstellungen unten in der Aktivitätsleiste.
2. Ändere die gewünschten Werte in den Blöcken Neue Pakete, Meta-Pakete oder Changelog.
3. 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.

Meta-Pakete

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.

Das Feld für die Produktversion im Dialog Meta-Paket … ist mit der Produktversion aus dem Block Neue Pakete vorbelegt.

Changelog

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.

Worker

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

Jede gespeicherte Änderung erscheint im Protokoll als settings.updated mit den geänderten Feldern.

Depot-Verwaltung

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.

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.

Depot-Einstellungen ändern

1. Öffne Depots in der Aktivitätsleiste und wähl links das Depot aus.
2. 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“.
3. 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.

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:

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

1. Wähl das Depot in der Liste aus.
2. Klick in der Kopfzeile auf Entfernen. Die Schaltfläche gibt es nur bei Depots, die nicht mehr gemeldet werden.
3. 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

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.

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.

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:

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:

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.

1. 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.
2. Grenz die Anzeige mit dem Feld Filtern ein. ⟳ lädt den Ordner neu.
3. 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.

1. Klick im Abschnitt Objektspeicher auf Bereinigen …. Ein Probelauf startet als Job; die Schaltfläche zeigt „Läuft …“.
2. 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.
3. 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
4. Prüf die Angaben und klick auf 37 Objekte löschen. Mit Abbrechen schließt du den Dialog, ohne etwas zu löschen.
5. 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.