Corrigindo a falha de inicialização "Servidor LDAP não está respondendo" do Zimbra: um guia prático de recuperação.

Quando o Zimbra falha durante a inicialização com um erro como esse LDAP server not responding, a questão importante não é simplesmente como fazer a mensagem desaparecer. O objetivo real é restaurar uma dependência LDAP saudável, confirmar se o Zimbra consegue ler sua configuração novamente e evitar alterar serviços não relacionados enquanto a causa raiz ainda for desconhecida.

Este guia se concentra nesse resultado. Ele usa comandos documentados pelo Zimbra para status do serviço, verificações LDAP, configuração local, verificação de certificado e URLs LDAP de vários servidores. Os exemplos usam nomes de host fictícios, como `<nome_do_host> ldap1.example.com`; substitua-os pelos valores da sua própria implementação.

Como deve ser uma recuperação bem-sucedida

Antes de alterar qualquer coisa, defina o objetivo final. Um reparo é convincente quando todas as seguintes condições forem verdadeiras:

• ldap statusRelata um slapdprocesso em execução em um nó LDAP.
• zmcontrol statusO sistema informa que o LDAP e os serviços Zimbra dependentes estão em execução no host afetado.
• O nome de host LDAP é resolvido para o endereço esperado do nó Zimbra afetado.
• A porta LDAP configurada está acessível.
• Se o TLS estiver envolvido, a cadeia de certificados é validada e o erro anterior do TLS desaparece.
• Em uma implantação com vários servidores, ldap_urlé ldap_master_urlnecessário que os hosts LDAP estejam válidos e ativos na ordem pretendida.
• Após a reinicialização, /var/log/zimbra.logos erros recorrentes de conexão LDAP deixaram de ocorrer.

Se uma dessas verificações ainda falhar, continue a solucionar problemas nessa camada em vez de reiniciar repetidamente toda a pilha Zimbra.

Guia rápido: sintomas e a próxima consulta

1. Verifique se o próprio LDAP está inativo.

Execute verificações de status como o zimbrausuário:

su - zimbra
zmcontrol status
ldap status

A documentação de solução de problemas LDAP do Zimbra recomenda verificar se o slapdprocesso está realmente em execução e, em seguida, confirmar se o Zimbra o reconhece ldap status. Se o LDAP não estiver em execução localmente, investigue o processo LDAP antes de solucionar problemas de caixa de correio, MTA, proxy ou serviços da Web. O LDAP é uma dependência de configuração essencial; portanto, os serviços subsequentes podem falhar simplesmente porque não conseguem ler os dados de configuração.

Referência: Documentação de resolução de problemas do LDAP do Zimbra e referência do comando zmcontrol do Zimbra .

2. Verifique os URLs LDAP antes de alterar os serviços.

No nó afetado, inspecione os endpoints LDAP locais:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

Na documentação do Zimbra 10 para múltiplos servidores, `<master>` ldap_urlidentifica os servidores LDAP que um nó deve consultar, enquanto ` <master> ldap_master_url` identifica o endpoint mestre ou o conjunto mestre usado para gravações. O Zimbra também documenta que os URLs de réplica normalmente devem aparecer antes do mestre em `<master>` ldap_url, com o mestre mantido na lista.

Essa verificação é especialmente importante após uma migração de servidor, substituição de LDAP, renumeração de IP, recuperação de desastres ou atualização gradual. Um servidor LDAP em perfeito funcionamento não pode ajudar um nó Zimbra que ainda esteja tentando contatar um nome de host desativado.

Verifique a resolução de nomes e a acessibilidade TCP.

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

Se o DNS retornar o endereço errado, corrija primeiro a resolução de nomes. Se o DNS estiver correto, mas a porta não puder ser acessada, investigue o roteamento de rede, os firewalls do host, os grupos de segurança ou o listener do daemon LDAP. Não altere as senhas do LDAP apenas porque a conexão TCP expirou; o tempo limite ocorre antes que as credenciais de vinculação possam ser avaliadas.

O guia atual do Zimbra v10 para múltiplos servidores exige explicitamente que os nós não LDAP contatem o servidor LDAP mestre durante a configuração e afirma que a instalação não pode prosseguir se o servidor estiver inacessível. Consulte o Guia de Instalação do Zimbra Daffodil v10 para Múltiplos Servidores .

3. Leia o registro antes de decidir o que reparar.

Utilize o log central do Zimbra para identificar a categoria da falha:

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

Procure por um padrão em vez de uma única linha. Categorias comuns incluem tempo limite de conexão, conexão recusada, erros de nome de host, falhas de vinculação ou erros de validação TLS. A categoria é importante porque cada uma requer uma correção diferente.

• Tempo limite excedido ou sem rota: concentre-se no DNS, roteamento, firewall ou em um host inativo.
• Conexão recusada: o host está acessível, mas nenhum dispositivo está aceitando conexões na porta configurada, ou um firewall local está ativamente bloqueando a conexão.
• Erro de validação TLS/SSL: verifique os certificados e as cadeias de confiança.
• Erro de autenticação ou de vinculação: somente então investigue as senhas LDAP ou as credenciais de replicação.

Quando os certificados são o problema

O Zimbra documentou casos em que a comunicação LDAP falha devido à expiração de uma CA raiz ou intermediária. Um comando útil para verificar a autenticidade de um certificado comercial é:

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

Execute o programa a partir do diretório que contém os arquivos de certificado comercial relevantes, geralmente localizado em /opt/zimbra/ssl/zimbra/commercial/. Se a validação falhar, corrija a cadeia de certificados em vez de desativar a verificação TLS como uma solução paliativa.

Referência: Orientações do Zimbra para CA raiz expirada e falhas de TLS LDAP .

4. Corrija os endpoints LDAP obsoletos somente após verificar a substituição.

Se o nome do host configurado estiver obsoleto e você já tiver verificado o servidor LDAP ativo correto, atualize a configuração local como zimbrausuário. Por exemplo:

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

Para uma implementação com réplicas, utilize a topologia documentada para o seu ambiente, em vez de reduzir a lista a um único servidor. A documentação do Zimbra v10 fornece exemplos em que as réplicas são listadas primeiro para leituras e o servidor mestre permanece incluído. Ambientes com múltiplos servidores mestres têm seus próprios requisitos de ordenação.

Não copie esses URLs de exemplo literalmente. Confirme primeiro o protocolo, o nome do host, a porta e a função de mestre/réplica pretendida. Se sua implementação usa LDAPS ou StartTLS, preserve o design de segurança em vez de mudar silenciosamente para LDAP puro para que a inicialização seja bem-sucedida.

5. Reinicie uma vez e, em seguida, valide toda a cadeia de dependências.

Após corrigir a causa raiz do problema, reinicie o Zimbra:

zmcontrol restart

Em seguida, verifique:

ldap status
zmcontrol status

Uma reinicialização que apenas altera a mensagem de erro não é suficiente. Verifique novamente /var/log/zimbra.logse há falhas de conexão repetidas e teste as operações administrativas ou de usuário normais, adequadas à função do servidor.

6. Ambientes com vários servidores exigem uma verificação de replicação adicional.

Se você utiliza réplicas LDAP ou múltiplos servidores mestre, um servidor pode estar acessível mesmo que a replicação esteja com problemas. O Zimbra documenta a zmreplchkferramenta para validação de replicação:

/opt/zimbra/libexec/zmreplchk

Para sistemas com múltiplos mestres, a documentação do Zimbra descreve um resultado saudável como um status sincronizado com código de erro 0. O procedimento exato de recuperação depende se você tem replicação com um único mestre, replicação com múltiplos mestres ou uma migração em andamento.

Consulte as orientações sobre replicação multi-mestre LDAP do Zimbra e a documentação atual do Zimbra 10 para vários servidores .

Quando mudar a direção da resolução de problemas

Pare de tratar isso como um simples problema de conectividade quando qualquer uma das seguintes situações for verdadeira:

• slapdNão inicia, mesmo que o nome do host e a configuração da porta estejam corretos.
• O registro de logs reporta erros no banco de dados ou no armazenamento de dados LDAP, e não erros de rede.
• A replicação permanece dessincronizada mesmo após a conectividade ter sido restabelecida.
• As senhas diferem entre os servidores LDAP mestre e réplica após uma migração.
• O listener LDAP não consegue se conectar porque o nome do host configurado não pertence mais ao servidor.

Nesse ponto, o problema pode envolver a recuperação do banco de dados LDAP, credenciais de replicação, estado da migração ou identidade do servidor, em vez de uma simples condição de "servidor não responde". A documentação de migração do Zimbra observa especificamente que DNS, incompatibilidades de nome de host, senhas de configuração local incorretas e referências obsoletas a servidores LDAP antigos podem impedir a inicialização do LDAP.

O que não fazer

• Não exclua os arquivos do banco de dados LDAP como uma primeira medida de solução de problemas.
• Não redefina as senhas LDAP antes de comprovar que a autenticação é a camada com falha.
• Não remova um servidor mestre de todos os URLs LDAP só porque uma réplica está respondendo.
• Não desative a verificação TLS apenas para que a conexão seja bem-sucedida.
• Não execute o comando repetidamente zmcontrol restartsem ler os registros gerados.

Lista de verificação final para recuperação

• O nome de host LDAP é resolvido para o host pretendido.
• A porta LDAP está acessível a partir do nó Zimbra afetado.
• ldap_urle ldap_master_urlcorresponder à topologia atual.
• A cadeia de certificados TLS é válida se o LDAP criptografado for usado.
• ldap statusrelatórios slapdem execução.
• zmcontrol statusMostra os serviços necessários em execução.
• A replicação está sincronizada quando aplicável.
• /var/log/zimbra.logNão apresenta mais falhas recorrentes no LDAP.

A principal limitação deste procedimento é que "servidor LDAP não responde" é um sintoma de dependência, e não a causa raiz isolada. Pode resultar de um processo LDAP inativo, URLs desatualizadas, DNS corrompido, portas bloqueadas, falhas de certificado, problemas de replicação ou credenciais incorretas. A abordagem mais segura é, portanto, testar cada camada em ordem e alterar apenas a camada que apresentar falha.