[Dovecot] Passdb disconnected unexpectedly when trying to do Director with LMTP
Hi there,
I'm running Dovecot 2.0.16 just set up the director with cut&paste from the wiki. It's working & running fine for pop/imap connections (as verified by doveadm director status user), however when I specify 'RCPT TO' for a (tcp) lmtp connection straight away I get:
451 4.3.0 <xxx@yyy.com> Temporary user lookup failure
and in the logs: 2012-02-11T14:22:54+00:00 xxx dovecot: lmtp(27997): Error: passdb lookup(xxx@yyy.com): Disconnected unexpectedly
I'm sure this is an obvious issue for someone who's come across it before. The /var/run/dovecot/director-userdb socket is on the system; exactly the same permissions as the standard auth-userdb
Here are the relevant bits of my config (I'm setting lmtp to listen on a different port than normal). Backend password database is mysql if that makes any difference.
lmtp_proxy = yes
service lmtp { inet_listener lmtp_test { port = 2450 } } protocol lmtp { auth_socket_path = director-userdb }
Thanks,
Mark
On 11.2.2012, at 16.33, Mark Zealey wrote:
I'm running Dovecot 2.0.16 just set up the director with cut&paste from the wiki. It's working & running fine for pop/imap connections (as verified by doveadm director status user), however when I specify 'RCPT TO' for a (tcp) lmtp connection straight away I get:
451 4.3.0 <xxx@yyy.com> Temporary user lookup failure
and in the logs: 2012-02-11T14:22:54+00:00 xxx dovecot: lmtp(27997): Error: passdb lookup(xxx@yyy.com): Disconnected unexpectedly
Aren't there any other errors logged? I think there should be some error logged from either auth or director process.
Although director is missing one error, but auth should have also logged an error in that case. Anyway, fixed by http://hg.dovecot.org/dovecot-2.1/rev/9b70d164e974
Ah I should have checked this before - line before:
2012-02-11T14:22:54+00:00 xx dovecot: director: Error: connect(/var/run/dovecot//auth-userdb) failed: Permission denied
This is because the director is running as user dovecot; but that file is owned root.root permissions 0600. What would you suggest doing? Setting that socket 0660 is the obvious solution but perhaps there is a more secure way you would recommend eg chown dovecot? I'm guessing this would also need updating in the documentation as afaik our setup should be pretty standard. Only other relevant piece of config:
service auth { user = dovecot client_limit = 15000 }
Also (perhaps this should be a new thread) but I'm not too sure the director service would work for us. I was doing some testing yesterday & discovered that when I restart a dovecot instance it doesn't have any persistence (eg resync the lookup table with the other directors or do a save/restore from disk) so you are basically starting from scratch again which would be very bad in our setup.
Mark
On 12.2.2012, at 10.23, Mark Zealey wrote:
Ah I should have checked this before - line before:
2012-02-11T14:22:54+00:00 xx dovecot: director: Error: connect(/var/run/dovecot//auth-userdb) failed: Permission denied
This is because the director is running as user dovecot; but that file is owned root.root permissions 0600. What would you suggest doing? Setting that socket 0660 is the obvious solution but perhaps there is a more secure way you would recommend eg chown dovecot? I'm guessing this would also need updating in the documentation as afaik our setup should be pretty standard.
Yeah, the auth-userdb socket default permissions aren't usable pretty much anywhere. In v2.1 it's better, but still not as good as they could be. I'm not sure what the best solution for this is.
Also (perhaps this should be a new thread) but I'm not too sure the director service would work for us. I was doing some testing yesterday & discovered that when I restart a dovecot instance it doesn't have any persistence (eg resync the lookup table with the other directors or do a save/restore from disk) so you are basically starting from scratch again which would be very bad in our setup.
You mean if you restart one director some of the state is lost in all of them? I think v2.0 had some bugs related to this, but they should be fixed in v2.1.
If you mean that if you stop all of the directors and state is lost when restarting then yes, that does happen. You can run "doveadm director dump" to get the current state and after a restart run its output to get back to the same state.
What state specifically are you talking about anyway?
participants (3)
-
Mark Zealey
-
Mark Zealey
-
Timo Sirainen