389ds-replication

Configura la replicación entre instancias de servidor 389DS (servidor LDAP).

ansible-galaxy install lvps.389ds_replication

Requisitos

• Versión de Ansible: 2.7 o superior
• SO: CentOS 7

Si Ansible no soporta el módulo ldap_attrs, estás usando una versión antigua de las colecciones, pero puedes intentar la versión 1.0.x de este rol.

Variables del rol

Variable	Predeterminado	Descripción	Se puede cambiar	Rol
dirsv_replication_role		Rol de este servidor: 'supplier' (proveedor), 'consumer' (consumidor) o 'both' (ambos). Hub no está soportado.	No
dirsrv_server_uri	"ldap://localhost"	URI del servidor a configurar. Dado que esto se ejecuta en el objetivo de Ansible, localhost debería estar bien. También se puede establecer en ldaps://localhost para usar TLS en el puerto 636.		CSB
dirsrv_rootdn	"cn=Directory Manager"	DN raíz (nombre de usuario de la cuenta "administrador")		CSB
dirsrv_rootdn_password	secreto	Contraseña para la cuenta de DN raíz		CSB
dirsrv_use_starttls	true	Usar StartTLS para conectarse al servidor		CSB
dirsrv_tls_certificate_trusted	true	Verdadero si el certificado TLS es de una CA de confianza, falso si es autofirmado o de una CA privada, sin usar si no se utiliza TLS		CSB
dirsrv_serverid	default	ID del servidor, también conocido como ID de instancia, por ejemplo, si el servidor está instalado en el directorio dirsrv/slapd-example, "example" es el ID del servidor		CSB
dirsrv_suffix	dc=example,dc=local	Sufijo raíz		CSB
dirsrv_supplier_replica_id	1	Elige un número entre 1 y 65534. No lo asignes a otros servidores o pueden suceder cosas malas.	No	SB
dirsrv_consumer_uri	"ldap://consumer.example.com:389/"	URI completo, incluyendo el puerto, al que el proveedor se conectará para realizar la replicación empujando cambios	No	SB
dirsrv_replication_user_remote	Replication Manager	Cuenta de usuario que existe en el consumidor. El proveedor se conectará con esta cuenta para realizar la replicación. "Replication Manager" significa que la cuenta es "cn=Replication Manager,cn=config"	Sí	SB
dirsrv_replication_user_password_remote		Contraseña para la cuenta de usuario de replicación (Replication Manager)	Sí	SB
dirsrv_replica_bind_method	"PLAIN"	Método de enlace que el proveedor usa para conectarse al consumidor (SIMPLE, PLAIN, SASL)	Sí	SB
dirsrv_changelog_max_age	"10d"	Establece el valor de nsslapd-changelogmaxage	Sí	SB
dirsrv_replica_attributes_list	"(objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof"	Establece el valor de nsds5ReplicatedAttributeList, el valor predeterminado de esta variable se usa en ejemplos de la documentación	Sí	SB
dirsrv_replica_attributes_list_total	"(objectclass=*) $ EXCLUDE accountUnlockTime"	Establece el valor de nsds5ReplicatedAttributeListTotal, el valor predeterminado de esta variable se usa en ejemplos de la documentación	Sí	SB
dirsrv_replication_user	Replication Manager	Cuenta de usuario a crear en el consumidor. Esta cuenta será utilizada por el proveedor para realizar el enlace en este servidor (el consumidor). "Replication Manager" significa que la cuenta será creada en "cn=Replication Manager,cn=config"	Sí	CB
dirsrv_replication_user_password		Contraseña para esa cuenta.	Sí	CB
dirsrv_begin_replication_immediately	true	Booleano, establece nsds5ReplicaEnabled en "on" u "off" en el acuerdo de replicación. Esto debería ser seguro: si agregas un nuevo servidor, no comenzará a enviar su base de datos vacía a otros servidores en ningún caso porque tienen un ID de generación diferente y la replicación falla (consulta ejemplos para más detalles), pero si quieres ser aún más seguro o hacer algunas personalizaciones al acuerdo de replicación, establece esto en falso	No	CB
dirsrv_consumer_referral_to_supplier	"ldap://supplier.example.com:389/"	URI LDAP completo incluyendo puerto. Cuando un cliente intenta escribir en un consumidor, que es solo de lectura, redirigirá al cliente a este servidor (un proveedor que puede aceptar escrituras).	Sí	C

