Wenn Kopano während der E-Mail-Zustellung die Meldung „Verbindung zum Speicherserver fehlgeschlagen“ meldet , konnte der Zustellungsagent (dagent) keine Verbindung zum angegebenen Kopano-Server-Endpunkt herstellen. Die Meldung allein gibt nicht an, ob die Ursache ein angehaltener Server, ein falscher Socket-Pfad, fehlende Zugriffsrechte oder ein Problem mit der Remote-Verbindung ist. Überprüfen Sie zunächst den konfigurierten Endpunkt und den Server selbst. Vermeiden Sie Änderungen an Postfachdaten oder dem Speicher von Anhängen, während Sie den Verbindungsfehler diagnostizieren.
Die Administratordokumentation von Kopano beschreibt dagent als die Komponente, die E-Mails vom Mail Transport Agent (MTA) an einen Kopano-Benutzer zustellt. Die Konfigurationsreferenz von Kopano Core 8.0 legt server_socketdie Verbindung zum Kopano-Server fest und dokumentiert file:///var/run/kopano/server.sockdiese als Standardeinstellung. Paketversionen, Service Manager und lokale Konfigurationen können abweichen. Überprüfen Sie daher die Werte auf Ihrem Host, bevor Sie ein Beispiel anwenden.
Was sollten Sie zuerst überprüfen?
Prüfen Sie, ob der Fehler alle Empfänger oder nur einen Zustellungspfad betrifft. Falls alle eingehenden Zustellungen gleichzeitig fehlschlagen, prüfen Sie die Serververfügbarkeit und den Endpunkt. Falls nur Nachrichten, die über einen bestimmten Host oder Knoten geleitet werden, fehlschlagen, vergleichen Sie den dagent.cfgNetzwerkpfad dieses Knotens mit dem eines funktionierenden Knotens. Speichern Sie während des Tests eine fehlgeschlagene Nachricht oder einen Warteschlangeneintrag; wiederholte Versuche können den ersten relevanten Zeitstempel in den Protokollen verdecken.
Auf einem System, das systemd verwendet, sollten Sie die Kopano-Einheiten und das Serverprotokoll um den Zeitpunkt der Zustellung herum überprüfen:
systemctl list-units 'kopano*'
systemctl status kopano-server --no-pager
journalctl -u kopano-server -b --no-pager
Wenn Ihr Paket die Einheit anders benennt, verwenden Sie den angezeigten Namen list-units. Ein inaktiver oder wiederholt neu startender Server deutet auf ein serverseitiges Problem hin. Lesen Sie das Serverprotokoll auf frühere Start-, Datenbank-, Konfigurations- oder Speicherfehler. Ein Neustart von dagent behebt einen nicht verfügbaren Kopano-Server nicht. Das Administratorhandbuch beschreibt die Kopano-Dienstverwaltung, die genauen Einheitsnamen hängen jedoch vom jeweiligen Paket ab.
Zeigt dagent auf den richtigen Server-Socket?
Lesen Sie die aktive Konfigurationsdatei, üblicherweise /etc/kopano/dagent.cfg, und suchen Sie den server_socketEintrag:
grep -nE '^[[:space:]]*server_socket[[:space:]]*=' /etc/kopano/dagent.cfg
Vergleichen Sie bei einem lokalen Unix-Socket die Einstellung mit dem Socket, der tatsächlich vom laufenden Server erstellt wird. Ein häufig in der Kopano Core-Dokumentation angegebener Wert ist:
server_socket = file:///var/run/kopano/server.sock
Prüfen Sie, ob die Datei existiert und ein Socket ist:
ls -l /var/run/kopano/server.sock
test -S /var/run/kopano/server.sock && echo "Socket exists"
Wenn die konfigurierten und tatsächlichen Pfade voneinander abweichen, korrigieren Sie den server_socketWert auf den von Ihrer Installation beabsichtigten Endpunkt. Kopieren Sie den Standardwert nicht einfach, wenn der Server für die Verwendung eines anderen Laufzeitverzeichnisses, einer Clusteradresse oder eines Remote-Transports konfiguriert ist. Die Kopano-Referenz beschreibt auch die SSL-Schlüsseleinstellungen für HTTPS-Transporte; die Syntax des Remote-Endpunkts und die Zertifikatsanforderungen müssen mit Ihrer installierten Serverkonfiguration übereinstimmen.
Könnten Socket-Berechtigungen die Verbindung blockieren?
Ja. Ein Socket kann existieren und dennoch für den Benutzer, der dagent ausführt, nicht zugänglich sein. Ermitteln Sie den effektiven Prozessbenutzer anhand der entsprechenden Serviceeinheit oder des entsprechenden Prozesses und untersuchen Sie anschließend den Socket und jedes übergeordnete Verzeichnis. Zum Beispiel:
namei -l /var/run/kopano/server.sock
stat -c '%A %U:%G %n' /var/run/kopano/server.sock
Vergleichen Sie die Berechtigungen für Eigentümer, Gruppe und Verzeichnisnavigation mit der Laufzeitidentität von dagent. Die Kopano-dagent-Konfigurationsreferenz weist darauf hin, dass der Ausführungsbenutzer und die Gruppe konfiguriert werden können, wobei Kopano als dokumentierter Standardwert festgelegt ist; Paketierung oder Überschreibungen können dies ändern. Wenn systemd verwendet wird, überprüfen Sie die Unit und alle Überschreibungen, bevor Sie die Eigentümerschaft ändern.
systemctl cat kopano-dagent
systemctl show kopano-dagent -p User -p Group
Passen Sie die Berechtigungen nur so an, dass das gewünschte Dienstkonto die benötigten Zugriffsrechte erhält. Verwenden Sie diese Berechtigung nicht chmod 777für den Socket oder dessen Verzeichnis, da dies einen privilegierten Dienstendpunkt für nicht autorisierte lokale Benutzer zugänglich machen kann. Laufzeitverzeichnisse werden möglicherweise beim Systemstart neu erstellt. Korrigieren Sie daher die Dienst- oder Paketkonfiguration, die diese Verzeichnisse erstellt, anstatt sich auf eine temporäre manuelle Berechtigungsänderung zu verlassen.
Was passiert, wenn sich der Server auf einem anderen Knoten befindet?
In einer Umgebung mit mehreren Servern oder Hochverfügbarkeit überprüfen Sie, ob dagent die erreichbare Cluster- oder Serveradresse für seinen Knoten verwendet. Der Kopano-Leitfaden für Hochverfügbarkeit zeigt, dass Service-Endpunkte und das Postfix-Routing knotenübergreifend koordiniert werden müssen. Vergleichen Sie server_socketdie Server-Listener-, DNS- oder Clusteradresse, Firewall-Regeln und alle TLS-Einstellungen auf beiden Seiten. Eine erfolgreiche Verbindung zu einem lokalen Socket auf einem Knoten beweist nicht, dass ein Remote-Endpunkt von einem anderen Knoten aus erreichbar ist.
Testen Sie die Konnektivität mit demselben Endpunkt und Netzwerkpfad, der für dagent konfiguriert ist. Prüfen Sie bei einer Remote-Verbindung den Listener-Status und die Firewall-Richtlinie auf dem Kopano-Host und untersuchen Sie anschließend die dagent- und Serverprotokolle auf Verbindungsabbrüche, Timeouts oder TLS-Fehler. Öffnen Sie den Listener nicht pauschal im Internet, um die Fehlerbehebung zu vereinfachen; beschränken Sie den Zugriff auf vertrauenswürdige Mail- und Anwendungshosts.
Wie kann man die Zustellung testen, ohne den produktiven E-Mail-Ablauf zu verändern?
Nachdem der Server aktiv ist und Endpunkt und Berechtigungen übereinstimmen, führen Sie einen kontrollierten Test mit einem dafür vorgesehenen Testpostfach durch. Das Kopano-Administratorhandbuch beschreibt, wie Sie dagent direkt mit einem Benutzer auf diesem Knoten aufrufen und anschließend Betreff und Nachrichtentext eingeben. Ein typisches Testmuster ist:
kopano-dagent -v -c /etc/kopano/dagent.cfg testuser
Subject: Kopano connection test
This is a controlled delivery test.
[Press Ctrl-D to finish input]
Ersetzen Sie den Platzhalter testuserdurch einen vorhandenen lokalen Kopano-Benutzer und verwenden Sie die Befehlssyntax Ihrer installierten Version. Dieser Test umgeht bestimmte Routing- und Warteschlangenfunktionen des MTA. Eine erfolgreiche Direktzustellung bestätigt einen wichtigen Teil des Pfades, beweist aber nicht, dass Postfix oder ein anderer MTA E-Mails korrekt weiterleitet. Überprüfen Sie die Ausgabe von dagent, die Kopano-Protokolle und das Testpostfach, bevor Sie die Zustellung von in der Warteschlange befindlichen Produktionsnachrichten erneut versuchen.
Wann sollte man einen Dienst neu starten?
Starten Sie nur die Komponente neu, deren Konfiguration sich geändert hat, und zwar erst, nachdem Sie eine funktionierende Kopie ihrer Konfiguration gespeichert haben. Wenn Sie Änderungen vorgenommen haben dagent.cfg, starten Sie die dagent-Einheit neu, falls Ihre Installation dagent als permanenten Dienst ausführt. Bei manchen Installationen wird dagent für einzelne Lieferungen gestartet, sodass möglicherweise keine dauerhaft laufende dagent-Einheit neu gestartet werden muss. Wenn Sie server.cfgEinstellungen für Server-Listener geändert haben, befolgen Sie stattdessen die Änderungsprozedur Ihrer Website für Kopano Server. Die dagent-Referenzdokumente beschreiben nur ausgewählte Optionen, die von HUP neu geladen werden können; gehen Sie nicht davon aus, dass jede Socket- oder Laufzeitidentitätsänderung durch ein Signal wirksam wird.
Wie kann man die erfolgreiche Fehlerbehebung bestätigen?
Bitte bestätigen Sie vor dem Schließen des Vorfalls alle folgenden Punkte:
- Der Kopano-Server ist weiterhin aktiv und es sind keine neuen Verbindungsfehler in seinem Protokoll verzeichnet.
- Der in dagent konfigurierte Endpunkt entspricht einem aktiven Socket oder einem vorgesehenen Remote-Listener.
- Der dagent-Laufzeitbenutzer kann die übergeordneten Verzeichnisse des Sockets durchlaufen und auf den Endpunkt zugreifen.
- Eine kontrollierte Testnachricht erreicht das vorgesehene Postfach, und in den Protokollen wird kein Verbindungsfehler zum Speicherserver angezeigt.
- Eine neue eingehende Nachricht, die über den normalen MTA-Weg gesendet wird, wird angenommen und zugestellt; die MTA-Warteschlange sammelt nicht weiterhin denselben Fehler an.
Wenn die direkte Zustellung funktioniert, E-Mails über den MTA aber weiterhin fehlschlagen, untersuchen Sie den LMTP-Transport, den Socket-Pfad und das Routing des MTA, anstatt den Kopano-Mailbox-Speicher zu ändern. Falls Server und Endpunkt in Ordnung sind, dagent aber weiterhin einen Verbindungsfehler meldet, sammeln Sie übereinstimmende Zeitstempel, den bereinigten server_socketWert, den Dienststatus und relevante Protokolle für Ihren Paketbetreuer oder Kopano-Administrator. Schwärzen Sie Passwörter, private Schlüssel, Nachrichteninhalte und persönliche Adressen, bevor Sie die Diagnosedaten weitergeben.
Referenzen: Kopano Core Administrator Manual ; Kopano dagent configuration reference ; Kopano high-availability guide ; Kopano special configurations and troubleshooting .