opsi-Management-GUI: opsi-configed
Voraussetzungen und Aufruf
Der opsi-configed arbeitet mit den Daten eines auf dem Server laufenden opsiconfd mindestens der Version 4.1.
Das Programm steht auf download.uib.de in der jeweils aktuellen Version als opsi-Paket zur lokalen Installation zur Verfügung.
Zusätzlich kann der opsi-configed auch als Portable für die Betriebssysteme Windows, Linux und MacOS unter :http://download.uib.de/4.2/stable/misc/[] heruntergeladen werden. Auf diese Weise lässt sich das Programm auch ohne Installation starten.
Auf jedem System kann, wenn das benötigte jar-Archiv verfügbar ist, der Start des opsi-configed mittels java -jar configed.jar erfolgen.
Insbesondere zeigt dann der Aufruf java -jar configed.jar --help die Kommandozeilenoptionen:
-l [LOC] --locale [LOC] Set locale [LOC] (format: <language>_<country>)
-h [HOST] --host [HOST] Configuration server [HOST] to connect to
-u [NAME] --user [NAME] User for authentication
-p [PASSWORD] --password [PASSWORD] password for authentication
-c [CLIENT] --client [CLIENT] [CLIENT] to preselect
-g [CLIENTGROUP] --group [CLIENTGROUP] [CLIENTGROUP] to preselect
-t [INDEX] --tab [INDEX] Start with tab number INDEX, index counting starts with 0, works only if a CLIENT is preselected
-d [PATH] --logdirectory [PATH] Directory for the log files
-r [REFRESHMINUTES] --refreshminutes [REFRESHMINUTES] Refresh data every [REFRESHMINUTES] (where this feature is implemented, 0 = never)
-qs [SAVEDSEARCH_NAME] --querysavedsearch [SAVEDSEARCH_NAME] On command line: tell saved host searches list resp. the search result for [SAVEDSEARCH_NAME]
--ssh-key SSHKEY full path with filename from sshkey used for authentication on ssh server
--ssh-passphrase PASSPHRASE passphrase for given sshkey used for authentication on ssh server
--version Tell configed version
--collect_queries_until_no [N] Collect the first N queries; N = -1 (default, no collect), 0 = infinite
--help Give this help
--loglevel [L] Set logging level [L], [L] is a number >= 0, <= 9, Default 4
--halt Use first occurring debug halt point that may be in the code
--sqlgetrows Force use sql statements by getRawData
--nosqlrawdata Avoid getRawData
--localizationfile [EXTRA_LOCALIZATION_FILENAME] Use [EXTRA_LOCALIZATION_FILENAME] as localization file, the file name format has to be: configed_LOCALENAME.properties
--localizationstrings Show internal labels together the strings of selected localization
--swaudit-pdf FILE_WITH_CLIENT_IDS_EACH_IN_A_LINE [OUTPUT_PATH] export pdf swaudit reports for given clients (if no [OUTPUT_PATH] given, use home directory)
--swaudit-csv FILE_WITH_CLIENT_IDS_EACH_IN_A_LINE [OUTPUT_PATH] export csv swaudit reports for given clients (if no [OUTPUT_PATH] given, use home directory)Läuft der opsiconfd auf einem anderem als dem Standardport 4447, so ist dieser beim Start des opsi-configed dem Hostnamen mitzugeben (host:port).
Logging des opsi-configed
Der opsi-configed loggt defaultmäßig im Level 4 "Warning". Das Loglevel kann auf Level 1 bis 9 gesetzt werden. Zur Änderung des Loglevels gibt es auf die Kommandozeile die Option --loglevel [LEVEL] . Das Loglevel sollte beim Start nur auf 7 oder höher gesetzt werden, wenn bereits der configed-Start zu Problemen führt, da sonst die produzierte Logdatei sehr umfangreich wird und kaum noch durchgearbeitet werden kann. Wenn der configed läuft und eine mögliche Fehlersituation bei einer bestimmten Anforderung bevorsteht, kann vorher interaktiv über den Menüpunkt Hilfe/ConfigEditor Logstufe das verschärfte Logging eingeschaltet werden.
In Level 6 werden insbesondere die Service-Calls geloggt. Der Debug-Level (Level 7) bietet häufig die Möglichkeit, Aktionen sehr kleinschrittig zu verfolgen.
Die erzeugten Logdateien liegen per Default im Heimatverzeichnis des Users. Unter Windows werden sie dabei ab Version 4.1 im Verzeichnis
c:\Users\[Benutzername]\AppData\Roaming\opsi.org\log
abgelegt (wobei im Explorer statt "Users" die lokalisierte Bezeichnung steht, Achtung, der Explorer zeigt standardmäßig das Verzeichnis nur nach manueller Eingabe von AppData an).
Die aktuelle Logdatei heißt configed.log, die bis zu drei vorangegangen configed_0.log, configed_1.log, configed_2.log
Per Kommandozeilenparameter -d kann das Logging-Verzeichnis umgestellt werden.
Der Pfad zur aktuell genutzten Logdatei wird im Hilfemenü unter "Aktueller Logfile" angezeigt. Bei Aufruf des Punktes kann der Pfad in die Zwischenablage übernommen werden, um ihn im Öffnen-Dialog eines Editor zu verwenden; oder es kann direkt die Default-Anwendung für .log-Dateien geöffnet werden.
Die Auswahl der Sprache
Der opsi-configed versucht für seine Spracheinstellung die Lokalisierungsinformation des Betriebssystems zu verwenden. Sofern er nicht über die passende Übersetzungsdatei verfügt, verwendet er Englisch als Defaultsprache. Ebenso werden, wenn in der Übersetzungsdatei Terme fehlen, die Ausdrücke der englischen Sprachdatei eingesetzt.
Beim Aufruf des opsi-configed kann über den Parameter
-l bzw. --locale
eine Sprache im Zweizeichen-Format language_region vorgegeben werden, z.B. en_US oder de_DE. Es genügt aber bereits die Angabe von z.B. en, da die Sprachdatei Englisch für jede Variante der Sprache verwendet wird.
Im laufenden opsi-configed kann die Sprache über den Menüpunkt Datei/International geändert werden. Dies führt zu einer Reinitialisierung des Programms mit einem Neuaufbau (fast) aller Komponenten in der neuen Sprache.
Schließlich kann mit dem Aufrufparameter
--localizationfile
direkt eine Lokalisierungsdatei vorgegeben werden. Mit dem Zusatzparameter
--localizationstrings
werden auch die Terme angezeigt, die in der Lokalisierungsdatei stehen und übersetzt werden müssen. Dies kann als Hilfe beim Anlegen und Testen einer Übersetzungsdatei genutzt werden.
Login
Beim Login versucht sich der opsi-configed per https mit dem opsiconfd auf dem ausgewählten Server/Port zu verbinden. Wenn der 'opsiconfd' seinen Defaultport 4447 verwendet, muss dieser nicht angegeben werden. Die User müssen der Unix-Gruppe opsiadmin angehören.
Der opsi-configed speichert im lokalen Benutzerprofil einige Information über die jeweilige Session, damit beim erneuten Login die Arbeitsumgebung wiederhergestellt werden kann, insbesondere eine ausgewählte Client-Gruppe. Seit Version 4.0.7 werden die Session-Informationen auch genutzt, um eine Auswahlliste der zuletzt verbundenen opsi-Server (z.B. produktiver und Test-Server) zu erzeugen. An oberster Stelle steht der zuletzt genutzte, der damit ohne explizite Auswahlaktion wieder verwendet werden kann.
Vor der Verbindung mit einem Server findet eine Verifizierung des opsi-CA-Zertifikats statt. Bei der ersten Verbindung mit einem Server müssen Sie zuerst bestätigen, dass sie dem Zertifikat des Servers vertrauen. Durch einen Klick auf 'Diesmal vertrauen' verbinden Sie sich und die Warnung tritt beim nächsten Mal erneut auf. Wenn Sie auf 'Immer vertrauen' klicken, wird das Zertifikat in einem lokalen Ordner abgespeichert und auch für zukünftige Verbindungen benutzt. Das hat den Sinn, dass von dann an diese Warnung nur noch dann auftreten soll, wenn ein Angreifer mit einem gefälschten Zertifikat versucht, sich mit Ihnen zu verbinden und so an Ihre Anmeldedaten zu kommen.
Copy & Paste, Drag & Drop
Sie können aus (fast) allen Bereichen des opsi-configed die markierten Daten mit den üblichen Tastenkombinationen (Strg-Insert, Strg-C) in die Zwischenablage kopieren und so anderen Programmen zur Verfügung stellen.
Für die meisten Tabellen ist auch die Drag & Drop-Funktion aktiviert, mit der die Tabellendaten z.B. nach Excel transferiert werden können.
Auswahl des Bedienungsmodus
Um zwischen verschiedenen Funktionen des opsi-configed zu wechseln, befinden sich seit Version 4.0.4 rechts oben im opsi-configed-Fenster sechs Schaltflächen.
Die durch die ersten drei Schaltflächen wählbaren Modi Clientkonfiguration, Depotkonfiguration (Depot-Properties) oder Serverkonfiguration (Server-Configs) verändern das Zielobjekt des Hauptfensters, die Schaltflächen Gruppenaktionen, Produktaktionen sowie 'Lizenzmanagement' starten jeweils spezifische Fenster mit eigenen Objekten und Aktionsmöglichkeiten.
Diese Fenster können statt über die Schaltflächen auch über den Hauptmenüpunkt Fenster geöffnet werden (ab opsi-configed Version 4.0.7).
Depotauswahl
Werden an Ihrem opsi-Server mehrere Depotserver betrieben, so werden diese in einer Liste am linken Rand des opsi-configed angezeigt.
Per default ist das Depot auf dem opsi-configserver markiert und die zu diesem Depot gehörigen Clients werden angezeigt. Die Liste der Depotserver ist eine Mehrfachauswahlliste. D.h. mehrere Depots können markiert werden, es werden alle zugehörigen Clients gezeigt (genauer, alle Clients, die auf irgendeinem der ausgewählten Depots zur ausgewählten Gruppe (s. dort) gehören).
Die gemeinsame Clientanzeige gestattet nur dann, Clients gemeinsam z.B. in ihrer Produktkonfiguration zu bearbeiten, wenn sie Depots mit identischer Paketkonfiguration angehören, d.h. die Depots untereinander synchron sind. Der Versuch, Clients aus asynchronen Depots gemeinsam zu bearbeiten, wird mit einer entsprechenden Warn- und Fehlermeldung abgewiesen.
Für die erleichterte Depotselektion existieren mehrere Funktionen:
-
(=+) : Alle Depots mit identischen Produkten werden ausgewählt
-
(++) : Alle Depots werden ausgewählt (auch mit Strg-a möglich)
-
Textsuche im Namen der Depots und optional auch in der Beschreibung
Im Suchfeld kann mit dem ersten Checkfeld
Der opsi-configed speichert lokal (auf dem PC, auf dem er läuft) und User- sowie Server-bezogen die zuletzt getätigte Depot- und Gruppenauswahl und aktiviert sie beim nächsten Start wieder.
Zu beachten: Beim Depotwechsel bleibt die Gruppenauswahl erhalten, was nicht unbedingt das Gewünschte ist. Gegebenfalls muss daher für das neue Depot eine andere Gruppe bzw. die ganze CLIENT-LISTE aktiviert werden.
Clientauswahl
Nach erfolgreichem Login zeigt sich das Hauptfenster mit dem aktiviertem Karteireiter Clients zur Auswahl von Clients. Das Hauptfenster zeigt die Liste der Clients, wie sie durch die Depotwahl gegeben bzw. im 'Treeview' - s. Clientauswahl und hierarchische Gruppen im Treeview - bestimmt ist.
Der opsi-configed speichert lokal auf dem Rechner, auf dem er läuft userbezogen die zuletzt getätigte Gruppenauswahl und aktiviert sie beim nächsten Start wieder.
In der Liste kann eine Zeile auch über die Suche nach einem Stringwert ausgewählt werden, der im Suchfeld oberhalb der Liste einzugeben ist.
Wie die Suche ausgeführt wird, ist durch die Auswahl in den Drop-down-Listen zu den Feldern und zum Suchverfahren bestimmt. Die Feld-Auswahl bietet an:
-
Suche in allen Feldern (genauer, allen Feldern, die nach der momentanten Konfiguration als Spalten dargestellt werden, (Default) oder
-
Suche in einem bestimmten Feld.
Beim Suchverfahren (erweitert in Version 4.0.7) kann man sich entscheiden zwischen den Varianten
-
"Volltext": die Sucheingabe wird verwendet wie beim Standard-Googlen; d.h. wenn die Eingabe mehrere (durch Leerzeichen getrennte) Suchwörter (bzw. Wortbestandteile) enthält, muss mindestens eines in einer Spalte gefunden werden;
-
"Volltext (Komplettstring)": die Sucheingabe wird verwendet, als würde man beim Googlen den Text in Anführungszeichen setzen; d.h. der Gesamttext muss irgendwo in einer Spalte gefunden werden;
-
"Anfangstext": der Suchstring muss als Beginn einer Spalte vorkommen;
-
"regulärer Ausdruck": Suchstring wird sog. regulärer Ausdruck interpretiert, d.h. es werden Zeilen gesucht, bei denen der Text einer Spalte nach den Prinzipien der Regulären Ausdrücke (vgl. die Java-Dokumentation für java.util.regex.Pattern) "matcht"
Betätigen der Return-Taste springt auf den nächsten Treffer der Suche (ohne Treffer: nächste Zeile).
Weitere Auswahlfunktionen basierend auf der Suche zeigt das Kontextmenü des Suchfeldes:
|
Beispiele für Suchmuster (Such-Pattern)
Alle PCs, in deren Name oder Beschreibung die Zeichenfolge Meyer vorkommt, werden mit dem Pattern .*eyer.* gefunden. Dabei steht der Punkt in ".*" für ein "beliebiges Zeichen" und das Sternchen für "eine beliebige Zahl von Vorkommen (des vorher bezeichneten Elements)". .*eyer.* bedeutet also, das Suchmuster trifft zu (es "matcht"), sofern vor eyer irgendetwas (irgendwelche Zeichen in irgendeiner Zahl) steht und auf eyer wieder irgendetwas folgt. Weil "irgendeine Zahl" auch 0 sein darf, passt z.B. auch der String PC Meyer, bei dem auf eyer gar kein Zeichen mehr folgt, zum Suchstring. Um aber sicherzugehen, dass wir nicht auch Strings, die Beyer enthalten, als korrekt markieren, sollte das Suchmuster besser heißen .*[Mm]eyer.* Mehrere Zeichen eingeschlossen in eckigen Klammern bedeuten, dass der gesuchte Wert genau eines der aufgeführten Zeichen enthält. Das heißt, jetzt wird jeder String erkannt, der entweder Meyer oder meyer enthält. Als weiteres Beispiel sei eine Patternsuche bei Produkten dargestellt. 0.-opsi.*standard sucht alle Produkte, deren Namen mit "0" beginnt gefolgt von einem beliebigen Zeichen, gefolgt von -opsi gefolgt von irgendwelchen Zeichen (in beliebiger Zahl); und am Schluss steht standard. Wenn man sichergehen will, dass das zweite Zeichen eine Ziffer, das heißt eines der Zeichen "0", "1", "2", "3", "4", "5" , "6", "7", "8", "9" ist, kann man schreiben 0[0123456789]-opsi.*standard Als Abkürzung für [0123456789] gilt, da es sich um eine ununterbrochene Teilfolge der Folge aller Zeichen handelt, [0-9], der Ausdruck wird damit zu 0[0-9]-opsi.*standard Zu diesem Suchmuster passen z.B. die Produkte 03-opsi-abo-standard sowie 05_opsi-linux_standard Nähere Information zur Suche mit regulären Ausdrücken können in der java API-Dokumentation, Stichwort "java.util.regex.Pattern", gefunden werden. |
Die Clientliste
Die tabellarische Auflistung der Clients hat per Default die Spalten Client-Name, Beschreibung, An, IP-Adresse und Zuletzt gesehen.
-
Client-Name ist der full qualified hostname also der Clientname inklusive (IP-) Domainnamen.
-
Beschreibung ist eine frei wählbare Beschreibung, die im rechten oberen Teil des Fensters editiert werden kann.
-
In der mit An betitelten Spalte wird auf Betätigen des Buttons 'Prüfen, welche Clients verbunden sind' das Resultat der entsprechenden Anfrage angezeigt. Das Feature lässt sich in der Anmeldemaske sowie per Aufrufparameter aktivieren. Default ist ein Test-Intervall von 0 min (= ausgeschaltet).
-
IP-Adresse enthält die IP-Nummer, als die der opsi-Server den Clientnamen auflöst.
-
Zuletzt gesehen gibt Datum und Uhrzeit an, zu der sich der Client zum letzten Mal bei der Softwareverteilung (über den Webservice) gemeldet hat.
In der Defaultkonfiguration deaktiviert sind die Spalten
-
Session-Informationen (beziehbar vom Betriebssystem des Clients),
-
opsi-Mac-Adresse (Hardware-Adresse des Clients, die vom Opsi-Server verwendet wird),
-
Inventarnummer (optional erfasster kennzeichnender String) und
-
Erstellungsdatum (Datum und Zeit der Client-Erzeugung).
Während einer Sitzung können sie mittels des Kontextmenüs eingeblendet werden. Welche Spalten beim Start des opsi-configed angezeigt werden, kann in der Server-Konfiguration mittels des Configs configed.host_displayfields bearbeitet werden.
Das Hinzufügen der Spalte Session-Informationen schaltet den Button Abfrage der Session-Informationen von allen Clients auf aktiv.
Bei Betätigen des Buttons versucht sich der opsiconfd mit allen Clients zu verbinden und Information über die auf den Clients derzeit aktiven (User-) Sessions einzusammeln. In der Spalte 'Session-Informationen' wird der Account-Name der laufenden Sitzungen dargestellt. Mittels Kontextmenü sowie über den Hauptmenüpunkt 'OpsiClient' kann das Entsprechende nur für die gerade ausgewählten Clients erreicht werden. Dies vermeidet ggfs. das Warten auf die Netzwerk-Timeouts beim Verbindungsversuch mit gar nicht angeschalteten Rechnern.
Da die Suchfunktion der Clientliste sich (wenn nichts anderes eingestellt ist) über alle angezeigten Spalten erstreckt, kann nach Abruf der Session-Informationen auch nach dem Rechner gesucht werden, auf dem ein User mit bekanntem Account-Namen gerade angemeldet ist.
Die Clientliste kann durch Anklicken eines Spaltentitels nach der entsprechenden Spalte sortiert werden
Auswahl von Clients
In der Clientliste lassen sich ein oder mehrere Clients markieren und so für die (gemeinsame) Bearbeitung auswählen.
Mittels des Trichter-Icons bzw. über Auswahl / Nur die ausgewählten Clients anzeigen kann die Anzeige der Clientliste auf die markierten Clients beschränkt werden
Die ausgewählten Clients können zu einer existierenden Gruppe hinzugefügt werden (die im Treeview sichtbar ist), indem sie mit der Maus "auf die Gruppe gezogen" werden.
Im Client-Auswahldialog, der über Auswahl / Auswahl definieren oder über das Icon Auswahl definieren gestartet wird, können dynamische Clientzusammenstellungen anhand wählbarer Kriterien erstellt werden.
Neben allgemeinen Eigenschaften der Clients (Rubrik 'Wähle nach Host Eigenschaften') können als Suchkriterium auch (sowohl auf dem PC gefundene als auch mit Opsi installierte) Software sowie Hardware-Komponenten verwendet werden. Bei Texteingaben kann '*' als Wildcard benutzt werden. Die einzelnen Kriterien können dabei mit logischem AND (UND) bzw. OR (ODER) verknüpft werden wie auch negiert werden durch ein vorangestelltes NOT (NICHT) (erzeugt durch Anklicken des Not-Feldes vor dem Eigenschaftsnamen)
Die Auswahlliste, betitelt 'Kriterium hinzufügen', stellt weitere Kriterien zur Definition einer Anfrage bereit. Mit dem Papierkorb-Icon am rechten Rand wird ein Suchkriterium entfernt. Den initialen Zustand der Suchmaske stellt ein Klick auf den Button 'Neue Anfrage' wieder her.
Die erstellten Anfragen lassen sich unter einem frei wählbaren Namen speichern. Anschließend kann man sie über Auswahl / Gespeicherte Suchen… erneut abrufen. Falls beim Speichern das Feld Beschreibung ausgefüllt wurde, wird diese in der Auswahlliste als Tooltip angezeigt.
Falls bis zum nächsten Aufruf weitere Clients hinzugekommen sind, die den gespeicherten Suchkriterien entsprechen, werden diese beim nächsten Aufruf der Suche ebenfalls gefunden.
Für eine feste Gruppenbildung mit ganz bestimmten Clients siehe weiter unten Clientauswahl und hierarchische Gruppen im Treeview
Zusätzlich ist noch die Abfrage von Suchen über eine Kommandozeilen-Schnittstelle möglich, um sie auch Skripten zugänglich zu machen. Dazu wird der opsi-config-editor mit dem Parameter "-qs" und anschließend dem Namen
einer Suche aufgerufen. Lässt man den Namen der Suche weg, wird eine Liste der vorhandenen Suchen ausgegeben.
Unter dem Menüpunkt Auswahl die Punkte Fehlgeschlagene Aktionen bei Produkt… und Fehlgeschlagene Aktionen (heute, seit gestern, …),
gibt es die Möglichkeit, fehlerhafte Installationen zu suchen.
Wählt man den ersten Punkt, erhält man eine Liste aller Produkte. Selektiert man ein Produkt, so werden
alle Clients markiert, bei denen die Installation dieses Produktes fehlgeschlagen ist.
Wählt man z.B. Fehlgeschlagene Aktionen - heute, werden all die Clients markiert, bei denen heute mindestens ein Produkt fehlgeschlagen ist.
Clientauswahl und hierarchische Gruppen im Treeview
Clients können komfortabel gruppenweise verwaltet werden, indem die Baumansicht-Komponente auf der linken Seite des opsi-configed-Fensters genutzt wird.
Prinzipieller Aufbau
Der Treeview hat drei Basisknoten Gruppen, Directory und Client-Liste. In der Client-Liste werden automatische alle Clients der ausgewählten Depots aufgeführt.
Die ersten zwei Basisknoten unterscheiden sich darin, wie oft ein Client in ihnen bzw. in Unterknoten von ihnen vorkommen darf.
Das Prinzip lautet: Während eine Gruppe eindeutig durch ihren Namen bestimmt ist und nicht mehrfach vorkommen kann, kann ein Client beliebig vielen Gruppen angehören. Im 'Directory'-Teilbaum hat jedoch jeder Client einen eindeutigen Ort; solange keine explizite Zuweisung zu einer anderen Untergruppe von 'Directory' stattgefunden hat, wird der Client automatisch in der Gruppe 'NICHT_ZUGEWIESEN' angezeigt.
Wenn ein Client markiert ist, sind alle Gruppen, denen er angehört, mit gefüllter Farbfläche ausgezeichnet.
How to …
Wenn Sie auf einen Baumknoten (eine Gruppe) klicken, so werden alle Clients, die sich unterhalb dieses Knotens befinden, in der Tabelle im Client-Tab angezeigt (aber kein Client zur Bearbeitung ausgewählt).
Wenn Sie auf in der Baumansicht einen Client klicken oder mehrere Clients per Strg-Klick bzw. Shift-Klick markieren, so werden diese im Client-Tab angezeigt und zur Bearbeitung markiert.
Mit Doppelklick auf eine Gruppe werden die ihr angehörenden Clients in der Tabelle angezeigt und direkt ausgewählt.
Sie können auf diese Art und Weise auch den Client /oder die in Bearbeitung befindlichen Clients wechseln, während Sie in anderen Tabs (wie z.B. Logdateien) arbeiten, ohne zwischendurch zum Client-Tab zu gehen.
In diesem Treeview werden die Gruppen angezeigt, die Sie gemäß Auswahl von Clients angelegt haben. Sie können zusätzlich Gruppen definieren, indem Sie mit der rechten Maustaste über der Eltern-Gruppe bzw. dem Eltern-Knoten (z.B. "GRUPPEN") das Kontextmenü öffnen und 'Untergruppe erzeugen' wählen.
Wenn Sie dies gemacht haben, werden Sie in einem Dialogfenster nach dem Namen der Gruppe und einer optionalen Beschreibung gefragt.
Eine Gruppe können Sie nun mit Clients füllen, indem Sie mit gedrückter linker Maustaste per Drag&Drop:
-
Clients aus der tabellarischen Clientliste im Tab "Clients" in die Gruppe ziehen
-
Clients aus einer anderen "normalen" Gruppe, z.B. dem Hauptknoten 'CLIENT-LISTE', ziehen = kopieren
-
Clients aus dem Treeview aus einer Direktory-Gruppe in eine andere Directory-Gruppe ziehen = verschieben
Eine Gruppe kann
-
per Drag & Drop in eine andere Gruppe verschoben werden;
Das Kontextmenü einer Gruppe dient dazu
-
Untergruppen zu erzeugen;
-
die Gruppeneigenschaften zu bearbeiten;
-
bei Bedarf die Gruppe (samt ihren Untergruppen und allen Clientzuordnungen) zu löschen;
-
alle Clientzuordnungen entfernen, wobei die Gruppe und ihre Untergruppen erhalten bleiben;
-
die enthaltenen Clients anzuzeigen und in einem Schritt auszuwählen.
Client-Bearbeitung
Im Client-Tab können Sie über den Menüpunkt 'OpsiClient' oder das Kontextmenü eine Reihe clientspezifischer Operationen starten. Außerdem befinden sich auf der rechten Seite Eigenschaften von dem ausgewählten Client, die bei Auswahl eines Clients editierbar sind.
Install By Shutdown, Uefi-Boot und WAN-Konfiguration
Einige Standard Konfigurationen für einen Client können direkt in der Client-Information gesetzt werden, die sich rechts von der Client-Liste befindet. Zu beachten ist, dass es sich bei der UEFI-Boot-Unterstützung und bei der WAN-Konfiguration um derzeit kostenpflichtige Erweiterungsmodule handelt. Wenn die Module nicht aktiv sind, werden die Buttons ausgegraut.
-
Install By Shutdown:
Der herkömmliche Weg, Installationen beim Herunterfahren des Rechners zu konfigurieren, ist im Abschnitt opsi Installation beim Shutdown beschrieben. Dies wird vereinfacht durch die Buttons "An" und "Aus", welche beim Betätigen, den opsi-client-agent mit dem entsprechenden Wert für das Product-Property "on_shutdown_install" auf setup setzten. Bislang ist es nicht möglich den Status anzeigen zu lassen, ob ein Client beim Hoch- oder Herunterfahren die Pakete installiert. -
Uefi-Boot:
Die Checkbox Uefi-Boot zeigt an, ob ein Client für den Uefi-Boot konfiguriert ist. Beim Aktivieren wird die Konfigurationclientconfig.dhcpd.filenamezulinux/pxelinux.cfg/elilo.efigeändert. (Weiteres im Abschnitt opsi mit UEFI / GPT) -
WAN-Konfiguration:
Der opsi-configed prüft, ob die Standard-WAN-Konfiguration für den Client vorliegt oder nicht. Entsprechend ist der Haken für WAN-Konfiguration gesetzt oder nicht. Und wenn man den Haken manuell setzt, wird die Standard-Konfiguration eingerichtet.
Diese Konfiguration ist seit Version 4.0.7.6.5 nicht mehr hart kodiert, sondern wird aus den Server-Hostparametern configed.meta_config.wan_mode_off* ausgelesen bzw. als deren Verneinung interpretiert. Wenn man die automatisch eingerichteten Meta_Config.wan_mode*-Parameter beibehalten hat, kommt die in opsi WAN/VPN-Erweiterung beschriebene, von der uib GmbH empfohlene Standard-WAN-Konfiguration zum Zuge.
| Ob der Client als WAN-Client konfiguriert ist oder einen UEFI-Boot macht, kann in der Client-Tabelle auch in passenden Spalten dargestellt werden. Für die laufende Session werden sie im Menüpunkt 'OpsiClient' oder im Kontextmenü aktiviert, dauerhaft über den Eintrag configed.host_displayfields bei den Server-Hostparametern. Dann ist direkt in der Übersicht erkennbar, für welche Clients die Eigenschaft gesetzt ist, und es kann auch danach gesucht und sortiert werden. |
WakeOnLan-Funktionalität mit versetzten Zeiten
Bei der WakeOnLan-Funktion kann ab opsi-configed Version 4.0.7 gewählt werden
-
ob das Netzwerksignal direkt an alle ausgewählten Clients geschickt wird
-
ob es mit einem Abstand je zwischen zwei Clients versandt werden soll
-
wann der Prozess starten soll (Scheduler).
Wenn der Client einem mit dem configserver nicht identischen Depotserver zugeordnet ist, wird das WakeOnLan-Signal nicht direkt an den Client geschickt, sondern es wird eine HTTPS-Verbindung zum opsiconfd auf dem Depotserver aufgebaut und dieser veranlasst, in seinem Netz das Netzwerkpaket zu schicken.
Zu beachten ist, dass es der opsi-configed ist, der die Aktionen auslöst, d.h. das Programm darf in diesem Zeitraum nicht beendet werden.
Auslösen von opsiclientd-Events (Push-Installation)
Über diesen Menüpunkt wird den selektierten Clients ein Aufruf an den opsi-client-agent gesendet, durch den ein Event ausgelöst wird. Wenn ein Client nicht erreichbar ist oder gerade ein anderes Event verarbeitet, was nicht unterbrochen werden kann, so meldet der opsi-configed dies mit einem Fehlerhinweis.
Default-Event ist on_demand, das dazu führt, dass Aktionsanforderungen für den Client unmittelbar ausgeführt werden.
| Wenn ein Produktskript eine Rebootanforderung enthält, so wird der Client ohne Vorwarnung rebootet. |
Seit Version 4.0.4 können auch andere Events, die in der opsiclientd.conf konfiguriert sind, ausgelöst werden. Welche zur Auswahl angeboten werden, wird über den Server-Hostparameter configed.opsiclientd_events festgelegt.
Für WAN-Clients: Pakete-Cache löschen
Auf WAN-Clients kann es zu Problemen mit dem Pakete-Cache kommen. Daher wird für sie eine Funktion angeboten, den Pakete-Cache komplett zu resetten.
Nachrichten senden ('Starte Meldungsfenster')
Über die Auswahl von 'Starte Meldungsfenster auf den ausgewählten Clients' erhalten Sie die Möglichkeit, Nachrichten an einen oder mehrere Clients zu senden. Es erscheint zunächst ein Fenster in dem Sie die Nachricht editieren können.
Durch Anklicken des roten Häkchens versenden Sie die Nachricht. Auf den selektierten Clients wird nun die Nachricht angezeigt:
Sessioninfo der ausgewählten Clients
Sie können den ausgewählten Clients das Signal senden, dem opsi-configed ihre Session-Informationen mitzuteilen. Diese Informationen werden in der entsprechenden Spalte dargestellt, soweit diese eingeblendet ist.
Herunterfahren / Reboot der ausgewählten Clients
Sie können den ausgewählten Clients das Signal senden, herunterzufahren bzw. zu rebooten.
| Der Client fährt ggf. ohne Rückfrage herunter. |
Externe Remotecontrol-Werkzeuge für die ausgewählten Clients aufrufen
Mit der Option Remote Control Software im Kontextmenü sowie im Client-Menü (ab opsi-configed Version 4.0.1.11) können beliebige Betriebssystem-Kommandos aufgerufen werden, parametrisiert z.B. mit dem Clientnamen.
Beispielhaft sind zwei Konfigurationen zum Anpingen des ausgewählten Hosts automatisch mitgeliefert, und zwar ein Kommando, das unter Windows ausgeführt werden kann, und eines, das in einer graphischen Linux-Umgebung arbeitet. Zur Verdeutlichung: Der opsi-configed ruft das jeweilige Kommando aus seiner Systemumgebung auf. D.h., die Form des benötigten Kommandos hängt davon ab, ob der opsi-configed unter Windows oder Linux läuft.
Das Auswahlfenster ist dreigeteilt: Oben steht die Liste der Namen der verfügbaren Aufrufe. Es folgt eine Zeile, in der das ausgewählte Kommando angezeigt wird sowie, falls zulässig, verändert werden kann. Die Zeile enthält auch Buttons für Start und Abbruch der Aktion. Der dritte Textbereich des Fensters gibt eventuelle Rückmeldungen des Betriebssystems beim Aufruf des Kommandos wieder.
Die Möglichkeiten, die sich bieten, sind quasi unerschöpflich. Z.B. kann ein Kommando konfiguriert werden, das eine RemoteDesktop-Verbindung zum ausgewählten Client öffnet (sofern dieser das zulässt). Unter Windows kann dafür z.B. der folgende Befehl verwendet werden:
cmd.exe /c start mstsc /v:%host%
Ein entsprechendes Linux-Kommando lautet z.B.:
rdesktop -a 16 %host%
Dabei ist %host% eine Variable, die vom opsi-configed automatisch durch den entsprechenden Wert
für den Hostnamen ersetzt wird. Weitere Variable, die im Kommando verwendet werden können, sind:
-
%ipaddress% -
%hardwareaddress% -
%opsihostkey% -
%inventorynumber% -
%depotid% -
%configserverid%
Sofern das Kommando mit editable true gekennzeichnet ist, können in der angezeigten Kommandozeile
z.B. Passwörter oder andere ad-hoc-Variationen des Befehls eingegeben werden.
| Sobald irgendein Kommando als editable gekennzeichnet ist, hat faktisch der configed-Bediener die Möglichkeit, das vorgegebene Kommando in ein 'beliebiges' Kommando umzuwandeln und damit beliebige Programme mit Bezug auf den Client-Rechner zu starten. |
Sind mehrere Clients markiert, wird das Kommando auf allen ausgewählten parallel ausgeführt.
Die Liste der verfügbaren Kommandos wird über Server-Konfigurationseinträge bearbeitet (vgl. Host-Parameter in der Client- und der Serverkonfiguration).
Um ein Kommando des Namens example zu definieren, muss minimal ein Eintrag configed.remote_control.example
(oder configed.remote_control.example.command) erzeugt werden. Als Wert des Properties wird
das Kommando (ggfs. unter Verwendung von Variablen %host%, %ipaddress% usw.) gesetzt.
Zusätzlich kann ein Eintrag der Form configed.remote_control.example.description definiert werden. Der Wert
dieses Eintrags wird als Tooltip angezeigt. Mit einem Booleschen Eintrag der Form configed.remote_control.example.editable
kann durch Setzen des Wertes auf false festgelegt werden, dass das Kommando beim Aufruf nicht
verändert werden darf.
Clients entfernen, erstellen, umbenennen, umziehen
Sie können den ausgewählten Clients aus dem opsi-System löschen.
Sie haben hier auch die Möglichkeit, Clients neu anzulegen. Über den Menü-Punkt Neuen OpsiClient erstellen, erhalten Sie eine Maske zur Eingabe der nötigen Informationen zur Erstellung eines Clients.
Diese Maske enthält auch Felder für die optionale Angabe der IP-Nummer und der Hardware- (MAC)-Adresse. Wenn das Backend für die Konfiguration eines lokalen DHCP-Servers aktiviert ist (dies ist nicht der Default), werden diese Informationen genutzt, um den neuen Client auch dem DHCP-Server bekannt zu machen. Ansonsten wird die MAC-Adresse im Backend gespeichert und die IP-Nummer verworfen.
Beim Anlegen von Clients kann, ab der Version 4.0.5.8.1, für den neuen Client direkt eine Gruppe angegeben werden, zu der er gehören soll, sowie welches Netboot-Produkt eventuell direkt auf setup gesetzt werden soll. Außerdem kann direkt Install by shutdown, Uefi-Boot sowie die (Standard-) WAN-Konfiguration aktiviert werden. Diese Einstellungen können auch ganz einfach in der Hosts-Liste vorgenommen werden.
Seit opsi 4.0.4 können, falls die opsi-Clients z.B. über einen UCS-Service angelegt werden sollen, die Optionen zum Anlegen und Löschen von Clients abgeschaltet werden.
Zur Steuerung dieser Option existiert ein Hostparameter (Config) configed.host_actions_disabled, in dem
die beiden Listenwerte
-
add client -
remove client
zur Verfügung stehen, wobei Mehrfachselektion möglich ist. Default ist <leer>, also kein Wert ist gewählt.
Sie können die Default-Einstellung im opsi-configed über die Serverkonfiguration oder mit folgendem Befehl so ändern, dass ein Erstellen und Löschen von Clients über den opsi-configed nicht mehr möglich ist.
opsi-admin -d method config_updateObjects '{"defaultValues": ["add client", "remove client"], "editable": false, "multiValue": true, "possibleValues": ["add client", "remove client"], "type": "UnicodeConfig", "id": "configed.host_actions_disabled"}'Es gibt nun auch eine Möglichkeit für das erstellen von vielen Clients auf einmal im configed. Im Fenster zur Clienterstellung lässt sich durch Klicken auf Template ein CSV-Template erstellen. Dieses kann dann per Texteditor oder Programmen wie Microsoft Excel oder Libreoffice Calc bearbeitet werden, um beliebig viele Clients samt ihrer Eigenschaften aufzulisten. Indem über den Button Datei diese Liste geöffnet wird, werden alle in der Datei aufgelisteten Clients erstellt.
Sie können den ausgewählten Client innerhalb von opsi umbenennen. Sie werden dann in einem Dialogfenster nach dem neuen Namen gefragt.
Ein weiterer Dialog steht für den Umzug von einem Client oder mehreren Clients zu einem anderen Depot zur Verfügung:
Localboot-Produkte
Wechseln Sie auf den Karteireiter Localboot-Produkte, so erhalten Sie die Liste der zur Softwareverteilung bereitstehenden Produkte und des Installations- und Aktionsstatus zu den ausgewählten Clients.
Darüber hinaus finden Sie in der rechten Seitenleiste hilfreiche Informationen zu dem ausgewählten Produkt, wie Produktname und -version. Die Felder für Produktinformationen und -beschreibung unterstützen auch die Darstellung von MarkDown, sofern das für die Erstellung der Produktpakete in der control.toml-Datei verwendet wurde.
Auch Produktabhängigkeiten werden samt der Eigenschaften der Abhängigkeiten in einer Tabelle dargestellt. Darunter findet sich zudem noch ein Abhängigkeitsbaum, der die Abhängigkeiten rekursiv anzeigt. Dort kann nicht nur angezeit werden, welche anderen Produkte das ausgewählte benötigt, sondern auch, von welchen es benötigt wird. Das ist zum Beispiel nützlich, wenn Sie vor dem Entfernen eines Produkts überprüfen wollen, ob es noch von anderen benötigt wird.
Seit opsi 4.0.4 wird hier eine Suchfunktion angeboten. Mit der Suchfunktion kann nach Produktnamen bzw. - je nach Einstellung in der Auswahlbox - nach Werten in den Feldern der Produkttabelle gesucht werden (analog zur Suche in der Client-Tabelle). Dazu ist im Suchfeld ein Suchstring einzugeben, die Suche startet direkt und die erste Trefferzeile wird markiert. Wenn es keinen Treffer gibt oder Zeichen aus dem Suchstring gelöscht werden, geht die Markierung auf die erste Tabellenzeile.
Im Kontextmenü des Suchfeldes werden weitere Optionen angeboten.
Hilfreich kann die Benutzung der Filterfunktion sein. Aktivieren des Filters reduziert die angezeigten Produkte auf die in diesem Moment markierten. Die Auswahl bleibt erhalten, bis der Filter durch erneutes Anklicken des Filterbuttons wieder deaktiviert wird.
Werte in der Produktliste, die für die ausgewählten Clients unterschiedlich sind, werden grau (als Darstellung des Wertes 'undefined') angezeigt.
Sie können auch für die Produktliste eine Sortierung nach einer anderen als der ersten Spalte durch Anklicken des Spaltentitels erreichen. Verfügbar sind die folgenden Spalten:
-
Stand ist der letzte der Softwareverteilung gemeldete Status zu diesem Produkt und kann die Werte installed, not_installed und unknown haben. not_installed wird aus Gründen der Übersichtlichkeit nicht angezeigt. 'unknown' ist der Status üblicherweise während einer (De-)Installation sowie wenn das letzte Skript gescheitert ist.
-
Report ist eine Zusammenfassung der Werte der internen Statusinformationen "Installationsfortschritt" ('actionProgress'), "Ergebnis der letzten Aktion" (actionResult) und "letzte angeforderte Aktion" (lastAction). Während einer Installation steht hier z.B. 'installing' Nach Abschluss einer Aktion enthält das Feld den Text Ergebnis (letzte Aktion), z.B. failed (setup) oder success (uninstall).
-
Angefordert ist die Aktion, welche ausgeführt werden soll. Ein möglicher Wert ist immer none (visuell ist das Feld leer). Darüber hinaus sind die Aktionen verfügbar, für die bei diesem Produkt Skripte hinterlegt wurden. Möglich sind setup, uninstall, update, once, always, custom.
-
Prioritätsklasse gibt an, welche Priorität (100 bis -100) dem Produkt zugeordnet wurde (per default ist die Spalte nicht sichtbar.)
-
Position gibt an, in welcher Reihenfolge die Produkte installiert werden, per Default ebenfalls keine sichtbare Spalte.
-
Version ist die Kombination aus Produkt-Version und Package-Version, des auf dem Client installierten opsi-Softwareprodukts.
Durch das Anwählen eines Produkts erhalten Sie auf der rechten Seite des Fensters weitere Informationen zu diesem Produkt. Im Einzelnen:
-
ProduktID:: Klartextname des Produktes
-
Software/Paketversion: Produktversion-Paketversion der zur Verteilung bereitstehenden Software (wie sie der Paketierer angegeben hat).
-
Produktbeschreibung: Freier Text zur im Paket enthaltenen Software.
-
Hinweise: Freier Text mit Angaben zum Umgang mit diesem Paket.
-
Abhängigkeiten: Eine Liste von Produkten, zu denen das ausgewählte Produkt Abhängigkeiten aufweist mit Angabe der Art der Abhängigkeit:
-
required bedeutet, das ausgewählte Produkt benötigt das hier angezeigte Produkt, es besteht aber keine zwingende Installationsreihenfolge.
-
pre-required heißt, das hier angezeigte Produkt muss vor dem Ausgewählten installiert werden.
-
post-required spezifiziert, das hier angezeigte Produkt muss nach dem Ausgewählten installiert werden.
-
-
Konfiguration für den Client: Zur clientspezifischen Anpassung der Installation können für ein Produkt zusätzliche Properties definiert sein. Die Darstellung und Bearbeitung der Tabelle der Properties ist in einem spezifischen Oberflächenelement realisiert:
Property-Tabellen mit Listen-Editierfenstern
Eine Property-Tabelle ist eine zweispaltige Tabelle. In der linken Spalte stehen Property-Namen, denen jeweils in der rechten Spalte ein Property-Wert zugeordnet ist.
Die Zeilen, die nicht dem Serverdefault entsprechen, werden fett angezeigt.
Rechts oben befinden sich zwei Buttons:
-
(rechts): Entferne clientspezifische Werte:
Dieser Button löscht alle Einstellungen beim Client, so dass die Serverdefaults wirken. Werden Serverdefaults geändert wirkt sich dies somit direkt auf den Client aus. -
(links): Setze Clientwerte auf Serverdefaults:
Dieser Button kopiert die Serverdefaults als Clienteinstellungen. Damit bleiben diese Einstellungen beim Client erhalten, auch wenn später die Serverdefaults geändert werden.
Sofern entsprechend konfiguriert, wird ein Hinweis zur Bedeutung eines Wertes sowie der Defaultwert angezeigt, sobald der Mauszeiger über die betreffende Zeile bewegt wird ("Tooltip"):
Beim Anklicken eines Wertes poppt ein Fenster auf, der 'Listen-Editor', und zeigt einen Wert bzw. eine Liste vorkonfigurierter Werten, wobei der derzeit gültige Wert (bzw. die derzeit selektierte Wertekombination) markiert ist:
Durch Anklicken eines (anderen) Wertes kann die Auswahl neu gesetzt (bzw. durch Strg-Click erweitert oder verkleinert) werden.
Sofern die Liste der zulässigen Werte erweiterbar ist (die Werte sind somit änderbar), bietet das Fenster zusätzlich ein Editierfeld an, in dem neue bzw. geänderte Werte eingegeben werden können.
Wenn ein Wert nur modifiziert werden soll, kann er aus der Liste der Vorhandenen mit Doppelklick in das Editierfeld übernommen werden. Sobald ein in der Liste noch nicht vorhandener Wert im Editierfeld steht, aktiviert sich das Plus-Symbol zum Übernehmen des neuen Wertes.
Sofern - wie z.B. beim Property additional drivers der Fall sein sollte - Mehrfach-Werte zulässig sind, erlaubt die Liste eine Mehrfach-Selektion. Wenn die Liste als Mehrfach-Selektion konfiguriert ist, wird ein Wert mit Strg-Klick zur Selektion hinzugefügt bzw. ein Selektierter entfernt. Mit dem Minus-Button kann die Selektion in einem Rutsch komplett geleert werden.
Wenn die Liste bearbeitet wurde, wechselt wie auch sonst im configed der grüne Haken nach Rot. Anklicken des Hakens übernimmt den neuen Wert (d.h. die neue Selektion als Wert). Der blaue Cancel-Knopf beendet die Bearbeitung, indem der ursprüngliche Wert zurückgesetzt wird.
Geheime Property-Werte
Für den Fall, dass Passwörter oder andere "Geheimnisse" als Property-Werte vorkommen, ist folgende Vorkehrung getroffen (als "Hack" seit Version 4.0.7, bis ein spezifischer Datentyp eingerichtet ist):
-
Wenn im Namen des Properties irgendwo 'password' vorkommt
-
oder wenn der Property-Name mit 'secret' ("geheim" oder "Geheimnis") beginnt,
wird der Property-Wert bei der Anzeige durch fünf * ersetzt. Er wird erst - nach Vorwarnung - sichtbar gemacht, wenn er wie zur Bearbeitung angeklickt wird.
Die Bearbeitung findet ggfs. wie im Standardfall statt.
Netboot-Produkte
Die Produkte unter dem Karteireiter Netboot-Produkte werden analog zum Karteireiter Localboot-Produkte angezeigt und konfiguriert.
Die hier angeführten Produkte versuchen, werden sie auf setup gestellt, zu den ausgewählten Clients den Start von Bootimages beim nächsten Reboot festzulegen. Dies dient üblicherweise der OS-Installation.
Hardwareinformationen
Unter diesem Karteireiter erhalten Sie die letzten - entweder durch das Bootimage oder durch das Localboot-Produkt hwaudit erhobenen - Hardwareinformationen zum ausgewählten Client.
Automatisierte Treiberintegration
Um vereinfacht und automatisiert Treiber von speziellen Clients auf den opsi-Depotserver zu uploaden, gibt es seit der Version 4.0.5 die Möglichkeit aus den Hardwareinformationen mögliche Pfade auszuwählen, die vom opsi-configed über den Share übertragen werden. Die zwei angebotenen byAudit-Treiberpfade setzten sich zusammen aus dem Hersteller und dem Produkt bzw. dem Modell, welche jeweils aus dem Computer und der Hauptplatine ausgelesen werden. Betätigt man den rechten Button zum Treiberupload, so erscheint ein neues Fenster um weitere Einstellungen zu tätigen.
Haben Sie den opsi-configed auf einem Linux-System geöffnet, so ist es nicht direkt möglich einen Treiberupload durchzuführen, da die Verbindung über einen Share durchgeführt wird. Dies muss dann manuell getätigt werden. Jedoch sind die Methoden bzw. Verzeichnisstrukturen ein wesentlicher Aspekt der Treiberintegration.
Ohne weiteres funktioniert der Treiberupload von einem Windows-Rechner, wenn die Verbindung zum Share aktiviert ist. Unter anderem müssen im neues Fenster Angaben getätigt werden, für welches Windows-Produkt der Treiber bereit gestellt werden soll, welche Treiber geuploadet werden sollen und mit welcher Methode bzw. in welches Verzeichnis die Treiberintegration erfolgt. Das Zielverzeichnis wird mit Auswählen einer anderen Methode dem entsprechend geändert. Der zuvor ausgewählte byAudit-Treiberpfad findet sich in der per Default ausgewählten Methode 'byAudit' wieder, die den ausgewählten Treiber spezifisch für den Maschinentyp integriert. Folgende Methoden bzw. Verzeichnisse sind möglich:
-
Standard: Treiber welche im Verzeichnis
./drivers/driversliegen, werden anhand der PCI-Kennungen (bzw. USB- oder HD_Audio-Kennung) in der Beschreibungsdatei des Treibers als zur Hardware passend erkannt und in das Windows Setup mit eingebunden. Der Nachteil dieser Pakete ist, das sich hier auch Treiber finden, welche zwar von der Beschreibung zu Ihrer Hardware passen, aber nicht unbedingt mit Ihrer Hardware funktionieren. Hier können Treiber hinterlegt werden, die einen Fallback für alle Clients darstellen. -
Preferred: Zusätzliche bzw. geprüfte Treiber gehören in jeweils eigene Verzeichnisse (Name und Tiefe der Verzeichnisstruktur egal) unterhalb des Verzeichnisses
./drivers/drivers/preferred. Treiber welche im Verzeichnis./drivers/drivers/preferredliegen, werden gegenüber den Treibern in./drivers/driversbevorzugt anhand der PCI-Kennungen (bzw. USB- oder HD_Audio-Kennung) in der Beschreibungsdatei des Treibers als zur Hardware passend erkannt und in das Windows Setup mit eingebunden. Finden sich z.B. zu ein und derselben PCI-ID unterschiedliche Treiber unterpreferred, so kann dies zu Problemen bei der Treiber Zuordnung führen. In diesem Fall ist eine direkte Zuordnung der Treiber zu den Geräten notwendig. -
Excluded: Es kann vorkommen, das Treiberverzeichnisse von Herstellern Treiber für unterschiedliche Betriebssystemversionen (Vista / Win7) oder Konfigurationen (SATA / SATA-Raid) enthalten. Wenn Sie die Vermutung haben, das ein verlinkter Treiber falsch ist, so verschieben Sie diesen Treiber in das Verzeichnis
drivers/excludeund führencreate_driver_links.pyerneut aus. Treiber die indrivers/excludeliegen werden bei der Treiberintegration nicht berücksichtigt. -
Additional: Zusätzliche Treiber, die unabhängig von ihrer Zuordnung bzw. Erkennung über die PCI- oder USB-IDs installiert werden sollen, gehören in jeweils eigene Verzeichnisse (Name und Tiefe der Verzeichnisstruktur egal) unterhalb des Verzeichnisses
./drivers/drivers/additional. Über das Produkt-Property 'additional_drivers' können Sie einen oder mehrere Pfade von Treiberverzeichnissen innerhalb von./drivers/drivers/additionaleinem Client zu ordnen. Im Produkt-Property 'additional_drivers' angegebene Verzeichnisse werden rekursiv durchsucht und alle enthaltenen Treiber eingebunden. Dabei wird auch symbolischen Links gefolgt. Dies können Sie nutzen, um für bestimmte Rechner-Typen ein Verzeichnis zu erstellen (z.B. dell-optiplex-815). -
byAudit: In dem Verzeichnis
./drivers/drivers/additional/byAudit/<Vendor>/<Model>hinterlegte Treiber, werden bei einer Windows-Installation nach einem Verzeichnisnamen durchsucht, der dem bei der Hardwareinventarisierung gefundenen 'Vendor' entspricht. In diesem 'Vendor' Verzeichnis wird nun nach einem Verzeichnisnamen gesucht, das dem bei der Hardwareinventarisierung gefundenen 'Model' entspricht. Wird ein solche Verzeichnis gefunden, so wird diese Verzeichnis genauso behandelt, als wären sie über das Produktproperty 'additional_drivers' manuell zugewiesen.
Einige Hersteller verwenden Modellbezeichnungen, die für diese Methode sehr ungünstig sind, da man einige Sonderzeichen wie / nicht in Datei- oder Verzeichnisnamen verwenden darf. Ein Beispiel dafür wäre als Modelbezeichnung: "5000/6000/7000". Ein Verzeichnis mit dieser Bezeichnung ist wegen den Sonderzeichen nicht gestattet. Seit der dritten Service Release opsi 4.0.3 werden deshalb folgende Sonderzeichen: < > ? " : | \ / * intern durch ein _ ersetzt.
Mit dieser Änderung kann man oben genanntes schlechtes Beispiel als: "5000_6000_7000" anlegen und das Verzeichnis wird automatisch zu gewiesen, obwohl die Information in der Hardwareinventarisierung nicht der Verzeichnisstruktur enstprechen.
Nach einem Treiberupload nach ./drivers/drivers oder ./drivers/drivers/preferred sollte die create_driver_links.py auf dem 'opsi-Depotserver' aufgerufen werden!
|
Software-Inventarisierung
Unter diesem Karteireiter erhalten Sie die letzten mit swaudit ausgelesenen Informationen über installierte Software beim Client.
Logdateien: Logs von Client und Server
Im Kartenreiter Logdateien sind die Logdateien der Clients über den opsi-configed einsehbar.
Der Level, bis zu dem die Logeinträge sichtbar sind, kann mit einem Schieberegler variiert werden, so dass Fehler leichter gefunden werden können. Der Regler ist auch mausrad-bedienbar.
Dabei kann auch in den Logdateien gesucht werden (Fortsetzung der Suche mit F3 oder Strg-L = last search repeated). Die einzelnen Zeilen sind je nach Loglevel farbig hervorgehoben.
Produkt-Defaultproperties
Um die Defaultwerte der Produkte für einzelne oder mehrere opsi-depots zu ändern, gibt es einen Reiter Produkt-Defaultproperties. Dieser wird erst auswählbar, wenn man zur Depotkonfiguration (zweiter Button oben rechts) wechselt.
In der Haupttabelle werden alle Produkte mit der Produkt-Version und der Package-Version aufgelistet.
Wählt man ein Produkt aus, so werden, wie aus der Client-Produktkonfiguration gewohnt (vgl. Localboot-Produkte), rechts oben die allgemeinen Informationen zum Produkt-Paket angezeigt. Darunter befindet sich die Auflistung aller Depots, die das ausgewählte Produkt besitzen.
Die unterhalb befindliche Tabelle mit den Property-Schlüsseln und Werten ist
ebenfalls bekannt aus der Client-Produktkonfiguration.
Man kann ein oder mehrere Depots auswählen, um die Defaultwerte (d.h. die Depotwerte) des Produktes zu ändern. Als Voreinstellung werden alle verfügbaren Depots ausgewählt. Mit den üblichen Tastenkombinationen (Strg-a, Strg-Klick oder Shift-Klick) lassen sich mehrere bzw. alle Clients markieren.
Ist der Property-Wert ausgegraut (siehe opsi-configed: Produkt-Defaultproperties - ``gui_language''), so sind auf den ausgewählten Depots verschiedene Werte für diese Property gesetzt. Rechts neben den Depots befinden sich drei Buttons:
-
(=+): Markiere alle Depots mit identischen Werten
Alle Depots, die die gleichen Default-Werte haben, werden markiert. -
(++): Alle Depots werden markiert.
-
(Weltkugel): Setze die Paket-Default-Werte
Die Original-Paket-Werte des Produkts werden für das/die ausgewählte/n Depot/s gesetzt.
Host-Parameter in der Client- und der Serverkonfiguration
Eine ganze Reihe von Konfigurationsvorgaben können Sie über den Tab 'Host-Parameter' setzen und zwar als Server-Defaults im Modus Serverkonfiguration (vgl. Auswahl des Bedienungsmodus) und clientspezifisch in der Clientkonfiguration.
Konfigurationseinträge (config-Objekte des opsi-Servers) sind grundsätzlich Wertelisten. Als Werkzeug zur Bearbeitung der Werte dient daher der Listeneditor (vgl. Property-Tabellen mit Listen-Editierfenstern )
Je nach Type des jeweiligen Konfigurationsobjekts
-
können die Elemente der Liste entweder Unicode-Textwerte oder boolesche Werte (
true/false) sein; -
kann die Gesamtheit der zulässigen Listenelemente fest oder erweiterbar sein;
-
umfasst der DefaultValues-Eintrag des Objekts im singleValue-Fall genau ein Listenelement, bei multiValue-Objekten eine beliebige Auswahl aus den zulässigen Listenelementen.
Neue Konfigurationseinträge können über das Kontextmenü auf der Server-Hostparameter-Seite erstellt werden. Ebenso können dort bestehende Objete gelöscht werden.
Das Verhältnis von Server- und Client-Hosteinträgen ist verwickelt:
-
Server-Einträge liefern die Default-Werte für die Client-Einträge.
-
Konsequenterweise muss, um einen Client-Eintrag zu erhalten, zuerst ein Server-Konfigurationsobjekt angelegt werden.
-
Und, wenn ein Server-Eintrag (das Config-Objekt) gelöscht wird, verschwinden auch die zugehörigen Client-Einträge (die auf ConfigState-Objekten beruhen).
-
Es kann sowohl bei Abweichung des Client-Wertes vom Server-Default als auch, wenn die beiden derzeit identisch sind, einen eigenen Eintrag des Clients in der Datenbank geben. Sofern es diesen eigenen Eintrag gibt, bleibt er auch erhalten, wenn sich der Server-Default ändert.
-
Zum Umgang mit diesem Thema gibt es daher ab configed Version 4.0.7.6.5 für die Client-Properties ein Kontextmenü mit den beiden Optionen "Spezifischen Client-Wert entfernen" (d.h., der Clientwert ist immer der gerade aktuelle Default-Werte des Servers) und "Setze den jetzigen Default-Wert als (dauerhaften) Wert für den Client.
-
Wenn der Client-Wert sich vom aktuellen Server-Default unterscheidet, so ist dieser fett dargestellt.
-
Es kann Konfigurationsobjekte geben, für die theoretisch Client-Werte erzeugt und bearbeitet werden können, die jedoch keinerlei Bedeutung haben, weil eigentlich nur serverbezogene Informationen gespeichert werden. Diese Properties sind in den aktuellen configed-Versionen in der Regel ausgeblendet.
Zur besseren Übersicht sind die Host-Parameter gegliedert nach Funktionsgruppen aufgeführt. Die Gruppen werden auf der linken Seite in einer baumartigen Struktur aufgeführt. Jeweils die zugehörigen Parameter und ihre Werte erscheinen auf der rechten Seite.
Verwaltung von Benutzerrechten und -rollen
Ab Version 4.0.7.5 bietet der opsi-configed die Userrollen-Funktion an.
| Zur Verwendung des Features muss user roles in der modules-Datei freigeschaltet sein. |
In der Oberfläche zeigt die Existenz der Kategorie user in der Übersicht der Server-Hostparameter, dass diese Funktion verfügbar (aber noch nicht unbedingt aktiv) ist. Im Baum der Eigenschaften steht direkt in user primär der boolesche Eintrag
user.{}.registermit dem Defaultwert false.
Die anderen Einträge, die an dieser Stelle des Property-Baums stehen, sind die Defaultwerte für die auch userspezifisch mögliche Konfiguration der Server-Konsole (vgl. Server-Konsole):
Zur Aktivierung der Userrollen-Funktionalität ist
-
der Wert von user.{}.register auf true zu setzen;
-
eine Modules-Datei einzuspielen, die das Feature userroles temporär oder dauerhaft aktiviert hat.
Bei aktiver Userrollen-Funktionalität wird für den angemeldeten User ein Eintrag im Eigenschaftsbaum erzeugt. Die dabei für die Rechteverwaltung verwendeten Defaulteinstellungen entsprechend den "klassischen" Vorgaben für einen Adminitrator, d.h. zunächst werden dem User keine Einschränkungen auferlegt. Z.B. für einen User admindepot1 werden die Einträge
user.{admindepot1}.privilege.host.all.registered_readonly [false]
user.{admindepot1}.privilege.host.depotaccess.configured [false]
user.{admindepot1}.privilege.host.depotaccess.depots []
user.{admindepot1}.privilege.host.opsiserver.write [true]generiert.
Die vier Einträge bedeuten:
-
admindepot1 hat nicht lediglich readonly-Zugriff auf den Server (ein reiner readonly-Zugriff wäre möglicherweise für einen Mitarbeiter aus dem Helpdesk-Bereich angemessen);
-
Depotrestriktionen existieren nicht bzw. werden nicht berücksichtigt;
-
entsprechend kann die Liste der für den User zugänglichen Depots leer bleiben (aber auch wenn hier eine Auswahl aus den verfügbaren eingetragen ist, hat dies, solange depotaccess.configured false, keine Wirkung);
-
der User darf configserver-Einstellungen aller Art bearbeiten.
Soll künftig admindepot1 nur noch Zugriff auf die Rechner im Depotserver depot1 haben, ist folgendes einzustellen:
-
host.depotaccess.configured ist auf true zu setzen;
-
in die Liste host.depotaccess.depots ist der Wert "depot1" einzutragen.
Nach einem (vollständigen) Datenreload sind für den User admindepot1 keine Clients aus anderen Depots mehr sichtbar (und auch nur noch Depoteinstellungen für depot1 zugänglich).
| admindepot1 kann alle Restriktionen selbst aufheben, solange er über das Privileg host.opsiserver.write verfügt. |
Um die Abriegelung komplett zu machen, ist daher für admindepot1 noch
-
host.opsiserver.write auf false zu stellen.
| Die auf diese Weise gesetzten Privilegien beschränken ausschließlich die Funktionalität des opsi-configed. Bei anderen Zugriffsmethoden auf das JSON-RPC-Interface des opsi-servers werden sie derzeit nicht wirksam. |
Depotkonfiguration
Im Modus Depotkonfiguration (vgl. Auswahl des Bedienungsmodus) öffnet sich der Tab Depots. Nach Auswahl eines Depotservers in der Drop-Down-Liste können Werte bearbeitet werden, die das Depot parametrisieren.
Gruppenaktionen
Mittels der Schaltfläche "Gruppenaktionen" (vgl. Auswahl des Bedienungsmodus) wird ein entsprechendes Fenster für gruppenbezogene Funktionen geöffnet.
Im Moment wird nur eine Funktion angeboten, die für die opsi-localimage-Option interessant ist:
-
die Suche nach einem Betriebssystem, das auf allen PCs der selektierten Gruppe schon installiert war und daher zur Auswahl für die Inbetriebnahme (auf allen PCs der Gruppe) angeboten werden kann.
Produktaktionen
Mittels der Schaltfläche "Produktaktionen" (vgl. Auswahl des Bedienungsmodus) wird ein entsprechendes Fenster für Produkt-/Paket-bezogene Aktionen geöffnet.
Im Moment stehen zwei Funktionen zur Verfügung:
-
Eine .opsi-Datei (ein opsi-Paket) kann ausgewählt werden bzw. der Pfad zu ihr eingegeben werden. Das Paket kann auf den opsi-Server hochgeladen werden; der standardmäßig vorhandene Netzwerk- (Samba-) Share opsi_workbench auf dem opsi-Server ist dabei der Default-Wert für das Zielverzeichnis auf dem Server. Schließlich wird bei Betätigen des Buttons versucht, das Paket mit einem Aufruf analog einem opsi-package-manager-Aufruf auf dem Server als Produkt zu installieren.
-
Die WinPE-Dateien bzw. die Installfiles für ein Windows-Produkt (ab Windows Vista) können in das Server-Produktverzeichnis (Share opsi_depot) hochgeladen werden, so dass die Windows-Produkte nicht mehr serverseitig angefasst werden müssen.
Server-Konsole
| Einige der nachfolgend beschriebenen Configed-Funktionen stehen erst ab der python-opsi-Version 4.0.7.38 zur Verfügung. Dazu zählt vor allem die Befehlsbearbeitung (Befehle definieren) sowie die Ausführung der darüber hinterlegten Befehle im configed. |
Mit der Version 4.0.7.5 ist der configed um einen neuen Hauptmenüeintrag erweitert, die "Server-Konsole". Damit wird die Möglichkeit geboten, vom configed aus auch über eine SSH-Verbindung Aktionen auf dem opsi-server auszulösen. Zum einen kann ein Terminal auf dem opsi-server gestartet werden, zum anderen existieren Menüpunkte für vordefinierte Kommandozeilenbefehle.
Verbindungsdaten und Berechtigungen
Wenn nicht anderes konfiguriert ist, wird versucht, für die SSH-Verbindung den im configed angemeldeten User und den verbundenen Configserver zu verwenden.
Ist dies nicht erwünscht, kann die Verbindung über einen SSH-Schlüssel (ggf. mit Passphrase) beim Start des Configeds gestartet werden. Zu diesem Zweck existieren die folgenden Aufrufparameter für den configed:
-
--ssh-key PATH: z.B. --ssh-key /home/user/.ssh/id_rsa
-
--ssh-passphrase PASSPHRASE: z.B. --ssh-passphrase meinpassword
Die Einstellungen lassen sich unter dem Menüpunkt "Verbindungsdaten" ändern.
Über Server-Hostparameter (User-Abschnitt) kann feingranular gesteuert werden, welche der Menüpunkte sichtbar sind bzw. genutzt werden können. Bei aktivierter Userroles-Funktionalität (vgl. Verwaltung von Benutzerrechten und -rollen) werden die Konfigurationen userspezifisch verwendet. Für einen neu angelegten User werden dabei als Default-Werte zunächst die Werte von der allgemeinen User-Ebene gesetzt.
Folgende Configs existieren:
-
user.{}.ssh.serverconfiguration.active:
Aktiviert das Menü der SSH-Verbindungseinstellungen . (Default: false) -
user.{}.ssh.commandmanagement.active:
Aktiviert die Bearbeitung von Menüeinträgen der SSH-konsolen-Befehle (Default: false) -
user.{}.ssh.menu_serverconsole.active:
Gibt den Hauptmenüeintrag "Server-Konsole" als solchen frei. (Default: true) -
user.{}.ssh.terminal.active:
Schaltet die SSH-Shell frei. (Default: true) -
user.{}.ssh.commands.active:
Schaltet alle SSH-Menüeinträge frei, die hinterlegte Befehle darstellen. (Default: true)
SSH-Terminal
Mithilfe des Terminals können Linux-Systembefehle auf dem verbundenen SSH-Server ausgeführt werden.
Das Eingabe-Echo kann durch Sternchen (*) ersetzt werden (Passwort-Eingabe).
Ein gestarteter Prozess lässt sich mit dem Button "Prozess/Verbindung beenden" oder durch "Strg+C" abbrechen.
Wie von der Kommandozeile gewohnt, kann die "TAB"-Taste Befehle vervollständigen. Achtung: Pfade werden nicht vervollständigt - lediglich Linux-Systembefehle.
Außerdem können Datenquellen aus dem configed-Kontext angegeben werden, die bei der Befehlsausführung durch die konkreten Werte ersetzt werden.
(Mehr zu dieser Funktionalität: Befehle definieren - Punkt: Datenquellen)
Vordefinierte Befehle mit Eingabemasken
Unter der Menügruppe "opsi" stehen einige Befehle unabhängig von den selbst definierbaren Befehlen mit einer eigenen Eingabe-Oberfläche zur Verfügung. Diese vereinfachen den Umgang mit diversen Skripten.
-
Datei-Download …
Eine beliebige Datei kann aus dem Internet mittels "wget"-Befehl heruntergeladen und in ein Zielverzeichnis auf dem Server abgelegt werden. Anwendung findet der Befehl beispielsweise für konkrete opsi-Pakete von download.uib.de. -
Erstellung opsi-Produkt …
Voraussetzung für diesen Befehl ist ein opsi-utils-Paket mit der Version >=4.0.7.7. Über diesen Menüpunkt kann dann, mit Angabe eines Server-Verzeichnis, aus diesem ein opsi-Paket erstellt werden. Außerdem können die in der Control-Datei gefundenen Versionen (Paket- und Produkt-Version) über einen Button angezeigt und überschrieben sowie eine md5-Summe und/oder eine zsync-Datei erstellt werden. Beim Ausführen wird eine .opsi-Datei gebaut. Zwecks Installation auf dem Server bzw. Depot leitet der Button "Das neu erstellte Paket installieren" zum opsi-package-manager weiter. -
Opsi-Rechte setzen …
Dieser Menüpunkt bildet den opsi-Befehl opsi-set-rights ab. Nach der Möglichkeit einen bestimmten (optionalen) Pfad einzugeben in dem das Skript ausgeführt werden soll, wird nach dem root-Passwort gefragt und das Skript im seperaten Fenster ausgeführt. -
Paket-Installation …
Durch diesen Befehl können opsi-Pakete mittels "opsi-package-manager" auf allen Depots oder einem Depot installiert werden. Dabei kann der Server-Pfad zum Paket angegeben werden, in dem sich das opsi-Paket befindet.
Durch Auswahl eines Pakets aus dem Internet wird die Funktionalität des Befehls "Datei download …" aufgegriffen und anschließend das heruntergeladene Paket auf dem Depot installiert. Außerdem sind die Parameter "--update" und "--setup" des opsi-package-manager implementiert. Sollen die zsync und md5-Dateien eines opsi-Paketes heruntergeladen werden, kann der Schalter "zsync- und md5 einschließen" aktiviert werden. Dann wird die url der Pakete entsprechend ergänzt und die zusätzlichen Dateien werden ebenfalls gezogen.
Mehr zum opsi-package-manager finden Sie unter Werkzeug 'opsi-package-manager': opsi-Pakete (de-)installieren -
Paket-Deinstallation …
Aus einer Liste der installierten Pakete kann eines ausgewählt und deinstalliert werden.
Siehe Werkzeug 'opsi-package-manager': opsi-Pakete (de-)installieren -
Verteilung opsi-client-agent …
Möchte man existierende Rechner zu opsi hinzufügen, muss der opsi-client-agent auf dem Zielrechner installiert werden. Wählt man die betreffenden Clients im configed aus und ruft diesen Befehl auf, werden die Client-Namen in das entsprechende Feld übernommen. Wenn der Befehl für mehrere Clients mit einem Aufruf ausgeführt werden soll, müssen die Login-Daten bei den beteiligten Rechnern gleich sein.
Achtung: Das Skript zum Deployen der Client muss im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/ liegen und den Namen opsi-deploy-client-agent haben. Genauere Informationen finden Sie im Handbuch 'opsi-getting-started' im Kapitel 'Erste Schritte'.
| Einige Oberflächen beinhalten eine Auswahlkomponente für Pfade in der Verzeichnisstruktur. Wird der Button "Ermittle Unterverzeichnisse" betätigt werden alle Verzeichnisse bzw. Dateien aufgelistet, die in dem angegebem Pfad enthalten sind. Für weitere Ebenen muss der Button wiederholt betätigt werden. Diese Funktionalität befindet sich u.a. in der "Opsi-Rechte setzen" oder "Paket-Installation"-Oberfläche. |
Befehle definieren
Zusätzlich zu den vordefinierten Befehlen lassen sich eigene Serverkonsolenbefehle erstellen bzw. verändern oder entfernen, die über Menüpunkte aufgerufen werden können. Dabei ist zu beachten, dass unterschiedliche Linux-Systeme unter Umständen nicht die gleichen Kommandozeilenbefehle ausführen können. Deswegen muss der Administrator sicherstellen, dass die Befehle entsprechend dem adressierten Linux-System funktionieren.
Folgende Daten müssen bzw. können (gekennzeichnet durch ein "*") für einen Befehl angegeben werden:
-
Menü-Text:
Beim Erstellen eines Befehls muss darauf geachtet werden, dass der Menütext noch nicht für einen anderen Befehl verwendet wurde. Wenn ein Menütext geändert werden soll, muss der Befehl mit dem Minus-Button gelöscht und ein neuer Befehl erstellt werden. -
Beschreibung*:
Wird eine genauere Beschreibung hinterlegt, taucht diese als Tooltip-Text des Befehls auf. -
übergeordnetes Menü*:
Legt fest, in welchem Menü der neue Befehl als Menüeintrag erscheinen soll. Bleibt das Feld leer, wird der Menüeintrag direkt dem Menü "Server-Konsole" zugeordnet. -
Position*:
Die Position bestimmt die Reihenfolge (kleine Zahlen zuerst) der Menüpunkte insgesamt und damit innerhalb des jeweiligen Menüs. Ist eine alphabetische Reihenfolge erwünscht, müssen alle Positionen identisch gesetzt sein (z.B. alle 0). Bleibt das Feld leer, wird standardmäßig die Position 0 vergeben. -
"sudo"-Rechte*:
Wenn einer der Befehle in der Befehlsliste administrative Rechte benötigt, muss das Häkchen bei "Benötigt root-Rechte" gesetzt sein, dann werden die Befehle in der Liste automatisch um das Schlüsselwort "sudo" ergänzt. -
Befehlsliste:
Bei der Befehlsliste müssen die Linux-Befehle zeilenweise eingetragen werden, damit sie sequentiell ausgeführt werden können. Achtung: Der Befehl kann mittels Button direkt auf dem verbundenen SSH-Server getestet / ausgeführt werden, ohne ihn als Menüpunkt zu erstellen. -
Datenquellen* (für die Befehlsliste):
Zusätzlich können Methoden als Datenquelle hinterlegt werden, d.h. vor Ausführung des Befehls werden Parameter mit dem Ergebnis einer Methode überschrieben. folgende Methoden sind möglich:-
Interaktive Eingabe:
Es ist möglich, für die Befehle Parameter nicht fest vorzugeben, sondern für eine interaktive Eingabe zu kennzeichnen. Dies geschieht in der Form "<<<Dieser Text wird dem Benutzer angezeigt und durch die Benutzereingabe ersetzt>>>" , wobei empfohlen wird, eine Beispieleingabe für den Parameter zum Benutzertext hinzuzuschreiben. -
Ausgewählte Client-Namen / Ausgewählte Client-IP-Adressen
-
Ausgewählte Depot-Namen / Ausgewählte Depot-IP-Adressen
-
Configserver-Name
-
Verbundener SSH-Servername
Hinweis: Außer für die "Interaktive Eingabe" kann die Rückgabe der Methoden formatiert werden, beispielsweise in eine kommaseparierte Liste. In der Oberfläche kann die Datenquelle sowohl getestet, als auch an die im Feld der Befehlsliste markierten Stelle eingefügt werden.
-
|
— Unter Linux lassen sich Befehle mithilfe von zwei kaufmännischen Unds ("&&") kombinieren. Dabei muss jedoch darauf geachtet werden, dass zum zweiten Befehl, falls benötigt ein sudo ergänzt wird, da dies nicht automatisch geschieht. Beispiel: Benötigt root-Rechte:"aktiviert" , Befehlsliste: "apt-get update --yes && sudo apt-get upgrade --yes". — Während der Ausführung lassen sich keine Benutzereingaben tätigen. Es ist notwendig, alle Eingaben über die Befehls\-parameter zu steuern (Beispiel: "--yes" -Option bei "apt-get upgrade") |
Validierungsstatus der opsi-Module
Im Menüpunkt Hilfe kann unter Validierungsstatus der opsi-Module der aktuelle Lizenzierungsstand der opsi-Module eingesehen werden.
In der Tabelle wird zu jedem Modul angezeigt, ob das Modul erworben wurde bzw. verfügbar ist.
Die grüne Spalte hebt den aktuellen Zeitraum hervor und zeigt an, für wie viele Clients das Modul aktuell lizenziert ist.
Jede Spalte zeigt den Stand ab dem jeweiligen Datum an.
Die Spalten mit Datum in der Zukunft stellen zukünftige Änderungen dar, z.B. wenn eine Lizenz ausläuft oder eine neue Lizenz gültig wird.
Durch Auswählen der Checkbox 'Vollständiger zeitlicher Verlauf' kann man zusätzlich die Zustände in der Vergangenheit einsehen.
Im weiteren Teil des Fensters ist eine Legende zu den Warnungen und Warngrenzen zu finden.
Es können drei verschiedene Warngrenzen konfiguriert werden, ab denen der User eine Warnung erhält.
Diese Warnungen sollen darauf aufmerksam machen, wenn die Lizenzgrenze (bald) erreicht ist oder wenn eine Lizenz (bald) ausläuft.
Die Warngrenze 'Clients Anzahl' legt die absolute Differenz der Clientzahl zu der lizenzierten Anzahl fest, ab der gewarnt werden soll.
Die Warngrenze 'Clients prozentual' legt die prozentuale Menge der Clientzahl zu der lizenzierten Anzahl fest, ab der gewarnt werden soll.
Die Warngrenze 'Tage bis Lizenzende' legt die Anzahl der verbleibenden Tage bis Lizenzende fest, ab denen gewarnt werden soll.
Die Warngrenzen können in der Server-Konfiguration mittels der Configs licensing.client_limit_warning_absolute, licensing.client_limit_warning_percent und licensing.client_limit_warning_days bearbeitet werden.
Wenn eine Warngrenze für ein Modul überschritten wird, wird das entsprechende Feld in der Tabelle in gelb markiert.
Wenn für ein Modul nicht mehr genug Lizenzen existieren oder die Lizenz abgelaufen ist, wird das entsprechende Feld in rot markiert.
Dann muss eine neue Lizenz erworben werden.
Beim Starten des opsi-configed wird auf existierende Warnzustände hingewiesen.
Im unteren Teil des Fensters befinden sich Informationen zu den Clients und den Kundendaten, für die die Lizenzen ausgestellt wurden.
Der Checksum-Wert ist zum Abgleich, ob die Daten in der Umgebung mit den Daten bei uib übereinstimmen.