Benutzerhandbuch

• Erste Schritte
• Pakete
• Paket aus Installer erzeugen
• Paket-Editor
• Dateien des Pakets
• Scripteditor
• Bauen und verteilen
• Snippets
• Depots
• Jobs
• Konto und Sprache

Erste Schritte

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Dieses Kapitel zeigt dir, wie du dich anmeldest, wie die Oberfläche von oPBWeb aufgebaut ist und wie du mit der Suche schnell zu Paketen, Dateien und Befehlen springst. Am Ende findest du eine kurze Übersicht über Rollen und den Lebenszyklus eines Pakets.

Anmelden

1. Öffne oPBWeb im Browser. Ohne gültige Sitzung landest du auf der Anmeldeseite.
2. Gib deinen Benutzernamen und dein Passwort ein.
3. Klick auf Anmelden.

Nach der Anmeldung öffnet sich die Paketliste, oder die Seite, die du ursprünglich aufrufen wolltest. Auf der Anmeldeseite kannst du oben in der Ecke schon die Sprache (DE/EN) und Hell/Dunkel umschalten.

Deine Sitzung bleibt bis zu sieben Tage erhalten, solange du dich nicht abmeldest. Abmelden kannst du dich über das Avatar-Menü, siehe Konto und Sprache .

Aufbau der Oberfläche

Die Oberfläche ist wie eine Entwicklungsumgebung aufgebaut: oben die Kopfleiste, links die Bereichsleiste, in der Mitte der Arbeitsbereich und unten die Statusleiste.

Kopfleiste

Von links nach rechts findest du:

Bereichsleiste

Über die Bereichsleiste links wechselst du zwischen den Bereichen:

Ohne Beschriftung zeigt die Leiste nur Symbole; fahr mit der Maus darüber, um den Namen als Tooltip zu sehen.

Statusleiste

Die Statusleiste unten zeigt links die Versionen von Frontend und Backend. Ist der Server nicht erreichbar, steht dort „Backend nicht verbunden“.

Daneben erscheint ein orangefarbener Hinweis, wenn mit einem Configserver etwas zu tun ist, etwa „Kein Configserver eingerichtet“, „Configserver 1: neues CA-Zertifikat“ oder „Configserver 1: CA läuft in 30 Tagen ab“. Für Administratoren führt der Hinweis in die Ansicht Depots. Rechts siehst du den Fortschritt der Jobs, die du in diesem Browser-Tab gestartet hast. Ein Klick darauf öffnet den Job im Bereich Jobs .

Bereiche in der Breite anpassen

Viele Ansichten sind in Bereiche geteilt, zum Beispiel Paketliste und Paketdetails. Die Trennlinien kannst du verschieben:

• Ziehen mit der Maus ändert die Breite.
• Mit Fokus auf der Trennlinie verschieben die Pfeiltasten sie um 20 Pixel.
• Ein Doppelklick setzt die Breite zurück.

oPBWeb merkt sich die Breiten in deinem Browser.

Suche

Mit der Suche springst du per Tastatur zu Paketen, Dateien und Befehlen, ohne zu klicken.

1. Drück Strg K (am Mac ⌘ K) oder klick in das Suchfeld „Paket, Datei oder Befehl …“.
2. Tipp ein paar Buchstaben ein.
3. Wähl mit den Pfeiltasten ↑ und ↓ einen Treffer aus und drück Enter. Mit Esc schließt du die Suche.

Die Treffer sind in Gruppen sortiert, höchstens 14 auf einmal:

Exakte Treffer stehen vor Treffern am Wortanfang, danach folgen Treffer irgendwo im Namen. Findet die Suche nichts davon, sucht sie unscharf (die Buchstaben in dieser Reihenfolge, auch mit Lücken).

Rollen im Überblick

Was du in oPBWeb tun darfst, legt deine Rolle fest:

Die ausführliche Tabelle findest du in der Übersicht des Benutzerhandbuchs .

Lebenszyklus in einem Bild

Entwurf ──Bauen (beliebig oft)──► „gebaut“
   ▲                                │ Installieren …
   │                                ▼
   └──── Zurück auf Entwurf ──── Freigegeben (schreibgeschützt)
                                    │ Neue Version
                                    ▼
                              neuer Entwurf (Kopie)

Ein Entwurf lässt sich bearbeiten und bauen. Erst das Installieren auf einem Depot gibt die Version frei. Wie das im Einzelnen abläuft, steht in Bauen und verteilen .

Pakete

Rollen: Leser, Packager, Releaser, Administrator

Überblick

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

Die Paketliste

Die Tabelle zeigt pro Paket die neueste Version:

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

Filtern

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

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

Paketdetails

Im rechten Bereich siehst du zum ausgewählten Paket:

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

Verteilung

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

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

Workbench

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

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

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

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

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

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

Neues Paket anlegen

Rollen: Packager, Releaser, Administrator

1. Klick in der Paketliste auf Neues Paket.

   

2. Füll die Felder aus:

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

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

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

.opsi-Dateien importieren

Rollen: Packager, Releaser, Administrator

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

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

   

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

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

4. Klick auf Import starten.

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

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

Aus der Workbench importieren

Rollen: Packager, Releaser, Administrator

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

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

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

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

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

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

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

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

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

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

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

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

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

Installierte Versionen freigeben

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

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

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

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

Ordner ignorieren

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

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

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

Übergabe vom opsi-setup-detector

Rollen: Packager, Releaser, Administrator

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

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

Launcher von Hand einrichten

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

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

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

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

4. Hinterleg einmalig die Adresse von oPBWeb:

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

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

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

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

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

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

Launcher als opsi-Paket verteilen

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

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

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

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

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

Übergabe nutzen

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

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

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

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

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

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

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

Meta-Paket anlegen

Rollen: Packager, Releaser, Administrator

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

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

   

2. Füll links die Felder aus:

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

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

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

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

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

Version löschen

Rollen: Packager, Releaser, Administrator

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

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

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

Paket archivieren

Rollen: Packager, Releaser, Administrator

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

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

Ein archiviertes Paket

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

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

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

Paket löschen

Rollen: Packager, Releaser, Administrator

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

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

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

Paket aus Installer erzeugen

Rollen: Packager, Releaser, Administrator

Überblick

Der Assistent Aus Installer … in der Paketliste macht in oPBWeb, was sonst der opsi-setup-detector auf deinem Rechner erledigt: Er analysiert einen Installer, schlägt Product-ID, Version, Installations- und Deinstallationsbefehl vor und erzeugt aus den Script-Vorlagen des opsi-setup-detectors ein vollständiges Paket. Das Paket landet als Entwurf in oPBWeb, der Installer liegt schon in CLIENT_DATA/files1.

Du brauchst dafür weder den opsi-setup-detector noch eine Workbench-Freigabe auf deinem Rechner. Wer lieber mit dem opsi-setup-detector arbeitet, nutzt weiter die Übergabe über den Launcher ; beide Wege führen zum selben Ergebnis, einem Entwurf in oPBWeb.

Die Analyse und das Erzeugen laufen als Jobs im Worker. Den Fortschritt siehst du im Assistenten und unter Jobs („Installer analysieren: …“, „Paket aus Installer anlegen: …“).

Der Assistent im Überblick

Klick in der Werkzeugleiste der Paketliste auf Aus Installer …. Der Dialog „Neues Paket aus Installer“ führt dich durch vier Schritte:

Mit Zurück gehst du einen Schritt zurück, ein Klick auf einen erledigten Schritt oben springt direkt dorthin. Bei den Vorlagen-Arten ohne Installer entfällt der Schritt Analyse.

Beim ersten Öffnen des Assistenten erscheint vorher einmalig der Hinweis „Hinweis zum Funktionsumfang“: Der Assistent kann weniger als der originale opsi-setup-detector, die Unterschiede stehen unter Einschränkungen . Derselbe Hinweis erscheint auch vor dem ersten Installer analysieren im Paket-Editor, falls du ihn noch nicht bestätigt hast. Nach Verstanden merkt sich oPBWeb das an deinem Benutzerkonto; der Hinweis kommt also auch in einem anderen Browser nicht wieder. Unter Mein Konto kannst du ihn mit Wieder anzeigen wieder einschalten.

Schritt 1: Quelle

1. Wähl unter Art des Pakets, was entstehen soll (Tabelle unten). Unter dem Feld steht jeweils ein kurzer Hinweis zur gewählten Art.
2. Wähl das Ziel-Betriebssystem (Windows, Linux oder macOS). Das Feld ist nur bei den Arten aktiv, die für ein einzelnes Betriebssystem gelten.
3. Wähl den Vorlagenkanal. Vorbelegt ist der Kanal aus den Einstellungen :
   • Training (ausführlich kommentiert): Scripte mit vielen Erklärungen, gut zum Lernen.
   • Standard: die Vorlagen, die der opsi-setup-detector normalerweise verwendet.
   • Strukturiert: Scripte, die stärker in einzelne Dateien aufgeteilt sind.
   • Eigene (custom): eure eigenen Vorlagen. Was dort fehlt, nimmt der Generator aus Standard, siehe Vorlagen .
4. Gib für jeden Installer an, woher er kommt:
   • Hochladen: Zieh die Datei in das Feld „Installer hierher ziehen oder auswählen“ oder klick auf Datei auswählen ….
   • Aus der Workbench: Gib unter Pfad relativ zur Workbench den Pfad ab dem Projektordner an, zum Beispiel firefox/CLIENT_DATA/files1/setup.exe. Sind mehrere Configserver eingerichtet, wählst du darüber den Configserver. Mit Ganzen Ordner übernehmen kopiert oPBWeb beim Erzeugen alle Dateien aus dem Ordner des Installers (mit Unterordnern) nach files1 bzw. files2, files3, etwa für Installer mit Zusatzdateien.
5. Bei einer .msi-Datei kannst du eine MST-Datei (optional) angeben: beim Hochladen in einem zweiten Feld, bei der Workbench nur mit ihrem Namen (sie muss im selben Ordner liegen). Der Installationsbefehl bekommt dann TRANSFORMS=….
6. Stell bei Bedarf die beiden Analyseoptionen um (vorbelegt aus den Einstellungen):
   • Silent- statt Unattended-Parameter verwenden: Der Installer läuft ganz ohne Fenster statt mit Fortschrittsanzeige.
   • MSI-Wrapper über msiexec deinstallieren, wenn die MSI-Daten bekannt sind: Bei Installern mit eingebettetem MSI deinstalliert das Paket über msiexec /x mit dem ProductCode.
7. Klick auf Analysieren. Bei den Vorlagen-Arten heißt die Schaltfläche Weiter.

Fehlt etwas, nennt der Dialog es unter den Feldern, zum Beispiel „Installer: Datei oder Workbench-Pfad fehlt.“

Arten von Paketen

Schritt 2: Analyse

oPBWeb lädt die Installer hoch und startet für jeden einen Analyse-Job. Neben dem Dateinamen zeigt ein Abzeichen den Stand: „lädt hoch“, „analysiert“ mit Prozentangabe, „analysiert ✓“ oder „fehlgeschlagen“. Unter Protokoll steht das Job-Protokoll. Weiter wird erst aktiv, wenn alle Analysen fertig sind.

