Datenhaltung von opsi (Backends)

file-Backend

Bei Verwendung des File-Backends liegen die Konfigurationsinformationen in Ini-Dateien auf dem Server.

Wesentliche Merkmale des Backends file:

Aktuelles Standard-Backend von opsi
Die Dateien dieses Backends liegen unter /var/lib/opsi/config.
Ist implementiert in der Annahme, dass der FQDN des Servers auf welchem das Backend verwendet wird dem FQDN des Konfigurations-Server in opsi entspricht.

Inhalt und Aufbau dieser Dateien ist im Kapitel Datenhaltung von opsi näher erläutert.

mysql-Backend

mysql-Backend für Inventarisierungsdaten (Übersicht und Datenstruktur)

Die Daten der Hardware- und Softwareinventarisierung werden standardmäßig ü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:

Optional (nicht das Standard-Backend)
Für Inventarisierungsdaten kostenfrei, für die Nutzung für sonstige Daten benötigen Sie eine kostenpflichtige Freischaltung.
Fein granulierte Datenstruktur zur Datenhaltung und zusätzlich vereinfachtes Datenmodell für Abfragen.
Eine Historyfunktion, welche Änderungen an den Inventarisierungsdaten protokolliert.

Bedingt durch die sehr unterschiedliche Natur der zu inventarisierenden Hardwarekomponenten ist die Datenstruktur in etwa wie folgt aufgebaut:

Eine Tabelle HOST beschreibt alle bekannten Clients und stellt eine eindeutige host_id bereit.
Für jeden Device-Typ gibt es zwei Tabellen:
- 'HARDWARE_DEVICE…' beschreibt das Device z.B. Netzwerkkartentyp mit PCI-Kennung
- 'HARDWARE_CONFIG…' beschreibt Konfiguration der konkreten Netzwerkkarte z.B. MAC-Adresse. Die beiden Tabellen sind über das Feld hardware_id miteinander verbunden.

Ä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 AS d
LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE AS h
ON
  d.hardware_id = h.hardware_id ;

Die Softwareinventarisierung verwendet als Hauptschlüssel die folgenden Felder:

Name
Dieser ist der windowsDisplayName bzw. wenn dieser nicht vorhanden ist die windowsSoftwareId. Beide werden aus der Registry ermittelt:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall bzw.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<id> DisplayName
Version
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<id> DisplayVersion
SubVersion
Language
Architecture (32 Bit / 64 Bit)

In der Tabelle Software_config sind diese Felder zum Feld config_id zusammengefasst.

Abbildung 1. Datenbankschema: Softwareinventarisierung

mysql-Backend für Konfigurationsdaten (Übersicht)

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 Freischaltung kostenpflichtiger Module.

Das MySQL-Backend hat den Vorteil der höheren Performanz insbesondere bei großen Installationen.

Hier eine Übersicht über die Datenstruktur:

Abbildung 2. Datenbankschema: Konfigurationsdaten

Initialisierung des MySQL-Backends

Wenn der MySQL-server noch nicht installiert ist, muss dies zunächst erfolgen mit:

apt install mysql-server

Danach muss für den MySQL-Benutzer root 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:

Abbildung 3. opsi-setup --configure-mysql: Eingabemaske

Abbildung 4. opsi-setup --configure-mysql: Ausgabe

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 vorgenommen wird.

Manualle Konfiguration

Eine 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.

Konfigurieren der MySQL-Datenbank zum Zugriff von außen

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.

HostControl-Backend

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:
Netzwerk-Port für die Verbindungsaufnahme zu einem opsi-client-agent.
hostRpcTimeout:
Timeout (in Sekunden) bei der Verbindungsaufnahme zu einem opsi-client-agent.
resolveHostAddress:
Steht diese Option auf 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:
Maximale Anzahl simultaner Verbindungen zu opsi-client-agents.
broadcastAddresses:
Zuordnung von Netzwerk-Adressen zu Broadcast-Adressen in der Form:
{ "<network-address>": { "<broadcast-address>": <port-list> } }
Einer Netzwerk-Adresse können mehrere Broadcast-Adressen zugeordnet werden. Für jede Broadcast-Adresse können unterschiedliche Ports konfiguriert werden. Die passenden Broadcast-Adressen werden auf Basis der, im opsi-Backend hinterlegten, IP-Adresse eines Clients ermittelt. Ist die IP-Adresse hierbei Teil mehrerer Netzwerke, wird der spezifischste Eintrag verwendet.
Beispiel:

"broadcastAddresses": {
		"0.0.0.0/0": {
			"255.255.255.255": [7, 9, 12287]
		},
		"10.10.0.0/16": {
			"10.10.1.255": [12287],
			"10.10.2.255": [12287]
		},
		"10.10.3.0/24": {
			"10.10.3.255": [12287]
		},
		"192.168.1.0/24": {
			"192.168.1.255": [12287, 9, 12287]
		}
	}

HostControlSafe-Backend

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 herunterfahren bzw. neu Starten.

Deshalb gibt es mit Service Release opsi 4.0.3 an dieser Stelle zwei Änderungen:

Die Methoden: 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:
```
Hierbei wird die  Netzwerkadressen mit kleineren
```

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.

Konvertierung zwischen Backends

Der Befehl opsi-convert dient zum Konvertieren der opsi-Konfigurationsdaten zwischen verschiedenen Backends. Das Ziel und die Quelle können auf verschieden Arten bestimmt werden:

Backendnamen:
Durch Angabe des Namens wird ein entsprechendes Backend auf dem aktuellen Server angegeben. So konvertiert opsi-convert file mysql auf dem aktuellen Server vom File-Backend zum MySQL-Backend.
Service-Adresse
Durch Angaben von Serviceadressen kann ein Server z.B. auch Remote angesprochen werden. Die Service Adresse hat die Form https://<username>@<ipadresse>:4447/rpc. Nach den Passwörtern wird gefragt.
Beispiel:

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

Bootdateien

Unter /tftpboot/linux finden sich die Bootdateien, die im Zusammenspiel mit den PXE-Boot benötigt werden.

Absicherung der Shares über verschlüsselte Passwörter

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-Hostschlü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.