Re: [Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP

2011-02-14 Thread da...@apollo.lv

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.0 +0200
--- src/auth/auth-request.c.orig 2010-12-30 11:42:54.0 +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+   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 ...


Re: [Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP

2011-02-09 Thread da...@apollo.lv

Timo Sirainen wrote:

On 9.2.2011, at 9.37, da...@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.
it's worked flawlessy for many years : firstly redhat distros, later all 
fedora versions. But in latest fedora distro are included v2.x branch ...

  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've seen - auth from many databases possible - but all in one block, 
... as solution can create 2 variables that may be passed to auth process :

- 1 = local ip address , to which was connected client
- 2 = resolved ip address from 1
that variables must be possible to use in auth database "include file" 
definition similar to :

!include auth-ldap.conf.%IP
or
!include auth-ldap.conf.%IP_Resolved

_- 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 ...



  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)..
   
that way (multiple instances of dovecot with full copy of all 
configuration files) i was doing, but not liked, so on each update of 
distro currently i'm recompiling and reinstalling 1.x version on all 
mine controlled servers (ppc+x86+x64) ...


Re: [Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP

2011-02-08 Thread Timo Sirainen
On 9.2.2011, at 9.37, da...@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)..



[Dovecot] critical feature from version 1 not migrated to version 2 = authentication configuration database per IP

2011-02-08 Thread da...@apollo.lv

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@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