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 <[email protected]> > Sent: Tuesday, March 17, 2026 10:44 AM > To: [email protected]; [email protected] > 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: [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
