La herramienta principal para mantener directorios OpenLDAP bien sincronizados es el demonio slurpd, perteneciente también al proyecto OpenLDAP.

La función del demonio slurpd es observar todos los cambios que se realizan en el directorio maestro, de manera que cada vez que registra un cambio en el directorio maestro, intenta replicar esa modificación el el directorio esclavo, de manera que los dos directorios queden sincronizados en todo momento.
Para esto se precisa de al menos dos directorios, uno que va a ser el maestro junto con el cual se va a encontrar el demonio slurpd, y el esclavo, que puede estar en una máquina remota.

La forma que el demonio slurpd tiene de replicar los cambios del directorio maestro al esclavo, es haciendo un bind a un usuario del directorio esclavo, al igual que se hace un bind al usuario administrador del directorio cuando se quiere modificar información del árbol.
El demonio slurpd, toma sus valores de configuración del fichero slapd.conf, al igual que el demonio slapd.

Los valores que es necesario dejar bien configurados en este fichero de configuración, para que la replicación funcione correctamente, son los siguientes:

replogfile      /var/lib/ldap/replog
replica uri=ldap://192.168.1.2
binddn="cn=Replica,dc=codeplex,dc=ndos"
bindmethod=simple
credentials=foobar


La directiva replogfile indica la ruta donde se encuentra el fichero de logs de la replicación. En este fichero se registran, en formato ldif, los cambios que se suceden en el directorio maestro. El demonio slurpd esta constantemente monitorizando este fichero, y en el momento en el que entra información, el demonio slurpd ejecuta esa modificación en el directorio esclavo y espera un código de suceso. Si ese código de suceso es positivo, el demomio slurpd elimina del fichero replogile las modificaciones, dejandolo de nuevo vacío.

El valor de replica uri, como su nombre indica, se refiere a el host y puerto en el cual se encuentra el directorio esclavo en el cual se van a replicar las modificaciones que ocurran en el maestro.
Como ya se ha comentado previamente en este handbook, binddn es el usuario del directorio que el directorio maestro, a través de slurpd, va a utilizar para hacer las modificaciones que requiera la replicación en el directorio esclavo. Puesto que se usa un usuario para esto, también se precisa de la contraseña que está asociada a dicho usuario. Esta contraseña queda indicada en la variable credentials.

El tipo de autenticación que ha de realizarse en el proceso de sincronización queda indicado con el valor de bindmethod. En este ejemplo el utilizado es el método simple.
Con estos valores el servidor maestro queda configurado suficientemente para que el demonio slurpd intente realizar la sincronización contra el directorio esclavo.

Para que esto tenga éxito, el servidor esclavo, también a través del fichero de configuración slapd.conf, ha de quedar configurado para que acepte y finalice correctamente la solicitud de sincronización del servidor maestro.
En primer lugar, el servidor esclavo, ha de definir cuidadosamente los permisos o acl's correspondientes al usuario que slurpd va a utilizar para realizar las modificaciones en este directorio esclavo. Este usuario, como se ha dicho hace un momento, es el definido en el valor de binddn del slapd.conf del servidor maestro.

A continuación resulta necesario definir dos directivas propias de la replicación que son las siguientes:

updatedn "cn=Replica,dc=codeplex,dc=ndos"
updateref "ldap://172.16.161.1"


La directiva updateref indica la dirección del servidor que hace de maestro, y a través del cual deberían de ser todas las modificaciones que se realizasen en el servidor esclavo.

La directiva updatedn hace referencia una vez más al usuario a través del cual se van a realizar las modificaciones provenientes del intento de sincronización del servidor maestro. Cualquier intento de modificación del directorio esclavo que no sea a través del usuario indicado en updatedn va a originar que este servidor devuelva una respuesta al cliente indicándole que la modificación que está intentando realizar en este servidor, ha de realizarse a través del servidor indicado en updateref. Con esto se consigue mantener una consistencia en la replicación forzando que cualquier intento de escritura en el servidor esclavo, solo provenga del servidor maestro y por medio del usuario de la replicación. El único usuario que va a tener permiso para realizar una modificación directamente en el servidor esclavo, es el usuario root del mismo, por lo que es conveniente separar el usuario root y el usuario encargado de la replicación.

También cualquier intento de escritura por medio del usuario de la replicación indicado en updatedn pero que no sea solicitado por el demonio slurpd del servidor maestro, va originar un error, que va a ser devuelto al cliente que esté intentando hacer esa escritura en el servidor esclavo.
Un esquema aproximado del funcionamiento de una replicación sería el siguiente:

slurpd_schema.png

Una vez que tanto el servidor maestro como el esclavo están correctamente configurados, el siguiente paso es hacer que los dos directorios partan de una misma base de información. Par ello hay que hacer una copia de seguridad de el árbol maestro y cargarla en el servidor esclavo.
Aquí se puede entrever un problema. En el proceso de copia y carga en el directorio esclavo, puede suceder que un cliente realice una modificación en el servidor maestro, por lo que una vez cargada la copia de seguridad en el esclavo, de nuevo habría dos versiones distintas. Para ello lo ideal podría ser parar el servidor maestro, pero como normalmente para un administrador la situación ideal no existe, lo menos traumático será reiniciar el servidor maestro en solo lectura. Para esto simplemente hay que añadir la directiva readonly y darle el valor on, en el fichero de configuración slapd.conf del servidor maestro.

Es momento de hacer la copia. Hay muchas formas de realizar esto. La más rápida y sencilla es por medio del comando slapcat que viene incluido en el paquete de openldap.

/usr/local/sbin/slapcat -b “dc=codeplex,dc=ndos” -l backup.ldif


El fichero backup.ldif conteniendo la información integra del directorio maestro, se copia al directorio esclavo, y se carga. Se sobreentiende que el directorio esclavo está totalmente vacío de información en el momento de cargar los datos del maestro.

/usr/local/sbin/slapadd -l backup.ldif


Ahora que en los dos directorios hay exactamente la misma información, ya se pueden iniciar, y a partir de ahora todo dato modificado en el servidor principal será replicado en el servidor esclavo.

Last edited Jan 10, 2007 at 11:29 AM by luisbosque, version 9

Comments

No comments yet.