Solucionar el error de arranque de Zimbra "El servidor LDAP no responde": una guía práctica de recuperación.

Cuando Zimbra falla durante el inicio con un error como este LDAP server not responding, la pregunta importante no es simplemente cómo hacer desaparecer el mensaje. El objetivo real es restablecer una dependencia LDAP correcta, confirmar que Zimbra puede leer su configuración nuevamente y evitar modificar servicios no relacionados mientras se desconoce la causa raíz.

Esta guía se centra en ese resultado. Utiliza comandos documentados por Zimbra para el estado del servicio, comprobaciones LDAP, configuración local, verificación de certificados y URL LDAP multiservidor. Los ejemplos utilizan nombres de host de marcador de posición, como ldap1.example.com; reemplácelos con los valores de su propia implementación.

Cómo debería ser una recuperación exitosa

Antes de cambiar nada, defina el objetivo final. Una reparación es convincente cuando se cumplen todas las siguientes condiciones:

• ldap statusinforma sobre un slapdproceso en ejecución en un nodo LDAP.
• zmcontrol statusEl sistema informa que LDAP y los servicios dependientes de Zimbra se están ejecutando en el host afectado.
• El nombre de host LDAP se resuelve en la dirección esperada del nodo Zimbra afectado.
• El puerto LDAP configurado es accesible.
• Si interviene TLS, la cadena de certificados se valida y el error de TLS anterior desaparece.
• En una implementación de varios servidores, ldap_urldeben ldap_master_urlcontener hosts LDAP válidos y activos en el orden previsto.
• Tras reiniciar el sistema, /var/log/zimbra.logya no se observan fallos recurrentes de conexión LDAP.

Si alguna de estas comprobaciones sigue fallando, continúe solucionando el problema en esa capa en lugar de reiniciar repetidamente toda la pila de Zimbra.

Guía rápida: síntomas y próxima revisión

1. Compruebe si el propio LDAP está caído.

Ejecutar comprobaciones de estado como el zimbrausuario:

su - zimbra
zmcontrol status
ldap status

La documentación de solución de problemas de LDAP de Zimbra recomienda verificar si el slapdproceso se está ejecutando y confirmar que Zimbra lo reconoce ldap status. Si LDAP no se está ejecutando localmente, investigue el proceso LDAP antes de solucionar problemas de buzón, MTA, proxy o servicios web. LDAP es una dependencia de configuración fundamental, por lo que los servicios posteriores pueden fallar simplemente porque no pueden leer los datos de configuración.

Referencia: Documentación de solución de problemas de Zimbra LDAP y referencia del comando Zimbra zmcontrol .

2. Verifique las URL de LDAP antes de cambiar de servicio.

En el nodo afectado, inspeccione los puntos finales LDAP locales:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

En la documentación de Zimbra 10 para servidores múltiples, ldap_urlse identifican los servidores LDAP que un nodo debe consultar, mientras que ldap_master_urlse identifica el punto final maestro o el conjunto maestro utilizado para las escrituras. Zimbra también documenta que las URL de réplica normalmente deben aparecer antes que la maestra en ldap_url, y la maestra se conserva en la lista.

Esta comprobación es especialmente importante tras una migración de servidor, la sustitución de LDAP, la renumeración de IP, la recuperación ante desastres o una actualización progresiva. Un servidor LDAP en perfecto estado no puede ayudar a un nodo Zimbra que aún intenta contactar con un nombre de host obsoleto.

Compruebe la resolución de nombres y la accesibilidad TCP.

getent hosts ldap1.example.com
nc -zv ldap1.example.com 389

Si el DNS devuelve una dirección incorrecta, corrija primero la resolución de nombres. Si el DNS es correcto pero no se puede acceder al puerto, investigue el enrutamiento de red, los firewalls del host, los grupos de seguridad o el servicio de escucha del demonio LDAP. No cambie las contraseñas LDAP simplemente porque la conexión TCP se agote; el tiempo de espera se agota antes de que se puedan evaluar las credenciales de enlace.

La guía actual de Zimbra v10 para servidores múltiples requiere explícitamente que los nodos que no son LDAP se comuniquen con el servidor maestro LDAP durante la configuración e indica que la instalación no puede continuar si el servidor no está disponible. Consulte la Guía de instalación de Zimbra Daffodil v10 para servidores múltiples .

3. Lea el registro antes de decidir qué reparar.

Utilice el registro central de Zimbra para identificar la categoría de fallo:

tail -n 100 /var/log/zimbra.log

Busque un patrón en lugar de una sola línea. Las categorías comunes incluyen tiempo de espera de conexión agotado, conexión rechazada, errores de nombre de host, fallos de enlace o errores de validación TLS. La categoría es importante porque cada una requiere una reparación diferente.

• Tiempo de espera agotado o ruta no disponible: concéntrese en el DNS, el enrutamiento, el cortafuegos o un host inactivo.
• Conexión rechazada: el host es accesible, pero ningún sistema acepta conexiones en el puerto configurado, o bien un cortafuegos local la está rechazando activamente.
• Error de validación TLS/SSL: verifique los certificados y las cadenas de confianza.
• Error de autenticación o de enlace: solo entonces investigue las contraseñas LDAP o las credenciales de replicación.

Cuando los certificados son el problema

