Paket-Editor

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Im Paket-Editor bearbeitest du eine Paketversion: die control-Daten (Produktangaben, Scripte, Abhängigkeiten, Properties), den Changelog und die Dateien des Pakets. Dieses Kapitel beschreibt den Reiter control. Wie du mit Dateien und Scripten arbeitest, steht in Dateien des Pakets und Scripteditor .

Bearbeiten kannst du nur Entwürfe, und nur mit mindestens der Rolle Packager. Als Leser und bei freigegebenen Versionen sind alle Felder gesperrt; ansehen kannst du alles.

Editor öffnen

Du öffnest den Editor auf einem dieser Wege:

• Doppelklick auf ein Paket in der Paketliste, oder Im Editor öffnen in den Paketdetails.
• Paket-Editor in der Bereichsleiste öffnet das zuletzt bearbeitete Paket.
• Über die Suche (Strg K) ein Paket auswählen.

Aufbau

Der Editor ist in drei Bereiche geteilt:

• Links: Oben die Liste aller Pakete (Filtern …, orangefarbener Punkt = Entwurf, blauer Punkt = freigegeben). Darunter die Reiter Dateien (Dateibaum) und Struktur (Include-Baum der Scripte).
• Mitte: Reiter control für die Paketdaten und je ein Reiter pro geöffneter Datei. Ein ● zeigt ungespeicherte Änderungen.
• Unten: Das Panel JOBS mit den letzten 30 Jobs dieses Pakets und dem Live-Protokoll des ausgewählten Jobs. Mit × schließt du es, mit „Jobs ▴“ öffnest du es wieder.

Werkzeugleiste des control-Reiters

Bauen, Speichern und Installieren … siehst du nur mit mindestens der Rolle Packager. Bauen, Installieren und Exportieren beschreibt Bauen und verteilen . In Workbench exportieren … fragt dabei unter Configserver, in welche Workbench geschrieben wird. Den Abgleich mit der Workbench beschreibt Mit Workbench abgleichen .

Speichern und ungespeicherte Änderungen

Änderungen im Formular landen erst mit Speichern auf dem Server. oPBWeb zeigt nach dem Speichern kurz „Gespeichert“.

Willst du den Editor oder die Version mit ungespeicherten Änderungen verlassen, fragt oPBWeb nach: „Es gibt ungespeicherte Änderungen. Trotzdem verlassen?“. Auch der Browser warnt beim Schließen des Tabs.

Abschnitt Produkt

Produkt

Scripte je Aktion

Für jede Aktion (setup, uninstall, update, always, once, custom, userLogin) wählst du das Script aus. Zur Auswahl stehen „—“ (kein Script) und alle Script-Dateien unter CLIENT_DATA/ mit den Endungen .opsiscript, .ins und .opsiinc.

Verweist die control-Datei auf ein Script, das es nicht gibt, steht dahinter „(Datei fehlt)“. So ein Paket lässt sich nicht bauen, bis du die Datei anlegst oder die Auswahl änderst.

Paket

Änderst du das Format, erscheint der Hinweis „Beim Speichern wird das Format des Pakets umgestellt. Die Quelltext-Ansicht zeigt das Ergebnis vorher.“ Steht beim Wechsel auf TOML der Changelog noch auf „eingebettet“, legt oPBWeb ihn beim Speichern als changelog.txt ab.

Diese Version löschen

Unter dem Abschnitt Produkt findest du als Packager die Schaltfläche Diese Version löschen. Sie funktioniert auch bei freigegebenen Versionen. Details stehen in Pakete .

Abschnitt Abhängigkeiten

Hier legst du fest, welche anderen Produkte vor oder nach diesem Produkt installiert sein müssen.

1. Klick auf + Abhängigkeit. Eine neue Zeile mit „setup / setup / before“ erscheint.
2. Füll die Spalten aus:
   • Für Aktion: Bei welcher Aktion dieses Produkts die Abhängigkeit gilt (setup, uninstall, update, always, once, custom, userLogin).
   • Benötigtes Produkt: Product-ID des anderen Produkts. Bekannte Product-IDs werden beim Tippen vorgeschlagen.
   • Benötigte Aktion: Aktion, die für das andere Produkt gesetzt wird, oder „—“.
   • Benötigter Status: installed, not_installed, unknown oder „—“.
   • Reihenfolge: before (vorher), after (nachher) oder „—“.
   • Version: optional, die benötigte Version.
3. Klick auf Speichern.

Pro Abhängigkeit muss entweder eine benötigte Aktion oder ein benötigter Status angegeben sein. Mit × am Zeilenende entfernst du eine Abhängigkeit.

Abschnitt Properties

Properties sind Einstellungen, die opsi-Administratoren pro Client oder Depot setzen können und die deine Scripte auslesen.

Property anlegen oder bearbeiten

