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,