[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.1.22 meta and bdb backend weirdness



> I'm seeing this in the logs, two identical queries (but directed to
> different slapd instances) that give different results (one generates an
>  error, the other does not):
>
> Query to the META instance:
> Feb 12 00:55:45 nmail slapd[21433]: conn=2991 op=1 SRCH
> base="dc=altkom,dc=pl,o=Altkom" scope=2
> filter="(&(mail=test)(!(?=false)))" Feb 12 00:55:45 nmail slapd[21433]:
> conn=2991 op=1 SRCH attr=maildrop Feb 12 00:55:45 nmail slapd[21433]:
> conn=2991 op=1 SEARCH RESULT tag=101  err=32 nentries=0 text=
>
> Query to the BDB instace:
> Feb 12 00:56:09 nmail slapd[12027]: conn=1311 op=1 SRCH
> base="dc=altkom,dc=pl,o=Altkom" scope=2
> filter="(&(mail=test)(!(?=false)))" Feb 12 00:56:09 nmail slapd[12027]:
> conn=1311 op=1 SRCH attr=maildrop Feb 12 00:56:09 nmail slapd[12027]:
> conn=1311 op=1 SEARCH RESULT tag=101  err=0 nentries=0 text=
>
>
> The META instace listens on port 389 and is configured to forward all
> queries to the BDB instance that listens on port 390.
>
> Relevant section from slapd_meta.conf:
>
> database        meta
> suffix          "dc=altkom,dc=pl,o=Altkom"
> rootdn       "SNIPPED_FOR_POSTING"
> rootpw     SNIPPED_FOR_POSTING
> uri           "ldap://localhost:390/dc=altkom,dc=pl,o=Altkom
> ldaps://ldap.altkom.pl"
>
> Relevant section from slapd_bdb.conf:
>
> database  bdb
> suffix    "dc=altkom,dc=pl,o=Altkom"
> rootdn    "SNIPPED_FOR_POSTING"
> rootpw    SNIPPED_FOR_POSTING
> directory /var/lib/ldap_bdb
>
>
> As can be seen, the meta instance forwards all queries to the BDB
> instance, and if BDB instance is down, to a backup LDAPS server
> "ldap.altkom.pl". It works, I've tested. No queries arrive on
> ldap.altkom.pl server if BDB instance on port 390 works, all is as
> expected.
>
> But META backend gives that error no. 32 and BDB does not, with the same
>  query. Those queries are generated by ldapaliasd daemon from Courier
> mail server, and because of that incoherence it only works when
> connecting directly to BDB instance, not indirectly through META
> backend.
>
> Because of this, I cannot make Courier mail server resistant to BDB
> database failures, which are quite common (I want to use META backend
> for dynamic failover)...
>
> So is this an OpenLDAP bug, or a misconfiguration on my side?

First of all,

the software you use is not up to date.  I strongly suggest
you use the latest release of OpenLDAP.

Moreover, a filter that logs "(&(mail=test)(!(?=false)))"
indicates a decoding failure, so either backend should
reject it.  Can you provide a more complete description
of the query you're trying to execute, e.g. what the
filter looks like on the client's side, or at (the very)
least in ber form?  Check out if the attributes that
appear in the filter are defined in the server's schema.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it