Hi

Thanks for the reply. However I am not using delta syncrepl just regular syncrepl. I don't understand how the organizationalUnit could only disappear (or be replaced by a glue object) on one of the servers. Anyway it does not get pulled back in on the provider where it is missing.

Also I cannot delete the glue object even after deleting the two objects that where below it in the tree (error: no such object). If there is a solution for that I would be happy to go this route. Apart from any other suggestions I'm afraid I have to go the slapcat and slapadd route and just hope that does not mess up anything on the second provider server as long as I block any connections between the two using nftables.

Best, Cyril

Windl, Ulrich u.windl@ukr.de hat am 29.07.2025 07:57 CEST geschrieben:

Hi!

I had a similar situation with delta-syncrepl, and I’d wish there were a tool like “touch” to force sending out the current object to the other servers. This problem is specific to delta-syncrepl, I guess (as the other methods will most likely “pull” any missing objects)

Kind regards,

Ulrich Windl

From: cyril@stoll.info cyril@stoll.info Sent: Monday, July 28, 2025 11:52 AM To: openldap-technical@openldap.org Subject: [EXT] Transform glue object to organizationalUnit

Hi

For some reason (probably after update to openldap-ltb 2.6.10, or after reload due to renewed certificate) we lost one organizationalUnit object on one of our two provider servers. However there are still two user objects that belong to this lost organzationalUnit. Therefore openldap created a glue object for the lost organizationalUnit.

On the second provider server (setup as multiprovider with the first one) the organzationalUnit object is still present and all looks like it should. I have no idea why one of the providers is still ok and the other is not since they are otherwise in sync as far as I can tell.

Unfortunately I did not find clear instructions on how to handle this situation. The best instructions I found are 15 years old: http://blog.mycroes.nl/2010/06/recovering-from-glue-objects-in.html

I have no experience with dumping everything with slapcat, deleting the whole database directory (scary) and importing everything again and it does sound a bit brutish.

So I asked some AI and it suggested to use ldapmodify to replace the glue object with an ldif like this:

dn: ou=serviceusers,dc=example,dc=com changetype: modify add: objectClass objectClass: organizationalUnit

add: ou ou: serviceusers

However that did not work as I got the following error message:

modifying entry "ou=serviceusers,dc=example,dc=com" ldap_modify: No such object (32) matched DN: ou=serviceusers,dc=example,dc=com

So my question is do I have to use the method of dumping everything with slapcat and then changeing the ldif (rewrite glue to organziationalUnit, etc.) and importing it all again? Or is there a more elegant solution to get the organizationalUnit back?

Thanks already in advance for every helping suggestion/link/explanation!

Best regards,

Cyril

Hi

Phil Pishioneri pgp@psu.edu hat am 29.07.2025 14:37 CEST geschrieben:

...

Hi!

I had a similar situation with delta-syncrepl, and I’d wish there were a tool like “touch” to force sending out the current object to the other servers. This problem is specific to delta-syncrepl, I guess (as the other methods will most likely “pull” any missing objects)

To force an object to sync I used to modify or temporarily add an attribute not relevant to the object. Typically, in my case, I added "description", let the object sync, then deleted that attribute.

Thanks for the hint. I did try that also with a description attribute. However on the "broken" provider server the object still was just a glue object and did not get synced despite the new attribute. I will try Howards suggestion with the manageDSAit control.

Best regards, Cyril