Zusammenarbeit mit Verzeichnisdienst

Die Erweiterung opsi-directory-connector überträgt Daten aus einem LDAP-fähigen Verzeichnisdienst in eine opsi-Installation. Damit ist es nicht mehr nötig, Daten auf mehreren Systemen zu pflegen — die automatische Synchronisation verringert den Administrationsaufwand. Da der Directory Connector im Hintergrund auf LDAP setzt, funktioniert er sowohl mit Active Directory als auch mit Samba 4.

Voraussetzungen

Dieses Modul ist momentan eine kostenpflichtige Erweiterung. Das heißt, dass Sie eine Freischaltdatei benötigen. Sie erhalten diese, nachdem Sie die Erweiterung gekauft haben. Zu Evaluierungszwecken stellen wir Ihnen kostenlos eine zeitlich befristete Freischaltung zur Verfügung. Bitte kontaktieren Sie uns dazu per E-Mail.

Allgemeine Anforderungen

  • Der Verzeichnisdienst auf dem Rechner, der als Quelle dient, muss das LDAP-Protokoll implementieren.

  • Auf dem Zielsystem muss mindestens opsi 4.0.7 installiert sein. Ältere Versionen funktionieren eventuell; das haben wir aber nicht getestet.

  • Der Rechner, auf dem der Directory Connector laufen soll, muss Netzwerkzugriff auf den Rechner mit dem Verzeichnisdienst und auf den opsi-Server haben.

Es ist möglich, alle Komponenten auf demselben Rechner zu betreiben. Wir gehen im Folgenden aber davon aus, dass es sich um mehrere Maschinen handelt.

Hardware-Anforderungen

Für eine kleine Umgebung mit bis zu 500 opsi-Clients benötigen Sie:

  • 256 MByte freien Arbeitsspeicher

  • Netzwerkverbindungen

In großen Umgebungen sind 256 MByte RAM möglicherweise nicht ausreichend. Passen Sie die Ausstattung der Rechner gegebenenfalls an.

Software-Anforderungen

Den Directory Connector können Sie nur unter Linux installieren und betreiben. Eine Unterstützung für Windows-Systeme ist nicht geplant.

Da die Erweiterung Standard-Protokolle zur Kommunikation übers Netzwerk benutzt, benötigen Sie keine zusätzlichen opsi- oder Verzeichnisdienst-spezifischen Komponenten.

Installation

Um den Directory Connector zu installieren, fügen Sie als Erstes das opsi-Repository hinzu (siehe Kapitel opsi-Server, Abschnitte Debian/Ubuntu, openSUSE/SLES und CentOS/RHEL). Installieren Sie danach über den Paketmanager Ihrer Distribution das Paket opsi-directory-connector.

Auf Debian-basierten Systemen rufen Sie dazu beispielsweise dieses Kommando auf:

apt-get install opsi-directory-connector

Konfiguration

Der Directory Connector bietet vielfältige Einstellungsmöglichkeiten, um ihn an ganz unterschiedliche Umgebungen anzupassen. Die Konfigurationsdatei /etc/opsi/opsidirectoryconnector-custom.conf ist im JSON-Format und muss gültiges JSON (Schlüssel-Wert-Paare) enthalten. Für boolesche Werte verwenden Sie true oder false; Text steht in doppelten Anführungszeichen (z. B. "das ist Text").

Unser Paket spielt eine Beispiel-Konfiguration ein. Sie können die Datei /usr/share/opsi-directory-connector/opsi-directory-connector.example.conf als Vorlage für die eigene Konfiguration verwenden: 
cp /usr/share/opsi-directory-connector/opsi-directory-connector.example.conf /etc/opsi/opsidirectoryconnector-custom.conf

Verbindung zum Verzeichnisdienst (directory)

Im Abschnitt directory konfigurieren Sie die Verbindung zum Verzeichnisdienst. Außerdem grenzen Sie hier den Suchbereich auf bestimmte Umgebungen und Objekte ein:

{
    "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": {
            "paged_search_limit": 768
        }
    },
    …
}

Hinter address geben Sie die Adresse des LDAP-Servers an. Wird das Protokoll ldaps oder der Port 636 verwendet, dann findet die Kommunikation SSL-verschlüsselt statt:

        "address": "192.168.12.34:636",

Tragen Sie außerdem den Benutzernamen (user) und das Kennwort (password) für die Authentifizierung am Verzeichnisdienst ein.

Um die Sicherheit zu erhöhen, empfehlen wir die Verwendung eines gesonderten Benutzerkontos.

Anstelle des Passwortes können Sie hinter passwordFile den Pfad zu einer Datei angeben, die das Passwort enthält. Das hat den Vorteil, dass das Passwort nicht im Klartext in der Konfigurationsdatei steht. Ein aus passwordFile ausgelesenes Passwort überschreibt eventuell gesetzte Werte für password.

Das Format des Benutzernamens hängt von der verwendeten Verzeichnisdienst-Software und deren Konfiguration ab:
Down-Level Logon Name: DOMAIN\username
User Principal Name (UPN): user@domain
Distinguished Name (DN): uid=opsiconnect,cn=users,dc=test,dc=intranet

Hinter search_base geben Sie an, ab welchem Punkt nach passenden Elementen gesucht wird. Hinter search_query_computers konfigurieren Sie für die Suche nach Clients verwendete Filter.

Der optionale Schlüssel identifying_attribute legt ab Version 23 fest, welche Attribute Clients eindeutig identifizieren. Die Standardeinstellung ist dn. Eine oft genutzte Alternative ist distinguishedName, die vor allem im Microsoft-Verzeichnisdienst Active Directory zum Einsatz kommt.

Der Schlüssel connection_options definiert zusätzliche Optionen für die Verbindung. Hier bestimmen Sie beispielsweise über verify, ob bei einer SSL-Verbindung das Zertifikat überprüft werden soll oder nicht. Zusätzlich können Sie den Pfad zu einer Certificate Authority (CA) angeben; notieren Sie hier den Namen der Datei, die Sie zur Verifizierung verwenden wollen. Wenn die Verbindung über den unverschlüsselten Port 389 gestartet wird, dann steuert start_tls, ob nach der Anmeldung eine gesicherte Verbindung gestartet wird. In der Voreinstellung ist start_tls für den Port 389 aktiviert, aber eine Zertifikat-Prüfung findet nicht statt.

Sollen während des Auslesens der Elemente aus dem Verzeichnis mehrere Abfragen stattfinden, dann definieren Sie die Anzahl hinter dem optionalen Schlüssel paged_search_limit. Der Wert muss eine Ganzzahl sein. Das Feature wird seit Version 20 unterstützt.

Ihnen fehlt eine Verbindungs-Option? Falls möglich, implementieren wir weitere Features. Kontaktieren Sie uns dazu gerne per E-Mail.
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.

Verbindung zu Univention Corporate Server

Für eine Verbindung zu Univention Corporate Server (UCS) geben Sie als Benutzernamen den Distinguished Name (DN) an. Dieser hat die folgende 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 Domänen-Controller eingerichtet, so lauscht dieser auf den Ports 389 (ungesichert) bzw. 636 (SSL-gesichert). Für die Verwendung der SSL-gesicherten Ports setzen Sie die Verbindungseinstellung start_tls auf true.

Die beiden möglichen Verbindungen unterscheiden sich auch, was die Anmeldung betrifft:

  • LDAP: uid=…

  • Samba: dn=…

In der Regel findet im Container computers eine Suche nach Rechner-Objekten statt. Der folgende Befehl gibt den dazu passenden Wert für search_base aus:

echo "cn=computers,$(ucr get ldap/base)"

Um nach Windows-Clients zu suchen, geben Sie (objectClass=univentionWindows) als Wert für search_query_computers an.

