Wichtige Dateien des opsi-servers

Allgemeine Konfigurationsdateien in /etc

/etc/hosts

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.

/etc/group

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.

/etc/opsi/backends/

Konfigurationsdateien der verwendeten Backends.

/etc/opsi/backendManager/

acl.conf
Konfiguration der Zugriffsrechte auf die opsi Methoden. Hierbei können für die Basis-Methoden des Webservices Zugriffsrechte für bestimmte Benutzer und auf bestimmte Attribute eingeschränkt werden.
dispatch.conf
Konfiguration welche der unter /etc/opsi/backends/ konfigurierten Backends wofür verwendet werden sollen.
extend.d/
Verzeichnis der Backenderweiterungen. So liegen hier z.B. die Scripte, welche die opsi 3 Methoden auf die opsi 4 Methoden mappen.

/etc/opsi/hwaudit/*

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 (für Windows) bzw. shell-Programmen (für Linux) und der opsi Datenhaltung konfiguriert.

/etc/opsi/opsi.conf

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.

/etc/opsi/modules

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.

Verzeichnis /etc/opsi/modules.d/

Ab opsi Version 4.1

Für zukünftige Verwendung angedachtes Verzeichnis.

/etc/opsi/opsiconfd.conf

Ab opsi Version 3.0

Konfigurationsdatei für den opsiconfd in dem sonstige Konfigurationen wie Ports, Interfaces, Logging hinterlegt sind.

/etc/opsi/opsiconfd.pem

Ab opsi Version 3.0

Konfigurationsdatei für den opsiconfd in dem das ssl-Zertifikat hinterlegt ist.

/etc/opsi/opsipxeconfd.conf

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.

/etc/opsi/opsi-package-updater.conf

Konfigurationsdatei für den opsi-package-updater.

Siehe opsi-package-updater

Bootdateien

Bootdateien in /tftpboot/linux

pxelinux.0
Bootfile, der im ersten Schritt vom PXE-Bootprom geladen wird.
install und miniroot.gz
Installationsbootimage, das per tftp an den Client bei der Reinstallation übertragen wird.

Bootdateien in /tftpboot/linux/pxelinux.cfg

01-<mac adresse> bzw. <IP-NUMMER-in-Hex>
Dateien mit der Hardwareadresse des Clients und dem Prefix 01 - sind auf dem opsi-Server als clientspezifische Bootfiles zu finden. Sie sind zumeist über den opsipxeconfd als named pipes erzeugt und sollen eine Reinstallation des Clients einleiten.
default
Die Datei default wird geladen, wenn es keine clientspezifischen Dateien gibt. Wird diese Datei geladen, so bootet der Client danach lokal weiter.
install
Informationen zum boot des Installationsbootimages, die vom opsipxeconfd in die named pipe geschrieben werden.

Dateien in /var/lib/opsi

/var/lib/opsi/depot

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.

/var/lib/opsi/ntfs-images

In diesem Verzeichnis werden (per default) Partionsimages abgelegt, welche mit dem Netboot-Produkt opsi-clonezilla ausgelesen werden.

/var/lib/opsi/repository

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.

/var/lib/opsi/workbench

Dieser Ordner beinhaltet die Stände der eigenen Software-Paketierung.

Weitere Verzeichnisse

Die restlichen Verzeichnisse in /var/lib/opsi (config und audit) sind Verzeichnisse des File-Backends, welche im folgenden Kapitel beschrieben sind.

Dateien des file Backends

/etc/opsi/pckeys

Hier sind die clientspezifischen opsi-Hostschlüssels sowie der Schlüssel des Servers selber abgelegt.

Beispiel:

schleppi.uib.local:fdc2493ace4b372fd39dbba3fcd62182
laptop.uib.local:c397c280fc2d3db81d39b4a4329b5f65
pcbon13.uib.local:61149ef590469f765a1be6cfbacbf491

/etc/opsi/passwd

Hier sind die mit dem Schlüssel des Servers verschlüsselten Passwörter (z.B. für pcpatch) abgelegt.

Übersicht /var/lib/opsi

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!

Konfigurationsdateien im Detail

In den folgenden Kapiten werden die Konfigurationsdateien des file-Backends im Detail vorgestellt.

./clientgroups.ini

Die Datei enthält die Informationen über Client-Gruppen.

[<GroupId>]
<HostId> = 1 #aktiv
<HostId> = 0 #inaktiv

./config.ini

Hier finden sich die Defaultwerte der Serverkonfiguration wie im opsi-configed im Tab Host Parameter angezeigt.

./clients/<FQDN>.ini

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>

/var/lib/opsi/config/templates

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.

/var/lib/opsi/config/depots/

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.

Product control files in /var/lib/opsi/config/products/

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:

Sektion [Package]
Beschreibung der Paketversion und Abhängigkeiten für die Installationen des Pakets auf dem opsi-Depotserver.
Sektion [Product]
Beschreibung des Produktes.
Sektion(en) [ProductProperty]
(optional)
Beschreibung von veränderbaren Produkteigenschaften.
Sektion(en) [ProductDependency]
(optional)
Beschreibung von Produktabhängigkeiten.

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

[Package]-Version
ist die Version des Paketes für die Produktversion. Die dient dazu, Pakete mit gleicher Produktversion aber z. B. korrigiertem opsi-script-Skript zu unterscheiden.
[Package]-depends
Gibt ein für die Installation auf einem opsi-Depotserver benötigtes Paket an. Bestimmte Versionen können konfiguriert werden, indem die Versionsangabe in Klammern nach dem Paketnamen erfolgt. Einer der folgenden Operatoren muss der Version innerhalb der Umklammerung vorangstellt sein: =, <, ⇐, >, >=.
[Package]-Incremental
Dies ist eine veraltete, auswirkungslose Einstellung, welche seit opsi 4.1 in neuen Paketen nicht mehr gesetzt wird. Sie können diesen Eintrag löschen.
[Product]-type
gibt die Art des Produktes an localboot/netboot.
[Product]-Id
ist ein eindeutiger Bezeichner für das Produkt; in der Regel unabhängig von der Version.
[Product]-name
ist der Klartextname des Produkts.
[Product]-Description
ist eine ergänzende Beschreibung zum Produkt, die z.B. im opsi-configed unter Beschreibung angezeigt wird.
[Product]-Advice
ist eine ergänzende Beschreibung (in der Regel) zum Umgang mit dem Produkt, die zu beachten ist und im opsi-configed unter Notiz angezeigt wird.
[Product]-version
ist die Version der eingepackten Software.
[Product]-Priority
beeinflusst zusammen mit den Produktabhängigkeiten die Installationsreihenfolge.
[Product]-productClasses
wird zur Zeit noch nicht verwendet (und auch nicht angezeigt).
[ProductProperty]-type
Typ des properties: (unicode/boolean)
[ProductProperty]-name:
Anzeigename der Eigenschaft.
[ProductProperty]- multivalue
Kann dieses Property eine Liste von Werten enthalten. (True/False)
[ProductProperty]- editable
Kann dieses Property frei editiert werden (oder kann nur aus einer vorgegebnenen Liste ausgewählt werden). (True/False)
[ProductProperty]-description:
Beschreibung der Eigenschaft (Tooltip im opsi-configed).
[ProductProperty]-values :
Liste möglicher, erlaubte Werte. Wenn leer, dann ist der Wert frei editierbar.
[ProductProperty]-default :
Default Wert der Eigenschaft.
[ProductDependency]-Action :
für welche Aktion des Produktes, welches Sie gerade erstellen, soll die Abhängigkeit gelten (setup, uninstall …).
[ProductDependency]-Requiredproduct:
Product-id (Bezeichner) des Produkts, zu dem eine Abhängigkeit besteht.
[ProductDependency]-Required action:
Sie können entweder eine Aktion anfordern oder (siehe unten) einen Status. Aktionen können z.B. sein : setup, uninstall, update …
[ProductDependency]-Required installation status:
Status, den das Produkt zu dem eine Abhängigkeit besteht, haben soll. Typischerweise installed - liegt ein anderer Status vor, so wird das Produkt auf setup gestellt.
[ProductDependency]-Requirement type:
Installationsreihenfolge. Wenn das Produkt zu dem eine Abhängigkeit besteht installiert sein muss, bevor mit der Installation des aktuellen Produkts begonnen werden kann, dann ist dies before. Muss es nach dem aktuellen Produkt installiert werden, so ist dies after. Ist die Reihenfolge egal, so muss hier nichts eingetragen werden.

Inventarisierungsdateien /var/lib/opsi/audit

Hier liegen die Dateien der Hardwareinventarisierung (*.hw) und der Softwareinventarisierung (*.sw).

opsi Programme und Libraries

Programme in /usr/bin

opsipxeconfd
Opsi Daemon, welcher für den PXE-Start der Clients die notwendigen Dateien im tftp-Bereich des Servers verwaltet.
opsi-admin
Kommandozeilen-Interface zur opsi python Library.
opsiconfd
Opsi Daemon zur Bereitstellung der opsi Methoden als Webservice und vieles mehr.
opsiconfd-guard
Opsi Daemon, der überwacht, ob der opsiconfd läuft und diesen im Zweifelsfall neu startet.
opsi-configed
Aufruf des opsi-Managementinterface.
opsi-convert
Skript zum Konvertieren zwischen verschiedenen Backends.
opsi-makepackage
Skript zum opsi-Paket packen.
opsi-newprod
Skript zum Erstellen eines neuen Produktes.
opsi-package-manager
Skript zum Installieren und Deinstallieren von opsi-Paketen auf einem opsi-server.
opsi-setup
Programm für diverse Basiskonfigurationen.

opsi-Logdateien

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)

/var/log/opsi/bootimage

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:

Netzwerk geht
Dann kann man per SCP z.B. von Windows aus per WinSCP die Datei /tmp/log holen.
Netzwerk geht nicht
Dann hilft der USB-Stick:
- Als root mit pass 'linux123' einloggen
- USB-Stick einstecken und ein paar Sekunden warten
- mit sfdisk -l prüfen, auf welchem Device der Stick liegt
- mounten
- kopieren
- unmounten

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

/var/log/opsi/clientconnect

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.

/var/log/opsi/instlog

Hier findet sich die Logdatei der auf den Clients ausgeführten opsi-script-Skripte.
Die Originale liegen auf dem Client unter C:\opsi.org\log\opsiscript.log

/var/log/opsi/opsiconfd

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.

/var/log/opsi/opsipxeconfd.log

Logdatei des opsipxeconfd
welcher für den PXE-Start der Clients die notwendiogen Dateien im tftp-Bereich des Servers verwaltet.

/var/log/opsi/package.log

Logdatei des opsi-package-manager.

/var/log/opsi/opsi-package-updater.log

Logdatei des opsi-package-updater.

tftp log in /var/log/syslog

Die Logeinträge des tftpd finden sich in /var/log/syslog.

c:\opsi.org\log\opsi_loginblocker.log

Logdatei des Loginblockers.

c:\opsi.org\log\opsiclientd.log

Logdatei des 'opsiclientd'.
Wird bei Beendigung auf den Server nach /var/log/opsi/clientconnect/<FQDN.>log kopiert.

c:\opsi.org\log\opsi-script.log

Logdatei des 'opsi-script'.
Wird bei Beendigung auf den Server nach /var/log/opsi/instlog/<FQDN.>log kopiert.