Inhaltsverzeichnis
Abbildungsverzeichnis
opsi-setup --edit-config-defaults
/home/partimg
gemountet.Tabellenverzeichnis
Das Copyright an diesem Handbuch liegt bei der uib gmbh in Mainz.
Dieses Handbuch ist veröffentlicht unter der creative commons Lizenz
Namensnennung - Weitergabe unter gleichen Bedingungen (by-sa).
Eine Beschreibung der Lizenz finden Sie hier:
https://creativecommons.org/licenses/by-sa/3.0/de/
Der rechtsverbindliche Text der Lizenz ist hier:
https://creativecommons.org/licenses/by-sa/3.0/de/legalcode
Die Software von opsi ist in weiten Teilen Open Source.
Nicht Open Source sind die Teile des Quellcodes, welche neue Erweiterungen enthalten die noch unter Kofinanzierung stehen, also noch nicht bezahlt sind.
siehe auch: opsi-Erweiterungen als Kofinanzierungsprojekte
Der restliche Quellcode ist veröffentlicht unter der AGPLv3:
Der rechtsverbindliche Text der AGPLv3 Lizenz ist hier:
http://www.gnu.org/licenses/agpl-3.0-standalone.html
Deutsche Infos zur AGPL: http://www.gnu.org/licenses/agpl-3.0.de.html
Für Lizenzen zur Nutzung von opsi im Zusammenhang mit Closed Source Software kontaktieren Sie bitte die uib gmbh.
Die Namen opsi, opsi.org, open pc server integration und das opsi-logo sind eingetragene Marken der uib gmbh.
Diese Handbuch richtet sich an alle, die sich näher für die automatische Softwareverteilung opsi interessieren. Der Schwerpunkt der Dokumentation ist die Erläuterung der technischen Hintergründe, um so zu einem Verständnis der Abläufe beizutragen.
Damit soll dieses Handbuch nicht nur den praktisch mit opsi arbeitenden Systemadministrator unterstützen sondern auch im Vorfeld den Interessenten einen konkreten Überblick über opsi geben.
In <spitzen Klammern> werden Namen dargestellt, die im realen Einsatz durch ihre Bedeutung ersetzt werden müssen.
Beispiel: Der Fileshare, auf dem die opsi Softwarepakete liegen, wird <opsi-depot-share> genannt und liegt auf einem realen Server z.B. auf /var/lib/opsi/depot
.
Das Softwarepaket: <opsi-depot-share>/ooffice liegt dann tatsächlich unter /var/lib/opsi/depot/ooffice
.
Beispiele aus Programmcode oder Konfigurationsdateien stehen in Courier-Schrift und sind farbig hinterlegt.
depoturl=smb://smbhost/sharename/path
Werkzeuge zur automatischen Softwareverteilung und Betriebssysteminstallation sind bei größeren PC-Netz-Installationen ein wichtiges Werkzeug zur Standardisierung, Wartbarkeit und Kosteneinsparung. Während die Verwendung solcher Werkzeuge für gewöhnlich mit erheblichen Lizenzkosten einher geht, bietet opsi als Opensource-Werkzeug deutliche Kostenvorteile. Hier fallen nur die Kosten an, die von Ihnen durch tatsächlich angeforderte Dienstleistungen, wie Beratung, Schulung und Wartung, entstehen bzw. soweit kostenpflichtige Module benutzen wollen geringe Kofinanzierungsbeiträge.
Auch wenn Software und Handbücher kostenlos sind, ist es die Einführung eines Softwareverteilungswerkzeuges nie. Um die Vorteile ohne Rückschläge und langwierige Lernkurven nutzen zu können, ist die Schulung und Beratung der Systemadministratoren durch einen erfahrenen Partner dringend geboten. Hier bietet Ihnen uib seine Dienstleistungen rund um opsi an.
Das von uib entwickelte System basiert auf Linux-Servern, über die das Betriebssystem und Software-Pakete auf den PC-Clients installiert und gewartet werden (PC-Server-Integration). Es basiert weitestgehend auf frei verfügbaren Werkzeugen (GNU-tools, SAMBA etc.). Dieses opsi (Open PC-Server-Integration) getaufte System ist durch seine Modularität und Konfigurierbarkeit in großen Teilen eine interessante Lösung für die Probleme der Administration eines großen PC-Parks.
opsi ist die Fortschreibung eines Konzepts, das seit Mitte der 90er Jahre bei einer Landesverwaltung auf über 2000 Clients in verschiedenen Lokationen kontinuierlich im Einsatz ist und stetig weiterentwickelt wurde. Als Produkt opsi ist es nun auch einem breiten Kreis von Interessenten zugänglich.
Eine Übersicht registrierter opsi-Installationen finden Sie auf der link:https://www.opsi.org/opsi-map/
Die wesentlichen Features von opsi sind:
Die Konfiguration von opsi benötigt eine Datenhaltung. Die externen Komponenten von opsi kommunizieren mit dem opsi-server über einen Webservice. Der Prozess opsiconfd, welcher den Webservice bereitstellt, übergibt die Daten dem Backendmanager, der die Daten in das konfigurierte Backend schreibt.
Dabei unterstützt opsi unterschiedliche Backends:
Mehr zur Datenhaltung finden Sie im Abschnitt 5.6, „Datenhaltung von opsi (Backends)“.
Die Konfiguration der Backends erfolgt in den Konfigurationsdateien in den Verzeichnissen
/etc/opsi/backendManager
sowie /etc/opsi/backends
.
In den Konfigurationsdateien im Verzeichnis /etc/opsi/backends
werden die Backends definiert.
Welche Backends für welche Zwecke verwendet werden, steht in der Datei /etc/opsi/backendManager/dispatch.conf
.
Wer auf welche Methoden zugreifen darf, ist in der Datei /etc/opsi/backendManager/acl.conf
konfiguriert.
Unterhalb von /etc/opsi/backendManager/extend.d
können weitere opsi-Methoden definiert sein, welche die Basis opsi-Methoden verwenden.
So ist z.B. das Mapping der vorgangsbasierten Methoden (Legacy) auf die objekt-basierten Methoden in der Datei /etc/opsi/backendManager/extend.d/20_legacy.conf
definiert.
Genaue Beschreibungen dieser Konfigurationsdateien finden Sie im Abschnitt 5.7.1, „Allgemeine Konfigurationsdateien in /etc“.
Ab Version 4.0.7.5.22 wird der opsi-configed in einer Fassung ausgeliefert, die mit Java 1.8 kompiliert ist und daher zum Ablauf eine eine Java-Laufzeitumgebung mindestens der Version 1.8 benötigt.
opsi-configed arbeitet mit den Daten eines auf dem Server laufenden opsiconfd mindestens der Version 4.0.6.
Das Programm steht auf download.uib.de in der jeweils aktuellen Version als opsi-Paket zur lokalen Installation zur Verfügung.
Auf Nicht-opsi-Systemen kann der opsi-configed auch durch Kopieren der zum Paket gehörenden Dateien installiert werden.
Zur Vereinfachung dieses Installationsvorgangs kann von http://download.uib.de/opsi4.1/misc/helper/ das Setupprogramm opsi-configed-setup.exe
für Windows-Clients oder die Datei opsi-configed-linux-setup.tar.gz
für Linux-Clients bezogen werden.
Sofern es sich um einen Rechner mit graphischer Oberfläche handelt, ist der opsi-configed auch durch einen Menüeintrag startbar.
Auf Rechnern ohne grafische Oberfläche können lediglich Starts mit den folgenden Optionen erfolgen:
Auf jedem System kann, wenn die benötigten jar-Archive verfügbar sind, 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]) --gzip [y/n] Activate gzip transmission of data from opsi server yes/no --sslversion PREFERRED_SSL_VERSION Try to use this SSL/ TLS version --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, <= 5 --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)
Läuft der opsiconfd auf einem anderem als dem Standardport 4447, so ist dieser beim Start des opsi-configed dem Hostnamen mitzugeben (host:port
).
Der opsi-configed loggt defaultmäßig im Level 3 "Info". Das Loglevel kann auf Level 4 "Check" und Level 5 "Debug" hochgesetzt werden. Zur Änderung des Loglevels gibt es auf die Kommandozeile die Option --loglevel [LEVEL] . Die Verwendung von Level 5 ist nur anzeigt, wenn bereits der configed-Start zu Problemen führt, da 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.
Im Level 4 werden insbesondere die Service-Calls geloggt. Der Debug-Level 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.0.7.6.12 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.
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.
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.
Die gzip-Komprimierung im HTTP-Protokoll verringert die zu übertragende Datenmenge auf Kosten der verlängerten Verarbeitungszeit, da die Daten komprimiert und dekomprimiert werden müssen. Es hat sich gezeigt, dass im lokalen Netz die Reaktionszeiten tendenziell kürzer ohne Komprimierung sind, da die Effekte der verlängerten Verarbeitungszeit überwiegen. Bei Übertragung übers WAN ist es tendenziell umgekehrt. Da im LAN die Kompression sich im Normalfall zeitlich praktisch nicht bemerkbar macht und bei WAN-Verbindungen meist vorteilhaft ist, ist die Gzip-Option per Default eingeschaltet.
Mittels des Features der Client-Erreichbarkeit lässt sich prüfen, welche Clients verbunden sind. Es lässt sich außer über die Anmeldemaske auch per Aufrufparameter aktivieren oder deaktivieren. In der Anmeldemaske ist ein Test-Intervall von 0 Minuten (= ausgeschaltet) als Default eingetragen. Zur Vermeidung einer zu hohen Zahl von Netzanfragen sollte das Test-Intervall nicht zu kurz eingestellt werden.
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.
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).
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:
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.
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. Abschnitt 4.7, „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:
Beim Suchverfahren (erweitert in Version 4.0.7) kann man sich entscheiden zwischen den Varianten
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:
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 tabellarische Auflistung der Clients hat per Default die Spalten Client-Name, Beschreibung, An, IP-Adresse und Zuletzt gesehen.
In der Defaultkonfiguration deaktiviert sind die Spalten
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
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 Abschnitt 4.7, „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.
Clients können komfortabel gruppenweise verwaltet werden, indem die Baumansicht-Komponente auf der linken Seite des opsi-configed-Fensters genutzt wird.
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.
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äß Abschnitt 4.6.2, „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:
Eine Gruppe kann
Das Kontextmenü einer Gruppe dient dazu
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.
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.
clientconfig.dhcpd.filename
zu linux/pxelinux.cfg/elilo.efi
geändert. (Weiteres im Abschnitt 9.6, „opsi mit UEFI / GPT“)
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 Abschnitt 9.11.5, „Empfohlene Konfiguration bei Verwendung der 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.
Bei der WakeOnLan-Funktion kann ab opsi-configed Version 4.0.7 gewählt werden
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.
Ü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, 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.
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.
Über diesen Menüpunkt wird den selektierten Clients ein Aufruf an den opsi-client-agent gesendet, dass auf den Clients zu installierende Software jetzt installiert werden soll. Wenn ein Client nicht erreichbar ist, so meldet der opsi-configed dies mit einem Fehlerhinweis.
Wenn ein Produkt eine Rebootanforderung enthält, so wird der Client ohne Vorwarnung rebootet.
Technisch gesehen wird dem opsi-client-agent die Meldung gesendet, er soll das Event on_demand auslösen. Das genaue Verhalten ist in der Konfiguration diese Events festgelegt (in der opsiclientd.conf).
Ü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:
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.
Sie können den ausgewählten Clients das Signal senden, herunterzufahren bzw. zu rebooten.
Der Client fährt ggf. ohne Rückfrage herunter.
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. Abschnitt 4.17, „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.
Abbildung 4.25. opsi-configed: Bearbeitung der Remote-Control-Aufrufe bei den Server-Konfigurationseinträgen
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"}'
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:
Wechseln Sie auf den Karteireiter Produktkonfiguration, so erhalten Sie die Liste der zur Softwareverteilung bereitstehenden Produkte und des Installations- und Aktionsstatus zu den ausgewählten Clients.
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:
Durch das Anwählen eines Produkts erhalten Sie auf der rechten Seite des Fensters weitere Informationen zu diesem Produkt. Im Einzelnen:
Abhängigkeiten: Eine Liste von Produkten, zu denen das ausgewählte Produkt Abhängigkeiten aufweist mit Angabe der Art der Abhängigkeit:
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:
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.
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):
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.
Die Produkte unter dem Karteireiter Netboot-Produkte werden analog zum Karteireiter Produktkonfiguration 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.
Unter diesem Karteireiter erhalten Sie die letzten - entweder durch das Bootimage oder durch das Localboot-Produkt hwaudit erhobenen - Hardwareinformationen zum ausgewählten Client.
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:
./drivers/drivers
liegen, 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.
./drivers/drivers/preferred
. Treiber welche im Verzeichnis ./drivers/drivers/preferred
liegen, werden gegenüber den Treibern in ./drivers/drivers
bevorzugt 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 unter preferred
, 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.
drivers/exclude
und führen create_driver_links.py
erneut aus. Treiber die in drivers/exclude
liegen werden bei der Treiberintegration nicht berücksichtigt.
./drivers/drivers/additional
. Über das Produkt-Property additional_drivers können Sie einen oder mehrere Pfade von Treiberverzeichnissen innerhalb von ./drivers/drivers/additional
einem 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).
./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!
Unter diesem Karteireiter erhalten Sie die letzten mit swaudit ausgelesenen Informationen über installierte Software beim Client.
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.
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. Abschnitt 4.9, „Produktkonfiguration“), 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 Abbildung 4.37, „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:
Eine ganze Reihe von Konfigurationsvorgaben können Sie über den Tab Host-Parameter setzen und zwar als Server-Defaults im Modus Serverkonfiguration (vgl. Abschnitt 4.4, „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. Abschnitt 4.10, „Property-Tabellen mit Listen-Editierfenstern“ )
Je nach Type des jeweiligen Konfigurationsobjekts
true
/false
) sein;
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:
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.
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.{}.register
mit 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. Abschnitt 4.21, „Server-Konsole“):
Zur Aktivierung der Userrollen-Funktionalität ist
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:
Soll künftig admindepot1 nur noch Zugriff auf die Rechner im Depotserver depot1 haben, ist folgendes einzustellen:
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
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.
Im Modus Depotkonfiguration (vgl. Abschnitt 4.4, „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.
Mittels der Schaltfläche "Gruppenaktionen" (vgl. Abschnitt 4.4, „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:
Mittels der Schaltfläche "Produktaktionen" (vgl. Abschnitt 4.4, „Auswahl des Bedienungsmodus“) wird ein entsprechendes Fenster für Produkt-/Paket-bezogene Aktionen geöffnet.
Im Moment stehen zwei Funktionen zur Verfügung:
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 (Abschnitt 4.21.4, „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.
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:
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. Abschnitt 4.17.1, „Verwaltung von User-Rechten 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:
Mit Hilfe 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: Abschnitt 4.21.4, „Befehle definieren“ - Punkt: Datenquellen)
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.
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.
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:
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:
— Unter Linux lassen sich Befehle mit Hilfe 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")
Die Funktionalitäten eines opsi-servers lassen sich auf vielen Business gängigen Linuxdistributionen installieren.
Grob lassen sich zwei wichtige Funktionalitäten unterscheiden, die auf einem Server vereint sein können:
Die aus diesen Diensten entstehenden Hardwareanforderungen sind in der Regel gering, so das ein Betrieb eines opsi-servers in einer Virtualisierungsumgebung kein Problem darstellt.
Die Installation und Inbetriebnahme eines opsi-servers ist in dem gesonderten Handbuch: opsi-getting-started ausführlich erläutert.
Um den Client-PCs Zugriff auf die Softwarepakete zu ermöglichen, stellt der opsi-server Shares bereit, die von den Clients als Netzlaufwerke gemountet werden können. Für die Windows-Clients wird dazu die Software Samba eingesetzt. Die Korrekte Sambakonfiguration können Sie erstellen bzw. reparieren durch den Aufruf von:
opsi-setup --auto-configure-samba
Nach einer Änderung der Samba-Konfigurationsdateien ist ein Neustart der Samba-Software notwendig (systemctl restart smbd.service
).
Der opsiconfd ist der zentrale Konfigurations-Daemon von opsi.
Alle Client-Komponenten (opsi-client-agent, opsi-configed, opsi-linux-bootimage, …) verbinden sich mit diesem Service um auf die Konfigurationen in den Backends zuzugreifen.
Der opsiconfd wird über die Datei /etc/opsi/opsiconfd.conf
konfiguriert.
Die einzelnen Konfigurations-Optionen sind in dieser Datei dokumentiert.
An dieser Stelle finden sich weitere Ergänzungen.
[global] admin networks
:[global] max log size
:Ergänzend zu dieser Einstellmöglichkeit ist es möglich durch das Werkzeug
logrotate die Logdateien auf einem Server automatisch zu komprimieren und
rotieren zu lassen.
Bitte entnehmen Sie dem zugehörigen Handbuch die Konfigurationsmöglichkeiten.
Ist die maximale Größe der Logdateien bekannt, lässt sich
berechnen wieviel Speicherplatz die anfallenden Logs benötigen werden.
Es gibt fünf verschiedene, Client-bezogene Log-Arten die vom opsiconfd
geschrieben werden: bootimage, clientconnect, instlog, opsiconfd und
userlogin.
Es gibt außerdem einige Client-unabhängige Logs: opsiconfd.log, opsipxeconfd.log,
opsi-backup.log, opsi-package-updater.log und package.log.
Wenn wir von einer mit opsiconfd und logrotate realisierten Konfiguration
ausgehen, bei der alle Logdateien auf 5MB limitiert sind, abgesehen von
package.log, welche 10MB groß werden darf, dann kommen wir auf folgende
Berechnung:
(Anzahl der clients * 5 * 5MB) + 5MB + 5MB + 5MB + 5MB + 10MB
Bei 100 Clients sollten wir bis zu 2530MB für Logs von opsi reservieren. Weil Logrotate überlicherweise zu einer bestimmten Uhrzeit aktiv wird, empfehlen wir diese Zahl aufzurunden.
/var/lib/opsi
.Setzen und Ändern Sie das Passwort mit opsi-admin -d task setPcpatchPassword
.
Bereich: Depotshare mit Softwarepaketen (opsi_depot)
Auf dem depot-Share liegen die für die Installation durch das Programm opsi Winst vorbereiteten Softwarepakete.
In der Voreinstellung liegt dieses Verzeichniss auf dem opsi-server unter /var/lib/opsi/depot
.
Unterhalb von diesem Verzeichnis findet sich für jedes Softwarepaket ein Verzeichnis mit dem Namen des Softwarepakets.
Wiederum unterhalb dieses Verzeichnisses liegen dann die Installationsskripte und -dateien.
Das Verzeichnis wird mit dem Freigabe-Namen opsi_depot per Samba read-only exportiert.
In alten Versionen von opsi war das entsprechende Verzeichnis /opt/pcbin
und der Share hieß opt_pcbin.
Bereich: Arbeitsverzeichnis zum Pakethandling (opsi_workbench)
Unter /var/lib/opsi/workbench
ist der Bereich um Pakete zu erstellen und in dem Pakete vor der Installation mit opsi-package-manager abgelegt werden sollen.
Dieses Verzeichnis ist als share opsi_workbench freigegeben.
Seit opsi 4.1 kann der Pfad Depot-spezifisch über das Attribut workbenchLocalUrl
konfiguriert werden.
Bereich: Konfigurationsdateien File-Backend (opsi_config)
Unter /var/lib/opsi/config
liegen die Konfigurationsdateien des file Backends.
Dieses Verzeichnis ist als share opsi_config freigegeben.
Wenn Sie über diesen Share auf den Dateien arbeiten, verwenden Sie keine Editoren die das Dateiformat (Unix/DOS) verändern und entfernen Sie Sicherungsdateien wie z.B. *.bak.
opsi verwendet zur Authentifizierung der User diverse PAM
-Module. Bisher wurden für verschiedene Distributionen verschiedene PAM-Module verwendet. In der folgenden Auflistung werden die eingesetzten PAM Module aufgelistet:
Standard: common-auth
openSUSE / SLES: sshd
CentOS und RedHat: system-auth
RedHat 6: password-auth
Wie man aus der Liste erkennen kann, wurden diverse PAM
-Konfigurationen verwendet, diese können sich aber je nach lokaler PAM
Konfiguration wieder ändern. Da für diese Anpassungen immer ein Eingriff in den Code nötig war gibt es nun die Möglichkeit unter: /etc/pam.d/
die Datei opsi-auth
an zu legen und für opsi eine eigene PAM
-Konfiguration zu hinterlegen. Wenn es diese Datei gibt, benutzt opsi automatisch diese Konfiguration.
Folgendes einfaches Beispiel soll das Verhalten verdeutlichen: Wenn Sie ein Debian/Ubuntu System betreiben und bei der Anmeldung am opsi-configed eine PAM
-Fehlermeldung bekommen, obwohl mit den selben Benutzerdaten eine SSH Verbindung zum Server geöffnet werden kann, kann man die Datei /etc/pam.d/opsi-auth
mit folgendem Inhalt erstellen:
@include sshd
Nach einem Neustart von opsiconfd
benutzt opsi automatisch das sshd
-PAM
-Modul zur authentifizierung.
Bitte beachten Sie, dass die Anwendung der ACL auf case-sensitive arbeitende Schnittstellen zurückgreift, wohingegen die Authentifizierung über PAM case-insensitiv geschehen kann. Dadurch kann der Fall eintreten, dass trotz erfolgreicher Authentifizierung keine Arbeit mit dem Service möglich ist, da die ACL dies verhindern.
Mit dem Erreichen des stable-Status von Samba 4 wurde die Entwicklungs- und Maintenancearbeiten für den Samba 3-Zweig eingestellt. Als Folge daraus werden fast alle gängigen Linux-Distributionen (Client- und Server-Varianten) mit Samba 4 statt Samba 3 ausgestattet. Daraus ergeben sich einige Veränderungen, die in diesem Kapitel dokumentiert werden sollen.
Samba-Freigaben sind zentraler Bestandteil für die Funktion von opsi. Durch das "generelle" Update auf Samba 4 gibt es einige Dinge zu beachten, die in folgenden Kapiteln kurz erläutert werden sollen.
Zunächst muss unterschieden werden, in welchem Betriebsmodus Samba ausgeführt wird. Eine besondere Eigenschaft von Samba 4 ist die Möglichkeit einen vollwertigen Active Directory-Kompatiblen Domain Controller zu betreiben. In diesem Betriebsmodus (der aus Vereinfachungsgründen in den folgenden Kapiteln als PDC-Modus bezeichnt wird) gibt es Restriktionen, die aus Kompatibilitätsgründen vom Active Directory übernommen werden mussten. In der Regel sind die neuen Distributionen mit Samba 4 ausgestattet, allerdings nur mit dem normalen Freigaben-Betriebsmodus. Eine vollwertige Active Directory Domain zu betreiben, ist mit den Standardpaketen von den Distributionen in der Regel nicht möglich. Eine Ausnahme stellt hier der Univention Corporate Server dar, bei dem auch in den Standardpaketen der PDC-Modus integriert ist.
Die Restriktion, die in diesem Kapitel beschrieben wird, betrifft nur den PDC-Modus von Samba 4.
Die klassische Installationsvariante mit dem Benutzer: pcpatch
mit der primären Gruppe: pcpatch
kann für Installationen mit Samba 4 nicht eingehalten werden. Da Samba 4 den grundlegenden Restriktionen von Active-Directory unterliegt, sind Gruppen mit der gleichen Bezeichnung wie User (wie in Unix/Linux üblich) nicht mehr erlaubt. Aus diesem Grund wurde für Samba 4 Installationen eine neue Konfigurationsdatei eingeführt: /etc/opsi/opsi.conf
, über die gesteuert wird, wie die Gruppe für den Samba-Zugriff auf die Freigaben bestimmt wird. Im Fall von Samba 4 Installationen wird nun über diese Datei der Gruppenname pcpatch
umbenannt und heißt von nun an: opsifileadmins
. Das bedeutet, dass die User, die Zugriffsrechte für die Freigaben von opsi erhalten müssen (opsi-Paketierer) unter Samba 4 nicht Mitglied der Gruppe pcpatch
werden können, sondern Mitglied der Gruppe opsifileadmins
sein müssen.
Weiterhin muss in diesem Fall der User pcpatch
nun als vollwertiger Domänenbenutzer angelegt werden und nicht mehr als Systemuser, da er ansonsten auf die Domänenfreigaben nicht zugreifen kann.
Diese Schritte werden bei einer Installation von opsi auf einem Univention Corporate Server automatisch ausgeführt, wenn bei der Installation erkannt wird, dass das Samba 4 im PDC-Modus läuft.
Da es außer den UCS-Installationen noch keine Standard-Active Directory Konfiguration existiert, müssen diese Schritte bei einem manuell aufgesetzten Samba 4 Active Directory Domaincontoller manuell konfiguriert werden. Wenn das opsi System bei einer späteren Aktualisierung merkt, dass die User schon exisitieren, werden Sie bei der Aktualisierung nicht mehr angelegt.
Für Rückfragen kontaktieren Sie bitte den Support von opsi. Falls Sie keinen Supportvertrag haben, wenden Sie sich bitte an info@uib.de.
Die Änderungen, die in diesem Kapitel beschrieben werden betreffen alle Betriebsmodis von Samba 4.
In Samba 3 war es allgemein erlaubt, jede Datei oder Verzeichnis auf den Clients auszuführen. Dieses Verhalten wurde in Samba 4 komplett verändert. Nun müssen alle Dateien, die über den Share ausführbar sein sollen, auch auf der Unix-Seite das Executable-Bit gesetzt haben.
Dies stellt ein allgemeines Problem für den Betrieb von opsi dar. Es ist nicht möglich dieses Verhalten über die Rechteverwaltung von opsi zu umgehen, da dies eine komplette Überarbeitung des Rechtesystems von opsi erfordern würde. Dies ist in opsi 4 nicht möglich.
Um das Problem mit opsi 4.0 dennoch zu umgehen, gibt es zwei Möglichkeiten.
Variante 1 (Empfohlen): Man kann folgende Option in der smb.conf setzen:
acl allow execute always = true
Durch diese Option wird für die entsprechenden Freigaben das Verhalten von Samba 3 wiederhergestellt.
Diese Option kann sowohl für einzelne shares als auch global gesetzt werden. Wir empfehlen diese Einstellungen nicht global aber für alle opsi shares vorzunehmen (soweit dies noch nicht automatisch passiert ist).
Diese Variante funktioniert evtl. bei Univention Corporate Server nicht, da hier eine sehr stark angepasste Samba 4 Variante eingesetzt wird. In diesem Fall greifen Sie auf die Variante 2 zurück.
Variante 2: auf den betroffenen Freigaben kann über die Freigabenkonfiguration über die folgende Option für jedes Mitglied der pcpatch-Gruppe (Freigaben-User) dieses Verhalten ausgehebelt werden:
admin users = @pcpatch
Diesen Fix setzt opsi schon seit längerem auch bei UCS >= 3 mit Samba 4 ein. Bei diesem Fix wird der Samba-Prozess der User mit erhöhten Rechten ausgeführt.
opsi setzt automatisch bei Samba 4 Distributionen über opsi-setup --auto-configure-samba
diese Option für den opsi_depot Share. Da dieser nur readonly gemounted wird, ist das Sicherheitsrisiko relativ gering.
Für alle anderen Freigaben, die auch Read-Write gemounted werden können, bleibt zu bedenken, dass durch diesen Fix der Samba-Prozess mit erhöhten Rechten ausgeführt wird. Dies kann zu einer potentiellen Gefahr werden. Zur Zeit sind allerdings keine Exploits bekannt, die diesen Umstand als Schwachstelle ausnutzen würden, dennoch ist das natürlich keine Garantie, dass ein solcher Exploit nicht doch existiert.
Der Linux smb Daemon hat einen Bug. Dieser steht in Kombination der opsi_depot Share-Definition in der smb.conf. Die oplock Parameter müssen bei bestehenden Installationen entfernt werden. Neue opsi-Installationen und dementsprechend neue Shares werden ohne oplocks angelegt.
Diese Restriktion betrifft alle Betriebsmodis von Samba 4.
Im Rahmen der Verwendung von Samba 4 kann es notwendig sein, zum mounten des depotshares explizit anzugeben mit welche Domain / User Kombination dies erfolgen soll. Dazu gibt es den neuen config: clientconfig.depot.user
. Gibt es diesen config nicht, so wird der user pcpatch
genommen.
Der Wert des config hat den Syntax: <domain name>\<user name>
z.B. ein config: clientconfig.depot.user = opsiserver\pcpatch
gibt an, dass bei dem Mount des depotshares zur Authentifizierung als domain opsiserver
und als user pcpatch
angegeben werden soll.
Die Erstellung eines solchen config kann über den opsi-configed erfolgen:
Serverkonfiguration / clientconfig / Rechte Maustaste: Standard Konfigurationseintrag hinzufügen.
Die Erstellung eines solchen config kann auch auf der Kommandozeile erfolgen (wobei pcpatch durch den gewünschten string z.B. opsiserver\pcpatch ersetzt werden muss):
opsi-admin -d method config_createUnicode clientconfig.depot.user "clientconfig.depot.user" pcpatch
Dieser Systemweite config kann (z.B. im configed im Reiter Hostparameter) clientspezifisch angepasst werden.
Das Programm opsi-setup ist das "Schweizer Taschenmesser" zur Einrichtung von opsi.
So greifen zum Beispiel die Pakete zur Installation von opsi auf dem Server auf dieses Skript zurück, um opsi korrekt einzurichten. Da dieses Skript nun auch extern aufrufbar ist, lassen sich damit diverse Wartungsarbeiten und Korrekturen durchführen:
Der Befehl opsi-setup --help
zeigt die Programmoptionen:
# opsi-setup --help Usage: opsi-setup [options] Options: -h, --help show this help -l log-level 0..9 --log-file <path> path to log file --backend-config <json hash> overwrite backend config hash values --ip-address <ip> force to this ip address (do not lookup by name) --register-depot register depot at config server --set-rights [path] set default rights on opsi files (in [path] only) --init-current-config init current backend configuration --update-from=<version> update from opsi version <version> --update-mysql update mysql backend --update-file update file backend --configure-mysql configure mysql backend --edit-config-defaults edit global config defaults --cleanup-backend cleanup backend --auto-configure-samba patch smb.conf --auto-configure-dhcpd patch dhcpd.conf --renew-opsiconfd-cert renew opsiconfd-cert --patch-sudoers-file patching sudoers file for tasks in opsiadmin context.
Die Funktionen und Parameter im Einzelnen:
--ip-address <ip>
--register-depot
--set-rights [path]
Setzt bzw. korrigiert die Dateizugriffsrechte in den wesentlichen opsi-Verzeichnissen:
/tftpboot/linux
/var/log/opsi
/var/lib/opsi
/var/lib/opsi/depot
/var/lib/opsi/workbench
(oder der abweichend für das Depot konfigurierte Workbench-Pfad)
/etc/opsi
Als Parameter kann auch ein Verzeichnis übergeben werden.
Dann werden unterhalb dieses Verzeichnisses die Rechte aller opsi-relevanten Verzeichnisse und Dateien gesetzt,
z.B.:
opsi-setup --set-rights /var/lib/opsi/depot/winxppro/drivers
--init-current-config
/etc/opsi/backendManager/dispatch.conf
--update-mysql
--update-file
--configure-mysql
--edit-config-defaults
Zum Editieren der Defaultwerte der Config wie im opsi-configed in der Serverkonfiguration angezeigt.
z.B.:
--cleanup-backend
Es ist gängige, gute Praxis vor dem Aufräumen des Backends ein Backup durch opsi-backup zu erstellen.
--auto-configure-samba
/etc/samba/smb.conf
die von opsi benötigten shares.
--auto-configure-dhcpd
Der opsi-package-manager dient zur (De-) Installation von Produkt-Paketen auf einem opsi-server.
Beim Aufruf von opsi-package-manager zur Installation
muss das zu installierende Paket für den Systemuser opsiconfd lesbar sein.
Es wird daher dringend empfohlen, Produkt-Pakete aus /var/lib/opsi/workbench/
bzw. einem Unterverzeichnis hiervon zu installieren.
Die Logdatei des opsi-package-manager ist /var/log/opsi/package.log
Paket installieren (ohne Fragen neu installieren):
opsi-package-manager -i softprod_1.0-5.opsi'
Paket installieren (mit Fragen nach Properties):
opsi-package-manager -p ask -i softprod_1.0-5.opsi
Paket installieren (und für alle auf Setup stellen, bei denen es installiert ist):
opsi-package-manager -S -i softprod_1.0-5.opsi
Paket installieren (und für alle mit Abhängigkeiten auf Setup stellen, bei denen es installiert ist):
opsi-package-manager -s -i softprod_1.0-5.opsi
oder:
opsi-package-manager --setup-with-dependencies --install softprod_1.0-5.opsi
Paket deinstallieren:
opsi-package-manager -r softprod
Paket extrahieren und umbenennen:
opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod
Es ist möglich ein Paket mit einer abweichenden Product ID zu installieren. Das ist besonders dann hilfreich, wenn vorher ein Windows-Netboot-Produkt aus einem bestehenden Paket abgeleitet wurde und dieses Paket in der Zwischenzeit aktualisiert wurde.
opsi-package-manager --install win7-x64_1.2.3.opsi --new-product-id win7-x64-custom
Bitte beachten Sie, dass opsi-package-updater
derartig installierte Produkte nicht automatisch aktualisiert.
Eine Übersicht über alle Optionen liefert die Option --help
.
Zu beachten:
-d
bzw. --depots
sind für den Betrieb mehrerer Depotserver gedacht.
/var/lib/opsi/repository
kopiert.
Dort muss ausreichend Platz zur Verfügung stehen.--temp-dir
ein abweichender Ort angegeben werden.
# opsi-package-manager --help Usage: opsi-package-manager [options] <command> Manage opsi packages Commands: -i, --install <opsi-package> ... install opsi packages -u, --upload <opsi-package> ... upload opsi packages to repositories -l, --list <regex> list opsi packages matching regex -D, --differences <regex> show depot differences of opsi packages matching regex -r, --remove <opsi-product-id> ... uninstall opsi packages -x, --extract <opsi-package> ... extract opsi packages to local directory -V, --version show program's version info and exit -h, --help show this help message and exit Options: -v, --verbose increase verbosity (can be used multiple times) -q, --quiet do not display any messages --log-file <log-file> path to debug log file --log-file-level <log-file-level> log file level (default 4) -d, --depots <depots> comma separated list of depot ids to process all = all known depots -p, --properties <mode> mode for default product property values ask = display dialog package = use defaults from package keep = keep depot defaults (default) --purge-client-properties remove product property states of the installed product(s) -f, --force force install/uninstall (use with extreme caution) -U, --update set action "update" on hosts where installation status is "installed" -S, --setup set action "setup" on hosts where installation status is "installed" -s, --setup-with-dependencies set action "setup" on hosts where installation status is "installed" with dependencies -o, --overwrite overwrite existing package on upload even if size matches -n, --no-delta full package transfers on uploads (do not use librsync) -k, --keep-files do not delete client data dir on uninstall -t, --temp-dir <path> tempory directory for package install --max-transfers <num> maximum number of simultaneous uploads 0 = unlimited (default) --max-bandwidth <kbps> maximum transfer rate for each transfer (in kilobytes per second) 0 = unlimited (default) --new-product-id <product-id> Set a new product id when extracting opsi package or set a specific product ID during installation. --suppress-pcf-generation Suppress the generation of a package content file during package installation. Do not use with WAN extension!
Das Kommandozeilen-Werkzeug opsi-package-updater
dient dazu, komfortabel
opsi-Produkte aus einem oder mehreren Repositories zu laden und auf dem Server zu installieren.
Es ist dafür gedacht zeitgesteuert (bspw. als cronjob) aufgerufen zu werden und so zur automatischen Synchronisation von opsi-Servern bzw. für automatische Updates verwendet zu werden.
Repositories sind die Quellen, von denen sich der opsi-server die Pakete holt. Jedes Repository kann in Hinblick auf Zugang und Verhalten einzeln konfiguriert werden.
Die allgemeinen Konfigurationseinstellungen werden in /etc/opsi/opsi-package-updater.conf
vorgenommen.
Mittels --help
kann die Hilfe angezeigt werden.
opsi-package-updater
arbeitet mit verschiedenen Modi, welche jeweils eine eigene Hilfe mitbringen.
# opsi-package-updater --help usage: opsi-package-updater [-h] [--version] [--config CONFIGFILE] [--verbose | --log-level {0,1,2,3,4,5,6,7,8,9}] [--force-checksum-calculation] [--repo repository_name] [--use-inactive-repository] {install,update,download,list} ... Updater for local opsi products. optional arguments: -h, --help show this help message and exit --version, -V show program's version number and exit --config CONFIGFILE, -c CONFIGFILE Location of config file --verbose, -v Increase verbosity on console (can be used multiple times) --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9} Set the desired loglevel for the console. --force-checksum-calculation Force calculation of a checksum (MD5) for every package. Default is to use existing checksums from the .md5-file of a package if possible. --repo repository_name Limit the actions the given repository. --use-inactive-repository Force the activation of an otherwise disabled repository. The repository must be given through --repo. Mode: {install,update,download,list} install Install all (or a given list of) downloadable packages from configured repositories (ignores excludes) update Update already installed packages from repositories. download Download packages from repositories. This will not install packages. list Listing information Modes have their own options that can be viewed with MODE -h.
# opsi-package-updater download --help usage: opsi-package-updater download [-h] [--force] [productID [productID ...]] positional arguments: productID Limit downloads to products with the given IDs. optional arguments: -h, --help show this help message and exit --force Force the download of a product even though it would otherwise not be required.
# opsi-package-updater list --help usage: opsi-package-updater list [-h] [--repos | --active-repos | --packages | --packages-and-installationstatus | --package-differences | --updatable-packages | --search-package text] optional arguments: -h, --help show this help message and exit --repos Lists all repositories --active-repos Lists all active repositories --packages, --products Lists the repositories and the packages they provide. --packages-and-installationstatus, --products-and-installationstatus Lists the repositories with their provided packages and information about the local installation status. --package-differences, --product-differences Lists packages where local and remote version are different. --updatable-packages, --updatable-products Lists packages that have updates in the remote repositories. --search-package text, --search-product text Search for a package with the given name.
Es gibt eine Reihe von allgemeinen Optionen.
--verbose
erhöht die Menge an sichtbaren Ausgaben. Dies kann mehrfach angegeben werden, um mehr Ausgabe zu erhalten. Ein bestimmter Log-Level kann über --log-level
angegeben werden. Beide Optionen beeinflussen nur die Ausgaben im Terminal.
--repo <Name eines Repositories>
schränkt die Aktionen auf das angegebene Repository ein. Die Namen der verfügbaren Repositories können über list --active-repos
ermittelt werden.
Die verschiedenen Modi haben unterschiedliche Auswirkungen auf das Verhalten.
Die Modi install
, update
und download
laden Pakete aus einem Repository, wohingegen mit list
Informationen angezeigt werden.
Der Modus install
installiert neue Pakete.
Der Modus update
aktualisiert vorhandene Pakete.
Beide Modi benötigen keine weiteren Parameter.
Beispiel: Das Installieren aller in den Repositories vorhandenen Pakete:
opsi-package-updater install
Bei den Modi install
und update
kann die Arbeit auf bestimmte Produkte eingeschränkt werden indem deren Produkt ID angegeben wird.
Beispiel: Aktualisieren der Pakete für die Produkte firefox und javavm:
opsi-package-updater -vv update firefox javavm
In Verbindung mit dem Schalter --repo
lässt sich gezielt Einschränken, woher ein Paket bezogen werden soll.
Beispiel: Die Installation des Pakets ubuntu aus dem Repository uib_linux:
opsi-package-updater -vv --repo uib_linux install ubuntu
Der Modus download
erlaubt das Herunterladen von Paketen, ohne dass diese anschließend installiert werden.
Über den Schalter --force
kann der Download erzwungen werden, selbst wenn diese Version schon auf dem Server installiert ist.
Mittels list --active-repos
werden die aktivierten Repositories angezeigt.
Die gezeigten Informationen sind der Name, die Adresse des Repositories und sofern vorhanden die Beschreibung des Repositories.
Über list --products
wird angezeigt welche Produkte im Repository vorhanden sind.
Zum Anzeigen der verfügbaren Aktualisierungen kann list --updatable-products
verwendet werden.
Dabei werden nur die bereits installierten Produkte berücksichtigt.
Anschließend kann die Aktualisierung über update
angestoßen werden.
opsi-package-updater list --updatable-packages opsi-package-updater -v update
Konfigurationsdateien für die einzelnen Repositories sind unter /etc/opsi/package-updater.repos.d/
zu finden.
Eine kommentierte Vorlage mit allen Einstellungsmöglichkeiten findet sich dort als example.repo.template
.
Es gibt zwei Arten von Repositories, Internet-Repositories und opsi-Server.
Internet-Repositories
Das wichtigste Beispiel ist das uib-Repository mit der URL http://download.uib.de
Internet-Repositories sind gekennzeichnet durch die Parameter
http://download.uib.de
)
opsi4.0/products/localboot
)
Bei Bedarf kann Zugang über einen Proxy konfiguriert werden.
Falls ein gemeinsamer Proxy verwendet werden soll, kann dieser für alle Repositories in opsi-package-updater.conf
eingetragen werden.
Dies benötigt mindestens opsi-utils 4.1.1.33.
Alle Repositories ohne eigene Proxy-Konfiguration werden diesen verwenden.
baseUrl = http://download.uib.de dirs = opsi4.0/products/localboot username = password = proxy =
opsi-server
Ein Repository hat den Typ opsi-server, wenn in der Repository-Konfigurationsdatei unter dem Punkt opsiDepotId die ID eines anderen opsi-Servers eingetragen wird.
opsiDepotId = mainserver.my.lan
In der Regel ist bei einem opsi-depotserver an dieser Stelle der zentrale configserver einzutragen.
Damit bezieht der Depotserver seine Pakete vom zentralen Server.
Der opsi-package-updater
bezieht die Pakete aus dem Verzeichnis /var/lib/opsi/repository
des angegebenen Servers.
Für jedes Repository kann eingestellt werden:
Zusätzlich ist es möglich, die Aktualisierung der Pakete auf den Clients über einen konfigurierbaren Wake-On-Lan-Mechanismus anzustoßen. In Verbindung mit dem Produkt shutdownwanted kann dafür gesorgt werden, dass die Clients nacheinander geweckt, die Software verteilt und die Clients danach wieder heruntergefahren werden. Hierdurch kann man seine Clients zum Beispiel außerhalb der Geschäftszeiten mit Updates und Software versorgen und die Anwender können am nächsten Morgen direkt mit der Arbeit beginnen.
Seit opsi 3.0 enthält eine Python-Bibliothek die zentralen Zugriffsfunktionen auf die opsi-Datenhaltung. Nach außen bietet opsiconfd diese als API an, mit der ihre Funktionen genutzt werden können. Es gibt mehrere Wege darauf zuzugreifen.
Über den Aufruf von https://<opsi-server>:4447/interface kann über ein grafisches Frontend in elementare Form auf diesen Webservice zugegriffen werden. Dazu müssen Sie sich als Mitglied der Gruppe opsiadmin authentifizieren.
Auf der Kommandozeile kann mit dem Befehl opsi-admin
auf die opsi API zugegriffen werden.
Dabei bietet opsi-admin einen interaktiven und einen nicht-interaktiven Modus, z.B. zum Einsatz in Skripten.
Der Aufruf von opsi-admin --help
zeigt eine Hilfe zu den Optionen:
# opsi-admin --help Verwendung: opsi-admin [options] [command] [args...] Optionen: -h, --help Diesen Hilfetext anzeigen -V, --version Versionsnummer ausgeben und beenden -u, --username Benutzername (standard: momentaner Benutzer) -p, --password Passwort (standard: Passwort interaktiv abfragen) -a, --address URL des opsiconfd (standard: https://localhost:4447/rpc) --opsirc Pfad zur zu verwendende opsirc-Datei (Standard: ~/.opsi.org/opsirc) Eine opsirc-Datei beinhaltet Zugangsdaten für die Web API. -d, --direct opsiconfd umgehen --no-depot Depotserver-Backend nicht verwenden -l, --log-level Protokollierungsstufe (Standard: 3) 0=nichts, 1=essenziell, 2=kritisch, 3=Fehler, 4=Warnungen 5=Hinweise, 6=Informationen, 7=debug, 8=debug2, 9=vertraulich -f, --log-file Pfad zur Protokolldatei -i, --interactive Im interaktiven Modus starten -c, --colorize Farbige Ausgabe -S, --simple-output Einfache Ausgabe (nur für Skalare und Listen) -s, --shell-output Shell-Ausgabe -r, --raw-output Rohdaten-Ausgabe --exit-zero Beende immer mit Exit-Code 0.
´opsi-admin´ kann auf einen opsi-Webservice zugreifen oder direkt auf der Datenhaltung arbeiten.
Für die Arbeit über den Webservice müssen neben der URL auch username und password angegeben werden.
Als Benutzername wird der Name des aktuell angemeldeten Benutzers verwendet.
Ein abweichender Name kann mittels --username
angegeben werden.
Für die Verwendung in Scripten wird man besonders das Kennwort nicht direkt über die Kommandozeile
angeben wollen, weil die Gefahr besteht, dass diese Werte in der Prozessliste von
anderen Benutzern gesehen werden können.
Es bietet sich dabei an eine opsirc-Datei zu verwenden.
Als Alternative kann der direkte Datenzugriff über die Option -d
verwendet werden.
opsi-admin
bietet einen interaktiven Modus an, welcher mit -i
gestartet wird.
In der Regel wird man diesen zusätzlich mit -c
zur farbigen Anzeige und manchmal zusätzlich mit -d
für direkten Datenzugriff starten wollen - der Befehl lautet dann opsi-admin -i -c -d
, kurz opsi-admin -idc
.
Im interaktiven Modus erhalten Sie Eingabe-Unterstützung durch die Tabtaste.
Betätigen der Tabtaste führt auf eine Auswahl der der möglichen Fortsetzungen der Eingabe
bzw. die Angabe des Datentyps der nächsten erwarteten Eingabe.
In der Liste der möglichen Eingaben können Sie mit Bild-auf und Bild-ab blättern.
Die Optionen -s
und -S
erzeugen eine Form der Ausgabe welche sich leichter in Skripten weiterverarbeiten lässt.
Außer den Methodenaufrufen (eingeleitet mit method
), welche direkt die API widerspiegeln, gibt
es Aufrufe (eingeleitet mit task
),
die intern auf eine Kombination von Methodenaufrufen zur Erledigung
einer bestimmten Aufgabe abgebildet werden.
Seit Version 4.1.1.30 bietet opsi-admin
die Möglichkeit die Konfiguration
für die Verbindung zum opsi Webservice in einer Datei zu speichern.
Damit ist es möglich eine Verbindung über den Webservice zu verwenden,
ohne dass Benutzername und Kennwort auf der Kommandozeile angegeben werden.
Eine solche Datei wird standardmäßig in ~/.opsi.org/opsirc
gesucht.
Mit der Option --opsirc
kann der Pfad zur zu verwendenden Datei angegeben werden.
Dadurch können mehrere, unterschiedlich konfigurierte Verbindungen
vorbereitet werden.
Eine opsirc-Datei hat den folgenden Aufbau:
address = https://seeing.the.ramp:4447/rpc username = tony password file = ~/.opsi.org/tonys_secret
Alle Angaben in einer opsirc-Datei sind optional. Falls die Datei leer oder nicht vorhanden ist, so werden die Standard-Einstellungen verwenden.
In vorangegangenen Beispiel ist das Kennwort in der Datei ~/.opsi.org/tonys_secret
hinterlegt
und wird von dort ausgelesen.
Diese Datei enthält nur das Kennwort.
Es ist ebenfalls möglich das Passwort direkt anzugeben:
address = https://seeing.the.ramp:4447/rpc username = tony password = first900
Ein Produkt für alle Clients auf setup stellen, welche dieses Produkt installiert haben:
opsi-admin -d task setupWhereInstalled "softprod"
opsi-admin -d method host_getIdents
opsi-admin -d method host_delete <clientname>
z.B.:
opsi-admin -d method host_delete "pxevm.uib.local"
opsi-admin -d method host_createOpsiClient <full qualified clientname>
z.B.:
opsi-admin -d method host_createOpsiClient "pxevm.uib.local"
opsi-admin -d method setProductActionRequest <productId> <clientId> <actionRequest>
z.B.:
opsi-admin -d method setProductActionRequest win7 pxevm.uib.local setup
Beschreibungen den Clients zuordnen.
opsi-admin -d method setHostDescription "dpvm02.uib.local" "virtueller Client"
IDs aller Clients auflisten. Hierzu wird die Option -S
verwendet, um zu erreichen, dass jeder Client in einer eigenen Zeile ausgeben wird. Durch die Eingrenzung auf den Typ OpsiClient
wird verhindert, dass opsi-Server mit ausgegeben werden.
Diese Ausgabe eignet sich zur Weiterverwendung in anderen Aufrufen.
opsi-admin -dS method host_getIdents '' '{"type": "OpsiClient"}'
Auflisten der auf Clients installierten Produkte.
opsi-admin -d method productOnClient_getObjects '["productVersion", "packageVersion", "installationStatus"]' '{"installationStatus": "installed"}'
opsi-admin -d task setPcpatchPassword
Setzt das Passwort von pcpatch für Unix, samba und opsi.
Der opsipxeconfd dient zur Bereitstellung von named pipes im tftpboot
-Bereich,
welche den Bootvorgang eines PCs über das PXE-Protokoll steuern.
Die zugehörige Konfigurationsdatei ist /etc/opsi/opsipxeconfd.conf
, die Logdatei
/var/log/opsi/opsipxeconfd.log
.
Der opsiconfd dient zur Bereitstellung der opsi-server-API als JSON-Webservice und nimmt noch eine Reihe weiterer Aufgaben wahr.
Dieser Dienst ist damit der zentrale opsi-Dienst. Über ihn wird z.B. sämtliche Kommunikation zwischen den Clients und dem Server abgewickelt.
Daher ist die Möglichkeit, diesen Prozess und seine Last zu überwachen, ein wichtiges Werkzeug.
Unter der Webadresse https://<opsi-server>:4447/info erhalten Sie grafisch aufbereitete Informationen über den Lastverlauf des opsiconfd der letzten Stunde, des letzten Tages, des letzten Monats und des letzten Jahrs sowie weitere tabellarische Informationen.
Der opsi-tftpd-hpa ist ein standard tftpd-hpa, welche um die Fähigkeit erweitert wurde mit named pipes umzugehen.
Per default wird der opsi-tftpd-hpa so installiert, daß er standardmäßig läuft und per systemd service file gestartet oder gestoppt werden kann.
Für gewöhnlich startet der Dienst mit einem Verbose Parameter. Zur Fehlersuche oder zur weiteren Analyse kann der Dienst mehr loggen. Hierfür muss folgender Befehl eingegeben werden:
# systemctl edit --full opsi-tftpd-hpa.service
Nun muss der Parameter -v durch den Parameter --verbosity 7 ersetzt werden. Daraufhin genügt es den Dienst neu zu starten
# service opsi-tftpd-hpa restart
auf Debian 8 ist die Operation edit nicht verfügbar. Hier die Befehle zum Ändern des Parameters:
# cp /lib/systemd/system/opsi-tftpd-hpa.service /etc/systemd/system/opsi-tftpd-hpa.service # vi /etc/systemd/system/opsi-tftpd-hpa.service # systemctl daemon-reload # service opsi-tftpd-hpa restart
Seit opsi 4 gibt es zwei unterschiedliche Arten von API Methoden:
Die opsi4-Backends basieren auf Objekten. Ein Objekt hat eine Reihe von Eigenschaften.
Als Beispiel diene hier das Objekt product. Das Objekt vom Typ product, welches das opsi-Produkt javavm beschreibt sieht z.B. so aus:
"ident": "javavm;1.6.0.20;2" "id": "javavm" "description": "Java 1.6" "changelog": "" "advice": "" "userLoginScript": "" "name": "SunJavaRuntimeEnvironment" "priority": 0 "packageVersion": "2" "productVersion": "1.6.0.20" "windowsSoftwareIds": None "productClassIds": None "type": "LocalbootProduct" "licenseRequired": False "setupScript": "javavm.ins" "updateScript": "" "uninstallScript": "deljvm.ins" "alwaysScript": "" "onceScript": "" "customScript": ""
Zu jedem Objekt gibt es eine Reihe von Operationen. In der Regel sind dies:
Die Namen der Methoden setzen sich zusammen aus:
<object name>_<operation>
Dadurch unterscheiden sie sich von den Legacy Methoden aus opsi 3.x welche in der Regel mit get, set oder create anfangen.
Die getObjects-Methoden haben zwei optionale Parameter:
attributes dient dazu, nur bestimmte Attribute des Objektes abzufragen. Zurückgeliefert werden immer alle Attributnamen, aber nur die Werte der Attribute, welche das Objekt eindeutig kennzeichnen sowie die in attributes angegebenen Attributwerden. Die restlichen Attribute werden mit dem Wert None geliefert.
So liefert z.B die Methode product_getObjects, parametrisiert mit attributes:["name"] für das Produkt javavm:
"onceScript": None, "ident": "javavm;1.6.0.20;2", "windowsSoftwareIds": None, "description": None, "setupScript": None, "changelog": None, "customScript": None, "advice": None, "uninstallScript": None, "userLoginScript": None, "name": "Sun Java Runtime Environment", "priority": None, "packageVersion": "2", "productVersion": "1.6.0.20", "updateScript": None, "productClassIds": None, "alwaysScript": None, "type": "LocalbootProduct", "id": "javavm", "licenseRequired": None
Wenn Sie keine attributes, aber einen filter angeben möchten, darf das Feld Sie für attributes nicht ganz leer bleiben, sondern muss den Wert [] erhalten.
Mit filter kann eingeschränkt werden, zu welchen Objekten Informationen geholt werden sollen, ähnlich einer sql-where-Bedingung. So schränkt für product_getObjects der Filter { "id":"javavm" } die Rückgabe auf das Object javavm ein.
Bei den Methoden, denen ein oder mehrere Objekte übergeben werden, muss dies als JSON-Objekt bzw. als Liste von JSON-Objekten geschehen.
Die wichtigsten Objekte sind:
Daneben gibt es noch eine Reihe von weiteren Objekten mit speziellen Operationen. Das aufgeführte Design ermöglicht es:
Hierdurch wird eine verbesserte Stabilität und höhere Performanz erreicht.
Beispiel für einen OpsiClient:
method host_getObjects [] {"id":"xpclient.vmnat.local"} [ { "ident" : "xpclient.vmnat.local", "description" : "", "created" : "2012-03-22 12:13:52", "inventoryNumber" : "", "ipAddress" : "172.16.166.101", "notes" : "Created by opsi-deploy-client-agent at Wed, 24 Aug 2011 10:24:36", "oneTimePassword" : "", "lastSeen" : "2012-03-30 16:20:04", "hardwareAddress" : "00:0c:29:35:70:a7", "opsiHostKey" : "1234567890abcef1234567890abcdef", "type" : "OpsiClient", "id" : "xpclient.vmnat.local" } ]
Die meisten dieser Daten finden sich im clients tab des opsi-configed.
Mögliche Werte für type
:
Der Server type hat andere und mehr Daten als ein Client..
Beispiel für einen server:
method host_getObjects [] {"id":"sepiolina.vmnat.local"} [ { "masterDepotId" : null, "ident" : "sepiolina.vmnat.local", "networkAddress" : "172.16.166.0/255.255.255.128", "description" : "", "inventoryNumber" : "", "ipAddress" : "172.16.166.1", "repositoryRemoteUrl" : "webdavs://sepiolina.vmnat.local:4447/repository", "depotLocalUrl" : "file:///var/lib/opsi/depot", "isMasterDepot" : true, "notes" : "", "hardwareAddress" : null, "maxBandwidth" : 0, "repositoryLocalUrl" : "file:///var/lib/opsi/repository", "opsiHostKey" : "1234567890abcef1234567890abcdef", "type" : "OpsiConfigserver", "id" : "sepiolina.vmnat.local", "depotWebdavUrl" : "webdavs://sepiolina:4447/depot", "depotRemoteUrl" : "smb://sepiolina/opsi_depot" } ]
Die meisten dieser Daten finden sich in der depot configuration des opsi-configed.
Beschreibt Gruppen und Ihre hierarchische Struktur
Beispiel für ein group
Objekt:
method group_getObjects [ { "ident" : "sub2", "description" : "sub2", "notes" : "", "parentGroupId" : null, "type" : "HostGroup", "id" : "sub2" }, { "ident" : "subsub", "description" : "subsub", "notes" : "", "parentGroupId" : "sub2", "type" : "HostGroup", "id" : "subsub" } ]
Beschreibt die Mitgliedschaft von Objekten in Gruppen.
Es gibt Hostgroups und Productgroups
Beispiel für ein objectToGroup
Objekt:
method objectToGroup_getObjects [ { "groupType" : "HostGroup", "ident" : "HostGroup;sub2;win7.vmnat.local", "type" : "ObjectToGroup", "groupId" : "sub2", "objectId" : "win7.vmnat.local" }, { "groupType" : "HostGroup", "ident" : "HostGroup;subsub;win7x64.vmnat.local", "type" : "ObjectToGroup", "groupId" : "subsub", "objectId" : "win7x64.vmnat.local" }, { "groupType" : "ProductGroup", "ident" : "ProductGroup;opsiessentials;opsi-client-agent", "type" : "ObjectToGroup", "groupId" : "opsiessentials", "objectId" : "opsi-client-agent" }, { "groupType" : "ProductGroup", "ident" : "ProductGroup;opsiessentials;opsi-winst", "type" : "ObjectToGroup", "groupId" : "opsiessentials", "objectId" : "opsi-winst" } ]
Beschreibt die Meta-Daten eines Produktes wie sie bei der Erstellung des Produktes definiert wurden.
Beispiel für ein product
Objekt:
method product_getObjects [] {"id":"jedit","productVersion":"4.5"} [ { "onceScript" : "", "ident" : "jedit;4.5;3", "windowsSoftwareIds" : [ ], "description" : "jEdit with opsi-winst Syntax-Highlighting", "setupScript" : "setup.ins", "changelog" : "", "customScript" : "", "advice" : "", "uninstallScript" : "uninstall.ins", "userLoginScript" : "", "name" : "jEdit programmer's text editor", "priority" : 0, "packageVersion" : "3", "productVersion" : "4.5", "updateScript" : "update.ins", "productClassIds" : [ ], "alwaysScript" : "", "type" : "LocalbootProduct", "id" : "jedit", "licenseRequired" : false } ]
Im Fall von mehreren Depotservern, können hier unterschiedliche Versionen eines product
auftauchen.
Die Eintragungen für productClassIds und windowsSoftwareIds werden im Moment nicht verwendet.
Beschreibt die properties eines product
wie sie bei der Erstellung des Produktes definiert wurden.
Beispiel für ein productProperty
Objekt:
method productProperty_getObjects [] {"productId":"jedit","productVersion":"4.5"} [ { "ident" : "jedit;4.5;3;start_server", "description" : "Should the jedit derver started at every startup ?", "editable" : false, "defaultValues" : [ false ], "multiValue" : false, "productVersion" : "4.5", "possibleValues" : [ false, true ], "packageVersion" : "3", "type" : "BoolProductProperty", "propertyId" : "start_server", "productId" : "jedit" } ]
Die für einen Client verwendeten default Werte finden sich nicht hier, sondern werden Depotspezifisch in productPropertyState
Objekten gespeichert.
Beschreibt:
Beispiel für ein productPropertyState
Objekt:
method productPropertyState_getObjects [] {"productId":"jedit"} [ { "ident" : "jedit;start_server;sepiolina.vmnat.local", "objectId" : "sepiolina.vmnat.local", "values" : [ false ], "type" : "ProductPropertyState", "propertyId" : "start_server", "productId" : "jedit" }, { "ident" : "jedit;start_server;xpclient.vmnat.local", "objectId" : "xpclient.vmnat.local", "values" : [ true ], "type" : "ProductPropertyState", "propertyId" : "start_server", "productId" : "jedit" } ]
Beschreibt die Abhäningkeit eines Produktes zu einem anderen Produkt wie sie bei der Erstellung des Produktes definiert wurden.
Beispiel für ein productDependency
Objekt:
method productDependency_getObjects [] {"productId":"jedit","productVersion":"4.5"} [ { "ident" : "jedit;4.5;3;setup;javavm", "productAction" : "setup", "requiredPackageVersion" : null, "requirementType" : "before", "requiredInstallationStatus" : "installed", "productVersion" : "4.5", "requiredProductId" : "javavm", "requiredAction" : null, "requiredProductVersion" : null, "type" : "ProductDependency", "packageVersion" : "3", "productId" : "jedit" } ]
Beschreibt, welche Produkte in welchen Versionen auf welchem Client installiert sind.
Beispiel für ein productOnClient
Objekt:
method productOnClient_getObjects [] {"productId":"jedit","clientId":"xpclient.vmnat.local"} [ { "ident" : "jedit;LocalbootProduct;xpclient.vmnat.local", "actionProgress" : "", "actionResult" : "successful", "clientId" : "xpclient.vmnat.local", "modificationTime" : "2012-03-30 15:49:04", "actionRequest" : "none", "targetConfiguration" : "installed", "productVersion" : "4.5", "productType" : "LocalbootProduct", "lastAction" : "setup", "packageVersion" : "3", "actionSequence" : -1, "type" : "ProductOnClient", "installationStatus" : "installed", "productId" : "jedit" } ]
Beschreibt, welches Produkt in welcher Version auf welchem Depot installiert ist.
Beispiel für ein productOnDepot
Objekt:
method productOnDepot_getObjects [] {"productId":"jedit"} [ { "ident" : "jedit;LocalbootProduct;4.4.1;2;depotserver.vmnat.local", "locked" : false, "productVersion" : "4.4.1", "productType" : "LocalbootProduct", "depotId" : "depotserver.vmnat.local", "type" : "ProductOnDepot", "packageVersion" : "2", "productId" : "jedit" }, { "ident" : "jedit;LocalbootProduct;4.5;3;sepiolina.vmnat.local", "locked" : false, "productVersion" : "4.5", "productType" : "LocalbootProduct", "depotId" : "sepiolina.vmnat.local", "type" : "ProductOnDepot", "packageVersion" : "3", "productId" : "jedit" } ]
Im Fall von mehreren Depotservern, können hier unterschiedliche Versionen eines Produktes auftauchen.
Beschreibt die Hostparameter der Server Konfiguration des opsi-configeds.
Beispiel für ein config
Objekt:
method config_getObjects [] {"id":"opsiclientd.event_gui_startup.active"} [ { "ident" : "opsiclientd.event_gui_startup.active", "description" : "gui_startup active", "defaultValues" : [ true ], "editable" : false, "multiValue" : false, "possibleValues" : [ false, true ], "type" : "BoolConfig", "id" : "opsiclientd.event_gui_startup.active" } ]
Beschreibt die Hostparameter der Client Konfiguration des opsi-configeds..
Beispiel für ein configState
Objekt:
method configState_getObjects [] {"configId":"opsiclientd.event_gui_startup.active"} [ { "configId" : "opsiclientd.event_gui_startup.active", "ident" : "opsiclientd.event_gui_startup.active;wanclient.vmnat.local", "values" : [ false ], "objectId" : "wanclient.vmnat.local", "type" : "ConfigState" } ]
Ein configState Objekt kann nicht erzeugt werden ohne das das config Objekt existiert auf das es referenziert.
Beschreibt die ermittelten Hardwaretypen (inclusive der clientspezifischen Daten). Die Idee ist in diesem Objekt die clientspezifischen Daten zu halten und in auditHardware
nur die allgemeinen, so dass es dort z.B. nur einen Eintrag für eine Netzwerkkarte gibt, die in vielen Clients benutzt wird.
Leider funktioniert diese Idee in der Praxis nicht wirklich.
Das Attribut state legt fest ob die Daten aktuell (Wert = 1) oder historisch (Wert = 0) sind.
Beispiel für ein auditHardwareOnHost
Objekt:
method auditHardwareOnHost_getObjects [] {"hostId":"xpclient.vmnat.local","hardwareClass":"NETWORK_CONTROLLER","ipAddress":"172.16.166.101"} [ { "vendorId" : "1022", "macAddress" : "00:0C:29:35:70:A7", "hardwareClass" : "NETWORK_CONTROLLER", "state" : 1, "deviceType" : "PCI", "subsystemVendorId" : "2000", "ipEnabled" : "True", "type" : "AuditHardwareOnHost", "firstseen" : "2012-03-30 15:48:15", "revision" : "10", "hostId" : "xpclient.vmnat.local", "vendor" : "Advanced Micro Devices (AMD)", "description" : "Ethernetadapter der AMD-PCNET-Familie", "subsystemDeviceId" : "1022", "deviceId" : "2000", "autoSense" : null, "netConnectionStatus" : "Connected", "maxSpeed" : null, "name" : "Ethernetadapter der AMD-PCNET-Familie", "serialNumber" : null, "lastseen" : "2012-03-30 15:48:15", "model" : null, "ipAddress" : "172.16.166.101", "adapterType" : "Ethernet 802.3" }, { "vendorId" : "1022", "macAddress" : "00:0C:29:35:70:A7", "hardwareClass" : "NETWORK_CONTROLLER", "state" : 0, "deviceType" : "PCI", "subsystemVendorId" : "2000", "ipEnabled" : "True", "type" : "AuditHardwareOnHost", "firstseen" : "2012-03-08 14:26:14", "revision" : "10", "hostId" : "xpclient.vmnat.local", "vendor" : "VMware, Inc.", "description" : "VMware Accelerated AMD PCNet Adapter", "subsystemDeviceId" : "1022", "deviceId" : "2000", "autoSense" : null, "netConnectionStatus" : "Connected", "maxSpeed" : null, "name" : "VMware Accelerated AMD PCNet Adapter", "serialNumber" : null, "lastseen" : "2012-03-10 14:47:15", "model" : null, "ipAddress" : "172.16.166.101", "adapterType" : "Ethernet 802.3" }, { "vendorId" : "1022", "macAddress" : "00:0c:29:35:70:a7", "hardwareClass" : "NETWORK_CONTROLLER", "state" : 0, "deviceType" : null, "subsystemVendorId" : "1022", "ipEnabled" : null, "type" : "AuditHardwareOnHost", "firstseen" : "2012-02-29 15:43:21", "revision" : "10", "hostId" : "xpclient.vmnat.local", "vendor" : "Advanced Micro Devices [AMD]", "description" : "Ethernet interface", "subsystemDeviceId" : "2000", "deviceId" : "2000", "autoSense" : "", "netConnectionStatus" : "yes", "maxSpeed" : null, "name" : "79c970 [PCnet32 LANCE]", "serialNumber" : "00:0c:29:35:70:a7", "lastseen" : "2012-03-30 14:58:30", "model" : "79c970 [PCnet32 LANCE]", "ipAddress" : "172.16.166.101", "adapterType" : "" } ]
Beschreibt die ermittelten Hardwaretypen (ohne die clientspezifischen Daten). Die Idee ist in diesem Objekt nur die allgemeinen Daten eines Hardwaretyps zu halten, so dass es hier z.B. nur einen Eintrag für eine Netzwerkkarte gibt, die in vielen Clients benutzt wird.
Leider funktioniert diese Idee in der Praxis nicht wirklich.
Beispiel für ein auditHardware
Objekt:
method auditHardware_getObjects [] {"hardwareClass":"NETWORK_CONTROLLER","vendorId":"1022"} [ { "vendorId" : "1022", "deviceId" : "2000", "maxSpeed" : null, "vendor" : "Advanced Micro Devices [AMD]", "name" : "79c970 [PCnet32 LANCE]", "subsystemDeviceId" : "2000", "deviceType" : null, "subsystemVendorId" : "1022", "autoSense" : "", "model" : "79c970 [PCnet32 LANCE]", "revision" : "10", "type" : "AuditHardware", "hardwareClass" : "NETWORK_CONTROLLER", "adapterType" : "", "description" : "Ethernet interface" }, { "vendorId" : "1022", "deviceId" : "2000", "maxSpeed" : null, "vendor" : "VMware, Inc.", "name" : "VMware Accelerated AMD PCNet Adapter", "subsystemDeviceId" : "1022", "deviceType" : "PCI", "subsystemVendorId" : "2000", "autoSense" : null, "model" : null, "revision" : "10", "type" : "AuditHardware", "hardwareClass" : "NETWORK_CONTROLLER", "adapterType" : "Ethernet 802.3", "description" : "VMware Accelerated AMD PCNet Adapter" }, { "vendorId" : "1022", "deviceId" : "2000", "maxSpeed" : null, "vendor" : "Advanced Micro Devices (AMD)", "name" : "Ethernetadapter der AMD-PCNET-Familie", "subsystemDeviceId" : "1022", "deviceType" : "PCI", "subsystemVendorId" : "2000", "autoSense" : null, "model" : null, "revision" : "10", "type" : "AuditHardware", "hardwareClass" : "NETWORK_CONTROLLER", "adapterType" : "Ethernet 802.3", "description" : "Ethernetadapter der AMD-PCNET-Familie" }, { "vendorId" : "1022", "deviceId" : "2000", "maxSpeed" : null, "vendor" : "Advanced Micro Devices (AMD)", "name" : "Ethernetadapter der AMD-PCNET-Familie", "subsystemDeviceId" : "1022", "deviceType" : "PCI", "subsystemVendorId" : "2000", "autoSense" : null, "model" : null, "revision" : "10", "type" : "AuditHardware", "hardwareClass" : "NETWORK_CONTROLLER", "adapterType" : "Ethernet 802.3", "description" : "Ethernetadapter der AMD-PCNET-Familie" }, { "vendorId" : "1022", "deviceId" : "2000", "maxSpeed" : null, "vendor" : "Advanced Micro Devices (AMD)", "name" : null, "subsystemDeviceId" : "2000", "deviceType" : "PCI", "subsystemVendorId" : "1022", "autoSense" : null, "model" : "", "revision" : null, "type" : "AuditHardware", "hardwareClass" : "NETWORK_CONTROLLER", "adapterType" : null, "description" : "Ethernetadapter der AMD-PCNET-Familie" }, (....) [
Beschreibt die ermittelten Softwaretypen (inclusive der clientspezifischen Daten). Die Idee ist in diesem Objekt die clientspezifischen Daten zu halten und in auditSoftware
nur die allgemeinen, so dass es dort z.B. nur einen Eintrag für eine Office-Software gibt, die in vielen Clients benutzt wird.
Beispiel für ein auditSoftwareOnClient
Objekt:
method auditSoftwareOnClient_getObjects [] {"name":"jEdit 4.5.0","clientId":"xpclient.vmnat.local"} [ { "ident" : "jEdit 4.5.0;4.5.0;;;x86;xpclient.vmnat.local", "licenseKey" : "", "name" : "jEdit 4.5.0", "uninstallString" : "\\\"C:\\\\Programme\\\\jEdit\\\\unins000.exe\\\"", "usageFrequency" : -1, "clientId" : "xpclient.vmnat.local", "lastUsed" : "0000-00-00 00:00:00", "subVersion" : "", "language" : "", "state" : 1, "version" : "4.5.0", "lastseen" : "2012-03-30 16:19:55", "binaryName" : "", "type" : "AuditSoftwareOnClient", "firstseen" : "2012-03-30 16:19:55", "architecture" : "x86" } ]
Beschreibt die ermittelten Softwaretypen (ohne die clientspezifischen Daten). Die Idee ist in diesem Objekt nur die allgemeinen Daten eines Softwaretyps zu halten, so dass es hier z.B. nur einen Eintrag für eine Office-Software gibt, die in vielen Clients benutzt wird.
Beispiel für ein auditSoftware
Objekt:
method auditSoftware_getObjects [] {"name":"jEdit 4.5.0"} [ { "windowsDisplayVersion" : "4.5.0", "ident" : "jEdit 4.5.0;4.5.0;;;x64", "name" : "jEdit 4.5.0", "windowsSoftwareId" : "jedit_is1", "windowsDisplayName" : "jEdit 4.5.0", "installSize" : -1, "subVersion" : "", "language" : "", "version" : "4.5.0", "architecture" : "x64", "type" : "AuditSoftware" }, { "windowsDisplayVersion" : "4.5.0", "ident" : "jEdit 4.5.0;4.5.0;;;x86", "name" : "jEdit 4.5.0", "windowsSoftwareId" : "jedit_is1", "windowsDisplayName" : "jEdit 4.5.0", "installSize" : -1, "subVersion" : "", "language" : "", "version" : "4.5.0", "architecture" : "x86", "type" : "AuditSoftware" } ]
Beschreibt die Zuordnung von Mustern aus der Softwareinventarisierung (auditSoftware) zu einzelnen Lizenzpools.
Beispiel für ein auditSoftwareToLicensePool
Objekt:
method auditSoftwareToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"} [ { "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x64;win7-msdn-prof", "name" : "Windows 7 Professional N", "language" : "de-DE", "subVersion" : "00376-165", "licensePoolId" : "win7-msdn-prof", "version" : "6.1", "architecture" : "x64", "type" : "AuditSoftwareToLicensePool" }, { "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x86;win7-msdn-prof", "name" : "Windows 7 Professional N", "language" : "de-DE", "subVersion" : "00376-165", "licensePoolId" : "win7-msdn-prof", "version" : "6.1", "architecture" : "x86", "type" : "AuditSoftwareToLicensePool" } ]
Beschreibt die Zuordnung von 'softwareLicenseId’s zu 'licensePoolId’s.
Beispiel für ein softwareLicenseToLicensePool
Objekt:
method softwareLicenseToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"} [ { "licensePoolId" : "win7-msdn-prof", "softwareLicenseId" : "uib-msdn-win7-vol", "ident" : "uib-msdn-win7-vol;win7-msdn-prof", "licenseKey" : "12345-12345-12345-12345-3dbv6", "type" : "SoftwareLicenseToLicensePool" } ]
Beschreibt die existierenden Softwarelizenzen und deren Metadaten.
Beispiel für ein softwareLicense
Objekt:
method softwareLicense_getObjects [] {"id":"uib-msdn-win7-vol"} [ { "ident" : "uib-msdn-win7-vol;msdn-uib", "maxInstallations" : 0, "boundToHost" : null, "expirationDate" : "0000-00-00 00:00:00", "licenseContractId" : "msdn-uib", "type" : "VolumeSoftwareLicense", "id" : "uib-msdn-win7-vol" } ]
Beschreibt die existierenden Lizenzverträge und deren Metadaten.
Beispiel für ein licenseContract
Objekt:
method licenseContract_getObjects [] {"id":"msdn-uib"} [ { "ident" : "msdn-uib", "description" : "", "conclusionDate" : "2011-04-22 00:00:00", "notificationDate" : "0000-00-00 00:00:00", "notes" : "", "expirationDate" : "0000-00-00 00:00:00", "partner" : "Microsoft", "type" : "LicenseContract", "id" : "msdn-uib" } ]
Beschreibt, welcher Client welche Lizenz in Verwendung hat.
Beispiel für ein licenseOnClient
Objekt:
method licenseOnClient_getObjects [] {"clientId":"win7client.vmnat.local"} [ { "softwareLicenseId" : "uib-msdn-win7-vol", "ident" : "uib-msdn-win7-vol;win7-msdn-prof;win7client.vmnat.local", "licenseKey" : "12345-12345-12345-12345-3dbv6", "notes" : "", "clientId" : "win7client.vmnat.local", "licensePoolId" : "win7-msdn-prof", "type" : "LicenseOnClient" } ]
Beschreibt einen Lizenzpool und dessen Zuordnung zu Produkten.
Beispiel für ein licensePool
Objekt:
method licensePool_getObjects [] {"id":"win7-msdn-prof"} [ { "ident" : "win7-msdn-prof", "type" : "LicensePool", "description" : "MSDN Keys", "productIds" : [ "win7", "win7-x64" ], "id" : "win7-msdn-prof" } ]
Hier soll erläutert werden, wie Änderungen an einem Objekt durch geführt werden können.
Als Beispiel wird das host
Objekt verwendet, welches über die Auswahl auf den Typ OpsiDepotserver
eingeschränkt wird:
method host_getObjects '[]' {"type":"OpsiDepotserver"} [ { "masterDepotId" : null, "ident" : "configserver.vmnat.local", "networkAddress" : "172.16.166.0/255.255.255.128", "description" : "", "inventoryNumber" : "", "ipAddress" : "172.16.166.1", "repositoryRemoteUrl" : "webdavs://configserver.vmnat.local:4447/reposi tory", "depotLocalUrl" : "file:///var/lib/opsi/depot", "isMasterDepot" : true, "notes" : "", "hardwareAddress" : null, "maxBandwidth" : 0, "repositoryLocalUrl" : "file:///var/lib/opsi/repository", "opsiHostKey" : "17835c8d52170dcd06ba3c5089a74815", "type" : "OpsiConfigserver", "id" : "configserver.vmnat.local", "depotWebdavUrl" : "webdavs://configserver.vmnat.local:4447/depot", "depotRemoteUrl" : "smb://configserver/opsi_depot" }, { "masterDepotId" : null, "ident" : "depotserver.vmnat.local", "networkAddress" : "172.16.166.128/25", "description" : "Depot Server", "inventoryNumber" : "", "ipAddress" : "172.16.166.150", "repositoryRemoteUrl" : "webdavs://depotserver.vmnat.local:4447/reposi tory", "depotLocalUrl" : "file:///var/lib/opsi/depot", "isMasterDepot" : true, "notes" : "", "hardwareAddress" : "00:0c:29:7d:eb:55", "maxBandwidth" : 0, "repositoryLocalUrl" : "file:///var/lib/opsi/repository", "opsiHostKey" : "8284d506278667cb25cc2f9f992a024d", "type" : "OpsiDepotserver", "id" : "depotserver.vmnat.local", "depotWebdavUrl" : "webdavs://depotserver.vmnat.local:4447/depot", "depotRemoteUrl" : "smb://depotserver/opsi_depot" } ]
Zur Änderung der Werte für den Key "maxBandwidth" würde dieser Aufruf eine Datei erzeugen, in der die max. Bandbreite auf allen Depotservern von "0" auf "100" geändert wird. An der Datei können auch händisch Änderungen vorgenommen werden.
opsi-admin -d method host_getObjects '[]' '{"type":"OpsiDepotserver"}' | sed -e 's/"maxBandwidth"\s:\s0/"maxBandwidth" : 100/' > /tmp/maxBand.json
Hiermit wird die geänderte Konfiguration in das Opsi-Backend übernommen:
opsi-admin -d method host_createObjects < /tmp/maxBand.json
Es gibt eine Reihe von speziellen Methoden. Einige davon werden nachfolgend vorgestellt.
Diese Methode liefert Informationen darüber, welchem Depot ein Client zugordnert ist.
Die Syntax ist:
method configState_getClientToDepotserver *depotIds *clientIds *masterOnly *productIds
Beispiel:
method configState_getClientToDepotserver [] "pcbon4.uib.local" [ { "depotId" : "bonifax.uib.local", "alternativeDepotIds" : [ ], "clientId" : "pcbon4.uib.local" } ]
Die hostControl-Methoden werden verwendet, um mit den Clients zu kommunizieren und diese zu steuern.
Seit opsi 4.0.3 empfehlen wird die Verwendung der hostControlSafe-Methoden.
Beide Varianten haben einen Parameter hostIds. Bei hostControl ist dieser optional - ohne Angabe werden die Aktionen gegen alle Clients durchgeführt.
Bei hostControlSafe ist der Parameter zwingend. Falls alle Clients angesprochen werden sollen, muss hier "*"
angegeben werden.
Bei Befehlen wie hostControl_reboot kann das Weglassen der Host-IDs zum versehentlichen Neustart aller Clients führen, weshalb in opsi 4.0.3 die Abwärtskompatibilität gebrochen wurde und bei den Befehlen hostControl_reboot und hostControl_shutdown das Weglassen des Parameters nun zu einem Fehler führt.
hostControlSafe_execute
command
auszuführen.command hostIds
hostControlSafe_fireEvent
event hostIds
hostControlSafe_getActiveSessions
hostIds
hostControlSafe_opsiclientdRpc
method
mit den gegebenen params
als Parameter aus.method *params hostIds
hostControlSafe_reachable
hostIds
hostControlSafe_reboot
hostIds
hostControlSafe_showPopup
message hostIds
hostControlSafe_shutdown
hostIds
hostControlSafe_start
hostIds
hostControlSafe_uptime
hostIds
Die folgenden Methoden drehen sich um die Arbeit mit Logs.
log_read
logType *objectId *maxSize
log_write
logType data *objectId *append
append
wird gesteuert, ob der neue Inhalt an ein eventuell bestehendes Logfile angehängt wird. Der Wert kann true
oder false
sein. Letzteres ist der Standard.
Sie arbeiten mit Gruppen-Objekten. Die Methoden beginnen also mit group.
Dann gibt es zwei Arten von Gruppen: Host-Gruppen und Produkt-Gruppen. Für die Treeview benötigen wir die erste Variante, das heißt beim Erstellen oder Abfragen muss type
auf HostGroup
gesetzt werden.
Das Erstellen von Hostgruppen ist vereinfacht durch die Methode group_createHostGroup
.
Die Parameter sind id
, description
(Beschreibung), notes
(Notizen) und parentGroupId
(ID der übergeordneten Gruppe). Davon ist nur die id zwingend zu vergeben und diese muss einzigartig sein.
In opsi 4.0 werden Gruppen anhand ihrer ID identifiziert. Diese ID muss gruppenübergreifend einzigartig sein.
Das Anlegen einer Gruppe ist so möglich:
opsi-admin -d method group_createHostGroup rechner_wenselowski "Nikos Rechner"
Wollen Sie die angelegte Gruppe anschauen, so können Sie mittels group_getObjects die Gruppen abfragen. Hier die Abfrage nach der soeben angelegten Gruppe:
opsi-admin -d method group_getObjects '' '{"id": "rechner_*", "type": "HostGroup"}'
Wollen Sie Untergruppen anlegen, so müssen Sie als parentGroupId die ID der übergeordneten Gruppe angeben. Hier als Beispiel eine Untergruppe zur gerade angelegten Gruppe:
opsi-admin -d method group_createHostGroup "rechner_wenselowski2" "Untergruppe" "" "rechner_wenselowski"
Die Abfrage von vorher sollte nun auch die neue Gruppe ausgeben.
Wenn Sie nun mit dem Directory arbeiten wollen, so wird dieses intern als Gruppe mit der ID clientdirectory behandelt. Clients dürfen im Directory immer nur in einer Gruppe sein - per Default sind sie der Gruppe mit der ID NICHT_ZUGEWIESEN zugewiesen. Verwenden Sie opsi in einer anderen Sprache, kann der Gruppenname abweichen. Dafür, dass die Clients immer in nur einer Gruppe sind, wenn sie im Directory sein sollen, muss vom jeweiligen Administrator gesorgt werden, da das Backend an dieser Stelle nicht eingreift.
Die Zuordnung von Clients zur Gruppe geschieht über objectToGroup-Objekte. Wir legen einen Client mit dem folgenden Befehl an:
opsi-admin -d method host_createOpsiClient "wenselowski-test.uib.local"
Diesen fügen wir der Untergruppe von vorhin hinzu:
opsi-admin -d method objectToGroup_create "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"
Um das zu überprüfen, können wir wie folgt die Zuordnung abfragen:
opsi-admin -d method objectToGroup_getObjects '' '{"groupType": "HostGroup", "groupId": "rechner_wenselowski2"}'
Um den Client aus der Gruppe zu entfernen, können Sie so vorgehen:
opsi-admin -d method objectToGroup_delete "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"
Um zu guter letzt eine Gruppe zu löschen, können Sie das wie folgt machen:
opsi-admin -d method group_delete "rechner_wenselowski"
Die mit opsi 3 eingeführten aktions orientierten Methoden stehen weiterhin zur Verfügung und werden weiter gepflegt. Diese Methodenwerden aber ab opsi 4.0 intern auf die objekt orientierten Methoden gemappt.
Hier eine Liste der Methoden (dargestellt in der Form des Aufrufs mit opsi-admin) mit einer kurzen Beschreibung. Diese dient zur Orientierung und nicht als Referenz. Das bedeutet die Beschreibung muss nicht alle Informationen enthalten, die Sie benötigen, um diese Methode tatsächlich zu verwenden.
method authenticated
Überprüfen, ob die Authentifizierung am Service erfolgreich war.
method createClient clientName domain
Erzeugt einen neuen Client.
method createGroup groupId members = [] description = ""
Erzeugt eine Gruppe von Clients, wie sie vom opsi-configed verwendet wird.
method createLicenseKey productId licenseKey
Weist dem Produkt productId einen (weiteren) Lizenzkey zu.
method createLocalBootProduct productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=('localBoot')
Legt ein neues Localboot-Produkt (Winst-Produkt) an.
method createNetBootProduct productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=('netboot')
Legt ein neues bootimage Produkt an.
method createProduct productType productId name productVersion packageVersion licenseRequired=0 setupScript="" uninstallScript="" updateScript="" alwaysScript="" onceScript="" priority=10 description="" advice="" productClassNames=""
Legt ein neues Produkt an.
method createProductDependency productId action requiredProductId="" requiredProductClassId="" requiredAction="" requiredInstallationStatus="" requirementType=""
Erstellt Produktabhängigkeiten.
method createProductPropertyDefinition productId name possibleValues=[]
Erstellt eine Produkteigenschaft.
method deleteClient clientId
Löscht einen Client.
method deleteGeneralConfig objectId
Löscht Konfiguration eines Clients oder einer Domain.
method deleteGroup groupId
Löscht eine Clientgruppe.
method deleteHardwareInformation hostId
Löscht sämtliche Hardwareinfos zum Rechner hostid.
method deleteLicenseKey productId licenseKey
Löscht einen Lizenzkey.
method deleteProduct productId
Löscht ein Produkt aus der Datenbasis.
method deleteProductDependency productId action requiredProductId="" requiredProductClassId="" requirementType=""
Löscht Produktabhängigkeit.
method deleteProductPropertyDefinition productId name method deleteProductPropertyDefinitions productId
Löscht alle Produkteigenschaften zum Produkt productid.
method deleteServer serverId
Löscht die Serverkonfiguration.
method exit
Verlässt den opsi-admin.
method getBackendInfos_listOfHashes
Liefert eine Beschreibung der auf dem opsi-server konfigurierten Backends und welche davon aktiviert sind.
method getClientIds_list
Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen.
method getClients_listOfHashes
Liefert die Liste der Clients, welche den angegebenen Kriterien entsprechen, zusammen mit Beschreibung, Notizen und Lastseen.
method getDomain hostId
Liefert die Domain zu einem Rechner.
method getGeneralConfig_hash objectId
Liefert allgemeine Konfiguration zu einem Client oder einer Domain.
method getGroupIds_list
Liefert die Liste der gespeicherten Clientgruppen.
method auditHardwareOnHost_getObjects '[]' '{"hostId":"<hostId>"}'
Liefert die Hardwareinformationen zu dem angegebenen Rechner.
method getHostId hostname
Liefert hostid zu dem angegebenen Hostnamen.
method getHost_hash hostId
Liste der Eigenschaften des angegebenen Rechners.
method getHostname hostId
Liefert hostname zur Host-ID.
method getInstallableLocalBootProductIds_list clientId
Liefert alle Localboot-Produkte, die auf diesem Client installiert werden können.
method getInstallableNetBootProductIds_list clientId
Liefert alle Netboot-Produkte, die auf diesem Client installiert werden können.
method getInstallableProductIds_list clientId
Liefert alle Produkte, die auf diesem Client installiert werden können.
method getInstalledLocalBootProductIds_list hostId
Liefert alle Localboot-Produkte, die auf diesem Client installiert sind.
method getInstalledNetBootProductIds_list hostId
Liefert die Liste der installierten Netboot-Produkte für einen Client oder Server.
method getInstalledProductIds_list hostId
Liefert die Liste der installierten Produkte für einen Client oder Server.
method getIpAddress hostId
Liefert IP-Adresse zur Host-ID.
method getLicenseKey productId clientId
Liefert einen freien Lizenzkey zu dem angegebenen Produkt bzw. liefert den der clientId zugeordneten Lizenzkey,
method getLicenseKeys_listOfHashes productId
Liefert eine Liste der Lizenzkeys für das angegebene Produkt.
method getLocalBootProductIds_list
Liefert alle bekannten Localboot-Produkte.
method getLocalBootProductStates_hash clientIds = []
Liefert für die angegebenen Clients Installationsstatus und Action-Requests für alle Localboot-Produkte.
method getMacAddresses_list hostId
Liefert die MAC-Adresse zum angegebenen Rechner.
method getNetBootProductIds_list
Liefert Liste der Netboot-Produkte.
method getNetBootProductStates_hash clientIds = []
Liefert für die angegebenen Clients Installationsstatus und {Action-request= für alle Netboot-Produkte.
method getNetworkConfig_hash objectId
Liefert die Netzwerk-spezifischen Konfigurationen für einen Client oder eine Domain.
method getOpsiHostKey hostId
Liefert den pckey zur angegeben Host-ID.
method getPcpatchPassword hostId
Liefert das mit dem pckey von hostId verschlüsselte Passwort des Users pcpatch.
method getPossibleMethods_listOfHashes
Liefert die Liste der aufrufbaren Methoden (in etwa so wie in diesem Kapitel beschrieben).
method getPossibleProductActionRequests_list
Liefert die Liste der in opsi prinzipiell zulässigen Action-Requests.
method getPossibleProductActions_hash
Liefert zu allen Produkten die möglichen Aktionen (setup, deinstall,… ).
method getPossibleProductActions_list productId=softprod
Liefert zum angegebenen Produkt die möglichen Aktionen (setup, deinstall,…).
method getPossibleProductInstallationStatus_list
Liefert die möglichen Installationsstatus (installed, not_installed,… ).
method getPossibleRequirementTypes_list
Liefert die möglichen Typen von Produktabhängigkeiten (before, after, … ).
method getProductActionRequests_listOfHashes clientId
Liefert die anstehenden ausführbaren Aktionen für den angegebenen Client.
method getProductDependencies_listOfHashes
Liefert die bekannten Produktabhängigkeiten (zum angegebenen Produkt).
method getProductIds_list
Liefert die Liste der Produkte, die den angegebenen Kriterien entsprechen.
method getProductInstallationStatus_hash productId hostId
Liefert den Installationsstatus zum angegebenen Client und Produkt.
method getProductInstallationStatus_listOfHashes hostId
Liefert den Installationsstatus zum angegebenen Client.
method getProductProperties_hash productId
Liefert die Schalterstellungen (Product-Properties) zum angegebenen Produkt und Client.
method getProductPropertyDefinitions_hash
Liefert alle bekannten Product-Properties mit Beschreibung, erlaubten Werten etc..
method getProductPropertyDefinitions_listOfHashes productId
Liefert die Product-Properties zum angegebenen Produkt mit Beschreibung, erlaubten Werten etc..
method getProductStates_hash clientIds = []
Liefert Installationsstatus und Action-Requests der einzelnen Produkte (zu den agegebenen Clients).
method getProduct_hash productId
Liefert die Metadaten (Beschreibung, Version,…) zum angegebenen Produkt.
method getProvidedLocalBootProductIds_list serverId
Liefert die Liste der auf dem angegebenen Server bereitgestellten Localboot-Produkte.
method getProvidedNetBootProductIds_list serverId
Liefert die Liste der auf dem angegebenen Server bereitgestellten Netboot-Produkte.
method getServerId clientId
Liefert den zuständigen opsi-configserver zum angegebenen Client.
method getServerIds_list
Liefert die Liste der bekannten opsi-configserver.
method powerOnHost mac
Sendet ein WakeOnLan-Signal an die angegebene MAC.
method setGeneralConfig config
Setzt für Client oder Domain die GenaralConfig.
method setHostDescription hostId description
Setzt für einen Client die Beschreibung.
method setHostLastSeen hostId timestamp
Setzt für einen Client den Zeitstempel für LastSeen.
method setHostNotes hostId notes
Setzt für einen Client die Notiz-Angaben.
method setMacAddresses hostId macs
Trägt für einen Client seine MAC-Adresse in die Datenbank ein.
method setOpsiHostKey hostId opsiHostKey
Setzt für einen Rechner den pckey.
method setPcpatchPassword hostId password
Setzt das verschlüsselte (!) password für hostId.
method setProductActionRequest productId clientId actionRequest
Setzt für den angegebenen Client und das angegebene Produkt einen Action-Request.
method setProductInstallationStatus productId hostId installationStatus policyId="" licenseKey=""
Setzt für den angegebenen Client und das angegebene Produkt einen Installationsstatus.
method setProductProperties productId properties
Setzt Product-Properties für das angegebene Produkt (und den angegebenen Client).
method unsetProductActionRequest productId clientId
Setzt einen Action-Request auf none.
Durch die in opsi 4 implementierten Funktionalität des Backend-Extenders können auf der Basis der opsi4-API-Methoden oder des Funktionskerns jederzeit zusätzliche Methoden definiert und als API-Erweiterung aufrufbar gemacht werden.
Das Standard-API-Methoden-Set wird durch den opsiconfd mittels
Überlagerung der in den .conf
-Dateien in /etc/opsi/backendManager/extend.d definierten Methoden erstellt.
Backend-Erweiterungen können dazu dienen für spezifische Konfigurationsaufgaben angepasste Zusatzfunktionen zu implementieren.
Erweiterungen werden in der Programmiersprache Python geschrieben. Sie werden an den BackendManager geladen, so dass dieser mittels `self referenziert werden kann.
Die API nutzt JSON-RPC 1.0 über HTTP zur Kommunikation. Es wird basic authentication verwendet.
Um die Schnittstelle zu verwenden, müssen Aufrufe per POST zum Pfad
rpc
am opsi-Server gesendet werden, bspw. https://opsiserver.domain.local:4447/rpc
.
Wie jedes andere System auch, sollte das opsi-System auch einem Backup unterzogen werden. Da opsi ein zentrales Werkzeug für das Windows-Client- wie auch das Windows-Server-Management darstellt, sollte der opsi-server gesichert werden. Dieses Handbuch soll einen Einblick in die Backup-Strategie von opsi geben und auch auf Themen, wie das zurückschreiben und das "DisasterRecovery" von opsi.
Um ein Backup des opsi-Systems anzulegen, gibt es nicht wirklich eine Vorbedingung. Wenn man die zentralen Dateien und Backends des opsi-Systems lokalisiert hat, kann man diese auf diversen Methoden sichern. Die folgende Anleitung soll nicht nur die Frage: "Was soll gesichert werden?" beantworten, sondern auch einen Weg dokumentieren, wie eine Backupstrategie für das opsi-System aussehen könnte.
Das Backupskript sollte als root ausgeführt werden, entweder manuell oder einen root-cronjob, damit man die Konfiguration von opsi lesen kann und auch die Systemkonfiguration feststellen kann. Weiterhin sollte für ein Backup des mysql-Backends das mysqldump-Programm installiert sein, dieses findet sich in der Regel in den client-Paketen von mysql.
Backup erzeugen:
opsi-backup create opsi_backup.tar.bz2
Erzeugt ein Backup der aktuell genutzten Backends sowie der Konfigurationsdateien im aktuellen Verzeichnis mit dem Namen opsi_backup.tar.bz2
.
Backend-Daten (ohne Konfigurationsdateien) zurückspielen:
opsi-backup restore opsi_backup.tar.bz2
Stellt die Daten aus dem Backupfile opsi_backup.tar.bz2
aus dem aktuellen Verzeichnis wieder her.
Komplettes Backup inklusive Konfigurationsdateien zurück spielen:
opsi-backup restore --backends=all --configuration opsi_backup.tar.bz2
Opsi kann man grob in fünf Teile gliedern. Die folgenden fünf Teile sind opsi spezifisch und können von System zu System, je nach Konfiguration variieren.
Der mit Abstand wichtigste Teil von opsi, ist die Konfiguration. Getreu nach LSB (Linux Standard Base) befindet sich die Konfiguration von opsi unter /etc/opsi
.
Dieses Verzeichnis beinhaltet hauptsächlich die Backend-Konfiguration, die Webservice-Konfiguration und das SSL-Zertifikat für den Webservice. Weiterhin sind hier Backend-Erweiterungen untergebracht, die Konfigurationen des opsipxeconfd, des opsi-package-updater mit seinen Repositories und auch die modules-Datei, die Ihnen Ihre kofinanzierten Module freischaltet.
Um später eine volle Wiederherstellung nach einem Unglück zu verwirklichen, muss das Verzeichnis /etc/opsi
gesichert werden.
Dieser Bereich wird mit opsi-backup
gesichert.
Die Sicherung hat daneben noch einen weiteren Vorteil:
Wenn man viele Konfigurationen von opsi geändert hat und das System nicht mehr richtig arbeitet, ist ein Rücksprung auf eine vorherige funktionierende Version meist leichter und schneller, als die Fehlersuche.
Im folgenden Kapitel werden die Backends von opsi aufgezählt. Diese bilden das Herzstück der opsi-Datenhaltung. Alle Clients, Produkte, Konfigurationen, Statis, etc… sind in der jeweiligen Datenhaltung abgelegt.
Opsi bietet folgende Datenbackends:
Tabelle 5.1. opsi-Backends
Backend | Beschreibung |
---|---|
file-Backend | Backend auf Dateibasis, momentan der default bei opsi |
mysql-Backend | MySQL-basiertes Backend (seit opsi 4.0) |
dhcp | spezial Backend bei Verwendung von des dhcpd auf dem opsi-server |
Wenn Sie nicht wissen, welches Backend sie einsetzen, setzen Sie wahrscheinlich das file-Backend ein. opsi ist aber auch dafür ausgelegt, mehrere Backends gleichzeitig einzusetzen. Welche Backends, für welche Funktionen von opsi eingesetzt werden, wird in der /etc/opsi/backendManager/dispatch.conf
konfiguriert.
Dieser Bereich wird mit opsi-backup
gesichert.
Die Depotfiles sind deshalb interessant, da Sie die eigentlichen Dateien der zu verteilenden Software enthalten. Die Localboot-Produkte, wie auch die Netboot-Produkte haben Ihre Files jeweils unterhalb von /var/lib/opsi/depot
. In früheren Versionen von opsi waren diese im Verzeichnis /opt/pcbin/install
angesiedelt.
Je nachdem, wie viel Software auf dem opsi-server vorgehalten wird und wie viele Betriebssystem-Installationen inklusive Treibern vorgehalten werden, kann dieses Datenvolumen enorme Ausmaße annehmen.
Es gibt verschiedene Ansätze diese Dateien zu sichern. Die einfachste Alternative ist das Rsnapshot. Es gibt aber elegantere Lösungen, wie das Verlegen dieser Daten in redundant ausgelegte Filesysteme auf einem SAN, etc.
Dieser Bereich wird mit opsi-backup
nicht gesichert.
Der Bereich opsi Workbench, welcher auch als gleichnamige Samba-Freigabe (opsi_workbench) in opsi eingesetzt wird, beinhaltet die Stände der eigenen Software-Paketierung. Das Verzeichnis ist standardmäßig unter /var/lib/opsi/workbench
. Wenn dieser Share, wie vorgesehen dafür verwendet wird, um eigene Pakete in verschiedenen Revisionen dort vor zu halten, sollte dieses Verzeichnis auch gesichert werden.
Auch hier bietet sich das Tool rsnapshot an.
Dieser Bereich wird mit opsi-backup
nicht gesichert.
Seit opsi 4.1 kann dieses Verzeichnis für jeden Depotserver einzeln konfiguriert werden, so dass abweichende Pfade möglich sind.
Vor opsi 4.1 war dieses Verzeichnis auf non-SLES-Systemen unter /home/opsiproducts
zu finden.
Das Verzeichnis unter /var/lib/opsi/repository
wird dazu verwendet, um opsi-Pakete zu puffern. Anders als die opsi Workbench, dient es aber nicht dem Paketieren von opsi Paketen, sondern die opsi Pakete welche dort abgelegt werden, sollen vorgehalten werden, um eventuell das Synchronisieren auf anderen Servern, oder das Synchronisieren mit dem opsi-package-updater
zu vereinfachen.
Diese Dateien sind für ein vollständige Wiederherstellung nicht unbedingt nötig, können aber auch mit dem Tool rsnapshot gesichert werden.
Dieser Bereich wird mit opsi-backup
nicht gesichert.
Das TFTP-Verzeichnis beinhaltet Konfigurationsdateien für den Bootvorgang per PXE.
Diese Verzeichnis befindet sich unter /tftpboot/
auf den meisten Systemen. Auf SLES ist dieses Verzeichnis /var/lib/tftpboot/opsi/
.
Möglicherweise angepasste Dateien sind bspw. linux/pxelinux.cfg/default.menu
bzw. linux/pxelinux.cfg/default.nomenu
.
Diese Dateien werden bei der Installation von opsi-linux-bootimage mit Defaultwerten angelegt. Für ein Disaster Recovery sind diese nicht zwingend nötig.
Dieser Bereich wird mit opsi-backup
nicht gesichert.
Mit dem Kommandozeilenprogramm opsi-backup
existiert ein Werkzeug, welches die Erstellung und das Wiederherstellen einfacher Backups komfortabel erledigt.
Dazu lässt sich opsi-backup
mit drei grundlegenden Befehlen steuern: create
, restore
und verify
.
Die Option --help
gibt einen detaillierten Überblick über alle Optionen, die opsi-backup
akzeptiert.
Ein mit opsi-backup
erstelltes Backup ist ein Rohbackup, dass bedeutet, es werden keine Datein auf logischer Ebene gesichert, sondern es werden Sicherungen der in den Backends abgelegten Datein in den entsprechenden Strukturen angefertigt.
Ein solches Backup lässt sich daher auch nur für eine identische Backendkonfiguration zurückspielen.
Ein mit opsi-backup
erstelltes Backup ist immer ein Vollbackup (opsi-backup
unterstützt keine incrementellen oder differenziellen Backups).
Zu beachten ist, dass opsi-backup
keine Sicherung der Depot Dateien, der Workbench Dateien sowie der Repository Dateien durchführt. Diese Datein sollten daher anderweitig gesichert werden.
Der mit opsi-backup
erstellte backup file ist eine komprimierte tar Datei, deren Inhalt sich entsprechend auch anschauen lässt.
opsi-backup --help
Ein Backup, dass mit opsi-backup
erstellt wird, kann unter anderem Passwörter und PC-Keys enthalten, und sollte daher entsprechend sicher archiviert werden.
Das Anlegen eines neuen opsi Backups erfolgt mit dem Befehl opsi-backup create
. Wird dieser Befehl ohne weitere Parameter angegeben erstellt das Programm ein Archiv mit allen Daten der Backends sowie der Konfiguration. Der Dateiname wird dabei automatisch generiert.
Für den Befehl opsi-backup create
sind zusätzliche Programmhilfen verfügbar, welche über die Option --help
ausgegeben werden.
opsi-backup create opsi-backup create --help
Es ist auch möglich, den Dateinamen oder das Zielverzeichnis des neuen Backups vorzugeben. Dazu wird einfach ein Dateiname oder ein Zielverzeichnis einfach an den entsprechenden Befehl angehängt. Wird ein Verzeichnis übergeben, generiert opsi-backup
automatisch einen Dateinamen in diesem Verzeichnis.
Ein durch opsi-backup
generierter Dateiname hat die Form <hostname>_<opsi-version>_<datum>_<uhrzeit>
und ist daher gut zur Archivierung meherere Backups geeignet. Wird ein Dateiname fest vorgegeben, so wird ein älteres Backup mit dem selben Namen durch opsi-backup
überschrieben.
opsi-backup create /mnt/backup/opsi_backup.tar.bz2 opsi-backup create /mnt/backup/
Zusätzlich ermöglicht das create
Kommando die Steuerung des Backups mittels der folgenden Optionen:
--backends {file,mysql,dhcp,all,auto}
Ermöglicht die Auswahl der Backends, die in dem Backup eingeschlossen werden sollen. Diese Option kann mehrfach angegeben werden, um mehrere Backends anzugeben. Die Option --backends=all
steht für alle Backends.
Die Voreinstellung (default) für diese Optionen ist --backends=auto
, was dafür sorgt, dass opsi-backup
versucht, die verwendeten Backends anhand der Konfigurationsdatei /etc/opsi/backendManager/dispatch.conf
zu ermitteln.
Im Moment werden folgende Backends unterstützt: mysql
, file
, dhcp
opsi-backup create --backends=file --backends=mysql opsi-backup create --backends=all
Wenn Sie ein nicht unterstütztes Backend (wie z.B. ldap) verwenden, so können Sie vor dem Backup dieses mit dem Befehl opsi-convert
in ein Backend konvertieren, dass sich per opsi-backup
sichern lässt.
--no-configuration
Schließt die Opsi Konfiguration aus dem Backup aus.
opsi-backup create --no-configuration
-c [{gz,bz2,none}], --compression [{gz,bz2,none}]
Spezifiziert die Kompressionsmethode, mit der das Archiv komprimiert werden soll. none
steht hier für nicht komprimieren, die Standardkompression (default) ist bz2
.
opsi-backup create -c bz2
--flush-logs
Die Sicherung des mysql-Backends erfolgt intern über einen mysqldump Befehl. Das bedeutet, dass die Daten genauso gesichert werden, wie die Datenbank sie zu diesem Zeitpunkt sieht (unabhängig davon ob die Daten schon auf Platte stehen oder nur im Speicher). Somit ist das erstellte Backup evtl. aktueller und unterscheidet sich vom Stand der Datenbankdateien. Möchte man dies vermeiden, so müssen die von mysql im Speicher gehaltenen Daten vorher auf die Festplatte geschrieben werden.
Ist die Option --flush-logs
angegeben, wird opsi-backup
versuchen, diese Operation durchzuführen (also die Daten aus dem Speicher auf die Platten zuschreiben). Allerdings benötigt der entsprechende Datenbankuser der opsi Datenbank dazu die entsprechende MySQL Berechtigung RELOAD. Standardmäßig wird der opsi Benutzer aber ohne dieses Recht angelegt!
Besitzt er diese nicht (und die Option --flush-logs
ist angegeben) wird das Backup fehlschlagen. Verwenden Sie daher diese Option nur, wenn Sie vorher die Rechte des Datenbankusers angepasst haben.
opsi-backup create --backends=mysql --flush-logs
Beispiel
opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2
Von Haus aus bringt opsi-backup
keine Funktionen zum Archivieren von Backups mit. Der Administrator hat daher Sorge zu tragen, dass erzeugte Backups sicher und versioniert ablegt werden.
Außerdem löscht opsi-backup
niemals selbstständig ältere Backup Version (außer sie werden mittels create
überschrieben). Da opsi-backup
immer Vollbackups und keine inkrementellen Backups anlegt, kann es schnell zu großen Datenmengen kommen.
Hier muss ebenfalls der Administrator Sorge tragen, dass ältere Backups wenn nötig regelmäßig gelöscht werden.
Mit dem Befehl opsi-backup verify
kann das Archiv auf interne Integrität geprüft werden. Diese Prüfung ist keine logische Prüfung der Daten, es handelt sich um eine reine Prüfung auf die Korrektheit der im Archiv gespeicherten Daten.
Für den Befehl opsi-backup verify
sind zusätzliche Programmhilfen verfügbar, welche über die Option --help
ausgegeben werden.
Beispiel
opsi-backup verify opsi_backup.tar.bz2 opsi-backup verify --help
Wird der Befehl opsi-backup verify
explizit auf der Konsole aufgerufen ist es häufig sinnvoll, die opsi-backup
Standardausgabe zu aktivieren: opsi-backup -v verify opsi_backup.tar.bz2
Mit dem Befehl opsi-backup list
wird angezeigt welche Daten ein Backup enthält.
Aufgelistet wird, ob Konfigurationsdaten vorhanden sind und Daten aus welchen Backends.
Beispiel
opsi-backup list opsi_backup.tar.bz2
Das Wiederherstellen des Archivs erfolgt mit dem Befehl opsi-backup restore
. Dabei werden (per default) die Backends anhand der aktuellen Konfiguration eingespielt. Es kann also kein reines Backend Backup wiederhergestellt werden, ohne dass eine opsi Konfiguration vorhanden ist.
Der Befehl opsi-backup restore
braucht als Parameter das Backup Archiv, aus dem Daten wiederhergestellt werden.
Für den Befehl opsi-backup restore
sind zusätzliche Programmhilfen verfügbar, welche über die Option --help
ausgegeben werden.
opsi-backup restore
akzeptiert folgende Optionen:
--backends {file,mysql,dhcp,auto,all}
Stellt das spezifizierte Backend wieder her. Diese Option kann mehrfach angegeben werden, um mehrere Backends anzugeben. Die Option --backends=all
steht für alle Backends.
Als Voreinstellung (default) wird die Option --backends=auto
verwendet, was dazu führt, dass opsi-backup
versucht, anhand der Konfigurationsdatei /etc/opsi/backendManager/dispatch.conf
festzustellen, welche Backends wiederherzustellen sind.
opsi-backup restore --backends=file --backends=mysql opsi_backup.tar.bz2 opsi-backup restore --backends=all opsi_backup.tar.bz2
Wenn Sie seit der Erstellung des Backups das Backend gewechselt haben, so wird die default Einstellung keine Daten zurück sichern.
--configuration
Stellt die Opsi Konfiguration wieder her. Diese Option ist beim restore
Vorgang kein default.
opsi-backup restore --configuration opsi_backup.tar.bz2
-f, --force
opsi-backup
führt vor dem Wiederherstellen eines Backups, eine Sicherheitsprüfung durch, um zu überprüfen, ob die aktuelle opsi Installation mit der Installation des Backups übereinstimmt (opsi Version, OS-Version, Host- und Domain Name). Mit dieser Option lässt sich diese Prüfung umgehen.
opsi-backup restore -f opsi_backup.tar.bz2
Beispiel
opsi-backup restore --configuration --backends=all opsi_backup.tar.bz2
Wird ein Backup auf einen Server zurückgespielt und es existiert kein Backup des Depot-Ordners, so gibt es die Möglichkeit mit opsi-package-updater
und opsi-package-manager
alle Pakete aus dem Repository erneut herunterzuladen und einzuspielen.
Eventuell vorgenommene Änderungen im Depot müssen anschließend allerdings wieder durchgeführt werden.
opsi-package-updater download --force opsi-package-manager --install /var/lib/opsi/repository/*.opsi
Bei Verwendung des file-Backends liegen die Konfigurationsinformationen in Ini-Dateien auf dem Server.
Wesentliche Merkmale des Backends file:
/var/lib/opsi/config
.
Inhalt und Aufbau dieser Dateien ist im Kapitel Abschnitt 5.7.4, „Dateien des file Backends“ näher erläutert.
Die Daten der Hardware- und Softwareinventarisierung werden per default über das opsi file-Backend in Textdateien abgelegt. Diese Form der Ablage ist für freie Abfragen und Reports weniger geeignet. Hierfür bietet sich die Ablage der Daten in einer SQL-Datenbank an.
Wesentliche Merkmale des Backends mysql:
Bedingt durch die sehr unterschiedliche Natur der zu inventarisierenden Hardwarekomponenten ist die Datenstruktur in etwa wie folgt aufgebaut:
Für jeden Device-Typ gibt es zwei Tabellen:
Ähnlich sieht es für die Softwareinventarisierung aus. Auch hier beschreibt die Tabelle Software die insgesamt gefundene Software während die Tabelle Software_Config die Client spezifische Konfiguration speichert.
Daraus ergibt sich folgende Liste von Tabellen:
HARDWARE_CONFIG_1394_CONTROLLER HARDWARE_CONFIG_AUDIO_CONTROLLER HARDWARE_CONFIG_BASE_BOARD HARDWARE_CONFIG_BIOS HARDWARE_CONFIG_CACHE_MEMORY HARDWARE_CONFIG_COMPUTER_SYSTEM HARDWARE_CONFIG_DISK_PARTITION HARDWARE_CONFIG_FLOPPY_CONTROLLER HARDWARE_CONFIG_FLOPPY_DRIVE HARDWARE_CONFIG_HARDDISK_DRIVE HARDWARE_CONFIG_IDE_CONTROLLER HARDWARE_CONFIG_KEYBOARD HARDWARE_CONFIG_MEMORY_BANK HARDWARE_CONFIG_MEMORY_MODULE HARDWARE_CONFIG_MONITOR HARDWARE_CONFIG_NETWORK_CONTROLLER HARDWARE_CONFIG_OPTICAL_DRIVE HARDWARE_CONFIG_PCI_DEVICE HARDWARE_CONFIG_PCMCIA_CONTROLLER HARDWARE_CONFIG_POINTING_DEVICE HARDWARE_CONFIG_PORT_CONNECTOR HARDWARE_CONFIG_PRINTER HARDWARE_CONFIG_PROCESSOR HARDWARE_CONFIG_SCSI_CONTROLLER HARDWARE_CONFIG_SYSTEM_SLOT HARDWARE_CONFIG_TAPE_DRIVE HARDWARE_CONFIG_USB_CONTROLLER HARDWARE_CONFIG_VIDEO_CONTROLLER HARDWARE_DEVICE_1394_CONTROLLER HARDWARE_DEVICE_AUDIO_CONTROLLER HARDWARE_DEVICE_BASE_BOARD HARDWARE_DEVICE_BIOS HARDWARE_DEVICE_CACHE_MEMORY HARDWARE_DEVICE_COMPUTER_SYSTEM HARDWARE_DEVICE_DISK_PARTITION HARDWARE_DEVICE_FLOPPY_CONTROLLER HARDWARE_DEVICE_FLOPPY_DRIVE HARDWARE_DEVICE_HARDDISK_DRIVE HARDWARE_DEVICE_IDE_CONTROLLER HARDWARE_DEVICE_KEYBOARD HARDWARE_DEVICE_MEMORY_BANK HARDWARE_DEVICE_MEMORY_MODULE HARDWARE_DEVICE_MONITOR HARDWARE_DEVICE_NETWORK_CONTROLLER HARDWARE_DEVICE_OPTICAL_DRIVE HARDWARE_DEVICE_PCI_DEVICE HARDWARE_DEVICE_PCMCIA_CONTROLLER HARDWARE_DEVICE_POINTING_DEVICE HARDWARE_DEVICE_PORT_CONNECTOR HARDWARE_DEVICE_PRINTER HARDWARE_DEVICE_PROCESSOR HARDWARE_DEVICE_SCSI_CONTROLLER HARDWARE_DEVICE_SYSTEM_SLOT HARDWARE_DEVICE_TAPE_DRIVE HARDWARE_DEVICE_USB_CONTROLLER HARDWARE_DEVICE_VIDEO_CONTROLLER HOST SOFTWARE SOFTWARE_CONFIG
Die Zuordnung der Spaltennamen zu einzelnen Deviceklassen ergibt sich aus folgender Liste (/etc/opsi/hwaudit/locales/de_DE
):
DEVICE_ID.deviceType = Gerätetyp DEVICE_ID.vendorId = Hersteller-ID DEVICE_ID.deviceId = Geräte-ID DEVICE_ID.subsystemVendorId = Subsystem-Hersteller-ID DEVICE_ID.subsystemDeviceId = Subsystem-Geräte-ID DEVICE_ID.revision= Revision BASIC_INFO.name = Name BASIC_INFO.description = Beschreibung HARDWARE_DEVICE.vendor = Hersteller HARDWARE_DEVICE.model = Modell HARDWARE_DEVICE.serialNumber = Seriennummer COMPUTER_SYSTEM = Computer COMPUTER_SYSTEM.sku = Artikelnummer COMPUTER_SYSTEM.systemType = Typ COMPUTER_SYSTEM.totalPhysicalMemory = Arbeitsspeicher COMPUTER_SYSTEM.dellexpresscode = Dell Expresscode CHASSIS = Chassis CHASSIS.name = Name CHASSIS.chassisType = Chassis-Typ CHASSIS.installDate = Installations-Datum CHASSIS.serialNumber = Seriennummer BASE_BOARD = Hauptplatine BASE_BOARD.product = Produkt BIOS = BIOS BIOS.version = Version SYSTEM_SLOT = System-Steckplatz SYSTEM_SLOT.currentUsage = Verwendung SYSTEM_SLOT.status = Status SYSTEM_SLOT.maxDataWidth = Max. Busbreite PORT_CONNECTOR = Port PORT_CONNECTOR.connectorType = Attribute PORT_CONNECTOR.internalDesignator = Interne Bezeichnung PORT_CONNECTOR.internalConnectorType = Interner Typ PORT_CONNECTOR.externalDesignator = Externe Bezeichnung PORT_CONNECTOR.externalConnectorType = Externer Typ PROCESSOR = Prozessor PROCESSOR.architecture = Architektur PROCESSOR.family = Familie PROCESSOR.currentClockSpeed = Momentane Taktung PROCESSOR.maxClockSpeed = Maximale Taktung PROCESSOR.extClock = Externe Taktung PROCESSOR.processorId = Prozessor-ID PROCESSOR.addressWidth = Adress-Bits PROCESSOR.socketDesignation = Zugehöriger Sockel PROCESSOR.voltage = Spannung PROCESSOR.NumberOfCores = Anzahl Kerne PROCESSOR.NumberOfLogicalCores = Anzahl logischer Kerne MEMORY_BANK = Speicher-Bank MEMORY_BANK.location = Position MEMORY_BANK.maxCapacity = Maximale Kapazität MEMORY_BANK.slots = Steckplätze MEMORY_MODULE = Speicher-Modul MEMORY_MODULE.deviceLocator = Zugehöriger Sockel MEMORY_MODULE.capacity = Kapazität MEMORY_MODULE.formFactor = Bauart MEMORY_MODULE.speed = Taktung MEMORY_MODULE.memoryType = Speichertyp MEMORY_MODULE.dataWidth = Datenbreite MEMORY_MODULE.tag = Bezeichnung CACHE_MEMORY = Zwischenspeicher CACHE_MEMORY.installedSize = Installierte Größe CACHE_MEMORY.maxSize = Maximale Größe CACHE_MEMORY.location = Position CACHE_MEMORY.level = Level PCI_DEVICE = PCI-Gerät PCI_DEVICE.busId = Bus-ID NETWORK_CONTROLLER = Netzwerkkarte NETWORK_CONTROLLER.adapterType = Adapter-Typ NETWORK_CONTROLLER.maxSpeed = Maximale Geschwindigkeit NETWORK_CONTROLLER.macAddress = MAC-Adresse NETWORK_CONTROLLER.netConnectionStatus = Verbindungsstatus NETWORK_CONTROLLER.autoSense = auto-sense NETWORK_CONTROLLER.ipEnabled = IP-Protokoll aktiviert NETWORK_CONTROLLER.ipAddress = IP-Adresse AUDIO_CONTROLLER = Audiokarte HDAUDIO_DEVICE = HD-Audio Gerät HDAUDIO_DEVICE.address = Adresse IDE_CONTROLLER = IDE-Controller SCSI_CONTROLLER = SCSI-Controller FLOPPY_CONTROLLER = Floppy-Controller USB_CONTROLLER = USB-Controller 1394_CONTROLLER = 1394-Controller PCMCIA_CONTROLLER = PCMCIA-Controller VIDEO_CONTROLLER = Grafikkarte VIDEO_CONTROLLER.videoProcessor = Video-Prozessor VIDEO_CONTROLLER.adapterRAM = Video-Speicher DRIVE.size = Größe FLOPPY_DRIVE = Floppylaufwerk TAPE_DRIVE = Bandlaufwerk HARDDISK_DRIVE = Festplatte HARDDISK_DRIVE.cylinders = Cylinder HARDDISK_DRIVE.heads = Heads HARDDISK_DRIVE.sectors = Sektoren HARDDISK_DRIVE.partitions = Partitionen DISK_PARTITION = Partition DISK_PARTITION.size = Größe DISK_PARTITION.startingOffset = Start-Offset DISK_PARTITION.index = Index DISK_PARTITION.filesystem = Dateisystem DISK_PARTITION.freeSpace = Freier Speicher DISK_PARTITION.driveLetter = Laufwerksbuchstabe OPTICAL_DRIVE = Optisches Laufwerk OPTICAL_DRIVE.driveLetter = Laufwerksbuchstabe USB_DEVICE = USB-Gerät USB_DEVICE.vendorId = Hersteller-ID USB_DEVICE.deviceId = Geräte-ID USB_DEVICE.usbRelease = USB-Version USB_DEVICE.maxPower = Maximale Stromaufnahme USB_DEVICE.interfaceClass = Schnittstellen-Klasse USB_DEVICE.interfaceSubClass = Schnittstellen-Unterklasse USB_DEVICE.interfaceProtocol = Schnittstellen-Protokoll USB_DEVICE.status = Status MONITOR = Monitor MONITOR.screenHeight = Vertikale Auflösung MONITOR.screenWidth = Horizontale Auflösung KEYBOARD = Tastatur KEYBOARD.numberOfFunctionKeys = Anzahl Funktionstasten POINTING_DEVICE = Zeigegerät POINTING_DEVICE.numberOfButtons = Anzahl der Tasten PRINTER = Drucker PRINTER.horizontalResolution = Vertikale Auflösung PRINTER.verticalResolution = Horizontale Auflösung PRINTER.capabilities = Fähigkeiten PRINTER.paperSizesSupported = Unterstützte Papierformate PRINTER.driverName = Name des Treibers PRINTER.port = Anschluss
Beispiele für Abfragen: Liste aller Festplatten:
SELECT * FROM HARDWARE_DEVICE_HARDDISK_DRIVE D LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE H ON D.hardware_id=H.hardware_id ;
Die Softwareinventarisierung verwendet als Hauptschlüssel die folgenden Felder:
In der Tabelle Software_config sind diese Felder zum Feld config_id zusammengefasst.
Das mysql-Backend für Konfigurationsdaten steht seit opsi 4.0 zur Verfügung.
Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung. Das bedeutet die Verwendung ist nicht kostenlos.
Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Das mysql-Backend hat den Vorteil der höheren Performanz insbesondere bei großen Installationen.
Hier eine Übersicht über die Datenstruktur:
Wenn der mysql-server noch nicht installiert ist, muss dies zunächst erfolgen mit:
apt install mysql-server
Danach muss für der root Zugang von mysql ein Passwort gesetzt werden:
mysqladmin --user=root password linux123
MySQL-Server verwendet seit Version 5.7 den vorher optionalen strict mode nun standardmäßig. Dies führt zu einem Fehlschlag des Befehls opsi-setup --configure-mysql
. Dementsprechend sollte vor dem Befehlsaufruf die Datei /etc/mysql/mysql.conf.d/mysqld.cnf
editiert werden.
In der [mysqld]
Sektion muss nun folgende Zeile eingefügt werden:
sql_mode=NO_ENGINE_SUBSTITUTION
Danach muss der Dienst mysql
neu gestartet werden: systemctl restart mysql.service
Es ist nun möglich fort zu fahren.
Mit dem Befehl opsi-setup --configure-mysql
kann nun die Datenbank aufgebaut werden.
Eine Beispiel-Sitzung:
Bei den Abfragen können außer beim Passwort alle Vorgaben mit Enter bestätigt werden.
Als nächstes muss in der /etc/opsi/backendManager/dispatch.conf
eingetragen werden, dass das mysql-Backend auch verwendet werden soll. Eine genaue Beschreibung zu dieser Konfiguration finden Sie im Kapitel Backend-Konfiguration des getting-started Handbuchs. Die Datei selbst enthält eine Reihe von Beispielen typischer Konfigurationen.
Eine Konfiguration für das mysql-Backend (ohne internen dhcpd) sieht so aus:
backend_.* : mysql, opsipxeconfd host_.* : mysql, opsipxeconfd productOnClient_.* : mysql, opsipxeconfd configState_.* : mysql, opsipxeconfd .* : mysql
Nach Abschluss dieser Konfigurationsarbeit müssen Sie durch den folgenden Befehlen die Benutzung des jetzt konfigurierten und konvertierten Backend aktivieren:
opsi-setup --init-current-config opsi-setup --set-rights systemctl restart opsiconfd.service systemctl restart opsipxeconfd.service
Der Dienst opsiconfd hat per Default keine feste Abhängigkeit zu MySQL, da opsi einerseits ohne MySQL-Backend auskommt, andererseits der Dienst auch auf einem anderen Server starten kann. Bitte entnehmen Sie der Dokumentation Ihres Betriebssystems wie eine solche Konfiguration gemacht wird.
Manuelle Konfiguration kann über die Backend-Konfigurations-Datei erfolgen.
Diese ist standardmäßig /etc/opsi/backends/mysql.conf
.
Seit python-opsi 4.1.1.76 ist es möglich die Erstellung neuer Verbindungen nach einer bestimmten Zeit zu forcieren, um Probleme mit Timeouts zu vermeiden. Ein Indikator für solche Timeouts kann die Meldung mysql server has gone away sein.
Sie können einen Timeout setzen, indem Sie für connectionPoolRecycling angeben nach wievielen Sekunden eine neue Verbindung erstellt werden soll.
Der Standardwert ist -1
, welcher keine erzwungene Neu-Erstellung von Verbindungen bedeutet.
Wird diesert Wert gesetzt, sollte er in der Regel niedriger als der auf dem Server konfigurierte Wert für Verbindungs-Timeouts (wait_timeout) sein.
Die vorliegende Datenbank muss so konfiguriert werden, dass ein Zugriff von außen möglich ist, also nicht nur Verbindungen von localhost akzeptiert werden.
Bitte informieren Sie sich um Handbuch der von Ihnen verwendeten Datenbank über die nötigen Schritte.
Das HostControl-Backend speichert keine Konfigurationsdaten, sondern dient der Steuerung von opsi-Clients. Hierzu gehören beispielsweise das Starten von Clients per Wake-On-LAN oder das Senden von Steuerungsbefehlen an den opsi-client-agent.
Die Konfiguration des HostControl-Backends wird in der Konfigurationsdatei /etc/opsi/backends/hostcontrol.conf
vorgenommen. Konfigurations-Optionen sind hierbei:
opsiclientdPort
:hostRpcTimeout
:resolveHostAddress
:True
, wird bei einem Verbindungsaufbau vom opsi-server zu einem opsi-client die IP-Adresse des Clients bevorzugt über die Namensauflösung ermittelt.
Um die im Backend von opsi hinterlegte IP-Adresse zu bevorzugen ist die Option auf False
zu setzen.
maxConnections
:broadcastAddresses
:Eine Besonderheit beim Standardverhalten von opsi 4.0 Methoden ist, dass bei einer Abfrage ohne Angaben von Parametern, alle Objekte abgerufen werden. Beispielsweise gibt der Befehl "host_getObjects" ohne Parameter aufgerufen, alle Host-Objekte zurück. Dieses Verhalten ist im HostControl-Backend etwas problematisch. Besonders bei den beiden Befehlen: hostControl_shutdown
und hostControl_reboot
. In diesen Fällen würde ein Aufruf dieser Methoden ohne Parameter alle Clients hunterfahren bzw. neustarten.
Deshalb gibt es mit Service Release opsi 4.0.3 an dieser Stelle zwei Änderungen:
hostControl_shutdown
und hostControl_reboot
brechen seit dieser Release mit dem opsi 4.0 Standardverhalten. Diese beiden Methoden geben nun eine Fehlermeldung zurück, wenn kein Parameter übergeben wurde.
Es wurde ein neues Backend (HostControlSafe-Backend) eingeführt, welches Standardmäßig bei allen Methoden eine Fehlermeldung ausgegeben wird, wenn keine korrekte Angaben zu den Clients übergeben wird. Um mit einer Methode vom HostControlSafe-Backend alle Clients an zu sprechen, kann man das *
-Zeichen verwenden:
opsi-admin -d method hostControlSafe_shutdown *
Aus den oben genannten Gründen, empfehlen wir hostControlSafe-Methoden zu verwenden, wenn man etwas unsicher auf der Konsole ist oder neu anfängt sich mit den Servicemethoden zu beschäftigen.
Der Befehl opsi-convert
dient zum Konvertieren der opsi-Konfigurationsdaten zwischen verschiedenen Backends. Die Quelle und das Ziel können auf verschieden Arten bestimmt werden:
opsi-convert file mysql
auf dem aktuellen Server vom file-Backend zum mysql-Backend.
https://<username>@<ipadresse>:4447/rpc
.
Nach den Passwörtern wird gefragt.opsi-convert -s -l /tmp/log https://uib@192.168.2.162:4447/rpc https://opsi@192.168.2.42:4447/rpc
Kommandozeilenargumente von opsi-convert
:
usage: opsi-convert [-h] [--version] [--quiet] [--verbose] [--log-level {0,1,2,3,4,5,6,7,8,9}] [--clean-destination] [--with-audit-data] [-s OLD SERVER ID] [--log-file LOGFILE] source destination Convert an opsi database into an other. positional arguments: source Backend to read data from. destination Backend to write data to. optional arguments: -h, --help show this help message and exit --version, -V show program's version number and exit --quiet, -q do not show progress --verbose, -v increase verbosity (can be used multiple times) --log-level {0,1,2,3,4,5,6,7,8,9} Set log-level (0..9) --clean-destination, -c clean destination database before writing --with-audit-data, -a including software/hardware inventory -s OLD SERVER ID use destination host as new server --log-file LOGFILE, -l LOGFILE Log to this file. The loglevel will be DEBUG. The backends can either be the name of a backend as defined in /etc/opsi/backends (file, mysql, ...) or the the url of an opsi configuration service in the form of http(s)://<user>@<host>:<port>/rpc
Unter /tftpboot/linux
finden sich die Bootdateien, die im Zusammenspiel mit den PXE-Boot benötigt werden.
Der opsi-client-agent greift auf die vom opsi-server zur Verfügung gestellten Shares zu, um die dort liegende Software installieren zu können.
Hierzu wird der System-User pcpatch verwendet. Die Absicherung dieser Shares und damit der Authentifizierungsdaten des Users pcpatch sind wichtig für die: * allgemeine Systemsicherheit und Datenintegrität * Absicherung der potenziell lizenzpflichtigen Softwarepakete gegen missbräuchliche Nutzung
Um dem opsi-client-agent Zugriff auf die Authentifizierungsdaten zu ermöglichen, wird für jeden Client bei seiner Erzeugung in opsi ein spezifischer Schlüssel (opsi-host-Schlüssel) erzeugt. Dieser Schlüssel wird zum einen (beim file-Backend) in der Datei /etc/opsi/pckeys
abgelegt und zum anderen dem PC bei der Reinstallation übergeben. Der übergebene Schlüssel wird im Rahmen der der Installation des opsi-client-agent in der Datei c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
so abgelegt, dass nur Administratoren Zugriff darauf haben. Ebenso hat auf dem opsi-server nur root und Mitglieder der Gruppe opsiadmin Zugriff auf die Datei /etc/opsi/pckeys
. Auf diese Weise verfügt jeder PC über einen Schlüssel, der nur dem PC und dem opsi-server bekannt ist und der gegenüber dem Zugriff durch normale Anwender geschützt ist. Mit diesem Schlüssel wird das aktuelle Passwort des system users pcpatch auf dem opsi-server verschlüsselt und im Backend abgelegt. Dieses verschlüsselte Passwort wird vom Client bei jeder Aktivierung des opsi-client-agent neu gelesen, so dass eine Änderung des pcpatch Passwortes jederzeit möglich ist und der Client auf verschlüsseltem Wege das veränderte Passwort erfährt.
Hier können IP-Nummer und IP-Name der Clients eingetragen werden (zusätzliche Namen sind Aliase, ab dem Zeichen „#“ ist der Eintrag Kommentar).
Opsi braucht den fully qualified hostname (also inclusive Domain) und dieser kann auch statt aus der /etc/hosts
aus dem DNS kommen.
Beispiel:
192.168.2.106 dplaptop.uib.local dplaptop # this opsi-server 192.168.2.153 schleppi.uib.local 192.168.2.178 test_pc1.uib.local # Test-PC PXE-bootprom
Die Ausgabe von:
getent hosts $(hostname -f)
Das Ergebnis sollte beispielsweise so aussehen:
192.168.1.1 server.domain.tld server
Sieht das Ergebnis nicht so aus (enthält z.B. 127.0.0.1 oder localhost), dann müssen Sie Ihre /etc/hosts
oder Namensauflösung zunächst korrigieren.
Hier müssen zwei Gruppen angelegt sein: pcpatch und opsiadmin. In der Gruppe pcpatch sollten alle Benutzer sein, die mit Paketverwaltung zu tun haben. In der Gruppe opsiadmin müssen alle user sein, die den opsiconfd-Webservice verwenden wollen z.B. über den opsi-configed.
acl.conf
dispatch.conf
/etc/opsi/backends/
konfigurierten Backends wofür verwendet werden sollen.
extend.d/
Ab opsi Version 3.2
Hier finden sich Konfigurationen zur Hardwareinventarisierung.
Im Verzeichnis locales
liegen die Sprachanpassungen.
In der Datei opsihwaudit.conf
ist die Abbildung zwischen WMI Klassen und der opsi Datenhaltung konfiguriert.
Seit opsi Version 4.0.2-2
Allgemeine opsi Konfigurationen.
Beispiel:
[groups] fileadmingroup = pcpatch
Hintergrund:
Die klassischen Installationsvariante mit dem Benutzer: pcpatch
mit der primären Gruppe: pcpatch
funktioniert nicht mit Samba 4. Da Samba4 den grundlegenden Restriktionen von Active-Directory unterliegt, sind Gruppen mit der gleichen Bezeichnung wie User (wie in Unix/Linux üblich) nicht mehr erlaubt. Aus diesem Grund wurde eine neue Konfigurationsdatei eingeführt: /etc/opsi/opsi.conf
, über die gesteuert wird, wie die Gruppe für den Samba-Zugriff auf die Freigaben bestimmt wird. So wird bei Distributionen mit Samba 4 nun über diese Datei der Gruppenname pcpatch
umbenannt und heißt von nun an: opsifileadmins
. Das bedeutet, dass die User, die Zugriffsrechte für die Freigaben von opsi erhalten müssen (opsi-Paketierer) nicht Mitglied der Gruppe pcpatch
werden können, sondern Mitglied der Gruppe opsifileadmins
sein müssen.
Ab opsi Version 3.4
Von der uib gmbh signierte Datei zur Freischaltung kostenpflichtiger Features. Wird die Datei verändert, verliert sie Ihre Gültigkeit. Ohne diese Datei stehen nur die kostenlosen Features zur Verfügung.
Ab opsi Version 4.1
Für zukünftige Verwendung angedachtes Verzeichnis.
Ab opsi Version 3.0
Konfigurationsdatei für den opsiconfd in dem sonstige Konfigurationen wie Ports, Interfaces, Logging hinterlegt sind.
Ab opsi Version 3.0
Konfigurationsdatei für den opsiconfd in dem das ssl-Zertifikat hinterlegt ist.
Konfigurationsdatei für den opsipxeconfd, der für das Schreiben der Startdateien für das Linux-Bootimage zuständig ist. Hier können Verzeichnisse, Defaults und Loglevel konfiguriert werden.
Konfigurationsdatei für den opsi-package-updater.
pxelinux.0
install
und miniroot.gz
01-<mac adresse>
bzw. <IP-NUMMER-in-Hex>
default
install
Dieses Verzeichnis ist (read-only) als Samba share opsi_depot freigegeben.
Bei alten opsi-Installationen war dieses Verzeichnis /opt/pcbin/install
. Sollte dieses Verzeichnis noch existieren, so ist es durch einen Symlink mit /var/lib/opsi/depot
verbunden.
In diesem Verzeichnis werden (per default) Partionsimages abgelegt, welche mit dem Netboot-Produkt opsi-clonezilla ausgelesen werden.
Hier werden Produkt-Pakete gespeichert, welche über den Aufruf des opsi-package-updater
auf den Server geladen werden.
Weiterhin werden hier Produkt-Pakete gespeichert, welche über den Aufruf des opsi-package-manager
installiert werden, wenn dieser mit der Option -d
aufgerufen wird.
Hier sind die clientspezifischen opsi-host-Schlüssels sowie der Schlüssel des Servers selber abgelegt.
Beispiel:
schleppi.uib.local:fdc2493ace4b372fd39dbba3fcd62182 laptop.uib.local:c397c280fc2d3db81d39b4a4329b5f65 pcbon13.uib.local:61149ef590469f765a1be6cfbacbf491
Hier sind die mit dem Schlüssel des Servers verschlüsselten Passwörter (z.B. für pcpatch) abgelegt.
Die Dateien des file Backends von opsi 4 finden sich standardmäßig in /var/lib/opsi/config/
. Das folgende Schema gibt einen Überblick der Verzeichnisstruktur:
/var/lib/opsi-| |-depot opsi_depot share |-repository opsi package repository used by opsi-package-updater and opsi-package-manager |-audit inventory files !-config/-| config share |-clientgroups.ini client groups |-config.ini Host Parameters (Global Defaults) |-clients/ <pcname.ini> files |-products/ product control files !-depots depot description files +audit/ global.<Type> (Allgemeine Hard-, bzw. Softwareinformationen) <FQDN>.<Type> (Hard-, bzw. Softwareinformationen der Clients) clientgroups.ini (enthält HostGroups) +clients/ <FQDN>.ini (Informationen der Clients) config.ini (enthält Configs) +depots/ <FQDN>.ini (Informationen der Server) +products/ <ID>_<ProdVer>-<PackVer>.<Type> (Informationen der Products) +templates/ pcproto.ini (Vorlage für Clients) <FQDN>.ini (Vorlage für spezifische Clients)
Vom Editieren der Dateien wird dringend abgeraten!
In den folgenden Kapiten werden die Konfigurationsdateien des file-Backends im Detail vorgestellt.
Die Datei enthält die Informationen über Client-Gruppen.
[<GroupId>] <HostId> = 1 #aktiv <HostId> = 0 #inaktiv
Hier finden sich die Defaultwerte der Serverkonfiguration wie im opsi-configed im Tab Host Parameter angezeigt.
In der dieser Datei werden die Client-spezifischen Konfigurationen zusammengefasst. Die Informationen werden mit denen aus der <depot-id>.ini
zusammengefasst, wobei Informationen aus der <FQDN>.ini
Vorrang haben.
Diese Dateien sind folgendermaßen aufgebaut:
Die Sektion info enthält alle direkt auf den Client bezogene Informationen, wie z.B. die Beschreibung:
[info] description = <String> created = <Date> #format: 'YYYY-MM-DD HH:MM:SS' lastseen = <Date> #format: 'YYYY-MM-DD HH:MM:SS' inventorynumber = <String> notes = <String> hardwareaddress = <MAC> #format: 'hh:hh:hh:hh:hh:hh' ipaddress = <IP> #format: 'nnn.nnn.nnn.nnn' onetimepassword = <String>
Die folgende Sektion beschreibt die aktuellen Zustände der Produkte auf dem Client. Wenn keine Einträge vorhanden sind, wird not_installed:none angenommen.
[<Type>_product_states] #'Local-', bzw. 'NetbootProduct' <ProductId> = <InstallationStatus>:<ActionRequest>
Genauere Informationen stehen dazu in den, zu den jeweiligen Produkten zugehörigen, Sektionen:
[<ProductId>-state] producttype = <Type> #'Local-', bzw. 'NetbootProduct' actionprogress = <String> productversion = <ProdVer> packageversion = <PackVer> modificationtime = <Date> #format: 'YYYY-MM-DD HH:MM:SS' lastaction = <ActionRequest> actionresult = <ActionResult> targetconfiguration = <InstallationStatus>
Hier findet sich die Datei pcproto.ini
, welche das Standardtemplate zur Erzeugung neuer Client-Ini-Dateien ist und besitzt dieselbe Struktur. Wenn bestimmte Clients abweichende Informationen erhalten sollen, kann man auch jeweils eine <FQDN>.ini
in diesem Verzeichnis ablegen.
Hier findet sich die Dateien der opsi-depotserver, die ebenfalls mit <depot-id>.ini
gespeichert werden. Hier wird u.a. die Erreichbarkeit des Depots abgelegt.
[depotshare] remoteurl = smb://<NetBiosName>/<Path> localurl = file://<Path> [depotserver] notes = <String> network = <IP> description = <String> hardwareaddress = <MAC> ipaddress = <IP> inventorynumber = <String> [repository] remoteurl = webdavs://<FQDN>:<Port>/<Path> localurl = file://<Path> maxbandwidth = <Integer> #in Bytes
Hier finden sich aber auch die Informationen, welche opsi-Produkte, in welcher Version und mit welchen Property Defaultwerten, auf dem Depot installiert sind.
Die product control files enthalten die Metainformationen der Produkte, wie z.B. Name, Properties und deren Defaultwerte, Abhängigkeiten …
Die control files entsprechen den control files, wie sie bei der Erstellung von opsi-Produkten im Verzeichnis <produktname>/OPSI/control
erzeugt werden.
Die control files bestehen aus folgenden Sektionen:
Ein Beispiel:
[Package] version: 1 depends: [Product] type: localboot id: thunderbird name: Mozilla Thunderbird description: Mailclient von Mozilla.org advice: version: 2.0.0.4 priority: 0 licenseRequired: False productClasses: Mailclient setupScript: thunderbird.ins uninstallScript: updateScript: alwaysScript: onceScript: [ProductProperty] name: enigmail description: Installiere Verschluesselungs Plugin fuer GnuPG values: on, off default: off [ProductDependency] action: setup requiredProduct: mshotfix requiredStatus: installed requirementType: before
=
, <
, <=
, >
, >=
.
Die opsi Logdateien haben das Format:
[Loglevel] Timestamp Meldung Die Loglevel sind dabei: 0 = nothing (absolute nothing) 1 = essential ("we always need to know") 2 = critical (unexpected errors that may cause a program abort) 3 = error (Errors that will not abort the running program) 4 = warning (you should have a look at this) 5 = notice (Important statements to the program flow) 6 = info (Additional Infos) 7 = debug (important debug messages) 8 = debug2 (a lot more debug informations and data) 9 = confidential (passwords and other security relevant data)
Hier findet sich die Logdateien der bootimages zu den Clients. Dabei werden die Dateien als <Hostname>.log
angelegt.
Sollte das bootimage den Webservice nicht erreichen können, so findet sich die Logdatei im bootimage unter /tmp/log
. Um in einem solchen Fall an die Logdatei vom bootimage zu kommen, gibt es zwei Wege:
SCP
z.B. von Windows aus per WinSCP
die Datei /tmp/log
holen.
Netzwerk geht nicht
Dann hilft der USB-Stick:
sfdisk -l
prüfen, auf welchem Device der Stick liegt
Das Ganze sieht als Beispiel etwa so aus:
#sfdisk -l Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 30401- 30402- 244197528+ 7 HPFS/NTFS /dev/sda2 0 - 0 0 0 Empty /dev/sda3 0 - 0 0 0 Empty /dev/sda4 0 - 0 0 0 Empty Disk /dev/sdb: 1017 cylinders, 33 heads, 61 sectors/track Units = cylinders of 1030656 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdb1 0+ 1016 1017- 1023580 b W95 FAT32 /dev/sdb2 0 - 0 0 0 Empty /dev/sdb3 0 - 0 0 0 Empty /dev/sdb4 0 - 0 0 0 Empty # mount /dev/sdb1 /mnt # cp /tmp/log /mnt #umount /mnt
Hier findet sich die Logdatei der auf dem Client laufenden opsi-client-agent.
Dies ist auf dem Client die C:\opsi.org\log\opsiclientd.log
.
Hier findet sich die Logdatei der auf den Clients ausgeführten opsi-winst-Skripte.
Die Originale liegen auf dem Client unter C:\opsi.org\log\opsiscript.log
Hier findet sich die Logdatei des opsiconfd selbst, sowie log Dateien zu den Clients.
Dabei werden die Dateien als <IP-Nummer>.log
angelegt und, soweit in /etc/opsi/opsiconfd.conf
eingestellt, zu diesen symbolische Links als <FQDN>.log
erzeugt.
Logdatei des opsipxeconfd
welcher für den PXE-Start der Clients die notwendiogen Dateien im tftp-Bereich des Servers verwaltet.
Logdatei des opsiclientd.
Wird bei Beendigung auf den Server nach /var/log/opsi/clientconnect/<FQDN.>log
kopiert.
Diese finden Sie ab opsi 4.0 in den versionspezifischen releasenotes Handbüchern.
UCS 4.X benötigt noch eine DHCP Richtlinie, um einen PXE-Boot von einem UCS System aus zu ermöglichen.
Diese Richtlinie muss in den Richtlinieneinstellungen der Domäne vorgenommen werden und betrifft den DHCP Boot.
Als Boot-Server trägt man den Server ein, auf welchem die Boot Datei liegt. Der Boot-Dateiname lautet pxelinux.0. Da diese Datei direkt im Verzeichnis /tftpboot/
liegt, sieht der Eintrag dann so aus linux/pxelinux.0
Mit dem opsi Produkt opsi-auto-update
lassen sich Geräte einfach und sicher aktualisieren
ohne dass die Aktualisierung für jedes einzelne Gerät angepasst werden muss.
Das Produkt opsi-auto-update
ist hier: „opsi-auto-update“ beschrieben.
Mithilfe von cron jobs auf dem opsi-config-server lässt sich die Ausführung von opsi-produkten zeitlich steuern und so z.B. in die Nacht verlegen.
Voraussetzung hierfür ist, dass sich die Clients per wake-on-lan
(WOL) wecken lassen oder per BIOS zeitgesteuert geweckt werden.
Um die Steuerung per cron job möglichst einfach und effektiv zu machen, haben wir das Script wake_clients_for_setup.py
entwickelt. Dieses Script hat folgende Aufgaben:
setup
gesetzt
wake-on-lan
geweckt
geschlafen
haben und nicht gebootet wurden, kann den Clients noch das Signal gesendet werden, ein bestimmtes Event auszuführen.
Die Angabe der ausgewählten Clients erfolgt dabei wahlweise :
--host-group-id HOSTGROUPID
--depotId DEPOTID
--host-file INPUTFILE
Die Angabe der ausgewählten Produkte welche auf setup
gesetzt werden, erfolgt dabei über die Angabe einer Produktgruppe die z.B. mit dem opsi-configed erstellt werden kann (siehe: „Produktgruppen pflegen“)
--product-group-id PRODUCTGROUPID
Die Angabe des auszulösenden Events erfolgt über den Parameter --event EVENTNAME
Die Namen von Gruppen in opsi müssen einmalig sein. Egal, ob es um eine Hostgruppe aus dem Bereich Directory
oder Gruppen
oder um eine Produktgruppe geht: Ein Gruppenname darf nur einmal vorkommen.
Hier eine Übersicht der Aufrufparameter von wake_clients_for_setup.py
:
# wake_clients_for_setup.py --help usage: wake_clients_for_setup.py [-h] [--version] [--verbose] [--log-level {0,1,2,3,4,5,6,7,8,9}] [--wol-timeout WOLTIMEOUT] [--ping-timeout PINGTIMEOUT] [--connect-timeout CONNECTTIMEOUT] [--event-timeout EVENTTIMEOUT] [--reboot-timeout REBOOTTIMEOUT] [--host-group-id HOSTGROUPID] [--depotId DEPOTID] [--host-file INPUTFILE] [--product-group-id PRODUCTGROUPID] [--event EVENTNAME] [--reboot] [--no-auto-update NOAUTOUPDATE] Wake clients for software installation. optional arguments: -h, --help show this help message and exit --version, -V show program's version number and exit --host-group-id HOSTGROUPID, -H HOSTGROUPID Group in which clients have to be to be waked up. (default: None) --depotId DEPOTID, -D DEPOTID DepotId in which clients have to be registered to be waked up. (default: None) --host-file INPUTFILE, -F INPUTFILE Filename with clients per line have to be waked up. (default: None) --product-group-id PRODUCTGROUPID, -P PRODUCTGROUPID ID of the product group to set to setup on a client (default: None) --event EVENTNAME, -E EVENTNAME Event to be triggered on the clients (default: None) --reboot, -X Triggering reboot on the clients (default: False) --no-auto-update NOAUTOUPDATE, -N NOAUTOUPDATE Do not use opsi-auto-update product. (default: False) Logging: --verbose, -v increase verbosity on console (can be used multiple times) (default: 4) --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9} Set the desired loglevel for the logfile. (default: None) Timeouts: --wol-timeout WOLTIMEOUT Time to wait until opsiclientd should be reachable. (default: 300) --ping-timeout PINGTIMEOUT Time to wait until client should be pingable. (default: 300) --connect-timeout CONNECTTIMEOUT Timeout for connecting to opsiclientd. (default: 15) --event-timeout EVENTTIMEOUT Time to wait until opsiclientd should be processing. (default: 300) --reboot-timeout REBOOTTIMEOUT Time to wait before opsiclientd will be reboot the client. (default: 60)
Das script wake_clients_for_setup.py
finden Sie hier:
https://download.uib.de/opsi4.1/misc/time-driven-maintenance-tools/wake_clients_for_setup.py
Speichern Sie es unter /usr/local/bin
auf dem opsi-server ab und machen es ausführbar:
chmod u+x /usr/local/bin/wake_clients_for_setup.py
Ein beispielhafter Aufruf wäre folgender:
wake_clients_for_setup.py --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-0
Hierbei werden die Clients der Hostgruppe nightly-cron-gruppe-0
ausgewählt und für diese die Produkte der Produktgruppe nightly-cron-produkte
auf setup
gestellt. Anschließend werden die gewählten Clients per wake-on-lan
geweckt und nach einer kurzen Wartezeit ihnen der Befehl gesendet, das Event gui_startup
auszuführen.
Damit das Ganze nun täglich zu einem bestimmten Zeitpunkt ausgeführt wird, muss das Ganze in die crontab
des Servers eingetragen werden.
Dazu kann zum Beispiel (als root) der Befehl crontab -e
verwendet werden.
In der crontab steht vor dem Befehl eine Zeitangabe. Diese besteht aus 5 Teilen, von denen uns hier nur die ersten zwei intressieren: Minute, Stunde.
Eine Crontab bei der unterschiedliche Clientgruppen über die Nacht verteilt aufgerufen werden zeigt folgendes Beispiel:
# For more information see the manual pages of crontab(5) and cron(8) # # m h dom mon dow command # cronjobs zum wecken und installieren der PCs 5 0 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-0 --wol-timeout=120 --event-timeout=120 30 0 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-030 --wol-timeout=120 --event-timeout=120 59 0 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-1 --wol-timeout=120 --event-timeout=120 30 1 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-130 --wol-timeout=120 --event-timeout=120 5 2 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-2 --wol-timeout=120 --event-timeout=120 30 2 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-230 --wol-timeout=120 --event-timeout=120 5 3 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-3 --wol-timeout=120 --event-timeout=120 30 3 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-330 --wol-timeout=120 --event-timeout=120 5 4 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-cron-gruppe-4 --wol-timeout=120 --event-timeout=120 30 4 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-430 --wol-timeout=120 --event-timeout=120 5 5 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-500 --wol-timeout=120 --event-timeout=120 35 5 * * * /usr/local/bin/wake_clients_for_setup.py --log-level=5 --event=gui_startup --product-group-id=nightly-cron-produkte --host-group-id=nightly-jpr-gruppe-530 --wol-timeout=120 --event-timeout=120
Evtl. soll verhindert werden, das Installationen versehentlich ausserhalb des geplanten zeitlichen Wartungsfensters passieren. So soll in einer Schule wenn Tagsüber ein Schüler einen Rechner anschaltet, dieser sofort zur Verfügung stehen und daher keine Installationen durchgeführt werden, selbst wenn Actionrequests gesetzt sind. Dazu kann in der Konfiguration des opsiclientd für bestimmte Events (in der Regel gui_startup
) ein working_window
gesetzt werden.
Wie dieses working_window
konfiguriert wird ist hier beschrieben: „Working Window“
Damit die Verteilung von Software nicht zur "Turnschuh-Administration" wird, muss ein Client-PC selbstständig erkennen, dass neue Softwarepakete oder Updates für ihn bereit stehen und diese installieren. Bei der Installation ist auf jede Form von Anwender-Interaktion zu verzichten, damit diese unbeaufsichtigt erfolgen kann und nicht durch verunsicherte Anwender notwendige Installationen abgebrochen werden.
Diese Anforderungen werden bei opsi durch einen Agenten auf dem Client realisiert:
Auf dem Client wird der sogenannte opsi-client-agent installiert. Dieser überprüft üblicherweise beim Start des Clients und vor dem Login des Anwenders, anhand von Konfigurations-Informationen auf dem opsi-configserver, ob für diesen Client ein Update installiert werden soll.
Soll Software installiert werden, wird das skriptgesteuerte Installationsprogramm opsi-winst gestartet. Auf einer Dateifreigabe, dem sogenannten opsi-depot, stehen die dafür notwendigen Skripte und Softwarepakete bereit. Während dieser Zeit besteht für den Anwender keine Notwendigkeit und keine Möglichkeit in den Installationsprozess einzugreifen.
Um zu verhindern, dass sich ein Anwender vor dem Abschluss der Installation am System anmelden und so den Installations-Prozess stören kann, wird zusätzlich der sogenannte opsi-Loginblocker installiert, der eine Anmeldung erst nach Abschluss der Installationen zulässt.
Damit Softwarepakete mit dem Programm opsi-winst ohne Interaktion installiert werden können, müssen sie dafür vorbereitet werden. Siehe dazu das Kapitel Einbindung eigener Software in die Softwareverteilung von opsi im opsi-getting-started Handbuch.
Der opsi-client-agent installiert sich nach %ProgramFiles%\opsi.org\opsi-client-agent
.
Dieses Verzeichnis enthält alle Programme des opsi-client-agent wie z.B. den opsiclientd, die opsiclientd notifier, den opsi-winst und einige Bibliotheken. Weiterhin finden sich hier die Konfigurationsdateien und grafischen Vorlagen der genannten Programme.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent
ist gegen Veränderung mit Benutzerrechten geschützt.
Das Verzeichnis %ProgramFiles%\opsi.org\opsi-client-agent\opsiclientd
enthält die Konfigurationsdatei des opsiclientd und kann nur mit Administratorrechten gelesen werden.
Weiterhin gibt es das Verzeichnis c:\opsi.org
.
Dieses Verzeichnis dient zur Zeit für den Installationscache (wenn gecached installiert wird → WAN-Erweiterung). Es wird in Zukunft noch weitere Funktionen übernehmen.
Das Verzeichnis c:\opsi.org
kann nur mit Administratorrechten gelesen werden.
Logdateien des opsi-client-agent befinden sich unter c:\opsi.org\log\
.
Der opsiclientd ist die Basis des opsi-client-agents. Er läuft als Service mit administrativen Rechten und wird beim Boot automatisch gestartet.
Wesentliche Funktionen sind:
Der opsi-client-agent besteht aus mehreren Komponenten:
Im Rahmen einer Neuinstallation eines Betriebssystems per unattended Setup über opsi wird der opsi-client-agent automatisch mit installiert.
Zur Deinstallation kann der opsi-client-agent auf uninstall gesetzt werden.
Zur nachträglichen Installation oder zu Reparaturzwecken siehe Kapitel Abschnitt 6.1.6, „Nachträgliche Installation des opsi-client-agents“.
Kernkomponente des opsi-client-agents ist der Service opsiclientd. Dieser läuft beim Start des Betriebssystems an.
Er übernimmt folgende Aufgaben:
Der opsiclientd notifier realisiert die Interaktion mit dem Anwender. Hier werden sowohl Statusmeldungen des opsiclientd ausgegeben als auch Dialoge, die zur Steuerung des opsiclientd dienen. Die jeweilige Funktion und das Erscheinungsbild wird hierbei über Konfigurations-Dateien bestimmt.
Der opsiclientd notifier kann zu unterschiedlichen Situationen und auf unterschiedliche Weise erscheinen:
Änderung der Benennung/Funktionalität von opsi 4.0.1 gegenüber opsi 4.0.
Den opsi 4.0 event notifier gibt es nicht mehr.
Der opsi 4.0.1 event notifier entspricht dem opsi 4.0 action notifier.
Der opsi 4.0.1 action notifier ähnelt dem opsi 4.0 event notifier, wird aber nur aktiv, wenn die Bearbeitung von Aktionen ansteht.
Der opsi-Loginblocker für NT5 Win2K/WinXP ist als GINA implementiert (opsigina.dll). Diese GINA wartet bis zum Abschluss der Produktaktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd. Danach wird die Kontrolle an die nächste GINA übergeben (in der Regel an die msgina.dll).
Der opsi-Loginblocker für NT6 (Vista/Win7) ist als credential provider filter realisiert (OpsiLoginBlocker.dll). Er blockiert alle credential provider bis zum Abschluss der Produktaktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd.
Der Ablauf der Aktionen, die in einem Event stattfinden, ist vielfältig konfigurierbar. Um die Konfigurations-Möglichkeiten zu verstehen, ist ein Verständnis der Ablauf-Logik notwendig. Es folgt zunächst ein Überblick über den Ablauf eines "Standard-Events" bei dem der opsi-configserver gefragt wird, ob Aktionen auszuführen sind (z.B. event_gui_startup).
Die wichtigsten Parameter wirken hier wie folgt zusammen:
Tritt bei der Verbindungsaufnahme zum opsi-configserver ein Fehler auf, kann natürlich auch keine Log-Datei
zum opsi-configserver übertragen werden.
Die genaue Fehlerbeschreibung ist jedoch in der opsiclientd.log
im Log-Verzeichnis auf dem Client festgehalten.
event_notifier_command
ausgeführt.user_cancelable_after
Sekunden keine Verbindung hergestellt werden, so wird im opsiclientd notifier
der Button aktiviert, der das Abbrechen der Verbindungsaufnahme ermöglicht.
Sobald die Verbindung zum opsi-configserver hergestellt ist, ist ein Abbrechen nicht mehr möglich.connection_timeout
Sekunden keine Verbindung zum opsi-configserver hergestellt werden,
so wird das laufende Event mit einem Fehler beendet.
Soll der User keine Möglichkeit zum Abbrechen haben, muss user_cancelable_after
auf einen Wert größer oder gleich connection_timeout
gesetzt werden.
action_notifier_command
ausgeführt.action_warning_time
Sekunden sichtbar.
Ist die action_warning_time
= 0 (Standard-Wert) wird kein action_notifier_command
ausgeführt.action_user_cancelable
mal verschoben werden.action_user_cancelable
= 0 kann der Anwender die Aktionen nicht verhindern.action_message
bzw action_message[lang]
konfigurierbar.%action_user_cancelable%
(Gesamtanzahl der möglichen Abbrüche)
und %action_cancel_counter%
(Anzahl der bereits erfolgten Abbrüche) verwendet werden.action_cancel_counter
zurückgesetzt und der opsi-winst startet mit deren Bearbeitung.
shutdown_notifier_command
gesetzt ist
und ob sie shutdown_warning_time
> 0 ist.
Sind diese Bedingungen erfüllt, wird der shutdown_notifier_command
ausgeführt.shutdown_warning_time
Sekunden sichtbar.shutdown_user_cancelable
konfiguriert.shutdown_warning_repetition_time
Sekunden wieder.shutdown_warning_message
bzw. shutdown_warning_message[lang]
konfigurierbar.
Innerhalb dieses Textes können die Platzhalter %shutdown_user_cancelable%
(Gesamtanzahl der möglichen Abbrüche)
und %shutdown_cancel_counter%
(Anzahl der bereits erfolgten Abbrüche) verwendet werden.shutdown_cancel_counter
zurückgesetzt.
Der Ablauf des Event und auch die Aktionen des Benutzers sind in der Timeline auf der Info-Seite des opsiclientds sichtbar (siehe „opsiclientd infopage“).
Um den vielen unterschiedlichen Situationen gerecht zu werden, in denen der opsi-client-agent aktiv werden kann, sind die Konfigurations-Möglichkeiten vielfältig.
In der Konfiguration des opsiclientd leitet eine Sektion in der Form [event_<config-id>]
eine neue Event-Konfiguration ein.
Eine Event-Konfiguration kann über das Setzen der Option active = false
deaktiviert werden.
Existiert zu einem Event-Typ keine Event-Konfiguration (oder sind diese deaktiviert), wird der entsprechende Event-Typ komplett deaktiviert.
Es gibt verschiedene Typen von Event-Konfigurationen (type
).
super
die Id einer anderen Event-Konfiguration gesetzt,
erbt die Event-Konfiguration alle Optionen (bis auf active
) der Parent-Konfiguration.
Geerbte Optionen können jedoch überschrieben werden.
Alle weiteren Event-Konfigurationen gelten für einen gewissen Event-Typ (type).
Verfügbare Event-Typen sind:
gui startup
gui startup
tritt beim Start des Clients (der GUI) auf.custom
custom
können selbst festlegen, wann ein solches Event erzeugt wird.
Hierfür kann über die Option wql
ein WQL-Ausdruck angegeben werden.
Sobald dieser WQL-Ausdruck ein Ergebnis liefert, wird ein custom
-Event mit der jeweiligen Konfiguration gestartet.custom
-Event die Option wql
leer angegeben, tritt dieses Event praktisch nie auf,
kann aber über die Webservice-Schnittstelle des opsiclientd bei Bedarf ausgelöst werden.
user login
timer
interval
Sekunden).
sync completed
sync_config_from_server
) oder von Produkten (cache_products
) erfolgt.
sw on demand
Es gibt Preconditions (Vorbedingungen)
Preconditions geben bestimmte Systemzustände vor (z.B. ob gerade ein Benutzer am System angemeldet ist).
In der Konfiguration des opsiclientd leitet eine Sektion in der Form [precondition_<precondition-id>]
die Deklaration einer Precondition ein.
Eine Precondition ist dann erfüllt, wenn alle angegebenen Optionen erfüllt sind.
Eine nicht angegebene Option gilt hierbei als erfüllt.
Mögliche Optionen für Preconditions sind:
user_logged_in
: ist erfüllt, wenn ein Benutzer am System angemeldet ist.
config_cached
: ist erfüllt, wenn das Cachen von Konfigurationen abgeschlossen ist (siehe: sync_config_from_server
).
products_cached
: ist erfüllt, wenn das Cachen von Produkten abgeschlossen ist (siehe: cache_products
).
Ein Beispiel zur Erläuterung:
Im Rahmen einer Installation kann es notwendig sein den Rechner zu rebooten.
Ist gerade ein Benutzer am System angemeldet, sollte dieser über den anstehenden Reboot informiert werden.
Hierbei ist eine angemessene Wartezeit vor dem Ausführen des Reboots angebracht.
Zusätzlich kann es sinnvoll sein, dem Benutzer die Entscheidung zu überlassen, ob der Reboot besser zu einem späteren Zeitpunkt ausgeführt werden soll.
Ist zum Zeitpunkt des benötigten Reboots jedoch kein Benutzer angemeldet, ist es sinnvoll, den Reboot ohne weitere Wartezeit sofort durchzuführen.
Dieses Problem wird am Beispiel von event_on_demand
wie folgt konfiguriert:
user_logged_in
definiert, die erfüllt ist, wenn ein Benutzer am System angemeldet ist (user_logged_in = true
).
event_on_demand
(ohne Precondition) wird shutdown_warning_time = 0
gesetzt (sofortiger Reboot ohne Meldung).
event_on_demand{user_logged_in}
wird shutdown_warning_time = 300
gesetzt (300 Sekunden Vorwarnzeit).
Für alle Events kann ein sogenanntes working_window konfiguriert werden. Dieses begrenzt die Funktion eines Events auf einen Zeitraum innerhalb einer konfigurierbaren Start- und Endzeit.
Für das working_window Feature wird der opsi-client-agent >= Version 4.1.0.0-39 benötigt.
Um das working_window zu verwenden, muss der Konfiguration eines Events der Key working_window hinzugefügt werden. Falls dieser Key nicht existiert, oder keinen, oder einen ungültigen Wert hat, so gilt das working_window als leer und es gibt keine zeitliche Beschränkung für das Event.
Startzeit und Endzeit müssen im Format hh:mm angegeben werden und sind durch einen Bindestrich voneinander getrennt. Leerzeichen zwischen Start und Endzeit sind nicht erlaubt!
Ein working_window kann in allen events angelegt werden.
Die Konfiguration des working_window erfolgt über das Hinzufügen des Hostparameter working_window für das gewünschte Event.
Das kann entweder über den opsi-configed, oder über das Tool opsi-admin auf dem opsi-configserver erfolgen.
Die folgenden Beispiele zeigen wie ein working_window für das Event event_gui_startup per opsi-admin konfiguriert werden kann. Siehe Kapitel „Konfiguration über den Webservice (Hostparameter)“ für das Hinzufügen von Hostparameter per opsi-configed.
Beispiel 1: Globales Erstellen eines leeren working_window für das Event event_gui_startup. Die zeitliche Einschränkung erfolgt clientspezifisch (siehe Beispiel 3).
opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window
Beispiel 2: Globales Erstellen eines working_window für die Zeit zwischen 20:00 Uhr und 07:00 Uhr für das Event event_gui_startup.
opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window "gui_startup.working_window" "20:00-07:00"
Beispiel 3: Clientspezifisches Einstellen des working_window für die Zeit zwischen 07:00 Uhr und 19:00 Uhr für das Event event_gui_startup.
opsi-admin -d method configState_create opsiclientd.event_gui_startup.working_window "client.domain.de" "07:00-19:00"
Ist die Startzeit größer ist als die Endzeit gilt das working_window über den nächtlichen Tageswechsel (23:59-0:00).
Beispiel am Tag (Startzeit < Endzeit): working_window=07:00-19:00
Beispiel in der Nacht (Startzeit > Endzeit): working_window=20:00-07:00
Für das Beispiel "working_window=20:00-07:00" würde das Log des opsiclientd beispielsweise so aussehen:
[5] [<timestamp>] [ event processing gui_startup] We have now: 2019-11-05 01:02:13.993000 (EventProcessing.pyo|1121) [5] [<timestamp>] [ event processing gui_startup] Working Window configuration starttime: 2019-11-04 20:00:00 endtime: 2019-11-05 07:00:00 systemtime now: 2019-11-05 01:02:13.993000 (EventProcessing.pyo|1138) [5] [<timestamp>] [ event processing gui_startup] We are in the configured working window (EventProcessing.pyo|1139)
In der Sektion: "global" von der opsiclientd.conf gibt es jetzt die Möglichkeit, den opsi-client-agent einen Proxyserver mit zu konfigurieren. Wenn ein Proxy konfiguriert wurde, werden alle HTTP- und HTTPS-Verbindungen vom opsiclientd über diesen Proxy umgeleitet.
# Use a proxy for connecting configservice # proxy_mode: # 'system' will try to check the system setting, # 'static' to use proxyurl from configfile/hostparameter # proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port> # Example: http://proxyuser:proxypass123@proxy.domain.local:8080 proxy_mode = static proxy_url =
Die Proxyeinstellungen erlauben auch, einen Proxy zu benutzen, der eine Authentifizierung erfordert. Dazu muss die Proxy_url wie oben im Beispiel angegeben werden.
Der proxy_mode ist so vorgesehen, dass bei der Einstellung system, der proxy aus dem laufenden Client-System ausgelesen wird. Dies ist im Moment nicht implementiert, deshalb funktioniert momentan nur die Einstellung static.
Mit diesem neuen Feature ist es über die Konfiguration möglich, die Liste der ab zu bearbeitenden Produkte über Produktgruppen zu steuern.
Dazu gibt es Grundsätzlich zwei Vorgehensweise:
Blacklisting (Ausschließen):
Mit der Option exclude_product_group_ids
kann man eine kommaseparierte Liste von Produktgruppen-Ids mitgeben, dessen Mitglieder vom aktuellen Event ausgeschlossen werden. Auch wenn sie eigentich auf setup stehen. Diese Produkte werden zwar ignoriert, aber bleiben auf setup stehen.
Whitelisting (Liste von Produkten ausschliesslich freigeben):
Mit der Option `include_product_group_ids`kann man eine kommaseparierte Liste von Produktgruppen-Ids festlegen, dessen Mitglieder überhaupt bearbeitet werden dürfen, vorausgesetzt eine entsprechende Aktion ist gesetzt.
Diese Einstellung kann man Global im Default-Event angeben, damit das für jedes Event gilt. Alternativ kann man diese Optionen aber auch zum Beispiel nur im Event_on_demand einsetzen. Somit kann man Pakete, die auf setup stehen von Push-Installationen ausschliessen, obwohl Sie auf setup stehen. Bei einem normalen Neustarts des Clients mit gui_startup (default) würden diese ausgeschlossenen Pakete trotzdem auf dem Client installiert werden.
Für Clients, die das Modul WAN/VPN aktiviert haben, muss man diese Optionen neben dem Sync-Event auch in der CacheService-Sektion mit aufgenommen werden, da der CacheService zwar vom Sync-Event getriggert wird, aber selbst keinen Zugriff auf das sync-Event hat.
Produktabhängigkeiten werden bei diesem Feature nicht berücksichtigt. Bitte achten Sie darauf, dass Sie bei der Konfiguration keine Abhängigkeiten außer Kraft setzen.
Die Konfigurationsdatei ist auf einem 64Bit Windows zu finden unter c:\program files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
.
Auf einem 32Bit Windows ist die Konfigurationsdatei unter c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
zu finden.
Diese Konfigurationsdatei ist UTF-8 kodiert.
Änderungen mit Editoren, die diese Kodierung nicht beherrschen (z.B. notepad.exe), zerstören die Umlaute in dieser Datei.
Die hier festgelegte Konfiguration kann nach erfolgreicher Verbindung zum opsi-configserver durch die dort festgelegte Hostparameter überschrieben werden.
Beispiel opsiclientd.conf
:
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ; = configuration file for opsiclientd = ; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - global settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [global] # Location of the log file. log_file = c:\\opsi.org\\log\\opsiclientd.log # Set the log (verbosity) level # (0 <= log level <= 9) # 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices # 6: infos, 7: debug messages, 8: more debug messages, 9: passwords log_level = 4 # Client id. host_id = # Opsi host key. opsi_host_key = # Verify opsi server certs verify_server_cert = false # Verify opsi server certs by ca verify_server_cert_by_ca = false # On every daemon startup the user login gets blocked # If the gui starts up and no events are being processed the login gets unblocked # If no gui startup is noticed after <wait_for_gui_timeout> the login gets unblocked # Set to 0 to wait forever wait_for_gui_timeout = 120 # Application to run while blocking login block_login_notifier = %global.base_dir%\\notifier.exe -s notifier\\block_login.ini # Use a proxy for connecting configservice # proxy_mode: # 'system' will try to check the system setting, # 'static' to use proxyurl from configfile/hostparameter # proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port> # Example: http://proxyuser:proxypass123@proxy.domain.local:8080 proxy_mode = static proxy_url = # Try to Suspend Bitlocker before rebooting the client suspend_bitlocker_on_reboot = false ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - config service settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [config_service] # Service url. # http(s)://<opsi config server address>:<port>/rpc url = https://opsi.uib.local:4447/rpc # Conection timeout. connection_timeout = 30 # The time in seconds after which the user can cancel the connection establishment user_cancelable_after = 30 # If this option is set, the local system time will be synced with time from service sync_time_from_service = false ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - depot server settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [depot_server] # Depot server id depot_id = # Depot url. # smb://<depot address>/<share name>/<path to products> url = # Local depot drive drive = # Username that is used for network connection [domain\]<username> username = pcpatch ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - cache service settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [cache_service] # Maximum product cache size in bytes product_cache_max_size = 5000000000 # Members of this ProductGroups will be excluded from processing exclude_product_group_ids = # Only members of this ProductGroups will be excluded from processing include_product_group_ids = ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - control server settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [control_server] # The network interfaces to bind to. # This must be the IP address of an network interface. # Use 0.0.0.0 to listen to all interfaces interface = 0.0.0.0 # The port where opsiclientd will listen for HTTPS rpc requests. port = 4441 # The location of the server certificate. ssl_server_cert_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem # The location of the server private key ssl_server_key_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem # The location of the static files static_dir = %global.base_dir%\\opsiclientd\\static_html # The maximum number of authentication failures before a client ip # is blocked for an amount of time. max_authentication_failures = 5 ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - notification server settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [notification_server] # The network interfaces to bind to. # This must be the IP address of an network interface. # Use 0.0.0.0 to listen to all interfaces interface = 127.0.0.1 # The first port where opsiclientd will listen for notification clients. start_port = 44000 # Port for popup notification server popup_port = 45000 ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - opsiclientd notifier settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [opsiclientd_notifier] # Notifier application command command = %global.base_dir%\\notifier.exe -p %port% -i %id% ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - opsiclientd rpc tool settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [opsiclientd_rpc] # RPC tool command command = %global.base_dir%\\opsiclientd_rpc.exe "%global.host_id%" "%global.opsi_host_key%" "%control_server.port%" ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - action processor settings - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [action_processor] # Locations of action processor local_dir = %global.base_dir%\\opsi-winst remote_dir = opsi-winst\\files\\opsi-winst filename = winst32.exe # Action processor command command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key% # Load profile / environment of %run_as_user% create_environment = false ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; - events - ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [event_default] ; === Event configuration # Type of the event (string) type = template # Interval for timer events in seconds (int) interval = -1 # Maximum number of event repetitions after which the event will be deactivated (int, -1 = forever) max_repetitions = -1 # Time in seconds to wait before event becomes active (int, 0 to disable delay) activation_delay = 0 # Time in seconds to wait before an event will be fired (int, 0 to disable delay) notification_delay = 0 # Event notifier command (string) event_notifier_command = %opsiclientd_notifier.command% -s notifier\\event.ini # The desktop on which the event notifier will be shown on (current/default/winlogon) event_notifier_desktop = current # Block login while event is been executed (bool) block_login = false # Lock workstation on event occurrence (bool) lock_workstation = false # Logoff the current logged in user on event occurrence (bool) logoff_current_user = false # Get config settings from service (bool) get_config_from_service = true # Store config settings in config file (bool) update_config_file = true # Transmit log file to opsi service after the event processing has finished (bool) write_log_to_service = true # Shutdown machine after action processing has finished (bool) shutdown = false # Reboot machine after action processing has finished (bool) reboot = false # Members of this ProductGroups will be excluded from processing exclude_product_group_ids = # Only members of this ProductGroups will be excluded from processing include_product_group_ids = ; === Sync/cache settings # Sync configuration from local config cache to server (bool) sync_config_to_server = false # Sync configuration from server to local config cache (bool) sync_config_from_server = false # Sync configuration from local config cache to server after action processing (bool) post_sync_config_to_server = false # Sync configuration from server to local config cache after action processing (bool) post_sync_config_from_server = false # Work on local config cache use_cached_config = false # Cache products for which actions should be executed in local depot cache (bool) cache_products = false # Maximum transfer rate when caching products in byte/s (int, 0 = no limit) cache_max_bandwidth = 0 # Dynamically adapt bandwidth to other network traffic (bool) cache_dynamic_bandwidth = false # Work on local depot cache use_cached_products = false ; === Action notification (if product actions should be processed) # Time in seconds for how long the action notification is shown (int, 0 to disable) action_warning_time = 0 # Action notifier command (string) action_notifier_command = %opsiclientd_notifier.command% -s notifier\\action.ini # The desktop on which the action notifier will be shown on (current/default/winlogon) action_notifier_desktop = current # Message shown in the action notifier window (string) action_message = Starting to process product actions. You are allowed to cancel this event a total of %action_user_cancelable% time(s). The event was already canceled %state.action_processing_cancel_counter% time(s). # German translation (string) action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie können diese Aktion insgesamt %action_user_cancelable% mal abbrechen. Die Aktion wurde bereits %state.action_processing_cancel_counter% mal abgebrochen. # French translation (string) action_message[fr] = Traitement des actions du produit. Vous êtes autorisé à annuler cet événement un total de %action_user_cancelable% fois. L'événement a été déjà annulée %state.action_processing_cancel_counter% fois. # Number of times the user is allowed to cancel the execution of actions (int) action_user_cancelable = 0 ; === Action processing # Should action be processed by action processor (bool) process_actions = true # Type of action processing (default/login) action_type = default # Update the action processor from server before starting it (bool) update_action_processor = true # Command which should be executed before start of action processor pre_action_processor_command = # Action processor command (string) action_processor_command = %action_processor.command% # The desktop on which the action processor command will be started on (current/default/winlogon) action_processor_desktop = current # Action processor timout in seconds (int) action_processor_timeout = 10800 # Command which should be executed before after action processor has ended post_action_processor_command = ; === Shutdown notification (if machine should be shut down or rebooted) # Process shutdown requests from action processor process_shutdown_requests = true # Time in seconds for how long the shutdown notification is shown (int, 0 to disable) shutdown_warning_time = 0 # Shutdown notifier command (string) shutdown_notifier_command = %opsiclientd_notifier.command% -s notifier\\shutdown.ini # The desktop on which the action notifier will be shown on (current/default/winlogon) shutdown_notifier_desktop = current # Message shown in the shutdown notifier window (string) shutdown_warning_message = A reboot is required to complete software installation tasks. You are allowed to delay this reboot a total of %shutdown_user_cancelable% time(s). The reboot was already delayed %state.shutdown_cancel_counter% time(s). # German translation (string) shutdown_warning_message[de] = Ein Neustart wird benötigt um die Software-Installationen abzuschliessen. Sie können diesen Neustart insgesamt %shutdown_user_cancelable% mal verschieben. Der Neustart wurde bereits %state.shutdown_cancel_counter% mal verschoben. # French translation (string) shutdown_warning_message[fr] = Un redémarrage est nécessaire pour terminer l'installation du logiciel. Vous êtes autorisé à retarder le redémarrage un total de %shutdown_user_cancelable% fois. Le redémarrage a été déjà retardé %state.shutdown_cancel_counter% fois. # Number of times the user is allowed to cancel the shutdown (int) shutdown_user_cancelable = 0 # Time in seconds after the shutdown notification will be shown again after the user has canceled the shutdown (int) shutdown_warning_repetition_time = 3600 [event_gui_startup] super = default type = gui startup name = gui_startup block_login = true [event_gui_startup{user_logged_in}] name = gui_startup shutdown_warning_time = 300 block_login = false [event_gui_startup{cache_ready}] use_cached_config = true use_cached_products = true action_user_cancelable = 3 action_warning_time = 60 [event_gui_startup{installation_pending}] name = gui_startup active = true [event_on_demand] super = default type = custom name = on_demand [event_on_demand{user_logged_in}] name = on_demand shutdown_warning_time = 300 [event_software_on_demand] super = default type = sw on demand [event_sync] super = default type = template process_actions = false event_notifier_command = sync_config_to_server = true sync_config_from_server = true cache_products = true cache_dynamic_bandwidth = true [event_timer] super = sync type = timer active = false interval = 3600 [event_net_connection] super = sync type = custom active = false wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_NetworkAdapter' AND TargetInstance.NetConnectionStatus = 2 [event_sync_completed] super = default type = sync completed event_notifier_command = process_actions = false get_config_from_service = false write_log_to_service = false [event_sync_completed{cache_ready_user_logged_in}] reboot = true shutdown_user_cancelable = 10 shutdown_warning_time = 300 [event_sync_completed{cache_ready}] reboot = true [event_user_login] super = default type = user login action_type = login active = false action_message = Starting to process user login actions. action_message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen. action_message[fr] = Traitement des actions à la connexion de l'utilisateur. block_login = false process_shutdown_requests = false get_config_from_service = false update_config_file = false write_log_to_service = false update_action_processor = true event_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini event_notifier_desktop = default action_processor_command = %action_processor.command% /sessionid %service_session% /allloginscripts /silent action_processor_desktop = default action_processor_timeout = 300 [event_on_shutdown] super = default type = custom name = on_shutdown active = False [event_on_shutdown{installation_pending}] name = on_shutdown active = False [event_silent_install] super = default type = custom name = silent_install event_notifier_command = process_shutdown_requests = false action_processor_productIds = swaudit,hwaudit action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent action_processor_desktop = winlogon action_processor_timeout = 300 [event_timer_silentinstall] super = silent_install type = timer active = false interval = 21600 [precondition_user_logged_in] user_logged_in = true [precondition_cache_ready] config_cached = true products_cached = true [precondition_cache_ready_user_logged_in] user_logged_in = true config_cached = true products_cached = true [precondition_installation_pending] installation_pending = true
Die Konfiguration kann auch zentral gesteuert werden. Hierzu dienen Einträge in der Hostparameter des opsi-configservers.
Diese Einträge müssen dem folgenden Muster folgen:
opsiclientd.<name der section>.<name der option>
Ein Beispiel:
opsiclientd.event_gui_startup.action_warning_time = 20
setzt in der Konfigurationsdatei opsiclientd.conf
in der Sektion [event_gui_startup]
den Wert von action_warning_time
auf 20.
Die folgende Abbildung zeigt, wie diese Werte als Defaults für alle Clients über den opsi-configed gesetzt werden können.
Hier kann über das Kontextmenü Property hinzufügen
ein neuer Wert gesetzt werden.
Um einen Hostparameter zu löschen, verwenden Sie das Werkzeug opsi-admin. Beispiel:
opsi-admin -d method config_delete "opsiclientd.event_gui_startup.action_warning_time"
Eine Client-spezifische Änderung über den opsi-configed führen Sie über den Hosts-Parameter Tab in der Client-Konfiguration aus. Um Client-spezifische Einträge zu löschen, verwenden Sie das Werkzeug opsi-admin. Beispiel:
@opsi-admin> method configState_delete "opsiclientd.event_gui_startup.action_warning_time" "myclient.uib.local"
Die Log-Datei des opsiclientd ist standardmäßig c:\opsi.org\log\opsiclientd.log
.
Die Log-Informationen werden auch an den opsi-configserver übertragen. Dort liegen sie unter /var/log/opsi/clientconnect/<ip-bzw.-name-des-clients>.log. Sie sind auch im opsi-configed über Logdateien ⇒ Clientconnect einsehbar.
Jede Zeile in der Logdatei folgt dem Muster:
[<log level>] [<datum zeit>] [Quelle der Meldung] Meldung (Quellcode-Datei|Zeilennummer).
Dabei gibt es die folgenden Log-Level:
# Set the log (verbosity) level # (0 <= log level <= 9) # 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices # 6: infos, 7: debug messages, 8: more debug messages, 9: passwords
Beispiel:
(...) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'sync_completed{cache_ready}' added to event generator 'sync_completed' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'gui_startup' added to event generator 'gui_startup' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'gui_startup{cache_ready}' added to event generator 'gui_startup' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'on_demand' added to event generator 'on_demand' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'sync_completed{cache_ready_user_logged_in}' added to event generator 'sync_completed' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'gui_startup{user_logged_in}' added to event generator 'gui_startup' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'sync_completed' added to event generator 'sync_completed' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'software_on_demand' added to event generator 'software_on_demand' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config 'on_demand{user_logged_in}' added to event generator 'on_demand' (Events.pyo|1107) [5] [Mar 22 10:17:46] [ event processing gui_startup ] Updating config file: 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf' (Config.pyo|287) [5] [Mar 22 10:17:46] [ event processing gui_startup ] No need to write config file 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf', config file is up to date (Config.pyo|318) [5] [Mar 22 10:17:46] [ event processing gui_startup ] No product action requests set (EventProcessing.pyo|591) [5] [Mar 22 10:17:49] [ event processing gui_startup ] Writing log to service (EventProcessing.pyo|247) [6] [Mar 22 10:17:49] [ opsiclientd ] shutdownRequested: 0 (Windows.pyo|340) [6] [Mar 22 10:17:49] [ opsiclientd ] rebootRequested: 0 (Windows.pyo|326) [5] [Mar 22 10:17:49] [ opsiclientd ] Block login now set to 'False' (Opsiclientd.pyo|111) [6] [Mar 22 10:17:49] [ opsiclientd ] Terminating block login notifier app (pid 1620) (Opsiclientd.pyo|148) [6] [Mar 22 10:17:49] [ event processing gui_startup ] Stopping notification server (EventProcessing.pyo|225) [6] [Mar 22 10:17:51] [ control server ] client connection lost (Message.pyo|464) [6] [Mar 22 10:17:52] [ event processing gui_startup ] Notification server stopped (Message.pyo|651) [5] [Mar 22 10:17:52] [ event processing gui_startup ] ============= EventProcessingThread for event 'gui_startup' ended ============= (EventProcessing.pyo|1172) [5] [Mar 22 10:17:52] [ opsiclientd ] Done processing event '<ocdlib.Events.GUIStartupEvent object at 0x023CE330>' (Opsiclientd.pyo|405) [5] [Mar 22 10:19:41] [ opsiclientd ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' expired after 120 seconds (Session.pyo|184) [6] [Mar 22 10:19:41] [ opsiclientd ] Session timer <_Timer(Thread-20, started daemon 2636)> canceled (Session.pyo|120) [5] [Mar 22 10:19:41] [ opsiclientd ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' deleted (Session.pyo|207) [6] [Mar 22 10:27:55] [ control pipe ] Creating pipe \\.\pipe\opsiclientd (ControlPipe.pyo|253) [5] [Mar 22 10:27:55] [ event generator wait_for_gui ] -----> Executing: getBlockLogin() (JsonRpc.pyo|123) [5] [Mar 22 10:27:55] [ opsiclientd ] rpc getBlockLogin: blockLogin is 'False' (ControlPipe.pyo|428) [6] [Mar 22 10:27:55] [ event generator wait_for_gui ] Got result (JsonRpc.pyo|131) '
Die Log-Datei des opsi-Loginblockers befindet sich unter NT6 (Vista/Win7) als auch unter NT5 (Win2k/WinXP) in C:\opsi.org\log\opsi_loginblocker.log
.
Da bei den Abläufen im opsiclientd vielfältige Komponenten zusammenwirken, welche zum Teil gleichzeitig aktiv sind, wird die Logdatei leicht unübersichtlich.
Daher verfügt der opsiclientd über eine eigene infopage welche die Abläufe auf einer Zeitachse grafisch darstellt. Diese infopage kann mit dem Browser über die URL https://<adresse-des-clients>:4441/info.html aufgerufen werden.
Abbildung 6.8. Info-Page des opsiclientd nach einer Push-Installation mit aktiviertem Produkt-Caching
Clients mit aktivierter Bitlocker-Verschlüsselung mit manueller Passworteingabe beim Booten verhindern die unbeaufsichtigte Installation von Software und Patches.
Genau wie der opsi-winst ist es nun auch möglich für Reboots, die von Events des opsiclientd ausgelöst werden, ebenfalls die Passwort-Eingabe beim Booten zu unterdrücken.
Dieses Feature ist zwangsläufig mit einem Sicherheitsverlust verbunden. Bei diesem Vorgang wird das Passwort als Klartext auf die Festplatte geschrieben und ist damit auch potenziell eine Schwachstelle.
Dieses Feature ist per default deaktiviert. Um diese Option nur auf ausgesuchten Clients zu aktivieren, muss zuerst eine Standardkonfiguration erstellt werden:
opsi-admin -d method config_createBool clientconfig.suspend_bitlocker_on_reboot "Suspending Bitlocker at Reboot" false
Der Standard-Wert false entspricht hierbei dem Wert in der mitgelieferten opsiclientd.conf
.
Zum Setzen des Hostparameter über opsi-admin ist der folgende Befehl auf dem opsi-configserver auszuführen
(im Beispiel für einen Client mit der opsi-host-Id myclient.domain.de
):
opsi-admin -d method configState_create clientconfig.suspend_bitlocker_on_reboot myclient.domain.de true
Diese Option kann ebenfalls auf Clients aktiviert werden, die keine Bitlocker-Verschlüsselung aktiviert haben und sollte den Betrieb des opsiclientd nicht stören.
Der opsiclientd verfügt über eine Webservice-Schnittstelle. Diese ermöglicht es, dem opsi-client-agent Anweisungen zu übermitteln und Vieles mehr. Sie lassen sich momentan grob in drei Bereiche aufteilen:
Dies kann auch auf der Kommandozeile mittels Aufrufs einer hostControlSafe_*-Methode über opsi-admin geschehen.
Bei Verwendung der hostControlSafe_*-Methoden
opsi-admin -d method hostControlSafe_xx *hostIds
kann der Parameter *hostIds
["*"]
, dann gilt der Aufruf für alle Clients
eine Liste von Clients enthalten ["<client1>", "<client2>", …]
z.B. ["client1.uib.local", "client2.uib.local"]
eine Wildcard enthalten, wobei *
als Platzhalter dient
z.B. "client.*" oder "*.uib.*"
Werden Rechner nicht erreicht (z.B. weil sie aus sind), wird für diese Rechner eine Fehlermeldung ausgegeben.
Über den opsi-configed lassen sich Nachrichten an einen oder mehrere Clients versenden.
Siehe dazu Kapitel Abschnitt 4.8.6, „Nachrichten senden (Starte Meldungsfenster)“
Auf der Kommandozeile lässt sich dies ebenfalls mittels opsi-admin durchführen:
opsi-admin -d method hostControlSafe_showPopup message *hostid
Beispiel:
opsi-admin -d method hostControlSafe_showPopup "Ein Text..." "myclient.uib.local"
Vom opsi-server aus kann der Client aufgefordert werden, die gesetzten Produktaktionen auszuführen.
Das Auslösen des Events kann vom opsi-configed aus erfolgen. Abschnitt 4.8.5, „on_demand Ereignis auslösen (Push Installation)“
Auf der Kommandozeile lässt sich dies ebenfalls mittels opsi-admin durchführen:
opsi-admin -d method hostControlSafe_fireEvent event *hostIds
Beispiel:
opsi-admin -d method hostControlSafe_fireEvent "on_demand" "myclient.uib.local"
Über den Webservice des opsiclientd ist es möglich, steuernd auf den opsi-client-agent einzuwirken. Dazu muss man sich an diesem Webservice authentifizieren. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels der opsi-host-Id (FQDN / vollständiger Host-Name inkl. DNS-Domain) als Benutzername und des opsi-host-Schlüssels als Passwort.
Vom opsi-configed aus geht dies über das Menü OpsiClient oder aus dem Kontextmenü des Client-Tabs.
Auch auf der Kommandozeile gibt es hierfür Entsprechungen:
shutdown:
opsi-admin -d method hostControlSafe_shutdown [hostIds]
reboot:
opsi-admin -d method hostControlSafe_reboot [hostIds]
Die Anpassung des Erscheinungsbildes des opsi-client-agent kann insbesondere bei der Einführung erheblich zur Akzeptanz beitragen. So kann z.B. durch das Einfügen eines bekannten Firmenlogos in die Hintergrundgrafiken eine Verunsicherung der Anwender vermieden werden.
Seit opsi-client-agent 4.0.7.16 basieren alle graphischen Komponenten des opsi-client-agent (notifier, opsi-script, kiosk-client) auf den Darstellungskomponenten zum Anzeigen von Grafiken und werden auf die selbe Weise angepasst.
Farben können auf drei unterschiedliche Weise angegeben werden: Als symbolischer Name (clRed
), als Hexadezimalwert ($FF00FF
) oder als rgb Wertliste ((255,0,0)
).
Ein Hilfsprogramm zur Auswahl von Farben und deren richtigen Schreibweise ist der opsi color chooser.
Als Hintergrund Grafikformate kommt eine Vielzahl unterschiedlicher Bitmap Formate wie .bmp, .png, jpeg usw in Frage. All dies Formate sind wieder Containerformate, dh. z.B. PNG ist nicht unbeding gleich PNG. Evtl ist das eine Darstellbar und das andere nicht. Ein Hilfsprogramm mit dem Sie schnell prüfen können ob eine gegeben Bitmap Grafik korrekt angezeigt werden wird, ist der opsi bitmap viewer.
Die Dateien, die Sie beim opsi-winst anpassen können finden Sie im Verzeichnis /var/lib/opsi/depot/opsi-client-agent/files/opsi/opsi-winst/winstskin
:
bg.png
skin.ini
angepasst werden.
skin.ini
Im Verzeichnis
/var/lib/opsi/depot/opsi-client-agent/files/opsi/dist/notifier
finden sich die Dateien welche das Erscheinungsbild der unterschiedlichen Notifier bestimmen. Dabei gibt es für jeden Notifier eine Bild- und eine Konfigurationsdatei:
block_login.bmp
block_login.ini
event.bmp
event.ini
action.bmp
action.ini
shutdown.bmp
shutdown.ini
popup.bmp
popup.ini
userlogin.bmp
userlogin.ini
Die Beschreibung in diesem Kapitel für den Kiosk gilt nur für opsi-client-agents <= 4.1.0.0. Ab Version 4.1.1.0 steht der Kiosk als seperates Paket zur Verfügung. Siehe hierzu Kapitel opsi Software On Demand - opsi Client Kiosk (frei)
Die Headerleiste des Hauptfensters (1) ist Kunden spezifisch anpassbar. Dabei spielen zwei Dateien eine Rolle:
opsiclientkiosk.png
opsiclientkiosk.ini
Die opsiclientkiosk.png
enthält das Bild welches in diesen Bereich geladen wird.
Die opsiclientkiosk.ini
definiert den Text und dessen Darstellung die in diesem Bereich angezeigt wird.
Beispiel:
[TitleLabel] Text= Opsi Client Kiosk FontName = Arial FontSize = 15 FontColor = clWhite FontBold = false FontItalic = false FontUnderline = false [Tile] Width = 220 Height = 200 Color = clCream FontName = Arial FontSize = 12 FontColor = clBlack FontBold = false FontItalic = false FontUnderline = false [TileRadio] Fontsize = 10 None_color = clBlack Uninstall_color = clRed Setup_color = clGreen
Templates für diese Dateien finden Sie unter /var/lib/opsi/depot/opsi-client-agent/files/opsi/opsiclientkiosk/opsiclientkioskskin
bzw. C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientkiosk\opsiclientkioskskin
Das jeweils verwendete Icon kann durch Ablegen einer kiosk.ico
Datei unter
/var/lib/opsi/depot/opsi-client-agent/files/opsi/custom/opsiclientkioskskin/
verändert werden.
(Seit opsi-client-agent Version 4.0.3.1)
Möchten Sie Änderungen, welche Sie an den oben genannten Dateien durchgeführt haben, davor schützen, dass selbige beim Einspielen einer neuen Version des opsi-client-agenten verloren gehen, so können Sie hierfür das custom
Verzeichnis (/var/lib/opsi/depot/opsi-client-agent/files/opsi/custom
) verwenden. Das komplette custom
Verzeichnis wird bei der Installation einer neuen Version des opsi-client-agenten gesichert und wieder hergestellt, so dass hier gemachte Änderungen bei einem Update nicht verloren gehen.
custom/config.ini
cfg/config.ini
. Ausnahme: die Werte für pckey
und bootmode
werden nie aus dieser Datei geholt. Schreiben Sie in diese Datei nur die Werte, die Sie tatsächlich gegenüber dem Default geändert haben wollen.
custom/winstskin/*.*
C:\Program Files (x86)\opsi.org\opsi-client-agent\custom\winstskin
kopiert. Falls vorhanden, wird (ab opsi-winst Version 4.11.3.4) dieses winstskin Verzeichnis bevorzugt verwendet. Es muss alle benötigten Dateien und Einträge vollständig enthalten, da die Inhalte des Standard-winstskin-Verzeichnisses bei Verwendung des custom/winstskin/
ignoriert werden.
custom/notifier/*.*
C:\Program Files (x86)\opsi.org\opsi-client-agent\notifier
kopiert und überschreiben dabei die entsprechenden aus dem serverseitigen Standard-Verzeichnis files/opsi/dist/notifier/
stammenden Dateien.
custom/opsiclientd.conf
C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd
kopiert und überschreibt dabei die aus dem serverseitigen files/opsi/dist/opsiclientd/
Verzeichnis stammende opsiclientd.conf
. Es werden also nicht einzelne Werte überschrieben, sondern die komplette Datei, die deshalb alle benötigten Einstellungen vollständig enthalten muss.opsiclientd.conf
über diese Methode wird nicht empfohlen. Verwenden Sie zur Konfiguration Ihrer Clients Hostparameter/Configs wie im Kapitel zum opsi-client-agent beschrieben. Die Verwendung einer custom/opsiclientd.conf
ist nur bei extrem komplexen Anpassungen der opsiclientd.conf sinnvoll. Wenn Sie diese Methode anwenden, müssen Sie bei jedem Einspielen einer neuen opsi-client-agent Version auf dem Server überprüfen, ob in der Default Datei files/opsi/dist/opsiclientd/opsiclientd.conf
Änderungen gemacht oder neue Einträge hinzugefügt wurden, welche Sie in Ihrer Version nachpflegen müssen. Also:custom/opsiclientkioskskin/*.*
Alle Dateien aus diesem Verzeichnis werden bei der Installation des opsi-client-agent auf dem Client nach C:\Pro
gram Files (x86)\opsi.org\opsi-client-agent\custom\opsiclientkioskskin kopiert. Falls vorhanden, wird dieses opsiclientkioskskin
Verzeichnis bevorzugt verwendet.
Die Beschreibung für den Kiosk gilt nur für opsi-client-agents <= 4.1.0.0. Ab Version 4.1.1.0 steht der Kiosk als seperates Paket zur Verfügung. Siehe hierzu Kapitel opsi Software On Demand - opsi Client Kiosk (frei)
Ein nachträgliches Rechte nachziehen hilft Folgefehler zu vermeiden:
opsi-setup --set-rights /var/lib/opsi/depot/opsi-client-agent
Um zu verhindern, dass sich ein Anwender schon vor dem Abschluss der Installation am System anmeldet, kann zusätzlich der opsi-Loginblocker installiert werden. Dieser gibt den Zugriff auf den Login erst frei, wenn der Installations-Prozess beendet ist.
Ob der opsi-Loginblocker während der opsi-client-agent-Installation installiert bzw. aktiviert wird,
kann über das Product-Property loginblockerstart
konfiguriert werden.
Der opsi-Loginblocker (opsigina.dll
) ist als GINA realisiert.
Die opsigina wartet bis zum Abschluss der Produktaktionen oder dem Timeout (standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd.
Danach wird die Kontrolle an die nächste GINA übergeben (in der Regel an die msgina.dll).
GINA steht hierbei für „Graphical Identification and Authentication“ und stellt die seitens Microsofts offiziell unterstützte Möglichkeit dar, in den Login-Prozess von Windows einzugreifen.
Gelegentlich ist es der Fall, dass bereits andere Softwareprodukte (z.B. Client für Novell-Netzwerke) eine GINA auf dem System installiert haben und empfindlich auf Eingriffe reagieren.
Generell sind mehrere ,nacheinander aufgerufene GINAs (GINA-chaining) durchaus möglich. Auch die opsigina.dll des opsi-Loginblocker ist für das genannte GINA-chaining vorbereitet. Sollte der beschriebene Fall bei Ihren Clients eintreten, informieren Sie sich bitte auf dem freien Supportforum (https://forum.opsi.org) nach bestehenden Anpassungsmöglichkeiten oder kontaktieren Sie die Firma uib.
Der opsi-Loginblocker für NT6 (Vista/Win7) ist als credential provider filter realisiert (OpsiLoginBlocker.dll). Er blockiert alle credential provider bis zum Abschluss der Produktaktionen oder dem Timeout (Standard-Wert: 120 Sekunden) bei nicht erreichbarem opsiclientd.
Die Anleitung zur nachträglichen Installation des opsi-client-agents finden Sie im Handbuch opsi-getting-started im Kapitel Erste Schritte.
Siehe aus Kapitel opsi Software On Demand (Kiosk-Mode): Abschnitt 9.17, „opsi Software On Demand - opsi Client Kiosk (frei)“
Um den opsi-client-agent über ein versiegeltes (sysprep) Masterimage zu verteilen, muss der opsi-client-agent sich beim aufwachen also beim personaliesieren des erstellten Klons auch neu personalisieren.
Dies geschieht am besten über eine Neuinstallation.
Dazu gehe Sie wie folgt vor:
Editieren Sie die Datei files\opsi\cfg\config.ini
:
[installation]
setzen Sie für service_user=
einen User, der Mitglied in der Gruppe opsi-admin ist.
[installation]
(nicht empfohlen) setzen Sie für service_password=
das Klartextpasswort des users. Besser:
[installation]
setzen Sie für service_hidden_password=
das base64 encodete passwort des users. Das encoden des Klartextpasswortes können sie über die entsprechende opsi-winst Funktion base64EncodeStr(<string>)
durchführen oder z.B. über http://www.base64encode.org/service_hidden_password=
einen Wert hat wird service_password=
ignoriert.
[opsiclientd]
setzen Sie für config_service.url =
die Webserviceadresse Ihres opsi-config-servers z.B. https://192.168.1.10:4447/rpc
silent_setup.cmd
aus dem temporären Verzeichnis aufgerufen wird.
silent_setup.cmd
kann das temporäre Verzeichnis gelöscht werden.
Wenn man möchte, kann man das Ganze in eine selbstextrahierende .exe-Datei mit Programmaufruf verpacken, bspw. über das Programm filzip.
Das Systray Programm des opsi-client-agent erfüllt folgende Aufgaben:
Steuerung des opsi systray Programms über die Produktproperties des Produkts opsi-client-agent:
systray_install
true
/ false
) Soll das opsi-systray Programm installiert werden ?false
systray_check_interval
180
(Kleine Werte hier, geben viel Last auf den Server)0
bedeutet, das keine regelmäßigen Prüfungen durchgeführt werden.
systray_request_notify_format
Logging des opsi systray Programms:
Das Programm loggt nach %Appdata%\opsi.org\log
. D.h. in das Verzeichnis opsi.org\log
im Anwendungsdatenverzeichnis des angemeldeten Users.
Zum Beispiel:
C:\Users\<username>\AppData\Roaming\opsi.org\log\
Siehe auch Kapitel opsi Software On Demand (Kiosk-Mode): Abschnitt 9.17, „opsi Software On Demand - opsi Client Kiosk (frei)“
bootmode= <bkstd | reins>
Diese Registry Einträge werden vom opsi-winst selbst verwaltet und sollten nicht verändert werden.
"LastLogFilename"="C:\\TMP\\syslogin.log" "ContinueLogFile"=dword:00000000 "RebootRequested"=dword:00000000 "SendLogToService"=dword:00000001 "NumberOfErrors"=dword:00000000 "ShutdownRequested"=dword:00000000
log_read
logType *extension *maxSize
Opsi ist ein mächtiges Werkzeug zur zentralen Administration vieler Clients. Damit steht der opsi-server natürlich auch im besonderen Fokus der Sicherheitsbetrachtung. Wer den opsi-server kontrolliert, kontrolliert auch die Clients. Wer einen Client davon überzeugen kann, er sei der richtige opsi-server, der kontrolliert den Client.
Wieviel Energie und Geld Sie in die Absicherung der opsi Infrastruktur stecken sollten hängt von Ihren Sicherheitsbedürfnis und vom Einsatzszenario ab. Ein opsi-server in der cloud ist z.B. gefährdeter als einer in einem abgeschlossenen Inselnetz.
Im Folgenden haben wir die wichtigsten uns bekannten Maßnahmen und Probleme zusammengetragen.
Wir danken an dieser Stelle allen Kunden und Anwendern die uns auf Probleme hingewiesen und damit zur Sicherheit beigetragen haben. Wir bitten Sie darum Probleme die Ihnen auffallen zunächst an info@uib.de zu melden bevor das Problem öffentlich gemacht wird.
Informationen über Security relevante opsi Updates werden veröffentlicht in:
News Bereich des opsi forums:
https://forum.opsi.org/viewforum.php?f=1
In der opsi Mailingliste:
https://lists.sourceforge.net/lists/listinfo/opsi-announce_de
Die opsi Software auf einem Server kann nicht sicherer als der Server selbst sein. Daher ist es wichtig, dass Sie Ihren opsi-server regelmäßig aktualisieren, d.h. die vom Distributor angebotenen Security Updates auch einspielen. Dies gilt sowohl für den opsi-configserver wie auch für die opsi-depotserver.
Sie können auf dem Server Programme installieren, welche Sie per E-Mail informieren wenn es Paketupdates gibt.
Darüber hinaus gibt es viele Möglichkeiten Linuxserver weiter abzusichern. Dies ist aber nicht das Thema dieses Handbuchs. Gerne beraten wir Sie hierzu im Rahmen eines Support- und Pflegevertrages.
Der Client authentifiziert sich beim Server mit seinem FQDN sowie dem opsi-host-key.
Client-seitig liegt dieser Key in der Datei %programfiles%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
und ist nur mit administrativen Rechten lesbar.
Serverseitig liegen die opsi-host-keys im jeweiligen Backend (z.B. unter /etc/opsi/pckeys
).
Zusätzlich zu dieser Authentifizierung kann der opsiconfd angewiesen werden, zu überprüfen ob die IP-Nummer unter der sich der Client meldet auch zu dem angegebenen Clientnamen passt.
Um dieses Verhalten zu aktivieren setzen sie in der /etc/opsi/opsiconfd.conf
folgenden Parameter:
verify ip = yes
und starten opsiconfd neu:
systemctl restart opsiconfd.service
Verwenden Sie diese Feature nur wenn Sie eine vollstängig funktionierende Namensauflösung (vorwärts wie rückwärts) für Ihre Clients haben.
Seit opsi 4.0.1 gibt es verschiedene Möglichkeiten den Client prüfen zulassen, ob der kontaktierte opsi-server vertrauenswürdig ist.
Bei der ersten Kontaktaufnahme zu einem opsi-server wird dessen SSL-Zertifikat akzeptiert und unter C:\opsi.org\opsiclientd\server-certs
abgespeichert.
Bei der nächsten Kontaktaufnahme wird der public key des gespeicherten Zertifikats ermittelt und mit diesem ein Zufallsstring sowie die eigenen Zugangsdaten verschlüsselt.
Diese Daten werden an den Server übergeben.
Der Server entschlüsselt mittels des private key seines SSL-Zertifikats diese Daten und sendet zum Beweis der erfolgreichen Entschlüsselung den Zufallsstring an den Client zurück.
Nach erfolgreicher Prüfung des zurückgegbenen Zufallsstrings erachtet der Client den Server als vertrauenswürdig.
Auf diese Weise kann verhindert werden, dass per Angriff auf das DNS opsi-clients falsche Server als opsi-server akzeptieren. Diese Methode minimiert das Risiko, dass bei einem Serverumzug Clients den neuen Server nicht mehr akzeptieren, da sich die Serverzertifikate von einem auf einen anderen Server übertragen lassen. Außerdem ist keine Verteilung einer certification authority (CA) notwendig.
Die Schwäche dieser Methode ist die Möglichkeit eines Man-in-the-middle Angriffs, da aus den oben genannten Gründen das Zertifikat keiner weiteren Prüfung unterzogen wird.
Die Prüfung betrifft die Webservice Kommunikation mit dem opsi-configserver.
Wird im Rahmen der opsi WAN-Erweiterung für die WAN-Clients als clientconfig.depot.protocol
webdav
verwendet, so wird auch der opsi-depotserver entsprechend geprüft. „Protokoll zum Zugriff auf ein opsi-depot“
Um diese Methode zu aktivieren, muss in der opsiclientd.conf
in der Sektion [global] folgende Option gesetzt werden:
verify_server_cert = true
Mit dem folgenden Befehl richten Sie den Konfigurationseintrag ein, so das er vom opsi-configed bearbeitet werden kann:
opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert "verify_server_cert" false
Aktivieren können Sie dies nun in dem Sie im opsi-configed in der Serverkonfiguration oder in den Hostparameter einzelner Clients den Wert von false auf true setzen.
Dies sollte nur gemacht werden, wenn man genau weiß, was man tut. Ansonsten ist die Gefahr groß, dass die Clients den Kontakt zum Server verweigern und somit abgehängt sind.
Dieser Mechanismus funktioniert analog zu der Art und Weise wie Browser die SSL-Zertifikate von Webservern prüfen. SSL-Zertifikate werden klaglos akzeptiert wenn diese auf genau den FQDN (bzw. Wildcard) ausgestellt sind unter dem der Server angesprochen wird und das Zertifikat von einer dem Browser bekannten CA signiert ist.
Der opsicliend enthält eine nur für diesen Zweck erstellte Root-CA der uib gmbh und akzeptiert Zertifikate, die durch die CA der uib gmbh signiert sind. Ebenso wird überprüft ob der commonName mit dem FQDN des Servers übereinstimmt. Ist eine der beiden Bedingungen nicht erfüllt, verweigert der Client die Kommunikation.
Diese Methode ist sicherer als die oben beschriebene, erfordert aber den Erwerb von Zertifikaten über die uib gmbh. Die Bedingungen und Preise zum Erwerb solcher Zertifikate erfahren Sie auf der Preisliste der uib gmbh. Die Überschüsse aus dem Zertifikatsverkauf fließen in die Pflege der opsi-Security.
Um diese Methode zu aktivieren, muss in der opsiclientd.conf
in der Sektion [global] folgender Parameter gesetzt werden:
verify_server_cert_by_ca = true
Mit dem folgenden Befehl richten Sie den Konfigurationseintrag ein, so das er vom opsi-configed bearbeitet werden kann:
opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert_by_ca "verify_server_cert_by_ca" false
Aktivieren können Sie dies nun in dem Sie im opsi-configed in der Serverkonfiguration oder in den Hostparameter einzelner Clients den Wert von false auf true setzen.
Dies sollte nur getan werden, wenn man genau weiß, was man tut. Ansonsten ist die Gefahr groß, dass die Clients den Kontakt zum Server verweigern und somit abgehängt sind.
Der opsiclientd besitzt eine Webservice-Schnittstelle die es erlaubt dem opsiclientd Anweisungen von aussen zu erteilen („Fernsteuerung des opsi-client-agent“).
Für den Zugriff auf den Webservice wird eine Authentifizierung benötigt. Dies geschieht entweder mittels des lokalen Administrator-Accounts (ein leeres Passwort ist unzulässig) oder mittels leerem Benutzernamen und dem opsi-host-Schlüssels als Passwort.
Die Idee eines Admin-Networks ist es, administrative Zugriffe auf Server nicht aus dem allgemeinen Produktiv-Netz zu erlauben, sondern nur von einem speziellen und abgesicherten Netzbereich.
Zwar müssen alle opsi-clients Zugang zum opsi-webservice haben, diese dürfen aber nur eingeschränkt Daten abrufen und ändern. Ein administrativer Zugang zum Webservice setzt die Mitgliedschaft in der Gruppe opsiadmin voraus.
Über die Option [global] admin networks
in der /etc/opsi/opsiconfd.conf
kann der administrative Zugriff auf den opsiconfd auf Verbindungen von bestimmten Netzwerkadressen eingeschränkt werden.
Es können mehrere Netzwerkadressen durch Kommas getrennt angegeben werden.
Nicht-administrative Client-Verbindungen können auch aus anderen Netzwerken erfolgen.
Der default ist:
admin networks = 0.0.0.0/0
und erlaubt Zugriff von allen Netzen.
Eine Konfiguration wie z.B.
admin networks = 127.0.0.1/32, 10.1.1.0/24
würde administrative Zugriffe nur vom Server selbst und aus dem Netz 10.1.1.0/24 erlauben.
Der user pcpatch dient in opsi 4 dem Mounten des depot-Shares (opsi_depot
) durch den Client.
Ausnahme hier von sind die Produkte:
opsi-wim-capture
und opsi-local-image-capture
welche als user pcpatch auch den share opsi_depot_rw
mit Schreibrechten mounten.
opsi-clonezilla
welches den share opsi_images
mit Schreibrechten mountet.
Das Passwort des Benutzers pcpatch wird in der Regel verschlüsselt abgelegt und auch nur verschlüsselt übertragen. Es existieren jedoch auch unter gewissen Umständen Möglichkeiten das Passwort in Erfahrung zu bringen. Um den Schaden der hierdurch entstehen kann zu minimieren empfehlen wir folgende Maßnahmen:
In der /etc/samba/smb.conf
in allen Share-Definitionen ausser opsi_depot dem user pcpatch den Zugriff verbieten über den Eintrag:
invalid users = root pcpatch
Alternativ
In der /etc/samba/smb.conf
dem User pcpatch auf Leserechte beschränken durch den Eintrag in der [global] Sektion:
read list = pcpatch
Für die Produkte opsi-wim-capture
und opsi-local-image-capture
muß der share opsi_depot_rw
für pcpatch beschreibbar sein. Für das Produkt opsi-clonezilla
muß der share opsi_images
beschreibbar sein.
Als weitere Maßnahme sollten Sie das Passwort des Users pcpatch öfters ändern. Da das Klartext-Passwort niemandem bekannt sein muss, kann es z.B. durch den regelmäßigigen Aufruf (z.B. per cronjob) des folgenden Scriptes auf ein zufälliges Passwort setzen.
opsi-admin -d task setPcpatchPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)
Falls Sie keine Netboot-Produkte verwenden, welche eine Anmeldung am Server als Benutzer pcpatch benötigen, so können Sie zusätzlich die Anmeldung des Benutzer pcpatch am Server unterbinden.
Dazu weisen Sie in der Datei /etc/passwd
dem Benutzer pcpatch die Shell /bin/false
zu.
Seit opsi 4.1 wird der Benutzer pcpatch standardmäßig mit der Shell /bin/false
angelegt. Handlungsbedarf besteht hier nur, falls das System mit einer früheren Version installiert wurde.
In der Datei /etc/opsi/backendManager/acl.conf
kann der Zugriff auf
bestimmte Methoden und Attribute der zurückgegebenen Werte beschränkt werden.
Die Beschränkung greift auf die Basis-Methoden des Webservices, für welche eingeschränkt werden kann welche Benutzer oder Gruppen zugreifen dürfen sowie für welche Attribute der Zugriff erlaubt ist.
Der Zugriff sollte für eine Absicherung auf eine Freigabe der verwendeten Methoden beschränkt werden. Falls unklar ist welche Methoden verwendet werden, so kann dazu die Ausgabe des opsiconfd über die aufgerufenen Methoden herangezogen werden, welche im Falle eines Neustarts oder Stops des Dienstes in der Datei /var/log/opsi/opsiconfd/opsiconfd.log
ausgegeben werden.
Weitere Informationen zu den Methoden des Webservice sind unter Abschnitt 5.4.1, „Web service / API Methoden seit opsi 4.0“ zu finden.
Das root Passwort des bootimages ist per default linux123. Dies sollte aus Gründen der Sicherheit geändert werden. Wie das geht ist beschrieben in: Abschnitt 8.2.1, „Parametrisierung vom Linux Installationsbootimage“
Als Localboot-Produkte werden alle Produkte bezeichnet, die nach einem lokalen Boot des Rechners über den opsi-client-agent installiert werden. Dies im Gegensatz zu den weiter unten beschriebenen Netboot Produkten Abschnitt 8.2, „Netboot Produkte“.
Die folgenden Localboot Produkte gehören zur Grundausstattung von opsi.
Der opsi-client-agent ist der Clientagent von opsi und weiter oben ausführlich beschrieben: siehe Kapitel Abschnitt 6.1, „opsi-client-agent“.
Das Produkt opsi-winst ist ein Spezialfall. Es enthält den aktuellen opsi-winst. Dieser muss zur Aktualisierung nicht auf setup gestellt werden. Vielmehr prüft ein Teil der opsi-client-agent bei jedem Start, ob auf dem Server eine andere Version des opsi-winst verfügbar ist und holt sich diese im Zweifelsfall.
Das Produkt javavm stellt die für den opsi-configed benötigte Java Laufzeitumgebung für die Clients zur Verfügung.
opsi Graphical Management Interface als Applikation Für Windows und Linux. Siehe auch Kapitel: Kapitel 4, opsi-Management GUI: opsi-configed
Die Produkte hwaudit und swaudit dienen der Hard- bzw. Software-Inventarisierung. Bei der Hardware-Inventarisierung werden die Daten über WMI erhoben und über den opsi-webservice an den Server zurück gemeldet. Bei der Software-Inventarisierung werden die Daten aus der Registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) erhoben und über den opsi-webservice an den Server zurück gemeldet.
Template zur Erstellung eigener opsi-Scripts. Sie können das Template extrahieren mit
opsi-package-manager -x opsi-template_<version>.opsi
oder auch dabei gleich umbenennen mit
opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod
Siehe auch opsi-getting-started Manual.
Template zur Erstellung eigener opsi-Scripts. Sie können das Template extrahieren mit
opsi-package-manager -x opsi-template_<version>.opsi
oder auch dabei gleich umbenennen mit
opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod
Siehe auch opsi-winst-manual / opsi-script-manual
Kapitel: Skript für Installationen im Kontext eines lokalen Administrators
Große Sammlung von opsi-script Selbsttests. Diese kann als Beispielsammlung für funktionierende Aufrufe von opsi-script Befehlen verwendet werden.
Siehe auch Kapitel: Abschnitt 9.4, „opsi WIM Capture“
Produkt zur einfachen Erzeugung eine opsi-winpe Siehe auch opsi-getting-started Manual, Kapitel Erstellen eines PE.
Siehe auch Kapitel: Abschnitt 9.6, „opsi mit UEFI / GPT“
Siehe auch Kapitel: Abschnitt 9.21, „opsi Setup Detector (frei)“
Text viewer mit Filter nach Loglevel und Events.
Für Windows und Linux.
Konfiguriert verschiedene Windows 10 Einstellungen wie z.B. Sperrbildschirm, Hibernationboot, Telemetrie und Update-Verhalten.
In der Version 4.0.7 kamen neue Deaktivierungsmöglichkeiten hinzu.
[ProductProperty] type: bool name: disable_fast_boot description: Disable Fastboot for proper opsi startup default: True [ProductProperty] type: bool name: disable_lock_screen default: True [ProductProperty] type: bool name: disable_telemetry description: Disable telemetry data transmission default: True [ProductProperty] type: bool name: disable_cortana description: Disable Cortana assistant default: True [ProductProperty] type: bool name: disable_customer_experience description: Disable customer experience program default: True [ProductProperty] type: bool name: disable_mrt description: Disable Malicious Software Removal Tool default: True [ProductProperty] type: unicode name: config_updates multivalue: False editable: False description: Set Windows-Update behavior values: ["AllowPeerToPeer", "LocalPeerToPeer", "MicrosoftOnly"] default: ["MicrosoftOnly"] [ProductProperty] type: bool name: disable_mac description: Disable Microsoft Account communication default: False [ProductProperty] type: bool name: disable_advertising_id description: Disable Microsoft Advertising ID default: False [ProductProperty] type: bool name: disable_updates description: Disable Windows Updates default: False [ProductProperty] type: bool name: disable_defender description: Disable Microsoft Windows Defender default: False [ProductProperty] type: bool name: disable_wifi_sense description: Disable Wi-Fi Sense default: False [ProductProperty] type: bool name: disable_sending_feedback description: Disable sending feedback and diagnostics default: False [ProductProperty] type: bool name: disable_font_streaming description: Disable font streaming of not installed fonts default: False [ProductProperty] type: bool name: defer_upgrade description: Defer Windows 10 Upgrade default: True [ProductProperty] type: bool name: flashplayer_autorun description: Adobe Flashplayer: allow autorun? default: False [ProductProperty] type: bool name: location_sensors description: Disable location and sensor detection default: True [ProductProperty] type: bool name: online_search description: Disable online search during file or command search default: True [ProductProperty] type: bool name: disable_handwrite_sharing description: Tablet-PC: Disable sharing of handriting information default: True [ProductProperty] type: bool name: sync_settings description: Sync settings with AccountID default: False
opsi-auto-update ist ein Produkt, um die Pflege der Clents zu vereinfachen.
Im Kern ist es die Aufgabe des Produktes, dafür zu sorgen, die installierten Produkte aktuell zu halten.
Das Produkt setzt alle installierten Produkte,
deren Version nicht identisch mit der auf dem Server ist,
für den Client auf setup.
Properties zur Behandlung von Ausnahmen:
name: products_to_exclude
name: products_to_exclude_by_regex
name: products_to_include
Properties zur Behandlung von Ergänzungen:
name: products_to_run_always
name: setup_after_install
Properties zur Ablaufsteuerung:
name: shutdown_on_finish
Special Properties für local-image / vhd-reset:
siehe auch: Abschnitt 9.9, „opsi vhd reset“
siehe auch: Abschnitt 9.8, „opsi local image“
name: do_cleanup
opsi-vhd-control
aufgerufen und dadurch alle Änderungen verworfen und der gespeicherte Zustand wieder hergestellt.opsi-local-image-restore
aufgerufen und dadurch alle Änderungen verworfen und der gespeicherte Zustand wieder hergestellt.opsi-auto-update
Produkte hinzuzufügen oder entfernen zu können, gibt es die folgenden beiden Properties.
name: products_to_install
name: products_to_uninstall
name: do_merge
opsi-vhd-control
mit upgrade=true
aufgerufen und dadurch alle Änderungen gespeichert.opsi-local-image-backup
aufgerufen und dadurch alle Änderungen gespeichert.
Properties zu Debug-Zwecken (Finger weg):
disabled
rebootflag
stop_after_step
Das Produkt opsi-auto-update
hat eine sehr niedrige Priorität (-97),
welche noch geringer ist als die von opsi-vhd-control.
Das opsi-Produkt opsi-auto-update
kann gut mit einem cron-job der das skript wake_clients_for_setup.py
ausführt kombiniert werden.
(https://download.uib.de/opsi4.1/misc/time-driven-maintenance-tools/wake_clients_for_setup.py)
Zur Dokumentation siehe hier: Abschnitt 5.10.1, „Der cronjob wake_clients_for_setup.py, opsi-auto-update und working_window“
Seit opsi 4.0 wird die Installationsreihenfolge vom opsi-server unter Berücksichtigung von Produktabhängigkeiten und Produktprioritäten berechnet.
Wie diese beiden Faktoren gegeneinander gewichtete werden sollen, kann unterschiedlich gesehen werden. Daher stellt opsi zwei Algorithmen zur Verfügung.
Die Umstellung zwischen diesen Algorithmen erfolgt entweder:
im opsi-configed, in der Server-Konfiguration
oder auf der Kommandozeile mit folgendem Befehl:
opsi-setup --edit-config-defaults
Bei diesem Algorithmus werden zunächst die Produkte anhand Ihrer Prioritäten sortiert und dann aufgrund der Produktabhängigkeiten nochmals umsortiert. Hierdurch kann natürlich ein Produkt mit sehr niedriger Priorität weit nach vorne geschoben werden, weil es von einem anderen Produkt als required before benötigt wird. Auf der anderen Seite wird vermieden, dass es zu Installationsproblemen aufgrund nicht aufgelöster Produktabhängigkeiten kommt.
Der Algorithmus 1 sorgt dafür, das die Installationsreihenfolge konstant ist, unabhängig davon wieviele Produkte auf setup stehen. Diese Reihenfolge entspricht der Reihenfolge, welche im configed angezeigt wird wenn die Produkte nach der Spalte Position sortiert werden.
Damit ist gesichert, dass
bei einer mit "ExitWindows /immediateReboot" nur unterbrochenen Abarbeitung eines setup-Skripts nach dem Reboot
direkt die Bearbeitung des unterbrochenen Skripts weitergeführt wird.
Dieser Algorithmus geht von dem Gedanken aus, dass es in der Praxis im wesentlichen drei Prioritätsklassen gibt:
Die Auflösung der Produktabhängigkeiten erfolgt nur innerhalb einer Prioritätsklasse. Hierdurch ist sichergestellt, dass Produkte mit einer hohen Priorität auch tatsächlich am Anfang installiert werden. Prioritätsklassen übergreifende Produktabhängigkeiten werden nicht berücksichtigt bzw. führen zu einer Warnung. Daher ist beim Packen zu beachten, dass Produktabhängigkeiten nur innerhalb einer Prioritätsklasse definiert werden.
Die Produktabhängigkeiten werden hier so interpretiert, dass sie bei "normalen" Produkten automatisch zu einer konsistenten, alle Abhängigkeiten berücksichtigenden Reihenfolge führen. Wurden widersprüchliche (zirkuläre) Abhängigkeiten definiert, wird ein Fehler angezeigt.
Bei den für die PC-Einrichtung grundlegenden Produkten mit hohen Prioritäten wird dagegen der Administrator – ähnlich wie etwa bei Unix-Startskripten – die genaue Reihenfolge von Hand festlegen, indem er pro Produkt entsprechend der gewünschten Reihenfolge je eine spezifische Priorität zwischen +100 und +1 setzt. Ähnliches gilt für die finalen Produkte mit niedrigen Prioritäten.
Prioritäten und Produktabhängigkeiten gehören zu den Meta-Daten eines Produktes. Diese werden bei der Erstellung eines Produktes mit dem Befehl opsi-newprod
abgefragt.
Diese Metadaten werden im control file des Produktes abgelegt und können dort editiert werden. Nach einer Veränderung im control file muss das Produkt neu gepackt und installiert werden.
Siehe hierzu auch das Kapitel Erstellen eines opsi-Product-Paketes im opsi-getting-started Handbuch.
Das opsi-linux-bootimage hat eine Reihe von Standardeinstellungen, welche das Verhalten beeinflussen.
Sollte nach dem Laden des Bootimages der Bildschirm schwarz bleiben oder die Netzwerkkarte nicht (korrekt) funktionieren, so muss evtl. für diese Hardware die Startparameter des Bootimages angepasst werden.
Dies können Sie im opsi-configed im Tab Hostparameter am Eintrag opsi-linux-bootimage.append tun.
Typische Werte sind hier (einzeln oder kombiniert):
acpi=off
noapic
irqpoll
reboot=bios
Für AMD Ryzen 2XXX Prozessoren empfiehlt es sich, die Parameter
mem=2G
ramdisk_size=2097152
einzusetzen. AMD Ryzen 3XXX ist zusätzlich der Parameter
nomodeset
nötig um die grafische Ausgabe zu korrigieren.
Eine weitere wichtige Standardeinstellung ist das Passwort von root im Bootimage. Dieses ist per default linux123 und sollte aus Sicherheitsgründen ebenfalls auf diesem Weg abgeändert werden.
Um diese angesprochenen Modifikationen durchzuführen, muss man die Konfiguration: opsi-linux-bootimage.append am besten in der Serverkonfiguration anpassen.
Die hier wichtige Option ist pwh. Dieser Option muss man das verschlüsselte Passwort als Hash-Wert mitgeben. Dieser wird dann automatisch beim Booten in die Datei /etc/shadow geladen. Somit wird, bevor ein Login auf dem Client möglich ist, das Passwort verändert. Um diesen Hash zu bekommen, gibt es verschiedene Wege. Um sicher zu gehen, dass man den richtigen Hash in der richtigen Formatierung und Art (MD5, SHA1, etc…) bekommt, empfehlen wir folgendes Vorgehen.
Möchte man ein Python Skript vor dem eigentlichen Netboot Produkt starten gibt es noch die Parameter:
pre-execute
pre-script
Als Zusatz benötigen die Parameter noch eine Adresse, von der das entsprechende Skript gezogen werden soll. Dies kann eine http:// oder tftp:// Adresse sein. Hier ein Beispiel:
tftp://172.16.166/linux/test.py
Es ist zu beachten, dass der Port für die Kommunikation mit dem tftp-Server standardmäßig auf 69 gestellt ist.
Einen opsi-Client per PXE oder mit der aktuellen opsi-client-boot-cd starten. Dann per Putty oder direkt vom opsi-server aus per ssh als root eine Verbindung aufbauen. Vom opsi-server aus:
ssh root@<client.domain.tld>
Das Passwort lautet linux123. Dann einfach das Passwort von root neu setzen:
passwd
Nun muss man den gesetzten Hash holen.
grep root /etc/shadow
Die Ausgabe sollte nun folgendermaßen aussehen:
root:$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz/:14803:0:99999:7:::
Um das Passwort zu setzen, reicht es, wenn man den Hash kopiert, der nach dem ersten Doppelpunkt beginnt und beim zweiten Doppelpunkt in der Zeile aufhört. Die daraus resultierende Option für die Konfiguration opsi-linux-bootimage.append wäre:
pwh=$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz/
Ablauf einer Reinstallation:
Bei PXE-Boot:
Bei CD-Boot:
Der Client-PC sollte mit einer bootfähigen Netzwerkkarte ausgestattet sein. Viele heute eingesetzte Netzwerkkarten verfügen über eine entsprechende PXE-Firmware. Diese kontrolliert den Bootvorgang vom Netz, falls nicht eine andere Reihenfolge im BIOS eingestellt ist. Ist kein PXE vorhanden kann alternativ kann auch von der opsi-client-boot-cd das Bootimage gebootet werden.
Das opsi-Installationspaket für das zu installierende Betriebssystem muss auf dem opsiserver installiert sein. In den folgenden Abschnitten wird als Beispiel jeweils Windows 10 angenommen.
Die Firmware des PXE wird beim Starten eines PCs aktiv: sie „kann“ dhcp und führt die Abfragen im Netz durch.
Der PC kennt zu Beginn lediglich seine Hardware-Adresse (= hardware ethernet, MACNummer der Netzwerkkarte), bestehend aus sechs zweistelligen Hexadezimalzeichen.
Die Firmware schickt damit eine Rundfrage ins Netz. Es ist eine *DHCPDISCOVER*Anfrage über Standard-Port per Broadcast (= an alle Rechner im Netz): „Ich brauche eine IP-Nummer und wer ist mein dhcp-Server?“ (Discover= entdecken)
Mittels DHCPOFFER macht der dhcp-Server diesbezüglich einen Vorschlag. (offer=anbieten)
DHCPREQUEST ist die Antwort des Clients an den Server (wenn er die angebotene IP akzeptiert; Hintergrund ist hier: Es können in einem Netz mehrere dhcp-Server tätig sein.). Der Client fordert damit die angebotene Adresse an. (request=Anfrage)
Mit DHCPACK bestätigt der dhcp-Server diese Anforderung des Clients. Die Informationen werden an den Client übertragen. (acknowledge=bestätigen)
Am Bildschirm des bootenden PCs können diese Prozesse mitverfolgt werden. Nach
den ersten Systeminformationen meldet sich das PXE-BOOTPROM mit seinen technischen Daten und stellt seine „CLIENT MAC ADDR“ dar. Im Anschluss zeigt ein sich drehendes Pipe-Zeichen die Dauer der Anfrage des Clients an. Wird das bewegliche Zeichen durch einen Backslash ersetzt, hat der dhcp-Server ein Angebot gemacht („CLIENT IP, MASK, DHCP IP, GATEWAY IP“).
Kurze Zeit später – wenn alles funktioniert hat – meldet das PXE: „My IP ADDRESS
SEEMS TO BE …"
Nach dem Empfang und der Verarbeitung dieser Konfigurationsinformationen durch den PC ist dieser als Netzwerkteilnehmer ordentlich konfiguriert. Der nächste Schritt ist, das in den Konfigurationsinformationen angegebene Bootfile (bootimage) zu laden.
Das Bootimage wird per tftp (trivial file transfer protocol) geladen. (Meldung auf dem PC-Bildschirm: „LOADING“). Das Protokoll tftp ist zum Übertragen von Dateien, bei dem sich der Client nicht authentifizieren muss. Das heißt, die über tftp ladbaren Dateien sind für alle im Netz verfügbar. Daher wird der Zugriff per tftp auf ein bestimmtes Verzeichnis (mit Unterverzeichnissen) beschränkt. Gewöhnlich ist dieses Verzeichnis /tftpboot. Konfiguriert ist dies in der Konfigurationsdatei des x/inetd (/etc/inetd.conf), der den eigentlichen tftpd bei Bedarf startet. (z.B. tftpd -p -u tftp -s /tftpboot
).
Der Ladevorgang gemäß dem PXE-Standard ist dabei mehrstufig:
In der ersten Stufe wird die per tftp übermittelte Datei (üblicherweise /tftpboot/linux/pxelinux.0) geladen und gestartet.
Das Programm pxelinux.0 sucht bei Ausführung im Verzeichnis /tftpboot/linux/pxelinux.cfg nach Konfigurations- bzw. Bootinformationen. Dabei wird zunächst nach PC-spezifischen Informationen gesucht. Eine solche PC-spezifische Datei basiert auf der Hardwareadresse (MAC-Adresse) der Netzwerkkarte im Dateinamen.
Die Datei ist eine Einweg-Datei (named pipe) und kann daher nur einmal
gelesen werden. Der Hardwareadresse im Dateinamen werden dabei immer die zwei
Ziffern 01 vorangestellt. Alle Zeichenpaare werden durch ein Minuszeichen verknüpft, z.B. 01-00-0c-29-11-6b-d2 für eine Netzwerkkarte mit MAC: 00:0C:29:11:6B:D2. Wird eine solche Datei nicht gefunden wird nach einer Datei gesucht deren Namen der Hexadezimaldarstellung der IP-Adresse entspricht. Ist auch keine solche PCspezifische Datei vorhanden, wird pxelinux.0 den Dateinamen (von hinten beginnend) immer weiter verkürzt suchen, bis die Suche ergebnislos verlaufen ist und bei der Datei default endet. Diese Datei enthält den Befehl localboot 0 Lädt der PC diese Datei, findet also keine Installation statt, sondern das lokal installierte Betriebssystem wird gestartet.
Um für einen bestimmten PC eine Reinstallation einzuleiten, wird das Programm
pxelinux.0 dazu gebracht, in einer zweiten Stufe ein Installationsbootimage zu laden.
Dazu wird mit Hilfe des opsipxeconfd eine PC-spezifische Datei in /tftpboot/linux/pxelinux.cfg
erzeugt, in der unter anderem der Befehl zum Laden des eigentlichen Installationsbootimages liegt. Weiterhin findet sich hier der PC-spezifische Schlüssel zur Entschlüsselung des pcpatch-Passwortes. Diese Datei wird als named pipe erzeugt und ist damit eine Einweg-Datei die durch einmaliges Lesen von selbst verschwindet. Details hierzu in den Kapiteln zur Absicherung der Shares und zum opsipxeconfd.
Linux Installationsbootimage wird geladen
Basierend auf den Informationen die das pxelinux.0 aus der named pipe gelesen hat, wird nun per tftp vom opsi-server das eigentliche Installationsbootimage geladen. Dieses besteht üblicherweise aus dem Kernel (/tftpboot/linux/install)
in dem dazugehörigen "initrd" (initiale root disc) Filesystem (/tftpboot/linux/miniroot.bz2)
.
Das Bootimage, das nun geladen wird, ist Linux basiert.
Analog zu dem Bootvorgang per tftp mit Hilfe des PXE-bootproms kann das Bootimage auch direkt von der opsi-client-boot-cd geladen werden.
Diese Möglichkeit bietet sich bei folgenden Voraussetzungen an:
Entsprechend der unterschiedlichen Situationen müssen dem Bootimage auf der CD unterschiedlich viele Informationen interaktiv bereitgestellt werden. Im einfachsten Fall müssen überhaupt keine Angaben gemacht werden.
Lesen Sie hierzu auch das Kapitel Anlegen eines neuen opsi-Clients mit Hilfe der opsi-client-bootcd in Getting-Started Handbuch.
Das Bootimage startet eine erneute dhcp-Anfrage und konfiguriert sich entsprechend sein Netzwerkinterface. Danach werden über den opsi-webservice die Konfigurationsdaten für diesen Client geladen.
Abbildung 8.6. Ueber PXE-Boot geladenes Bootimage bereitet Festplatte zur Betriebssysteminstallation vor
Ergänzt wird dieses Informationspaket durch Angaben aus der dhcp-Antwort (z.B. wer ist der tftp-Server) sowie mit über den Webservice ermittelte Informationen. Die gesammelten Informationen werden für die Weiterverarbeitung durch das eigentliche Installationsskript bereitgestellt.
Nun wird das Passwort des Installations-Users pcpatch mit Hilfe des übergebenen Schlüssels entschlüsselt und der angegebene Installationsshare gemountet. Jetzt kann das auf dem gemounteten Share liegende Installationsskript für das zu installierende Betriebssystem gestartet werden. Die Abläufe in diesem Skript sind abhängig von dem zu installierenden Betriebssystem. Im Folgenden werden beispielhaft die Abläufe für eine Windows-10-Installation skizziert.
Vorbereitung der Festplatte: Auf der Platte wird eine 4 GB große FAT32 Partition angelegt, formatiert und bootfähig gemacht. Sofern nicht anders angegeben, wird der Rest der Festplatte mit einem NTFS Dateisystem formatiert. Auf diese Partition wird das Betriebssystem installiert.
Kopieren der Installationsdateien: Die Dateien für die Installation des Betriebssystems werden von dem Installationsshare des Servers (z.B. /var/lib/opsi/depot/win10/installfiles) auf die lokale Platte kopiert. Das Gleiche gilt für das Setup-Programm des 'opsi-client-agent’s zur Einrichtung der automatischen Softwareverteilung auf dem PC.
Einpflegen der Konfigurationsinformationen: Unter den auf die lokale Platte kopierten Dateien finden sich auch Konfigurations- und Steuerdateien, die Platzhalter enthalten. Durch ein spezielles Skript (patcha) werden diese durch entsprechende Parameter aus dem Informationspaket ersetzt (gepatcht). Ein Beispiel für eine zu patchende Datei ist die unattend.xml. Sie steuert das „unbeaufsichtigte“ Installieren von Windows.
Reboot vorbereiten: Der Bootloader wird so konfiguriert, dass beim nächsten Boot der Rechner via ntloader in das Windows Setup-Programm startet. Der Aufruf ist dabei mit der Option versehen, die gepatchte unattend.xml als Steuerdatei zu verwenden.
Reboot: Da in /tftpboot/linux/pxelinux.cfg
nun keine PC-spezifische Datei mehr vorhanden ist, wird in Stufe 1 des PXE-Boots der Befehl hdboot aus der Datei default geladen. Damit wird der lokale Bootloader gestartet und die Betriebssysteminstallation gestartet.
Die beschriebenen Abläufe werden von dem für diese Installation angegebenen Python-Script gesteuert.
Die Installation des Betriebssystems ist ein unattended Setup wie es von Microsoft vorgesehen ist. Dabei werden die Standardmöglichkeiten der Hardwareerkennung genutzt. Im Gegensatz zu einer normalen Installation von CD können auf der Installations-Partition schon aktualisierte Treiber und Servicepacks eingepflegt werden, damit diese schon direkt bei der Erstinstallation verwendet werden.
Zu einer unattended Installation gehört die Möglichkeit, nach Abschluss der eigentlichen Betriebssysteminstallation automatisch noch weitere Installationen starten zu können. Dieser Mechanismus wird genutzt, um das Setup des 'opsi-client-agent’s auszuführen und damit die automatische Softwareverteilung einzubinden. In der Registry wird eingetragen, dass sich der Rechner immer noch im Reinstallationsmodus befindet.
Nach dem abschließenden Reboot starten nun vor einem Login die opsi-Programme zur Softwareverteilung. Diese Software erkennt anhand der Registry den Reinstallationsmodus. Dieser Modus hat hier zur Folge, dass alle Softwarepakete, für welche der Installationsstatus installed oder die angeforderte Aktion setup/update ist, nun installiert werden. Auf diese Weise werden sämtlich Pakete, die vor der Reinstallation des Betriebssystems auf diesem PC waren, automatisch wieder eingespielt. Erst nach Abschluss aller Installationen wird der Reinstallationsmodus zum Standard-Bootmodus zurückgeschaltet. (Im Gegensatz zum Reinstallationsmodus, werden im Standard-Bootmodus nur Pakete installiert, bei denen die Angeforderte Aktion setup/update ist.) Damit ist der PC fertig installiert.
Wie oben erläutert werden vom Bootimage (genauer gesagt vom Programm
/usr/local/bin/master.py
) die Konfigurationsinformationen aus dem opsi-webservice und dhcp gesammelt, um sie dann in entsprechende andere Konfigurationsdateien wie z.B. die unattended.xml einzupflegen. Das Einpflegen übernimmt das Programm /usr/local/bin/patcha
.
Das Skript gleicht anhand eines Suchmusters @flagname() eine Konfigurationsdatei mit den Einträgen aus einer anderen Datei (hier cmdline) ab, die Einträge der Art "Flagname=Wert" enthalten muss und patcht diese bei Übereinstimmung des Suchmusters. Das Suchmuster kann nach dem Flagnamen einen "" enthalten und muß einen oder beliebig viele "#" als Abschluß enthalten. Die zu patchenden Parameter werden aus den Properties des jeweiligen Netboot-Produkts gelesen und in eine Variable im Bootimage geschrieben.
Usage: patcha [-h|-v] [-f <params file>] <patch file> Fill placeholders in file <patch file> Options: -v Show version information and exit -h Show this help -f <params file> File containig key value pairs If option not given key value pairs from kernel cmdline are used
patcha
patcht nur einen Tag pro Zeile.
Der Platzhalter wird auf die Länge des zu ersetzenden Wertes getrimmt bzw erweitert und dann ersetzt. D.h unabhängig von der Länge des Platzhalters wird dieser durch den Wert ersetzt. Anhängende Zeichen bleiben anhängend.
Beispiel:
Mit der Datei
cat try.in tag1=hallohallohallo1 tag2=t2
und der Datei
cat patch.me <#@tag1##########################> <#@tag2##########################> <#@tag1#> <#@tag2#> <#@tag1*##########################> <#@tag2*##########################> <#@tag1*#> <#@tag2*#> <#@tag1#><#@tag1#####> <#@tag2*#######><#@tag1#>
ergibt
./patcha -f try.in patch.me cat patch.me <hallohallohallo1> <t2> <hallohallohallo1> <t2> <hallohallohallo1> <t2> <hallohallohallo1> <t2> <hallohallohallo1><#@tag1#####> <t2><#@tag1#>
Die Informationen zum Aufbau der Produkte zur unattended Installation finden Sie im Handbuch opsi-getting-started.
Voraussetzungen. Alle Netbootprodukte der Version >= 4.1.0.0 benötigen einen auf dem Server installierten opsi-winst >= 4.12.0.13. Diese Netbootprodukte laufen auch unter opsi 4.0.x.
Multidiskmode. Der neue Multidiskmode bietet eine Unterstützung der Betriebssystem Installation auf Systemen mit mehreren Festplatten.
Dabei kann gezielt die gewünschte Zielfestplatte ausgewählt werden.
Es kann auch gezielt die erste SSD oder die erste rotierende Festplatte ausgewählt werden.
Der Multidiskmode ist nur implementiert für die Property-Einstellung: winpenetworkmode = true.
Wenn Sie auf einem Rechner mit MBR BIOS über das Property multidiskmode
eine Platte wählen, so müssen Sie dafür sorgen, das diese Platte auch die erste Platte in der BIOS Bootreihenfolge ist.
Bei UEFI BIOS Systemen müssen Sie nichts unternehmen, da hier die Bootreihenfolge durch die Installation gesteuert werden kann.
Verhalten im PE. Bei der Windows Betriebssystem Installation wird durch das opsi-linux-bootimage
die Festplatte vorbereitet und ein Win-PE Partition erstellt. Diese wird gebootet um die eigentliche Windowsinstallation zu starten.
In den 4.1.0.0 Produkten wird hier opsi-script gestartet um die notwendigen Arbeiten durch zu führen. Die Vorteile dieses Vorgehens sind:
NT6 Productproperties. Die Netbootprodukte zur Installation von NT6 Betriebssystemen enthalten eine Fülle von Produktproperties, welche in Ihrer Funktion in der Folge erläutert werden sollen:
<productid>\drivers\drivers\additional
. Alle Treiberverzeichnisse unterhalb der angegebenen Verzeichnisse werden unabhängig von der automatischen Treibererkennung zusätzlich in die Installation mit eingebunden.
Wird hierüber Treiber für ein Gerät eingebunden, so wird für dieses Gerät kein weiterer Treiber über die automatische Treiberintegration mehr eingebunden.
license-management.use
auf false steht. Ansonsten wird der Lizenzschlüssel aus dem Lizenzmanagement geholt.
Das Produkt hwinvent dient dazu eine Hardwareinventariserung des Clients durchzuführen.
Zur Inventarisierung stehen die Localbootprodukte hwaudit
und swaudit
sowie das Netboot Produkt hwinvent
zur Verfügung.
Die Hardwareinventarisierung ist unter opsi über eine Konfigurationsdatei gesteuert. Das bedeutet, das die Information wie und welche Daten erhoben werden, nicht in den entsprechenden Produkten hwaudit
und hwinvent
fest verdrahtet sind. Vielmehr werden diese Produkte über eine Konfigurationsdatei gesteuert. Dazu wird die Konfigurationsdatei bei jeder Ausführung über den opsi Webservice eingelesen und interpretiert. Gleichzeitig steuert diese Konfigurationsdatei auch den Aufbau der Datenbank, so dass eine Erweiterung dieser Konfigurationsdatei auch eine Erweiterung der Datenhaltung nach sich zieht.
Die Konfigurationsdatei ist die /etc/opsi/hwaudit/opsihwaudit.conf
.
In dieser Datei werden alle zu Inventarisierenden Objekte definiert und beschreiben, wie die zu diesem Objekt gehörenden Daten zu erheben sind (unter Linux und unter Windows). Gleichzeitig wird darüber auch die dazu gehörige Datenstruktur definiert.
Zur Vereinfachung enthält diese Konfigurationsdatei Vererbungsmechanismen die an eine Objektorientierung angelehnt sind. Hintergrund hierfür ist die Tatsache, dass viele Objekte identische Datenfelder wie z.B. Name
und Vendor
enthalten. Diese allgemeinen Informationen werden so in virtual Hardwareklassen definiert. Die eigentlichen Inventarisierungsobjekte sind dann structural Hardwareklassen, welche viele Eigenschaften von übergeordneten virtual Klassen erben können.
Zur Erläuterung dieses Mechanismus ein Beispiel:
So definiert die Knfigurationsdatei zunächste eine virtual Class Namens "BASIC_INFO". Diese definiert die Eigenschaften (Values):
Als nächstes folgt die virtual Class Namens "HARDWARE_DEVICE" welche alle Eigenschaften von "BASIC_INFO" erbt und folgende zusätzliche definiert:
Als nächstes folgt als erstes Objekt welche wir in der Inventarisierung auch finden, die erste structural Class Namens "COMPUTER_SYSTEM", welche alle Eigenschaften von "HARDWARE_DEVICE" erbt und folgende zusätzliche definiert bzw. überschreibt:
Im Rahmen der Definition einer Klasse und ihrer Values werden verschiedene Eigenschaften beschrieben:
Klassen definition:
Weiterhin können in der Klassendefinition angegeben werden, wie diese Daten erhoben werden. Diese Informationen können aber auch bei der Definition der Values stehen.
Für die Inventarisierung unter Linux:
Für die Inventarisierung unter Windows:
Value Definition:
/etc/opsi/hwaudit/locales
wiederum lokalisiert werden.
Hierzu als Beispiel die Klasse "COMPUTER_SYSTEM":
{ "Class": { "Type": "STRUCTURAL", "Super": [ "HARDWARE_DEVICE" ], "Opsi": "COMPUTER_SYSTEM", "WMI": "select * from Win32_ComputerSystem", "Linux": "[lshw]system" }, "Values": [ { "Type": "varchar(100)", "Scope": "i", "Opsi": "name", "WMI": "Name", "Linux": "id" }, { "Type": "varchar(50)", "Scope": "i", "Opsi": "systemType", "WMI": "SystemType", "Linux": "configuration/chassis" }, { "Type": "bigint", "Scope": "i", "Opsi": "totalPhysicalMemory", "WMI": "TotalPhysicalMemory", "Linux": "core/memory/size", "Unit": "Byte" }, { "Type": "varchar(50)", "Scope": "i", "Opsi": "dellexpresscode", "Condition": "vendor=[dD]ell*", "Cmd": "#dellexpresscode\dellexpresscode.exe#.split('=')[1]", "Python": "str(int(#{'COMPUTER_SYSTEM':'serialNumber','CHASSIS':'serialNumber'}#,36))" } ] },
Besonders interessant ist hier der letzte Value "dellexpresscode":
Dieser ist nur sinnvoll, wenn es sich auch um einen Dell-Rechner handelt, daher die Condition.
Unter Windows wird das Kommandozeilen Programm dellexpresscode.exe
ausgeführt, welches sich von der hwaudit.exe
aus gesehen im Unterverzeichnis dellexpresscode\
befindet. Diese produziert eine Ausgabe in der Form: dellexpresscode=123456789. Durch den hinter dem Platzhalter befindlichen .split('=')[1]
wird der Wert hinter dem Gleichheitszeichen verwendet.
Unter Linux wird geprüft in welchem Element (COMPUTER_SYSTEM oder CHASSIS) bei serialNumber ein Wert gefunden wurde, und dieser dann zur Berechung des Dell expresscodes verwendet.
Die Opsi-Namen der Values werden über die Dateien /etc/opsi/hwaudit/locales/*
übersetzt.
Bsp. /etc/opsi/hwaudit/locales/de_DE
:
COMPUTER_SYSTEM = Computer COMPUTER_SYSTEM.systemType = Typ
Der Klassenname COMPUTER_SYSTEM wird übersetzt in "Computer". Das Opsi-Attribut "systemType" der Klasse COMPUTER_SYSTEM wird übersetzt in "Typ". Abschliessend noch der Hinweis: Wenn ein neues Feld erzeugt wird, sollte man dieses in den locale-Dateien anlegen, auch wenn man den Begriff selber nicht übersetzt. Dadurch wird vermieden, dass bei der Laufzeit "Warning" Meldungen produziert werden.
Nachdem Sie die Konfigurationsdatei und die locales modifiziert haben müssen Sie noch den nachfolgenden Aufruf tätigen, damit die Änderungen auch in die Datenbank übernommen werden:
opsi-setup --init-current-config
Weiterhin müssen Sie im opsi-configed die Daten komplett neu laden: Datei/Alle Daten neu laden.
Der Quellcode diese Paketes ist zu finden auf Github: opsi-org/hwaudit
Die Softwareinventarisierung findet über das Localbootprodukt swaudit
statt. Dabei werden die Informationen aus dem Uninstallzweig der Registry erhoben und durch zusätzliche Informationen zu Hotfixes und Lizenzkeys ergänzt.
Der Quellcode diese Paketes ist zu finden auf Github: opsi-org/swaudit
Zur Bereitstellung der benötigten Pakete können Sie diese manuell herunterladen oder aber alle Pakete nach Anpassung der Konfiguration des opsi-package-updater
über diesen installieren.
Für den weiteren Betrieb ist es empfohlen, die Repository-Konfiguration in /etc/opsi/package-updater.repos.d/ abzulegen. Eine entsprechende Konfigurationsdatei erhalten Sie mit Ihren Zugangsdaten.
Bei Bedarf muss in diesen Dateien noch der Zugang über einen Proxy konfiguriert werden!
Es bietet sich anschließend an, gezielt nur die benötigten Pakete aus den neuen Repositories zu installieren:
# Beispiel: Pakete für mshotfix, Plattform Windows 7 x64 / Server 2008 R2 und Windows 10 / 2016 / 2019 x64 installieren opsi-package-updater --repo uib_abo_mshotfix install mshotfix mshotfix-win7-win2008r2-x64-glb mshotfix-win10-win2016-x64-glb # Beispiel: Pakete für msoffice Office 2016 installieren opsi-package-updater --repo uib_abo_msoffice install office_2016_hotfix # Beispiel: Pakete für standard produkte firefox und libreoffice installieren opsi-package-updater --repo uib_abo_standard install firefox libreoffice
Es ist möglich, gezielt benötigte Pakete zu installieren, bspw. nur die Pakete für das Update von Windows 7:
opsi-package-updater -v install mshotfix mshotfix-win7-x86-glb mshotfix-win7-win2008r2-x64-glb
Für die Aktualisierung der Pakete wird der opsi-package-updater
empfohlen.
Mittels Aufruf von opsi-package-updater -v update
können dann z.B. per Cronjob die installierten Pakete aktualisiert werden.
Eine gleichwertige Variante ist, für jedes Repository die Pakete gezielt zu aktualisieren:
# Pakete für mshotfix aktualisieren opsi-package-updater --repo uib_abo_mshotfix update # Pakete für msoffice aktualisieren opsi-package-updater --repo uib_abo_msoffice update # Pakete für standard produkte aktualisieren opsi-package-updater --repo uib_abo_standard update
Bei der nichtinteraktiven Installation von opsi-Paketen werden auf einem opsi-configserver bzw. einem opsi-server die Paket default-Properties als default festgelegt.
Ab opsi Version 4.0.5 können die opsi-server-default-Properties über das Managementinterface opsi-configed festgelegt werden.
Bei einer anschliessenden Installation einer neueren Paketversion mittels opsi-package-manager
oder opsi-package-updater
bleiben die eingestellten depot default Properties erhalten.
Regelmäßige Updates des Produktes mshotfix (Hotfixes für Windows 7 / 2008-R2, Windows 8.1 / 2012-R2, Windows 10 / Windows 2016).
Von Microsoft nicht mehr unterstützte Versionen werden als "failed" angezeigt: 1507 "non"-ltsb, 1511 und 1607 "non"-ltsb außer Education und Enterprise
Das Update erscheint jeweils innerhalb von 3 Arbeitstagen nach dem Erscheinen eines von Microsoft als wichtig oder kritisch eingeschätzten Patches.
https://www.microsoft.com/de-de/msrc/security-update-severity-rating-system
Bewertung | Beschreibung |
---|---|
Kritisch | Hierbei handelt es sich um ein Sicherheitsrisiko, bei dessen Ausnutzung Code ohne Benutzerinteraktion ausgeführt werden könnte. Dieses ist beispielsweise in Fällen von sich selbstständig verbreitender Schadsoftware wie Netzwerkwürmer oder nicht vermeidbaren Nutzungsfällen gegeben, bei denen Code ohne Warnungen oder Eingabeaufforderungen ausgeführt werden kann. Darunter kann das Öffnen einer Webseite oder E-Mail fallen. Microsoft empfiehlt Kunden, kritische Updates sofort anzuwenden. |
Wichtig | Hierbei handelt es sich um ein Sicherheitsrisiko, dessen Ausnutzung die Vertraulichkeit, Integrität oder Verfügbarkeit von Benutzerdaten oder die Integrität oder Verfügbarkeit von Verarbeitungsressourcen gefährden kann. Darunter können häufige Nutzungsfälle fallen, z. B., dass der Client mit Warnungen oder Eingabeaufforderungen kompromittiert wird (unabhängig von Herkunft, Qualität oder Nützlichkeit der Aufforderung). Auch sequenzielle Benutzeraktionen, die keine Eingabeaufforderungen oder Warnungen generieren, sind eingeschlossen. Microsoft empfiehlt Kunden, wichtige Updates so früh wie möglich anzuwenden. |
Mittel | Die Auswirkung des Sicherheitsrisiko wird durch Faktoren wie Authentifizierungsanforderungen oder eine ausschließliche Anwendbarkeit auf nicht dem Standard entsprechende Konfigurationen erheblich verringert. Microsoft empfiehlt Kunden dennoch, diese Sicherheitsupdates anzuwenden. |
Niedrig | Die Auswirkung des Sicherheitsrisikos wird durch die Eigenschaften der betroffenen Komponente erheblich verringert. Microsoft empfiehlt Kunden, zu evaluieren, ob das Sicherheitsupdate auf die betroffenen Systeme angewendet werden soll. |
Das opsi-mshotfix Paket verwendet (wie WSUS Offline Update http://forums.wsusoffline.net/viewtopic.php?f=7&t=172 Abdeckung des / Coverage of WSUS Offline Update ) für den Download Microsoft’s Update-Katalogdatei wsusscn2.cab, um die erforderlichen Patches zu ermitteln. Diese Katalogdatei enthält mindestens alle als „kritisch“ und „sicherheitsrelevant“ eingestuften Updates, aber nicht notwendigerweise alle „wichtigen“ und „optionalen“.
Die opsi mshotfix-Pakete sind modular aufgebaut. Das Basis-Paket „mshotfix“ beinhaltet nur ein Skript zum Installieren der Patches. Die eigentlichen Patches sind gesondert in separaten Paketen enthalten.
Tabelle 8.1. mshotfix Client-Betriebssystem Voraussetzung
OS |
Windows 7 SP1 / Windows 2008 R2 SP1 |
Windows 8 / Windows 2012 |
Windows 8.1 / Windows 2012 R2 |
Windows 10 / Windows 2016 / Windows 2019 |
Wan/VPN Modul Die Pakete für Windows 8.1 / 2012 R2 benötigen opsi-winst >= 4.11.3.11-1 und opsi-client-agent >= 4.0.4.4-1
Wan/VPN Modul Die Pakete für Windows 10 /2016 benötigen opsi-client-agent >= 4.0.7.9-2
Wan/VPN Modul Die modularen Pakete für Windows 10 / 2016 / 2019 benötigen opsi-client-agent >= 4.1.0.0-27 bzw. opsiclientd >= 4.0.95
Auf unserem Download-Server ist die Struktur des Abo verzeichnisses
mshotfix !-opsi4/ !-glb/ Basis-Paket mshotfix sowie globale Patchpakete mshotfix-win7-x86-glb mshotfix-win7-win2008r2-x64-glb mshotfix-win8-win2012-x64-glb mshotfix-win81-x86-glb mshotfix-win81-win2012r2-x64-glb mshotfix-win10-win2016-x64-glb mshotfix-win10-x86-glb mshotfix-win10-1507-x64-glb (seit 201904-1) mshotfix-win10-1507-x86-glb (seit 201904-1) mshotfix-win10-1607-x64-glb (seit 201904-1) mshotfix-win10-1607-x86-glb (seit 201904-1) mshotfix-win10-1703-x64-glb (seit 201904-1) mshotfix-win10-1703-x86-glb (seit 201904-1) mshotfix-win10-1709-x64-glb (seit 201904-1) mshotfix-win10-1709-x86-glb (seit 201904-1) mshotfix-win10-1803-x64-glb (seit 201904-1) mshotfix-win10-1803-x86-glb (seit 201904-1) mshotfix-win10-1809-x64-glb (seit 201904-1) mshotfix-win10-1809-x86-glb (seit 201904-1) mshotfix-win10-1903-x86-glb (seit 201904-1) mshotfix-win10-1903-x64-glb (seit 201904-1) !-misc/ diverse zusätzliche Pakete dotnetfx dotnetfx-hotfix mshotfix-uninstall ms-ie11 ms-optional-fixes silverlight
Folgende Tabelle soll bei der Auswahl der richtigen Pakete helfen:
Tabelle 8.2. mshotfix Client-Betriebssystem
OS | Arch | Patch-Paket |
Windows 7 | 32Bit | mshotfix-win7-x86-glb |
Windows 7 | 64Bit | mshotfix-win7-win2008r2-x64-glb |
Windows 2012 | 64Bit | mshotfix-win8-win2012-x64-glb |
Windows 8.1 | 32Bit | mshotfix-win81-x86-glb |
Windows 8.1 | 64Bit | mshotfix-win81-win2012r2-x64-glb |
Windows 2008 Server R2 | 64Bit | mshotfix-win7-win2008r2-x64-glb |
Windows 2012 R2 | 64Bit | mshotfix-win81-win2012r2-x64-glb |
Windows 10 | 32Bit | mshotfix-win10-x86-glb oder das passende modulare Paket |
Windows 10 | 64Bit | mshotfix-win10-win2016-x64-glb oder das passende modulare Paket |
Windows 2016 | 64Bit | mshotfix-win10-win2016-x64-glb oder mshotfix-win10-1607-x64-glb |
Windows 2019 | 64Bit | mshotfix-win10-win2016-x64-glb oder mshotfix-win10-1809-x64-glb |
Installation:
opsi-package-manager -i mshotfix_201008-1.opsi
zum Scharfschalten (überall auf setup stellen, wo das Produkt auf installed steht):
opsi-package-manager -iS mshotfix_201008-1.opsi
Zusätzlich zum Basis-Paket werden die Patch-Pakete auf die gleiche Weise installiert. Da diese Pakete aber keine Installationsskripte enthalten, sind sie nur zusammen mit dem Basis-Paket einzuspielen, d.h. man kann diese nicht separat auf setup stellen. Für die Client-Installation ist komplett das mshotfix-Basispaket zuständig.
Seit Paket mshotfix 201304-1 werden sich durch mshotfix installierte Patches in der Datei C:\opsi.org\mshotfix\deployed.txt
lokal gemerkt.
mshotfix-uninstall 201512-1 MS Hotfix BasePackage
Entfernt Patches mittels wusa /uninstall ...
die sich mit dieser Methode deinstallieren lassen.
dotnetfx 4.7.2-3 .NET Framework
Paket zur Installation der Dotnet Framework Versionen 4.5 und höher insbesondere auf Windows 7 / 2008 R2 / 8.1 / 2012 R2 / 10 Auf Windows Versionen (neuer Windows 7) kann auch Dotnet 3.5 installiert werden.
dotnetfx-hotfix 201808-1 dotnetfx-hotfix
Im Update-Abo MS-Hotfixes sind die Hotfixes für Microsoft .NET Framework nur enthalten, falls es passend zum jeweiligen Betriebssystem ist.
Also z.B. bei Windows 7 "Microsoft .NET Framework 3.5.1"
( Allerdings gibt es seit Oktober 2016 unter Umständen auch "Monthly Rollups" für DotnetFramework, die im mshotfix-Paket enthalten sind.)
Das Paket dotnetfx-hotfix beinhaltet die Hotfixes von Microsoft für
Das Paket dotnetfx-hotfix patcht zur Zeit - so vorhanden - die Versionen 4.x auf den jeweils letzten Stand der Reihe.
Bitte beachten Sie: "Support for .NET Framework 4, 4.5, and 4.5.1 ended on January 12, 2016" (https://support.microsoft.com/en-us/lifecycle?p1=14380)
bzw. https://support.microsoft.com/en-us/gp/framework_faq/de
ms-ie11 11.0-11 Internet Explorer 11
Win7 Internet Explorer 11
ms-optional-fixes 201808-1 MS optional fixes
Gedacht als Ergänzung zu mshotfix und basiert auf mshotfix.
Enthält:
kb2999226 für win7-win8.1
Regelmäßige Updates für MS-Office 2010/2013/2016 32 Bit sowie MS-Office 2016 64 Bit.
Das Update erscheint jeweils innerhalb von 3 Arbeitstagen nach dem Erscheinen eines von Microsoft als wichtig oder kritisch eingeschätzten Patches.
Tabelle 8.3. Office hotfix Voraussetzung
Office Version | required |
Office 2010 32-bit | Service Pack 2 |
Office 2013 32-bit | Servicepack 1 |
Office 2016 |
office_2010_hotfix 201808-1 Microsoft Office 2010 Hotfixes
Enthält sprachunabhängige monatliche Office 2010 Hotfixes (inclusive Visio und Project 2010). Setzt Servicepack 2 voraus.
Wird getestet gegen Office 2010 Professional und Standard.
Seit Paket office_2010_hotfix 201305-2 werden sich durch office_2010_hotfix installierte Patches in der Datei C:\opsi.org\mshotfix\office_2010_hotfix_deployed.txt
lokal gemerkt.
Seit office_2010_hotfix 201503-1:
office_2013_hotfix 201808-1 Microsoft Office 2013 Hotfixes
Enthält sprachunabhängige monatliche Office 2013 Hotfixes (inclusive Visio 2013). Setzt Servicepack 1 voraus.
Wird getestet gegen Office 2013 Professional
Durch office_2013_hotfix installierte Patches in der Datei C:\opsi.org\mshotfix\office_2013_hotfix_deployed.txt
lokal gemerkt.
Seit office_2013_hotfix 201503-1:
office_2016_hotfix 201808-1 Microsoft Office 2016 Hotfixes
Enthält sprachunabhängige monatliche Office 2016 Hotfixes (inclusive Visio 2016).
Wird getestet gegen Office 2016 Professional
Durch office_2016_hotfix installierte Patches in der Datei C:\opsi.org\mshotfix\office_2016_hotfix_deployed.txt
lokal gemerkt.
Passen Sie das repo uib_abo_msoffice update an: x3264 / x64
Regelmäßige Updates der Produkte:
Adobe Reader DC Classic / Continuous (international, 32 Bit) Adobe Flashplayer (international, 32 Bit / 64 Bit) Apache OpenOffice.org (deutsch, 32 Bit) Google Chromium for business (international, 32 Bit / 64 Bit) LibreOffice (international, 32 Bit / 64 Bit) Mozilla Firefox (deutsch, englisch, französisch und niederländisch, 32 Bit) bzw. 32/64-Bit Pakete seit 201706 Mozilla Thunderbird (deutsch, englisch und französisch, 32 Bit) Java VM (javavm) basierend auf Open JDK LTS 11 (international, 64 Bit) Java VM 8 (javavm8) basierend auf Open JDK LTS 8 (international, 32 Bit / 64 Bit) Java VM (javavm-oracle-jdk) OpenJDK basierend auf der aktuellen open jdk implementation (international, 64 Bit)
Je nach Vertrag stellen wir noch folgende Sprachen im Abo zur Verfügung:
Mozilla Firefox (zusätzlich dänisch, italienisch, spanisch, tschechisch und norwegisch / 32 Bit) Mozilla Thunderbird (zusätzlich italienisch / 32 Bit)
weitere Sprachen auf Anfrage.
Das Update erscheint jeweils innerhalb von 2 Arbeitswochen nach dem Erscheinen eines Updates dieser Produkte; bei vom Hersteller als kritisch eingestuften Security-Updates innerhalb von 1 Arbeitswoche.
Für die Pakete
adobe.reader.dc.classic adobe.reader.dc.continuous firefox flashplayer thunderbird
gibt es die Möglichkeit eigene Konfigurationen zu erstellen und im Verzeichnis custom
zu hinterlegen,
die über Properties auswählbar sind. (Näheres siehe unten)
Für die Pakete
adobe.reader.dc.classic firefox (ab 17.0.6esrorstandard-1) flashplayer (ab 13.0.0.182or11.7.700.275-1) google-chrome-for-business javavm (ab javavm_1.7.0.51-5 ) javavm8 javavm-oracle-jdk libreoffice (ab libreoffice_4.3.5or4.4.0-2) ooffice (ab ooffice_4.1.1-2) thunderbird (ab 17.0.6esrorstandard-1)
besteht die Möglichkeit, eigene custom-Scripte einzubauen im Verzeichnis custom\scripts
.
Einfache Templates für die unterstützen Scripte finden sich im Verzeichnis opsi\scripts
.
custom.actions.post.setup custom.actions.post.uninstall custom.actions.pre.setup custom.actions.pre.uninstall custom.declarations custom.sections custom scripts will be included in - setup-script - uninstall-script custom pre-scripts will be included in - setup-script - uninstall-script custom post-scripts will be included in - in setup-script - uninstall-script custom.declarations ; intended for declaration of custom Variables and Stringlist Variables ; will be included with "include_insert" at top of [actions] ; but after GetProductProperties custom.sections ; intended for declaration of custom secondary sections ; will be included with "include_append" at top of [actions] ; but after GetProductProperties custom.actions.pre.setup (or custom.actions.pre.uninstall) ; will be included with "include_insert" at at top of [actions] ; (but after GetProductProperties) custom.actions.post.setup (or custom.actions.post.uninstall) ; will be included with "include_insert" in case of successful installation before "endof_"actions" ; in setup-script ( or uninstall-script)
adobe.reader.dc.classic 20151500630493or20171701130138-1 Adobe Acrobat Reader DC classic
Das adobe.reader.dc.classic-Paket beinhaltet Adobe Acrobat Document Cloud Classic (MUI-Version)
Adaptation in the transform file *.mst
cat transform.txt Changes vs default the transform file *.mst Personalisation Options Suppress Eula Installation Options acivated - Make Reader the default PDF viewer IF REBOOT REQUIRED - suppress reboot Shortcuts deactivated - Destination Computer/Desktop/Adobe Reader XI (Icon) Online and Acrobat.com Features Online Features activated - Disable product updates Enable & Ask before Installing - Load trusted root certificates from Adobe Online Services and Features disable product updates Load trusted root certificates from Adobe disable DISABLE all Services
opsi_depot
im Verzeichnis /var/lib/opsi/depot/adobe.reader.dc.classic/custom
eigene MST-Dateien abgelegt werden, die über dieses
Property ausgewählt werden können (nach erneutem Einspielen des Pakets mittels opsi-package-manager -i <adobe-paket>
).
Beim Einspielen des adobe.reader.dc.classic-Pakets auf dem opsi-Server wird das Verzeichnis custom ueber ein preinst/postinst-Script gesichert.
Bei Einsatz des Wan/VPN Moduls muss nach Änderungen im Verzeichnis custom
das Paket neu eingespielt werden, damit die Datei <productid>.files
neu erzeugt wird.
adobe.reader.dc.continuous 201901020099-1 Adobe Acrobat Reader DC Continuous
Das adobe.reader.dc.continuous-Paket beinhaltet Adobe Acrobat Document Cloud Continuous (MUI-Version)
Adaptation in the transform file *.mst
cat transform.txt Changes vs default the transform file *.mst Personalisation Options Suppress Eula Installation Options acivated - Make Reader the default PDF viewer IF REBOOT REQUIRED - suppress reboot Shortcuts deactivated - Destination Computer/Desktop/Adobe Reader (Icon) Online and Acrobat.com Features Online Features activated - Disable product updates Enable & Ask before Installing - Load trusted root certificates from Adobe Online Services and Features disable product updates Load trusted root certificates from Adobe disable DISABLE all Services
opsi_depot
im Verzeichnis /var/lib/opsi/depot/adobe.reader.dc.continuous/custom
eigene MST-Dateien abgelegt werden, die über diese
Property ausgewählt werden können (nach erneutem Einspielen des Pakets mittels opsi-package-manager -i <adobe-paket>
)
Beim Einspielen des adobe.reader.dc.continuous-Pakets auf dem opsi-Server wird das Verzeichnis custom ueber ein preinst/postinst-Script gesichert.
Bei Einsatz des Wan/VPN Moduls muss nach Änderungen im Verzeichnis custom
das Paket neu eingespielt werden, damit die Datei <productid>.files
neu erzeugt wird.
flashplayer 32.0.0.171-1 Adobe Flashplayer
Das flashplayer-Paket beinhaltet Adobe Flashplayer in der von Adobe unterstützten Version.
Die zentrale Konfigurationsdatei mms.cfg wird bei jedem neu "auf setup" setzen neu erstellt und gemaess den Produktproperties angepasst (Ausnahme: Verwendung einer custom mms.cfg) Bei leeren Werten werden keine Eintraege gemacht. Seit Version 13.0.0.250-2 besteht die Möglichkeit abweichend davon eine custom mms.cfg bereitzustellen
/var/lib/opsi/depot/flashplayer/custom
eigene mms.cfg -Dateien abzulegen, die über diese Property ausgewählt werden können (nach erneutem Einspielen des Pakets mittels opsi-package-manager -i <flashplayer-paket>
).
Beim Einspielen des flashplayer-Pakets auf dem opsi-Server wird das Verzeichnis custom ueber ein preinst/postinst-Script gesichert.
Bei Einsatz des Wan/VPN Moduls muss nach Änderungen im Verzeichnis custom
das Paket neu eingespielt werden, damit die Datei <productid>.files
neu erzeugt wird.
Weitere Einstellungen ausser Verwendung der Property autoupdatedisable werden dann nicht verwendet.
Weitere Hinweise siehe:
Adobe Flashplayer Admin Guide:
flash_player_11_1_admin_guide.pdf (flash_player_admin_guide.pdf) ##################################### Chapter 4: Administration You can create and place files on the end user’s machine to manage features related to security, privacy, use of disk space, and so on. Privacy and security settings (mms.cfg) As a network administrator, you can install Flash Player across the enterprise while enforcing some common global security and privacy settings (supported with installation-time configuration choices). To do this, you install a file named mms.cfg on each client machine. The mms.cfg file is a text file. When Flash Player starts, it reads its settings from this file, and uses them to manage functionality as described in the following sections. mms.cfg file location Assuming a default Windows installation, Flash Player looks for the mms.cfg file in the following system directories: 32-bit Windows - %WINDIR%\System32\Macromed\Flash 64-bit Windows - %WINDIR%\SysWow64\Macromed\Flash Note: The %WINDIR% location represents the Windows system directory, such as C:\WINDOWS.
description: 1 (Acrobat.exe,Acroread.exe,WINWORD.EXE,EXCEL.EXE,POWERPNT.EXE,PPTVIEW.EXE,OUTLOOK.EXE,MSACCESS.EXE,VISIO.EXE,thunderbird.exe) values: ["0", "1"] default: ["1"]
Bekannte Probleme
google-chrome-for-business 73.0.3683.103-1
Das Paket beinhaltet den msi-Installer von Google (Häufig gestellte Fragen Chrome for Business https://support.google.com/a/answer/188447).
Bemerkungen:
Die Deinstallation und Installation des google-chrome.msi schlägt manchmal fehl.
Daher gibt es verschiedene Ansätze im opsi-Paket, um die Zuverlässigkeit der Installation zu erhöhen.
Ein Kunde berichtete von einer Erfolsquote von 100% bei 40 Installationen mit folgender Einstellung der Properties:
install_architecture
: 32
reboot_on_retry
: True
reboot_after_uninstall
: True
timeout
: 240
Intern verwenden wir für Tests:
* install_architecture
: system specific
* reboot_on_retry
: True
* reboot_after_uninstall
: True
* timeout
: notimeout
gibt es 0,1,2,3 als Wert für HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\UpdateDefault
bzw ADM falls Gruppenrichtlinien verwendet werden
ADM= use Policy based on Googles Template, 0=UpdatesDisabled, 1=UpdatesEnabled, 2=ManualUpdatesOnly, 3=AutomaticUpdatesOnly, values: ["0", "1", "2", "3", "ADM"] default: ["0"]
ooffice 4.1.6-1 Apache OpenOffice
Das ooffice-Paket beinhaltet Apache OpenOffice in deutsch.
libreoffice 6.0.6or6.1.0-2 LibreOffice
Das libreoffice-Paket beinhaltet LibreOffice international.
firefox 60.6.1esror66.0.3-1
Das firefox-Paket beinhaltet Mozilla Firefox in den Sprachen deutsch, englisch, französisch und niederländisch.
Es werden alle von Mozilla unterstützten Versionen bereitgestellt.
Firefox kann zentral konfiguriert werden
a) entweder über eine zentrale Konfigurationsdatei mozilla.cfg
(vgl. http://kb.mozillazine.org/Locking_preferences)
b) oder über eine policies.json
(vgl. https://github.com/mozilla/policy-templates/blob/master/README.md)
die in folgendem Verzeichnis abzulegen ist:
/var/lib/opsi/depot/firefox/custom/
Bei erneutem Einspielen des Pakets mittels opsi-package-manager -i <firefox-paket>
werden die gefundenen Konfigurationsdateien über preinst-/postinst-Mechanismus erhalten und dann über das Property "mozillacfg" auswählbar.
Beispiel:
cat /var/lib/opsi/depot/firefox/custom/mozilla.cfg // lockPref("browser.startup.homepage", "http://www.uib.de"); lockPref("network.proxy.type", 1); lockPref("network.proxy.http", "router.uib.local"); lockPref("network.proxy.http_port", 3128);
Alternativ zu einer mozilla.cfg kann man auch eine mit dem CCK2 erstellte autoconfig.zip über das Property "mozillacfg" einbinden.
Bei Einsatz des Wan/VPN Moduls muss nach Änderungen im Verzeichnis custom
das Paket neu eingespielt werden, damit die Datei <productid>.files
neu erzeugt wird.
(off/direct/manual/file) proxy einstellungen verändern
%scriptpath%\custom
-directory, http://kb.mozillazine.org/Locking_preferences
enable or disable Profilemigrator on first run values: ["off", "on"] default: ["off"]
Bekannte Probleme
thunderbird 60.6.1-1
Das thunderbird-Paket beinhaltet Mozilla Thunderbird in den Sprachen deutsch, englisch und französisch.
Es werden alle von Mozilla unterstützten Versionen bereitgestellt.
Analog dem Firefox-Paket kann zentrale Konfigurationsdatei bereitgestellt werden.
https://developer.mozilla.org/en/Addons/Add-on_Manager/AddonManager
http://mike.kaply.com/2012/02/09/integrating-add-ons-into-firefox/
Set_Netscape_User_Pref ("extensions.autoDisableScopes", 11) Set_Netscape_User_Pref ("extensions.shownSelectionUI", true)
%scriptpath%\custom
-directory, http://kb.mozillazine.org/Locking_preferences
description: Install calender plugin lightning values: ["off", "on"] default: ["off"]
Bekannte Probleme
javavm 11.0.3-1 JDK 11
Das javavm Paket enthält die Open JDK 11 LTS Implementationen von SAP (SapMachine) und Amazon (Amazon Corretto), da Oracle keine frei verfügbare JAVA-Runtime mehr zur Verfügung stellt (seit Anfang Januar 2019).
(Oracle announced "End Of Public Updates Februar 2019" http://www.oracle.com/technetwork/java/eol-135779.html)
javavm8 1.8.0.212or1.8.0.201-1 JDK 8 LTS
Das javam8 Paket enthält die Open JDK 8 LTS Implementationen von Amazon (Amazon Corretto) und ojdkbuild (https://github.com/ojdkbuild/ojdkbuild). Letzteres enthält eine auf Iced-Tea basierende Webstart-Komponente.
javavm-oracle-jdk 12.0.1-1 Open JDK
Das javavm-oracle-jdk Paket enthält die aktuelle Open JDK Implementation von Oracle http://jdk.java.net/
Auch wenn opsi Open Source ist, so gibt es einige Zusatzkomponenten, die im Rahmen eines Kofinanzierungsprojektes erstellt wurden bzw. gepflegt werden und (noch) nicht kostenlos sind.
Zur Zeit (Dezember 2016) sind dies:
Mehr Informationen zu diesem Thema finden Sie unter opsi-Erweiterungen als Kofinanzierungsprojekte.
Solange die Zusatzkomponenten den Cofunding-Status besitzen, können Sie nur zur Evaluation frei genutzt werden, zur dauerhaften regulären Verwendung sind jedoch die Cofunding-Beiträge zu zahlen.
Die Zulässigkeit der Verwendung von Modulen ist auf dem opsi-Server in der Freischaltdatei /etc/opsi/modules
festgelegt.
Es handelt sich um eine einfache Textdatei mit der Information, welches Modul (für
wie viele Clients) aktiviert ist. Die Datei ist gegen Veränderung geschützt durch eine digitale Signatur. Bei fehlenden Angaben
wird von den Defaultwerten ausgegangen. Fehlt die Freischaltdatei komplett, sind nur die standardmäßigen freien Komponenten von opsi aktiv.
Bei einer befristeten Freischaltung ist in der Datei die Befristung enthalten.
Um zu Evaluierungszwecken eine zeitlich befristet gültige Freischaltdatei zu erhalten, wenden Sie sich an info@uib.de. Im Rahmen einer Beteiligung an den entsprechenden Kofinanzierungsprojekten erhalten Sie eine Freischaltdatei zur dauerhaften und regulären Nutzung der freigeschalteten Komponenten.
Wenn Sie eine modules
-Datei erhalten haben, kopieren Sie sie nach /etc/opsi
.
Führen Sie danach den folgenden Befehl aus, um korrekte Zugriffsrechte zu setzen:
opsi-setup --set-rights /etc/opsi
Starten Sie danach noch den opsiconfd neu.
Kontrollieren Sie die Freischaltung mit einer der folgenden Methoden:
Im opsi-configed können Sie über den Menüpunkt Hilfe / Installierte opsi-Module sich den Status Ihrer Freischaltung anzeigen lassen.
Mit der Methode backend_info
können Sie mit opsi-admin überprüfen, welche Module freigeschaltet sind.
Geben Sie weder die Datei noch die Ausgabe dieses Befehls öffentlich weiter, zumindest nicht ohne die Signatur zu löschen.
$ opsi-admin -d method backend_info { "opsiVersion" : "4.0.1", "modules": { "customer" : "uib GmbH", "vista" : true, "vpn" : true, "license_management" : true, "expires" : "never", "valid" : true, "multiplex" : true, "signature" : "DIES-IST-KEINE-ECHTE-SIGNATUR", "treeview" : true, "mysql_backend" : true } }
Es muss das Feature user roles in der modules-Datei freigeschaltet sein. Zur Bedienung siehe Abschnitt 4.17.1, „Verwaltung von User-Rechten und -Rollen“
Der opsi Directory Connector ist ein Werkzeug um Daten aus einem Verzeichnisdienst in eine opsi-Installation zu überführen. Dadurch wird mehrfacher Pflegeaufwand in unterschiedlichen Systemen vermieden.
Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie, wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung (mail an info@uib.de).
Der Quell-Verzeichnisdienst muss das LDAP-Protokoll implementieren.
Das Ziel-Opsi-System sollte mindestens opsi 4.0.7 verwenden. Ältere Versionen können funktionieren, wurden aber nicht getestet.
Die Maschine, auf welcher der Connector laufen soll, muss über das Netzwerk Zugriff auf den Directory- und opsi-Server haben. Es ist möglich alle Komponenten auf der gleichen Maschine zu betreiben, aber es wird davon ausgegangen, dass jeweils getrennte Maschinen verwendet werden.
Diese Anforderungen richten sich an eine einfache Verwendung in einer kleinen Umgebung mit bis zu 500 Clients. Diese Anforderungen fallen in großen Umgebungen gegebenenfalls größer aus, weshalb Anpassungen notwendig sein können.
Es wird nur die Installation und der Betrieb des Connectors unter Linux unterstützt. Eine Unterstützung für Windows ist nicht geplant.
Der Connector verwendet Python 3, welches mindestens in Version 3.2 vorliegen muss.
Durch die Verwendung standardisierter Protokolle zur Kommunikation werden keine zusätzlichen opsi- oder Verzeichnisdienst-spezifischen Komponenten benötigt.
Zur Installation fügen Sie bitte das opsi-Repository wie im Dokument Getting Started
beschrieben hinzu.
Anschließend verwenden Sie den Paket-Manager des Betriebssystems um das Paket opsi-directory-connector
zu installieren.
Auf einer Debian-basierten Maschine kann die Installation wie folgt durchgeführt werden:
apt-get install opsi-directory-connector
CentOS und RedHat stellen in Version 6 und 7 kein Python 3 als Teil ihrer Kern-Repositories bereit, weshalb die Installation auf diesen Maschinen von uns nicht unterstützt wird.
Der Connector kann über eine Vielzahl an Einstellungsmöglichkeiten an verschiedenste Umgebungen angepasst werden.
Die Konfiguration geschieht über eine Konfigurationsdatei im JSON-Format, welche gültiges JSON enthalten muss.
Zur Angabe von boolschen Werten verwenden Sie bitte true
oder false
.
Text muss mit doppelten Anführungszeichen eingegeben werden, beispielsweise "das ist Text"
.
Eine Beispiel-Konfiguration wird unter /etc/opsi/opsidirectoryconnector.example.conf
bereitgestellt.
Diese Datei kann als eine Vorlage für eigene Konfigurationen verwendet werden.
cp /etc/opsi/opsidirectoryconnector.example.conf /etc/opsi/opsidirectoryconnector-custom.conf
Diese Einstellungen werden benötigt, um eine Verbindung zum Verzeichnisdienst herzustellen und den Suchbereich auf bestimmte Bereiche und Objekte einzugrenzen.
{ "directory": { "address": "ldap://192.168.12.34", "user": "DOMAIN\\opsiconnector", "password": "insertpasswordhere", "passwordFile": "", "search_base": "dc=testcompany,dc=local", "search_query_computers": "(objectClass=computer)", "identifying_attribute": "dn", "connection_options": { "start_tls": true, "paged_search_limit": 768 } }, … }
Unter address
muss angegeben werden unter welcher Adresse der Server angesprochen wird.
user
und password
werden für die Authentifikation an Selbigem verwendet.
Sofern für passwordFile
ein Wert angegeben wird, wird dieser als Pfad zu einer Datei, welche das Passwort enthält, interpretiert.
Der Inhalt dieser Datei wird als Passwort verwendet.
Dadurch muss das Passwort nicht im Klartext in der Konfigurationsdatei vorgehalten werden.
Das so ausgelesene Passwort wird eventuell gesetzte Werte für password
überschreiben.
Wir empfehlen die Verwendung eines gesonderten Benutzerkontos.
Je nach verwendeter Directory-Software und dessen Konfiguration können zur Anmeldung verschiedene Formate eines Benutzernamens zum Tragen kommen.
Neben Down-Level Logon Name im Stile von DOMAIN\\username
kann das Format auch User Principal Name im Stile von user@domain
oder ein Distinguished Name (DN) wie uid=opsiconnect,cn=users,dc=test,dc=intranet
sein.
Über search_base
wird angegeben ab welchem Punkt nach passenden Element gesucht wird.
Über search_query_computers
kann der für die Suche nach Clients verwendete Filter konfiguriert werden.
Über den optionalen Parameter identifying_attribute
wird ab Version 23 festgelegt welches Attribut verwendet werden soll um einen Client eindeutig zu identifizieren.
Als Standard wird hier dn
verwendet.
Eine häufige Alternative zu dn
ist der Wert distinguishedName
, diese Variante kommt oftmals in Microsoft Active Directory zum Einsatz.
Der Parameter connection_options
beinhaltet zusätzliche Optionen zur Konfiguration der Verbindung.
Mit start_tls
kann gesteuert werden, ob eine gesicherte Verbindung verwendet werden soll.
Ist der optionale Parameter paged_search_limit
vorhanden und als Wert eine Ganzzahl angegeben, so werden zum Auslesen der Elemente aus dem Directory mehrere Abfragen verwendet. Wieviele Elemente eine Antwort maximal enthält wird über den gesetzten Wert gesteuert.
Dieses Verhalten wird seit Version 20 unterstützt.
Weitere Verbindungs-Optionen werden auf Nachfrage implementiert.
Seit Version 14 ist es möglich, über den Aufrufparameter --check-directory
die Verbindungseinstellungen zum Verzeichnis zu prüfen, ohne dass eine Verbindung zum opsi-Server hergestellt wird.
Für eine Verbindung zu Univention Corporate Server (UCS) muss für die Verbindung als Benutzername ein vollständiger Distinguished Name verwendet werden.
Dieser hat die Form uid=<username>,cn=users,dc=company,dc=mydomain
.
Unter UCS ist LDAP über die Ports 7389 (ungesichert) bzw. 7636 (SSL-gesichert) erreichbar.
Ist auf dem Server ebenfalls Samba installiert und als AD-kompatibler Domaincontroller eingerichtet, so lauscht dieser auf den Ports 389 (ungesichert) bzw. 636 (SSL-gesichert).
Für die Verwendung der SSL-gesicherten Ports muss die Verbindungseinstellung start_tls
auf true
gesetzt werden.
Die beiden möglichen Verbindungen unterscheiden sich auch in der Art der Anmeldung. Bei LDAP kommt uid=…
zum Tragen, wohingegen bei Samba mittels dn=…
gearbeitet wird.
In der Regel wird man nach Rechner-Objekten im Container computers
suchen.
Der folgende Befehl gibt den dazu passenden Wert für search_base
aus:
echo "cn=computers,$(ucr get ldap/base)"
Für die Suche nach Windows-Clients kann (objectClass=univentionWindows)
als Wert für search_query_computers
angegeben werden.
Wie ein Benutzer mit nur lesendem Zugriff angelegt werden kann, ist im Univention-Wiki zu finden: Cool Solution - LDAP search user
Die Einstellungen steuern das Verhalten des Connectors.
{ … "behaviour": { "write_changes_to_opsi": true, "root_dir_in_opsi": "clientdirectory", "update_existing_clients": true, "prefer_location_from_directory": true, "group_handling": "dn", "group_description": "dn", "override_root_dir": true }, … }
Wird write_changes_to_opsi
auf false
gesetzt, werden keine Daten nach opsi geschrieben.
Mit dieser Einstellung ist es möglich, die Verbindungseinstellungen zu überprüfen, bevor sie angewendet werden.
Per root_dir_in_opsi
wird angegeben, welche Gruppe in opsi als Wurzelgruppe verwendet werden soll.
Es muss von Ihnen sichergestellt werden, dass diese Gruppe existiert.
Die Gruppe clientdirectory wird im Configed als DIRECTORY angezeigt.
Sollen also Clients oder Gruppen direkt unterhalb von DIRECTORY erscheinen, so muss als Wert für root_dir_in_opsi
der Wert clientdirectory
eingetragen werden.
Wird update_existing_clients
auf false
gesetzt, so werden bereits in opsi existierende Clients nicht verändert.
Wird dieser Wert auf true
gesetzt, so werden möglicherweise manuell gesetzte Daten mit den Werten aus dem Directory überschrieben.
Falls prefer_location_from_directory
auf true
gesetzt, werden Clients in opsi an die Position verschoben, welche sie im Directory haben.
Für das Deaktivieren dieses Verhaltens muss dieser Wert auf false
gesetzt werden.
Die Gruppenbehandlung kann seit Version 31 über den optionalen Schlüssel group_handling
gesteuert werden.
Der Default ist hierbei dn
. Dabei werden Gruppen aus dem DN eines Computers abgeleitet und entsprechend als Teil des opsi-Directory angelegt. Ein Client ist dabei nur Mitglied einer Gruppe.
Wird das Gruppenhandling auf ucsatschool
gesetzt, so wird das Verhalten auf die Verwendung in UCS@School-Umgebungen angepasst.
Dabei wird der opsi-directory-connector automatisch nach Schulen suchen und für diese die Räume ermitteln, welche dann nach opsi synchronisiert werden.
Für jede ermittelte Schule wird in opsi eine Gruppe angelegt.
Um den Gruppen von UCS@School zu folgen, bei welchen ein Rechner in mehr als einem Raum zu finden sein kann, werden die Gruppen dabei nicht als Gruppe innerhalb des opsi-Directory angelegt, sondern als normale Gruppe, so dass ein Client auch in opsi in mehreren Gruppen sein kann.
Sollen die Gruppen bei UCS@School in OPSI doch unter DIRECTORY angelegt werden, kann der Schalter override_root_dir
auf false
gesetzt werden. override_root_dir
ist nur bei group_handling
ucsatschool
verfügbar und der Defaultwert ist true
.
Wenn override_root_dir
auf false
gestellt wird und die Gruppen somit in OPSI unter DIRECTORY
gespeichert werden, sollte sichergestellt werden, dass jeder Schulrechner nur einem Raum zugewiesen wurde.
Mit group_description
kann die Beschreibung der OPSI-Gruppen angepasst werden. Folgende Werte sind möglich:
dn
: Der dn der Gruppe wird in OPSI als Gruppenbeschreibung hinterlegt.
directory
: Die Gruppenbeschreibung wird aus dem Feld description
der Directory-Gruppe gelesen.
Mit einem derart flexiblen System wie einem Verzeichnisdienst benötigt der Connector Informationen darüber, welche Attribute im Directory auf welche Attribute in opsi angewendet werden sollen.
{ … "mapping": { "client": { "id": "name", "description": "description", "notes": "", "hardwareAddress": "", "ipAddress": "", "inventoryNumber": "", "oneTimePassword": "" } }, … }
Es gibt ein Mapping für Client-Attribute. Der Schlüssel des Mappings ist das Attribut in opsi und der Wert ist das Attribut aus dem Verzeichnisdienst. Ist der Wert (in der Zuordnung) leer, so wird keine Zuordnung vorgenommen.
Sollte der aus dem Verzeichnis ausgelesene Wert für die ID des Clients nicht als FQDN erkennbar sein, so wird ein enstprechender FQDN erstellt. Der Domain-Teil hierfür wird aus den DC-Werten des Elements gebildet.
Unter Univention Corporate Server (UCS) kann bei hardwareAddress
der Wert macAddress
angegeben werden, wenn die Verbindung über LDAP (Port 7389 oder 7636) hergestellt wird.
Gruppennamen werden in der Regel ohne große Anpassungen übernommen. Allerdings kann es dabei vorkommen, dass Gruppennamen verwendet werden sollen, welche in opsi ungültig sind.
Für diese Sonderfälle kann eine manuelle Zuordnung von Gruppennamen vorgenommen werden, welche es erlaubt auch diese Fälle zu behandeln.
Zur Einrichtung wird in mapping
ein Eintrag group_name
angelegt, in welchem eine Zuordnung der Directory-Seite zur opsi-Seite vorgenommen wird.
Für Gruppen, welche in dieser Zuordnung nicht vorkommen, wird der Namen nicht angepasst.
Die Gruppennamen werden immer in Kleinbuchstaben verarbeitet, weshalb die Einträge hier in Kleinbuchstaben erfolgen müssen.
Möglich ist dies ab Version 23.
Das folgende Beispiel behandelt die aus dem Directory stammende Gruppe _server
in opsi als server
.
{ ... "mapping": { "client": { ... }, "group_name": { "_server": "server" } }, ... }
Bei unbedachtem Einsatz kann die manuelle Zuordnung unerwünschte Seiteneffekte haben. Deshalb sollte diese Zuordnungsmöglichkeit nur in Ausnahmefällen eingesetzt werden.
Hierüber wird gesteuert wie der Connector sich zu opsi verbindet.
{ … "opsi": { "address": "https://localhost:4447", "username": "syncuser", "password": "secret", "exit_on_error": false, "passwordFile": "", "connection_options": { "verify_certificate": true } } }
Unter address
ist die Adresse des opsi-Servers einzutragen.
Vergessen Sie nicht die Angabe des Ports!
Ein Proxy für die Verbindung kann über die Umgebungsvariable HTTPS_PROXY gesetzt werden.
Mittels username
und password
wird geregelt welche Zugangsdaten zur Authentifizierung am opsi-Server verwendet werden.
Sofern für passwordFile
ein Wert angegeben wird, wird dieser als Pfad zu einer Datei, welche das Passwort enthält, interpretiert.
Der Inhalt dieser Datei wird als Passwort verwendet.
Dadurch muss das Passwort nicht im Klartext in der Konfigurationsdatei vorgehalten werden.
Das so ausgelesene Passwort wird eventuell gesetzte Werte für password
überschreiben.
Wir empfehlen die Verwendung eines gesonderten Benutzers. Die Anlage zusätzlicher Benutzer ist im Dokument Getting Started beschrieben.
Ist der Parameter exit_on_error
auf true
gestellt, so führt ein Problem bei der Aktualisierung der Daten in opsi - das kann bspw. auch durch die Übermittlung von für opsi ungültige Werte geschehen - zu einem Abbruch.
Steht dies auf false
, so werden Fehler geloggt, aber der Lauf wird nicht beendet.
Unter connection_options
werden Optionen für die Verbindung zum opsi-Server festgelegt.
Mittels verify_certificate
wird die Überprüfung des Server-Zertifikats gesteuert.
Für selbstsignierte Zertifikate kann dieser Wert auf false
gesetzt werden.
Seit Version 14 ist es möglich, über den Aufrufparameter --check-opsi
die Verbindung zum opsi-Server zu testen, ohne dass eine Verbindung zum Verzeichnisdienst hergestellt wird.
Nach der Installation existiert ein Binary opsidirectoryconnector
auf dem System.
Dieses muss einen Parameter --config
zusammen mit dem Pfad zur Konfigurationsdatei übergeben bekommen.
opsidirectoryconnector --config /etc/opsi/opsidirectoryconnector-custom.conf
Der ausführende Benutzer benötigt keinen Zugriff auf das opsi-System, da der zugreifende Benutzer in der Konfigurationsdatei hinterlegt ist.
Der Connector macht aktuell bei der Ausführung einen Synchronisationslauf, aber die Chancen stehen gut, dass eine ständige Synchronisation erfolgt.
Es ist einfach, die Ausführung wiederkehrender Läufe zu automatisieren.
Wir werden hierbei systemd verwenden. Im Gegensatz zu cronjobs wird systemd verhindern, dass überlappende Läufe stattfinden, weshalb systemd eine gute Wahl ist.
Das folgende Beispiel wird den Connector so einrichten, dass er fünf Minuten nach dem Start der Maschine ausgeführt wird und danach jede Stunde.
Unter /etc/systemd/system/
, dem Verzeichnis für benutzerdefinierte Units, müssen die zwei folgenden Dateien abgelegt werden.
Eine Datei ist der Timer, welche unseren Job wiederkehrend aufruft und die Andere ist für den Job selbst.
Bitte füllen Sie die Datei opsi-directory-connector.timer
mit dem folgenden Inhalt:
[Unit] Description=Start the opsi-directory-connector in regular intervals [Timer] OnBootSec=5min OnUnitActiveSec=1hour [Install] WantedBy=timers.target
Und dies muss nach opsi-directory-connector.service
:
[Unit] Description=Sync clients from AD to opsi. Wants=network.target [Service] Type=oneshot ExecStart=/usr/bin/opsidirectoryconnector --config /etc/opsi/opsidirectoryconnector-custom.conf
Um den Timer zu aktivieren und ihn sofort zu starten, können die folgenden Befehle verwendet werden:
systemctl enable opsi-directory-connector.timer systemctl start opsi-directory-connector.timer
Falls der Timer nicht gestartet wird, wird er erst nach dem nächsten Neustart der Maschine ausgeführt werden.
Es ist einfach, die Ausführung wiederkehrender Läufe über einen Crobjob zu automatisieren.
Bitte beachten Sie, dass überlappende Läufe stattfinden können, weshalb der Synchronisationsintervall am besten größer gewählt werden sollte. Zur Vermeidung dieses Problems wird die Verwendung von systemd anstatt cron empfohlen!
Zur Bearbeitung der Cronjob-Datei wird in der Regel crontab -e
aufgerufen.
Für eine zu jeder Stunde stattfindenden Synchronisation kann dort folgendes als Cronjob hinterlegt werden:
0 * * * * /usr/bin/opsidirectoryconnector --config /etc/opsi/opsidirectoryconnector-custom.conf
usage: opsi-directory-connector [-h] [--version] [--log-level {0,1,2,3,4,5,6,7,8,9}] [--check-directory | --check-opsi] --config CONFIG opsi directory connector optional arguments: -h, --help show this help message and exit --version show program's version number and exit --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9} Sets how much information will be logged. --check-directory Check if a connection to the directory can be established and if items will be received. --check-opsi Check if a connection to the opsi server can be established. --config CONFIG Path to the config.
Ab Version 39 benutzt der opsi-directory-connector den OPSI-Logger mit Loglevel 0-9.
Dieses Modul ist momentan eine
kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen
zu können. Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie, wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Technische Voraussetzungen sind opsi 4.0.6 mit den Paketständen:
Tabelle 9.1. Benötigte Pakete
opsi-Paket | Version |
---|---|
opsi-linux-bootimage | >= 20160111 |
opsi-client-agent | >= 4.0.6.3-8 |
Windows Netboot >=7 | >= 4.0.6.1-3 |
opsi-clonezilla |
Für das Produkt opsi-wim-capture
muß der share opsi_depot_rw
für pcpatch beschreibbar sein. Prüfen Sie Ihre Samba Konfiguration!
Für die ganz Eiligen folgt hier eine Kurzanleitung. Ausführliche Informationen sind weiter unten zu finden.
Vorbereitungen:
custom
Verzeichnis kopiert oder verlinkt werden, zB.: unattend.xml
opsi-wim-capture
automatisch gesetzt
Start des Produktes opsi-wim-capture
:
opsi-wim-capture
auf setup setzen.
Rechner mit neuem Image installieren:
opsi-wim-capture
Produkt übernehmen)
Microsoft hat mit NT6 (also ab Vista) zur Installation ein neues Imageformat, das Windows Imaging Format (WIM) eingeführt. Ein WIM Image ist kein Platten- oder Partitionsimage, sondern mehr ein Dateien und Metadaten Archiv. Eine WIM Datei kann mehrere Images enthalten. Die normale Installation eines NT6 Rechners basiert darauf, dass die setup.exe ein Image aus der Datei install.wim auspackt, und dieses danach konfiguriert und mit zusätzlichen Treibern versieht.
Die Installation geht dadurch schneller als zu Zeiten von NT5. Leider dauern die Installationen der Hotfixes unter NT6 aber wesentlich länger, so daß eine Grundinstallation von z.B. Windows 7 zwar nur ca. eine halbe Stunde dauert, das Einspielen der Hotfixes aber etliche Stunden.
Von einem existierenden Rechner kann das Windows inclusive installierter Software, Hotfixes und Konfigurationen ausgelesen, und in Form eines WIM abgespeichert werden. Ein solches WIM kann dann wieder die Basis für neue Installationen sein.
Dazu dient das Produkt opsi-wim-capture. Im Rahmen dieses Produktes wird im Kern von der PE-Partition gebootet, und das PE liest die Systempartition aus und schreibt sie in ein WIM.
Das Capturen eines installierten Windows läuft wie folgt ab:
Vorbereitung:
Start des Produktes opsi-wim-capture
.
Alle folgenden Punkte werden ohne weitere Interaktion vom Produkt opsi-wim-capture
gesteuert:
Vorbereitung
Installation von Windows mit der Property-Einstellung: preserve_winpe_partition=true, da die winpe Partition später noch gebraucht wird.
Nach der Windows-Installation kann nun weitere Software, Hotfixes und Konfigurationen per opsi oder händisch auf den Rechner aufgespielt werden.
opsi-wim-capture
Der ganze Ablauf benötigt einige Zeit. Sie sollten mit mindestens einer Stunde rechnen. Der komplette Ablauf ist aber nicht interaktiv. D.h. Sie müssen nicht dabei bleiben.
Steht das Property disabled
auf true (default=false), so wird sofort abgebrochen. Dieser Schalter dient nur zu Entwicklungszwecken.
Es wird Anhand des Properties always_backup_before_sysprep geprüft ob ein Backup gemacht werden soll. Wenn ja, so wird über opsi-clonezilla ein Plattenbackup ausgelöst.
Für opsi-clonezilla wird das runcommand:
ocs-sr -q2 --batch -j2 -rm-win-swap-hib -i 2000 -p true savedisk imagefile sda
gesetzt. Innerhalb diese Kommandos wird imagefile
abhängig von dem Wert des Properties clonezilla_imagefile gesetzt: Steht diese Property auf auto (default), so wird der Wert für imagefile automatisch erstellt. Dies geschieht unter Verwendung von Propertywerten und dem Clientnamen nach dem Muster:
<FQDN des Clients>_<target_product>_<imagename>
Bei einem anderen Wert als auto wird der angegebene Wert als Imagefile verwendet. Weiterhin wird das Produkt opsi-clonezilla auf setup gesetzt. Damit das Produkt opsi-clonezilla startet ist nun ein Reboot nötig.
Um eine Endlosschleife zu vermeiden, wird nun ein Rebootflag gesetzt, damit nach Beendigung des Backup erkannt werden kann, dass dieser Schritt bereits erledigt ist.
Technischer Hinweis: Hier entsteht das Problem, dass der Rebootflag auch in dem Backup landet, aber nach einem Restore nicht mehr erwünscht ist. Daher wird der Rebootflag als Timestamp gesetzt. Ein Rebootflag, der älter als 0,1 Tage (=2,4 Stunden) ist wird ignoriert.
Die Maschine wird rebootet, dabei bleibt das Produkt opsi-wim-capture auf setup stehen. Nun startet das Netboot Produkt opsi-clonezilla und führt das Backup aus.
Warum opsi-clonezilla Backup ?
Das nachfolgende Sysprep macht die Systempartition für die weitere Verwendung unbrauchbar.
Ein vom erstellten (captured) WIM-Image erstelltes System enthält Informationen über das gelaufene Sysprep und ist nicht als Basis für weitere
opsi-wim-capture Läufe geeignet.
Erneutes capturen immer auf Basis des
per restore wiederhergestellten opsi-clonezilla Images ausführen.
Das Produkt opsi-clonezilla wird nun so eingestellt, das ein erneuter start ein Restore durchführen wird.
Muß ein opsi-clonezilla Backup erstellt werden?
Wenn der Rechner lediglich zum Erstellen eines WIM-Captures dient und danach neu Installiert wird, oder es sich um einen virtuellen Rechner handelt der sich aus einem Snapshot wieder herstellen läßt, kann auf die Erstellung eines Backups mit Clonezilla und den abschließenden Restore verzichtet werden.
Die entsprechenden Properties sind always_backup_before_sysprep und start_after_capture.
Nun werden die opsi Informationen, welche opsi-Produkte in welcher Version auf dem Client installiert sind, auf dem Client hinterlegt.
Die productOnClient Objekte für alle Localboot Produkte werden nach c:\opsi.org\tmp\productonclients.json
geschrieben.
Der opsi-client-agent des Rechners wird deaktiviert, damit er beim späteren Ausrollen des Images nicht aktiv wird.
Damit das Image, welches erstellt werden soll, sich wie ein Standard Windows Setup auf einem beliebigen Rechner ausrollen läßt, muß es depersonalisiert werden. Dies wird mit dem Winows Werzeug sysprep
erledigt.
Installierte Software wird nicht depersonalisiert. Es ist durchaus möglich, dass installierte Software sich in Ihrer Konfiguration merkt, auf welchem Rechner sie installiert wurde. Eine solche Konfiguration wird dann wahrscheinlich Probleme machen, wenn das Image auf einem anderen Rechner ausgerollt wird. Von daher ist es nicht die ideale Idee, möglichst viel Software in einem Image unterzubringen.
Steht das Property startcapture
auf false (default=true), so wird die Arbeit nach dem sysprep abgebrochen und der Rechner heruntergefahren. Dies ist nur sinnvoll wenn von dem Rechner danach mit einem anderen Werkzeug ein Image erstellt werden soll.
Das Auslesen der Windows-Partition und Wegschreiben in die WIM-Datei muss von einem Windows erfolgen, welches nicht das Windows ist, welches gelesen werden soll. Vielmehr wird hierfür das Windows PE verwendet, welches bei der ursprünglichen Installation angelegt und aufgehoben wurde.
start_after_capture
In dieser Phase startet das WinPE und führt nun den eigentlichen Capturevorgang durch. Im Detail:
check_disk_before_capture
den Wert true hat (default=false) dann wird nun ein chkdsk
für die Windows Partition ausgeführt. Dies dauert lange.
target_product
angegebene Produkt auf dem Share opsi_depot_rw existiert und eine install.wim
Datei an der richtigen Stelle besitzt.
target_product
. Wenn diese Datei bereits existiert, so wird hier abgebrochen, um zu vermeiden, dass mehrere capture Vorgänge gleichzeitig in die selbe WIM-Datei schreiben.
force_imagex
den Wert true hat (default=true), dann wird das imagex
Programm des Produktes opsi-wim-capture zum capturen verwendet, auch wenn das Windows PE über das Programm dism
verfügt. Ansonsten wird dism
verwendet, wenn verfügbar. Dism
ist schneller, kann aber zu Images führen, welche sich nicht ausrollen lassen.
capture_mode
den Wert append
hat: Überprüfen, ob ein Image mit diesem Namen in der install.wim
schon vorhanden ist, und gegebenenfalls dieses löschen.always_create
wird nur akzeptiert, wenn als Werkzeug dism
verwendet wird. In diesem Fall wird eine neue install.wim
Datei erzeugt.
Start des Capturevorgangs. Hierzu wird das weiter oben ausgewälte Werkzeug (imagex
oder dism
) und der ausgewählte capture_mode
verwendet. Der Name des Images wird durch das Property imagename
festgelegt. Die Hinterlegte Beschreibung des Images wird durch das Property image_description
festgelegt.
Dies kann lange dauern.
Imagename merken! Der Name des erstellten Images wird momentan noch nicht automatisch in die Liste der möglichen Imagenamen aufgenommen. Sie müssen sich den Namen merken und beim Ausrollen angeben!
target_product
.
Setzen der Produkte aus dem Property setup_after_capture
auf setup.
Dabei werden auch die Produktabhängigkeiten der betroffenen Produkte aufgelöst.
Dieses Property ist eine Liste und kann auch mehre ProduktIds aufnehmen.
opsi-clonezilla auf setup stellen lassen!
Der Rechner ist nach dem Capture Vorgang depersonalisert und damit weitgehend unbrauchbar. Das Produkt opsi-clonezilla ist so vorbereitet, dass ein weiter oben erstelltes Backup automatisch wieder hergestellt wird, wenn es hier auf setup gestellt wird.
Wenn das Produkt opsi-clonezilla
hier auf setup gestellt worden ist, so wird nun automatisch ein Restore der Platte durchgeführt.
Das Produkt opsi-wim-capture hat folgende Produktproperties:
always_backup_before_sysprep
:startcapture
:disabled
:target_product
:Dieses Property ist nicht schlau, d.h. es wird nicht überprüft, ob das ausgelesene Image zum Zielprodukt passt. Sie können also ohne Fehlermeldung ein win7-32Bit Image in ein Win81-64Bit Produkt schreiben. Das sollten Sie aber nicht! Wir empfehlen die Verwendung von gesonderten Produkten, welche nur als Ziel dienen (z.B. win7-x64-captured
).
Das Zielprodukt muß, genauso wie ein normales Produkt, zur Windows Installation vorbereitet werden. Als Zieldatei innerhalb des Zielproduktes dient die install.wim
Datei (installfiles/sources/install.wim
), welche auch die von Microsoft gelieferten Images enthält. Ob das ausgelese Image nun an diese Datei angehängt werden soll, oder eine neue install.wim
erzeugt werden soll, steuert das Property:
capture_mode
:Bei append
wird das neu erstellte Image an die vorhandene install.wim angehängt.
Enthält die install.wim schon ein Image gleichen Namens wird dieses ohne Nachfrage gelöscht.
Bei always_create
wird eine neue install.wim erstellt.
always_create
funktioniert nicht mit WinPE-Installationen, die auf Windows < 8 basieren.
Die Install.wim-Datei ist ein Container, der mehrere Images enthalten kann. Die Images haben einen Namen und eine Beschreibung. Der Name und die Beschreibung des neu erstellten Images werden durch die folgenden Properties gesteuert:
imagename
:image_description
:start_after_capture
force_imagex
:imagex
verwendet werden, auch wenn im WinPE das Werkzeug dism
zur verfügung steht.
opsi_depot_rw_host
:auto
(default) oder leer lassen.auto
oder leer: der Host von dem der share opsi_depot_rw
gemountet werden soll. Wenn der Host angegeben wird, dann als Hostname, FQDN oder IP-Nummer.opsi_depot_rw
nicht über das Depot dem der Client zugewiesen ist erreichbar ist.
checkdisk_before_capture
:verify_clonezilla_images
:after_save
, before_restore
, never
, always
never
Die Target Produkte dienen dazu die gecapturten Images aufzunehmen.
Warum Target-Produkte ?
Die Target-Produkte unterscheiden sich nicht von den Standard opsi Windows-Install Produkten. Technisch kann also z.B. ein normales win7-x64
als TargetProdukt dienen.
Wir empfehlen die Verwendung von Target Produkten, um eine Installation aus dem unmodifizierten Abbild einer orginal Microsoft DVD von einer Installation, welche aus einer modifizierten install.wim kommt, abgrenzen zu können.
Weiterhin haben Sie somit noch ein Produkt in Reserve, sollte bei einem capture mal die install.wim
unbrauchbar werden.
Die Entscheidung, was Sie als Target Produkt verwenden, liegt natürlich bei Ihnen.
Wir liefern die folgenden Target Produkte aus:
win7-x64-captured
win81-x64-captured
win10-x64-captured
Sie müssen diese Produkte genauso befüllen, wie andere Windows Netboot Produkte (siehe hierzu opsi-getting-started Handbuch).
Dabei dürfen Verzeichnisse wie winpe
oder z.B. drivers/drivers/additional/byAudit
durchaus symbolische Links auf die entsprechenden Verzeichniss aus dem passenden Nicht-Target-Produkt sein. Achtung: das installfiles
Verzeichnis muß tatsächlich mit bem Inhalt der Windows DVD befüllt werden und darf kein symbolischer Link sein.
(Ausrollen des gecapturten Images)
Wiederherstellung der opsi Metadaten zu installierten Produkten
Das Problem:
Wenn Sie ein Windows mit opsi neu installieren, z.B. aus win7-x64
, dann werden bei der Installation des opsi-client-agent alle Localboot-Produkte, welche bei diesem Rechner vorher auf installed
standen, automatisch auf setup gestellt und damit später erneut installiert.
Dies kann beim Ausrollen eines gecapturten Images nicht ganz genauso durchgeführt werden.
Im Image befindet sich das Backup der opsi-Daten, das dort während des capture Vorgangs abgelegt wurde. Dieses wird bei der Installation des opsi-client-agent entdeckt, und wieder in den opsi-server eingespielt. Damit stehen die Produkte, die in dem gecapturten Image installiert waren, jetzt für den frisch installierten Rechner auf installed
.
Würden jetzt alle Produkte, welche auf installed
stehen auf setup
gesetzt, würde dies dazu führen, dass alle schon im Image installierten Produkte nochmal installiert werden. Dies ist nicht erwünscht.
Bei der Wiederherstellung der opsi Metadaten zu installierten Produkten gibt es ab opsi 4.0.7 zwei Varianten:
Variante 1
Beim Ausrollen eines gecapturten Images werden nach der Installation des Images nur die Produkte automatisch installiert, welche schon vor dem Beginn der Betriebssystem-Installation auf setup
standen. Dies kann durch Ihren Eingriff oder das Property setup_after_install
erfolgt sein.
Daher werden in diesem Fall auch nur die Produkte installiert, welche vor der Installation des Betriebssystems auf setup
standen.
Dies ist der Default und das Verhalten vor opsi 4.0.7
Variante 2
Die Variante 2 verhält sich vom Ergebnis ähnlich wie es bei Installationen aus nicht gecapturten Images der Fall ist:
* Zurückspielen der Metadaten.
* Produkte die auf installed stehen werden auf setup gestellt ausser denen welche in den restorten Metadaten enthalten waren.
Diese Verhalten steht erst ab opsi 4.0.7 zur Verfügung und ist nicht der Default. Variante 2 ist durch Erweiterungen am opsi-script möglich geworden und ist Bestandteil des opsi-client-agent von 4.0.7.
Um dieses Verhalten zu verwenden muss ein config (Hostparameter) gesetzt werden:
Der boolsche Konfigurationseintrag: clientconfig.capture.switch_installed_products_to_setup
. Hat dieser Eintrag für den Client den Wert true dann wird Variante 2 verwendet, ansonsten Variante 1.
Über diese Hostparameter können dann Events Client-spezifisch aktiviert bzw. deaktiviert werden. Die Hostparameter können über den opsi-configed oder opsi-admin angelegt werden.
Zum Anlegen der Hostparameter über opsi-admin sind die folgenden Befehle auf dem opsi-configserver auszuführen:
opsi-admin -d method config_createBool clientconfig.capture.switch_installed_products_to_setup "capture.switch_installed_products_to_setup" true
Damit stellen Sie für alle Rechner Variante 2 ein.
Zum Anlegen der Hostparameter über den opsi-configed wählen Sie dort Serverkonfiguration / clientconfig / Auf der Rechten Seite mit der rechten Maustaste: Boolschen Konfigurationseintrag hinzufügen
.
Das Produkt opsi-wim-info
kann verwendet werden um schnell informationen über die in einer install.wim gespeicherten Images auszulesen. Diese Informationen werden dann in der Logdatei gespeichert.
Properties:
target_produkt
Stand 30.08.2019
Tabelle 9.2. Supported Linux OS as Client in opsi 4.1 and 4.0.7 / Unterstützte Linux-OS als Client in opsi 4.1 und 4.0.7
Distribution | OS-Installation | netboot products | client-agent | opsiclientd |
Debian 10 Buster | debian, debian10 | |||
Debian 9 Stretch | debian, debian9 | |||
Debian 8 Jessie | debian, debian8 | |||
Debian 7 Wheezy | debian, debian7 | |||
Debian 6 Squeeze | ||||
Ubuntu Bionic 18.04 LTS | ubuntu, ubuntu18-04 | |||
Ubuntu Xenial 16.04 LTS | ubuntu, ubuntu16-04 | |||
Ubuntu Trusty 14.04 LTS | ubuntu, ubunt14-04 | |||
Ubuntu Precise 12.04 LTS | ubuntu | |||
Ubuntu Lucid 10.04 LTS | ||||
RHEL 7 | rhel70 | |||
RHEL 6 | ||||
CentOS 7 | centos70 | |||
CentOS 6 | ||||
SLES 15 | ||||
SLES 12 SP4 | sles12sp4 | |||
SLES 12 SP3 | sles12sp3 | |||
SLES 12 SP2 | sles12sp2 | |||
SLES 12 SP1 | sles12sp1 | |||
SLES 12 | sles12 | |||
SLES 11SP4 | sles11sp4 | |||
SLES 11SP3 | sles11sp3 | |||
openSuse Leap 15.1 | opensusel15 | |||
openSuse Leap 15.0 | opensusel15 | |||
openSuse Leap 42.3 | opensusel42-2 | |||
openSuse Leap 42.2 | opensusel42-2 | |||
openSuse Leap 42.1 | opensusel42-1 | |||
openSuse 13.2 | opensuse13-2 | |||
openSuse 13.1 RC2 | ||||
openSUSE 12.3 | ||||
openSuse Tumbleweed | ||||
UCS 4.4 | ucs44 | |||
UCS 4.3 | ucs43 | |||
UCS 4.2 | ucs42 | |||
UCS 4.1 | ucs41 | |||
UCS 4.0 | ||||
UCS 3.2 | ||||
UCS 3.0 |
: Supported
: Unsupported
: Under Development
: Discontinued
Tabelle 9.3. Linux netboot products and the used installer type in opsi 4.1 and 4.0.7 / Linux Netboot-Produkte nach Installer-Typ in opsi 4.1 und 4.0.7
Netbootproduct | Installer | State | Remark |
debian | opsi | squeeze - buster | |
debian10 | distribution | ||
debian9 | distribution | ||
debian8 | distribution | ||
debian8 | distribution | ||
debian7 | distribution | ||
ubuntu | opsi | trusty - focal | |
ubuntu20-04 | distribution | ||
ubuntu18-04 | distribution | ||
ubuntu16-04 | distribution | ||
ubuntu15-10 | distribution | ||
ubuntu15-04 | distribution | ||
ubuntu14-04 | distribution | ||
centos70 | distribution | ||
redhat70 | distribution | ||
sles15 | distribution | ||
sles12sp4 | distribution | ||
sles12sp3 | distribution | ||
sles12sp2 | distribution | ||
sles12sp1 | distribution | ||
sles12 | distribution | ||
sles11sp4 | distribution | ||
sles11sp3 | opsi | ||
opensusel15-1 | distribution | ||
opensusel15 | distribution | ||
opensusel42-3 | distribution | ||
opensusel42-2 | distribution | ||
opensusel42-1 | distribution | ||
opensuse13-2 | distribution | ||
opensuse13-1 | opsi | ||
ucs44 | distribution | ||
ucs43 | distribution | ||
ucs42 | distribution | ||
ucs41 | distribution |
Technische Voraussetzungen sind opsi 4.0.5 mit den Paketständen:
Der opsi Support für Linux besteht aus einem Teil, der von Anfang an Opensource ist (den Netbootprodukten) und einem kofinanzierten Teil (dem Agent für die Clients).
Dieser opsi-linux-client-agent ist eine
kofinanzierte opsi Erweiterung.
Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Seit opsi 4.0.7 beinhaltet der opsi-linux-client-agent 15 Freistarts bei denen der Agent auch ohne Freischaltung verwendet werden kann.
Genauer formuliert: Nach der initalen Installation des opsi-linux-client-agent kann der der opsi-script 15 mal im Servicekontext gestartet werden ohne eine Freischaltung zu fordern.
Dies gibt Ihnen die Möglichkeit einen Linuxrechner aufzusetzen und mit den entsprechenden opsi-Produkten für den geplanten Einsatz zu konfigurieren.
Beispielsweise können Sie nach der Installation das Produkt l-opsi-server
aufrufen, um aus dem frisch installierten Rechner einen opsi-server zu machen.
Für eine dauerhafte Pflege des installierten Linuxrechners über diese 15 Freistarts hinaus benötigen Sie aber eine Freischaltung dieses Features.
Die Linux-bezogenen Pakete können über den opsi-package-updater
geladen werden.
Im Auslieferungszustand hat dieser bereits das Repository für die Linux-Produkte aktiviert.
Sie können mit dem folgenden Aufruf die opsi-linux Produkte einspielen:
opsi-package-updater -v --repo uib_linux install
Ein Management-Werkzeug für Windows und Linux
Ziel der Erweiterung von opsi um die Unterstützung von Linux-Systemen ist die Schaffung eines Managementsystems für heterogene Umgebungen. Der Fokus liegt dabei auf der möglichst vollständigen Integration beider Welten in die gleichen Management-Vorgänge und Werkzeuge.
Dies bedeutet, dass eine Linux-Installation auf die gleiche Weise angestoßen wird wie eine Windows-Installation.
Der opsi-client-agent unter Linux basiert auf dem selben Code wie der unter Windows und ist (soweit sinnvoll) befehlskompatibel.
Linux-Distributionsübergreifend
Der Linux-Support von opsi ist distributionsübergreifend angelegt.
Die folgenden Distributionen werden gleichwertig unterstützt:
Bei den mit opsi v4.0.5 veröffentlichten Linux-Netboot-Produkte wurden die Installationen des gewählten Betriebssystems weitgehend vom Netboot-Produkt gesteuert. Die entsprechenden Produkte setzen ab v4.0.6 auf den distributionseigenen Installer.
Dies ist ein grundsätzlicher Umbau, der dazu führt, das sowohl Aufbau als auch Verhalten der Produkte unterschiedlich zu den bisherigen Produkten sind.
Hier eine Übersicht:
Abläufe der neuen Installationsmimik:
Die Vorteile dieses Vorgehens sind:
Es ergeben sich aber auch folgende Nachteile:
Die Bereitstellung der Installationsmedien für die Suse- und RedHat-artigen Distributionen erfolgt auf einem nfs share: opsi_nfs_share
.
Zur Einrichtung des shares muss ein NFS-Server auf dem opsi-server installiert und konfiguriert sein.
Seit opsi v4.0.6 wird dies über ein gesondertes Paket opsi-linux-support
erfolgen. Dieses Paket wird nicht per default installiert und muss einmalig nachinstalliert werden.
Auf Debian-artigen Betriebssystemen kann das durch den folgenden Befehl erreicht werden:
apt install opsi-linux-support
Beim Einsatz einer Firewall auf Ihrem Server muss diese noch so konfiguriert werden, dass TCP-Verbindungen auf Port 80 akzeptiert werden. Bitte konsultieren Sie hierzu das entsprechende Handbuch.
Was dieses Paket macht, ist (als händige Anleitung) im Folgenden beschrieben:
nfs-kernel-server
. Auf Centos, Redhat ist es das Paket nfs-utils
.
Der Export opsi_nfs_share
muss angelegt und exportiert werden:
mkdir -p /var/lib/opsi/depot/opsi_nfs_share
/etc/exports
den Eintrag:/var/lib/opsi/depot/opsi_nfs_share *(ro,no_root_squash,insecure,async,subtree_check)
exportfs -r
showmount -e localhost
Export list for localhost: +
/var/lib/opsi/depot/opsi_nfs_share *
opsi_nfs_share
hat folgenden Verzeichnisaufbau:opsi_nfs_share/<productId>/<arch>/<dvd>.iso
opsi_nfs_share/opensuse13-2/64/openSUSE-13.2-DVD-x86_64.iso
.iso
haben, der Rest ist egal. Liegen in einem Verzeichnis mehrere .iso
Dateien so ist nicht definiert, welche verwendet wird.
opsi_nfs_share
und führen Sie aus:opsi-set-rights /var/lib/opsi/depot/opsi_nfs_share
/var/lib/opsi/depot/opsi_nfs_share
nicht vom opsi-server aus per NFS exportieren können (z.B. weil der Depotshare vom opsiserver per NFS von einem NAS eingebunden ist), so kann der zu verwendende NFS-share über ein Serverweites config angegeben werden. Z.B. clientconfig.opsi_nfs_share=172.16.166.1:/var/lib/opsi/depot/opsi_nfs_share
Die opsi v4.0.6 Netbootprodukte für Debian und Ubuntu beziehen Ihre Installations-Dateien nicht aus einem ISO-File. Vielmehr werden diese von uns mit dem Standard Netboot-Kernel und initrd ausgeliefert. Alle weiteren benötigten Pakete werden über das Internet bezogen. Zur Entlastung Ihrer Netzwekverbindung kann bei vielen Installationen daher die Verwendung eines lokalen apt-cache sinnvoll sein.
Die Pakete debian8 und ubuntu16-04 können auch auf ein lokales http-Repository zugreifen.
Siehe auch Kapitel Abschnitt 9.5.14, „Proxy für .deb-Pakete einrichten und verwenden“
Siehe auch Kapitel „Einrichtung eines lokalen deb http Repository“
Es kann vorkommen, dass der showmount
-Befehl mit einer Fehlermeldung wie nachfolgend abbricht:
# showmount -e localhost clnt_create: RPC: Program not registered
Bitte stellen Sie sicher, dass nach der Installation des NFS-Servers ein Neustart stattgefunden hat. Anschließend müssen die Dienste rpcbind und nfs-server in genau dieser Reihenfolge gestartet werden.
Ein Neustart der Dienste kann wie folgt durchgeführt werden:
# systemctl restart rpcbind.service # systemctl restart nfs-server.service
Anschließend liefert showmount das gewünschte Ergebnis:
# showmount -e localhost Export list for localhost: /var/lib/opsi/depot/opsi_nfs_share *
Die folgenden Properties finden Sie zur Steuerung der Linuxinstallation in allen v406 Netbootprodukten:
askbeforeinst
:architecture
:language
oder locale
:console_keymap
:timezone
:root_password
:user_password
:proxy
:http://<ip>:<port>
. (Default='')
install_opsi-client-agent
:Die Basis-Installation erfolgt direkt aus dem Netz. Bei debian8 und ubuntu16-04 ist auch eine Installation von einem lokalen Repository möglich.
Das Produkt hat produktiven Status.
Das Produkt hat folgende zusätzliche Properties:
online_repository
:encrypt_password
:linux123
Default: linux123
partition_disk
:first
oder kompletter device path
Examples: "first", "/dev/sda", "/dev/sdb"first
partition_method
:regular
: Standard Partionierung / lvm
: LVM’s anlegen / crypto
: In einer verschlüsselten Partition LVM’s anlegen
Possible: "regular", "lvm", "crypto"lvm
partition_recipe
:atomic
: Alles in einer Partition / home
: eigene /home Partition / multi
: eigene /home, /usr, /var, und /tmp Partitionen
Possible: "atomic", "home", "multi"atomic
desktop_package
:standard
language_packs
:de
Videos (Zeitraffer). Folgende Videos zeigen jeweils eine Installation.
Sie sind mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Die Basis-Installation bezieht ihre Pakete von den offiziellen UCS Repositories. Eine Installation mit lokalen Paketquellen ist ebenfalls möglich.
Dieses Produkt hat einen produktiven Status.
Mit diesem Produkt ist es möglich, einen Master-, Slave-, Backup, und einen Member-Server zu installieren. Wir empfehlen das l-opsi-server Produkt, um aus einer UCS Maschine auch einen opsi-Server zu machen. Dieses Produkt ermöglicht es auch Clients über einen Member-Server zu installieren, hierfür werden einige Besonderheiten durchgeführt.
Das Produkt hat über die oben genannten Properties eines z.B debian8 Produktes noch die folgenden zusätzlichen UCS spezifischen Properties:
dns_domain
:example.com
Default: ucs.test
ldap_base
:dc=example,dc=com
Default: dc=ucs,dc=test
ucs_code_name
:ucs414
Default: ucs414
organisation
:uib gmbh
Default: uib gmbh
windomain
:MYDOMAIN
Default: MYDOMAIN
external_nameserver
:10.11.12.13
Default: auto
= the name server given by dhcp
ucs_master_ip
:10.10.10.10
Default: 10.10.10.10
ucs_master_admin_password
:linux123
Default: linux123
ucs_role
:domaincontroller_master
Mit dem debian8, ubuntu16-04 und ucs41 Paket ist es nun möglich, von einem lokalen Apache2 Repository zu installieren.
Dazu müssen bei dem Produkt im Property online_repository die entsprechende Adresse angeben nach dem Muster http://<opsi-server>/opsi/<productId>
z.B http://opsiserver/opsi/debian8
Weiterhin muss das lokale Repository natürlich erstellt werden.
Stellen Sie dazu sicher, dass das Produkt opsi-linux-support
auf Ihrem opsi-server installiert ist. Dieses Paket installiert die
hierfür benötigten Distributions-Pakete (apache2) und erstellt auch die benötigten Ordner. Dieser muss danach mit einem passenden Distributions-Repository gefüllt werden.
Hierfür gibt es zwei Möglichkeiten:
Einfach:
Führen Sie das nachfolgende Script als root aus.
Beachten Sie das der Pfad zum Apache2 DocumentRoot
zum einen Distributiontypisch unterschiedliche Defaults hat und darüberhinaus abweichend vom Default konfiguriert sein kann.
Daher müssen Sie evtl. die zweite Zeile des Scriptes anpassen !
#! /bin/bash DOCUMENTROOT=/var/www/html URL=http://download.uib.de/opsi4.0/products/opsi-linux FILE=debian8.tgz mkdir -p ${DOCUMENTROOT}/opsi cd ${DOCUMENTROOT}/opsi wget ${URL}/${FILE} tar xzf ${FILE} opsi-set-rights .
#! /bin/bash DOCUMENTROOT=/var/www/html URL=http://download.uib.de/opsi4.0/products/opsi-linux FILE=ubuntu16-04.tgz mkdir -p ${DOCUMENTROOT}/opsi cd ${DOCUMENTROOT}/opsi wget ${URL}/${FILE} tar xzf ${FILE} opsi-set-rights .
#! /bin/bash DOCUMENTROOT=/var/www/html URL=http://download.uib.de/opsi4.0/products/opsi-linux/univention-repository/ FILE=univention-repository-4.1.tgz mkdir -p ${DOCUMENTROOT}/opsi cd ${DOCUMENTROOT}/opsi wget ${URL}/${FILE} tar xzf ${FILE} opsi-set-rights .
#! /bin/bash DOCUMENTROOT=/var/www/html URL=http://download.uib.de/opsi4.0/products/opsi-linux/univention-repository/ FILE=univention-repository-4.2.tgz mkdir -p ${DOCUMENTROOT}/opsi cd ${DOCUMENTROOT}/opsi wget ${URL}/${FILE} tar xzf ${FILE} opsi-set-rights .
Beachten Sie die Readme!
Aufwendiger:
Sie können das Repository auch selbst erstellen:
Ein selbst erstelltes Repo auf Basis einer UCS 4.2-0 DVD führt zu einem uvollständigem Repository. Hierbei ist das Paket debootstrap
nicht fähig ein UCS 4.2-0 zu installieren. Das von uns bereitgestellte Repository ist hiervon nicht betroffen.
#! /bin/bash set -x BASE_DIR=/var/www/opsi DVD_PATH=UCSISOMOUNTPOINT UCS_VERSION=4.1 UCS_SUBVERSION=4 UCS_REPODIR=univention-repository/mirror UCS_REPODIR2=${UCS_VERSION}/maintained/${UCS_VERSION}-${UCS_SUBVERSION} UCS_RELEASE_PATH=dists/ucs414/main/binary-amd64/Release cd ${BASE_DIR} mkdir -p ${UCS_REPODIR} cd ${UCS_REPODIR} pwd ln -s . univention-repository mkdir -p ${UCS_REPODIR2} cd ${UCS_REPODIR2} pwd cp -r ${DVD_PATH}/all . cp -r ${DVD_PATH}/amd64 . cp -r ${DVD_PATH}/dists . mkdir -p i386 cd all dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz dpkg-scanpackages . /dev/null > Packages.gz cd .. cd amd64 dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz dpkg-scanpackages . /dev/null > Packages.gz cd .. cd i386 dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz dpkg-scanpackages . /dev/null > Packages.gz cd .. echo "Archive: stable" > ${UCS_RELEASE_PATH} echo "Origin: Univention" >> ${UCS_RELEASE_PATH} echo "Label: Univention" >> ${UCS_RELEASE_PATH} echo "Version: ${UCS_VERSION}.${UCS_SUBVERSION}" >> ${UCS_RELEASE_PATH} echo "Component: main" >> ${UCS_RELEASE_PATH} echo "Architecture: amd64" >> ${UCS_RELEASE_PATH} cat ${UCS_RELEASE_PATH} cd ${BASE_DIR} chown -R www-data:www-data univention-repository echo "all done"
Das Produkt hat folgende zusätzliche Properties:
name: productkey multivalue: False editable: True description: email:regcode-sles for suse_register. Is only used if the host parameter `license-management.use` is set to false . If it set to True the license key will be get from the license management module. / La clé de licence pour l'installation. Est utilisée uniquement si dans "Réseau et paramètres supplémentaires" `license-management.use` est défini à false (faux) . Si c'est réglé sur True (vrai) la clé de licence sera obtenue du module de gestion des licences. values: ["", "myemail@example.com:xxxxxxxxxxxxxx"] default: [""] name: suse_register description: set to false, if you don't want to register your system online, if you set this to false you have to give local repositories default: True name: local_repositories multivalue: True editable: True description: list of local repositories to use. Syntax: "repository description", example entry: "http://sles.example.com/suse/repo NameForRepo" values: [""] default: [""] name: install_unattended description: If false then do interactive installation default: True
Installationsquelle. Zum herunterladen der Installations DVD brauchen Sie einen Account bei SUSE.
Installations DVD sollte heißen (mit einer Datei dieses Namens haben wir getestet):
sles11sp4: SLES-11-SP4-DVD-x86_64-GM-DVD1.iso
sles12: SLE-12-Server-DVD-x86_64-GM-DVD1.iso
sles12sp1: SLE-12-SP1-Server-DVD-x86_64-GM-DVD1.iso
ISO-File kopieren nach /var/lib/opsi/depot/opsi_nfs_share/opensusel42-1/64/
Ausführung von opsi-set-rights
nicht vergessen.
Videos (Zeitraffer). Folgendes Video zeigt eine Installation.
Es ist mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Das Produkt hat folgende zusätzliche Properties:
name: install_unattended description: If false then do interactive installation default: True name: selinux_mode multivalue: False editable: False description: In which mode should SELinux run ? values: ["enforcing", "permissive", "disabled"] default: ["permissive"] name: partition_method multivalue: False editable: False description: plain: Regular partitions with no LVM or Btrfs. / lvm: The LVM partitioning scheme. / btrfs: The Btrfs partitioning scheme. / thinp: The LVM Thin Provisioning partitioning scheme. values: ["plain", "lvm", "btrfs", "thinp"] default: ["lvm"] name: productkey multivalue: False editable: True description: email:regcode for subscription_register. Is only used if the host parameter `license-management.use` is set to false . If it set to True the license key will be get from the license management module. / La clé de licence pour l'installation. Est utilisée uniquement si dans "Réseau et paramètres supplémentaires" `license-management.use` est défini à false (faux) . Si c'est réglé sur True (vrai) la clé de licence sera obtenue du module de gestion des licences. values: ["", "myemail@example.com:xxxxxxxxxxxxxx"] default: [""] name: subscription_register description: set to false, if you don't want to register your system online, if you set this to false you have to give local repositories default: True
Installationsquelle CentOS. Installations DVD hier herunterladen, beispielsweise von hier.
ISO-File kopieren nach /var/lib/opsi/depot/opsi_nfs_share/centos70/64/
Ausführung von opsi-set-rights
nicht vergessen.
Installationsquelle RedHat. Zum Herunterladen der Installations DVD brauchen Sie einen Account bei RedHat.
Installations DVD sollte heißen (mit einer Datei dieses Namens haben wir getestet):
rhel-server-7.0-x86_64-dvd.iso
ISO-File kopieren nach /var/lib/opsi/depot/opsi_nfs_share/redhat70/64/
Ausführung von opsi-set-rights
nicht vergessen.
Videos (Zeitraffer). Folgende Videos zeigen eine Installation.
Sie sind mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Basis-Installation des OS per Netboot
Für die Installation eines Linux Basissystems wird zunächst per Netboot das Standard opsi-linux-bootimage gebootet (welches auch für die Windows-Installationen zum Einsatz kommt).
Von diesem Bootimage aus wird die Ziel-Festplatte partitioniert (/ und swap) und formatiert. Nun folgt die Installation des Grundsystems (mit Netzwerkkonfiguration und ssh aber ohne X11). Die Abläufe dieser Grundinstallation unterscheiden sich naturgemäß zwischen den unterschiedlichen Distributionen erheblich. Gemeinsam ist, dass die Installation direkt aus den Originalpaketen der Distribution erfolgt.
Auf diese Basisinstallation können optional die opsi-Pakete installiert werden, um aus dem System einen opsi-Server (z.B. neuen Depotserver) zu machen.
Ebenfalls optional kann nun der opsi-client-agent für Linux installiert werden. Dieser ist dann für die Installation und Konfiguration weiterer Software zuständig.
Die opsi-Netboot-Produkte zur Linuxinstallation sind bereits als Open Source freigegeben.
Bedingt dadurch, dass die Basisinstallation aus dem Standard opsi-linux-bootimage erfolgt, gibt es distributionsabhängig unterschiedlich bestimmte Dinge, welche sich erst in der Umgebung nach dem ersten Boot des Systems konfigurieren bzw. installieren lassen. Beispiele hierfür sind die SELinux-Installation bei den RedHat artigen bzw. die Konfiguration der Tastatur bei den Debian artigen. Hierfür gibt es ein Standard Localbootprodukt l-os-postinst
welches diese Aufgaben übernimmt.
Die folgenden Properties finden Sie zur Steuerung der Linuxinstallation in allen Netbootprodukten:
askbeforeinst
:architecture
:system_partition_size
:swap_partition_size
:data_partition_create
:data_partition_preserve
:language
:console_keymap
:timezone
:root_password
:user_password
:install_opsi_server
:online_repository
:opsi_online_repository
:proxy
:http://<ip>:<port>
. (Default='')
additional_packages
:wget_and_execute
:install_opsi-client-agent
:release
:setup_after_install
:Die Basis Installation erfolgt per debootstrap direkt aus dem Netz.
Das Produkt hat produktiven Status.
Das Produkt ist UEFI/GPT kompatibel (getestet für release=trusty).
Es gibt für diese Produkt passende opsi-server Pakete, welche über install_opsi_server=true installiert werden können.
Der opsi-client-agent für Linux ist Bestandteil des Kofinanzierungsprojektes Linux Agent und derzeit kostenpflichtig.
Dies ist ein Problem mit der derzeitigen Datenstruktur in opsi und wird zu einem späteren Zeitpunkt gelöst.
Der opsi-client-agent für Windows besteht im Kern aus den Komponenten:
opsiclientd
opsiscriptstarter
opsi-script / opsi-script-nogui
Der opsi-client-agent für Linux basiert auf einer Portierung des Windows-Clientagenten nach Linux.
Der opsiclientd
ist derzeit nicht für alle unterstützten Distributionen verfügbar und ist deshalb für alle anderen Distributionen zunächst durch das Programm opsiscriptstarter
ersetzt
Der opsiclientd
steht auf folgenden Distributionen / Releases zur Verfügung:
Steht kein opsiclientd zur Verfügung, wird der opsiscriptstarter
so installiert, das er die Aufgaben des opsiclientd
beim Systemstart übernimmt:
Der Actionprocessor heißt unter Linux opsi-script und ist aus den selben Quellen gebaut wie der opsi-winst unter Windows. Damit steht unter Linux die gleiche Scriptsyntax zur Verfügung wie unter Windows. Weiterhin sind alle nicht plattformspezifischen Funktionen umgesetzt wie z.B:
Natürlich gibt es unter Linux keine Funktionen zum Patchen der Registry, dafür aber neue linuxspezifische Funktionen wie z.B.:
Das Logging des opsi-script ist analog zur dem des opsi-winst unter Windows.
Anders als bei Windows gibt es den opsi-script neben einer grafischen Version für die Arbeit unter X-Windows zusätzlich in einer Version no-gui für Systeme ohne grafische Oberfläche.
Diese Methode dient zur Installation auf einzelnen Rechnern. Für ein Massen-Rollout siehe weiter unten.
root
Rechten auf dem Client ein.
//<opsiserver>/opsi_depot
an eine beliebige Stelle.
opsi-linux-client-agent
auf dem gemounteten share
./service_setup.sh
Das Skript nimmt per opsi-Webservice Kontakt zum Server auf, um serverseitig den Client zu erzeugen und den pckey zu erfahren. Dies erfolgt zunächst mit der, in der config.ini eingetragenen user/password Kombination. Schlägt dies fehl, so erscheint ein Login mit der Frage nach Service-URL, user und password. Dort kann die Operation mit dem Accountdaten eines Mitglieds der Gruppe opsiadmin autorisiert werden.
Der Client rebootet nach der Installation.
Das opsi-deploy-client-agent
Skript verteilt den opsi-client-agent direkt vom opsi-server auf die Clients.
Voraussetzung auf dem opsi-server:
python-paramiko
zur Verfügung und kann über den jeweiligen Paketmanager installiert werden.
Voraussetzung hierfür sind bei den Clients:
sudo
ausführen darf.
Bei opsi-deploy-client-agent
4.1.0.1 oder älter muss für die Verwendung eines Benutzers anders als root die Möglichkeit der nicht-interaktiven sudo
-Ausführung für diesen Benutzer bestehen.
Das Skript erzeugt serverseitig den Client, kopiert die Installations-Dateien und Konfigurationsinformationen, wie bspw. den pckey, auf den Client und startet dort die Installation.
Mit dem opsi-deploy-client-agent
Skript kann auch eine ganze Liste von Clients bearbeitet werden.
Dazu können entweder beliebig viele Clients als letzter Parameter übergeben werden oder mit der Option -f die Clients aus einer Datei eingelesen werden.
Bei der Verwendung einer Datei, muss in jeder Zeile ein Client stehen.
Das Programm kann mit IP-Adressen, Hostnamen und FQDNs arbeiten. Es wird versuchen automatisch zu erkennen welche Art von Adresse übergeben wurde.
Mit dem opsi-deploy-client-agent
Skript kann auch eine ganze List von Clients bearbeitet werden. Das Skript findet sich unter /var/lib/opsi/depot/opsi-linux-client-agent
Führen Sie das Programm mit root Rechten aus.
Bei der Installation über opsi-deploy-client-agent
ist zu beachten, dass eventuell gesetzte ProductProperties (falls der Client schon registriert ist) keinen Effekt haben.
Grund dafür ist, dass eine Verbindung zum Backend erst im Laufe des deploys aufgebaut werden kann. Für den außergewöhnlichen Fall, dass ein Client bereits registriert ist und
trotzdem per deploy-Programm der opsi-linux-client-agent ausgerollt werden soll und dabei vom Default abweichende Einstellungen gesetzt werden sollen, ist empfohlen, nach dem
Aufruf von opsi-deploy-client-agent, den opsi-linux-client-agent auf setup zu setzen, um die geänderten Einstellungen über die Defaults drüberzuinstallieren.
bonifax:/var/lib/opsi/depot/opsi-linux-client-agent# ./opsi-deploy-client-agent --help usage: opsi-deploy-client-agent [-h] [--version] [--verbose] [--debug-file DEBUGFILE] [--username USERNAME] [--password PASSWORD] [--use-fqdn | --use-hostname | --use-ip-address] [--ignore-failed-ping] [--reboot | --shutdown | --start-opsiclientd] [--hosts-from-file HOSTFILE] [--skip-existing-clients] [--threads MAXTHREADS] [--keep-client-on-failure | --remove-client-on-failure] [host [host ...]] Deploy opsi client agent to the specified clients. The clients must be accessible via SSH. The user must be allowed to use sudo non-interactive. positional arguments: host The hosts to deploy the opsi-client-agent to. optional arguments: -h, --help show this help message and exit --version, -V show program's version number and exit --verbose, -v increase verbosity (can be used multiple times) --debug-file DEBUGFILE Write debug output to given file. --username USERNAME, -u USERNAME username for authentication (default: root). Example for a domain account: -u "<DOMAIN>\\<username>" --password PASSWORD, -p PASSWORD password for authentication --use-fqdn, -c Use FQDN to connect to client. --use-hostname Use hostname to connect to client. --use-ip-address Use IP address to connect to client. --ignore-failed-ping, -x try installation even if ping fails --reboot, -r reboot computer after installation --shutdown, -s shutdown computer after installation --start-opsiclientd, -o start opsiclientd service after installation --hosts-from-file HOSTFILE, -f HOSTFILE File containing list of clients (one hostname per line). If there is a space followed by text after the hostname this will be used as client description for new clients. --skip-existing-clients, -S skip known opsi clients --threads MAXTHREADS, -t MAXTHREADS number of concurrent deployment threads --keep-client-on-failure If the client was created in opsi through this script it will not be removed in case of failure. (DEFAULT) --remove-client-on-failure If the client was created in opsi through this script it will be removed in case of failure.
Wenn Sie ein Linux über die opsi-Netboot-Produkte installieren, wird der opsi-linux-client-agent automatisch mit installiert, wenn das Property install_opsi-client-agent
auf true steht.
Der opsiclientd
für Linux ist eine Portierung des opsiclientd für Windows und arbeitet mit einer analogen Konfigurations Datei: /etc/opsi-client-agent/opsiclientd.conf
.
Eine ausführliche Beschreibung dieser Konfiguration findet sich im Kapitel zum opsi-client-agent: „Konfiguration“
Dabei sind nicht alle Features und Events auch unter Linux verfügbar.
Verfügbar sind:
opsiclientd
) unter Linux ist der Name des Events opsiclientd_start
(und nicht gui_startup
)
event_on_demand
event_timer
aber nur mit der Einstellung: super = default
Nicht verfügbar sind (derzeit):
event_net_connection
event_on_shutdown
event_silent_install
Der opsi-linux-client-agent legt Dateien an folgenden Orten ab:
Die Binaries:
/usr/bin/opsi-script
(X11)
/usr/bin/opsi-script-nogui
(ohne X11)
/usr/bin/opsiscriptstarter
(Hilfsprogramm bzw. opsiclientd Ersatz)
/usr/bin/opsiclientd
Die Hilfsdateien für den opsi-script finden sich in:
Skindateien:
/usr/share/opsi-client-agent/opsi-script/skin
(depricated)
Ab opsi-script 4.12.0.31
/ opsi-linux-client-agent (4.1.0.9-1)
:
default : /usr/share/opsi-script/skin
custom : /usr/share/opsi-script/customskin
opsi-script Library:
/usr/share/opsi-script/lib
Translation Dateien:
/usr/share/locale/
<LANG>/LC_MESSAGES/opsi-script.po
Die Konfigurationen:
/etc/opsi-client-agent/opsiclientd.conf
(Konfiguration des opsiscriptstarter / opsiclientd)
/etc/opsi-client-agent/opsi-script.conf
(depricated)
Ab opsi-script 4.12.0.31
/ opsi-linux-client-agent (4.1.0.9-1)
:
/etc/opsi-script/opsi-script.conf
Logdateien sind zu finden unter:
/var/log/opsi-client-agent
/var/log/opsi-client-agent/opsiclientd
/var/log/opsi-client-agent/opsi-script
(depricated)
Ab opsi-script 4.12.0.31
/ opsi-linux-client-agent (4.1.0.9-1)
:
/var/log/opsi-script/
Das Kopieren von vielen Dateien von einem Samba3-Share ist abhängig von der Samba-Version fehlerhaft. Es werden nicht alle Dateien kopiert. Das Problem wurde bei Samba4 Shares bisher nicht beobachtet.
Als Workaround kann statt:
[Files_copy_netboot] copy -s "%scriptPath%/installfiles/*" "$target$/installfiles/"
das folgende verwendet werden:
[ShellInAnIcon_opsi_copy_netboot] set -x export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin cd "%scriptPath%" tar cf - installfiles | ( cd "$target$/installfiles/" ; tar xf - )
Unter Windows gilt für die Softwareverteilung: Die Installation von Software ist genauso wichtig wie die anschließende Konfiguration der Software.
Unter Linux stehen die meisten Pakete über die Repositories der Distribution zur Verfügung. Dadurch wird der Installationsanteil kleiner, der Konfigurationsanteil aber bleibt. Weiterhin gibt es auch Applikationen, welche nicht über die Standardrepositories verfügbar sind.
Hier müssen unter Umständen zunächst weitere Repositories dem System hinzugefügt werden bzw. Installationsquellen dem Paket zugefügt werden.
Wichtig ist, dass alle Installations- und Konfigurationsarbeiten zentral vom opsi-Server gesteuert und dort auch geloggt werden.
Im folgenden finden Sie Beispiele für folgende Aufgaben in einem beispielhaften Script für den opsi-linux-client-agent:
apt
, zypper
und yum
Beispiel: Beenden wenn es nicht unter Linux läuft:
[Actions] requiredWinstVersion >= "4.11.4.1" ScriptErrorMessages=off DefVar $OS$ set $OS$ = GetOS if not($OS$ = "Linux") LogError "Wrong OS: Product: " + $ProductId$ + " is only for Linux" isFatalError "Wrong OS" endif
Beispiel: Feststellen des Distributionstyps:
[Actions] requiredWinstVersion >= "4.11.4.1" ScriptErrorMessages=off DefVar $distrotype$ set $distrotype$ = getLinuxDistroType if $distrotype$ = 'debian' Message "Try to get Package Lock..." if waitForPackageLock("60","false") comment "we got the package lock." else LogError "could not get Package Lock" isFatalError "package lock failed" endif ShellInAnIcon_Upgrade_deb else LogError "Wrong Distro: This Product is for Debian/Ubuntu only" isFatalError "Wrong distro" endif if not("0" = getLastExitCode) Message "failed ShellInAnIcon_Upgrade" LogError "failed ShellInAnIcon_Upgrade" isFatalError "failed Upgrade" endif [ShellInAnIcon_Upgrade_deb] set -x export DEBIAN_FRONTEND=noninteractive apt update apt --yes dist-upgrade exit $?
Beispiel: Feststellen der genauen Linux Version und Installation eines Paketes:
[Actions] requiredWinstVersion >= "4.11.4.1" ScriptErrorMessages=off DefVar $distCodeName$ DefVar $distroName$ DefVar $distRelease$ DefVar $desktop$ DefStringList $linuxInfo$ set $linuxInfo$ = getLinuxVersionMap set $distCodeName$ = getValue("Codename", $linuxInfo$) set $distRelease$ = getValue("Release", $linuxInfo$) set $distroName$ = getValue("Distributor ID", $linuxInfo$) set $desktop$ = GetProductProperty("desktop", "kde") if $distrotype$ = 'suse' if $desktop$ = "unity" Message " No Unity on SUSE - fallback to KDE ..." set $desktop$ = "kde" endif ; unity Message "Try to get Package Lock..." if waitForPackageLock("60","false") comment "we got the package lock." else LogError "could not get Package Lock" isFatalError "package lock failed" endif if $desktop$ = "kde" if ($distroName$ = 'openSUSE project') ShellInAnIcon_kde_suse endif if ("SUSE LINUX" = $distroName$) and ($distRelease$ = "11") ShellInAnIcon_kde_sles11 endif if not("0" = getLastExitCode) LogError "failed ShellInAnIcon" Message "failed kde" isFatalError "failed kde" endif endif ; kde endif; suse type [ShellInAnIcon_kde_suse] set -x zypper --no-gpg-checks --non-interactive install patterns-openSUSE-kde4 patterns-openSUSE-kde4_basis zypper --no-gpg-checks --non-interactive install splashy-branding-openSUSE exit $? [ShellInAnIcon_kde_sles11] set -x zypper --no-gpg-checks --non-interactive install --auto-agree-with-licenses -t pattern kde exit $?
Beispiel: Hinzufügen eines Repositories:
[Actions] requiredWinstVersion >= "4.11.4.1" ScriptErrorMessages=off DefVar $distCodeName$ DefVar $distroName$ DefVar $distRelease$ DefVar $desktop$ DefStringList $linuxInfo$ set $linuxInfo$ = getLinuxVersionMap set $distCodeName$ = getValue("Codename", $linuxInfo$) set $distRelease$ = getValue("Release", $linuxInfo$) set $distroName$ = getValue("Distributor ID", $linuxInfo$) set $desktop$ = GetProductProperty("desktop", "kde") if $distroName$ = 'Ubuntu' if $desktop$ = "cinnamon" set $desktopPackage$ = $desktop$ Message "Try to get Package Lock..." if waitForPackageLock("60","false") comment "we got the package lock." else LogError "could not get Package Lock" isFatalError "package lock failed" endif ShellInAnIcon_ubuntu_cinnamon if not("0" = getLastExitCode) Message "failed ShellInAnIcon_ubuntu_cinnamon" LogError "failed ShellInAnIcon_ubuntu_cinnamon" isFatalError "failed cinnamon" endif endif ; cinnamon endif; ubuntu [ShellInAnIcon_ubuntu_cinnamon] set -x export DEBIAN_FRONTEND=noninteractive # we need to get the add-apt-repository command apt --yes --force-yes install python-software-properties # the cinnamon repository add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-stable apt update apt --yes install ubuntu-desktop exit $?
Hier einige Lokalbootprodukte, welche zum Standardumfang des opsi Linuxsupports gehören.
Das Produkt l-opsi-server dient dazu automatisiert auf einer Linuxmaschine per opsi-linux-client-agent einen opsi-server zu installieren. Dies kann dazu dienen um schnell einen neuen opsi-depot-server zu installieren oder z.B. ein opsi Testsystem.
Derzeit kann eine Maschine nicht gleichzeitig am selben opsi-config-server
opsi-client und opsi-depot-server sein.
Sie haben derzeit zwei Möglichkeiten mit dieser Beschränkung umzugehen:
1. Verwendung von einem opsi-config-server: Wenn also ein per l-opsi-server installierter opsi-server zum Depotserver an seinem Config-Server werden soll, so müssen Sie vorher im configed die Maschine als Client löschen.
2. Verwendung von zwei opsi-config-servern: Sie setzen für die Verwaltung Ihrer opsi-server einen zweiten, unabhängigen
opsi-config-server auf, welcher nur dazu dient die anderen opsi-server zu installieren und zu pflegen. Dieser zweite opsi-config-server kennt die anderen opsi-server also nur als Clients, während der bisherige (erste) opsi-config-server die anderen opsi-server nur als Depots (oder garnicht) kennt.
In UCS Umgebungen wird Methode 2 empfohlen und der zweite opsi-config-server darf keine UCS Maschine sein.
Das Produkt l-opsi-server hat folgende Properties:
opsi_online_repository
:opsi_noproxy_online_repository
:opsi_online_repository
einen Proxy oder deb-cacher mit angegeben haben
(z.B. 'http://mydeb-cacher:9999/download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40"),
dann geben Sie hier die URL nochmal ohne den Proxy an. Ansonsten geben Sie hier dasselbe an, wie bei opsi_noproxy_online_repository
.
repo_kind
:backend
:mysql
benötigt die Hinterlegung einer gültigen Freischaltdatei). (Default=file)opsi_admin_user_name
:opsi_admin_user_password
opsi_admin_user_password
:opsi_admin_user_name
setup_after_install
:allow_reboot
:myipname
:install_and_configure_dhcp
myipnumber
:install_and_configure_dhcp
install_and_configure_dhcp
:netmask
:network
:dnsdomain
:nameserver
:gateway
:ucs_master_admin_password
:update_test
:Das Produkt hat eine setup required before Abhängigkeit zu dem Produkt l-system-update. D.h. wenn Sie l-opsi-server auf setup stellen, wird automatisch l-system-update auch auf setup gestellt und vorher installiert.
In dem Verzeichnis custom
des Produktes l-opsi-server
kann eine Freischaltdatei (modules
) abgelegt werden, welche bei der Installation durch das Produkt l-opsi-server
verwendet wird und beim Einspielen einer neuen Version des Produktes erhalten bleibt.
Dieses Produkt übernimmt jene Teile der Basisinstallation, welche sich vom Bootimage nicht korrekt ausführen lassen.
Dies ist für die unterschiedlichen Distributionen:
CentOS:
Das Produkt hat eine Abhängigkeit zu dem Produkt l-system-update, welches vor dem Lauf von l-os-postinst aufgerufen wird.
Das Produkt hat eine hohe Priorität, d.h. es wird vor normalen Produkten ausgeführt.
Das Produkt l-desktop installiert einen Desktop auf dem Rechner.
Über das Property desktop
kann der zu installierende Desktop ausgewählt werden. Dabei ist zu beachten, das nicht alle Desktops auf allen Distributionen verfügbar sind. So gibt es z.B. Unity nur unter Ubuntu. Wird ein nicht verfügbarer Desktop gewählt so wird ein Distributionsspezifischer Defaultdesktop installiert. Weiterhin haben die Desktop Pakete einen unterschiedlichen Umfang, welcher abhängig von Distribution und Desktop sich auf die eigentliche Desktop Software beschränken kann oder auch Basisprodukte wie libreoffice, firefox, PDF-Reader usw. enthalten kann.
Das Property desktop
hat folgende Werte:
Hardwareinventarisierung.
Die Hardwareinventarisierung basiert zur Zeit auf der in Python implementierten Methode wie sie auch vom bootimage verwendet wird. Dazu muss das Paket python-opsi
aus dem opsi-Repository der Distribution installiert werden. Ist für die Distribution kein opsi-Repository verfügbar, so scheitert auch die Hardwareinventarisierung.
Zur Inventarisierung werden die Daten durch den Clientagenten erhoben und an den Server gesendet. Die Hardwareinventarisierung basiert auf den schon im Bootimage implementierten Methoden.
Die Softwareinventarisierung basiert auf den Daten des Paketmanagements der verwendeten Distribution.
Einige der opsi v4.0.5 Linuxprodukte sind UEFI/GPT kompatibel. Details siehe hierzu in der obigen Auflistung der Netbootprodukte.
Die opsi v4.0.6 Linuxprodukte sind leider noch nicht UEFI/GPT kompatibel. Die Informationen über die UEFI Umgebung gehen im Moment noch bei dem kexec Boot verloren. Wir hoffen, das wir dieses Problem mit einem neueren bootimage irgendwann beheben können.
Die Linux Unterstützung von opsi ist neu. Das bedeutet auch, dass wir im ersten Release noch nicht alle Features verwirklicht haben.
Weitere Features werden folgen, wie:
Anleitungen zur Erstellung eines eigenen Proxy zum Zwischenspeichern von .deb-Paketen finden Sie unter anderem hier:
Stand 25.08.2018
Tabelle 9.6. Standard Windows
Netboot product | Opsi 4.0.7 / 4.1 | Remark |
Server 2016 | ||
win10 64 Bit | ||
win10 32 Bit | ||
Server 2012 R12 | ||
win8.1 64 Bit | ||
win8.1 32 Bit | ||
Server 2012 | ||
win7 64 Bit | ||
win7 32 Bit | ||
Server 2008 R2 | ||
winvista 32 Bit | ||
winvista 64 Bit | ||
Server 2008 64 Bit | ||
winxp |
: Supported
: Unsupported
: Under Development
: Discontinued
Tabelle 9.7. Linux
Netboot product | Opsi 4.0.7 / 4.1 | Remark |
ubuntu | ||
ubuntu18-04 | ||
ubuntu16-04 | since ubuntu16-04_4.0.7.2-1 | |
ubuntu14-04 | ||
debian | ||
debian9 | ||
debian8 | since debian8_4.0.7.2-1 | |
debian7 | ||
centos70 | ||
centos65 | ||
redhat70 | ||
opensusel15 | ||
opensusel15-1 | ||
opensusel42-3 | ||
opensusel42-2 | ||
opensusel42-1 | ||
sles15 | ||
sles12sp3 | ||
sles12sp2 | ||
sles12sp1 | ||
sles12 | ||
sles11sp4 | ||
sles11sp3 |
: Supported
: Unsupported
: Under Development
: Discontinued
Tabelle 9.8. opsi-local-image
Netboot product | Opsi 4.0.7 / 4.1 | Remark |
opsi-local-image-prepare | ||
opsi-local-image-backup | ||
opsi-local-image-restore | ||
opsi-local-image-wim-capture | ||
opsi-local-image-win* | ||
opsi-local-image-ubuntu | ||
opsi-local-image-opensuse13-2 | ||
opsi-local-image-opensusel42-2 | ||
opsi-vhd-win10-x64 |
: Supported
: Unsupported
: Under Development
: Discontinued
Stand 24.09.2019
Tabelle 9.9. Windows
Netboot product | Opsi 4.1 |
Server 2019 | |
Server 2016 | |
win10 64 Bit | |
Server 2012 R2 | |
win8.1 64 Bit |
: Supported
: Unsupported
: Under Development
: Discontinued
Tabelle 9.10. Linux
Netboot product | 4.1 | Remark |
ubuntu | ||
ubuntu18-04 | since ubuntu18-04_4.1.0.2-1 | |
debian | ||
debian10 | since debian10_4.1.0.3-1 |
: Supported
: Unsupported
: Under Development
: Discontinued
Tabelle 9.11. opsi-local-image
Netboot product | Opsi 4.1 |
opsi-local-image-prepare | |
opsi-local-image-backup | |
opsi-local-image-restore | |
opsi-local-image-wim-capture | |
opsi-local-image-win10-x64 | |
opsi-vhd-win10-x64 |
: Supported
: Unsupported
: Under Development
: Discontinued
Dieses Modul ist momentan eine
kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen
zu können. Das bedeutet, das Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Technische Voraussetzungen sind opsi 4.1 mit den Paketständen:
Tabelle 9.12. Benötigte Pakete
opsi-Paket | Version |
---|---|
Netbootprodukte | >=4.1 |
opsi Server Pakete | >=4.1 |
opsipxeconfd | >=4.1.1.20-3 |
opsi-linux-bootimage | >=20200506 |
EFI
und Datei bootmgr.efi
im winpe-Ordner des opsi-Netboot-Produkts. )
Ist dies nicht der Fall, sollte ein aktuelles winpe mittels dism erstellt werden (siehe: "Erstellen eines Winpe" im "Getting-Started - Dokument". )
Ein UEFI winpe wird im Ordner winpe_uefi neben dem winpe verzeichnis erwartet. Sofern man ein winpe für beide Bootmodi hat, kann man winpe_uefi durch einen Soft-Link auf winpe ersetzen.
Im Managementinterface opsi-configed muss für uefi-Clients das Häkchen "Uefi-Boot" gesetzt sein (seit version 4.0.5.8.1) oder aber der Hostparameter clientconfig.dhcpd.filename=linux/pxelinux.cfg/shimx64.efi.signed
Client-spezifisch konfiguriert werden. Diese Einstellung kann auch über folgenden Kommandozeilen-Aufruf erfolgen:
opsi-admin -d method configState_create "clientconfig.dhcpd.filename" "hier.host.id" "linux/pxelinux.cfg/shimx64.efi.signed"
Falls ihr opsi Server vorherige Paketversionen, als die als benötigt bereits installiert hatte, müssen sie die Datei /etc/opsi/opsipxeconfd.conf
eventuell anpassen.
Diese Änderung betrifft die Zeile uefi netboot config template x64 = /tftpboot/linux/pxelinux.cfg/install-elilo-x64
welche in uefi netboot config template x64 = /tftpboot/linux/pxelinux.cfg/install-grub-x64
geändert werden muss. Ansonsten kommt es zu einer Inkompatibilität zwischen dem UEFI bootloader und der named pipe.
Einstellungen im BIOS:
Da die BIOS-Menüs sehr unterschiedlich sind und unterschiedliche Begrifflichkeiten verwenden, müssen Sie hier überlegen wie das hier gesagte am besten auf Ihr BIOS passt.
Neue PC’s, Tablets und Server enthalten meist ein UEFI BIOS. Häufig kann dieses in einen Legacy Mode umgestellt werden, um das bisherige Verhalten und die Unterstützung eines PXE Boots zu bekommen. Es tauchen aber auch zunehmend Geräte mit UEFI-only BIOS auf (besonders bei den Tablets). Diese lassen sich in einer bisherigen opsi Umgebung nicht per netboot verwalten.
Um auch diese Geräte in opsi integrieren bzw. die Vorteile von UEFI nutzen zu können, entwickelt die uib gmbh die opsi Erweiterung UEFI Support.
UEFI steht für Unified Extensible Firmware Interface und ist der Nachfolger des klassischen PC-BIOS (auch MBR-BIOS genannt).
Für Detailierte Informationen zum Thema UEFI finden sich unten einige Links.
UEFI ist ungleich mächtiger als das herkömmliche BIOS. Im Prinzip ist UEFI ein eigenes kleines Mini-Betriebssystem. Hier sollen aber nur Punkte erwähnt werden, welche für den Systemverwalter von besonderer Bedeutung sind:
Partitionierung mit GPT und zusätzliche Partitionen für die Bootloader:
Links:
GPT (GUID Partition Table) ersetzen die bisherigen MBR Partitionstabellen. GPT ist Bestandteil der UEFI Spezifikation.
Wesentliche Merkmale für den Sysadmin sind:
Prinzipiell lässt sich GPT auch ohne UEFI verwenden. UEFI funktioniert aber nur mit GPT. Wird UEFI verwendet, so kommen ein bis zwei zusätzliche Partitionen hinzu:
Links:
Im Gegensatz zu herkömmlichen BIOSen kann hier die Bootreihenfolge nicht nur für Geräte, sondern auch für unterschiedliche Bootloader auf der EFI System Partition eingetragen werden. Darüber hinaus ist diese Reihenfolge auch von einem laufenden Betriebssystem manipulierbar. Wenn Sie also den Netboot als oberste Priorität festlegen, so wird dies die erste OS-Installation nicht überleben.
Leider unterstützen viele frühe UEFI BIOSe noch kein Netboot, aber die Unterstützung wird zunehmend besser.
Die uib gmbh stellt mit der opsi-Erweiterung UEFI Support eine funktionierende Unterstützung für die Anbindung eines Clients über einen UEFI-Netboot an opsi vor. Gleichzeitig erwarten wir, dass im Rahmen der technischen Weiterentwicklung diese opsi-Erweiterung in den nächsten Jahren noch deutlich umgebaut werden wird.
Die opsi Unterstützung für UEFI ist im Rahmen einer Reihe von Teilkomponenten umgesetzt:
clientconfig.uefinetbootlabel
). Dies ermöglicht es opsi-Produkten gezielt für den nächsten Boot die Bootreihenfolge auf Netboot umzustellen. Diese Technik ist in verschiedenen opsi-Produkten implementiert. Ein wichtiges Beispiel ist das Produkt opsi-uefi-netboot
:uefinetbootlabel
gefunden oder handelt es sich nicht um einen UEFI Rechner wird nur ein Reboot ausgelöst.Damit Uefi-Clients auch per PXE-Boot betankt werden können, benötigen sie einen anderen Bootfile Eintrag, als den herkömmlichen für Bios-Clients. Als Bootfile ist einzutragen: linux/pxelinux.cfg/shimx64.efi.signed. Da in der Praxis vermutlich beide Varianten in einer opsi-Umgebung betrieben werden sollen, muss der DHCP-Server je nach Clienttyp das entsprechende Bootfile auf dem opsi-Server zuweisen. Hierzu folgen Beispielkonfigurationen für DHCP-Server auf Basis von Linux- oder Windows-Systemen.
Auf einem Linux-Server kann in die dhcpd.conf folgende Weiche konfiguriert werden:
filename "linux/pxelinux.0"; # Das ist die UEFI Detection: if substring (option vendor-class-identifier , 19,1 ) = "0" { log (info, "pxe client"); filename "linux/pxelinux.0"; } else if substring (option vendor-class-identifier , 19,1 ) = "6" { log (info, "efi32 client"); filename "linux/pxelinux.cfg/elilo-x86.efi"; } else if substring (option vendor-class-identifier , 19,1 ) = "7" { log (info, "efi64 client"); filename "linux/pxelinux.cfg/shimx64.efi.signed"; } else { log (info, concat ( "Unhandled vendor class Arch: ", substring (option vendor-class-identifier , 19,1 ))); }
Siehe auch: Fedora: PXE Boot Configuration
Herstellerklasse definieren Neue Herstellerklasse hinzufügen Klasse bearbeiten Anzeigename: Legacy BIOS Asci: PXEClient:Arch:00000:UNDI:002001
Vordefinierte Optionen einstellen Optionen hinzufügen Optionsklasse: Legacy BIOS Hinzufügen Optionstyp anpassen Name: Legacy BIOS Datentyp: Zeichenfolge Code: 60 Beschreibung: PXEClient Class Legacy BIOS Vordefinierte Optionen und Werte Zeichenfolge: PXEClient
Neue Richtlinie Richtlinienname: PXE BootFile Legacy BIOS weiter Bedingungen hinzufügen Kriterien: Herstellerklasse Operator: ist gleich Wert: Legacy BIOS hinzufügen Möchten Sie einen IP-Adressbereich für die folgende Richtlinie konfigurieren: Nein Herstellerklasse: DHCP Standard Options 067 Name der Startdatei Dateieingabe Zeichenfolgenwert: linux/pxelinux.0
067 Name der Startdatei: linux/pxelinux.cfg/shimx64.efi.signed Richtlinie: Keine 067 Name der Startdatei: linux/pxelinux.0 Richtlinie: PXE BootFile Legacy BIOS
Die folgenden Informationen stammen von Univention:
https://help.univention.com/t/how-to-configure-a-dhcp-switch-for-uefi-and-non-uefi-boot/9931
Seit opsipxeconfd 4.0.7.7 ist es möglich, den Pfad der, als Vorlage verwendeten Dateien über die Konfigurationsdatei opsipxeconfd.conf
anzupassen.
Dazu können in dieser Datei über die Optionen uefi netboot config template x86
bzw. uefi netboot config template x64
die Pfade zu den entsprechenden Dateien angegeben werden.
Ob ein UEFI BIOS für die Anforderungen eines Client-Management-Systems wie opsi geeignet ist, hängt von verschiedenen Kriterien ab. Diese Kriterien sagen nichts über die Qualität des Gerätes als solches aus, sondern nur über seine Wartbarkeit per Netboot-Anbindung. Es geht hier also um die BIOS-Funktionen zum UEFI Netboot. Hier ein beispielhafter Vergleich :
Tabelle 9.13. Beispiele für UEFI BIOS Unterschiede
Lenovo Twist | MS-Surface | Dell Venue 11 | |
---|---|---|---|
UEFI pur | √ | √ | √ |
UEFI + CSM | √ | x | √ |
Legacy | √ | x | √ |
Both | √ | x | x |
UEFI Netboot | √ | √ | √ |
Aktivierbarer Eintrag | √ | x | √ |
Netboot ohne Interaktion | √ | x | √ |
Unter Aktivierbarer Eintrag verstehen wir, dass sich per Standard-Software ein Netboot für den nächsten Reboot aktivieren lässt. Netboot ohne Interaktion bedeutet, dass ein aktivierter Netboot-Eintrag beim Reboot ausgeführt wird und dazu keine Interaktion (drücken von Tastenkombinationen, F12-Taste, …) nötig sind. Sind diese Vorausetzungen gegeben, können bestimmte opsi Produkte einen Netboot auslösen. Dies ist für die Automatisierung von Abläufen von großer Bedeutung. Ein Produkt in dem dies implementiert ist, ist das Localbootprodukt für Windows und Linux opsi-uefi-netboot
.
Die folgenden Unterkapitel dienen als Wissensbasis zu dem händigen oder gescripteten Umgang mit UEFI / GPT. Zum Verständnis wie opsi mit UEFI/GPT arbeitet sind sie nicht erforderlich.
Manipulation der UEFI Bootloader Einträge passiert unter Linux mit dem Programm efibootmgr
.
Liste der Booteinträge:
efibootmgr -v BootCurrent: 000D Timeout: 0 seconds BootOrder: 0012,0011,000D,0010,000B,0009,0007,0008,000A,000C Boot0000 Setup Boot0001 Boot Menu (..) Boot0007* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55 Boot0008* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49 Boot0009* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600 Boot000D* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803 Boot0010* ubuntu HD(1,800,31801,faffb7b9-bdf9-4767-b475-0b8aee68d3ac)File(\EFI\ubuntu\grubx64.efi) Boot0011* opsitempwinpe HD(4,3c72800,7cf801,dc1cea68-a296-4fb8-a97a-263227ed86f4)File(\EFI\boot\bootx64.efi) Boot0012* Windows Boot Manager HD(1,800,31801,5e4ffde2-3e25-42dd-b0f7-fcb7ee5d2b20)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Manipulation der UEFI Bootloader Einträge passiert unter Windows mit dem Programm bcdedit
.
Liste der Booteinträge:
bcdedit /enum firmware Start-Manager für Firmware - - - - - - - - - - - - - - - Bezeichner {fwbootmgr} displayorder {bootmgr} {99a9f9be-9a98-11e3-b22f-806e6f6e6963} {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4} {11a8b986-99df-11e3-ae5c-b888e3e3cbb4} Windows-Start-Manager - - - - - - - - - - - - - - - Bezeichner {bootmgr} device partition=\Device\HarddiskVolume1 path \EFI\Microsoft\Boot\bootmgfw.efi Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b971-99df-11e3-ae5c-b888e3e3cbb4} description Setup Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b972-99df-11e3-ae5c-b888e3e3cbb4} description Boot Menu (...) Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b978-99df-11e3-ae5c-b888e3e3cbb4} description USB CD Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b979-99df-11e3-ae5c-b888e3e3cbb4} description USB FDD Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b97a-99df-11e3-ae5c-b888e3e3cbb4} description ATA HDD0 Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4} description PCI LAN Firmwareanwendung (101fffff) - - - - - - - - - - - - - - - Bezeichner {99a9f9be-9a98-11e3-b22f-806e6f6e6963} device partition=X: path \EFI\boot\bootx64.efi description opsitempwinpe
Mit beiden Programmen lassen sich Einträge erstellen, löschen, der nextboot setzen und die Reihenfolge manipulieren.
Beispiel: Eintrag für den nächsten Boot setzen:
efibootmgr /bootnext <hexId>
bcdedit /set {fwbootmgr} bootsequence <GUID>
GPT Partitionen kennen neue Partitionstypen. Diese sind an die bisher bekannten angelehnt. So wird aus dem Partitionstyp für NTFS 07
unter GPT 0700
. Analog wird aus den Linux Partitionstypen 82
und 83
entsprechend 8200
und 8300
.
Die Liste der bekannten Partitionstypen kann man sich anzeigen lassen:
# sgdisk -L 0700 Microsoft basic data 0c01 Microsoft reserved 2700 Windows RE 4100 PowerPC PReP boot 4200 Windows LDM data 4201 Windows LDM metadata 7501 IBM GPFS 7f00 ChromeOS kernel 7f01 ChromeOS root 7f02 ChromeOS reserved 8200 Linux swap 8300 Linux filesystem 8301 Linux reserved 8302 Linux /home 8400 Intel Rapid Start 8e00 Linux LVM a500 FreeBSD disklabel a501 FreeBSD boot a502 FreeBSD swap a503 FreeBSD UFS a504 FreeBSD ZFS a505 FreeBSD Vinum/RAID a580 Midnight BSD data a581 Midnight BSD boot a582 Midnight BSD swap a583 Midnight BSD UFS a584 Midnight BSD ZFS a585 Midnight BSD Vinum a800 Apple UFS a901 NetBSD swap a902 NetBSD FFS a903 NetBSD LFS a904 NetBSD concatenated a905 NetBSD encrypted a906 NetBSD RAID ab00 Apple boot af00 Apple HFS/HFS+ af01 Apple RAID af02 Apple RAID offline af03 Apple label af04 AppleTV recovery af05 Apple Core Storage be00 Solaris boot bf00 Solaris root bf01 Solaris /usr & Mac Z bf02 Solaris swap bf03 Solaris backup bf04 Solaris /var bf05 Solaris /home bf06 Solaris alternate se bf07 Solaris Reserved 1 bf08 Solaris Reserved 2 bf09 Solaris Reserved 3 bf0a Solaris Reserved 4 bf0b Solaris Reserved 5 c001 HP-UX data c002 HP-UX service ea00 Freedesktop $BOOT eb00 Haiku BFS ed00 Sony system partitio ef00 EFI System ef01 MBR partition scheme ef02 BIOS boot partition fb00 VMWare VMFS fb01 VMWare reserved fc00 VMWare kcore crash p fd00 Linux RAID
Tatsächlich sind diese hier gezeigten Partitionstypen nur Abkürzungen für die eigentlich verwendeten GUID’s welche dem Partitionierungsschema den Namen gegeben haben.
Also:
0700
steht für Microsoft basic data
und für die GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
Eine Liste der GUID’s findet sich z.B. bei Wikipedia:
https://de.wikipedia.org/wiki/GUID_Partition_Table#Partitionstyp-GUIDs
https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
Weiterhin kennt das Werkzeug gdisk (und sgdisk, …) eine interne Ersetzungstabelle für unbekannte Partitionstypen. So gibt es für den alten Partionstyp für vfat32 0b
keine Entsprechung als 0b00
. Übergibt man aber trotzdem 0b00
als Typ an sgdisk so wird ohne jede Meldung hieraus 0700
. Dies passiert wohl nach der Überlegung: vfat32 - das wird schon eine Microsoft Daten Partition sein…
GPT Partitionen kennen Attribute.
Liste der z.Zt. bekannten Attribute
Wert | Beschreibung | Attributwert (sgdisk --info / diskpart gpt attribute) |
nix | nix | 0000000000000000 |
0 | Systempartition (system partition) | 0000000000000001 |
1 | Verstecke die Partition vor EFI (hide from EFI) | 0000000000000002 |
2 | Legacy Bootflag (legacy BIOS bootable) | 0000000000000004 |
60 | Nur lesen (read-only) | 1000000000000000 |
62 | Versteckt (hidden) | 4000000000000000 |
63 | Nicht Einhängen (do not automount) | 8000000000000000 |
Die Attribute werden unter Linux bei sgdisk über die Option -A, --attributes
unter Verwendung der Kurzform und unter Windows über diskpart mit dem Befehl gpt attributes
unter Verwendung der Langform gesetzt.
Beispiele:
select disk 0 select partition 1 gpt attributes=0x0000000000000000
sgdisk -t 1:0700 --attributes 1:clear:63 --attributes 1:set:62 -p /dev/sda
Anzeigen der Partitionstabelle mit -p , --print
:
sgdisk -p /dev/sda
Anzeigen der Detailinfos zu einer Partition (1) mit --info=
:
sgdisk --info=1 /dev/sda
Die verschiedenen OEM Hersteller liefern mit Secureboot (manchmal auch Secure Boot geschrieben) eine zusätzliche Sicherheitsebene, mit der nur autorisierte Software und Betriebssysteme installiert werden können. Diese Autorisierung geschieht über eine Schlüsselabfrage im UEFI. Sofern die verwendeten Schlüssel zueinander passen, gilt die Software als autorisiert. Die Schlüssel im UEFI wurden vom Microsoft und meist dem OEM Hersteller erstellt und jedes geladene Binary im Secureboot Modus muss auch von mit dem privaten Schlüssel des Schlüsselerstellers signiert werden. Diesen Vorgang nennt man auch chain of trust. Nur wenn alle Elemente der Sicherheitskette die Signaturen verifizieren, ist die Installation erfolgreich.
Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung. Dies bedeutet unter anderem, das Sie zum Einsatz eine gekaufte Freischaltung benötigen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung (→ mail an info@uib.de). Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können.
Technische Voraussetzungen sind opsi mit den Paketständen:
Tabelle 9.14. Benötigte Paketstände
Paket | Version |
---|---|
opsi-linux-bootimage | >= 201900923-4 |
opsipxeconfd | >= 4.1.1.15-1 |
Clients müssen mit ihrer Firmware UEFI Secure Boot unterstützen. Die Installation eines Clients mit Secureboot wird nur, wie mit UEFI, in 64-Bit unterstützt.
Für die Installation über UEFI Netboot wird ein UEFI-taugliches winpe_uefi (analog dem winpe für die legacy-Installation) benötigt.
Oftmals enthält ein existentes winpe bereits UEFI-Unterstützung (Ordner EFI
und Datei bootmgr.efi
im winpe-Ordner des opsi-Netboot-Produkts).
Ist dies nicht der Fall, sollte ein aktuelles winpe mittels dism
erstellt werden (siehe: "Erstellen eines Winpe" im "Getting-Started - Dokument").
Ein UEFI taugliches winpe wird im Ordner winpe_uefi neben dem winpe verzeichnis erwartet.
Sofern man ein winpe für beide Bootmodi hat, kann man winpe_uefi durch einen Soft-Link auf winpe ersetzen.
Einen externen DHCP-Server müssen Sie so konfigurieren, dass er ein UEFI Netboot über den opsi-server ermöglicht.
Als Bootfile ist einzutragen: linux/pxelinux.cfg/shimx64.efi.signed
Im Managementinterface opsi-configed muss für uefi-Clients das Häkchen "Uefi-Boot" gesetzt sein oder aber der Hostparameter clientconfig.dhcpd.filename den Wert linux/pxelinux.cfg/elilo.efi Client-spezifisch konfiguriert werden. Diese Einstellung kann auch über folgenden Kommandozeilen-Aufruf erfolgen:
opsi-admin method configState_create "clientconfig.dhcpd.filename" "<hier host id einfügen>" "linux/pxelinux.cfg/elilo.efi"
Die Angabe der Datei elilo.efi dient lediglich zum setzen des UEFI Hakens im opsi-configed. Dies hat keinerlei Einfluss auf die Verwendung der DHCP Bootdatei. Der opsi-configed wird in einer zukünftigen Version die korrekte Datei akzeptieren und eine Secureboot Checkbox setzen.
Zusätzlich müssen in der Konfigurationsdatei des opsipxeconfd
die Template-Dateien für die UEFI Installation geändert werden.
Die Konfiguration des uefi netboot config template x64
muss zu /tftpboot/linux/pxelinux.cfg/install-grub-x64
geändert werden.
Nach dieser Änderung ist es ratsam den Befehl opsi-setup --init-current-config durchzuführen.
Alle UEFI Clients booten die vom opsi-linux-bootimage
mitgelieferte und von Microsoft signierte Datei shimx64.efi.signed
.
Clients mit aktiviertem Secureboot verifizieren die Signatur und springen in den nächsten Schritt.
Clients ohne Secureboot scheitern bei der Verifikation.
Nichtsdestotrotz springen die Clients dann in den Grub2 Bootloader und fahren mit der Installation fort.
Der Installationvorgang unterscheidet sich nicht.
Secureboot Clients sind bei Installationsabschluss im sogenannten sicheren Startzustand
, gewöhnliche UEFI Clients nicht.
Diesen Zustand können Sie mit dem Befehl msinfo32
im gebooteten Windows prüfen.
Bitte beachten Sie, dass die Begriffe sich je nach Hersteller und Hardware-Modell unterscheiden.
Das UEFI des Clients sollte wie folgt konfiguriert werden:
Dieses Modul ist momentan eine
kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen
zu können. Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie, wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Abschnitt 9.1, „Freischaltung kostenpflichtiger Module“.
Mit der Berechtigung opsi-local-image zu verwenden erwerben Sie gleichzeitig auch das Recht, die Erweiterung opsi-vhd-reset (siehe Abschnitt 9.9, „opsi vhd reset“) zu verwenden.
Technische Voraussetzungen sind opsi 4.0.3 mit den Paketständen:
Für das Produkt opsi-local-image-capture
muss der share opsi_depot_rw
für pcpatch beschreibbar sein. Prüfen Sie Ihre Samba Konfiguration.
Opsi bietet eine gute Basis, um automatisiert Windows Rechner zu installieren und zu pflegen - auch und gerade, wenn es sich um heterogene Hardware handelt. Die von opsi unterstützte Technik der Paket basierten Installation ist aber nicht schnell genug, um in Schulungsräumen Rechner innerhalb von kurzer Zeit wie z.B. in einer Pause zwischen zwei Kursen wieder in einen definierten Zustand zu versetzen. Daher wird hier ein Konzept vorgestellt, bei dem die paketbasiert durchgeführte Installation lokal auf einer zweiten Partition als Imagekopie gesichert wird und von dort eine schnelle Wiederherstellung möglich ist.
Die Anforderungen edukativer Computernetze unterscheiden sich teilweise von denen anderer Netzwerke. Eine wesentliche Anforderung, die im Folgenden diskutiert wird, ist die schnelle Wiederherstellung von Rechnern in einen definierten Zustand, den Sie im Rahmen einer temporären Nutzung verloren haben. Konkret geht es um die Bereitstellung von Rechnern in schulischen Computerräumen, wobei die Problemlage auch auf kommerzielle Computerräume oder universitäre Computerpools zutrifft.
Die Wiederherstellung soll innerhalb von kurzer Zeit (ca. 15 Minuten) erfolgen und sollte soweit möglich einen Rechner nicht nur zurücksetzen sondern auf eine andere Basisinstallation (z.B. Win XP / Win 7 / Linux) umschalten können.
Weiterhin muss es möglich sein, dass eine kontinuierliche Pflege der Systeme mit Sicherheitsupdates gewährleistet ist.
Die Üblichen Techiken zur Installation von PC’s haben verschiedene spezifische Vor- und Nachteile:
Tabelle 9.16. Vor- und Nachteile von Unattend und Image Lösungen
Feature | Unattend | Image |
---|---|---|
Geschwindigkeit | (-) langsam | (+) schnell |
Empfindlichkeit gegen heterogene Hardware | (+) gering | (-) hoch |
Netzwerkbelastung | (-) hoch | (-) hoch |
Das Konzept von opsi-local-image versucht die Vorteile beider klassischen Konzepte miteinander zu kombinieren:
Tabelle 9.17. opsi-local-image
Feature | Unattend |
---|---|
Geschwindigkeit | (+) schnell |
Empfindlichkeit gegen heterogene Hardware | (+) gering |
Netzwerkbelastung | (+) gering |
Das Konzept kann in den folgenden Stichpunkten zusammengefasst werden:
Der Schulungsrechner wird mit einer statischen Partitionstabelle verwendet. Dabei kann entweder mit 3 oder 4 Partitionen gearbeitet werden:
opsi-local-image-prepare
über ein Property gesteuert.
opsi-local-image-prepare
über ein Property gesteuert.
Die Netbootprodukte zur Betriebssystem Installation verwenden nur die ersten zwei oder drei Partitionen (XP nur die erste) und lassen die letzte Backup-Partition unberührt. Somit bleiben die auf der Partition 4 (backup) liegenden Images auch bei der Installation eines neuen Betriebssystems erhalten.
Über das Produkt opsi-local-image-prepare
wird zunächst die notwendige statische Partitionierung erzeugt.
Anschließend können über die Produkte opsi-local-image-win
* und andere verschiedene Betriebssysteme mit unterschiedlicher Ausstattung an Anwendungssoftware installiert werden.
Diese werden per default nach Ihrer Installation automatisch als Image gesichert.
Der einfache Aufruf des Produktes opsi-local-image-restore
stellt automatisch das letzte erstellte Image wieder her. Soll ein anderes Image wieder hergestellt werden, so muss dies im Property imagefile
angegeben werden.
opsi-auto-update
ist ein Produkt, um die Pflege der Clients zu vereinfachen.
Im Kern ist es die Aufgabe des Produktes, dafür zu sorgen, die installierten Produkte aktuell zu halten.
Das Produkt setzt alle installierten Produkte,
deren Version nicht identisch mit der auf dem Server ist,
für den Client auf setup.
Da dieses Produkt nicht nur im Kontext von opsi-local-image eingesetzt werden kann, ist es im Kapitel opsi Standardprodukte / opsi-auto-update beschrieben:
„opsi-auto-update“
Die opsi-local-image Produkte ab Version 4.1 unterstützen auch Mehrplattensysteme. Bitte beachte Sie dazu auch den Abschnitt Abschnitt 8.2.3, „Hinweise zu den NT6 Netbootprodukten (Win 7 bis Win 10)“
Das Paket opsi-local-image besteht aus folgenden Produkten
Das Netbootprodukt zur Partitionierung
opsi-local-image-prepare
Die Netbootprodukte zur Betriebssystem Installation:
opsi-local-image-winxp
opsi-local-image-win7
opsi-local-image-win7-x64
opsi-local-image-win81
opsi-local-image-win81-x64
opsi-local-image-win10
opsi-local-image-win10-x64
opsi-local-image-ubuntu
Den Netbootprodukten zum Handling der lokalen Images
opsi-local-image-backup
opsi-local-image-restore
opsi-local-image-delete
Den Lokalbootprodukten zur Ablaufsteuerung:
opsi-local-image-backup-starter
opsi-auto-update
Zur Installation der Produkte stellen Sie bitte in der Datei /etc/opsi/package-updater.repos.d/uib-local_image.repo
das Attribut active des Repositories uib_local_image auf True.
Anschließend können Sie über einen Aufruf von opsi-package-updater --repo uib_local_image install
die neuen Produkte installieren lassen.
opsi-local-image-prepare
Erstellung der statischen Partitionierung der Festplatte für alle anderen Produkte.
Properties:
opsi-local-image-restore
die Produktproperties imagefile und imagefiles_list gelöscht, da durch die Neupartitionierung diese Daten ungültig geworden sind.
system_partition_size
+ data_partition_size
+ winpe_partition_size
).minimal_backup_partition_size
wird mit einem Fehler abgebrochen.Verwenden Sie dieses Produkt nur zur initialen Vorbereitung der Platte. Es löscht alle gespeicherten Images.
Die Netbootprodukte zur Installation von Windows sind Abkömmlinge der opsi Standardprodukte zur Windowsinstallation. Das bedeutet konkret, dass sie bezüglich des Aufbaus und der Treiberintegration identisch sind. Entsprechende Anleitungen finden sich im opsi-getting-started Handbuch.
Die Properties der Windows NT6 Produkte ab Version 4.1 sind eine Teilmenge der Properties der NT6 Standardprodukte, wie sie im Abschnitt Abschnitt 8.2.3, „Hinweise zu den NT6 Netbootprodukten (Win 7 bis Win 10)“ beschrieben sind. Die fehlenden Properties zu Platten und Partitionen werden dem Produkt opsi-local-image-prepare
entnommen.
Ändern Sie die Propertyeinstellungen von opsi-local-image-prepare nicht mehr nachdem Sie die Maschine damit präpariert haben, da die nachfolgenden Produkte auf diese Werte zugreifen.
opsi-local-image-winxp
opsi-local-image-win7
opsi-local-image-win7-x64
opsi-local-image-win81
opsi-local-image-win81-x64
opsi-local-image-win10
opsi-local-image-win10-x64
Diese Produkte haben folgende opsi-local-image spezifische Properties:
imageFile
des Produktes opsi-local-image-restore
gelöscht. Dies führt dazu, dass das erstellte Backup den Namen des laufenden Netbootproduktes (z.B. opsi-local-image-win7
) bekommt.
opsi-local-image-ubuntu
Installation von Ubuntu Linux 12.04/14.04 32Bit/64Bit.
Das installierte System kennt 2 user: root
und user
. Für root wird das im Produktproperty root_password
festgelegte Passwort gesetzt (Default: linux123
). Für user wird das im Produktproperty user_password
festgelegte Passwort gesetzt (Default: linux123
).
Details der Installation werden über Produktproperties gesteuert. Die wesentlichen Produktproperties sind dabei:
askbeforeinst
:architecture
:additional_packages
:language
:console_keymap
timezone
:online_repository
proxy
:http://<ip>:<port>
. (Default = '')
backup_after_install
setup_after_install
wget_and_execute
:release
:install_opsi-client-agent
:
opsi-local-image-backup
Dieses Produkt sichert das aktuell auf Partition 1 installierte Betriebssystem in einer Imagedatei auf Partition 4. Als Image Namen wird der im Property gesetzte Name verwendet. Wenn dieser leer ist, so wird der Name des opsi Netbootproduktes verwendet, welcher aktuell auf installed steht (z.B. opsi-local-image-winxp
). Dieser Name wird beim Produkt opsi-local-image-restore
als Produktproperty imagefile gesetzt, so daß ein nachfolgender Aufruf von opsi-local-image-restore
per default genau dieses Image wiederherstellt. Dieser Name wird beim Produkt opsi-local-image-restore
dem Produktproperty imagefiles_list hinzugefügt. Damit enthält dieses Property die Liste aller verfügbaren Images. Weiterhin werden (für die Windows-Produkte) die aktuellen opsi-Produktstände zusammen mit dem Image gesichert, damit auch diese im Rahmen des restores wiederhergestellt werden können.
Als Sicherungsmethode wird partclone verwendet.
Properties:
askbeforeinst
:free_on_backup
:imagefile
setup_after_install
opsi-local-image-restore
Dieses Produkt spielt das im Produktproperty imagefile angegebene Image wieder auf der Partition 1 ein und sorgt dafür, dass es gebootet werden kann. Weiterhin werden (für die Windows-Produkte) die für das Image gesicherten opsi-Produktstände zusammen mit dem Image wiederhergestellt.
Properties:
askbeforeinst
:architecture
:imagefile
imagefiles_list
.
imagefiles_list
update_and_backup
opsi-auto-update
. Dieses ist es im Kapitel opsi Standardprodukte / opsi-auto-update beschrieben:setup
gestellt werden und das Produkt opsi-local-image-backup-starter
auf once
gesetzt wird. Dies führt dazu, dass alle vorhandenen Updates eingespielt und nach den Updates automatisch wieder eine Sicherung durchgeführt wird.
setup_after_restore
opsi-local-image-delete
Dieses Produkt löscht das im Produktproperty imagefile angegebene Image von der Backup Partition
imagefile
opsi-local-image-backup-starter
opsi-local-image-backup
auf setup und rebootet den Rechner dann. Dieses Produkt hat eine sehr niedrige Priorität von -98. Dies bedeutet das alle normalen Localboot Produkte vorher abgearbeitet werden.
opsi-auto-update
Im Rahmen dieser Erweiterung können die Rechner eines Schulungsraums in einer opsi-client Gruppe zusammengefasst werden. Um möglichst komfortable Aktionen für alle Rechner eines Schulungsraums auszulösen sind folgende Erweiterungen der opsi-service Methoden vorgesehen:
setProductActionRequestForHostGroup
hostGroupId, productId, actionRequest
setProductPropertyForHostGroup
productId propertyId propertyValue hostGroupId
getPossibleImagefileValuesForHostGroup
groupId
opsi-local-image-backup
auf allen Mitgliedern der Gruppe angelegt hat. Wenn ein bestimmtes Image (z.B. opsi-local-image-winxp
) auf einem oder mehreren Rechnern nicht vorhanden ist, so ist es nicht Bestandteil der Rückgabeliste.
Diese Methoden werden zu einem späteren Zeitpunkt in die Standardpakete von opsi integriert. Bis dahin steht Ihnen in der Auslieferung eine Datei 40_groupActions.conf
zur Verfügung, die Sie bitte mit root Rechten nach /etc/opsi/backendManager/extend.d
kopieren. Führen Sie danach aus:
opsi-setup --set-rights /etc/opsi
.
Die Backuppartion ist (bei MBR BIOS und ohne Datenpartition) die dritte Partition der System-Festplatte.
Bei Systemen mit mehr als einer Platte wird die Systemfestplatte bestimmt durch das opsi-local-image-prepare Property multi_disk_mode.
Bei Systemen mit mehr als einer Platte kann sich die Backuppartition abhängig vom opsi-local-image-prepare Property backup_partition_on_same_disk auch als erste Partition einer anderen Platte befinden.
Dort finden sich:
master.log
mit Informationen über alle durchgeführten Image Operationen. Diese Logdatei wird in die bootimage logs übernommen.
opsi-local-image-ubuntu
: 3.6G
opsi-local-image-winxp
: 6.4G
opsi-local-image-win7
: 9.4G
opsi-local-image-win7-x64
: 13G
Microsoft hat mit NT6 (also ab Vista) zur Installation ein neues Imageformat, das Windows Imaging Format (WIM) eingeführt. Ein WIM Image ist kein Platten- oder Partitionsimage, sondern mehr ein Dateien und Metadaten Archiv. Eine WIM Datei kann mehrere Images enthalten. Die normale Installation eines NT6 Rechners basiert darauf, dass die setup.exe ein Image aus der Datei install.wim auspackt und dieses danach konfiguriert und mit zusätzlichen Treibern versieht.
Von einem existierender Rechner kann das Windows inklusive installierter Software, Hotfixes und Konfigurationen ausgelesen und in Form eines WIM abgespeichert werden. Ein solches WIM kann dann wieder die Basis für neue Installationen sein.
Für die Erstellung eines Capture Images im Wim Format benötigen Sie ab den Produktversionen 4.1 nur noch das Produkt:
opsi-local-image-wim-capture
Die vorherigen Produkte:
opsi-local-image-capture
opsi-local-image-sysprep
Sind damit obsolet und können gelöscht werden.
Ergänzend gibt es die Zielprodukte welche dafür gedacht sind, das gecapturte Image aufzunehmen:
opsi-local-image-win7-capture
opsi-local-image-win7-x64-capture
opsi-local-image-win81-capture
opsi-local-image-win81-x64-capture
opsi-local-image-win10-capture
opsi-local-image-win10-x64-capture
Die Abläufe und Einstellungen beim Produkt opsi-local-image-wim-capture
entsprechen denen des Produktes opsi-wim-capture
welches hier: Abschnitt 9.4, „opsi WIM Capture“