Lesen Sie auch den Artikel Cool Solution - LDAP search user / simple authentication account in der Univention Knowledge Base, der erklärt, wie Sie einen Benutzer mit nur lesendem Zugriff anlegen.

Verhaltens-Einstellungen (behaviour)

Diese Einstellungen steuern das Verhalten des Directory Connector:

{
    …
    "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,
        "delete_empty_groups": false,
        "skip_adding_clients": false,

    },
    …
}

Wenn Sie write_changes_to_opsi auf false setzen, werden keine Daten nach opsi geschrieben. Das ist beispielsweise dann sinnvoll, wenn Sie die Verbindungseinstellungen überprüfen möchten.

root_dir_in_opsi gibt an, welche Gruppe in opsi als Wurzelgruppe verwendet werden soll. Stellen Sie sicher, dass diese Gruppe existiert.

Die Management-Oberfläche opsi-configed zeigt die Gruppe clientdirectory als DIRECTORY an. Wenn Clients oder Gruppen also direkt unterhalb von DIRECTORY erscheinen sollen, tragen Sie clientdirectory als Wert für root_dir_in_opsi ein.

Wenn Sie update_existing_clients auf false setzen, dann werden bereits in opsi existierende Clients nicht verändert. Steht dieser Wert hingegen auf true, so werden möglicherweise manuell gesetzte Daten mit den Werten aus dem Verzeichnisdienst überschrieben.

Falls prefer_location_from_directory auf true gesetzt ist, werden Clients in opsi an die Position verschoben, die sie auch im Verzeichnisdienst haben. Setzen Sie den Wert auf false, um das Verhalten zu deaktivieren.

Die Gruppenbehandlung steuert seit Version 31 der optionale Schlüssel group_handling. Die Voreinstellung ist dn. Dabei werden Gruppen aus dem DN (Distinguished Name) eines Computers abgeleitet und entsprechend als Teil des opsi-Verzeichnisdienstes angelegt. Ein Client ist dabei nur Mitglied einer Gruppe.

Wenn Sie delete_empty_groups aktivieren, dann werden Gruppen, die nach dem Synchronisieren leer sind, auch aus dem opsi-Verzeichnisdienst gelöscht. Es werden dann nur Gruppen unterhalb von root_dir_in_opsi berücksichtigt.

Mit skip_adding_clients überspringen Sie das Anlegen von Clients in opsi komplett. Diese Option können Sie z. B. in Verbindung mit prefer_location_from_directory verwenden, sodass nur bestehende Clients verschoben werden.

Einstellungen für UCS@school

Setzen Sie den Schlüssel group_handling auf ucsatschool, um das Verhalten für UCS@school-Umgebungen anzupassen. Der Directory Connector sucht dann automatisch nach Schulen und ermittelt für diese die Räume. Anschließend erfolgt die Synchronisation mit opsi.

Für jede ermittelte Schule wird in opsi eine Gruppe angelegt. Bei den UCS@school-Gruppen kann ein Rechner aber in mehr als einem Raum zu finden sein. Daher legt der Directory Connector die Gruppen nicht als Gruppe im opsi-Verzeichnisdienst an, sondern als normale Gruppe. Auf diese Weise kann ein Client auch in opsi in mehreren Gruppen sein.

Wenn die UCS@school-Gruppen doch im opsi-Verzeichnisdienst angelegt werden sollen, setzen Sie den Schlüssel override_root_dir auf false. Der Schlüssel override_root_dir steht nur bei "group_handling": "ucsatschool" zur Verfügung. Der Standardwert ist true. Steht override_root_dir auf false, dann stellen Sie sicher, dass jeder Schulrechner nur einem Raum zugewiesen wird.

