Full_Name: Version: RE24 22ee28752e3e0d2a6910a22922fc69befd78578a OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.34.231) When querying cn=Monitor there are two entries returned with the same DN cn=Connection 0,cn=Connections,cn=Monitor This is a MMR setup with two nodes.
Hallo, I've the same issue on SLES11-SP3. openLDAP version 2.4.26 Kernel 3.0.101-0.15-default sles11-sp3-krb5-master:~ # ldapsearch -Y EXTERNAL -H ldapi:// -b cn=Connections,cn=Monitor -s sub '(cn=Connection 0)' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=Connections,cn=Monitor> with scope subtree # filter: (cn=Connection 0) # requesting: ALL # # Connection 0, Connections, Monitor dn: cn=Connection 0,cn=Connections,cn=Monitor objectClass: monitorConnection cn: Connection 0 # Connection 0, Connections, Monitor dn: cn=Connection 0,cn=Connections,cn=Monitor objectClass: monitorConnection cn: Connection 0 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Was this issue fixed already? -- Peter Varkoly Sr. Developer SUSE Linux Enterprise Applications SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany
varkoly@suse.com wrote: > Hallo, > > I've the same issue on SLES11-SP3. openLDAP version 2.4.26 > Was this issue fixed already? No, there was never any information provided on how to reproduce it. But 2.4.26 is quite old, do you still see this occurring using 2.4.40? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hello Mr.Chu. After experimenting with monitoring DB myself, I have figured out a minimal reproducable test case, I am afraid that the issue still shows up in 2.4.39 (distributed by SUSE Server 12). The 2.4.40 changelog does not seem to suggest any relevant bug fix, but I will give it a try anyway. May I help by attaching the test case? Which Linux distribution would you like to use for testing? Thanks very much. Kind regards, Howard Guo SUSE LINUX Products GmbH
hguo@suse.com wrote: > After experimenting with monitoring DB myself, I have figured out a > minimal reproducable test case, I am afraid that the issue still shows > up in 2.4.39 (distributed by SUSE Server 12). > > The 2.4.40 changelog does not seem to suggest any relevant bug fix, but > I will give it a try anyway. You could easily try with 2.4.40 with my SLES12 packages: http://download.opensuse.org/repositories/home:/stroeder:/branches:/network:/ldap/SLE_12/ I hope these will make it into mainstream: https://build.opensuse.org/package/show/home:stroeder:branches:network:ldap/openldap2 Ciao, Michael.
Good day Michael. Thanks you very much for the packages, they work in SLES 12! But unfortunately my test case is still able to reproduce the issue using version 2.4.40. Would you like to try out the test case? If so I'll tailor the test case code to your choice of Linux distribution. Kind regards, Howard Guo SUSE LINUX Products GmbH On 09/03/15 17:41, Michael Ströder wrote: > hguo@suse.com wrote: >> After experimenting with monitoring DB myself, I have figured out a >> minimal reproducable test case, I am afraid that the issue still shows >> up in 2.4.39 (distributed by SUSE Server 12). >> >> The 2.4.40 changelog does not seem to suggest any relevant bug fix, but >> I will give it a try anyway. > You could easily try with 2.4.40 with my SLES12 packages: > > http://download.opensuse.org/repositories/home:/stroeder:/branches:/network:/ldap/SLE_12/ > > I hope these will make it into mainstream: > > https://build.opensuse.org/package/show/home:stroeder:branches:network:ldap/openldap2 > > Ciao, Michael. > >
Good day! The appearance of connections with ID 0 in the Monitor backend seems entirely cosmetic and does not affect the normal operation of OpenLDAP server. I created a patch against the latest source code and uploaded the patch "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, monitor backend no longer returns connection ID 0 to the LDAP client. Please review - many thanks. Kind regards, Howard Guo SUSE LINUX Products GmbH
hguo@suse.com wrote: > I created a patch against the latest source code and uploaded the patch > "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, > monitor backend no longer returns connection ID 0 to the LDAP client. I'm curious: Which problem do you want to solve? Ciao, Michael.
The patch is a proposed resolution to the issue. To prevent monitor backend from returning invalid result about Connection 0, it will simply not report information about the connection 0. Kind regards, Howard On 10/04/15 11:41, Michael Ströder wrote: > hguo@suse.com wrote: >> I created a patch against the latest source code and uploaded the patch >> "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, >> monitor backend no longer returns connection ID 0 to the LDAP client. > > I'm curious: Which problem do you want to solve? > > Ciao, Michael. >
hguo@suse.com wrote: > The patch is a proposed resolution to the issue. > > To prevent monitor backend from returning invalid result about > Connection 0, it will simply not report information about the connection 0. Indeed I do understand what your patch does. But what is the real problem with Connection 0 you're trying to solve? Note that slapd internally access the database(s). So your monitoring checks should simply ignore this Connection 0. Ciao, Michael.
According to the issue report, the connection 0's DN appears not only once, but twice, in some circumstances. Duplicated DN should not have appeared in server response. Apart from that, connection 0 does not serve any purpose for LDAP clients, therefore its connection details are not useful. What do you think? Kind regards, Howard On 10/04/15 14:29, Michael Ströder wrote: > hguo@suse.com wrote: >> The patch is a proposed resolution to the issue. >> >> To prevent monitor backend from returning invalid result about >> Connection 0, it will simply not report information about the >> connection 0. > > Indeed I do understand what your patch does. > > But what is the real problem with Connection 0 you're trying to solve? > Note that slapd internally access the database(s). So your monitoring > checks should simply ignore this Connection 0. > > Ciao, Michael. > .
hguo@suse.com wrote: > According to the issue report, the connection 0's DN appears not only > once, but twice, in some circumstances. Duplicated DN should not have > appeared in server response. > > Apart from that, connection 0 does not serve any purpose for LDAP > clients, therefore its connection details are not useful. Yes, the duplicate occurence should be fixed. I have to check in my installation if it's still an issue. But IMO it's not the correct solution to completely mask out Connection 0. Ciao, Michael.
Last month when I tried OpenLDAP 2.4.40 using your SLES 12 package, I was still able to get two Connection0s to show up in one response. It'll be a great news if that's no longer the case with the next release. Kind regards, Howard On 10/04/15 15:08, Michael Ströder wrote: > hguo@suse.com wrote: >> According to the issue report, the connection 0's DN appears not only >> once, but twice, in some circumstances. Duplicated DN should not have >> appeared in server response. >> >> Apart from that, connection 0 does not serve any purpose for LDAP >> clients, therefore its connection details are not useful. > > Yes, the duplicate occurence should be fixed. I have to check in my > installation if it's still an issue. > > But IMO it's not the correct solution to completely mask out > Connection 0. > > Ciao, Michael. > >
Michael Ströder wrote: > Yes, the duplicate occurence should be fixed. I have to check in my > installation if it's still an issue. Using a local build from RE24 branch I cannot see the duplicate occurence of cn=Connection 0,cn=Connections,cn=Monitor anymore. Ciao, Michael.
Is your build identical to the 2.4.40 on OBS in terms of patches/source code revision? What distribution did you use for testing? Kind regards, Howard On 10/04/15 15:23, Michael Ströder wrote: > Michael Ströder wrote: >> Yes, the duplicate occurence should be fixed. I have to check in my >> installation if it's still an issue. > > Using a local build from RE24 branch I cannot see the duplicate > occurence of > cn=Connection 0,cn=Connections,cn=Monitor anymore. > > Ciao, Michael. > >
hguo@suse.com wrote: > Is your build identical to the 2.4.40 on OBS in terms of patches/source > code revision? No. It's RE24 with all changes to be released as 2.4.41. > What distribution did you use for testing? openSUSE Tumbleweed x86_64. Ciao, Michael.
Good day Michael. I built the branch OPENLDAP_REL_ENG_2_4 revision d281bd3, unfortunately connection 0 still shows up twice. The source code of my test case is here: https://github.com/HouzuoGuo/ldap-conn0 Would you mind to try it out in your test environment? Thanks. Regards, Howard On 10/04/15 15:44, Michael Ströder wrote: > hguo@suse.com wrote: >> Is your build identical to the 2.4.40 on OBS in terms of patches/source >> code revision? > > No. It's RE24 with all changes to be released as 2.4.41. > >> What distribution did you use for testing? > > openSUSE Tumbleweed x86_64. > > Ciao, Michael. > .
moved from Incoming to Software Bugs
Note: This has a test case, should be trivial to see if we can reproduce it.
(In reply to Quanah Gibson-Mount from comment #18) > Note: This has a test case, should be trivial to see if we can reproduce it. Note that the standard package for openSUSE/SLE removes conn=0 from cn=monitor completely: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0008-In-monitor-backend-do-not-return-Connection0-entries.patch?expand=1 With my own 2.4.49 builds without the above patch conn=0 is only returned once. IMHO you can close this.
(In reply to Michael Ströder from comment #19) > (In reply to Quanah Gibson-Mount from comment #18) > > Note: This has a test case, should be trivial to see if we can reproduce it. > > Note that the standard package for openSUSE/SLE removes conn=0 from > cn=monitor completely: > > https://build.opensuse.org/package/view_file/network:ldap/openldap2/0008-In- > monitor-backend-do-not-return-Connection0-entries.patch?expand=1 > > With my own 2.4.49 builds without the above patch conn=0 is only returned > once. > > IMHO you can close this. Thanks Michael!