[Date Prev][Date Next]
Re: OpenLDAP 2.1.22 meta and bdb backend weirdness
> Pierangelo Masarati wrote:
>>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
> That helped a lot, thanks!
> Indeed, the Courier mail server had a bug and queried an attribute that
> wasn't in the schema. I've fixed that in Courier's code.
> There's a bug in BDB backend, though. As can be seen it doesn't return
> an error code on decoding errors, while Meta backend does. If BDB were
> returning error code on those errors, the problem with Courier would be
> noticed instantly - Courier just wouldn't work.
Unfortunately, your diagnosis is not correct;
DSAs do not return errors on malformed filters
(don't remember where this is stated, but it
has to be in some RFC). I think back-meta does
for a different reason, because the erroneous
filter is processed again for rewriting purposes,
and it fails with a backend specific error
related to the impossibility to rewrite the
filter. I'm afraid this will require to fix
back-meta (and back-ldap), since filter errors
must not be returned to clients.
>> 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?
> The whole filter was hardcoded in Courier's source, it was:
> The query looked for the "maildrop" attribute.
> The filter was incorrect, as the default name of the attribute is now
> "mailsource", not "source", as defined in Courier schema and config
> Thanks again for your reply! It helped track down that bug in Courier.
In this case, the correct (and only) way
to find the error is to look at the logs.
I'll try to make them more expressive in
this case (there's always room for log
improvements, mostly based on users'