Für jeden Installer zeigt der Dialog:

• Typ: der erkannte Installertyp, zum Beispiel „Inno Setup“ oder „Nullsoft Install System“. Haben die Regeln mehrere Typen gefunden, steht darunter „Ebenfalls erkannt: …“. Erkennt oPBWeb den Typ falsch oder gar nicht, wählst du ihn hier aus; das startet eine neue Analyse mit diesem Typ („Typ von Hand gewählt“). automatisch erkennen schaltet zurück.
• Hinweis des Detectors: die Erklärung des opsi-setup-detectors zu diesem Installertyp, oft mit Link zur Dokumentation des Herstellers.
• Fundstellen: die Erkennungsmuster, die in der Datei gefunden wurden.
• Ergebnis von Detect-It-Easy: nur, wenn Detect-It-Easy im Worker installiert ist (siehe Grenzen ).
• Hinweise der Analyse, zum Beispiel „Installertyp nicht erkannt. Bitte den Typ von Hand wählen.“
• Die Felder, die der Generator verwendet: Product-ID, Produktname, Produktversion, Installationsverzeichnis, Architektur, Hauptprogramm (für das Desktop-Icon), Installationsbefehl, Deinstallationsbefehl, Deinstallationsprogramm, Über msiexec deinstallieren, Platzbedarf, bei MSI MSI-ProductCode und MSI-UpgradeCode sowie Prüfung „installiert?“ (opsi-script-Zeilen, die prüfen, ob die Software schon installiert ist).

Alle Felder kannst du ändern; der Generator übernimmt deine Werte. Mit Erneut analysieren startest du die Analyse noch einmal, etwa nachdem du Silent- statt Unattended-Parameter verwenden umgestellt hast.

Was die Analyse je Installertyp findet

Den Typ erkennt oPBWeb wie der opsi-setup-detector an Textmustern in der Datei. Grundlage ist die Installertabelle des opsi-setup-detectors mit rund 30 Typen; aus ihr kommen auch die Silent- und Unattended-Parameter, das Deinstallationsprogramm und die Funktion, die Exit-Codes bewertet. Danach liest oPBWeb je nach Typ weitere Angaben aus:

Grenzen der Analyse

• Inno Setup: Den Setup-Header liest das Werkzeug innoextract. Neue Inno-Versionen, die innoextract noch nicht kennt, liefern „Der Inno-Setup-Header konnte nicht gelesen werden (innoextract).“ Installationsverzeichnis und Deinstallationsprogramm sind dann Standardannahmen; prüf sie.
• MSI in Wrapper-Installern: Der opsi-setup-detector führt solche Installer unter Windows aus, um das MSI auszupacken. oPBWeb führt keine Installer aus, sondern versucht es mit 7-Zip. Findet 7-Zip kein MSI („7-Zip hat kein eingebettetes MSI gefunden …“), fehlen die MSI-Angaben, und das Paket deinstalliert über das Deinstallationsprogramm des Installers. Sind mehrere MSI-Dateien drin, wertet oPBWeb die erste aus und nennt alle.
• Detect-It-Easy: Der opsi-setup-detector holt sich bei unbekannten Dateien eine zweite Meinung von Detect-It-Easy. Im Image von oPBWeb ist es nicht enthalten; ohne Detect-It-Easy bleibt es bei der Erkennung über die Muster. Wie man es nachrüstet, steht in der Konfiguration .
• Nur unter Windows: Was der opsi-setup-detector durch Ausführen des Installers auf einem Windows-Rechner herausfindet, kann oPBWeb nicht ermitteln. Prüf deshalb vor allem bei unbekannten Typen Installationsverzeichnis, Deinstallationsprogramm und die Prüfung „installiert?“.

Schritt 3: Produkt

Product-ID, Name, Produktversion und Beschreibung sind aus der Analyse vorbelegt, Paketversion, Priorität, Format control und Changelog aus den Einstellungen für neue Pakete . Für die Felder gelten dieselben Regeln wie bei Neues Paket. Unter den Feldern zeigt oPBWeb, ob es die Product-ID oder die Version schon gibt, zum Beispiel „firefox gibt es in oPBWeb bereits; die Version wird neu angelegt.“

Optionen

Die Optionen schalten zusätzliche Bausteine der Vorlagen ein:

Desktop-Icon und Lizenzschlüssel-Property sind vorausgewählt, wenn ein Administrator das in den Einstellungen so festgelegt hat.

Properties und Standard-Properties

Unter Properties stehen die vorbelegten Properties aus den Einstellungen. Du kannst sie ändern, löschen und mit Property hinzufügen ergänzen (Name, Typ, Standardwert, Mögliche Werte kommagetrennt, Beschreibung, Frei). Jeder Name darf nur einmal vorkommen.

Die Properties, die zu den gewählten Optionen und zur Art des Pakets gehören, ergänzt der Generator selbst. Du musst sie nicht anlegen:

Abhängigkeiten, Changelog und Produktbild

• Abhängigkeiten: Mit Abhängigkeit hinzufügen trägst du je Zeile unter Benötigtes Produkt das Produkt ein, unter Benötigt eine Aktion oder einen Zustand dieses Produkts und unter Reihenfolge before, after oder „egal“. Die Abhängigkeiten gelten für die Aktion setup; ändern kannst du sie später im Paket-Editor .
• Changelog-Eintrag: Text des ersten Changelog-Eintrags. Leer lassen ergibt den Standardtext des Generators.
• Produktbild (PNG): Mit PNG auswählen … lädst du ein eigenes Bild hoch. Ohne eigenes Bild bekommt das Paket das Standardbild des Betriebssystems aus den Vorlagen.

Schritt 4: Erzeugen

Der letzte Schritt fasst Art, Vorlagenkanal, Product-ID, Version, Installer und die Zahl der Properties zusammen und prüft, ob es das Paket schon gibt. Je nach Lage bietet er an:

Nach dem Klick zeigt der Dialog den Fortschritt („Erzeuge das Paket … 40 %“) und das Job-Protokoll. Der Job erzeugt die Produktdateien aus den Vorlagen, kopiert die Installer nach CLIENT_DATA/files1 (bzw. files2, files3) und legt alles als neue Entwurfsversion an. Danach meldet er „firefox 128.0-1 ist als Entwurf angelegt.“ Klick auf Im Editor öffnen, um das Paket zu prüfen, zu bauen und zu testen.

In den Paketdetails steht als Herkunft „opsi-setup-detector“.

Warnungen des Jobs stehen unter der Erfolgsmeldung:

• „Vorlage … fehlt, der Baustein wird ausgelassen“: Im gewählten Kanal, in Standard und in default/generic gibt es die Datei nicht, etwa weil ein Administrator sie gelöscht hat.
• „Nicht ersetzte Platzhalter in den erzeugten Dateien: …“: Eine Vorlage enthält einen Platzhalter, für den der Generator keinen Wert hat. Such ihn im Editor und ersetz ihn von Hand.

Installer im Paket analysieren

Liegt ein Installer schon in einem Paket, analysierst du ihn im Paket-Editor über das Kontextmenü des Dateibaums mit Installer analysieren, siehe Dateien des Pakets . Das Ergebnis ist dort nur eine Anzeige, es ändert das Paket nicht. Hast du den „Hinweis zum Funktionsumfang“ noch nicht bestätigt, erscheint er vor der ersten Analyse; die Einschränkungen gelten auch hier.

Einschränkungen gegenüber dem opsi-setup-detector

Der Assistent übernimmt Analyse und Paketerzeugung des opsi-setup-detectors, läuft aber im Worker-Container unter Linux und nicht auf einem Windows-Rechner. Daraus und aus dem Umfang der Portierung ergeben sich diese Unterschiede:

Wann der opsi-setup-detector die bessere Wahl ist

Nimm den opsi-setup-detector unter Windows, wenn

• ein Wrapper-Installer sein MSI nur beim Ausführen herausgibt und du die MSI-Angaben brauchst,
• der Installer exotisch ist und nur Detect-It-Easy ihn erkennt (und es in deinem oPBWeb nicht nachgerüstet ist),
• ein Inno-Setup-Installer so neu ist, dass oPBWeb seinen Header nicht lesen kann,
• die Dateien lokal liegen und du sie nicht erst hochladen oder in die Workbench legen willst, oder ein .app-Bundle als Ordner vorliegt,
• du mit Projektdateien oder im Batch-Betrieb arbeitest,
• du ein winget-Paket oder ein Paket mit Installation im Benutzerkontext brauchst, solange diese Arten in oPBWeb nicht auf einem Client geprüft sind.

Das Ergebnis des opsi-setup-detectors landet trotzdem in oPBWeb: Über den Launcher übernimmt oPBWeb den erzeugten Projektordner aus der Workbench, siehe Übergabe vom opsi-setup-detector .

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. Liegt das Projekt in einem Gruppenordner, gib den Pfad an, zum Beispiel develop/firefox.
   • 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:

Dateien des Pakets

Rolle: Packager

Überblick

Jede Paketversion besteht aus den drei Bereichen OPSI/, CLIENT_DATA/ und SERVER_DATA/. Im Paket-Editor siehst du sie links unter dem Reiter Dateien. Dort legst du Dateien und Ordner an, lädst Installer hoch, benennst um, verschiebst und löschst. Der Reiter Struktur daneben zeigt, welche Scripte welche anderen Scripte einbinden.

Ändern kannst du Dateien nur in einer Version mit dem Status Entwurf und mit mindestens der Rolle Packager. In freigegebenen Versionen und mit der Rolle Leser ist der Dateibaum schreibgeschützt: Öffnen und Herunterladen funktionieren weiterhin, alle ändernden Einträge im Kontextmenü sind ausgegraut.

Der Dateibaum

Die drei Bereiche stehen immer oben im Baum. OPSI/ und CLIENT_DATA/ sind beim Öffnen aufgeklappt. Ein Bereich ohne Inhalt trägt den Vermerk „leer“. Bei Binärdateien steht die Dateigröße hinter dem Namen.

• Ein Klick auf eine Datei öffnet sie als Reiter im Editor. Textdateien bis 5 MB öffnen sich im Scripteditor .
• Bilder (PNG, JPG, GIF, BMP, ICO, SVG bis 10 MB) zeigt oPBWeb als Vorschau an.
• Für andere Binärdateien und zu große Textdateien siehst du Pfad, Größe, SHA-256 und Art („Binärdatei“ bzw. „Textdatei, zu groß für den Editor“) sowie die Schaltfläche Herunterladen.

Die Bereiche selbst kannst du weder umbenennen noch löschen.

Das Kontextmenü

Ein Rechtsklick auf eine Datei oder einen Ordner öffnet das Kontextmenü.

Bei einem Rechtsklick auf eine Datei beziehen sich Neue Datei, Neuer Ordner und Dateien hochladen … auf den Ordner, in dem die Datei liegt.

Ein Rechtsklick auf die freie Fläche unterhalb der Einträge zeigt nur Neue Datei, Neuer Ordner und Dateien hochladen …; Ziel ist dann CLIENT_DATA/.

Neue Datei anlegen