1. Klick auf + Property. oPBWeb legt ein Property property_<n> vom Typ unicode an und klappt den Editor auf. Ein Klick auf ▸ klappt ein vorhandenes Property auf.
2. Füll die Felder aus:
   • Name: Buchstaben, Ziffern, _, . und -; jeder Name darf in der Version nur einmal vorkommen.
   • Typ: unicode (Text) oder bool (true/false).
   • Bei unicode: Mehrfachwerte (mehrere Werte gleichzeitig wählbar) und editierbar (eigene Werte erlaubt).
   • Beschreibung.
   • Bei unicode: Werte unter „Werte · Klick markiert/entfernt Default“. Tipp einen Wert in „Wert hinzufügen …“ und drück Enter. Ein Klick auf einen Wert markiert ihn als Default oder hebt das auf, × entfernt ihn.
   • Bei bool: Default true oder false.
3. Klick auf Speichern.

Scripte prüfen

Scripte prüfen durchsucht alle Scripte des Pakets nach GetProductProperty, GetConfidentialProductProperty und GetProductPropertyList und vergleicht die gelesenen Properties mit den definierten:

• „… im Script gelesene Properties fehlen im control:“ listet Properties, die ein Script liest, die aber nicht definiert sind, mit Fundstelle (Datei und Zeile) und dem im Script verwendeten Default. Mit Anlegen übernimmst du ein Property direkt.
• „Von keinem Script gelesen: …“ nennt definierte Properties, die kein Script verwendet.
• „Alle … gelesenen Properties sind definiert.“ bedeutet: alles passt.

Geprüft werden nur die Scripte dieses Pakets, nicht die uib-Bibliotheken auf dem Client. Die Prüfung kannst du auch als Leser starten; Anlegen braucht einen Entwurf und die Rolle Packager.

Abschnitt Changelog

Ein Etikett neben der Überschrift nennt, wo der Changelog liegt (OPSI/changelog.md, OPSI/changelog.txt oder OPSI/control [Changelog]). Daneben schaltest du zwischen Einträge und Freitext um.

Einträge

Entspricht der Changelog der Standardform, öffnet oPBWeb ihn als Liste der Einträge. Standardform heißt:

• txt und eingebettet (Debian-Stil, wie im opsiPackageBuilder): je Eintrag die Kopfzeile produkt (version) status; urgency=dringlichkeit, der Text und die Fußzeile -- Name <E-Mail> Datum.
• md (Format des opsi-setup-detectors): optional ein Titel # Changelog …, dann je Eintrag ## [version] - Datum, der Text und (Name <E-Mail>).

Ein Klick auf eine Zeile klappt den Eintrag auf. Dort änderst du Version, Status und Dringlichkeit (nur Debian-Stil), Text, Autor, E-Mail und Datum; Jetzt setzt das aktuelle Datum. Mit ↑ und ↓ verschiebst du einen Eintrag, × löscht ihn nach einer Rückfrage. Gespeichert wird mit Speichern in der Werkzeugleiste. Unveränderte Einträge schreibt oPBWeb zeichengenau zurück, eine Änderung betrifft also nur die Zeilen des geänderten Eintrags.

Freitext

Im Freitext bearbeitest du den Changelog direkt im Texteditor; speichern kannst du mit Speichern oder Strg S. Weicht der Text von der Standardform ab, steht darüber „Der Changelog entspricht nicht der Standardform. Bearbeiten ist nur als Freitext möglich.“ und Einträge ist gesperrt. Sobald der Text wieder der Standardform entspricht, kannst du zurückschalten.

Eintrag hinzufügen

1. Klick auf + Eintrag für … (die aktuelle Version steht im Namen der Schaltfläche).
2. Trag im Dialog „Neuer Changelog-Eintrag“ unter Änderungen (eine pro Zeile) deine Änderungen ein.
3. Bei txt- und eingebettetem Changelog: Wähl Status (testing, stable, unstable; Standard testing) und Dringlichkeit (low, medium, high, critical; Standard low).
4. Klick auf Hinzufügen.

Der Eintrag wird oben eingefügt, mit deinem Namen, deiner E-Mail-Adresse und dem aktuellen Datum. Hast du keine E-Mail-Adresse hinterlegt, verwendet oPBWeb benutzername@<Mail-Domain> aus den Einstellungen. In der Ansicht Einträge ist der neue Eintrag danach aufgeklappt und wird mit Speichern gespeichert; im Freitext speichert oPBWeb ihn sofort.

Mit Workbench abgleichen

Rollen: Packager, Releaser, Administrator

Manchmal ändert jemand ein Paket direkt in der Workbench eines Configservers, zum Beispiel ein Script, und baut es dort neu. Mit ⋯ › Mit Workbench abgleichen … holst du solche Änderungen in die Version in oPBWeb, damit sie nicht verloren gehen.

