Question La connexion de Dovecot (avec Postfix) a une connexion refusée lors de l'accès à auth-userdb


... c'était difficile à décrire dans un titre. Cette description devrait mettre en évidence le problème.

Le contexte

  • Je suivais le Workaround.org Didacticiel installer une pile, pigeonnier (avec quelques plugins supplémentaires).
  • Exécution sur une machine Ubuntu 12.04 (VM avec Vagrant / Chef)
  • Dovecot v2.0.19
  • Postfix v2.9.6

Conf. Des dossiers

10-master

....
service auth {    
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail
}
...

Edit - informations de configuration supplémentaires (quelques chevauchements)

service auth {
# auth_socket_path points to this userdb socket by default. It's typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone's userdb lookups.
unix_listener auth-userdb {
  mode = 0644
  user = vmail
  group = vmail
}

# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
  mode = 0660
  user = postfix
  group = postfix
}

# Auth process is run as this user.
#user = $default_internal_user
user = dovecot
}

auth-sql

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%d/%n allow_all_users=yes
}

ls -la / var / run / pigeonnier / auth-userdb

srw-r--r-- 1 vmail vmail 0 Jun 20 13:04 /var/run/dovecot/auth-userdb

Postfix master.cf

dovecot    unix  -      n       n       -       -       pipe
   flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -d ${recipient}

Problème

J'ai suivi le tutoriel de très près, ne modifiant que quelques petites choses. Je suis arrivé au "Test de livraison du courrier" et a couru echo test | mail test@chefdovecot.com

Le courrier n'est pas arrivé depuis find /var/vmail n'a rien montré.

Dans le syslog du serveur, les erreurs suivantes sont présentes:

postfix/pickup[16842]: 019023A06AB: uid=1000 from=<vagrant>
postfix/cleanup[19542]: 019023A06AB: message-id=   <20130620140358.019023A06AB@mail-server-berkshelf>
postfix/qmgr[16843]: 019023A06AB: from=<vagrant@mail-server-berkshelf.localdomain>, size=382, nrcpt=1 (queue active)
dovecot: lda: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: lda: Debug: Module loaded: /usr/lib/dovecot/modules/lib90_sieve_plugin.so
dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Connection refused
dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
postfix/pipe[19545]: 019023A06AB: to=<test@chefdovecot.com>, relay=dovecot, delay=1.2, delays=0.04/0.01/0/1.1, dsn=4.3.0, status=deferred (temporary failure)

L'erreur "connexion refusée" devrait être l'erreur que j'attaque, non? J'ai cherché dans de nombreux endroits pour comprendre ce qui se passe ici, mais je n'ai rien trouvé d'utile.

Quelqu'un peut-il fournir des pistes ou des idées? Une solution serait géniale, mais je suis heureux d’accepter de nouvelles idées à essayer.


5
2018-06-20 14:07


origine


J'ai toujours utilisé postfix ou dovecot en tant qu'utilisateur pour le authdb fichier.. - NickW
Une erreur "Connexion refusée" peut-elle avoir un lien avec la personne sur laquelle j'exécute les processus? Je m'attendrais à ce que ce soit une erreur d'autorisation de fichier ou telle. D'après le message d'erreur, il semble qu'une connexion tente effectivement d'être établie, mais qu'elle soit rejetée. - Adam
Ouais, cela pourrait être quelque chose "sous" le fichier présenté, si vous utilisez SQL, pouvez-vous voir une connexion essayée? Il est dit de regarder dans le journal de pigeonnier pour plus de détails cependant, y en a-t-il? - NickW
J'utilise SQL. La requête via auth-userdb (qui, je suppose, consiste à interroger le mot de passe et à s’authentifier), ne parvient jamais à MySQL. Les requêtes Postfix relatives au domaine, à l'utilisateur et à la destination passent toutes (ceci bien sûr avant l'erreur auth-userdb). J'ai changé les autorisations en 777 pour éliminer la possibilité de simples autorisations de fichiers, et cela n'a pas aidé. Avez-vous des idées sur la façon de découvrir certains des rouages ​​"sous-jacents"? De plus, le pigeonnier se connecte à syslog, l’extrait ci-dessus est un mélange de msg de journal pigeonnier et postfix. - Adam
Ceci est la partie LDA, comment avez-vous configuré cela dans votre master.cf? - NickW


Réponses:


L'erreur de connexion refusée est en effet le problème. La connexion refusée sur les sockets unix n’est pas très intuitive, mais elle indique qu’il n’ya rien d’écoute sur la socket (en général, le processus est mort ou le fichier indiqué comme adresse n’est pas du tout une socket). Cela ne devrait jamais être un problème d'autorisations, sauf si dovecot est incapable d'ouvrir le socket pour l'écoute en raison d'autorisations.

Essayez d'arrêter dovecot et postfix, en supprimant le fichier de socket à /var/run/dovecot/auth-userdb, et relancer postfix et dovecot (en s’assurant que le dovecot de l’utilisateur est en cours d’exécution avec les autorisations nécessaires). /var/run/dovecot). Habituellement, cela résoudra ce type de problème.

Netstat affichera également les sockets de domaine unix. Vérifiez sa sortie (utilisez netstat -nvlap | less et recherchez le chemin ou le pigeonnier) pour vous assurer que le pigeonnier est à l’écoute.


2
2018-06-24 08:22



Lorsque vous dites "supprimer le fichier de socket", vous ne voulez pas dire rm -f droite? Je suppose que vous voulez dire du fichier de configuration? Pourriez-vous clarifier cette partie un peu? - Adam
Je veux dire absolument supprimer le fichier de socket en utilisant rm. Lorsque vous ouvrez un nouveau socket d’écoute, le fichier sera créé s’il n’existe pas. le supprimer, démarrer le processus qui l'écoute (afin qu'il soit créé) et le processus qui s'y connecte doivent garantir la cohérence. - Falcon Momot
A bien fonctionné. Merci pour votre contribution, je n'avais pas les connaissances nécessaires pour essayer quelque chose comme ça. - Adam
Cette solution fonctionne également bien dans le cas où la connexion de socket ne répondait plus après une panne de sockets sur un VPS (limite OpenVZ "numothersock"). Le message d'erreur exact est alors dovecot: lda: Error: userdb lookup(mail@example.com): Request timed out. - tanius