1. Klick mit der rechten Maustaste auf den Zielordner, z. B. CLIENT_DATA/.
2. Wähl Neue Datei.
3. Gib im Feld „Name in CLIENT_DATA/“ den Dateinamen ein, z. B. install.opsiinc.
4. Bestätige den Dialog. Die Datei wird angelegt und erscheint im Baum.

Dateien hochladen

Du hast zwei Wege, um Dateien ins Paket zu bringen:

• Per Kontextmenü: Rechtsklick auf den Zielordner, dann Dateien hochladen …. Du kannst mehrere Dateien auf einmal auswählen.
• Per Drag & Drop: Zieh Dateien oder ganze Ordner aus deinem Dateimanager auf einen Ordner im Baum. Die Ordnerstruktur bleibt dabei erhalten. Lässt du sie auf eine Datei fallen, landen sie in deren Ordner; lässt du sie auf eine freie Fläche des Baums fallen, landen sie in CLIENT_DATA/.

Während des Hochladens zeigt ein Fortschrittsbalken den Stand. Danach meldet oPBWeb „3 Datei(en) hochgeladen“. Eine vorhandene Datei mit gleichem Pfad wird ohne Rückfrage ersetzt.

Ausführbare Dateien

Ob eine Datei ausführbar ist (z. B. ein Shell-Script unter Linux), zeigt der Dateibaum nicht an. oPBWeb übernimmt das Kennzeichen beim Import eines .opsi-Pakets und setzt es beim Bauen wieder. Beim Import aus der Workbench werden .sh- und .py-Dateien in CLIENT_DATA/ automatisch als ausführbar markiert.

MSI-Informationen

Für .msi-Dateien liest oPBWeb die wichtigsten Eigenschaften direkt aus dem Installer. Das ist praktisch, um ProductCode und Version für dein Script zu übernehmen.

1. Klick mit der rechten Maustaste auf die .msi-Datei.
2. Wähl MSI-Informationen. Der Dialog „MSI: setup.msi“ zeigt kurz „Lese MSI-Datei …“ und dann eine Tabelle, u. a. mit ProductName, ProductVersion, ProductCode, UpgradeCode, Manufacturer und ProductLanguage.
3. Klick neben einem Wert auf Kopieren, um ihn in die Zwischenablage zu übernehmen. Der Knopf zeigt kurz „kopiert“.
4. Mit Alle Properties anzeigen (24) blendest du die vollständige Property-Tabelle des Installers ein, mit Weniger anzeigen wieder aus.

Installer analysieren

Rollen: Packager, Releaser, Administrator

Für Installer in CLIENT_DATA/ (.exe, .msi, .msix, .appx, .appxbundle, .msixbundle, .deb, .rpm, .dmg, .pkg, .zip) zeigt das Kontextmenü Installer analysieren. oPBWeb untersucht die Datei dann so, wie es der Assistent Paket aus Installer tut: Installertyp, Product-ID, Version, Installationsverzeichnis, Installations- und Deinstallationsbefehl, MSI-Angaben und die Prüfung, ob die Software installiert ist. Vor der ersten Analyse erscheint einmalig der „Hinweis zum Funktionsumfang“; er lässt sich unter Mein Konto wieder einschalten.

1. Klick mit der rechten Maustaste auf den Installer, zum Beispiel CLIENT_DATA/files1/setup.exe.
2. Wähl Installer analysieren. Der Dialog „Installer-Analyse: setup.exe“ startet einen Analyse-Job und zeigt den Fortschritt („Analysiere … 40 %“) und das Protokoll.
3. Prüf das Ergebnis. Bei Bedarf stellst du das Ziel-Betriebssystem oder Silent- statt Unattended-Parameter verwenden um und klickst auf Erneut analysieren.

Das Ergebnis ist nur eine Anzeige: Es ändert das Paket nicht. Werte wie den Deinstallationsbefehl oder den MSI-ProductCode übernimmst du von Hand in deine Scripte. Das funktioniert auch in freigegebenen Versionen. Für ein neues Paket aus diesem Installer nutze Aus Installer … in der Paketliste.

Der Reiter Struktur

Der Reiter Struktur zeigt, wie die Scripte des Pakets zusammenhängen. Ausgangspunkt sind die Scripte, die im control für die einzelnen Aktionen (setup, uninstall, update …) eingetragen sind.

• Für jede Aktion siehst du das zugehörige Script. Ist die Datei nicht vorhanden, steht dort „fehlt“.
• Eingerückt darunter folgen die Dateien, die das Script einbindet, jeweils mit der Art der Einbindung (sub, include_insert, include_append, importLib).
• Ein Abzeichen gibt die Herkunft an: Paket (Datei liegt im Paket), Bibliothek (uib-Bibliothek von opsi-script auf dem Client) oder fehlt (nicht gefunden).
• Das Zeichen ↺ markiert eine rekursive Einbindung.
• Ein Klick auf einen Eintrag öffnet die Datei im Editor.
• Mit ⟳ (Neu laden) aktualisierst du die Ansicht, z. B. nachdem du ein Script gespeichert hast.

Sind im control keine Aktions-Scripte hinterlegt, erscheint „Keine Aktions-Skripte im Control hinterlegt.“

Scripteditor

Rolle: Packager

Überblick

Textdateien des Pakets öffnest du per Klick im Dateibaum (siehe Dateien des Pakets ). Sie erscheinen als eigener Reiter neben dem Reiter control im Scripteditor. Für opsi-Scripte bietet der Editor Vervollständigung, Fehlerprüfung, Hilfe zu den Befehlen und Snippets. Alle anderen Textformate bekommen eine Syntaxhervorhebung. Die Farben der Hervorhebung legst du pro Dateityp unter Mein Konto fest.

Bearbeiten kannst du Dateien nur in einer Version mit dem Status Entwurf und mindestens mit der Rolle Packager. Sonst ist der Editor schreibgeschützt; Lesen, Suchen, Hilfe und das Kopieren von Text funktionieren trotzdem.

Aufbau

• Werkzeugleiste des Reiters: Pfad der Datei, bei opsi-Scripten die Zähler „2 Fehler“ und „5 Warnungen“, die Schaltfläche Werkzeugleiste ausblenden bzw. Werkzeugleiste einblenden für die Seitenleiste und Speichern.
• Editorfläche: Zeilennummern, Faltmarken am Rand und bei opsi-Scripten eine Leiste mit Diagnose-Symbolen.
• Seitenleiste (nur bei opsi-Scripten) mit den Reitern Snippets, Variablen, Warnungen und Hilfe. Du kannst sie über ihren Rand breiter oder schmaler ziehen.
• Unteres Panel JOBS: zeigt rechts die Cursorposition („Z. 12, Sp. 8“) und das Zeilenende der Datei (CRLF oder LF).

Zeilenenden bleiben beim Speichern erhalten: Eine Datei mit Windows-Zeilenenden (CRLF) bleibt eine CRLF-Datei.

Unterstützte Sprachen

Die Sprache erkennt der Editor am Dateinamen.

Für opsi-script kennt der Editor den Sprachumfang aus dem opsi-script-Handbuch 4.3: Anweisungen, eingebaute Funktionen, Sektionstypen, Befehle der Sekundärsektionen und Konstanten. Dazu kommen die Funktionen der uib-Bibliotheken, die opsi-script mitbringt (z. B. uib_exitcode.opsiscript, uib_strlistutils.opsiscript, uib_backend.opsiscript, osd-lib.opsiscript).

Alle weiteren Funktionen – Vervollständigung, Diagnose, Hilfe, Kontextmenü, Snippets und Seitenleiste – gibt es nur für opsi-Scripte.

Vervollständigung

Beim Tippen schlägt der Editor passende Einträge vor. Mit Strg+Leertaste öffnest du die Liste jederzeit von Hand. Mit den Pfeiltasten wählst du aus, mit Enter übernimmst du den Eintrag.

Vorgeschlagen werden:

• Anweisungen und eingebaute Funktionen von opsi-script,
• Funktionen der uib-Bibliotheken, jeweils mit dem nötigen importLib "<datei>" als Herkunft,
• Funktionen, die im Paket selbst mit DefFunc definiert sind (siehe Funktionen des Pakets ),
• Variablen der aktuellen Datei, sobald du $ tippst,
• Konstanten wie %ScriptPath%, sobald du % tippst,
• Sektionen der Datei,
• Snippets, gekennzeichnet mit „Snippet · Allgemein“.

Übernimmst du eine Funktion, setzt der Editor die Klammern gleich mit und stellt den Cursor hinein. Innerhalb der Klammern zeigt ein kleiner Hinweis die Signatur; der Parameter, an dem du gerade schreibst, ist fett.

Hilfe zu Befehlen

Fährst du mit der Maus über einen Befehl, eine Funktion, eine Variable oder eine Konstante, erscheint ein Hinweis:

• bei Befehlen und Funktionen die Signatur und eine Kurzbeschreibung, ggf. mit „seit opsi-script 4.12“,
• bei Variablen die Art der Deklaration und „deklariert in Zeile 5“,
• bei Konstanten deren Bedeutung,
• bei Sektionsköpfen und Sektionsaufrufen wie Files_copy_config die Beschreibung des Sektionstyps, bei Befehlen innerhalb einer Sektion (z. B. copy in Files) und bei Aufruf-Modifiern wie /64Bit die Beschreibung passend zur Sektion.

Die ausführliche Hilfe steht im Reiter Hilfe der Seitenleiste: Name, Signatur, Beschreibung, Kategorie und Herkunft (z. B. die Bibliothek oder die Datei mit Zeilennummer). Der Reiter zeigt immer die Hilfe zum zuletzt angefragten Befehl, auch wenn du nur mit dem Mauszeiger darauf zeigst. Mit F1 auf dem Befehl oder über das Kontextmenü Hilfe zum Befehl springt die Seitenleiste direkt auf den Reiter Hilfe. Unten im Reiter führt ein Link zum offiziellen opsi-script-Handbuch auf docs.opsi.org, falls du etwas nachschlagen willst, das die eingebaute Hilfe nicht zeigt.

Findet der Editor keinen Eintrag, steht dort „Keine Hilfe zu „Messagebox“ gefunden.“ Die Beschreibungen sind Zusammenfassungen aus dem opsi-script-Handbuch 4.3 der uib GmbH (CC BY-SA 4.0).

Diagnose

Während du schreibst, prüft der Editor die aktuelle Datei und markiert Auffälligkeiten im Text und am linken Rand. Fährst du mit der Maus über eine Markierung, siehst du die Meldung. Die Zähler „2 Fehler“ und „5 Warnungen“ in der Werkzeugleiste fassen das Ergebnis zusammen.

Navigieren und falten

• Gehe zu Definition: F12 oder Strg+Klick auf eine Variable oder Sektion springt zu der Zeile, in der sie definiert ist. Steht eine aufgerufene Sektion nicht in dieser Datei (Hinweis „Sektion … ist in dieser Datei nicht definiert“), sucht oPBWeb sie in den anderen Scripten des Pakets und öffnet die Datei an der Definition. Findet sich keine, meldet oPBWeb „Sektion … ist in keinem Script des Pakets definiert.“
• Alle Vorkommen auswählen: Strg+Umschalt+L markiert alle Stellen des Worts unter dem Cursor; du kannst sie dann gemeinsam ändern.
• Falten: Jede Sektion ([Actions], [Files_copy] …) lässt sich über die Marke am Rand ein- und ausklappen.
• Seitenleiste Variablen: Ein Klick auf einen Eintrag springt in die Zeile (siehe unten).