Zimbra tiene casos documentados en los que la comunicación LDAP falla debido a que una CA raíz o intermedia ha caducado. Un comando de verificación útil para un certificado comercial es:

/opt/zimbra/bin/zmcertmgr verifycrt comm   commercial.key commercial.crt commercial_ca.crt

Ejecútalo desde el directorio que contiene los archivos de certificado comercial correspondientes, generalmente en /opt/zimbra/ssl/zimbra/commercial/. Si la validación falla, corrige la cadena de certificados en lugar de deshabilitar la verificación TLS como solución rápida.

Referencia: Guía de Zimbra para CA raíz caducadas y fallos de LDAP TLS .

4. Corrija los puntos finales LDAP obsoletos solo después de verificar el reemplazo.

Si el nombre de host configurado está obsoleto y ya ha verificado el servidor LDAP activo correcto, actualice la configuración local como zimbrausuario. Por ejemplo:

zmlocalconfig -e ldap_url="ldap://ldap1.example.com:389"
zmlocalconfig -e ldap_master_url="ldap://ldap1.example.com:389"

Para implementaciones con réplicas, utilice la topología documentada para su entorno en lugar de reducir la lista a un solo servidor. La documentación de Zimbra v10 ofrece ejemplos en los que las réplicas se listan primero para lecturas y el maestro permanece incluido. Los entornos con varios maestros tienen sus propios requisitos de ordenación.

No copie literalmente estas URL de ejemplo. Confirme primero el protocolo, el nombre de host, el puerto y la función de maestro/réplica prevista. Si su implementación utiliza LDAPS o StartTLS, mantenga el diseño de seguridad en lugar de cambiar automáticamente a LDAP para que el inicio se complete correctamente.

5. Reinicia una vez y luego valida toda la cadena de dependencias.

Tras corregir la causa raíz, reinicie Zimbra:

zmcontrol restart

Luego verifique:

ldap status
zmcontrol status

Un simple reinicio que solo cambia el mensaje de error no es suficiente. Vuelva a comprobar /var/log/zimbra.logsi se producen fallos de conexión repetidos y pruebe las operaciones administrativas o de usuario habituales, según la función del servidor.

6. Los entornos multiservidor necesitan una comprobación de replicación adicional.

Si utiliza réplicas LDAP o varios servidores maestros, un servidor puede ser accesible aunque la replicación no funcione correctamente. Zimbra documenta la zmreplchkutilidad para la validación de la replicación:

/opt/zimbra/libexec/zmreplchk

Para sistemas multi-maestro, la documentación de Zimbra describe un resultado correcto como un estado sincronizado con código de error 0. El procedimiento de recuperación exacto depende de si se trata de replicación de un solo maestro, replicación multi-maestro o una migración en curso.

Consulte la guía de replicación multi-maestro LDAP de Zimbra y la documentación actual de Zimbra 10 para servidores múltiples .

Cuándo cambiar la dirección de la resolución de problemas

Deja de tratar esto como un simple problema de conectividad cuando se cumpla alguna de las siguientes condiciones:

• slapdNo se iniciará aunque la configuración del nombre de host y del puerto sea correcta.
• El registro informa de errores en el sistema de almacenamiento de datos o en el servidor LDAP, en lugar de errores de red.
• La replicación permanece desincronizada incluso después de que se haya restablecido la conectividad.
• Las contraseñas difieren entre los servidores maestros y las réplicas de LDAP después de una migración.
• El oyente LDAP no puede conectarse porque el nombre de host configurado ya no pertenece al servidor.

En ese punto, el problema podría estar relacionado con la recuperación de la base de datos LDAP, las credenciales de replicación, el estado de la migración o la identidad del servidor, en lugar de una simple falta de respuesta del servidor. La documentación de migración de Zimbra indica específicamente que los errores de DNS y de nombre de host, las contraseñas incorrectas de la configuración local y las referencias obsoletas a servidores LDAP antiguos pueden impedir el inicio de LDAP.

Qué no hacer

• No elimine los archivos de la base de datos LDAP como primer paso para solucionar problemas.
• No restablezca las contraseñas de LDAP antes de comprobar que la autenticación es la capa que está fallando.
• No elimine un servidor maestro de cada URL LDAP solo porque una réplica esté respondiendo.
• No desactive la verificación TLS simplemente para que la conexión se realice correctamente.
• No ejecute el programa repetidamente zmcontrol restartsin leer los registros resultantes.

Lista de verificación de recuperación final

• El nombre de host LDAP se resuelve al host previsto.
• Se puede acceder al puerto LDAP desde el nodo Zimbra afectado.
• ldap_urly ldap_master_urlque coincida con la topología actual.
• La cadena de certificados TLS es válida si se utiliza LDAP cifrado.
• ldap statusinformes slapden ejecución.
• zmcontrol statusmuestra que los servicios necesarios están en funcionamiento.
• La replicación está sincronizada cuando corresponde.
• /var/log/zimbra.logYa no muestra fallos recurrentes de LDAP.

La principal limitación de este procedimiento es que el error "El servidor LDAP no responde" es un síntoma de dependencia, no una única causa raíz. Puede deberse a un proceso LDAP inactivo, URL obsoletas, DNS defectuoso, puertos bloqueados, fallos en los certificados, problemas de replicación o credenciales incorrectas. Por lo tanto, el enfoque más seguro es verificar cada capa en orden y modificar únicamente la capa que falla.