What does a grep on your custom schemas show for these attributes?

On Mon, May 4, 2026, 13:18 Sebastian Perkins <Sebastian.Perkins@hoistgroup.com> wrote:
Hello Erik

Seems you might not have all the history. 

Grepping out the 2 extended attributes resolves the import issue. They actually get created after the ldif import.

So we are trying to pinpoint what part of openldap is causing this « double » in ldapsearch, but not a slapcat.

Sebastian


Sebastian Perkins
Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
weareplanet.com
De : Erik de Waard <erikdewaard@gmail.com>
Date : lundi, 4 mai 2026 à 13:01
À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.com>
Cc : Ondřej Kuzník <ondra@mistotebe.net>; openldap-technical <openldap-technical@openldap.org>
Objet : Re: Ldapsearch : double on certain extended attributes

You don't often get email from erikdewaard@gmail.com. Learn why this is important

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.

Ah ok. You dont mention that in your last mail. So to verify. before importing oSEclasdic.ldif
You remove the entryDN and subschemaSubentry and then import it?2

---
Here is the ldif (oSEclassic.ldif) using the « classic » object

dn: o=Swisscom-Eurospot
objectClass: organization
o: Swisscom-Eurospot
entryDN: o=Swisscom-Eurospot
subschemaSubentry: cn=Subschema
--







On Mon, May 4, 2026, 10:56 Sebastian Perkins <Sebastian.Perkins@hoistgroup.com> wrote:
Hello Erik

That’s what we are currently doing, especially in our ldapsearch based backup. 

The goal of the thread is to understand what is going on.


Sebastian



Sebastian Perkins
Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
De : Erik de Waard <erikdewaard@gmail.com>
Date : samedi, 2 mai 2026 à 10:19
À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.com>
Cc : Ondřej Kuzník <ondra@mistotebe.net>; openldap-technical <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.

Remove the operational attributes (entryDN subschemaSubentry) from the import ldif (oSEclassic.ldif)


On Sat, May 2, 2026, 07:22 Sebastian Perkins <Sebastian.Perkins@hoistgroup.com> wrote:
Hi Ondřej

We have been running a brand new openldap on a dedicated fresh server, and has allowed to move away literally anything custom our custom schémas.

Please find below the slapd.conf 

# Schema and objectClass definitions
include        /etc/ldap/schema/core.schema
include        /etc/ldap/schema/cosine.schema

loglevel        sync stats
moduleload      back_mdb

# core DB
database        mdb
suffix          "dc=sceur,dc=ch"
rootdn          "cn=admin,dc=sceur,dc=ch"
rootpw          "******"
directory       "/var/lib/ldap"

# user DB
database        mdb
suffix          ""
rootdn          "cn=admin,dc=sceur,dc=ch"
directory       "/var/lib/ldap/eurospot"
timelimit       900
tool-threads    2
idletimeout     60
threads         16

Here is the ldif (oSEclassic.ldif) using the « classic » object

dn: o=Swisscom-Eurospot
objectClass: organization
o: Swisscom-Eurospot
entryDN: o=Swisscom-Eurospot
subschemaSubentry: cn=Subschema

We import the ldif this way

service slapd stop
find /var/lib/ldap/eurospot -type f -delete
slapadd -c -b "o=Swisscom-Eurospot" -l /root/oSEclassic.ldif

And….. 
ldapsearch -o ldif-wrap=no -LLL -x -b "o=Swisscom-Eurospot" -H ldap://localhost + | sort

createTimestamp: 20260430145139Z
creatorsName: cn=admin,dc=sceur,dc=ch
dn: o=Swisscom-Eurospot
entryCSN: 20260430145139.888833Z#000000#000#000000
entryDN: o=Swisscom-Eurospot
entryDN: o=Swisscom-Eurospot
entryUUID: d6e971c4-d8ef-1040-9502-8322e1709cea
hasSubordinates: FALSE
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20260430145139Z
structuralObjectClass: organization
subschemaSubentry: cn=Subschema
subschemaSubentry: cn=Subschema

EntryDN and subschemaSubentry are in double using « out of the box » setup !



Sebastian

Sebastian Perkins
Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
De : Ondřej Kuzník <ondra@mistotebe.net>
Date : mercredi, 29 avril 2026 à 17:33
À : 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 Wed, Apr 29, 2026 at 08:58:31AM +0000, Sebastian Perkins wrote:
> 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.
>
> [...]
> # Local Schema and objectClass definitions
> include        /etc/ldap/schema/eurospot.schema
> include        /etc/ldap/schema/insight.schema
> [...]
>
> 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
>
> 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

Hi Sebastian,
I've just tried the same on a fresh Debian 13 (so 2.6.10+dfsg-1),
swapping out the schemas to a plain `objectClass: organization`, since I
have no idea what's in your schema and you didn't include it. But things
work just fine:

$ ldapsearch -x -H ldapi://socket -o ldif-wrap=no -LLL +
dn: o=Test-Root
structuralObjectClass: organization
entryUUID: 30b25038-d82b-1040-8346-d76423b101c5
creatorsName: cn=admin,dc=sceur,dc=ch
createTimestamp: 20260429152359Z
entryCSN: 20260429152359.666601Z#000000#000#000000
modifiersName: cn=admin,dc=sceur,dc=ch
modifyTimestamp: 20260429152359Z
entryDN: o=Test-Root
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

So again, there must be something in your setup that's not captured by
the above?

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%7C2ee3a08d3f034e6fe99b08dea604affd%7Cb607882112c74949982752da66c836c7%7C0%7C0%7C639130736280320661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0J8snHYLVqWjwxDR28W4e8Ma2Jw%2Bl8L6hpkVeAdaQuo%3D&reserved=0
Packaged, certified, and supported LDAP solutions powered by OpenLDAP