Das Kontextmenü

Ein Rechtsklick in den Text oder Umschalt+F10 öffnet das Kontextmenü. Du kannst es auch mit der Tastatur bedienen: Pfeiltasten, Enter oder Leertaste zum Ausführen, → öffnet das Untermenü, Esc schließt.

Einträge, die den Text ändern, sind in schreibgeschützten Dateien ausgegraut. Erlaubt dein Browser keinen Zugriff auf die Zwischenablage, meldet oPBWeb „Kein Zugriff auf die Zwischenablage – bitte Strg+C/V verwenden.“

Tastenkürzel

Auf dem Mac gilt ⌘ statt Strg und ⌥ statt Alt.

Die Seitenleiste

Bei opsi-Scripten steht rechts neben dem Text die Seitenleiste mit vier Reitern. Mit Werkzeugleiste ausblenden in der Werkzeugleiste des Reiters blendest du sie aus, mit Werkzeugleiste einblenden wieder ein.

Snippets

Hier findest du alle Snippets, die du verwenden darfst: die globalen und deine eigenen (Abzeichen „eigen“). Sie sind nach Kategorien gruppiert; das Feld „Snippets filtern …“ grenzt die Liste ein. Zeigst du mit der Maus auf ein Snippet, erscheint unten eine Vorschau der ersten zehn Zeilen mit hervorgehobenen Platzhaltern. Ein Klick auf eine Kategorie klappt sie ein oder aus.

Ein Snippet einfügen:

1. Setz den Cursor an die Stelle im Script, an der das Snippet stehen soll.
2. Doppelklick in der Seitenleiste auf das Snippet oder steuere es mit der Tab-Taste an und drück Enter. Alternativ ziehst du das Snippet mit der Maus an die gewünschte Stelle im Text, wählst es im Kontextmenü unter Snippet einfügen oder übernimmst es aus der Vervollständigung.
3. Enthält das Snippet Platzhalter der Form ${Name}, ist der erste davon markiert. Überschreib ihn und spring mit Tab zum nächsten Platzhalter.

Über den Link Snippets verwalten gelangst du zur Snippet-Verwaltung, siehe Snippets .

Variablen

• Definierte Variablen: alle Variablen der Datei mit Art (DefVar, DefStringList) und Zeile.
• Sektionen: alle Sektionen der Datei mit Zeile.
• Konstanten: die Konstanten von opsi-script mit Beschreibung.

Ein Klick auf eine Variable oder Sektion springt in die zugehörige Zeile.

Warnungen

Listet alle Fehler, Warnungen und Hinweise der Datei untereinander, Fehler zuerst, mit Zeilennummer. Die Zahl am Reiter nennt ihre Anzahl. Ein Klick auf einen Eintrag springt in die Zeile. Bei Sektionen, die in einer anderen Datei stehen können, führt Gehe zu Definition unter der Meldung direkt zur Definition in einem anderen Script des Pakets.

Hilfe

Zeigt die ausführliche Hilfe zum zuletzt angefragten Befehl, siehe Hilfe zu Befehlen . Ist noch nichts angefragt, steht dort „F1 auf einem Befehl zeigt hier die Hilfe an.“

Snippet aus Auswahl erstellen

Code, den du öfter brauchst, machst du direkt im Editor zu einem eigenen Snippet.

1. Markiere den gewünschten Text im Script.
2. Öffne mit einem Rechtsklick das Kontextmenü und wähl Snippet aus Auswahl erstellen ….
3. Im Dialog „Snippet aus Auswahl“ prüfst du den Namen. Vorgeschlagen wird die erste nicht leere Zeile der Auswahl (höchstens 60 Zeichen).
4. Wähl eine Kategorie oder leg mit Neue Kategorie eine an und gib den Namen der Kategorie ein.
5. Wähl die Sichtbarkeit: Nur für mich oder – nur als Administrator – Global.
6. Klick auf Speichern. oPBWeb meldet „Snippet gespeichert“; das Snippet steht sofort in der Seitenleiste zur Verfügung.

Funktionen des Pakets

Funktionen, die du in einem Script des Pakets mit DefFunc definierst, kennt der Editor in allen Scripten desselben Pakets. Sie erscheinen in der Vervollständigung und in der Hilfe, jeweils mit Datei und Zeile der Definition als Herkunft.

Als Beschreibung übernimmt oPBWeb die Kommentarzeilen direkt über dem DefFunc. Kommentare im Stil der uib-Bibliotheken mit @Description und @Returns werden ausgewertet:

; @Description Liefert den Installationspfad des Produkts
; @Returns Pfad als String
DefFunc GetInstallDir(val $Arch$ : string) : string
  ...
EndFunc

Die Liste der Funktionen wird aktualisiert, sobald du eine Datei gespeichert hast.

Speichern

Mit Strg+S oder der Schaltfläche Speichern in der Werkzeugleiste des Reiters speicherst du die Datei. oPBWeb bestätigt mit „Gespeichert“.

Ungespeicherte Änderungen gehen nicht unbemerkt verloren:

• Schließt du einen geänderten Reiter, fragt oPBWeb „Ungespeicherte Änderungen an setup.opsiscript verwerfen?“.
• Wechselst du die Version oder verlässt du den Editor, kommt „Es gibt ungespeicherte Änderungen. Trotzdem verlassen?“.
• Schließt oder lädst du das Browserfenster neu, warnt der Browser.

Bauen und verteilen

Rollen: Packager, Releaser

Überblick

Dieses Kapitel beschreibt den Weg einer Paketversion vom Entwurf bis auf die Depots: Bauen erzeugt die .opsi-Datei, Installieren … bringt sie auf ein oder mehrere Depots und gibt die Version dabei frei, Übernehmen … bringt eine getestete Version unverändert auf die Depots der nächsten Stufe. Alle Aktionen findest du in der Werkzeugleiste des Reiters control im Paket-Editor und im Menü ⋯ (Weitere Aktionen).

Bauen, Installieren auf Test- und Staging-Depots und die übrigen Aktionen in diesem Kapitel brauchen mindestens die Rolle Packager. Für produktive Depots ist die Rolle Releaser nötig. Mit der Rolle Leser kannst du gebaute Pakete nur herunterladen.

Der Lebenszyklus einer Version

Entwurf ──Bauen (beliebig oft)──► „gebaut“
   ▲          Änderung → „seit dem Bauen geändert“ → erneut bauen
   │
   │      Installieren … (nur mit aktuellem Build)
   │                     ▼
   └── Zurück auf Entwurf ── Freigegeben (schreibgeschützt)
                              └── Neue Version → neuer Entwurf

Bauen allein gibt eine Version nicht frei. Freigegeben wird sie erst durch das Installieren auf einem Depot. Einzige Ausnahme: Importierst du aus der Workbench eine Version, die auf einem Depot dieses Configservers schon installiert ist, gibt oPBWeb sie beim Import frei, siehe Installierte Versionen freigeben .

Bauen

1. Öffne die Version im Paket-Editor und wechsle auf den Reiter control.
2. Speichere alle Änderungen – im control und in allen geöffneten Dateien. Solange etwas ungespeichert ist, bleibt Bauen ausgegraut („Bitte zuerst alle Änderungen speichern.“).
3. Klick auf Bauen. Die Schaltfläche zeigt „Baut …“, und unten im Panel JOBS läuft das Protokoll des Build-Jobs mit.
4. Nach dem Ende meldet oPBWeb „Paket gebaut“ bzw. „Build fehlgeschlagen“. Neben der Versionsauswahl erscheint das Abzeichen gebaut.

Du kannst eine Version im Status Entwurf so oft bauen, wie du willst. Jeder Build ersetzt den vorherigen; die Version bleibt bearbeitbar.

Das Abzeichen „gebaut“

Das Abzeichen zeigt, ob der letzte Build noch zum aktuellen Stand der Version passt:

• gebaut – Der Build entspricht dem aktuellen Stand. Du kannst installieren.
• seit dem Bauen geändert – Seit dem letzten Build hast du control-Daten, Properties, Abhängigkeiten oder Dateien geändert. Bau die Version erneut, bevor du sie installierst.

Ohne Abzeichen wurde die Version noch nie gebaut.

Wenn der Build fehlschlägt

Das Protokoll im Panel JOBS (und unter Jobs ) nennt den Grund. Häufige Ursachen:

Warnungen im Protokoll (kein Script für irgendeine Aktion, keine Dateien in CLIENT_DATA/) brechen den Build nicht ab, deuten aber meist auf ein unvollständiges Paket hin.

Gebautes Paket herunterladen

Sobald es einen Build gibt, lädst du ihn mit .opsi herunterladen in der Werkzeugleiste herunter. Die Prüfsummendatei holst du über ⋯ › .md5 herunterladen. Beides steht jeder Rolle zur Verfügung, auch für freigegebene Versionen.

Installieren

Installieren … überträgt den Build auf die gewählten Depots und installiert ihn dort. Die Schaltfläche ist nur aktiv, wenn

• die Version gebaut ist und das Abzeichen gebaut zeigt (sonst: „Bitte zuerst bauen: Die Version wurde noch nicht gebaut oder seitdem geändert.“) und
• es keine ungespeicherten Änderungen gibt.

1. Klick auf Installieren …. Der Dialog „Installieren: firefox 128.0-1“ öffnet sich.

   

2. Wähl in der Tabelle die Depots aus. Die Tabelle enthält die Depots aller Configserver. Für jedes Depot siehst du:

   • Depot – die Depot-ID, beim Depot auf dem Configserver selbst mit dem Zusatz „Configserver“,
   • Configserver – der Name des Configservers, zu dem das Depot gehört,
   • Stufe – die wirksame Stufe Produktion, Staging oder Test; kursiv, wenn das Depot sie von seinem Configserver erbt,
   • Installiert – die dort installierte Version und den Zeitpunkt des letzten Abgleichs.

   Vorausgewählt sind die Depots, auf denen du zuletzt installiert hast.

3. Setz bei Bedarf die Optionen (siehe unten).

4. Prüf den Zähler „2 von 3 Depots ausgewählt“ und klick auf Installieren.

5. Der Dialog schließt sich, das Panel JOBS zeigt das Protokoll. Am Ende meldet oPBWeb „Job erfolgreich abgeschlossen“ oder „Job fehlgeschlagen“.

Die Depots werden nacheinander bearbeitet. Ist ein Depot gerade durch einen anderen Job belegt, wartet die Installation, bis es frei ist.

Gesperrte Depots im Dialog

Nicht jedes Depot lässt sich auswählen. Der Grund steht in der letzten Spalte:

