Hello All
We are running into a very bizarre situation using opendap 2.4.57 on Debian 11 and Debian 13 openldap 2.6.10
When running
ldapsearch -LLL -x -H ldap://localhost login=x.y +
We get the 2 below extended attributes (and only those) in double
entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot
subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema
Standard attributes are fine
A slapcat of the DB is perfect, no double up on the above on any user.
phpmyadmin is also OK showing the extended attributes
If I slapadd the DB (into the Debian 13 stance) … it works, but I also get the above again
This is how we discovered the issue as the dump script used ldapsearch, and we were getting tons of « duplicates » (hence ignored) due to the above.
Thanks for any help to resolve this mystery !
Best Sebastian
Sebastian Perkins Senior Systems Development Engineer weareplanet.com
On Thu, Mar 19, 2026 at 05:30:30PM +0000, Sebastian Perkins wrote:
Hello All
We are running into a very bizarre situation using opendap 2.4.57 on Debian 11 and Debian 13 openldap 2.6.10
When running
ldapsearch -LLL -x -H ldap://localhost login=x.y +
We get the 2 below extended attributes (and only those) in double
entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot
subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema
Standard attributes are fine
A slapcat of the DB is perfect, no double up on the above on any user.
phpmyadmin is also OK showing the extended attributes
If I slapadd the DB (into the Debian 13 stance) … it works, but I also get the above again
This is how we discovered the issue as the dump script used ldapsearch, and we were getting tons of « duplicates » (hence ignored) due to the above.
Hi Sebastian, could you share your configuration, are you using RWM or any of the proxies (back-ldap, slapo-chain, meta, ...)? Also if you manage to set up a short script to reproduce this, you can file a bug[0] and attach it there.
[0]. https://bugs.openldap.org
Thanks,
Hello Ondřej
up a short script to reproduce this, you can file a bug[0] and attach it there.
To reproduce the script, ldapsearch is enough
ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost login=a.b entryDN subschemaSubentry | sort
entryDN: cn=a.b,ou=Network,ou=PT,o=Swisscom-Eurospot entryDN: cn=a.b,ou=Network,ou=PT,o=Swisscom-Eurospot subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema
Slapcat does not have this issue.
For the ldapsearch (old script to backup users) we simply added
| grep -v "^entryDN:" \ | grep -v "^subschemaSubentry: » \
To remove the entries, which, on a slapadd get automatically created
Hi Sebastian, could you share your configuration, are you using RWM or any of the proxies (back-ldap, slapo-chain, meta, ...)? Also if you manage to set
Here is the config (a bit anonymised) on ldap 2.4 and 2.6, we only changed policy (now standard) and TLS setup (Debian 13 compiled it with openssl)
include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/sudo-ldap.schema include /etc/ldap/schema/openssh-lpk.schema include /etc/ldap/schema/ldapns.schema #include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap
include /etc/ldap/schema/eurospot.schema include /etc/ldap/schema/insight.schema include /etc/ldap/schema/eurospotexternal.schema include /etc/ldap/schema/people.schema include /etc/ldap/schema/eurospotmatches.schema
# TLS TLSCipherSuite HIGH:MEDIUM TLSCACertificateFile /etc/ldap/ssl/x.crt TLSCertificateFile /etc/ldap/ssl/x.crt TLSCertificateKeyFile /etc/ldap/ssl/x.key TLSVerifyClient never
allow bind_v2 loglevel sync stats
# moduleload back_hdb moduleload back_monitor moduleload back_ldap moduleload back_meta moduleload back_relay moduleload rwm moduleload syncprov moduleload auditlog.la moduleload ppolicy.la moduleload memberof.la moduleload refint.la moduleload back_mdb moduleload lastbind.so
sizelimit unlimited timelimit 900 tool-threads 2 idletimeout 60 threads 32 overlay auditlog auditlog /var/log/ldapaudit/audit.log
overlay lastbind lastbind-precision 60
database monitor rootdn "cn=x,dc=y,dc=z"
# Specific Directives for database database mdb maxsize 3221225472 envflags nosync envflags writemap envflags nometasync
suffix "" rootdn "cn=x,dc=y,dc=z"
directory "/var/lib/ldap/"
readonly off
index objectClass eq index cn eq,pres index uid eq,pres index mail,mailalias eq,pres index login eq,pres index uidNumber eq,pres index memberUid eq,pres index eurospotEmployeeSearch eq,pres index sudoUser eq index member eq index memberOf eq index entryUUID eq index entryCSN eq
lastmod on
limits dn.exact="cn=syncrepl,dc=sceur,dc=ch" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=admin,dc=sceur,dc=ch" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=manager" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=manager,o=admin" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=alliacom,o=admin" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=extranet,o=admin" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
overlay syncprov syncprov-checkpoint 128 5 syncprov-sessionlog 128
overlay refint refint_attributes memberOf member refint_nothing "cn=placeholder,o=Swisscom-Eurospot"
overlay ppolicy ppolicy_default "cn=passwordDefault,ou=Policies,o=z" ppolicy_hash_cleartext
Sebastian Perkins Senior Systems Development Engineer weareplanet.com De : Ondřej Kuzník ondra@mistotebe.net Date : lundi, 23 mars 2026 à 11:52 À : Sebastian Perkins Sebastian.Perkins@hoistgroup.com Cc : openldap-technical@openldap.org openldap-technical@openldap.org Objet : Re: Ldapsearch : double on certain extended attributes
[You don't often get email from ondra@mistotebe.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
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, Mar 19, 2026 at 05:30:30PM +0000, Sebastian Perkins wrote:
Hello All
We are running into a very bizarre situation using opendap 2.4.57 on Debian 11 and Debian 13 openldap 2.6.10
When running
ldapsearch -LLL -x -H ldap://localhost login=x.y +
We get the 2 below extended attributes (and only those) in double
entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot entryDN: cn=x.y,ou=Sales,ou=IT,o=Swisscom-Eurospot
subschemaSubentry: cn=Subschema subschemaSubentry: cn=Subschema
Standard attributes are fine
A slapcat of the DB is perfect, no double up on the above on any user.
phpmyadmin is also OK showing the extended attributes
If I slapadd the DB (into the Debian 13 stance) … it works, but I also get the above again
This is how we discovered the issue as the dump script used ldapsearch, and we were getting tons of « duplicates » (hence ignored) due to the above.
Hi Sebastian, could you share your configuration, are you using RWM or any of the proxies (back-ldap, slapo-chain, meta, ...)? Also if you manage to set up a short script to reproduce this, you can file a bug[0] and attach it there.
[0]. https://bugs.openldap.org/https://bugs.openldap.org/
Thanks,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, Mar 26, 2026 at 07:17:15AM +0000, Sebastian Perkins wrote:
could you share your configuration, are you using RWM or any of the proxies (back-ldap, slapo-chain, meta, ...)? Also if you manage to set
Here is the config (a bit anonymised) on ldap 2.4 and 2.6, we only changed policy (now standard) and TLS setup (Debian 13 compiled it with openssl)
I still don't see it in any of the similar configurations I've used. Nor do I see anything out of the ordinary in your configuration.
If you only load the modules you use (removing the rwm, meta, ... modules below) does it still happen?
# moduleload back_hdb moduleload back_monitor moduleload back_ldap moduleload back_meta moduleload back_relay moduleload rwm moduleload syncprov moduleload auditlog.la moduleload ppolicy.la moduleload memberof.la moduleload refint.la moduleload back_mdb moduleload lastbind.so
Also (and this is unrelated), you don't need to use lastbind overlay anymore on 2.6, if you are happy to use the attribute pwdLastSuccess instead (defined in behera-ppolicy-10 and onward), you can just use:
lastbind on lastbind-precision 60
Instead of the overlay.
Regards,
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.
Also (and this is unrelated), you don't need to use lastbind overlay anymore on 2.6, if you are happy to use the attribute pwdLastSuccess instead (defined in behera-ppolicy-10 and onward), you can just use: lastbind on astbind-precision 60 Instead of the overlay.
Thanks for that, the deb13 setup is still a proof of concept regarding the diffs from openldap 2.4 to 2.6
Sebastian
Sebastian Perkins Senior Systems Development Engineer weareplanet.com De : Ondřej Kuzník ondra@mistotebe.net Date : vendredi, 27 mars 2026 à 11:00 À : Sebastian Perkins Sebastian.Perkins@hoistgroup.com Cc : openldap-technical@openldap.org openldap-technical@openldap.org Objet : Re: Ldapsearch : double on certain extended attributes
[You don't often get email from ondra@mistotebe.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
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, Mar 26, 2026 at 07:17:15AM +0000, Sebastian Perkins wrote:
could you share your configuration, are you using RWM or any of the proxies (back-ldap, slapo-chain, meta, ...)? Also if you manage to set
Here is the config (a bit anonymised) on ldap 2.4 and 2.6, we only changed policy (now standard) and TLS setup (Debian 13 compiled it with openssl)
I still don't see it in any of the similar configurations I've used. Nor do I see anything out of the ordinary in your configuration.
If you only load the modules you use (removing the rwm, meta, ... modules below) does it still happen?
# moduleload back_hdb moduleload back_monitor moduleload back_ldap moduleload back_meta moduleload back_relay moduleload rwm moduleload syncprov moduleload auditlog.la moduleload ppolicy.la moduleload memberof.la moduleload refint.la moduleload back_mdb moduleload lastbind.so
Also (and this is unrelated), you don't need to use lastbind overlay anymore on 2.6, if you are happy to use the attribute pwdLastSuccess instead (defined in behera-ppolicy-10 and onward), you can just use:
lastbind on lastbind-precision 60
Instead of the overlay.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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,
Hi Ondřej
The last weeks have been hectic…
I will proceed on a tcpdump + minimal setup in the next weeks.
Sebastian
Sebastian Perkins Senior Systems Development Engineer weareplanet.com 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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 weareplanet.com 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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,
Hi Ondřej
The slapd config is what I gave you its really minimal
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
Thats the ldif file I am testing, nothing more,
entryDN: o=Test-Root subschemaSubentry: cn=Subschema
Are doubled up everywhere on a slapcat import.
include /etc/ldap/schema/eurospot.schema include /etc/ldap/schema/insight.schema
Can I add these to the mail as an attach or directly ? They might de a bit big.
What I fail to understand is the ldapsearch generates the issue but not a slapcat
Sebastian
Sebastian Perkins Senior Systems Development Engineer weareplanet.com 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Hi Ondřej
We have revivied our old ldap setup in prod and test setup debian stretch 9.13 slapd is version 2.4.44+dfsg-5+deb9u9 Same configuration
Ldapsearch is fine here, and the slapcat load to the deb9 ldap (in a test environnement) works fine (ie no duplicate extended attributes for entryDN and subschemaSubentry)
It’s using this transfer in the deb 11 setup that we discovered the issue. Also present in deb 13 and the test bed I am running.
I cannot comment for the Debian 10 version, as we migrated from Debian 9 to 11 directly.
Sebastian Perkins Senior Systems Development Engineer weareplanet.com 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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 weareplanet.com 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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/ weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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.c... http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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 weareplanet.com 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
You don't often get email from erikdewaard@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
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.commailto: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
[cid:image672870.png@7424EE37.9F4D7C08]https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [https://www.linkedin.com/company/planet/]https://www.linkedin.com/company/planet/ weareplanet.comhttps://www.weareplanet.com/ [cid:image232062.png@89086B1C.D5273D3D]https://utm.io/ujp5N De : Ondřej Kuzník <ondra@mistotebe.netmailto:ondra@mistotebe.net> Date : mercredi, 29 avril 2026 à 17:33 À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com> Cc : openldap-technical@openldap.orgmailto:openldap-technical@openldap.org <openldap-technical@openldap.orgmailto: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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/ weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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
You don't often get email from erikdewaard@gmail.com. Learn why this is important https://aka.ms/LearnAboutSenderIdentification
*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 [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/
weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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.c... http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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 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 importanthttps://aka.ms/LearnAboutSenderIdentification
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.commailto: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
[https://mail.google.com/mail/?ui=2&ik=9b18abc3c6&attid=0.7&th=19...]https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [https://www.linkedin.com/company/planet/]https://www.linkedin.com/company/planet/ weareplanet.comhttps://www.weareplanet.com/ [https://mail.google.com/mail/?ui=2&ik=9b18abc3c6&attid=0.8&th=19...]https://utm.io/ujp5N De : Erik de Waard <erikdewaard@gmail.commailto:erikdewaard@gmail.com> Date : samedi, 2 mai 2026 à 10:19 À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com> Cc : Ondřej Kuzník <ondra@mistotebe.netmailto:ondra@mistotebe.net>; openldap-technical <openldap-technical@openldap.orgmailto:openldap-technical@openldap.org> Objet : Re: Ldapsearch : double on certain extended attributes
You don't often get email from erikdewaard@gmail.commailto:erikdewaard@gmail.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
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.commailto: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
[https://mail.google.com/mail/?ui=2&ik=9b18abc3c6&attid=0.9&th=19...]https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [https://www.linkedin.com/company/planet/]https://www.linkedin.com/company/planet/ weareplanet.comhttps://www.weareplanet.com/ [https://mail.google.com/mail/?ui=2&ik=9b18abc3c6&attid=0.11&th=1...]https://utm.io/ujp5N De : Ondřej Kuzník <ondra@mistotebe.netmailto:ondra@mistotebe.net> Date : mercredi, 29 avril 2026 à 17:33 À : Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com> Cc : openldap-technical@openldap.orgmailto:openldap-technical@openldap.org <openldap-technical@openldap.orgmailto: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 http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
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
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/ weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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 https://aka.ms/LearnAboutSenderIdentification
*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 [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/
weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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
You don't often get email from erikdewaard@gmail.com. Learn why this is important https://aka.ms/LearnAboutSenderIdentification
*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 [image: https://www.linkedin.com/company/planet/] https://www.linkedin.com/company/planet/
weareplanet.com https://www.weareplanet.com/ https://utm.io/ujp5N *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.c... http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Sebastian Perkins 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.
Those attributes are dynamically generated by slapd, so they appear in ldapsearch but not in slapcat. But because you included them in your slapadd,they got persisted into the DB and so your subsequent ldapsearches display both the statically persisted attribute and the dynamically generated values.
The slapadd docs state pretty clearly that it's meant to be fed the output of slapcat, not any other LDIF. When you feed it the output of ldapsearch, it's up to you to strip out operational attributes so they don't get persisted erroneously by slapadd.
Sebastian
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer
https://www.linkedin.com/company/planet/ https://www.linkedin.com/company/planet/ weareplanet.com https://www.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 https://aka.ms/LearnAboutSenderIdentification
*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 mailto: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 <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/ <https://www.linkedin.com/company/planet/> weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Erik de Waard <erikdewaard@gmail.com <mailto:erikdewaard@gmail.com>> *Date : *samedi, 2 mai 2026 à 10:19 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.com <mailto:Sebastian.Perkins@hoistgroup.com>> *Cc : *Ondřej Kuzník <ondra@mistotebe.net <mailto:ondra@mistotebe.net>>; openldap-technical <openldap-technical@openldap.org <mailto:openldap-technical@openldap.org>> *Objet : *Re: Ldapsearch : double on certain extended attributes You don't often get email from erikdewaard@gmail.com <mailto:erikdewaard@gmail.com>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> *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 <mailto: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 <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/ <https://www.linkedin.com/company/planet/> weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Ondřej Kuzník <ondra@mistotebe.net <mailto:ondra@mistotebe.net>> *Date : *mercredi, 29 avril 2026 à 17:33 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.com <mailto:Sebastian.Perkins@hoistgroup.com>> *Cc : *openldap-technical@openldap.org <mailto:openldap-technical@openldap.org> <openldap-technical@openldap.org <mailto: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 <http://www.symas.com/> Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Shouldn't the " SINGLE-VALUE" definition olcAttributeTypes: ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) prevent duplicating the attribute in any case?
Kind regards, Ulrich Windl
-----Original Message----- From: Howard Chu hyc@symas.com Sent: Monday, May 4, 2026 5:35 PM To: Sebastian Perkins Sebastian.Perkins@hoistgroup.com; Erik de Waard erikdewaard@gmail.com Cc: Ondřej Kuzník ondra@mistotebe.net; openldap-technical <openldap- technical@openldap.org> Subject: [EXT] Re: Ldapsearch : double on certain extended attributes
Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die Echtheit überprüft haben.
Sebastian Perkins 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.
Those attributes are dynamically generated by slapd, so they appear in ldapsearch but not in slapcat. But because you included them in your slapadd,they got persisted into the DB and so your subsequent ldapsearches display both the statically persisted attribute and the dynamically generated values.
The slapadd docs state pretty clearly that it's meant to be fed the output of slapcat, not any other LDIF. When you feed it the output of ldapsearch, it's up to you to strip out operational attributes so they don't get persisted erroneously by slapadd.
Sebastian
https://www.weareplanet.com/ Sebastian Perkins Senior Systems Development Engineer
https://www.linkedin.com/company/planet/
weareplanet.com https://www.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 https://aka.ms/LearnAboutSenderIdentification
*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 mailto:Sebastian.Perkins@hoistgroup.com> wrote:
Hello Erik That’s what we are currently doing, especially in our ldapsearch basedbackup.
The goal of the thread is to understand what is going on. Sebastian <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/https://www.linkedin.com/company/planet/
weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Erik de Waard <erikdewaard@gmail.com*Date : *samedi, 2 mai 2026 à 10:19 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com>
*Cc : *Ondřej Kuzník <ondra@mistotebe.netmailto:ondra@mistotebe.net>; openldap-technical <openldap- technical@openldap.org
<mailto:openldap-technical@openldap.org>> *Objet : *Re: Ldapsearch : double on certain extended attributes You don't often get email from erikdewaard@gmail.commailto:erikdewaard@gmail.com. Learn why this is important https://aka.ms/LearnAboutSenderIdentification
*CAUTION:* This email originated from outside Planet. Do not click linksor open attachments unless you recognise the sender and know the content is safe.
Please report all suspicious emails by clicking on the report messagebutton in Outlook.
Remove the operational attributes (entryDN subschemaSubentry) fromthe import ldif (oSEclassic.ldif)
On Sat, May 2, 2026, 07:22 Sebastian Perkins<Sebastian.Perkins@hoistgroup.com mailto:Sebastian.Perkins@hoistgroup.com> wrote:
Hi Ondřej We have been running a brand new openldap on a dedicated freshserver, 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" -Hldap://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 <https://www.weareplanet.com/> Sebastian Perkins Senior Systems Development Engineer https://www.linkedin.com/company/planet/https://www.linkedin.com/company/planet/
weareplanet.com <https://www.weareplanet.com/> <https://utm.io/ujp5N> *De : *Ondřej Kuzník <ondra@mistotebe.net*Date : *mercredi, 29 avril 2026 à 17:33 *À : *Sebastian Perkins <Sebastian.Perkins@hoistgroup.commailto:Sebastian.Perkins@hoistgroup.com>
*Cc : *openldap-technical@openldap.org <mailto:openldap-technical@openldap.org> <openldap-technical@openldap.org mailto:openldap-technical@openldap.org>
*Objet : *Re: Ldapsearch : double on certain extended attributes CAUTION: This email originated from outside Planet. Do not click linksor open attachments unless you recognise the sender and know the content is safe.
Please report all suspicious emails by clicking on the report messagebutton 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 barebones.
> > [...] > # 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. Butthings
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 Corporationhttps://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sy mas.com%2F&data=05%7C02%7CSebastian.Perkins%40hoistgroup.com%7C2 ee3a08d3f034e6fe99b08dea604affd%7Cb607882112c74949982752da66c836c 7%7C0%7C0%7C639130736280320661%7CUnknown%7CTWFpbGZsb3d8eyJF bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0J8snHYLVqWjwxDR28 W4e8Ma2Jw%2Bl8L6hpkVeAdaQuo%3D&reserved=0
<http://www.symas.com/> Packaged, certified, and supported LDAP solutions powered byOpenLDAP
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Mon, May 04, 2026 at 08:56:37AM +0000, Sebastian Perkins wrote:
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.
Hi Sebastian, the issue as Howard already said is that these are dynamic attributes and not meant to be stored. slapcat-based backups (which you should prefer if possible, given that's the only way to guarantee a consistent view of the DB) will only return stored data. But `ldapsearch -MM` backups will also return these and should therefore be stripped, since slapadd stores what is given to it.
From 2.6.14 onward, slapadd will skip dynamic attributes when processing entries given to it (ITS#10501), however you should still prefer slapcat for your ldif-based backups and mdb_copy -c for file based backups in general.
Regards,
Hello Ondřej
Thanks, we will go ahead on that road, the answer and consistency of the 2 dynamic attributes throughout openldap 2.4 / 2.6 in Debian 11, 12 and 13 is fine for us.
Just a last question before totally moving on...
~From 2.6.14 onward, slapadd will skip dynamic attributes when processing entries given to it (ITS#10501), however you should still prefer slapcat for your ldif-based backups and mdb_copy -c for file based backups in general.
We also use the password policy which exports / imports fine, these are extended attributes but not dynamic ones and hence will be fine ?
Best regards Sebastian
Sebastian Perkins Senior Systems Development Engineer weareplanet.com De : Ondřej Kuzník ondra@mistotebe.net Date : lundi, 18 mai 2026 à 11:20 À : Sebastian Perkins Sebastian.Perkins@hoistgroup.com Cc : Erik de Waard erikdewaard@gmail.com; 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.
On Mon, May 04, 2026 at 08:56:37AM +0000, Sebastian Perkins wrote:
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.
Hi Sebastian, the issue as Howard already said is that these are dynamic attributes and not meant to be stored. slapcat-based backups (which you should prefer if possible, given that's the only way to guarantee a consistent view of the DB) will only return stored data. But `ldapsearch -MM` backups will also return these and should therefore be stripped, since slapadd stores what is given to it.
From 2.6.14 onward, slapadd will skip dynamic attributes when processing entries given to it (ITS#10501), however you should still prefer slapcat for your ldif-based backups and mdb_copy -c for file based backups in general.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com/http://www.symas.com/ Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, May 21, 2026 at 04:48:51AM +0000, Sebastian Perkins wrote:
Hello Ondřej
Thanks, we will go ahead on that road, the answer and consistency of the 2 dynamic attributes throughout openldap 2.4 / 2.6 in Debian 11, 12 and 13 is fine for us.
Just a last question before totally moving on...
From 2.6.14 onward, slapadd will skip dynamic attributes when processing entries given to it (ITS#10501), however you should still prefer slapcat for your ldif-based backups and mdb_copy -c for file based backups in general.
We also use the password policy which exports / imports fine, these are extended attributes but not dynamic ones and hence will be fine ?
So long as you use the ManageDSAiT control (ldapsearch -MM) when making the backup, the right attributes will be omitted (both right now and in 2.7 where ppolicy also populates pwdPolicySubentry based on the configured rules).
Regards,
openldap-technical@openldap.org
-
Erik de Waard -
Howard Chu -
Ondřej Kuzník -
Sebastian Perkins -
Windl, Ulrich