389ds-Replikation

Konfigurieren Sie die Replikation zwischen 389DS-Server (LDAP-Server) Instanzen.

ansible-galaxy install lvps.389ds_replication

Anforderungen

• Ansible-Version: 2.7 oder höher
• Betriebssystem: CentOS 7

Wenn Ansible das ldap_attrs Modul nicht unterstützt, verwenden Sie eine ältere Version der Collections, aber Sie können Version 1.0.x dieser Rolle ausprobieren.

Rollenvariablen

Variable	Standard	Beschreibung	Kann geändert werden	Rolle
dirsv_replication_role		Rolle dieses Servers: 'supplier' (Lieferant), 'consumer' ( Verbraucher) oder 'both' (beides, Master). Hub wird nicht unterstützt.	Nein
dirsrv_server_uri	"ldap://localhost"	URI des Servers, den Sie konfigurieren möchten. Da dies auf dem Ansible-Ziel ausgeführt wird, sollte localhost in Ordnung sein. Es ist möglich, dies auf ldaps://localhost zu setzen, um TLS auf Port 636 zu verwenden.		CSB
dirsrv_rootdn	"cn=Directory Manager"	Root DN (Benutzername des Administratorkontos)		CSB
dirsrv_rootdn_password	secret	Passwort für das Root DN Konto		CSB
dirsrv_use_starttls	true	Verwenden Sie StartTLS, um eine Verbindung zum Server herzustellen		CSB
dirsrv_tls_certificate_trusted	true	Wahr, wenn das TLS-Zertifikat von einer vertrauenswürdigen CA stammt, falsch, wenn es selbstsigniert oder von einer privaten CA stammt, ungenutzt, wenn TLS nicht verwendet wird		CSB
dirsrv_serverid	default	Server-ID auch bekannt als Instanz-ID, z.B. wenn der Server im Verzeichnis dirsrv/slapd-example installiert ist, ist "example" die Server-ID		CSB
dirsrv_suffix	dc=example,dc=local	Wurzel-Suffix		CSB
dirsrv_supplier_replica_id	1	Wählen Sie eine Zahl zwischen 1 und 65534. Weisen Sie es nicht anderen Servern zu, da sonst unerwartete Probleme auftreten können.	Nein	SB
dirsrv_consumer_uri	"ldap://consumer.example.com:389/"	Vollständige URI, einschließlich Port, zu dem der Lieferant eine Verbindung herstellt und die Replikation durch das Pushen von Änderungen durchführt	Nein	SB
dirsrv_replication_user_remote	Replikationsmanager	Benutzerkonto, das auf dem Verbraucher existiert. Der Lieferant wird sich mit diesem Konto verbinden, um die Replikation durchzuführen. "Replikationsmanager" bedeutet, dass das Konto "cn=Replication Manager,cn=config" ist.	Ja	SB
dirsrv_replication_user_password_remote		Passwort für das Replikationsbenutzerkonto (Replikationsmanager)	Ja	SB
dirsrv_replica_bind_method	"PLAIN"	Bindemethode, die der Lieferant verwendet, um eine Verbindung zum Verbraucher herzustellen (SIMPLE, PLAIN, SASL)	Ja	SB
dirsrv_changelog_max_age	"10d"	Setzt den Wert von nsslapd-changelogmaxage	Ja	SB
dirsrv_replica_attributes_list	"(objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof"	Setzt den Wert von nsds5ReplicatedAttributeList. Der Standardwert dieser Variablen wird in den Beispielen in der Dokumentation verwendet.	Ja	SB
dirsrv_replica_attributes_list_total	"(objectclass=*) $ EXCLUDE accountUnlockTime"	Setzt den Wert von nsds5ReplicatedAttributeListTotal. Der Standardwert dieser Variablen wird in den Beispielen in der Dokumentation verwendet.	Ja	SB
dirsrv_replication_user	Replikationsmanager	Benutzerkonto, das auf dem Verbraucher erstellt werden soll. Dieses Konto wird vom Lieferanten verwendet, um sich auf diesem Server (dem Verbraucher) zu verbinden. "Replikationsmanager" bedeutet, dass das Konto unter "cn=Replication Manager,cn=config" erstellt wird.	Ja	CB
dirsrv_replication_user_password		Passwort für dieses Konto.	Ja	CB
dirsrv_begin_replication_immediately	true	Boolescher Wert, setzt nsds5ReplicaEnabled auf "on" oder "off" im Replikationsvertrag. Dies sollte sicher sein: Wenn Sie einen neuen Server hinzufügen, wird er in jedem Fall nicht mit seiner leeren Datenbank zu anderen Servern anfangen, da diese eine andere Generations-ID haben und die Replikation fehlschlägt (siehe Beispiele für weitere Details). Wenn Sie jedoch noch sicherer sein oder einige Anpassungen am Replikationsvertrag vornehmen möchten, setzen Sie dies auf false.	Nein	CB
dirsrv_consumer_referral_to_supplier	"ldap://supplier.example.com:389/"	Vollständige LDAP-URI einschließlich Port. Wenn ein Client versucht, auf einen Verbraucher zu schreiben, der schreibgeschützt ist, wird der Client auf diesen Server (einen Lieferanten, der Schreibvorgänge akzeptieren kann) umgeleitet.	Ja	C