Depots erben die Stufe ihres Configservers; neue Configserver stehen zunächst auf Produktion. Welche Server und Depots Test- oder Staging-Stufe haben, legt ein Administrator fest, siehe opsi-Server und Depot-Verwaltung . Hast du mindestens ein produktives Depot ausgewählt, weist der Dialog mit „Mindestens ein produktives Depot ist ausgewählt.“ darauf hin.

Sind gar keine Depots bekannt, erscheint „Keine Depots bekannt. Bitte unter „Depots“ abgleichen.“ – siehe Depots .

Optionen beim Installieren

• Setup auf allen Clients anfordern, auf denen das Produkt installiert ist – Nach der Installation setzt oPBWeb auf jedem gewählten Depot für alle Clients, auf denen das Produkt bereits installiert ist, die Aktionsanforderung setup. Clients ohne das Produkt bleiben unberührt. So verteilst du ein Update gezielt an die bisherigen Installationen.
• Installation erzwingen (force), auch wenn das Produkt gesperrt ist – Installiert auch dann, wenn das Produkt auf dem Depot gesperrt ist, z. B. nach einer abgebrochenen Installation. Alternativ entsperrst du das Produkt unter Depots .

Freigegebene Versionen

Nach der Installation ist die Version freigegeben. Im Editor erscheint der Hinweis „Version 128.0-1 ist freigegeben (installiert) und schreibgeschützt. Für Änderungen eine neue Version anlegen oder zurück auf Entwurf setzen.“ mit Dateiname und Größe des Builds sowie den Schaltflächen Neue Version und Zurück auf Entwurf. Alle Formulare, der Dateibaum und der Scripteditor sind schreibgeschützt.

Eine freigegebene Version kannst du jederzeit erneut installieren, z. B. auf weiteren Depots. Installieren … ist dann die hervorgehobene Schaltfläche.

Auf andere Stufe übernehmen

Rollen: Packager, Releaser

Ein Paket, das auf den Test-Depots funktioniert, bringst du mit dieser Aktion unverändert auf die Depots der nächsten Stufe. Übernommen wird genau das Paket, das auf den Depots der Quellstufe installiert ist – derselbe Build, kein neuer. Deshalb lassen sich nur freigegebene Versionen übernehmen.

oPBWeb hat einen gemeinsamen Paketbestand für alle Configserver. Was auf welchem Depot installiert ist, unterscheidet sich je Server und kommt aus dem letzten Abgleich der Depots .

Typischer Ablauf

1. Auf dem Test-Configserver entwickeln: aus der Workbench importieren, bearbeiten, bauen und auf den Test-Depots installieren. Dabei wird die Version freigegeben.
2. Testen und die Version mit Übernehmen … von Test nach Staging bringen.
3. Nach dem Test auf Staging die Version von Staging nach Produktion übernehmen. Dafür ist die Rolle Releaser nötig.

Dialog öffnen

• Übernehmen … in der Werkzeugleiste der Paketliste öffnet den Dialog „Pakete auf andere Stufe übernehmen“ für alle Pakete.
• Auf andere Stufe übernehmen … im Abschnitt Verteilung der Paketdetails öffnet denselben Dialog nur für das ausgewählte Paket („firefox auf andere Stufe übernehmen“).

Pakete übernehmen

1. Wähl oben Von (Quellstufe, voreingestellt Test) nach (Zielstufe, voreingestellt Staging). Quell- und Zielstufe müssen verschieden sein.

2. Prüf unter Ziel-Depots die Depots, auf die übernommen wird. Angeboten werden alle aktiven Depots der Zielstufe, auf allen Configservern. Vorausgewählt sind alle, die du ändern darfst; produktive Depots ohne die Rolle Releaser sind gesperrt („erfordert Rolle Releaser“).

3. Prüf die Tabelle der Pakete:

   Spalte	Inhalt
   Product-ID	Kennung des Produkts
   Version auf … (z. B. Version auf Test)	die neueste Version, die auf einem Depot der Quellstufe installiert ist
   Auf den Ziel-Depots	„überall aktuell“ oder „fehlt auf 2 von 3“, dazu die Versionen, die stattdessen auf den Ziel-Depots liegen

   Der Chip Nur ausstehende (voreingestellt aktiv, nur im Dialog für alle Pakete) blendet Pakete aus, die auf allen Ziel-Depots schon aktuell sind. Vorausgewählt sind alle ausstehenden Pakete, die sich übernehmen lassen. Übernehmbare Pakete stehen oben.

4. Setz bei Bedarf die Optionen:

   • Setup auf allen Clients anfordern, auf denen das Produkt installiert ist und Installation erzwingen (force), auch wenn das Produkt gesperrt ist – wie beim Installieren .
   • Auch auf die Workbench der Ziel-Configserver schreiben (vorhandene Projektordner werden überschrieben) – schreibt die Version zusätzlich als Projektordner in die Workbench jedes Configservers, zu dem ein Ziel-Depot gehört.

5. Prüf den Zähler „Pakete: 2 · Ziel-Depots: 3“ und klick auf Übernehmen (n).

oPBWeb startet einen Installations-Job pro Version und, falls gewählt, einen Export-Job pro Version und Ziel-Configserver. Es meldet „Jobs gestartet: 3“. Jobs für dasselbe Depot laufen nacheinander. Den Fortschritt verfolgst du unter Jobs .

Warum lässt sich ein Paket nicht übernehmen?

Pakete ohne Häkchen zeigen in der Spalte Auf den Ziel-Depots den Grund:

Hast du ein produktives Depot ausgewählt, weist der Dialog mit „Mindestens ein produktives Depot ist ausgewählt.“ darauf hin.

Deinstallieren

Mit ⋯ › Deinstallieren … entfernst du das Produkt von Depots.

1. Öffne ⋯ und wähl Deinstallieren …. Der Dialog „Deinstallieren: firefox“ öffnet sich.
2. Vorausgewählt sind alle Depots, auf denen das Produkt installiert ist. Depots ohne das Produkt sind mit „nicht installiert“ gesperrt; die Stufenregel gilt wie beim Installieren.
3. Prüf die Optionen:
   • Dateien im Depot löschen (voreingestellt) – entfernt auch die Paketdateien vom Depot.
   • Deinstallation erzwingen (force) – deinstalliert auch, wenn das Produkt gesperrt ist.
4. Klick auf Deinstallieren. Das Protokoll erscheint im Panel JOBS.

Deinstallieren bezieht sich auf das Produkt, nicht auf die gerade geöffnete Version. Der Status der Version in oPBWeb ändert sich dadurch nicht.

Zurück auf Entwurf

Mit Zurück auf Entwurf machst du eine freigegebene Version wieder bearbeitbar, ohne die Versionsnummer zu ändern. Das ist sinnvoll, wenn ein Fehler auffällt, die Versionsnummer aber gleich bleiben soll.

1. Klick im Hinweis der freigegebenen Version auf Zurück auf Entwurf.
2. Der Dialog „Version 128.0-1 wieder bearbeiten“ erklärt die Folgen. Ist die Version bereits auf Depots installiert, nennt er diese.
3. Bestätige mit Zurück auf Entwurf. oPBWeb meldet „Version ist wieder bearbeitbar“.

Solange für die Version ein Job wartet oder läuft, ist Zurück auf Entwurf nicht möglich.

Neue Version

Neue Version legt eine bearbeitbare Kopie der aktuellen Version mit allen Daten und Dateien an. Du findest die Aktion im Hinweis einer freigegebenen Version und im Menü ⋯; sie funktioniert für Entwürfe und freigegebene Versionen.

1. Klick auf Neue Version.
2. Prüf Produktversion und Paketversion. Vorgeschlagen wird dieselbe Produktversion mit um eins erhöhter Paketversion; ist die Paketversion keine reine Zahl, wird .1 angehängt.
3. Klick auf Anlegen. Der Editor öffnet die neue Version im Status Entwurf.

Denk daran, in der neuen Version einen Changelog-Eintrag anzulegen, siehe Paket-Editor .

In Workbench exportieren

Mit ⋯ › In Workbench exportieren … schreibst du die Version als Projektordner in die Workbench eines Configservers, z. B. um dort mit opsi-makepackage oder anderen Werkzeugen weiterzuarbeiten. Das geht für Entwürfe und freigegebene Versionen.

1. Öffne ⋯ und wähl In Workbench exportieren ….
2. Wähl unter Configserver den Server, in dessen Workbench du schreiben willst (Name und Stufe; vorbelegt ist der zuletzt gewählte, sonst der erste Server der Stufe Test).
3. Gib den Projektordner an. Vorbelegt ist der Ordner, aus dem die Version importiert wurde, sonst die Product-ID. Unterordner trennst du mit / (bis vier Ebenen), zum Beispiel develop/firefox; fehlende Ordner legt oPBWeb an. Das Feld schlägt die Gruppenordner vor, die beim letzten Einlesen auf der Workbench des Servers lagen.
4. Gibt es den Ordner schon, setz das Häkchen Vorhandenen Ordner überschreiben (überzählige Dateien in den Paketordnern werden gelöscht). Ohne Häkchen schlägt der Export bei einem vorhandenen Ordner fehl.
5. Klick auf Exportieren. Nach dem Job meldet oPBWeb „In die Workbench exportiert“.

Geschrieben werden nur OPSI/, CLIENT_DATA/ und SERVER_DATA/. Andere Inhalte des Projektordners bleiben erhalten. Nach dem Export zeigt die Paketliste den Projektordner unter Workbench . Den umgekehrten Weg beschreibt Pakete (Workbench …). Änderungen, die später direkt auf der Workbench entstehen, holst du mit Mit Workbench abgleichen … zurück, siehe Paket-Editor .

Job-Ausgabe verfolgen

Bauen, Installieren, Deinstallieren, das Übernehmen auf andere Stufen und der Export laufen als Jobs im Hintergrund. Du kannst währenddessen weiterarbeiten.

• Das Panel JOBS unten im Editor öffnet sich beim Start automatisch. Es listet die letzten 30 Jobs dieses Produkts und zeigt das Protokoll des gewählten Jobs live an. Mit × schließt du das Panel, mit Jobs ▴ öffnest du es wieder.
• Die Statusleiste zeigt den Fortschritt der Jobs, die du in diesem Browser-Tab gestartet hast.
• Alle Jobs aller Benutzer findest du unter Jobs .

Snippets

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Snippets sind Textbausteine für opsi-script, die du im Scripteditor per Doppelklick, Autovervollständigung oder Kontextmenü einfügst. Die Ansicht Snippets in der Aktivitätsleiste ist der Ort, an dem du sie verwaltest: Kategorien anlegen, Snippets schreiben und testen, Dateien importieren und exportieren.

Leser sehen alle Snippets, können aber nichts ändern. Ab der Rolle Packager legst du eigene Snippets an und pflegst die gemeinsamen Kategorien.

Globale und eigene Snippets

Jedes Snippet hat eine Sichtbarkeit:

In der Liste erkennst du die Sichtbarkeit am Badge global bzw. eigen. Kategorien sind dagegen für alle gemeinsam: Jeder Packager kann Kategorien anlegen, umbenennen und löschen, und alle sehen dieselbe Kategorienstruktur.

Aufbau der Ansicht

Die Ansicht hat drei Spalten. Die Breite der linken und rechten Spalte kannst du durch Ziehen am Rand ändern.

