389ds-replikacja

Skonfiguruj replikację między instancjami serwera 389DS (serwer LDAP).

ansible-galaxy install lvps.389ds_replication

Wymagania

• Wersja Ansible: 2.7 lub wyższa
• System operacyjny: CentOS 7

Jeśli Ansible nie obsługuje modułu ldap_attrs, używasz starej wersji kolekcji, ale możesz spróbować wersji 1.0.x tego zadania.

Zmienne roli

Zmienna	Wartość domyślna	Opis	Można zmienić	Rola
dirsv_replication_role		Rola tego serwera: 'dostawca', 'odbiorca' lub 'obydwa' (master). Hub nie jest obsługiwany.	Nie
dirsrv_server_uri	"ldap://localhost"	URI serwera do skonfigurowania. Ponieważ działa to na docelowym systemie Ansible, localhost powinien być w porządku. Można ustawić na ldaps://localhost, aby używać TLS na porcie 636.		CSB
dirsrv_rootdn	"cn=Directory Manager"	Root DN (nazwa użytkownika konta "administrator")		CSB
dirsrv_rootdn_password	hasło	Hasło dla konta root DN		CSB
dirsrv_use_starttls	true	Użyj StartTLS do połączenia z serwerem		CSB
dirsrv_tls_certificate_trusted	true	Prawda, jeśli certyfikat TLS pochodzi z zaufanej CA, fałsz, jeśli jest samopodpisany lub z prywatnej CA, niewykorzystywany, jeśli TLS nie jest używany		CSB
dirsrv_serverid	default	ID serwera, czyli ID instancji, np. jeśli serwer jest zainstalowany w katalogu dirsrv/slapd-example, "example" to ID serwera		CSB
dirsrv_suffix	dc=example,dc=local	Sufiks root		CSB
dirsrv_supplier_replica_id	1	Wybierz liczbę między 1 a 65534. Nie przypisuj jej innym serwerom, ponieważ mogą wystąpić problemy.	Nie	SB
dirsrv_consumer_uri	"ldap://consumer.example.com:389/"	Pełny URI, w tym port, do którego dostawca się połączy i wykona replikację, przesyłając zmiany	Nie	SB
dirsrv_replication_user_remote	Menedżer replikacji	Konto użytkownika, które istnieje na odbiorcy. Dostawca połączy się z tym kontem, aby wykonać replikację. "Menedżer replikacji" oznacza, że konto to "cn=Replication Manager,cn=config"	Tak	SB
dirsrv_replication_user_password_remote		Hasło dla konta użytkownika replikacji (Menedżer replikacji)	Tak	SB
dirsrv_replica_bind_method	"PLAIN"	Metoda połączenia, której dostawca używa do połączenia z odbiorcą (SIMPLE, PLAIN, SASL)	Tak	SB
dirsrv_changelog_max_age	"10d"	Ustala wartość nsslapd-changelogmaxage	Tak	SB
dirsrv_replica_attributes_list	"(objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof"	Ustala wartość nsds5ReplicatedAttributeList, domyślna wartość tej zmiennej jest używana w dokumentacji jako przykład	Tak	SB
dirsrv_replica_attributes_list_total	"(objectclass=*) $ EXCLUDE accountUnlockTime"	Ustala wartość nsds5ReplicatedAttributeListTotal, domyślna wartość tej zmiennej jest używana w dokumentacji jako przykład	Tak	SB
dirsrv_replication_user	Menedżer replikacji	Konto użytkownika do utworzenia na odbiorcy. To konto będzie używane przez dostawcę do połączenia z tym serwerem (odbiorca). "Menedżer replikacji" oznacza, że konto będzie utworzone jako "cn=Replication Manager,cn=config"	Tak	CB
dirsrv_replication_user_password		Hasło dla tego konta.	Tak	CB
dirsrv_begin_replication_immediately	true	Boolean, ustawia nsds5ReplicaEnabled na "on" lub "off" w umowie replikacji. Powinno to być bezpieczne: jeśli dodasz nowy serwer, nie zacznie przesyłać swojej pustej bazy danych do innych serwerów, ponieważ mają one inny identyfikator generacji, a replikacja kończy się niepowodzeniem (zobacz przykłady, aby uzyskać więcej szczegółów), ale jeśli chcesz być jeszcze bardziej ostrożny lub dostosować umowę replikacji, ustaw to na fałsz	Nie	CB
dirsrv_consumer_referral_to_supplier	"ldap://supplier.example.com:389/"	Pełny URI LDAP, w tym port. Gdy klient próbuje zapisać do odbiorcy, który jest tylko do odczytu, przekieruje klienta do tego serwera (dostawca, który może przyjąć zapis).	Tak	C

