DaLiV at apollo.lv
2011-Feb-09 07:37 UTC
[Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP
not possible make operation with dovecot version 2.x as was possible in version 1.x: requisites description: connect to dovecot service on IP1 - dovecot must serve users that related to domain1 located in database1 connect to dovecot service on IP2 - dovecot must serve users that related to domain2 located in database2 login must be with username that form not as "user at domain" but simple "user" databases may contain identical username, but they have different passwords existing version 1 config file, that allow such configuration: -------- /etc/dovecot.conf BEGIN ---------------- server mail.domain1.tld { protocols = imaps pop3s pop3 ssl_cert_file = /etc/pki/cert1.pem ssl_key_file = /etc/pki/cert1.key listen = 123.123.123.1 ssl_listen = 123.123.123.1 default_mail_env = mbox:/tmp:INBOX=/var/mail/domain1.tld/%n:INDEX=MEMORY pop3_uidl_format = %08Xu%08Xv auth default { mechanisms = plain passdb ldap { args= /etc/dovecot-ldap.conf.domain1.tld1 } userdb ldap { args= /etc/dovecot-ldap.conf.domain1.tld1 } } login_process_per_connection = yes login_max_processes_count = 4 login_processes_count = 1 } server mail.domain2.tld { protocols = imaps pop3s pop3 ssl_cert_file = /etc/pki/cert2.pem ssl_key_file = /etc/pki/cert2.key listen = 123.123.123.2 ssl_listen = 123.123.123.2 default_mail_env = mbox:/tmp:INBOX=/var/mail/domain2.tld/%n:INDEX=MEMORY pop3_uidl_format = %08Xu%08Xv auth default { mechanisms = plain passdb ldap { args= /etc/dovecot-ldap.conf.domain2.tld2 } userdb ldap { args= /etc/dovecot-ldap.conf.domain2.tld2 } } login_process_per_connection = yes login_max_processes_count = 4 login_processes_count = 1 } -------- /etc/dovecot.conf END ---------------- /etc/dovecot-ldap.conf.domain1.tld and /etc/dovecot-ldap.conf.domain2.tld refers to different ldap databases
Timo Sirainen
2011-Feb-09 07:42 UTC
[Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP
On 9.2.2011, at 9.37, DaLiV at apollo.lv wrote:> existing version 1 config file, that allow such configuration: > -------- /etc/dovecot.conf BEGIN ---------------- > server mail.domain1.tld {I'm surprised that this server block really worked for you. I only remember having problems with it, and that's why its existence is well hidden. In v2.0 the idea is anyway that you could do: local mail.domain1.tld { .. } local mail.domain2.tld { .. } But this unfortunately doesn't currently work for auth settings. I'll get around to doing it at some point.. There is actually probably one horribly ugly way to make this already work, but it's so bad I don't really even want to suggest it (involving creating duplicate service blocks for different IPs and chrooting their processes to different dirs)..
DaLiV at apollo.lv
2011-Feb-14 14:20 UTC
[Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP
Timo Sirainen wrote:>> - another way (possible that will be more easiest, and good enough for >> advanced configurations) = single variable that may be set in block >> of exact ip listener configuration , as for provided before example >> may set variable "auth_db_suffix" = string("dc=domain1,dc=tld") for >> definition "local mail.domain1.tld" and that variable are inserted in >> auth block via variable inserting mechanism ... >> > Again not possible, because config parsing is done much earlier. >think for realization can take idea from that patch : --------------------------------- --- src/auth/auth-request.c.orig 2010-12-30 11:42:54.000000000 +0200 --- src/auth/auth-request.c.orig 2010-12-30 11:42:54.000000000 +0200 @@ -1547,6 +1547,7 @@ auth_request_get_var_expand_table(const { '\0', NULL, "login_user" }, { '\0', NULL, "login_username" }, { '\0', NULL, "login_domain" }, + { 'x', NULL, NULL }, { '\0', NULL, NULL } }; struct var_expand_table *tab; @@ -1600,6 +1601,15 @@ auth_request_get_var_expand_table(const auth_request); } } + const char *lip2user[][2] = {{"127.0.0.3","dc=domain1,dc=tld1"},{"127.0.0.1","localhost"},{"127.0.0.2","dc=domain2,dc=tld2"}}; + int arrsize=sizeof( lip2user ) / sizeof( lip2user[0]); + tab[18].value = ""; // default expanded to - emty string + int i; + for(i=0;i<arrsize;i++) { + if (strcmp(net_ip2addr(&auth_request->local_ip),(lip2user[i][0]))==0) { + tab[18].value = lip2user[i][1]; + } + } return tab; } --------------------------------- and there need only possibility to define pairs in config file for lip2user array initialization - then macro/variable %x will be available for substitution in all modules - as for ldap , as for filename-based parameters. in exaple patch created static table to match lip to suffix 127.0.0.3 = "dc=domain1,dc=tld1" 127.0.0.1 = "localhost" 127.0.0.2 = "dc=domain2,dc=tld2" how to initialize arrays from config - i'm was not explored for currently used coding structures may create this array more complex = not as simple pair - but as for selective conversion: %x1 lip to text1, %x2 lip to text2, %x3 lip to text3 ... - then diffirent advanced configurations will be possible ...