Hi Ondřej
Sorry for weeks I meant this week…
I have set up a deb 13 test bed with openldap stripped to the bare bones.
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap
# Local Schema and objectClass definitions
include /etc/ldap/schema/eurospot.schema
include /etc/ldap/schema/insight.schema
loglevel sync stats
moduleload ppolicy.la
moduleload back_mdb
moduleload lastbind.so
database mdb
suffix ""
rootdn "cn=admin,dc=sceur,dc=ch"
directory "/var/lib/ldap/eurospot"
timelimit 900
tool-threads 2
idletimeout 60
threads 16
Please note the 2 custom objects « local schema » created by a 3rd company a long time ago.
I am running the base tree (not very compliant but fine here)
dn: o=Test-Root
objectClass: insightOrganization
o: o=Test-Root
structuralObjectClass: insightOrganization
entryUUID: 02df68be-bad7-1037-853d-6b9d76b319d1
creatorsName: cn=admin,dc=sceur,dc=ch
createTimestamp: 20180313065342Z
entryCSN: 20180313065342.301666Z#000000#000#000000
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20180313065342Z
hasSubordinates: TRUE
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
A slapcat of the ldif file provides this
ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost
dn: o=Test-Root
objectClass: insightOrganization
o: Test-Root
Which is fine,
However the extended attributes provide double entries on the last 2 properties as described earlier
ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost +
dn: o=Test-Root
structuralObjectClass: insightOrganization
entryUUID: 02df68be-bad7-1037-853d-6b9d76b319d1
creatorsName: cn=admin,dc=sceur,dc=ch
createTimestamp: 20180313065342Z
entryCSN: 20180313065342.301666Z#000000#000#000000
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20180313065342Z
hasSubordinates: TRUE
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
And a slapcat doesn’t produce the above issue
/usr/sbin/slapcat -o ldif-wrap=no -f /etc/ldap/slapd.conf -b 'o=Test-Root'
dn: o=Test-Root
objectClass: insightOrganization
o: Test-Root
structuralObjectClass: insightOrganization
entryUUID: 02df68be-bad7-1037-853d-6b9d76b319d1
creatorsName: cn=admin,dc=sceur,dc=ch
createTimestamp: 20180313065342Z
entryCSN: 20180313065342.301666Z#000000#000#000000
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20180313065342Z
hasSubordinates: TRUE
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
Sebastian
 | | Sebastian Perkins | | Senior Systems Development Engineer |
|
|
|
| |
| |
|
|
|
|
De : Sebastian Perkins <Sebastian.Perkins@hoistgroup.com>
Date : mercredi, 29 avril 2026 à 07:08
À : Ondřej Kuzník <ondra@mistotebe.net>
Cc : openldap-technical@openldap.org <openldap-technical@openldap.org>
Objet : Re: Ldapsearch : double on certain extended attributes
Hi Ondřej
The last weeks have been hectic…
I will proceed on a tcpdump + minimal setup in the next weeks.
Sebastian
De : Ondřej Kuzník <ondra@mistotebe.net>
Date : mardi, 7 avril 2026 à 16:40
À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.com>
Cc : openldap-technical@openldap.org <openldap-technical@openldap.org>
Objet : Re: Ldapsearch : double on certain extended attributes
CAUTION: This email originated from outside Planet. Do not click links or open attachments unless you recognise the sender and know the content is safe. Please report all suspicious emails by clicking on the report
message button in Outlook.
On Thu, Apr 02, 2026 at 06:39:48AM +0000, Sebastian Perkins wrote:
> Hello Ondřej
>
>> If you only load the modules you use (removing the rwm, meta, …
>> modules below) does it still happen?
>
> We literally stripped down the config to be bare minimum, and still
> happened.
>
> We even just added a base DN entry and also failed…
>
> The current solution is to grep -v the 2 entries in ldif for
> ldapsearch (slapcat to slapadd is fine)
>
> FYI the ldapsearch dump is used for a very specific part of the tree
> containing users, allowing quick restore of users (crash, envrionment
> sync etc), the slapcat is more brutal 😃
>
> Would the « Issue » be in the ldapsearch result ? As slapcat is fine…
> however an ldapsearch bug issue on deb11 and 13 in openldap 2.4 and
> 2.6 is probably not one.
Hello Sebastian,
I don't think the issue is in ldapsearch (but that's easy to test, just
look at data in wireshark or `ldapsearch -d-1` or same in slapd logs to
see what was sent).
If it really happens all the time with the config you last provided,
even after making the changes that I suggested (not loading the extra
modules), then please prepare a small self-contained set up that we can
use to reproduce the issue. Given that I've been unable to do so based
on what's been provided so far, there must be a detail that's missing
that makes all the difference and honestly I'm not sure where else to
look.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.symas.com%2F&data=05%7C02%7CSebastian.Perkins%40hoistgroup.com%7Ca56d2675288a4c08b61c08de94b39461%7Cb607882112c74949982752da66c836c7%7C0%7C0%7C639111696195773305%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iYZf%2FbFMnXG%2FcOcaL7UXqb8SzJjBuPYf6PNTI7hkEg0%3D&reserved=0
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
