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

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.

You probably just need to use the manageDSAit control.

Thanks for the hint. Will have to read up on that as I have no idea how to do that. I will look into it in the next days.

Best regards, Cyril

Thanks again to everyone who replied to my original request from July 2025. As everything was working fine due to the glue object that OpenLDAP created to replace the lost database/tree I wasn't in a particular hurry to mess with the Server. Mainly because I was afraid to break something for real. In the meantime on the other provider server the database/tree (ou=admin,dc=domain,dc=tld) also somehow got lost and replaced by a glue object. But still everything was working and I was busy with other projects. Last week on the second provider server the two objects (a syncrepl user and a user for OpenLDAP access by our monitoring system) inside the glue database/tree got lost. By now I start to question the stability of OpenLDAP but that is another topic. However, this pleasing occurrence got me motivated to finally take care of the issue.

I'm happy to report that the fix was incredibly easy thanks to the hint regarding the manageDSAit control (thanks again!). In the end I used ldapmodify -M with the following ldif file and now the missing database/tree is no longer a glue object and therefore actually shows up again when querying OpenLDAP (e.g., with slapcat and Apache Directory Studio). So in case anyone else has a similar issue, maybe this ldif and the -M option for ldapmodify can help you as well which is why I decided to post again even though the original post is over half a year old.

dn: ou=admin,dc=domain,dc=tld changetype: modify replace: objectClass objectClass: organizationalUnit - add: ou ou: admin

Best regards, Cyril

Sorry for the stupid " Sicherheits-Hinweis:"! I forgot to remove in the cited message. IT stuff here thinks it's cool to modify any message from outside adding such banner...

Kind regards, Ulrich Windl

-----Original Message----- From: Windl, Ulrich u.windl@ukr.de Sent: Tuesday, March 17, 2026 10:44 AM To: cyril@stoll.info; openldap-technical@openldap.org Subject: [EXT] RE: [EXT] Re: Transform glue object to organizationalUnit

Hi!

Probably not useful at all, but independent of any software product a proven strategy is to start with a configuration that works as planned, preferably a simple configuration. THEN break it (sorry: joke: "extend"/"improve" it). If it broke, try to find out what broke it, and fix it. Then go for another iteration.

Kind regards, Ulrich Windl

...

-----Original Message----- From: cyril@stoll.info cyril@stoll.info Sent: Monday, March 16, 2026 7:32 PM To: openldap-technical@openldap.org Subject: [EXT] Re: Transform glue object to organizationalUnit

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.

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.

...

...

...

You probably just need to use the manageDSAit control.

Thanks for the hint. Will have to read up on that as I have no idea how to

do

...

that. I will look into it in the next days.

...

Best regards, Cyril

Thanks again to everyone who replied to my original request from July 2025. As everything was working fine due to the glue object that OpenLDAP

created

...

to replace the lost database/tree I wasn't in a particular hurry to mess with

the

...

Server. Mainly because I was afraid to break something for real. In the meantime on the other provider server the database/tree (ou=admin,dc=domain,dc=tld) also somehow got lost and replaced by a glue object. But still everything was working and I was busy with other projects. Last week on the second provider server the two objects (a syncrepl user

and

...

a user for OpenLDAP access by our monitoring system) inside the glue database/tree got lost. By now I start to question the stability of OpenLDAP but that is another topic. However, this pleasing occurrence got me

motivated

...

to finally take care of the issue.

I'm happy to report that the fix was incredibly easy thanks to the hint regarding the manageDSAit control (thanks again!). In the end I used ldapmodify -M with the following ldif file and now the missing database/tree is no longer a glue object and therefore actually shows up again when querying OpenLDAP (e.g., with slapcat and Apache Directory Studio). So in case anyone else has a similar issue, maybe this ldif and the -M option for ldapmodify can help you as well which is why I decided to post again even though the original post is over half a year old.

dn: ou=admin,dc=domain,dc=tld changetype: modify replace: objectClass objectClass: organizationalUnit

add: ou ou: admin

Best regards, Cyril

On Mon, Mar 16, 2026 at 07:31:36PM +0100, cyril@stoll.info wrote:

Thanks again to everyone who replied to my original request from July 2025. As everything was working fine due to the glue object that OpenLDAP created to replace the lost database/tree I wasn't in a particular hurry to mess with the Server. Mainly because I was afraid to break something for real. In the meantime on the other provider server the database/tree (ou=admin,dc=domain,dc=tld) also somehow got lost and replaced by a glue object. But still everything was working and I was busy with other projects. Last week on the second provider server the two objects (a syncrepl user and a user for OpenLDAP access by our monitoring system) inside the glue database/tree got lost. By now I start to question the stability of OpenLDAP but that is another topic. However, this pleasing occurrence got me motivated to finally take care of the issue.

Hi Cyril, are you running delta-syncrepl? If so, you can have a look at the accesslog to see when and why it removed the object. With that, sync-level logging and checking your ACLs that the replication user can indeed read the entry from the other provider should be able to pinpoint the issue. If it does not, you could provide the above plus relevant configuration here (with private data sanitised) and we can help you get to the bottom of it.

Also you mention glue, there are ways to set up glued replication correctly and they look very similar to glued DB replication that will only appear to work until it doesn't. The order of overlays matters (I think you have to put the glue overlay in a specific position related to syncprov) and AFAIK the syncrepl stanzas should only be configured on the top level database? But it's been a while since I had to set it up last time because as a rule, I try not to mix those if I can.

Regards,