• Links – SNIPPETS: Schaltflächen Neues Snippet, Neue Kategorie, Snippets importieren und Snippets exportieren, darunter der Filter Alle | Global | Eigene und das Suchfeld „Filtern …“ (durchsucht Name und Text). Darunter der Kategorienbaum mit der Anzahl der Snippets je Kategorie.
• Mitte: das ausgewählte Snippet mit den Feldern Name, Kategorie, Sichtbarkeit und Beschreibung, dem Codeeditor und der Leiste PLATZHALTER. Oben rechts Duplizieren, Löschen, Verwerfen und Speichern.
• Rechts – TESTEN: ein kleiner Scripteditor, in dem du ausprobierst, wie sich das Snippet beim Einfügen verhält.

Kategorien verwalten

Jedes Snippet gehört zu genau einer Kategorie. Bevor du das erste Snippet anlegen kannst, muss es mindestens eine Kategorie geben.

• Anlegen: Klick auf Neue Kategorie. Die Kategorie heißt zunächst „Neue Kategorie“.
• Umbenennen: Doppelklick auf den Kategorienamen oder Klick auf ✎ (Kategorie umbenennen). Gib den neuen Namen ein und bestätige mit Enter; Esc bricht ab. Kategorienamen müssen eindeutig sein.
• Löschen: Klick auf × neben der Kategorie. Das geht nur bei leeren Kategorien („Nur leere Kategorien können gelöscht werden“).
• Snippet verschieben: Zieh ein Snippet mit der Maus auf eine andere Kategorie. Globale Snippets können nur Administratoren verschieben.

Snippet anlegen und bearbeiten

1. Klick auf Neues Snippet. Es entsteht ein Entwurf mit dem Namen „Neues Snippet“ und dem Text ; ${Kommentar}.
2. Gib einen aussagekräftigen Name ein und wähl die Kategorie.
3. Wähl die Sichtbarkeit. Als Packager steht nur Nur für mich zur Verfügung; Global (für alle) ist Administratoren vorbehalten.
4. Trag optional eine Beschreibung ein. Sie erscheint später in der Autovervollständigung des Scripteditors.
5. Schreib den Snippet-Text im Editor. Er unterstützt opsi-script-Hervorhebung, Platzhalter werden farbig markiert.
6. Klick auf Speichern.

Solange es ungespeicherte Änderungen gibt, zeigt ein Punkt neben dem Titel das an. Verwerfen stellt den gespeicherten Stand wieder her. Wechselst du mit ungespeicherten Änderungen zu einem anderen Snippet, fragt oPBWeb „Ungespeicherte Änderungen verwerfen?“.

Löschen entfernt das Snippet nach einer Rückfrage endgültig.

Platzhalter

Platzhalter markieren die Stellen, die du nach dem Einfügen anpassen musst. Sie haben die Form ${name}, zum Beispiel:

; ${Kommentar}
Winbatch_${Sektionsname}

Nach dem Einfügen springst du mit der Tab-Taste von Platzhalter zu Platzhalter und überschreibst ihn jeweils.

• Die Leiste PLATZHALTER unter dem Editor listet alle Platzhalter des Snippets auf (oder „keine“).
• Markiere ein Stück Text im Editor und klick auf Auswahl als Platzhalter, um es in ${…} einzuschließen.

Snippet testen

Im Bereich TESTEN probierst du das Snippet aus, bevor du es im echten Script verwendest:

1. Setz den Cursor im Testeditor an die gewünschte Stelle.
2. Klick auf Einfügen. Das Snippet wird genau wie im Scripteditor eingefügt.
3. Spring mit Tab durch die Platzhalter.
4. Klick auf Zurücksetzen, um den Testeditor wieder auf den Beispieltext zu bringen.

Snippet aus dem Scripteditor erstellen

Du kannst ein Snippet auch direkt aus einem Script heraus anlegen:

1. Markiere im Scripteditor den gewünschten Text.
2. Öffne mit Rechtsklick das Kontextmenü und wähl Snippet aus Auswahl erstellen ….
3. Im Dialog „Snippet aus Auswahl“ prüfst du Name (vorbelegt mit der ersten nicht leeren Zeile), Kategorie und Sichtbarkeit. Über „Neue Kategorie“ legst du bei Bedarf gleich eine neue Kategorie an.
4. Klick auf Speichern.

Wie du Snippets im Scripteditor einfügst, beschreibt Scripteditor .

Snippets importieren

oPBWeb liest zwei Dateiformate:

• JSON-Exporte von oPBWeb (.json, Format „opbweb-snippets“), etwa von einer anderen oPBWeb-Installation oder einem Kollegen.
• Snippet-Dateien des alten ScriptEditors (opsi.sn-*.def, z. B. opsi.sn.def).

So importierst du:

1. Klick auf Snippets importieren.
2. Wähl die Sichtbarkeit der importierten Snippets. Packager importieren immer als Nur für mich; global importieren können nur Administratoren.
3. Klick auf Datei auswählen … und wähl die Datei aus.

oPBWeb meldet anschließend „42 Snippets importiert, 3 übersprungen“. Übersprungen werden Snippets, die es mit gleichem Namen in derselben Kategorie und Sichtbarkeit schon gibt. Fehlende Kategorien werden automatisch angelegt; Snippets ohne Kategorie landen in „Allgemein“.

Snippets exportieren

Klick auf Snippets exportieren (die Schaltfläche gibt es ab der Rolle Packager). Dein Browser lädt die Datei opbweb-snippets.json herunter. Sie enthält alle Snippets, die du sehen darfst, also alle globalen und deine eigenen, jeweils mit Name, Kategorie, Beschreibung und Text. Die Datei kannst du in einer anderen oPBWeb-Installation wieder importieren.

Depots

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Die Ansicht Depots zeigt alle opsi-Configserver, die in oPBWeb eingerichtet sind, und ihre Depots so, wie oPBWeb sie zuletzt gelesen hat. Du siehst, welche Produkte in welcher Version installiert sind, räumst das Repository auf, bearbeitest Dateien direkt auf dem Server und vergleichst die Depots untereinander.

Leser sehen alles, können aber nichts verändern. Was Packager und Releaser auf einem Depot ändern dürfen, hängt von dessen Stufe ab (siehe Stufen und Rollen ). Configserver hinzufügen, bearbeiten und entfernen können nur Administratoren, siehe opsi-Server .

Configserver und Depots

Links steht ein Baum mit allen Configservern und ihren Depots. Jedes Depot gehört zu genau einem Configserver.

Configserver sind fett dargestellt. Jede Zeile zeigt:

• einen Statuspunkt: grün, wenn die letzte Prüfung erfolgreich war, rot, wenn sie fehlgeschlagen ist, grau, wenn der Server noch nicht geprüft wurde,
• den Namen des Servers und ein Stufen-Badge (Produktion, Staging oder Test),
• darunter die Kurzinfo „Configserver · 3 Depots“.

Depots stehen eingerückt unter ihrem Configserver, jeweils mit Depot-ID, Stufen-Badge und einer Kurzinfo wie „Configserver · 42 Produkte“ (beim Depot auf dem Configserver selbst) oder „17 Produkte“. Ein kursives, helleres Stufen-Badge bedeutet: Das Depot hat keine eigene Stufe und erbt die seines Configservers (Tooltip „vom Configserver geerbt“). Zusätzlich können dort folgende Hinweise stehen:

• deaktiviert: Ein Administrator hat das Depot für oPBWeb abgeschaltet. Du kannst nichts darauf installieren.
• nicht mehr vorhanden: Der Configserver meldet das Depot nicht mehr. oPBWeb behält es mit seinen Einstellungen, bis ein Administrator es entfernt.

Ist noch kein Configserver eingerichtet, steht dort „Noch kein Configserver eingerichtet.“ Das Anlegen übernimmt ein Administrator.

Liste zuklappen und durchsuchen

Bei vielen Depots hilft dir zweierlei:

• Zuklappen: Ein Klick auf den Pfeil vor dem Namen eines Configservers klappt seine Depots zu oder wieder auf. Die Zeile des Servers bleibt sichtbar. oPBWeb merkt sich in diesem Browser, welche Server zugeklappt sind.
• Suchen: Das Feld „Depot suchen“ über der Liste sucht in Depot-ID und Beschreibung. Passt der Name eines Configservers, siehst du alle seine Depots. Während der Suche sind alle Server mit Treffern aufgeklappt. Findet die Suche nichts, steht dort „Kein Depot passt zur Suche.“

Configserver ansehen

Klick auf die Zeile eines Configservers. Als Packager, Releaser oder Leser siehst du rechts eine Übersicht, die du nicht ändern kannst:

• Name und Stufe des Servers,
• URL des Configservers,
• Zustand: „erreichbar“ oder „nicht erreichbar“ mit der Fehlermeldung der letzten Prüfung,
• die Gültigkeit des hinterlegten CA-Zertifikats.

Ab Packager steht oben Abgleichen für genau diesen Server. Administratoren sehen an dieser Stelle stattdessen das Formular des Servers, siehe opsi-Server .

Depot ansehen

Klick auf ein Depot, um rechts seine Details zu sehen. Oben stehen Depot-ID, Stufe, der Name des Configservers und der Zeitpunkt des letzten Abgleichs („abgeglichen …“).

Abgleichen

Ein Abgleich liest die Depots eines Configservers und ihre installierten Produkte neu. Er läuft als Job; währenddessen steht „Gleicht ab …“ auf der Schaltfläche. Abgleichen kannst du ab der Rolle Packager:

Der Abgleich eines Servers ändert nie die Depots eines anderen Servers.

Ein Abgleich über Abgleichen oder ⟳ liest außerdem die Workbench jedes Configservers. Dabei merkt sich oPBWeb, welcher Projektordner welches Paket in welcher Version enthält; das siehst du in der Paketliste unter Workbench . Ist die Workbench nicht lesbar, meldet der Job das als Warnung und gleicht die Depots trotzdem ab.

oPBWeb prüft zusätzlich alle fünf Minuten (Standard, einstellbar unter Einstellungen → Worker) selbstständig alle Configserver und gleicht die Depots jedes erreichbaren Servers ab; dieser automatische Abgleich erscheint nicht in der Jobliste und liest die Workbench nicht. Die Workbench liest der Worker getrennt davon, standardmäßig stündlich (ebenfalls unter Einstellungen → Worker). Einen manuellen Abgleich brauchst du vor allem, wenn du eine Änderung auf dem Server sofort sehen willst.

Einstellungen des Depots

Unter den Depotdetails stehen die Einstellungen mit Stufe, Dienst-URL und Aktiv sowie Infofelder wie Verwendete URL und Von opsi gemeldet. Bei Stufe bedeutet „wie Configserver (Produktion)“, dass das Depot die Stufe seines Configservers erbt. Ändern können diese Werte nur Administratoren; für alle anderen sind sie schreibgeschützt. Details stehen in Depot-Verwaltung .

Stufen und Rollen

Jeder Configserver hat eine Stufe: Produktion, Staging oder Test. Seine Depots erben diese Stufe, solange ein Administrator für ein Depot keine eigene festlegt. Die wirksame Stufe eines Depots bestimmt, wer dort schreibende Aktionen ausführen darf:

