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: [email protected] <[email protected]> > Sent: Monday, March 16, 2026 7:32 PM > To: [email protected] > 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