Najpierw wybierz, czy serwer jest dostawcą, odbiorcą, czy obydwa i ustaw zmienną dirsv_role odpowiednio. Następnie ustaw zmienne związane z tym: patrz w kolumnę Rola, C = Odbiorca, S = Dostawca, B = Obydwa.

Niektóre zmienne nie mogą być zmieniane po ustawieniu, ich zmiana spowoduje nieoczekiwane rezultaty, od "nic się nie dzieje" po "rola kończy się niepowodzeniem". Inne (szczegóły uwierzytelnienia, sufiks itp.) powinny być ustawione na odpowiednią wartość dla serwera, mogą być zmieniane tak długo, jak to ma sens, tzn. możesz zmienić dirsrv_rootdn_password, jeśli zmieniłeś hasło root DN, aby ta rola mogła się poprawnie uwierzytelnić, ale zmiana dirsrv_suffix między jednym a drugim uruchomieniem na tym samym serwerze jest bezsensowna, chyba że w jakiś sposób udało Ci się zmienić sufiks w 389DS.

Poniższe zmienne mają tę samą nazwę i znaczenie jak w roli 389ds-server, więc jeśli używasz obu ról w tym samym playbooku, możesz zdefiniować je tylko raz:

• dirsrv_rootdn

• dirsrv_rootdn_password

• dirsrv_tls_certificate_trusted
• dirsrv_serverid
• dirsrv_suffix

Zależności

Brak.

Ale pamiętaj, że ta rola oczekuje, że 389DS będzie już uruchomiony, tylko konfiguruje replikację między istniejącymi serwerami.

Przykładowy Playbook

Więcej przykładów, w tym instalacja 389DS od podstaw oraz potrzebne konfiguracje Vagrant do ich testowania, dostępne są w repozytorium 389ds-examples.

Zauważ, że zazwyczaj replikacja nie rozpoczyna się od razu, ponieważ "generacja repliki" jest inna między serwerami. Można to naprawić za pomocą procedury "odświeżania replikacji", która jest opisana na przykład w rozdziale 15.2.5 Przewodnika Administracyjnego. Należy to wykonać na dostawcach lub serwerach z rolą "obydwa".

Ogólnie rzecz biorąc, wykonanie "odświeżenia replikacji" wymusi przetransferowanie bazy danych z jednego dostawcy do odbiorcy, zastępując poprzednią bazę danych odbiorcy: zrób to, zaczynając od jednego dostawcy i stopniowo przechodząc do pozostałych, uważając, aby nie zastąpić bazy danych produkcyjnej pustą bazą danych serwera, który dopiero co został zainstalowany. Kiedy dwa serwery mają dokładnie tę samą bazę danych, replikacja zaczyna się automatycznie i natychmiast.

Procedura ta jest również dokładniej opisana w repozytorium 389ds-examples.

Odbiorca i dostawca

Najpierw skonfiguruj odbiorcę, ten serwer będzie zawierał kopię bazy danych tylko do odczytu:

- 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 # Utworzy cn=Replication Manager,cn=config z tym hasłem
      dirsrv_consumer_referral_to_supplier: "ldap://supplier.example.local:389/"

Następnie skonfiguruj dostawcę, ten serwer będzie akceptował zapisy i przesyłał wszystkie zmiany do odbiorcy:

- 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 # Połączy się z cn=Replication Manager,cn=config i tym hasłem na innym serwerze
      dirsrv_consumer_uri: "ldap://consumer.example.local:389/" # Inny serwer (odbiorca zdefiniowany powyżej)
      dirsrv_supplier_replica_id: 123

Multi-master z dwoma masterami

- 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" # Na drugim serwerze
      dirsrv_consumer_uri: "ldap://mm2.example.local:389/" # Inny serwer
      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" # Na drugim serwerze
      dirsrv_consumer_uri: "ldap://mm1.example.local:389/" # Inny serwer
      dirsrv_supplier_replica_id: 2

Znane błędy

Jeśli dirsrv_replication_user_password zostanie zmienione, nie zostanie zgłoszona żadna zmiana: dzieje się tak, ponieważ hasło faktycznie zmienia się przy każdym uruchomieniu (Ansible nie może określić, czy poprzednie zaszyfrowane hasło jest takie samo jak nowe, dlatego zostanie zmienione i ponownie zaszyfrowane), ale istnieje changed_when: false, aby ukryć ten szczegół.

Licencja

MIT.