[Dovecot] problem configuring deliver in LDAP environment.
hello
I am using dovecot-1.2.15 in debian squeeze (packaged) and i have some difficulties migrating from an older installation tha is working perfectly.
i have a transport defined in postfix to call deliver as follows:
dovecotlda unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -s -e -f ${sender} -d ${recipient}
with the auth-socket in dovecot.conf all ok and this in ldap-userdb.conf: user_attrs = vdHome=chroot,mailbox=mail=maildir:%$,quota=quota_rule=*:bytes=%$,otherPath=sieve
you see, i have the base directory for the chroot for the entire mail system in ldap:vdHome as /home/vmail/domains and the actual location of the mailbox in maildir format in ldap:mailbox so i can have the actual complete path as /(vdHome)/(mailbox)
This is running smoolthly, BUT the chroot environment with all the library dependencies is REALLY REALLY limiting because the huge number of files from the system i must put on the mail storeage (which is networked and used by more systems so i cannot put libraries and binaries there)
What i am trying to do is leaving all the dovecot services running in chroot mode (as they do) but let deliver running in NORMAL (non-chroot mode)
so i need to remove the chroot variable in userattr reply, and parametrize the mail location with the two ldap values.
i am conscious that i can set up this as user_attrs = mailbox=mail=maildir:/home/vmail/domains/%$,quota=quota_rule=*:bytes=%$,otherPath=sieve
but I WANT TO KEEP THE BASE DIR PARAMETRIZED to leave me the possibility to set the base dir in LDAP to goup the accounts on different mail storage system.
So you know a method to substitute TWO ldap values in the mail parameter definition?
Thank you Andrea
On Tue, 2011-02-08 at 20:23 +0100, Andrea Borghi wrote:
dovecotlda unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -s -e -f ${sender} -d ${recipient} .. What i am trying to do is leaving all the dovecot services running in chroot mode (as they do) but let deliver running in NORMAL (non-chroot mode)
How is deliver even chrooting? Postfix doesn't call it chrooted and since it's user vmail:vmail the process isn't privileged to do any chrooting of its own.
So you know a method to substitute TWO ldap values in the mail parameter definition?
Not possible currently.
On Thursday 10 February 2011, Timo Sirainen wrote:
On Tue, 2011-02-08 at 20:23 +0100, Andrea Borghi wrote:
dovecotlda unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -s -e -f ${sender} -d ${recipient} .. What i am trying to do is leaving all the dovecot services running in chroot mode (as they do) but let deliver running in NORMAL (non-chroot mode)
How is deliver even chrooting? Postfix doesn't call it chrooted and since it's user vmail:vmail the process isn't privileged to do any chrooting of its own.
Server with no local users except for root,
I enabled SUID bit on deliver binary, to get the thing going. but i doen't like that. It was only a rapid solution to get the system going while searching a more robust alternative.
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
So you know a method to substitute TWO ldap values in the mail parameter definition?
Not possible currently.
so you're telling i have no other option except to fold over the two parts of the path directly in the LDAP database and reconfigure dovecot (as a whole) to map just one attribute?
I can certainly live with that but in this case i am loosing flexibility.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
bye Andrea
On Thu, 2011-02-10 at 21:26 +0100, Andrea Borghi wrote:
What i am trying to do is leaving all the dovecot services running in chroot mode (as they do) but let deliver running in NORMAL (non-chroot mode)
How is deliver even chrooting? Postfix doesn't call it chrooted and since it's user vmail:vmail the process isn't privileged to do any chrooting of its own.
Server with no local users except for root,
I enabled SUID bit on deliver binary, to get the thing going. but i doen't like that. It was only a rapid solution to get the system going while searching a more robust alternative.
OK, so it's deliver that does the chrooting.
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
But deliver doesn't call antivirus, right? So what's the problem of keeping deliver chrooted? There shouldn't be any need for any libraries or anything inside the chroot.
So you know a method to substitute TWO ldap values in the mail parameter definition?
Not possible currently.
so you're telling i have no other option except to fold over the two parts of the path directly in the LDAP database and reconfigure dovecot (as a whole) to map just one attribute?
Yeah.
I can certainly live with that but in this case i am loosing flexibility.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
I've some plans to rewrite LDAP configuration to support this and other things.
On Friday 11 February 2011, Timo Sirainen wrote:
On Thu, 2011-02-10 at 21:26 +0100, Andrea Borghi wrote:
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
But deliver doesn't call antivirus, right? So what's the problem of keeping deliver chrooted? There shouldn't be any need for any libraries or anything inside the chroot.
for the use of deliver, yes. but you're forgetting sieve filter and the ability to program with it the vacation messages, etc. in short, for every action of that type i need a /bin/sendmail in the chroot jail, and if you see the postfix sendmail binary you'll see the plethora of libs it requires. and in this you can see also the conflicts when the mail storage is on a shared media between more servers that can not be aligned in library versions, ecc. ecc.
just a nightmare.
so you're telling i have no other option except to fold over the two parts of the path directly in the LDAP database and reconfigure dovecot (as a whole) to map just one attribute?
Yeah.
ok. i will make the necessary adaptations now that i have a small mailbox number. thank you for this confirmation.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
I've some plans to rewrite LDAP configuration to support this and other things.
it'll be useful to me to know a rough timeframe for this (ex 6 months) to decide to wait on some services (ex. sieve) or to start rewriting the mail system logic in regard to mailbox paths.
thank you Andrea
On Fri, 2011-02-11 at 23:33 +0100, Andrea Borghi wrote:
On Friday 11 February 2011, Timo Sirainen wrote:
On Thu, 2011-02-10 at 21:26 +0100, Andrea Borghi wrote:
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
But deliver doesn't call antivirus, right? So what's the problem of keeping deliver chrooted? There shouldn't be any need for any libraries or anything inside the chroot.
for the use of deliver, yes. but you're forgetting sieve filter and the ability to program with it the vacation messages, etc. in short, for every action of that type i need a /bin/sendmail in the chroot jail, and if you see the postfix sendmail binary you'll see the plethora of libs it requires. and in this you can see also the conflicts when the mail storage is on a shared media between more servers that can not be aligned in library versions, ecc. ecc.
Oh. This would be solved nicely by having deliver (optionally) send the vacation messages by connecting to SMTP server via TCP instead of executing sendmail binary. I've wanted that for a while already anyway. v2.0 also already has a library that can talk SMTP.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
I've some plans to rewrite LDAP configuration to support this and other things.
it'll be useful to me to know a rough timeframe for this (ex 6 months) to decide to wait on some services (ex. sieve) or to start rewriting the mail system logic in regard to mailbox paths.
I can't give a timeframe for this. It probably wouldn't take long to implement it, but I've so many other things to do..
participants (2)
-
Andrea Borghi
-
Timo Sirainen