Full_Name: Jochen Keutel Version: 2.4.46 OS: Debian 9 URL: Submission from: (NULL) (80.146.191.218) With certain configurations it happens that the attribute namingContexts of the rootDSE contains the same value twice (which is not correct). It seems to be related to the fact that the naming context of a hidden backend is not ignored (servers/slapd/root_dse.c). To reproduce it: I started to configure replication: szenario syncrepl proxy (push based replication, see 18.3.5 in OpenLDAP Admin Guide - "primary directory also contains back-ldap databases"). Configuring the LDAP backend leads unfortunately to a root DSE showing the same name context twice: namingContexts: dc=keutel,dc=de namingContexts: dc=keutel,dc=de Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It prints a lot of PHP arrays in this case. I've set "hidden on" for this backend but the problem remains. My configuration: 1. slapd.conf on server1 (master): database mdb suffix "dc=keutel,dc=de" ... database ldap hidden on suffix "dc=keutel,dc=de" rootdn "cn=admin,dc=keutel,dc=de" uri ldaps://server2/ lastmod on restrict all acl-bind bindmethod=simple binddn="cn=replication,dc=keutel,dc=de" credentials=secret syncrepl rid=001 provider=ldaps://server1/ binddn="cn=replication,dc=keutel,dc=de" bindmethod=simple credentials=secret searchbase="dc=keutel,dc=de" type=refreshAndPersist retry="5 5 300 5" 2. converting this to dynamic config using slaptest gives the following entry: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcHidden: TRUE olcSuffix: dc=keutel,dc=de ... 3. starting slapd with this dynamic configuration 4. reading rootDSE: attribute namingContexts occurs twice with the same value.
jochen@keutel.de wrote: > Full_Name: Jochen Keutel > Version: 2.4.46 > OS: Debian 9 > URL: > Submission from: (NULL) (80.146.191.218) > > > With certain configurations it happens that the attribute namingContexts of the > rootDSE contains the same value twice (which is not correct). It seems to be > related to the fact that the naming context of a hidden backend is not ignored > (servers/slapd/root_dse.c). Thanks for the report. Fixed now in git master. > > To reproduce it: I started to configure replication: szenario syncrepl proxy > (push based replication, see 18.3.5 in OpenLDAP Admin Guide - "primary directory > also contains back-ldap databases"). Configuring the LDAP backend leads > unfortunately to a root DSE showing the same name context twice: > > namingContexts: dc=keutel,dc=de > namingContexts: dc=keutel,dc=de > > Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It prints a > lot of PHP arrays in this case. > > I've set "hidden on" for this backend but the problem remains. > > My configuration: > > 1. slapd.conf on server1 (master): > > database mdb > suffix "dc=keutel,dc=de" > ... > > database ldap > hidden on > suffix "dc=keutel,dc=de" > rootdn "cn=admin,dc=keutel,dc=de" > uri ldaps://server2/ > > lastmod on > restrict all > > acl-bind bindmethod=simple > binddn="cn=replication,dc=keutel,dc=de" > credentials=secret > > syncrepl rid=001 > provider=ldaps://server1/ > binddn="cn=replication,dc=keutel,dc=de" > bindmethod=simple > credentials=secret > searchbase="dc=keutel,dc=de" > type=refreshAndPersist > retry="5 5 300 5" > > 2. converting this to dynamic config using slaptest gives the following entry: > > > dn: olcDatabase={2}ldap > objectClass: olcDatabaseConfig > objectClass: olcLDAPConfig > olcDatabase: {2}ldap > olcHidden: TRUE > olcSuffix: dc=keutel,dc=de > ... > > 3. starting slapd with this dynamic configuration > > 4. reading rootDSE: attribute namingContexts occurs twice with the same value. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
fixed in master fixed in RE24 (2.4.47)
changed notes changed state Release to Closed
On Fedora Core 36, @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ openldap Included static backends: config ldif monitor mdb using LDAP Browser\Editor v2.8.1: While attempting to add subordinate naming contexts off of base DN "" (RootDSE), slapd will only show such subordinate naming contexts if they are of the same RDN attribute. For instance, using all of FC36's trusted CA certificates DN, which boil down to those based at c=?, or o=?, only those of the same attribute will display as subordinates to "". I either get all c= or o=, but not both. The subordinate naming context attribute that comes in the configuration file determines which attribute will be shown.
(In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah
Created attachment 913 [details] attachment-466-0.html Thank you for the reply and my apologies for the lack of clarity. Upon further testing, I was unable to reproduce the behavior using a command line application, ldapsearch. I should have done that before submitting the bug. If you have been assigned this issue then please close it. I hope this is more clear: When attempting to display all of the subordinate partitions in the root partition I was only able to see a portion. Those displayed results were all of the same naming context, relative DN c=* or o=*. There is some form of filtering done by the LDAPBrowser GUI. This does not happen using ldapsearch. The problem is not in slapd as I initially thought. Thanks again for your reply. --Cliff On Monday, September 12, 2022 at 12:44:54 PM EDT, <openldap-its@openldap.org> wrote: https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah@openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah