Behebung des Zimbra-Startfehlers „LDAP-Server antwortet nicht“: Ein praktischer Leitfaden zur Wiederherstellung

Wenn Zimbra beim Start mit einer Fehlermeldung wie beispielsweise „Fehlermeldung“ abbricht LDAP server not responding, ist die wichtigste Frage nicht einfach, wie die Meldung verschwindet. Das eigentliche Ziel ist es, eine funktionierende LDAP-Abhängigkeit wiederherzustellen, sicherzustellen, dass Zimbra seine Konfiguration wieder lesen kann, und Änderungen an anderen Diensten zu vermeiden, solange die Ursache noch unbekannt ist.

Dieser Leitfaden konzentriert sich auf dieses Ergebnis. Er verwendet die von Zimbra dokumentierten Befehle für den Dienststatus, LDAP-Prüfungen, die lokale Konfiguration, die Zertifikatsverifizierung und LDAP-URLs für mehrere Server. Die Beispiele verwenden Platzhalter-Hostnamen wie z. B. `<hostname>` ldap1.example.com; ersetzen Sie diese durch die Werte Ihrer eigenen Installation.

Wie eine erfolgreiche Genesung aussehen sollte

Bevor Sie irgendetwas ändern, definieren Sie das Ziel. Eine Reparatur ist überzeugend, wenn alle folgenden Punkte zutreffen:

• ldap statusmeldet einen laufenden slapdProzess auf einem LDAP-Knoten.
• zmcontrol statusmeldet, dass LDAP und die abhängigen Zimbra-Dienste auf dem betroffenen Host ausgeführt werden.
• Der LDAP-Hostname wird vom betroffenen Zimbra-Knoten zur erwarteten Adresse aufgelöst.
• Der konfigurierte LDAP-Port ist erreichbar.
• Wenn TLS involviert ist, wird die Zertifikatskette validiert und der vorherige TLS-Fehler ist behoben.
• In einer Multi-Server-Bereitstellung ldap_urlund ldap_master_urlenthalten gültige, aktive LDAP-Hosts in der vorgesehenen Reihenfolge.
• Nach dem Neustart /var/log/zimbra.logwerden keine wiederkehrenden LDAP-Verbindungsfehler mehr angezeigt.

Wenn eine dieser Prüfungen weiterhin fehlschlägt, sollten Sie die Fehlerbehebung auf dieser Ebene fortsetzen, anstatt den gesamten Zimbra-Stack wiederholt neu zu starten.

Kurzübersicht: Symptome und die nächste Untersuchung

1. Prüfen Sie, ob LDAP selbst ausgefallen ist.

Statusprüfungen als zimbraBenutzer ausführen:

su - zimbra
zmcontrol status
ldap status

Die Dokumentation zur LDAP-Fehlerbehebung von Zimbra empfiehlt, zunächst zu prüfen, ob der slapdProzess tatsächlich ausgeführt wird und anschließend zu bestätigen, dass Zimbra ihn erkennt ldap status. Falls LDAP lokal nicht ausgeführt wird, untersuchen Sie den LDAP-Prozess, bevor Sie Probleme mit Mailbox-, MTA-, Proxy- oder Webdiensten beheben. LDAP ist eine zentrale Konfigurationsabhängigkeit; daher können nachgelagerte Dienste ausfallen, wenn sie die Konfigurationsdaten nicht lesen können.

Referenz: Dokumentation zur Fehlerbehebung bei Zimbra LDAP und Referenz zum Zimbra-Befehl zmcontrol .

2. Überprüfen Sie die LDAP-URLs, bevor Sie die Dienste ändern.

Überprüfen Sie auf dem betroffenen Knoten die lokalen LDAP-Endpunkte:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

In der Dokumentation zu Zimbra 10 für den Multi-Server-Betrieb ldap_urlidentifiziert `<ldap-server>` die LDAP-Server, die ein Knoten abfragen soll, während ldap_master_url`<master-endpoint>` den Master-Endpunkt bzw. die Master-Gruppe für Schreibvorgänge angibt. Zimbra dokumentiert außerdem, dass Replikat-URLs normalerweise vor dem Master in `<master-endpoint>` erscheinen sollten ldap_url, wobei der Master in der Liste erhalten bleibt.

Diese Überprüfung ist besonders wichtig nach einer Servermigration, einem LDAP-Austausch, einer IP-Adressumwandlung, einer Notfallwiederherstellung oder einem Rolling Upgrade. Ein einwandfrei funktionierender LDAP-Server kann einem Zimbra-Knoten, der noch versucht, einen veralteten Hostnamen zu erreichen, nicht helfen.

Namensauflösung und TCP-Erreichbarkeit prüfen

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

Wenn der DNS-Server die falsche Adresse zurückgibt, beheben Sie zuerst die Namensauflösung. Wenn der DNS-Server korrekt ist, der Port aber nicht erreichbar ist, überprüfen Sie das Netzwerk-Routing, die Host-Firewalls, Sicherheitsgruppen oder den Listener des LDAP-Daemons. Ändern Sie LDAP-Passwörter nicht allein aufgrund eines TCP-Verbindungs-Timeouts; ein Timeout tritt auf, bevor die Anmeldeinformationen ausgewertet werden können.

Die aktuelle Zimbra-Anleitung für die Installation auf mehreren Servern (Version 10) schreibt ausdrücklich vor, dass Nicht-LDAP-Knoten während der Konfiguration den LDAP-Master kontaktieren müssen und dass die Installation nicht fortgesetzt werden kann, wenn der Server nicht erreichbar ist. Siehe Zimbra Daffodil v10 Installationsanleitung für die Installation auf mehreren Servern .

3. Lesen Sie das Protokoll, bevor Sie entscheiden, was repariert werden soll.

Verwenden Sie das zentrale Zimbra-Protokoll, um die Fehlerkategorie zu identifizieren:

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

Achten Sie auf ein Muster statt auf eine einzelne Zeile. Häufige Kategorien sind Verbindungstimeout, Verbindungsabbruch, Hostnamenfehler, Bindungsfehler oder TLS-Validierungsfehler. Die Kategorie ist wichtig, da jede eine andere Reparatur erfordert.

• Zeitüberschreitung oder keine Route: Fokus auf DNS, Routing, Firewall oder einen nicht erreichbaren Host.
• Verbindung abgelehnt: Der Host ist erreichbar, aber es werden keine Verbindungen auf dem konfigurierten Port angenommen, oder eine lokale Firewall blockiert diese aktiv.
• TLS/SSL-Validierungsfehler: Zertifikate und Vertrauensketten überprüfen.
• Bei einem Authentifizierungs- oder Bindungsfehler sollten erst dann die LDAP-Passwörter oder die Replikationsdaten überprüft werden.

Wenn Zertifikate das Problem sind

Zimbra hat Fälle dokumentiert, in denen die LDAP-Kommunikation aufgrund eines abgelaufenen Root- oder Zwischenzertifikats fehlschlägt. Ein nützlicher Verifizierungsbefehl für ein kommerzielles Zertifikat lautet:

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

Führen Sie das Skript aus dem Verzeichnis mit den relevanten kommerziellen Zertifikatsdateien aus, üblicherweise unter /opt/zimbra/ssl/zimbra/commercial/. Falls die Validierung fehlschlägt, korrigieren Sie die Zertifikatskette, anstatt die TLS-Verifizierung als Abkürzung zu deaktivieren.

Referenz: Zimbra-Leitfaden für abgelaufene Stammzertifizierungsstellen und LDAP-TLS-Fehler .

4. Korrigieren Sie veraltete LDAP-Endpunkte erst nach Überprüfung des Ersatzes.

Wenn der konfigurierte Hostname veraltet ist und Sie den korrekten aktiven LDAP-Server bereits überprüft haben, aktualisieren Sie die lokale Konfiguration als zimbraBenutzer. Zum Beispiel:

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

Bei einer Bereitstellung mit Replikaten verwenden Sie die für Ihre Umgebung dokumentierte Topologie, anstatt die Liste auf einen Server zu reduzieren. Die Dokumentation von Zimbra v10 enthält Beispiele, in denen Replikate für Lesezugriffe zuerst aufgeführt werden und der Master weiterhin berücksichtigt wird. Umgebungen mit mehreren Mastern haben eigene Anforderungen an die Reihenfolge.

Kopieren Sie diese Beispiel-URLs nicht wörtlich. Prüfen Sie vorher Protokoll, Hostname, Port und die vorgesehene Master-/Replika-Rolle. Wenn Ihre Bereitstellung LDAPS oder StartTLS verwendet, behalten Sie das Sicherheitskonzept bei, anstatt stillschweigend auf reines LDAP umzuschalten, um den Startvorgang zu ermöglichen.

5. Starten Sie das System einmal neu und überprüfen Sie anschließend die gesamte Abhängigkeitskette.

Nachdem die eigentliche Ursache behoben wurde, starten Sie Zimbra neu:

zmcontrol restart

Anschließend überprüfen:

ldap status
zmcontrol status

Ein Neustart, der lediglich die Fehlermeldung ändert, reicht nicht aus. Überprüfen Sie erneut /var/log/zimbra.log, ob die Verbindung wiederholt fehlschlägt, und testen Sie normale administrative oder Benutzeraktionen, die für die Serverrolle relevant sind.

6. In Umgebungen mit mehreren Servern ist eine zusätzliche Replikationsprüfung erforderlich.

Wenn Sie LDAP-Replikate oder mehrere Master-Server betreiben, kann ein Server erreichbar sein, obwohl die Replikation fehlerhaft ist. Zimbra dokumentiert das zmreplchkDienstprogramm zur Replikationsvalidierung:

/opt/zimbra/libexec/zmreplchk

Bei Multi-Master-Systemen beschreibt die Zimbra-Dokumentation ein fehlerfreies Ergebnis als einen synchronisierten Status mit Fehlercode 0. Das genaue Wiederherstellungsverfahren hängt davon ab, ob Sie eine Single-Master-Replikation, eine Multi-Master-Replikation oder eine laufende Migration haben.

Siehe die Anleitung zur Zimbra LDAP Multi-Master-Replikation und die aktuelle Zimbra 10 Multi-Server-Dokumentation .

Wann sollte man die Fehlersucherichtung ändern?

Behandeln Sie dies nicht länger als einfaches Verbindungsproblem, wenn eine der folgenden Bedingungen zutrifft:

• slapdstartet nicht, obwohl Hostname und Portkonfiguration korrekt sind.
• Im Protokoll werden Datenbank-Backend- oder LDAP-Datenspeicherfehler gemeldet, nicht jedoch Netzwerkfehler.
• Die Replikation bleibt auch nach Wiederherstellung der Verbindung asynchron.
• Nach einer Migration unterscheiden sich die Passwörter zwischen LDAP-Mastern und Replikaten.
• Der LDAP-Listener kann keine Bindung herstellen, da der konfigurierte Hostname nicht mehr zum Server gehört.

In diesem Fall kann das Problem eher mit der Wiederherstellung der LDAP-Datenbank, den Replikationsdaten, dem Migrationsstatus oder der Serveridentität zusammenhängen als mit einem einfachen „Server antwortet nicht“. Die Migrationsdokumentation von Zimbra weist ausdrücklich darauf hin, dass DNS-Probleme, Hostnamen-Fehler, falsche Passwörter für die lokale Konfiguration und veraltete Verweise auf alte LDAP-Server den LDAP-Start verhindern können.

Was man nicht tun sollte

• Löschen Sie LDAP-Datenbankdateien nicht als ersten Schritt zur Fehlerbehebung.
• Setzen Sie LDAP-Passwörter erst dann zurück, wenn Sie nachgewiesen haben, dass die Authentifizierung die fehlerhafte Schicht ist.
• Entfernen Sie nicht den Master von jeder LDAP-URL, nur weil eine Replik antwortet.
• Deaktivieren Sie die TLS-Verifizierung nicht einfach, um die Verbindung herzustellen.
• Führen Sie das Skript nicht wiederholt aus, zmcontrol restartohne die resultierenden Protokolle zu lesen.

Checkliste für die abschließende Wiederherstellung

• Der LDAP-Hostname wird zum gewünschten Host aufgelöst.
• Der LDAP-Port ist vom betroffenen Zimbra-Knoten aus erreichbar.
• ldap_urlund ldap_master_urlder aktuellen Topologie entsprechen.
• Die TLS-Zertifikatskette ist gültig, wenn verschlüsseltes LDAP verwendet wird.
• ldap statusBerichte slapdwerden ausgeführt.
• zmcontrol statuszeigt an, dass die erforderlichen Dienste ausgeführt werden.
• Die Replikation erfolgt, sofern anwendbar, synchronisiert.
• /var/log/zimbra.logEs werden keine wiederkehrenden LDAP-Fehler mehr angezeigt.

Die größte Einschränkung dieses Vorgehens besteht darin, dass „LDAP-Server antwortet nicht“ ein Symptom einer Abhängigkeit und nicht die alleinige Ursache ist. Es kann durch einen abgebrochenen LDAP-Prozess, veraltete URLs, fehlerhafte DNS-Auflösungen, blockierte Ports, Zertifikatsfehler, Replikationsprobleme oder falsche Anmeldeinformationen verursacht werden. Daher ist es am sichersten, jede Ebene einzeln zu überprüfen und nur die fehlerhafte Ebene zu ändern.