Der Abgleich geht nur in eine Richtung, von der Workbench nach oPBWeb, und bietet nur an, was auf der Workbench neuer ist. Später in oPBWeb geänderte Dateien überschreibt er nicht, Dateien, die auf der Workbench fehlen, löscht er nicht.

1. Öffne die Version im Editor und wähl ⋯ › Mit Workbench abgleichen …. Der Dialog „Abgleich mit der Workbench: firefox 128.0-1“ öffnet sich und vergleicht sofort.

2. Prüf oben die Vorgaben und klick nach einer Änderung auf Vergleichen:

   • Configserver: der Server, dessen Workbench verglichen wird.
   • Projektordner: vorbelegt mit dem Ordner, aus dem die Version importiert wurde, sonst mit der Product-ID.
   • Der Chip Nur Unterschiede (voreingestellt aktiv) blendet gleiche Dateien aus.

3. Prüf die Tabelle mit den Spalten Datei, Zustand, Workbench geändert und oPBWeb geändert (Zeitpunkt der letzten Änderung):

   Zustand	Bedeutung	Übernehmbar
   „neu auf der Workbench“	Die Datei gibt es nur auf der Workbench.	ja, vorausgewählt
   „auf der Workbench neuer“	Die Datei wurde auf der Workbench später geändert als in oPBWeb.	ja, vorausgewählt
   „in oPBWeb neuer“	Die Datei wurde in oPBWeb später geändert.	nein, wird nie überschrieben
   „nur in oPBWeb“	Die Datei fehlt auf der Workbench.	nein, wird nie gelöscht
   „gleich“	kein Unterschied	–

   Ein Klick auf eine Zeile mit ▸ zeigt die Unterschiede: rot ist der Stand in oPBWeb, grün der Stand auf der Workbench. Unten steht eine Zusammenfassung wie „Übernehmbar: 2 · gleich: 14“.

4. Entferne die Häkchen bei allem, was du nicht übernehmen willst, und klick auf Übernehmen (n).

Nach dem Übernehmen meldet oPBWeb „Änderungen aus der Workbench übernommen“, vergleicht erneut und lädt die Version im Editor neu. Verglichen werden nur die Ordner OPSI/, CLIENT_DATA/ und SERVER_DATA/; alte Sicherungen control-*.bak werden ignoriert. Vergleich und Übernahme laufen als Jobs („Abgleich mit Workbench (Server): …“, „Aus Workbench übernehmen (Server): …“).

control-Daten

control-Datei und Changelog-Datei erscheinen gemeinsam als eine Zeile „control-Daten (control, changelog.txt)“. oPBWeb vergleicht hier die Daten, nicht den Text: Eine andere Formatierung, etwa andere Leerzeichen, zählt nicht als Unterschied. Übernimmst du diese Zeile, ersetzt oPBWeb Produktdaten, Abhängigkeiten, Properties und Changelog der Version durch den Stand der Workbench.

Freigegebene Versionen

Übernehmen kannst du nur in einen Entwurf. Bei einer freigegebenen Version zeigt der Dialog die Unterschiede, meldet aber „Diese Version ist freigegeben. Zum Übernehmen erst eine neue Version anlegen und diese abgleichen.“ Leg dann mit Neue Version eine neue Version an und gleiche diese ab.

Quelltext-Ansicht

Quelltext zeigt die control-Datei und den Changelog so, wie sie beim Bauen erzeugt werden. Die Ansicht ist nur zum Lesen und steht allen Rollen zur Verfügung.

• Links findest du die GLIEDERUNG (die Abschnitte der Datei, ein Klick springt hin) und die DATEIEN (OPSI/control bzw. OPSI/control.toml und gegebenenfalls den Changelog).
• Mit INI | TOML wählst du das Format. Entspricht es dem Format des Pakets, steht dort „Wird beim Bauen so erzeugt – nur Anzeige“. Wählst du das andere Format, siehst du eine „Vorschau einer Konvertierung – nur Anzeige“. So prüfst du vor einem Formatwechsel, was dabei herauskommt.
• Kopieren legt den Text in die Zwischenablage, Herunterladen speichert ihn als Datei.

Die Quelltext-Ansicht zeigt den gespeicherten Stand. Ungespeicherte Änderungen im Formular siehst du dort erst nach dem Speichern.

Freigegebene Versionen

Sobald eine Version auf einem Depot installiert wurde, ist sie freigegeben und schreibgeschützt. Oben im Editor erscheint dann:

Version … ist freigegeben (installiert) und schreibgeschützt. Für Änderungen eine neue Version anlegen oder zurück auf Entwurf setzen.

In diesem Zustand gilt:

• Alle Felder, Tabellen und Texteditoren sind gesperrt, Speichern und Bauen fehlen.
• .opsi herunterladen und Installieren … bleiben verfügbar, ebenso die Quelltext-Ansicht.
• Als Packager hast du im Hinweisbalken zwei Wege zurück zum Bearbeiten: