[Dovecot] 'doveadm who' enhancement request
When Dovecot is in proxy mode, the client sends along the original connection endpoints in an ID command. Is there any chance 'doveadm who' could use this to display the original connection source? As it currently stands, all I see is a bunch of connections from the proxy.
Thanks!
Brandon 'Brad' Davidson Virtualization Systems Administrator University of Oregon Information Services (541) 346-8098 brandond@uoregon.edu
On 2.6.2010, at 23.34, Brad Davidson wrote:
When Dovecot is in proxy mode, the client sends along the original connection endpoints in an ID command. Is there any chance 'doveadm who' could use this to display the original connection source? As it currently stands, all I see is a bunch of connections from the proxy.
If login_trusted_networks contains proxies, I think it should already do that?..
Timo,
Is there any chance 'doveadm who' could use this to display the original connection source?
If login_trusted_networks contains proxies, I think it should already do that?..
Interesting. I'd tried putting the private network in login_trusted_networks but it got stuck in a loop until the director process ran out of file handles, so I took it back out. This is probably a little weird in that it's proxying to itself, and also trusting the looped connection. I guess it's running the original endpoints through the authdb for validation, which then proxies, causes another authdb lookup, etc?
/etc/dovecot/dovecot.conf: director_servers = 10.142.0.162 director_mail_servers = 10.142.0.162 login_trusted_networks = 10.142.0.0/24 passdb { driver = sql args = /etc/dovecot/proxy-sqlite.conf } passdb { driver = pam } userdb { driver = passwd }
/etc/dovecot/proxy-sqlite.conf: driver = sqlite connect = /dev/null password_query = SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '%{lip}' NOT LIKE '10.142.0.%%' AND '%{lip}' != '%{rip}'
The verbose auth look during the loop looked like:
(lots more of the following omitted) Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: new auth connection: pid=19120 Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client in: AUTH 1 PLAIN service=imap secured lip=128.223.142.138 rip=128.223.157.45 lport=993 rport=60872 resp=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client out: OK 1 user=brandond proxy pass=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: sql(brandond,128.223.157.45): query: SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '128.223.142.138' NOT LIKE '10.142.0.%' AND '128.223.142.138' != '128.223.157.45' Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: new auth connection: pid=19121 Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client in: AUTH 1 PLAIN service=imap secured lip=128.223.142.138 rip=128.223.157.45 lport=993 rport=60872 resp=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client out: OK 1 user=brandond proxy pass=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: sql(brandond,128.223.157.45): query: SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '128.223.142.138' NOT LIKE '10.142.0.%' AND '128.223.142.138' != '128.223.157.45' Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client in: AUTH 1 PLAIN service=imap secured lip=128.223.142.138 rip=128.223.157.45 lport=993 rport=60872 resp=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client out: OK 1 user=brandond proxy pass=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: sql(brandond,128.223.157.45): query: SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '128.223.142.138' NOT LIKE '10.142.0.%' AND '128.223.142.138' != '128.223.157.45' Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: new auth connection: pid=19123 Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: new auth connection: pid=19124 Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: socket(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: connect(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client in: AUTH 1 PLAIN service=imap secured lip=128.223.142.138 rip=128.223.157.45 lport=993 rport=60872 resp=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: socket(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: connect(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: client out: OK 1 user=brandond proxy pass=<hidden> Jun 2 13:48:58 cc-popmap7 dovecot: auth: Debug: sql(brandond,128.223.157.45): query: SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '128.223.142.138' NOT LIKE '10.142.0.%' AND '128.223.142.138' != '128.223.157.45' Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: socket(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: director: Error: connect(/var/run/dovecot//auth-login) failed: Too many open files Jun 2 13:48:58 cc-popmap7 dovecot: imap-login: Warning: Error sending handshake to auth server: Broken pipe
-Brad
On 3.6.2010, at 1.20, Brad Davidson wrote:
Interesting. I'd tried putting the private network in login_trusted_networks but it got stuck in a loop until the director process ran out of file handles, so I took it back out. This is probably a little weird in that it's proxying to itself, and also trusting the looped connection. I guess it's running the original endpoints through the authdb for validation, which then proxies, causes another authdb lookup, etc? .. password_query = SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '%{lip}' NOT LIKE '10.142.0.%%' AND '%{lip}' != '%{rip}'
This query no longer works, because both lip and rip are replaced with the original ones from proxy..
-----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] ..
password_query = SELECT null AS password, 'Y' AS nopassword, 'Y' AS proxy WHERE '%{lip}' NOT LIKE '10.142.0.%%' AND '%{lip}' != '%{rip}'
This query no longer works, because both lip and rip are replaced with the original ones from proxy..
Ah, OK. The looping was unexpected though, as it has in the past complained "Proxying loops to itself", but I guess that check fails as well due to the aforementioned lip/rip replacement. I'll stick with untrusted for now then, and just live with some extra SSL overhead and doveadmin not showing the proxied endpoint. Maybe someday if you feel like adding proxy_maybe to the director it'll work right.
I know I'm trying to shoehorn the director into an infrastructure it's not really meant for. A better choice would probably be to bring a new dedicated director online in either location, and put those behind the load balancer. I wonder if they can stand up to 10k+ concurrent proxied connections though?
-Brad
On 3.6.2010, at 1.46, Brad Davidson wrote:
I know I'm trying to shoehorn the director into an infrastructure it's not really meant for. A better choice would probably be to bring a new dedicated director online in either location, and put those behind the load balancer. I wonder if they can stand up to 10k+ concurrent proxied connections though?
I'd think so.
Also another thought :) I guess you have now two login services for imap and pop3, one for proxy and one for backend? You could do the same for auth processes and override the other one's settings. Something like:
# disable default auth process for proxy lookups service auth { executable = auth -o passdb/proxy/args=ignore.conf unix_listener auth-login { mode = 0 } }
service auth-proxy { unix_listener auth-login { user = dovecot mode = 0600 } }
For the -o setting override to work, you need to name the passdb:
passdb proxy { driver = sql args = .. }
The ignore.conf would contain sql query that always returns 0 rows, so that it continues to pam.
On 6/2/10 7:33 PM, "Timo Sirainen" <tss@iki.fi> wrote:
I wonder if they can stand up to 10k+ concurrent proxied connections though?
I'd think so.
I could probably give that a try, but I'll have a hard time convincing folks to do that until after 2.0 has out of beta for a bit. Maybe after summer term then... October or so? I can certainly start testing it in advance of that though.
Also another thought :) I guess you have now two login services for imap and pop3, one for proxy and one for backend?
No, just the one for each right now. I haven't figured out how to do that yet ;) Just multiple imap-login/pop3-login blocks with different inet_listener addresses?
You could do the same for auth processes and override the other one's settings. Something like:
# disable default auth process for proxy lookups service auth { executable = auth -o passdb/proxy/args=ignore.conf unix_listener auth-login { mode = 0 } }
service auth-proxy { unix_listener auth-login { user = dovecot mode = 0600 } }
How do I tell different login services to use different auth backends? Is it the first argument to the login process executable? So like:
service imap-login { executable = imap-login auth-proxy inet_listener imaps { address = 1.2.3.4 } }
I'm still trying to grok what all the different config bits mean and imply.
-Brad
On ke, 2010-06-02 at 21:44 -0700, Brandon Davidson wrote:
Also another thought :) I guess you have now two login services for imap and pop3, one for proxy and one for backend?
No, just the one for each right now. I haven't figured out how to do that yet ;) Just multiple imap-login/pop3-login blocks with different inet_listener addresses?
Right.
How do I tell different login services to use different auth backends? Is it the first argument to the login process executable? So like:
service imap-login { executable = imap-login auth-proxy inet_listener imaps { address = 1.2.3.4 } }
Yes, but with director config you're already doing it:
proxy: director -> auth-login normal: login/login
So one auth that listens login/login and other auth that listens auth-login.
I'm still trying to grok what all the different config bits mean and imply.
All of this is something that wasn't really planned to be ever done :)
participants (3)
-
Brad Davidson
-
Brandon Davidson
-
Timo Sirainen