389ds-replication

Configurer la réplication entre les instances de serveur 389DS (serveur LDAP).

ansible-galaxy install lvps.389ds_replication

Exigences

• Version d'Ansible : 2.7 ou supérieure
• Système d'exploitation : CentOS 7

Si Ansible ne prend pas en charge le module ldap_attrs, cela signifie que vous utilisez une ancienne version des collections, mais vous pouvez essayer la version 1.0.x de ce rôle.

Variables du rôle

Variable	Par défaut	Description	Peut être modifié	Rôle
dirsv_replication_role		Rôle de ce serveur : 'supplier', 'consumer' ou 'both' (maître). Hub n'est pas supporté.	Non
dirsrv_server_uri	"ldap://localhost"	URI du serveur à configurer. Puisque cela s'exécute sur la cible Ansible, localhost devrait convenir. Il est possible de le définir sur ldaps://localhost pour utiliser TLS sur le port 636.		CSB
dirsrv_rootdn	"cn=Directory Manager"	DN racine (nom d'utilisateur du compte administrateur)		CSB
dirsrv_rootdn_password	secret	Mot de passe pour le compte DN racine		CSB
dirsrv_use_starttls	true	Utiliser StartTLS pour se connecter au serveur		CSB
dirsrv_tls_certificate_trusted	true	Vrai si le certificat TLS provient d'une autorité de certification de confiance, faux s'il est auto-signé ou provient d'une autorité privée, non utilisé si TLS n'est pas utilisé		CSB
dirsrv_serverid	default	ID du serveur, alias ID d'instance, par exemple si le serveur est installé dans le répertoire dirsrv/slapd-example, "example" est l'ID du serveur		CSB
dirsrv_suffix	dc=example,dc=local	Suffixe racine		CSB
dirsrv_supplier_replica_id	1	Choisissez un nombre entre 1 et 65534. Ne l'assignez pas à d'autres serveurs sous peine de provoquer des problèmes.	Non	SB
dirsrv_consumer_uri	"ldap://consumer.example.com:389/"	URI complète, y compris le port, que le fournisseur utilisera pour se connecter et effectuer la réplication.	Non	SB
dirsrv_replication_user_remote	Replication Manager	Compte utilisateur qui existe sur le consommateur. Le fournisseur se connectera avec ce compte pour effectuer la réplication. "Replication Manager" signifie que le compte est "cn=Replication Manager,cn=config"	Oui	SB
dirsrv_replication_user_password_remote		Mot de passe pour le compte de l'utilisateur de réplication (Replication Manager)	Oui	SB
dirsrv_replica_bind_method	"PLAIN"	Méthode de liaison que le fournisseur utilise pour se connecter au consommateur (SIMPLE, PLAIN, SASL)	Oui	SB
dirsrv_changelog_max_age	"10d"	Définit la valeur de nsslapd-changelogmaxage.	Oui	SB
dirsrv_replica_attributes_list	"(objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof"	Définit la valeur de nsds5ReplicatedAttributeList, la valeur par défaut de cette variable est utilisée dans les exemples de la documentation.	Oui	SB
dirsrv_replica_attributes_list_total	"(objectclass=*) $ EXCLUDE accountUnlockTime"	Définit la valeur de nsds5ReplicatedAttributeListTotal, la valeur par défaut de cette variable est utilisée dans les exemples de la documentation.	Oui	SB
dirsrv_replication_user	Replication Manager	Compte utilisateur à créer sur le consommateur. Ce compte sera utilisé par le fournisseur pour se connecter sur ce serveur (le consommateur). "Replication Manager" signifie que le compte sera créé à "cn=Replication Manager,cn=config"	Oui	CB
dirsrv_replication_user_password		Mot de passe pour ce compte.	Oui	CB
dirsrv_begin_replication_immediately	true	Booléen, définit nsds5ReplicaEnabled sur "on" ou "off" dans l'accord de réplication. Cela devrait être sûr : si vous ajoutez un nouveau serveur, il ne commencera pas à pousser sa base de données vide vers d'autres serveurs.	Non	CB
dirsrv_consumer_referral_to_supplier	"ldap://supplier.example.com:389/"	URI LDAP complète y compris le port. Lorsqu'un client essaie d'écrire sur un consommateur, qui est en lecture seule, il sera redirigé vers ce serveur (un fournisseur qui peut accepter des écritures).	Oui	C

Tout d'abord, choisissez si le serveur est un fournisseur, un consommateur ou les deux, et définissez dirsv_role en conséquence. Ensuite, définissez les variables connexes : regardez dans la colonne des Rôles, C = Consommateur, S = Fournisseur, B = Les deux.

Certaines variables ne peuvent pas être modifiées une fois définies, les changer produira des résultats inattendus, allant de "rien ne se passe" à "le rôle échoue". D'autres (détails d'authentification, suffixe, etc.) doivent être définies avec la bonne valeur pour le serveur, peuvent être modifiées tant que cela a du sens, c'est-à-dire que vous pouvez changer dirsrv_rootdn_password si vous avez changé le mot de passe du DN racine pour que ce rôle puisse s'authentifier correctement, mais changer dirsrv_suffix entre un run et un autre sur le même serveur n'a pas de sens, à moins que vous ne parveniez d'une manière ou d'une autre à changer le suffixe dans 389DS.

