Как исправить ошибку загрузки Zimbra «LDAP-сервер не отвечает»: практическое руководство по восстановлению.

Когда Zimbra завершает работу с ошибкой при запуске, например , с ошибкой LDAP server not responding, важный вопрос заключается не просто в том, как заставить это сообщение исчезнуть. Настоящая цель — восстановить работоспособную зависимость от LDAP, убедиться, что Zimbra снова может считывать свою конфигурацию, и избежать изменения несвязанных сервисов, пока первопричина остается неизвестной.

Данное руководство ориентировано на достижение именно такого результата. В нем используются команды, описанные в документации Zimbra, для проверки состояния службы, проверки LDAP, локальной конфигурации, проверки сертификатов и URL-адресов LDAP для нескольких серверов. В примерах используются имена хостов-заполнителей, например ldap1.example.com, ; замените их значениями из вашей собственной конфигурации.

Как должно выглядеть успешное выздоровление

Прежде чем что-либо менять, определите конечную цель. Ремонт считается убедительным, если выполняются все следующие условия:

• ldap statusсообщает о запущенном slapdпроцессе на узле LDAP.
• zmcontrol statusСообщается, что на затронутом хосте запущены LDAP и зависимые от него службы Zimbra.
• Имя хоста LDAP преобразуется в ожидаемый адрес на соответствующем узле Zimbra.
• Настроенный порт LDAP доступен.
• Если используется протокол TLS, цепочка сертификатов проходит проверку, и предыдущая ошибка TLS исчезает.
• В многосерверной конфигурации ldap_urlдолжны ldap_master_urlсодержаться действительные, активные LDAP-хосты в заданном порядке.
• После перезапуска /var/log/zimbra.logповторяющиеся ошибки подключения к LDAP больше не отображаются.

Если одна из этих проверок по-прежнему не проходит, продолжайте устранение неполадок на этом уровне, а не перезапускайте весь стек Zimbra снова и снова.

Краткая справка: симптомы и дальнейшая проверка

1. Выясните, не отключен ли сам LDAP.

Выполнять проверки состояния от имени zimbraпользователя:

su - zimbra
zmcontrol status
ldap status

В документации Zimbra по устранению неполадок LDAP рекомендуется проверить, slapdзапущен ли процесс, а затем убедиться, что Zimbra его распознает ldap status. Если LDAP не запущен локально, перед устранением неполадок почтовых ящиков, MTA, прокси или веб-сервисов следует изучить сам процесс LDAP. LDAP является ключевым элементом конфигурации, поэтому нижестоящие сервисы могут выйти из строя просто потому, что не могут прочитать данные конфигурации.

Справочная информация: документация по устранению неполадок Zimbra LDAP и справочник команд Zimbra zmcontrol .

2. Перед изменением служб проверьте URL-адреса LDAP.

На затронутом узле проверьте локальные конечные точки LDAP:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

В документации Zimbra 10 для многосерверной архитектуры ldap_urlуказывается, к каким LDAP-серверам должен обращаться узел, а также ldap_master_urlуказывается конечная точка или набор главных серверов, используемых для записи. Zimbra также указывает, что URL-адреса реплик обычно должны располагаться перед главным сервером в списке ldap_url, при этом главный сервер должен оставаться в списке.

Эта проверка особенно важна после миграции сервера, замены LDAP, перенумерации IP-адресов, аварийного восстановления или поэтапного обновления. Полностью исправный LDAP-сервер не сможет помочь узлу Zimbra, который все еще пытается связаться с устаревшим именем хоста.

Проверьте разрешение имен и доступность по протоколу TCP.

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

Если DNS возвращает неверный адрес, сначала исправьте разрешение имен. Если DNS работает правильно, но порт недоступен, проверьте маршрутизацию сети, брандмауэры хоста, группы безопасности или прослушиватель демона LDAP. Не меняйте пароли LDAP только потому, что TCP-соединение истекает по таймауту; таймаут происходит до того, как можно будет оценить учетные данные для привязки.

В текущем руководстве по многосерверной установке Zimbra версии 10 прямо указано, что узлы, не использующие LDAP, должны связаться с главным сервером LDAP во время настройки, и говорится, что установка не может быть продолжена, если сервер недоступен. См. руководство по многосерверной установке Zimbra Daffodil версии 10 .

3. Прежде чем решать, что ремонтировать, ознакомьтесь с журналом.

Используйте центральный журнал Zimbra для определения категории сбоя:

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

Ищите закономерность, а не отдельную строку. К распространенным категориям относятся: таймаут соединения, отказ в соединении, ошибки имени хоста, сбои привязки или ошибки проверки TLS. Категория имеет значение, поскольку для каждой требуется свой способ устранения неполадок.

• Истекло время ожидания или отсутствует маршрут: сосредоточьтесь на DNS, маршрутизации, брандмауэре или неработоспособном хосте.
• Соединение отклонено: хост доступен, но на настроенном порту ничего не принимает соединения, или локальный брандмауэр активно отклоняет его.
• Ошибка проверки TLS/SSL: проверка сертификатов и цепочек доверия.
• Ошибка аутентификации или привязки: только в этом случае следует проверить пароли LDAP или учетные данные репликации.

Когда проблема в сертификатах

В Zimbra зафиксированы случаи сбоя связи по LDAP из-за истечения срока действия корневого или промежуточного центра сертификации. Полезной командой для проверки коммерческого сертификата является:

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

Запустите программу из каталога, содержащего файлы соответствующих коммерческих сертификатов, обычно это папка ` /opt/zimbra/ssl/zimbra/commercial/.`. Если проверка не пройдена, исправьте цепочку сертификатов, а не отключайте проверку TLS в качестве быстрого способа.

Ссылка: Рекомендации Zimbra по устранению проблем с истекшим сроком действия корневого центра сертификации и сбоями TLS LDAP .

4. Исправляйте устаревшие конечные точки LDAP только после проверки замены.

Если указанное имя хоста устарело, и вы уже проверили, какой LDAP-сервер активен, обновите локальную конфигурацию от имени zimbraпользователя. Например:

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

Для развертывания с репликами используйте топологию, описанную для вашей среды, а не сокращайте список до одного сервера. В документации Zimbra версии 10 приведены примеры, в которых реплики указываются первыми для операций чтения, а главный сервер остается в списке. В многомастерных средах существуют свои требования к порядку реплик.

Не копируйте эти примеры URL-адресов дословно. Сначала подтвердите протокол, имя хоста, порт и предполагаемую роль мастера/реплики. Если в вашей системе используется LDAPS или StartTLS, сохраните настройки безопасности, а не переключайтесь автоматически на обычный LDAP для успешного запуска.

5. Перезапустите программу один раз, затем проверьте всю цепочку зависимостей.

После устранения первопричины проблемы перезапустите Zimbra:

zmcontrol restart

Затем проверьте:

ldap status
zmcontrol status

Простого перезапуска, изменяющего сообщение об ошибке, недостаточно. Необходимо повторно проверить /var/log/zimbra.logналичие сбоев подключения и протестировать обычные административные или пользовательские операции, соответствующие роли сервера.

6. В многосерверных средах требуется дополнительная проверка репликации.

Если вы используете реплики LDAP или несколько мастеров, сервер может быть доступен, в то время как репликация будет неисправна. Zimbra описывает утилиту zmreplchkдля проверки репликации:

/opt/zimbra/libexec/zmreplchk

В документации Zimbra для многомастерных систем корректным результатом считается состояние синхронизации с кодом ошибки 0. Точная процедура восстановления зависит от того, используется ли одномастерная репликация, многомастерная репликация или выполняется миграция.

См. руководство по репликации Zimbra LDAP Multi-Master и текущую документацию по многосерверной архитектуре Zimbra 10 .

Когда следует изменить направление поиска и устранения неисправностей

Прекратите рассматривать это как простую проблему с подключением, если выполняется хотя бы одно из следующих условий:

• slapdНе запускается, несмотря на то, что имя хоста и конфигурация порта верны.
• В журнале регистрируются ошибки в базе данных или хранилище данных LDAP, а не сетевые ошибки.
• После восстановления связи репликация по-прежнему остается рассинхронизированной.
• После миграции пароли различаются между главными и реплицированными LDAP-серверами.
• LDAP-слушатель не может выполнить привязку, поскольку настроенное имя хоста больше не принадлежит серверу.

В этом случае проблема может быть связана с восстановлением базы данных LDAP, учетными данными репликации, состоянием миграции или идентификацией сервера, а не с простой ситуацией «сервер не отвечает». В документации Zimbra по миграции особо отмечается, что DNS, несоответствие имен хостов, неверные пароли локальной конфигурации и устаревшие ссылки на старые серверы LDAP могут препятствовать запуску LDAP.

Чего не следует делать

• Не следует удалять файлы базы данных LDAP на начальном этапе устранения неполадок.
• Не следует сбрасывать пароли LDAP до тех пор, пока не будет доказано, что сбой происходит на уровне аутентификации.
• Не следует удалять главный сервер из каждого LDAP-адреса только потому, что отвечает хотя бы одна реплика.
• Не следует отключать проверку TLS только для того, чтобы соединение установилось успешно.
• Не запускайте программу повторно, zmcontrol restartне ознакомившись с полученными логами.

Итоговый контрольный список восстановления

• Имя хоста LDAP разрешается в нужный хост.
• Порт LDAP доступен с затронутого узла Zimbra.
• ldap_urlи ldap_master_urlсоответствовать существующей топологии.
• Цепочка TLS-сертификатов действительна при использовании зашифрованного LDAP.
• ldap statusОтчеты slapdо ходе выполнения.
• zmcontrol statusОтображает список запущенных необходимых служб.
• Там, где это применимо, репликация осуществляется синхронно.
• /var/log/zimbra.logБольше не отображаются повторяющиеся сбои LDAP.

Основной недостаток этой процедуры заключается в том, что ошибка «LDAP-сервер не отвечает» — это симптом зависимости, а не единственная первопричина. Она может быть вызвана зависшим процессом LDAP, устаревшими URL-адресами, неисправным DNS, заблокированными портами, сбоями сертификатов, проблемами репликации или некорректными учетными данными. Поэтому наиболее безопасный подход — проверять каждый уровень по порядку и изменять только тот уровень, который неисправен.