Über group_description passen Sie die Beschreibung der opsi-Gruppen an werden. Folgende Werte sind möglich:

  • dn: Der Distinguished Name der Gruppe wird in opsi als Gruppenbeschreibung hinterlegt.

  • directory: Die Gruppenbeschreibung wird aus dem Feld description der Verzeichnisdienst-Gruppe gelesen.

  • Ist der Wert nicht oder anders gesetzt, wird als Beschreibung der Name der Gruppe eingetragen.

…
 "behaviour": {
        "group_handling": "ucsatschool",
        …
        "group_not_in_directory": true,
        "opsi_clients_to_ignore": {
            "clients": ["win1.uib.local","win2.uib.local","win3.uib.local"],
            "groups": ["server"]
        }
 }
…

Steht group_not_in_directory auf true, dann werden alle Clients, die nicht im Verzeichnisdienst sind, der Gruppe not_in_directory hinzugefügt. Diese Option steht nur bei der Einstellung "group_handling": "uscatschool" zur Verfügung. Mit dem Parameter opsi_clients_to_ignore können Sie Clients oder ganze Gruppen von dieser Regel ausschließen.

Eine kurze Beschreibung aller Einstellungsmöglichkeiten finden Sie auch in der Beispielkonfiguration (/usr/share/opsi-directory-connector).

Attribute übernehmen (mapping)

Da ein Verzeichnisdienst ein äußerst flexibles System ist, benötigt der Directory Connector genaue Informationen über die Attribute und welche davon auf die Attribute in opsi selbst anzuwenden sind. Aus diesem Grund gibt es ein Mapping für Client-Attribute.

{
    …
    "mapping": {
        "client": {
            "id": "name",
            "description": "description",
            "notes": "",
            "hardwareAddress": "",
            "ipAddress": "",
            "inventoryNumber": "",
            "oneTimePassword": ""
        }
    },
    …
}

Der Schlüssel ist jeweils das Attribut in opsi, und der Wert ist das Attribut aus dem Verzeichnisdienst. Ist der Wert leer, so findet keine Zuordnung statt.

Sollte der aus dem Verzeichnis ausgelesene Wert für die Client-ID nicht als FQDN erkennbar sein, so wird ein entsprechender FQDN erstellt. Dabei wird der Domain-Teil 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.

Clients und Depots zuordnen

Im Bereich mapping können Sie außerdem die Zuordnung von Clients zu Depots definieren. Aktuell gibt es nur den Mapping-Typ network.

Ein Client wird einem Depot zugeordnet, wenn die IP-Adresse des Clients im Netzwerk (networkAddress) des Depots liegt.

Alternativ können Sie einem Depot auch eine Liste von Netzwerkbereichen zuordnen: 
{
    …
    "mapping": {
        …
        "depot": {
            "type": "network",
            "test-depot1.test.local": ["192.168.24.0/24","192.168.25.0/24"],
            "test-depot1.test.local": ["192.168.27.0/24","192.168.28.0/24"]
        }
    },
    …
}

Gruppennamen manuell zuordnen

Gruppennamen werden in der Regel ohne Anpassungen übernommen. Allerdings kann es dabei vorkommen, dass Gruppennamen verwendet werden sollen, die in opsi ungültig sind. In dem Fall können Sie Gruppennamen manuell zuordnen. Möglich ist dies ab Version 23.

Dazu definieren Sie im Abschnitt mapping einen Unterabschnitt group_name. Hier ordnen Sie nun die Namen aus dem Verzeichnisdienst den Namen der opsi-Umgebung zu. Die Gruppennamen notieren Sie stets in Kleinbuchstaben. Das folgende Beispiel weist der Gruppe _server aus dem Verzeichnisdienst die opsi-Gruppe server zu:

{
    …
    "mapping": {
        "client": {
            …
        },
        "group_name": {
            "_server": "server"
        }
    },
    …
}
Bei unbedachtem Einsatz kann die manuelle Zuordnung unerwünschte Seiteneffekte haben. Setzen Sie diese Zuordnungsmöglichkeit daher nur in Ausnahmefällen ein!