Les variables suivantes portent exactement le même nom et signification que dans le rôle 389ds-server, donc si vous utilisez les deux rôles dans le même playbook, vous pouvez les définir une seule fois :

• dirsrv_rootdn
• dirsrv_rootdn_password
• dirsrv_tls_certificate_trusted
• dirsrv_serverid
• dirsrv_suffix

Dépendances

Aucune.

Mais gardez à l'esprit que ce rôle s'attend à ce que 389DS soit déjà en cours d'exécution, il ne fait que configurer la réplication entre des serveurs existants.

Exemple de Playbook

Plus d'exemples, y compris l'installation de 389DS depuis le début et les configurations Vagrant nécessaires pour les tester, sont disponibles dans le référentiel 389ds-examples.

Notez que, généralement, la réplication ne commence pas immédiatement parce que la "génération de réplica" est différente entre les serveurs. Cela peut être corrigé avec la procédure de "rafraîchissement de réplica", qui est décrite par exemple dans la section 15.2.5 du guide d'administration. Vous devrez le faire sur les fournisseurs ou les serveurs avec le rôle "les deux".

Dans l'ensemble, procéder à un "rafraîchissement de réplica" poussera de force la base de données d'un fournisseur vers un consommateur, remplaçant ainsi l'ancienne base de données du consommateur : commencez par un fournisseur et progressez progressivement vers les autres, en faisant attention à ne pas remplacer une base de données de production par la base de données vide d'un serveur qui vient d'être installé. Lorsque deux serveurs ont exactement la même base de données, la réplication commence automatiquement et immédiatement.

La procédure est également expliquée plus en détail dans le référentiel 389ds-examples.

Consommateur et fournisseur

Configurez d'abord le consommateur, ce serveur contiendra une copie en lecture seule de la base de données :

- 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 # Créera cn=Replication Manager,cn=config avec ce mot de passe
      dirsrv_consumer_referral_to_supplier: "ldap://supplier.example.local:389/"

Ensuite, configurez le fournisseur, ce serveur acceptera les écritures et poussera tous les changements vers le consommateur :

- 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 # Se liera avec cn=Replication Manager,cn=config et ce mot de passe sur l'autre serveur
      dirsrv_consumer_uri: "ldap://consumer.example.local:389/" # L'autre serveur (le consommateur défini ci-dessus)
      dirsrv_supplier_replica_id: 123

Multi-maître avec deux maîtres

- 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" # Sur l'autre serveur
      dirsrv_consumer_uri: "ldap://mm2.example.local:389/" # L'autre serveur
      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" # Sur l'autre serveur
      dirsrv_consumer_uri: "ldap://mm1.example.local:389/" # L'autre serveur
      dirsrv_supplier_replica_id: 2

Bugs connus

Si dirsrv_replication_user_password est changé, aucun changement n'est signalé : c'est parce que le mot de passe change en fait à chaque exécution (Ansible ne peut pas dire si le mot de passe haché précédent est le même que le nouveau, donc il sera changé et haché à nouveau), mais il y a changed_when: false pour cacher ce détail.

Licence

MIT.