Hi Daniel! On Thu, 10 Apr 2025, I wrote:
> $ lbdbq Roland Rosenfeld
> lbdbq: no matches
> (surprisingly, with other backends this works as expected and finds
> some "Roland Rosenfeld" matches, seems that I have to re-check the
> ldap backend. BTW: with m_gpg I have 4 matches)
>
> $ lbdbq "Roland Rosenfeld"
> also gives no matches (m_gpg also gives 4 matches).
> Hmmm, from my point of view there is a bug in m_ldap, which should
> be possible to find at least one "Roland Rosenfeld" (maybe by
> internally fetching all "roland" and then grep for "Roland
> Rosenfeld" in the result).
In the meantime I digged a little deeper and found the root cause for
this problem: The Debian LDAP (db.debian.org) uses the attribute cn
in an unusual way:
cn: Roland
uid: roland
sn: Rosenfeld
gecos: Roland Rosenfeld,,,,
The usual way is to have the first name (Roland) in the givenName
attribute and use the cn (CommonName) attribute for the complete name
(Roland Rosenfeld). But this one is only available in the gecos field
here (with the commas (unused subfields) as a suffix).
So if I want to search in db.debian.org for "Roland Rosenfeld", I have
to search in the gecos field using wildcards (which can be enabled in
mutt_ldap_query/m_ldap with $ignorant=1).
This can be archived with the following ldap.rc:
%ldap_server_db = (
'debian' => [
'ldaps://db.debian.org',
'ou=users,dc=debian,dc=org',
'uid cn sn ircnick gecos',
'uid cn sn ircnick',
'${uid}@debian.org',
'${cn} ${sn}', '${ircnick}',
1, # wildcard search for matching gecos
],
);
and
LDAP_NICKS="debian"
in lbdbrc
(or alternatively setting all the $ldap_* variables manually including
$ldap_search_fields = 'uid cn sn ircnick gecos';
$ignorant = 1;
)
I'll have to update the debian example in /etc/lbdb_ldap.rc
accordingly.
@Daniel: I still don't understand what your problem in this issue is.
Please give me an example what you did, what you got and what you
expected.
After some more testing I found out, that mutt_ldap_query by default
does an "or" join, if called with two parameters. This also seems to
be the behavior you intended with your patch, which works at
least with m_ldap:
$ lbdbq-test Gröber Rosenfeld
lbdbq: 2 matches
d...@debian.org Daniel Gröber dxld
rol...@debian.org Roland Rosenfeld RoRo
The problem here is, that most other modules (like m_inmail or m_gpg)
do not expect multiple parameters this way and fail with your changed
lbdbq.
Maybe I should extend the documentation to more explicitly mention
that lbdbq always takes all parameters as a long (virtually quoted)
string and searches for this string in this order (instead of
searching for multiple space separated strings as "or"-connected).
Alternatively I could modify all modules to join multiple space
separated parameters with "or" (except manually quoted in the query
string), but this would change the default behavior for most current
users which doesn't sound like a very good idea to me...
Greetings
Roland
signature.asc
Description: PGP signature