Wählen Sie zuerst aus, ob der Server ein Lieferant, Verbraucher oder beides ist, und setzen Sie die Variable dirsv_role entsprechend. Anschließend setzen Sie die dazugehörigen Variablen: Sehen Sie in die Rollenspalte, C = Verbraucher, S = Lieferant, B = Beides.

Einige Variablen können nicht geändert werden, sobald sie gesetzt sind; ihre Änderung kann unerwartete Ergebnisse von "es passiert nichts" bis "die Rolle schlägt fehl" zur Folge haben. Andere (Authentifizierungsdetails, Suffix usw.) sollten auf den richtigen Wert für den Server gesetzt werden, können geändert werden, solange dies sinnvoll ist, z.B. können Sie dirsrv_rootdn_password ändern, wenn Sie das Passwort des Root DN geändert haben, damit diese Rolle korrekt authentifizieren kann. Die Änderung von dirsrv_suffix zwischen zwei Läufen auf demselben Server ist jedoch sinnlos, es sei denn, Sie haben es irgendwie geschafft, das Suffix in 389DS zu ändern.

Die folgenden Variablen haben denselben Namen und dieselbe Bedeutung wie in der Rolle 389ds-server, sodass Sie sie, wenn Sie beide Rollen im selben Playbook verwenden, nur einmal definieren können:

• dirsrv_rootdn
• dirsrv_rootdn_password
• dirsrv_tls_certificate_trusted
• dirsrv_serverid
• dirsrv_suffix

Abhängigkeiten

Keine.

Bitte beachten Sie jedoch, dass diese Rolle erwartet, dass 389DS bereits läuft. Sie konfiguriert nur die Replikation zwischen vorhandenen Servern.

Beispiel Playbook

Weitere Beispiele, einschließlich der 389DS-Installation von Grund auf sowie der erforderlichen Vagrant-Konfigurationen, um sie zu testen, sind im Repository 389ds-examples verfügbar.

Beachten Sie, dass die Replikation normalerweise nicht sofort beginnt, weil die "Replikatgeneration" unterschiedlich ist zwischen den Servern. Dies kann mit dem Verfahren zur "Replikataktualisierung" behoben werden, das beispielsweise in Abschnitt 15.2.5 des Administrationshandbuchs beschrieben ist. Sie müssen es bei Lieferanten oder Servern mit der Rolle "beides" durchführen.

Im Grunde wird die Durchführung einer "Replikataktualisierung" die Datenbank zwangsweise von einem Lieferanten auf einen Verbraucher übertragen und die vorherige Verbraucher-Datenbank ersetzen: Beginnen Sie mit einem Lieferanten und bewegen Sie sich schrittweise zu den anderen, wobei Sie darauf achten, keine Produktionsdatenbank mit der leeren Datenbank eines gerade installierten Servers zu ersetzen. Wenn zwei Server dieselbe Datenbank haben, beginnt die Replikation automatisch und sofort.

Das Verfahren wird auch ausführlicher im Repository 389ds-examples erklärt.

Verbraucher und Lieferant

Konfigurieren Sie zuerst den Verbraucher, dieser Server enthält eine schreibgeschützte Kopie der Datenbank:

- hosts: consumer
  become: true

  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: consumer
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret
      dirsrv_replication_user_password: foo # Wird cn=Replication Manager,cn=config mit diesem Passwort erstellen
      dirsrv_consumer_referral_to_supplier: "ldap://supplier.example.local:389/"

Konfigurieren Sie dann den Lieferanten, dieser Server akzeptiert Schreibvorgänge und überträgt alle Änderungen an den Verbraucher:

- hosts: supplier
  become: true

  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: supplier
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: verysecret
      dirsrv_replication_user_password_remote: foo # Wird sich mit cn=Replication Manager,cn=config und diesem Passwort auf dem anderen Server verbinden
      dirsrv_consumer_uri: "ldap://consumer.example.local:389/" # Der andere Server (der oben definierte Verbraucher)
      dirsrv_supplier_replica_id: 123

Multi-Master mit zwei Meistern

- hosts: mm1
  become: true
  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: 'both'
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret1
      dirsrv_replication_user_password: "aaaaaa"
      dirsrv_replication_user_password_remote: "bbbbbb" # Auf dem anderen Server
      dirsrv_consumer_uri: "ldap://mm2.example.local:389/" # Der andere Server
      dirsrv_supplier_replica_id: 1

- hosts: mm2
  become: true
  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: 'both'
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret2
      dirsrv_replication_user_password: "bbbbbb"
      dirsrv_replication_user_password_remote: "aaaaaa" # Auf dem anderen Server
      dirsrv_consumer_uri: "ldap://mm1.example.local:389/" # Der andere Server
      dirsrv_supplier_replica_id: 2

Bekannte Fehler

Wenn dirsrv_replication_user_password geändert wird, wird keine Änderung gemeldet: Das liegt daran, dass das Passwort bei jedem Lauf tatsächliche geändert wird (Ansible kann nicht feststellen, ob das vorherige gehashte Passwort dasselbe ist wie das neue), sodass es geändert und erneut gehasht wird, aber es gibt ein changed_when: false, um dieses Detail zu verbergen.

Lizenz

MIT.