Primero, elige si el servidor es un proveedor, consumidor o ambos y establece dirsv_role en consecuencia. Luego, establece las variables relacionadas: mira en la columna Rol, C = Consumidor, S = Proveedor, B = Ambos.

Algunas variables no se pueden cambiar una vez configuradas, cambiarlas puede generar resultados inesperados que van desde "no pasa nada" hasta "el rol falla". Algunas otras (detalles de autenticación, sufijo, etc.) deben establecerse en el valor correcto para el servidor, se pueden cambiar siempre que tenga sentido, es decir, puedes cambiar dirsrv_rootdn_password si has cambiado la contraseña de DN raíz para que este rol pueda autenticar correctamente, pero cambiar dirsrv_suffix entre una ejecución y otra en el mismo servidor no tiene sentido, a menos que hayas logrado cambiar el sufijo en 389DS.

Las siguientes variables tienen el mismo nombre y significado que en el rol 389ds-server, por lo que si estás utilizando ambos roles en el mismo playbook, puedes definirlas una sola vez:

• dirsrv_rootdn

• dirsrv_rootdn_password

• dirsrv_tls_certificate_trusted
• dirsrv_serverid
• dirsrv_suffix

Dependencias

Ninguna.

Pero ten en cuenta que este rol espera que 389DS ya esté en funcionamiento, solo configura la replicación entre servidores existentes.

Ejemplo de Playbook

Más ejemplos, incluyendo la instalación de 389DS desde cero y las configuraciones de Vagrant necesarias para probarlas, están disponibles en el repositorio 389ds-examples.

Ten en cuenta que, generalmente, la replicación no comienza de inmediato porque la "generación del réplica" es diferente entre los servidores. Esto se puede solucionar con el procedimiento de "recarga de réplica", que se describe, por ejemplo, en la sección 15.2.5 de la Guía de Administración. Necesitarás realizarlo en proveedores o servidores con el rol "ambos".

Básicamente, hacer una "recarga de réplica" empujará forzosamente la base de datos de un proveedor a un consumidor, reemplazando la base de datos anterior del consumidor: haz esto comenzando desde un proveedor y moviéndote gradualmente hacia los demás, teniendo cuidado de no reemplazar una base de datos de producción con la base de datos vacía de un servidor que apenas ha sido instalado. Cuando dos servidores tienen exactamente la misma base de datos, la replicación comienza automáticamente e inmediatamente.

El procedimiento también se explica con más detalles en el repositorio 389ds-examples.

Consumidor y proveedor

Configura primero el consumidor, este servidor contendrá una copia de lectura de la base de datos:

- 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: secreto
      dirsrv_replication_user_password: foo # Se creará cn=Replication Manager,cn=config con esta contraseña
      dirsrv_consumer_referral_to_supplier: "ldap://supplier.example.local:389/"

Luego configura el proveedor, este servidor aceptará escrituras y empujará todos los cambios al consumidor:

- 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: muysecreto
      dirsrv_replication_user_password_remote: foo # Se conectará con cn=Replication Manager,cn=config y esta contraseña en el otro servidor
      dirsrv_consumer_uri: "ldap://consumer.example.local:389/" # El otro servidor (el consumidor definido arriba)
      dirsrv_supplier_replica_id: 123

Multi-maestro con dos maestros

- 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: secreto1
      dirsrv_replication_user_password: "aaaaaa"
      dirsrv_replication_user_password_remote: "bbbbbb" # En el otro servidor
      dirsrv_consumer_uri: "ldap://mm2.example.local:389/" # El otro servidor
      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: secreto2
      dirsrv_replication_user_password: "bbbbbb"
      dirsrv_replication_user_password_remote: "aaaaaa" # En el otro servidor
      dirsrv_consumer_uri: "ldap://mm1.example.local:389/" # El otro servidor
      dirsrv_supplier_replica_id: 2

Errores conocidos

Si dirsrv_replication_user_password se cambia, no se reporta ningún cambio: esto se debe a que la contraseña realmente cambia en cada ejecución (Ansible no puede saber si la contraseña hash anterior es la misma que la nueva, así que se cambiará y se hashará de nuevo), pero hay un changed_when: false para ocultar ese detalle.

Licencia

MIT.