Résolution du problème « Échec de la connexion au serveur de stockage » de Kopano Dagent

Lorsque Kopano signale « Échec de la connexion au serveur de stockage » lors de la distribution d'un e-mail, cela signifie que l'agent de distribution (dagent) n'a pas pu établir de connexion avec le point de terminaison du serveur Kopano qui lui a été attribué. Ce message ne permet pas à lui seul d'identifier la cause du problème : serveur arrêté, chemin d'accès incorrect, problèmes d'autorisations d'accès ou problème de connexion distante. Commencez par vérifier le point de terminaison configuré et le serveur lui-même ; évitez de modifier les données de la boîte aux lettres ou le stockage des pièces jointes pendant le diagnostic de l'échec de connexion.

La documentation d'administration de Kopano décrit dagent comme le composant assurant la distribution des courriers électroniques depuis l'agent de transport de courrier (MTA) vers un utilisateur Kopano. La documentation de configuration de Kopano Core 8.0 indique que server_socketdagent spécifie la connexion au serveur Kopano et la documentation file:///var/run/kopano/server.sockcomme configuration par défaut. Les versions des paquets, les gestionnaires de services et la configuration locale pouvant varier, il est conseillé de vérifier les valeurs sur votre système avant d'appliquer un exemple.

Que devez-vous vérifier en premier ?

Vérifiez si l'erreur affecte tous les destinataires ou seulement un chemin de livraison. Si toutes les livraisons entrantes échouent simultanément, vérifiez la disponibilité du serveur et le point de terminaison. Si seuls les messages acheminés via un hôte ou un nœud échouent, comparez le dagent.cfgchemin réseau et le comportement de ce nœud avec ceux d'un nœud fonctionnel. Conservez un message ou une entrée de file d'attente ayant échoué pendant les tests ; des tentatives répétées peuvent masquer le premier horodatage utile dans les journaux.

Sur un système utilisant systemd, examinez les unités Kopano et le journal du serveur aux alentours de l'heure de livraison :

systemctl list-units 'kopano*'
systemctl status kopano-server --no-pager
journalctl -u kopano-server -b --no-pager

Si votre package nomme l'unité différemment, utilisez le nom affiché list-units. Un serveur inactif ou redémarrant fréquemment indique un problème côté serveur. Consultez son journal pour identifier une erreur de démarrage, de base de données, de configuration ou de stockage antérieure ; le redémarrage de dagent ne résoudra pas un serveur Kopano indisponible. Le manuel d'administration décrit la gestion du service Kopano, mais les noms d'unités exacts dépendent du package.

Est-ce que dagent pointe vers le bon socket serveur ?

Lisez le fichier de configuration actif, généralement /etc/kopano/dagent.cfg, et recherchez l' server_socketentrée :

grep -nE '^[[:space:]]*server_socket[[:space:]]*=' /etc/kopano/dagent.cfg

Pour un socket Unix local, comparez la configuration avec le socket réellement créé par le serveur en cours d'exécution. Une valeur courante dans la documentation de Kopano Core est :

server_socket = file:///var/run/kopano/server.sock

Vérifiez que le fichier existe et qu'il s'agit d'un socket :

ls -l /var/run/kopano/server.sock
test -S /var/run/kopano/server.sock && echo "Socket exists"

Si les chemins configurés et réels diffèrent, corrigez la server_socketvaleur pour qu'elle corresponde au point de terminaison utilisé par votre installation. Ne copiez pas la valeur par défaut sans la modifier si le serveur est configuré pour utiliser un autre répertoire d'exécution, une adresse de cluster ou un protocole de transport distant. La documentation de Kopano détaille également les paramètres des clés SSL pour les transports HTTPS ; la syntaxe du point de terminaison distant et les exigences relatives aux certificats doivent correspondre à la configuration de votre serveur.

Les permissions du socket peuvent-elles bloquer la connexion ?

Oui. Un socket peut exister tout en restant inaccessible à l'utilisateur exécutant dagent. Identifiez l'utilisateur du processus effectif dans l'unité de service ou le processus concerné, puis examinez le socket et tous ses répertoires parents. Par exemple :

namei -l /var/run/kopano/server.sock
stat -c '%A %U:%G %n' /var/run/kopano/server.sock

Comparez les permissions du propriétaire, du groupe et de la navigation dans les répertoires avec l'identité d'exécution de dagent. La documentation de configuration de dagent Kopano indique que l'utilisateur et le groupe d'exécution peuvent être configurés, Kopano étant la valeur par défaut documentée ; le packaging ou les substitutions peuvent modifier cela. Si systemd est utilisé, vérifiez l'unité et les éventuelles substitutions avant de modifier le propriétaire.

systemctl cat kopano-dagent
systemctl show kopano-dagent -p User -p Group

Modifiez les permissions uniquement pour accorder au compte de service concerné l'accès nécessaire. N'utilisez pas cette méthode chmod 777sur le socket ou son répertoire : cela pourrait exposer un point de terminaison de service privilégié à des utilisateurs locaux non autorisés. Les répertoires d'exécution peuvent être recréés au démarrage ; il est donc préférable de corriger la configuration du service ou du paquet qui les crée plutôt que de se fier à une modification manuelle temporaire des permissions.

Que se passe-t-il si le serveur se trouve sur un autre nœud ?

Dans une configuration multi-serveurs ou à haute disponibilité, vérifiez que dagent utilise l'adresse du cluster ou du serveur accessible pour son nœud. Le guide de haute disponibilité de Kopano indique que les points de terminaison de service et le routage de distribution Postfix doivent être coordonnés entre les nœuds. Comparez server_socketl'écouteur du serveur, l'adresse DNS ou du cluster, les règles de pare-feu et les paramètres TLS des deux côtés. Une connexion réussie à un socket local sur un nœud ne garantit pas qu'un point de terminaison distant soit accessible depuis un autre nœud.

Testez la connectivité en utilisant le même point de terminaison et le même chemin réseau que ceux configurés pour dagent. Pour un transport distant, vérifiez l'état du listener et la politique de pare-feu sur l'hôte Kopano, puis consultez les journaux de dagent et du serveur pour détecter les refus de connexion, les délais d'attente ou les erreurs TLS. N'ouvrez pas un listener à Internet pour simplifier le dépannage ; limitez l'accès aux hôtes de messagerie et d'applications de confiance.

Comment tester la livraison sans modifier le flux de courrier en production ?

Une fois le serveur actif et les autorisations du point de terminaison validées, effectuez un test contrôlé à l'aide d'une boîte mail de test dédiée. Le manuel d'administration de Kopano explique comment lancer dagent directement avec un utilisateur sur ce nœud, puis saisir un sujet et un corps de message. Voici un exemple de test :

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]

Remplacez testusercet utilisateur par un utilisateur Kopano local existant et respectez la syntaxe des commandes de votre version installée. Ce test contourne certaines fonctionnalités de routage et de gestion des files d'attente des MTA ; une livraison directe réussie confirme une partie utile du chemin, mais ne prouve pas que Postfix ou un autre MTA achemine correctement le courrier. Consultez la sortie de dagent, les journaux de Kopano et la boîte aux lettres de test avant de réessayer avec les messages de production en file d'attente.

Quand faut-il redémarrer un service ?

Redémarrez uniquement le composant dont la configuration a été modifiée, et seulement après avoir enregistré une copie de sauvegarde de sa configuration. Si vous avez modifié des paramètres dagent.cfg, redémarrez l'unité dagent lorsque votre installation exécute dagent en tant que service persistant. Certaines installations lancent dagent pour chaque livraison, il se peut donc qu'aucune unité dagent ne soit exécutée en continu et ne nécessite un redémarrage. Si vous avez modifié server.cfgdes paramètres ou les paramètres d'écoute du serveur, suivez plutôt la procédure de modification de votre site pour Kopano Server. La documentation de référence de dagent ne documente que certaines options pouvant être rechargées par HUP ; ne présumez pas que toute modification de socket ou d'identité d'exécution est prise en compte par un signal.

Comment confirmer la correction ?

Veuillez confirmer les points suivants avant de clore l'incident :

• Le serveur Kopano reste actif sans aucune nouvelle erreur de connexion dans son journal.
• Le point de terminaison configuré dans dagent correspond à un socket actif ou à un écouteur distant prévu.
• L'utilisateur du runtime dagent peut parcourir les répertoires parents du socket et accéder au point de terminaison.
• Un message de test contrôlé parvient à la boîte aux lettres prévue, et ses journaux ne montrent aucune défaillance de connexion au serveur de stockage.
• Un nouveau message entrant envoyé via la voie MTA normale est accepté et distribué ; la file d'attente MTA ne continue pas à accumuler la même erreur.

Si la distribution directe fonctionne mais que l'envoi de courrier via le MTA échoue toujours, examinez le protocole LMTP, le chemin du socket et le routage du MTA plutôt que de modifier le stockage de la boîte aux lettres Kopano. Si le serveur et le point de terminaison sont corrects mais que dagent signale toujours une erreur de connexion, collectez les horodatages correspondants, la server_socketvaleur anonymisée, l'état du service et les journaux pertinents pour votre responsable de paquet ou l'administrateur Kopano. Masquez les mots de passe, les clés privées, le contenu des messages et les adresses personnelles avant de partager les diagnostics.

Références : Manuel de l'administrateur principal de Kopano ; Référence de configuration de l'agent de données Kopano ; Guide de haute disponibilité de Kopano ; Configurations spéciales et dépannage de Kopano .