[Dovecot] Dovecot+LDAP issues

[Daniel Gomes]

Hey there,

first of all, sorry for the late reply, the long easter weekend got in 
the way...
Answering your questions:

Em 31-03-2010 17:13, Hugo Monteiro escreveu:
>
> Hi Daniel,
>
> Are you using by any chance the slapo-rwm overlay? There is mention in 
> openldap 2.4.13 changelog that prior versions would rewrite an 
> undefined filter.
No, but I'm using the dynlist overlay.
>
> Have you tried issuing the exact search on both servers, using 
> ldapseach for instance, and see if they both return the same information?
Yes, I tried it often and they always return the same information 
(provided the changes aren't very recent, since the extra server updates 
itself every 6 hours). Like I mentioned, the extra server got an 
undefined filter, so it really looks like a client side (ie. dovecot) 
issue and not a server issue.
>
> Regards,
>
> Hugo Monteiro.
>


Em 01-04-2010 08:55, Brian Candler escreveu:
> On Wed, Mar 31, 2010 at 02:59:28PM +0100, Daniel Gomes wrote:
>    
>> I am having some problems with a LDAP passdb authentication on Dovecot.
>> Before I forget, the specs: it's a Ubuntu 7.10 server running Dovecot
>> 1.0.5 connecting to 2 different machines running LDAP servers: gold with
>> OpenLDAP 2.4.19 and extra with OpenLDAP 2.4.9 (extra is a replication
>> slave of gold).
>>      
> If you can replicate this problem on a test IMAP box pointing to the same
> two LDAP servers, it might be worth checking whether dovecot-1.2.11 has the
> same problem.  At least, there are more people on this list who would be
> able to replicate it using current code.
>
>    
I set up my test box (Ubuntu 9.04) with dovecot 1.1.11 (it's the one 
available on repositories) and with the same configuration as the 
production server**, and everything seems to work fine. I tried:

- Both LDAP servers up: as expected, no troubles here
- I stopped the first LDAP server (gold) and verified that after losing 
the connection, dovecot went to the second server (extra) and I was also 
able to authenticate (I verified extra's slapd logs to make sure it was 
really querying it).
- I restarted gold's LDAP and killed extra's, and dovecot went back to 
(successfully) authenticating users against gold's LDAP.

**: the only difference in the server's configurations is the use of 
TLS: I had my main dovecot server with TLS activated (that is, it would 
use safe connections to the LDAP servers) but it seems to fail randomly 
on some occasions (even with other tools such as phpLDAPadmin, although 
it seems to work fine with the ldap* tools). So in my main dovecot 
server I set "tls = no" when I first had these issues, whereas on the 
test machine I decided to try it with tls ("tls = yes"). But like I 
mentioned, the troubles came when using TLS, so trying it on the test 
machine with TLS enabled just helps proving it ain't its fault.

> Also, you could try swapping master and slave around in the
> dovecot-ldap.conf (i.e.  try extra first, then gold). You state that the two
> LDAP databases are clones, but they are running different versions of
> openldap, so may behave differently.
>
>    
I tried this too, and it also worked. I then killed extra's LDAP (now 
the first on the list) and dovecot successfully authenticated against 
gold's ldap. I then also killed that server, after which I obviously 
couldn't login. As expected, bringing extra's LDAP back on restored 
functionality.
As a final test, I re-did these steps (logging in with both LDAPs on, 
killing the first and then logging in again) with my production server, 
and it also worked fine.

It really just looks like a random error (I almost wrote "bug" here but 
I don't want to blame it on dovecot itself just yet ;-) ) which won't be 
so easy to reproduce. My fear here is that it will randomly (even if not 
often) happen while in production and basically bring down the mail 
system with it (you can imagine the angry "costumers" hehe). Of course I 
will leave the MySQL passdb after the LDAP one as a safeguard, so that 
setup should minimize the chances of a total service failure...

> Regards,
>
> Brian.
>
> P.S. Unrelated, but I hope you're aware that Ubuntu 7.10 went out of support
> on Apr 18th last year?  https://wiki.ubuntu.com/Releases
>    

Thanks for the heads up! We (and by "we" I mean "me") are slowly 
upgrading our servers for the latest LTS version (Hardy), but it's still 
a work in progress.... You reckon the old Ubuntu/dovecot version is 
contributing to the issue here?

Cheers,

-- 
Daniel Gomes (SysAdmin)
dgomes at ipfn.ist.utl.pt
Ext. 3487 - 218419487

Instituto de Plasmas e Fusão Nuclear
Instituto Superior Técnico - UTL
Av. Rovisco Pais - 1049-001 Lisboa - Portugal