Verbindung zu opsi (opsi)

Im Abschnitt opsi definieren Sie, wie sich der Directory Connector zu opsi verbindet.

{
    …
    "opsi": {
        "address": "https://localhost:4447",
        "username": "syncuser",
        "password": "secret",
        "exit_on_error": false,
        "passwordFile": "",
        "connection_options": {
            "verify_certificate": true
        }
    }
}

Hinter address steht die opsi-Server-Adresse — vergessen Sie nicht die Angabe des Ports!

Läuft die Verbindung über einen Proxyserver, dann definieren Sie diesen über die Umgebungsvariable HTTPS_PROXY.

Die beiden Schlüssel username und password enthalten die Zugangsdaten zur Authentifizierung am opsi-Server. Anstelle des Passwortes können Sie hinter passwordFile den Pfad zu einer Datei angeben, die das Passwort enthält. Das hat den Vorteil, dass das Passwort nicht im Klartext in der Konfigurationsdatei steht. Ein aus passwordFile ausgelesenes Passwort überschreibt eventuell gesetzte Werte für password.

Um die Sicherheit zu erhöhen, empfehlen wir die Verwendung eines gesonderten Benutzerkontos.

Enthält der Schlüssel exit_on_error den Wert true, dann führen Probleme bei der Aktualisierung der Daten in opsi zum Verbindungsabbruch. Das passiert beispielsweise beim Übermitteln ungültiger Werte für opsi. Steht hier hingegen false, so werden Fehler protokolliert, die Verbindung bleibt aber bestehen.

Unter connection_options legen Sie Optionen für die Verbindung zum opsi-Server fest. Dabei steuert verify_certificate die Überprüfung des Server-Zertifikats. Setzen Sie selbstsignierte Zertifikate ein, dann können Sie den Wert auf false setzen, um die Verifizierung zu unterbinden.

Seit Version 14 ist es über den Aufrufparameter --check-directory möglich, die Verbindung zum opsi-Server zu testen, ohne dass eine Verbindung zum Verzeichnisdienst hergestellt wird.

Den Directory Connector ausführen

Das Installationspaket enthält die ausführbare Datei opsi-directory-connector. Sie erwartet hinter dem Schalter --config den Pfad zur Konfigurationsdatei:

opsi-directory-connector --config /etc/opsi/opsidirectoryconnector-custom.conf
Der ausführende Benutzer benötigt keinen Zugriff auf das opsi-System, da die Zugangsdaten in der Konfigurationsdatei hinterlegt sind.

Der Directory Connector synchronisiert bei jedem Lauf die Daten. Um einen regelmäßigen Abgleich einzurichten, können Sie entweder systemd verwenden oder einen Cronjob erstellen. Die nächsten beiden Abschnitte zeigen die Einrichtung.

Wiederkehrende Verarbeitung: systemd-Units einrichten

Wir empfehlen die Einrichtung von systemd-Units, da systemd im Gegensatz zu Cronjobs überlappende Läufe verhindert. Das hier gezeigte Beispiel führt den Directory Connector fünf Minuten nach dem Start eines Rechners aus. Danach läuft er regelmäßig jede Stunde.

Dazu richten Sie zwei benutzerdefinierte systemd-Units im Verzeichnis /etc/systemd/system/ ein, eine Timer-Unit und eine Service-Unit.

Timer-Unit

Die Timer-Unit definiert die wiederkehrende Ausführung des Jobs; die Datei /etc/systemd/system/opsi-directory-connector.timer hat den folgenden Inhalt:

[Unit]
Description=Start the opsi-directory-connector in regular intervals

[Timer]
OnBootSec=5min
OnUnitActiveSec=1hour

[Install]
WantedBy=timers.target

Service-Unit

Der Job selbst ist in der Datei /etc/systemd/system/opsi-directory-connector.service definiert:

[Unit]
Description=Sync clients from AD to opsi
Wants=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/opsi-directory-connector --config /etc/opsi/opsi-directory-connector-custom.conf

Timer-Unit aktivieren

Um den Timer zu aktivieren und ihn sofort zu starten, geben Sie die folgenden zwei Befehle ein:

systemctl enable opsi-directory-connector.timer
systemctl start opsi-directory-connector.timer

Andernfalls läuft der Timer das erste Mal nach dem nächsten Neustart der Maschine.

Wiederkehrende Verarbeitung: Cronjob einrichten

Alternativ zu den beiden systemd-Units können Sie den regelmäßigen Abgleich mit dem Directory Connector über einen Cronjob automatisieren.

Wählen Sie das Synchronisations-Intervall so, dass keine überlappenden Läufe stattfinden können. Alternativ verwenden Sie systemd, wie im vorigen Abschnitt gezeigt.

Rufen Sie den Befehl crontab -e auf, um eine neue Crontab zu erstellen oder eine vorhandene zu bearbeiten. In der Crontab stehen Informationen zum ausführbaren Programm. Außerdem definieren Sie hier, wann und wie oft ein Cronjob laufen soll. In unserem Beispiel fügen wir die folgende Zeile hinzu:

0 * * * * /usr/bin/opsi-directory-connector --config /etc/opsi/opsi-directory-connector-custom.conf

In diesem Fall findet die Synchronisation immer zur vollen Stunde statt. Das erste Feld definiert dazu Minute 0; alle anderen Felder (Stunde, Tag, Monat und Wochentag) enthalten * als Platzhalter.

Kommandozeilenparameter

Der Directory Connector kennt die folgenden Parameter und Optionen:

Usage: __main__.py [-h] [--version] [--log-level {0,1,2,3,4,5,6,7,8,9}]
                   [--log-level-stderr {0,1,2,3,4,5,6,7,8,9}]
                   [--log-level-file {0,1,2,3,4,5,6,7,8,9}]
                   [--log-file LOG_FILE]
                   [--max-log-size MAX_LOG_SIZE]
                   [--keep-rotated-logs KEEP_ROTATED_LOGS]
                   [--check-directory | --check-opsi | --delete-clients DELETE_CLIENTS [DELETE_CLIENTS …]]
                   [--dry-run] --config
                   CONFIG