Administratoren dürfen alles, was Releaser dürfen. Neue Configserver starten in der Stufe Produktion; ein Administrator stellt Test- und Staging-Server bzw. einzelne Depots um. Fehlt dir die nötige Rolle, blendet oPBWeb die betreffenden Schaltflächen aus oder sperrt das Depot im Dialog.

Wie du ein getestetes Paket von einer Stufe auf die nächste bringst, steht in Bauen und verteilen .

Tab „Installierte Produkte“

Die Tabelle zeigt alle Produkte, die auf dem Depot installiert sind:

Mit dem Chip Abweichend von oPBWeb schränkst du die Liste auf Produkte ein, bei denen Depot und oPBWeb unterschiedliche Versionen haben. Das Feld „Filtern …“ sucht nach der Product-ID.

Gesperrte Produkte entsperren

Bricht eine Installation ab, bleibt das Produkt auf dem Depot manchmal gesperrt. Es trägt dann das Badge gesperrt. So hebst du die Sperre auf:

1. Setz bei den gesperrten Produkten das Häkchen.
2. Klick auf Entsperren (n).

Das Entsperren läuft als Job; danach meldet oPBWeb „2 Produkte entsperrt“. Die Häkchen und die Schaltfläche siehst du nur, wenn du auf diesem Depot schreiben darfst.

Tab „Dateien“

Der Tab Dateien ist ein Dateimanager für die Freigaben des Depots. Je nach Depot gibt es bis zu drei Freigaben als Unter-Tabs:

/workbench gibt es nur auf dem Configserver und auf Depots, die eine Workbench melden. In schreibgeschützten Freigaben zeigt oPBWeb den Hinweis „/repository ist nur lesbar.“ bzw. „Ändern erfordert die Rolle Packager.“

Navigieren

• Klick auf einen Ordner öffnet ihn; die Zeile ‹ eine Ebene höher führt zurück. Oben siehst du den aktuellen Pfad.
• Das Feld „Filtern …“ filtert den aktuellen Ordner.
• Neu laden liest den Ordner erneut vom Server.
• Ordner in /workbench, zu denen es in oPBWeb ein Paket mit gleicher Product-ID gibt, tragen das Badge in oPBWeb, auch in Unterordnern.

Dateien ansehen und bearbeiten

Klick auf eine Textdatei (Scripte, control, .ini, .xml, .json, .ps1, .cmd, .log und viele mehr), um sie im Texteditor zu öffnen. opsi-Scripte bekommen dabei dieselbe Hervorhebung wie im Scripteditor. In /workbench kannst du die Datei ändern und mit Speichern zurückschreiben; in den anderen Freigaben ist sie „nur lesbar“.

Der Editor behält Zeichenkodierung (UTF-8 oder CP1252) und Zeilenenden der Datei bei; die Kodierung steht unten im Dialog. Bearbeiten lassen sich Textdateien bis 2 MB. Größere Dateien und Binärdateien lädst du herunter.

Herunterladen

Klick auf eine Datei, die kein Text ist, oder wähl im Kontextmenü (Rechtsklick) Herunterladen. Der Download läuft in zwei Schritten: Zuerst kopiert ein Job die Datei vom Server, danach startet dein Browser den Download. Nur wer den Download ausgelöst hat, kann die Datei abholen.

In der Workbench arbeiten (ab Packager)

In /workbench stehen dir zusätzlich zur Verfügung:

• Neuer Ordner und Neue Datei (Vorschlag neu.opsiscript)
• Dateien hochladen … und Ordner hochladen …
• im Kontextmenü: Umbenennen und Löschen (mit Rückfrage; bei Ordnern samt Inhalt)

Alternativ ziehst du Dateien oder ganze Ordner per Drag & drop in die Liste. Sie landen im aktuell geöffneten Ordner. Der Fortschritt erscheint als „Lade hoch … 45 %“; anschließend kopiert ein Job die Dateien auf den Server und oPBWeb meldet „3 Dateien hochgeladen“.

Paket aus der Workbench übernehmen

Ein Paketverzeichnis in /workbench kannst du direkt in oPBWeb importieren:

1. Öffne /workbench und darin ggf. den Gruppenordner, in dem das Projekt liegt (bis vier Ebenen tief).
2. Klick mit der rechten Maustaste auf den Paketordner.
3. Wähl In oPBWeb importieren.

Der Import läuft als Job und liest aus der Workbench des Configservers, zu dem das Depot gehört; danach meldet oPBWeb „{name} importiert“. Eine schon vorhandene Version wird dabei nicht überschrieben. Zum Ersetzen und für den Import mehrerer Ordner nutzt du den Dialog Workbench … in der Paketliste, siehe Pakete .

Tab „Repository“

Das Repository eines Depots enthält die hochgeladenen .opsi-Dateien samt .md5- und .zsync-Prüfdateien. Im Laufe der Zeit sammeln sich dort alte Versionen an.

Beim ersten Öffnen liest oPBWeb das Repository automatisch ein; mit Repository lesen wiederholst du das. Das Lesen läuft als Job. Darüber steht eine Zusammenfassung wie „12 Pakete, 1,4 GB“.

Die Tabelle zeigt Datei, Product-ID, Version und Größe sowie folgende Badges:

• Installiert: Diese Version ist auf dem Depot installiert.
• MD5 fehlt: Ohne .md5 kann das Depot die Datei nicht prüfen.
• ohne zsync: Es fehlt die .zsync-Datei.

Prüfdateien ohne zugehörige .opsi-Datei listet oPBWeb unter „Verwaiste Prüfsummen“ auf.

Dateien aus dem Repository löschen

1. Setz bei den Paketen, die weg sollen, das Häkchen.
2. Klick auf Löschen (n).
3. Bestätige die Rückfrage „2 Pakete samt .md5 und .zsync aus dem Repository von depot01.example.local löschen?“.

oPBWeb löscht die .opsi-Dateien zusammen mit ihren Prüfdateien. Installierte Produkte bleiben dabei erhalten. Die Häkchen siehst du nur, wenn du auf diesem Depot schreiben darfst (siehe Stufen und Rollen ).

Tab „Vergleich“

Der Tab Vergleich stellt für das ausgewählte Depot drei Versionen jedes Produkts nebeneinander: oPBWeb (gebaut), den Configserver, zu dem das Depot gehört (Spaltenkopf mit dem Zusatz „Configserver“), und das Depot selbst. Wählst du das Depot auf dem Configserver, gibt es nur die beiden Spalten oPBWeb und Configserver. Abweichende Versionen sind orange markiert.

• Der Chip Nur Abweichungen ist standardmäßig aktiv und blendet Produkte aus, die überall gleich sind.
• „Filtern …“ sucht nach der Product-ID.
• Als CSV exportieren speichert den Vergleich über alle Depots aller Configserver als depot-vergleich-JJJJ-MM-TT.csv, also mehr Spalten, als die Tabelle zeigt. Filter und Nur Abweichungen gelten auch für die Datei; „abweichend“ heißt dort: nicht auf allen Depots gleich. Die Datei ist UTF-8-kodiert (mit BOM) und durch Semikolon getrennt; die Spalten heißen product_id, opbweb und danach je Depot die Depot-ID.

Verwandte Themen

• Bauen und verteilen : Pakete auf Depots installieren und deinstallieren
• Jobs : Fortschritt und Protokoll der Depot-Aktionen
• opsi-Server : Configserver hinzufügen, bearbeiten und entfernen
• Depot-Verwaltung : Stufe, Dienst-URL und Aktiv festlegen

Jobs

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Alles, was länger dauert oder mit einem opsi-Server spricht, führt oPBWeb als Job im Hintergrund aus. Du startest die Aktion, arbeitest weiter und verfolgst den Fortschritt in der Statusleiste, im Paket-Editor oder in der Ansicht Jobs.

Alle Benutzer sehen alle Jobs, auch die der Kollegen, samt Protokoll. So lässt sich nachvollziehen, wer wann was gebaut oder verteilt hat.

Welche Aktionen laufen als Job?

Nur die ersten sechs Aktionen haben einen übersetzten Namen; alle anderen erscheinen mit ihrem technischen Namen. Titel und Protokollzeilen der Jobs kommen vom Server und erscheinen in der Sprache der Oberfläche. Jobs, die vor Version 0.15.0 entstanden sind, behalten ihre deutschen Titel und Protokollzeilen.

Die Jobliste

Öffne Jobs in der Aktivitätsleiste.

Oben stehen die Filter:

• Alle, Laufend, Wartend, Fehlgeschlagen: Chips mit der jeweiligen Anzahl
• Meine: zeigt nur Jobs, die du selbst ausgelöst hast
• Suchfeld „Paket, Depot oder Titel …“

Die Tabelle hat die Spalten Aktion, Titel, Ziel (Paket oder Depot), Status, Ausgelöst von, Start und Dauer. Laufende Jobs zeigen beim Status zusätzlich den Fortschritt in Prozent. Die Liste aktualisiert sich alle paar Sekunden von selbst und zeigt die letzten 200 Jobs („200 von 1.348 Jobs angezeigt“).

Ein Job hat einen dieser Zustände: wartet, läuft, erfolgreich, fehlgeschlagen oder abgebrochen.

Job-Details und Live-Protokoll

Klick auf einen Job in der Liste. Rechts erscheinen Titel, Status, Ziel, Auslöser und Startzeit, ein Fortschrittsbalken, bei Fehlern die Fehlermeldung und darunter das Protokoll.

Bei laufenden Jobs kommen neue Protokollzeilen live hinzu, und die Ansicht scrollt automatisch mit. Die Zeilen sind nach Bedeutung eingefärbt: grün für Erfolg, orange für Warnungen, rot für Fehler.

Im Detailbereich stehen je nach Job diese Schaltflächen:

• Zum Paket: öffnet das betroffene Paket im Paket-Editor (bei Jobs, die zu einem Paket gehören).
• Kopieren: kopiert das komplette Protokoll mit Uhrzeiten in die Zwischenablage, etwa für eine Fehlermeldung an den Administrator.
• Abbrechen: siehe unten.

Jobs abbrechen

Abbrechen kannst du nur Jobs im Zustand wartet, also Jobs, die noch nicht begonnen haben. Ein laufender Job lässt sich nicht abbrechen; er läuft bis zum Ende oder bis zu einem Fehler.

• Eigene wartende Jobs bricht jeder Benutzer selbst ab.
• Wartende Jobs anderer Benutzer kann nur ein Administrator abbrechen.

Wähl den Job aus und klick auf Abbrechen. Der Job erhält den Zustand abgebrochen.

Brichst du einen wartenden Installations-Job ab, der einen Entwurf freigegeben hat, ist die Version danach wieder ein Entwurf.

Fortschritt in der Statusleiste

Jobs, die du in diesem Browser-Tab gestartet hast, erscheinen rechts in der Statusleiste mit Titel, Fortschrittsbalken und Prozentangabe. Ein Klick darauf öffnet den Job in der Jobliste. Ist kein Job mehr aktiv, zeigt die Statusleiste den zuletzt beendeten Job mit seinem Ergebnis.

