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

Reply via email to