If an arg is specified in more than one place, then commandline values override environment
variables which override defaults.

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}
                              Sets how much information will be logged. [env var: OPDC_LOG_LEVEL]
                              (default: 4)
  --log-level-stderr {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. [env var:
                              ODC_LOG_LEVEL_STDERR] (default: 4)
  --log-level-file {0,1,2,3,4,5,6,7,8,9}
                              Sets how much information will be logged to the log file. [env var:
                              ODC_LOG_LEVEL_FILE] (default: 5)
  --log-file LOG_FILE
                              Sets log file path. [env var: ODC_LOG_FILE] (default:
                              /var/log/opsi/directory-connector.log)
  --max-log-size MAX_LOG_SIZE
                              Limit the size of logfiles to SIZE megabytes.Setting this to 0 will
                              disable any limiting. [env var: ODC_MAX_LOG_SIZE] (default: 5.0)
  --keep-rotated-logs KEEP_ROTATED_LOGS
                              Number of rotated log files to keep. [env var: ODC_KEEP_ROTATED_LOGS]
                              (default: 1)
  --check-directory
                              Check if a connection to the directory can be established and if items
                              will be received. (default: False)
  --check-opsi
                              Check if a connection to the opsi server can be established. (default:
                              False)
  --delete-clients DELETE_CLIENTS [DELETE_CLIENTS …]
                              Delete list of clients from directory. (default: None)
  --dry-run
                              Print what would be done. (default: False)
  --config CONFIG
                              Path to the config. (default: None)

Ab Version 39 benutzt der Directory Connector den opsi-Logger (Loglevel 0 bis 9). In der Voreinstellung protokolliert die Anwendung nach /var/log/opsi-directory-connector bzw. schreibt Fehler nach stderr. Um den Loglevel für die beiden Protokolle zu beeinflussen, verwenden Sie die Parameter --log-level-stderr bzw. --log-level-file. Der Schalter --log-file definiert ein anderes Logfile.

In der Voreinstellung wird das Logfile rotiert, wenn es 5 MByte groß ist, und jeweils eines der rotierten Protokolle wird aufgehoben. Die beiden Schalter --max-log-size und --keep-rotated-logs überschreiben diese Standardwerte.

Zusätzlich zu den Kommandozeilenparametern können Sie einige der Werte auch als Schlüssel in der Konfigurationsdatei oder über Umgebungsvariablen setzen. Dabei gilt die folgende Reihenfolge:

  • Parameter überschreiben alles.

  • Umgebungsvariablen überschreiben die Konfigurationsdatei und die Standardwerte.

  • Die Konfigurationsdatei überschreibt die Standardwerte.

Beispielkonfiguration:

{
…
    "log-level-stderr": 6,
    "log-level-file": 3,
    "keep-rotated-logs": 4
…
}

Testlauf (--dry-run)

Sie können opsi-directory-connector mit dem Parameter --dry-run starten, um einen Testlauf zu starten. Dabei sehen Sie in der Ausgabe die einzelnen Schritte; Änderungen in opsi werden dabei nicht durchgeführt:

---------- opsi actions ----------
Creating client client1.opsidc.intranet.
Creating client ds-win-client-2.opsidc.intranet.
Creating client ds-win-client-1.opsidc.intranet.
Creating client mac-client-1.opsidc.intranet.
Creating client windows-client-1.opsidc.intranet.
Creating client raspberrypi-1.opsidc.intranet.
Adding mac-client-1.opsidc.intranet to opsitestschool-mac pool.
Adding windows-client-1.opsidc.intranet to opsitestschool-pc pool og1.
Adding ds-win-client-2.opsidc.intranet to depotschule-pool-1.
Adding ds-win-client-1.opsidc.intranet to depotschule-pool-1.
----------------------------------
---------- summary ---------------
Create  6 clients and 0 groups.
0 clients removed from group.
Adding 4 clients to a new group.
----------------------------------

Anders als bei der Einstellung "write_changes_to_opsi": false, die keine Daten nach opsi schreibt, passt der Schalter --dry-run die Ausgabe an. Das gibt eine bessere Übersicht über die Aktionen.

Clients aus dem Verzeichnis löschen

In der Voreinstellung greift der Directory Connector nur lesend auf das Verzeichnis zu. Wenn Sie das Programm mit dem Parameter --delete-clients aufrufen, startet ein unabhängiger Lauf, der versucht, die übergebenen Objekte aus dem Verzeichnis zu löschen:

opsi-directory-connector --config config.conf --delete-clients client1

In diesem Fall sucht der Directory Connector im definierten Suchbereich nach Objekten mit cn=client1. Gibt es einen einzigen Treffer, dann wird das Objekt gelöscht. Findet das Programm allerdings mehrere passende Objekte, dann gibt es einen Fehler aus und löscht nichts.

Die zu löschenden Objekte können Sie noch genauer angeben:

opsi-directory-connector --config config.conf --delete-clients computers/test-clients/client1

Das Objekt cn=client1,ou=test-clients,ou=computers,dc=example,dc=org wäre ein Treffer und würde gelöscht, cn=client1,ou=clients,ou=computers,dc=example,dc=org allerdings nicht.

Sie können auch mehrere Clients angeben:

opsi-directory-connector --config config.conf --delete-clients computers/clients/client1 client2 client3
Verwenden Sie den Parameter --delete-clients stets mit Vorsicht! Zur Sicherheit können Sie den Schalter mit --dry-run kombinieren und vorher prüfen, ob die richtigen Objekte gefunden werden.