Re: OL 2.2.23 extensible matching on dn components

["Pierangelo Masarati" <ando@sys-net.it>]

I think this issue is related to ITS#3406, which has been fixed in
HEAD/2.3 with respect to extensible match in regular AVAs but not in
dnattrs.  The problem, in short, is that a normalized asserted value gets
compared to a non-normalized attribute value; in fact, I suggest you try
"(dc:dn:=brgs)", which should work (by chance) since the normalized and
non-normalized value are the same.  ITS#3406 needs be reopened with
respect to the dnattrs, but it's unlikely this will be fixed in 2.2.

p.


>
> OpenLDAP 2.2.23
> BDB 4.3.27
> Backend: back-bdb
> Debian GNU/Linux 3.0
>
> I've experiencing the same odd behavour after upgrading from 2.1.30 to
> 2.2.23 last weekend.
>
> For example:
>
> $ ldapsearch -LLL -x -b "dc=brgs,dc=org" "(ou:dn:=Sonstige)" dn
> dn: ou=Sonstige,ou=People,dc=brgs,dc=org
>
> returns only the ou entry itself but not the entries below:
>
> $ ldapsearch -LLL -x -b "ou=Sonstige,ou=People,dc=brgs,dc=org" dn
> dn: ou=Sonstige,ou=People,dc=brgs,dc=org
>
> dn: uid=flow,ou=Sonstige,ou=People,dc=brgs,dc=org
>
> dn: uid=floriankaine,ou=Sonstige,ou=People,dc=brgs,dc=org
>
> dn: uid=cormoran,ou=Sonstige,ou=People,dc=brgs,dc=org
>
> dn: uid=bronietzki,ou=Sonstige,ou=People,dc=brgs,dc=org
>
> [...]
>
>
> I'm open to any suggestions on how to fix/workaround this but it looks
> like a slapd-sided bug in my eyes...
>
> regards
> Dariush
>


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


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497