3.7. Domänenreplikation mit Listener und Notifier#

Der Univention Directory Listener- und Notifier-Mechanismus repliziert Verzeichnisdaten innerhalb einer Nubus für UCS-Domäne und besteht aus zwei Diensten.

  • Der Univention Directory Listener-Dienst wird auf allen UCS-Systemen ausgeführt.

  • Auf dem Primary Directory Node und auf vorhandenen Backup Directory Node-Systemen überwacht der Univention Directory Notifier-Dienst Änderungen im LDAP-Verzeichnis und verteilt diese Änderungen an die Univention Directory Listener-Dienste auf den anderen Nubus für UCS-Systemen.

Wie Abb. 3.4 zeigt, verbinden sich die aktiven Univention Directory Listener-Instanzen in der Domäne mit einem Univention Directory Notifier-Dienst. Alle anderen LDAP-Server in der Domäne sind schreibgeschützte Replicas. Wenn eine LDAP-Änderung auf dem Primary Directory Node auftritt, registriert der Univention Directory Notifier die Änderung und benachrichtigt die Listener-Instanzen.

Diagramm, das zeigt, wie Univention Directory Listener-Instanzen eine Verbindung zu einem Univention Directory Notifier-Dienst auf dem Primary Directory Node herstellen, der LDAP-Änderungen überwacht und an Listener-Instanzen auf anderen UCS-Systemen verteilt.

Abb. 3.4 Listener- und Notifier-Mechanismus#

3.7.1. Listener-Module#

Jede Listener-Instanz verwendet mehrere Listener-Module. Installierte Anwendungen stellen diese Module bereit. Das Druckserver-Paket enthält beispielsweise Listener-Module, die die CUPS-Konfiguration erzeugen.

Listener-Module übermitteln Änderungen in der Domäne an Dienste, die nicht mit LDAP kompatibel sind. Der Druckserver CUPS veranschaulicht dies: CUPS liest Druckerdefinitionen aus /etc/cups/printers.conf, nicht aus LDAP. Wenn Sie einen Drucker im Verwaltungsmodul Drucker speichern, legt Nubus für UCS ihn im LDAP-Verzeichnis ab. Das Univention Directory Listener-Modul cups-printers erkennt diese Änderung und fügt den entsprechenden Eintrag in /etc/cups/printers.conf hinzu, ändert oder löscht ihn basierend auf den Daten in LDAP.

Weitere Informationen zum Einrichten und Entwickeln von Listener-Modulen finden Sie unter Univention Developer Reference [6].

3.7.2. Transaktionsbasierte Replikation#

Eines der integrierten Listener-Module führt auch die LDAP-Replikation durch. Wenn der Ziel-LDAP-Server nicht erreichbar ist, speichert das System die LDAP-Änderungen vorübergehend in /var/lib/univention-directory-replication/failed.ldif. Das System überträgt den Dateiinhalt automatisch in LDAP, wenn der LDAP-Server wieder verfügbar ist.

Der Listener- und Notifier-Mechanismus ist transaktionsbasiert. Der Primary Directory Node erhöht die Transaktions-ID bei jeder LDAP-Änderung. Eine Listener-Instanz, die mehrere Transaktionen verpasst hat, beispielsweise weil Sie sie ausgeschaltet haben, fordert die fehlenden Transaktionen nach dem Wiederherstellen der Verbindung automatisch an, bis ihre lokale Transaktions-ID mit der des Primary Directory Node übereinstimmt.

3.7.3. Fehlerbehebung bei Listener und Notifier#

Wenn die Replikation nicht wie erwartet funktioniert, stellen die Listener- und Notifier-Dienste Diagnoseinformationen über Log-Dateien und Transaktions-IDs bereit. Die folgenden Abschnitte führen Sie durch die Auswertung dieser Daten und die Behebung häufiger Probleme.

3.7.3.1. Log-Dateien lesen und Debug-Level festlegen#

Der Listener und alle Listener-Module schreiben Statusmeldungen in /var/log/univention/listener.log. Den Detailgrad der Protokollierung legen Sie mit der UCR variable listener/debug/level fest.

Der Notifier-Dienst schreibt Statusmeldungen in /var/log/univention/notifier.log. Den Debug-Level legen Sie mit notifier/debug/level fest.

3.7.3.2. Probleme bei der Replikation identifizieren#

Bei normaler Last und ohne Netzwerkprobleme erfolgt die Replikation von den Verwaltungsmodulen zu einem Replica Directory Node nahezu sofort. Um zu überprüfen, ob die Replikation abgeschlossen ist, vergleichen Sie die Transaktions-IDs der Listener- und Notifier-Dienste.

  • Auf dem Primary Directory Node schreibt der Notifier alle Transaktionen in der Reihenfolge in /var/lib/univention-ldap/notify/transaction, wie in Listing 3.7 gezeigt.

    Listing 3.7 Letzte Notifier-Transaktion auf dem Primary Directory Node prüfen#
    root@primary:~# tail -1 /var/lib/univention-ldap/notify/transaction
    836 cn=replica3,cn=dc,cn=computers,dc=firma,dc=de m
    
  • Der Listener speichert die zuletzt empfangene Transaktions-ID in /var/lib/univention-directory-listener/notifier_id, wie in Listing 3.8 gezeigt.

    Listing 3.8 Letzte vom Listener empfangene Transaktions-ID prüfen#
    root@replica1:~# cat /var/lib/univention-directory-listener/notifier_id
    836
    

Der Nagios-Dienst UNIVENTION_REPLICATION kann diese Prüfung auch automatisch durchführen, siehe Vorkonfigurierte Nagios-Prüfungen in UCS Handbuch [3].

3.7.3.3. Listener-Module neu initialisieren#

Wenn ein Listener-Modul Probleme hat, können Sie es neu initialisieren. Die Neuinitialisierung bewirkt, dass das Listener-Modul alle LDAP-Objekte, mit denen es arbeitet, erneut verarbeitet. Übergeben Sie den Namen des Listener-Moduls als Argument an den Befehl zur Neuinitialisierung. Die installierten Listener-Module befinden sich in /var/lib/univention-directory-listener/handlers/.

Um beispielsweise das cups-printers Modul neu zu initialisieren, führen Sie den Befehl in Listing 3.9 aus.

Listing 3.9 Das cups-printers Listener-Modul neu initialisieren#
$ univention-directory-listener-ctrl resync cups-printers

Warnung

Die Neuinitialisierung entfernt den internen Zustand des Listener-Moduls und kann nicht rückgängig gemacht werden. Sichern Sie den Zustand des Listeners vor der Neuinitialisierung, wenn Sie ihn erhalten möchten.