Zusätzlich zeigt das Symbol Jobs in der Aktivitätsleiste die Anzahl der laufenden Jobs, die du in diesem Browser gestartet hast.

Bricht die Verbindung zum Server während eines Jobs ab, meldet oPBWeb „Verbindung zum Job verloren“. Der Job selbst läuft auf dem Server weiter; seinen Endstand siehst du in der Jobliste.

Jobs im Paket-Editor

Im Paket-Editor gibt es unten das Panel JOBS. Es listet die letzten Jobs des geöffneten Pakets mit Status und Zeitpunkt und zeigt rechts das Protokoll des ausgewählten Jobs, bei laufenden Jobs live.

Startest du im Editor einen Job, etwa mit Bauen oder Installieren …, öffnet sich das Panel automatisch. Mit × schließt du es; die Schaltfläche Jobs ▴ am unteren Rand blendet es wieder ein.

Mehr zum Bauen und Verteilen steht in Bauen und verteilen .

Konto und Sprache

Rollen: Leser, Packager, Releaser, Administrator

Überblick

Die Einstellungen zu deinem eigenen Konto erreichst du über das Avatar-Symbol mit deinen Initialen ganz rechts in der Kopfleiste. Daneben findest du in der Kopfleiste die Umschalter für Sprache und Hell-/Dunkel-Darstellung sowie den Zugang zu diesem Handbuch.

Diese Funktionen stehen allen Benutzern zur Verfügung, unabhängig von der Rolle.

Das Benutzermenü

Klick auf das Avatar-Symbol, um das Benutzermenü zu öffnen.

Oben im Menü stehen dein Anzeigename sowie Benutzername und Rolle, zum Beispiel mmuster · Packager. Darunter folgen Standardsprache, Mein Konto, Passwort ändern und Abmelden.

Mein Konto

Mein Konto im Benutzermenü öffnet eine eigene Seite. Oben stehen deine Kontodaten: Benutzername, Name, E-Mail, Rolle und Herkunft (lokal oder Verzeichnis). Dort legst du auch die Standardsprache fest und änderst mit Passwort ändern dein Passwort, genau wie im Benutzermenü. Darunter folgen die Farben im Editor .

Einmalige Hinweise

Manche Hinweise zeigt oPBWeb nur beim ersten Mal, zum Beispiel den „Hinweis zum Funktionsumfang“ vor dem ersten Öffnen des Assistenten Paket aus Installer . Bestätigst du einen solchen Hinweis, merkt sich oPBWeb das an deinem Konto.

In der Zeile Einmalige Hinweise siehst du, wie viele Hinweise du bestätigt hast, zum Beispiel „1 Hinweis bestätigt“. Mit Wieder anzeigen setzt du sie zurück; jeder Hinweis erscheint dann beim nächsten Mal wieder. Hast du noch keinen Hinweis bestätigt, ist der Knopf gesperrt.

Sprache

oPBWeb kennt zwei Oberflächensprachen: Deutsch und Englisch. Es gibt zwei Wege, die Sprache zu wechseln, die sich in ihrer Wirkung unterscheiden.

Standardsprache festlegen

1. Öffne das Benutzermenü.
2. Klick in der Zeile Standardsprache auf DE oder EN.

Die Oberfläche wechselt sofort, und oPBWeb merkt sich die Sprache in deinem Konto. Nach jeder Anmeldung startet oPBWeb in dieser Sprache, auch an einem anderen Rechner oder Browser.

Sprache vorübergehend umschalten

Der Umschalter in der Kopfleiste zeigt die aktuelle Sprache (DE oder EN). Ein Klick schaltet auf die andere Sprache um. Das ist praktisch, wenn du kurz einen englischen Begriff nachsehen oder einem Kollegen etwas auf Englisch zeigen willst.

Die Umstellung gilt nur für den aktuellen Browser-Tab und bleibt auch beim Neuladen der Seite erhalten. Sobald du dich ab- und wieder anmeldest, gilt wieder deine Standardsprache.

Sprache auf der Anmeldeseite

Auch die Anmeldeseite hat einen Sprachumschalter. Vor der Anmeldung kennt oPBWeb dich noch nicht; es verwendet die zuletzt in diesem Browser genutzte Sprache oder, beim ersten Besuch, die Sprache deines Browsers. Nach der Anmeldung übernimmt oPBWeb deine Standardsprache.

Passwort ändern

Diese Funktion gibt es nur für lokale Konten, also Konten, die in oPBWeb selbst angelegt wurden.

1. Öffne das Benutzermenü.
2. Klick auf Passwort ändern.
3. Gib dein Aktuelles Passwort ein.
4. Gib das Neue Passwort ein und wiederhole es unter Neues Passwort wiederholen. Das neue Passwort muss mindestens 10 Zeichen lang sein.
5. Klick auf Speichern.

Ist das Passwort zu kurz oder stimmen die beiden Eingaben nicht überein, zeigt der Dialog „Mindestens 10 Zeichen.“ bzw. „Die Passwörter stimmen nicht überein.“ an und Speichern bleibt gesperrt.

Hast du dein Passwort vergessen, wende dich an einen Administrator. Er kann dir ein neues Passwort setzen, siehe Benutzer und Rollen .

Abmelden

Klick im Benutzermenü auf Abmelden. oPBWeb beendet deine Sitzung und zeigt wieder die Anmeldeseite. Eine vorübergehend umgeschaltete Sprache wird dabei verworfen.

Hell oder dunkel

Das Mond-Symbol in der Kopfleiste (Hell oder dunkel umschalten) wechselt zwischen heller und dunkler Darstellung. Solange du nichts auswählst, folgt oPBWeb der Einstellung deines Betriebssystems. Deine Wahl speichert der Browser; sie gilt also für diesen Browser, nicht für dein Konto.

Den Umschalter gibt es auch auf der Anmeldeseite und als Befehl in der Befehlssuche (Strg K).

Farben im Editor

Auf der Seite Mein Konto stellst du im Abschnitt Farben im Editor ein, wie der Editor aussieht und in welchen Farben er Dateien hervorhebt. Das gilt für alle Editoren in oPBWeb: Scripteditor, Snippets, die Quelltextansicht des control und die Dateien auf dem Depot. Die Einstellung gehört zu deinem Konto und gilt auf jedem Gerät, an dem du dich anmeldest.

So ist der Abschnitt aufgebaut:

• Hell / Dunkel: Für die helle und die dunkle Darstellung gibt es je eine eigene Einstellung. Die Seite zeigt zuerst den Modus, in dem oPBWeb gerade läuft. Der Editor verwendet immer die Farben des aktuellen Modus.
• Editor (erster Eintrag der Liste links): die Farben des Editors selbst, also Hintergrund, Text, Randspalte, Zeilennummern, aktuelle Zeile, Auswahl und Cursor. Sie gelten pro Modus für alle Dateitypen. Als Quelle wählst du Wie Standard-Schema (die Editorfarben der Vorlage, die unter Standard gewählt ist), Vorlage (die Editorfarben einer anderen Vorlage, unabhängig von den Syntaxfarben) oder Eigene Farben. In eigene übernehmen kopiert die gerade wirksamen Farben nach Eigene Farben; dort passt du einzelne Farben an.
• Dateitypen (darunter in der Liste): Standard (alle Dateitypen) legt die Syntaxfarben für jeden Dateityp ohne eigenes Schema und für Textdateien ohne Hervorhebung fest. Darunter stehen opsi-script, Shell / Batch, control, Inno Setup, AutoIt, PowerShell, INI / REG / INF, XML, YAML, JSON und Python. Hinter jedem Typ steht wie Standard oder eigenes Schema.
• Vorlage: oPBWeb bringt bekannte Farbschemata mit, als helle Vorlagen oPBWeb, opsi ScriptEditor (Farben und Schrift des alten opsi ScriptEditors), GitHub Light, Solarized Light, One Light, VS Code Light+ und Gruvbox Light, als dunkle Vorlagen oPBWeb, GitHub Dark, Solarized Dark, One Dark, VS Code Dark+, Gruvbox Dark, Monokai, Dracula und Nord. Jede Vorlage lässt sich in beiden Modi wählen, auch eine dunkle Vorlage in der hellen Darstellung.
• Syntax: die Farben der Sprachelemente, die der gewählte Dateityp kennt, z. B. Kommentar, Sektion, Schlüsselwort, Funktion, Zeichenkette und Variable. Mit F (fett) und K (kursiv) neben jeder Farbe legst du die Schrift des Elements fest.
• Vorschau: zeigt ein kurzes Beispiel des gewählten Dateityps in den eingestellten Farben. Unter Editor zeigt sie das opsi-script-Beispiel mit den Syntaxfarben des Standards.

Farben einstellen

1. Wähl Hell oder Dunkel.
2. Für die Farben des Editors selbst: Wähl links Editor und eine Quelle. Für eigene Farben wähl zuerst eine Vorlage, klick auf In eigene übernehmen und ändere dann einzelne Farben.
3. Für die Syntaxfarben: Wähl links den Dateityp. Für alle Dateitypen auf einmal nimmst du Standard (alle Dateitypen).
4. Bei einem einzelnen Dateityp: Setz den Haken Eigenes Schema für diesen Dateityp. Das eigene Schema startet mit den Farben des Standards.
5. Wähl eine Vorlage.
6. Ändere bei Bedarf einzelne Farben: Klick auf das Farbfeld oder gib den Farbwert als Hex-Wert ein, z. B. #a31515. Schalte mit F und K fett und kursiv um. Ein geändertes Element bekommt den Knopf ↺, der wieder Farbe und Schrift der Vorlage einsetzt.
7. Klick auf Speichern.

Wechselst du die Vorlage eines Dateityps, verwirft oPBWeb die einzeln geänderten Farben und Schriften dieses Dateityps. Anpassungen zurücksetzen setzt alle Farben und Schriften des Dateityps auf die Vorlage zurück. Nimmst du den Haken Eigenes Schema für diesen Dateityp wieder heraus, gilt für den Dateityp wieder der Standard. Alle Farben zurücksetzen stellt nach einer Rückfrage für beide Modi die Editorfarben und die Syntaxfarben aller Dateitypen auf die Vorgaben von oPBWeb zurück. Auch das wird erst mit Speichern übernommen; Verwerfen stellt den zuletzt gespeicherten Stand wieder her.

Handbuch öffnen

Das Buch-Symbol in der Kopfleiste (Handbuch (neuer Tab)) öffnet dieses Handbuch in einem neuen Browser-Tab, und zwar in der aktuell eingestellten Oberflächensprache: bei Deutsch das deutsche, bei Englisch das englische Handbuch.

Navigation ein- und ausklappen

Die Aktivitätsleiste am linken Rand zeigt normalerweise nur Symbole; der Name eines Bereichs erscheint als Tooltip. Mit dem Symbol ☰ ganz links in der Kopfleiste (Menü mit Beschriftung ein-/ausklappen) blendest du die Beschriftungen ein, sodass neben jedem Symbol der Name steht. Ein weiterer Klick klappt die Leiste wieder ein.

Einen Überblick über die ganze Oberfläche gibt Erste Schritte .