OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/7145
Full headers

From: michael@stroeder.com
Subject: cn=Connection 0,cn=Connections,cn=Monitor received twice
Compose comment
Download message
State:
0 replies:
15 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 01 Feb 2012 20:30:37 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: cn=Connection 0,cn=Connections,cn=Monitor received twice
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.

Followup 1

Download message
Subject: Re: (ITS#7145) cn=Connection 0,cn=Connections,cn=Monitor received
 twice
From: Peter Varkoly <varkoly@suse.com>
To: openldap-its@OpenLDAP.org
Cc: michael@stroeder.com
Date: Wed, 21 Jan 2015 12:11:11 +0100
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




Followup 2

Download message
Date: Wed, 21 Jan 2015 11:48:08 +0000
From: Howard Chu <hyc@symas.com>
To: varkoly@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0, cn=Connections, cn=Monitor
 received twice
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/



Followup 3

Download message
Date: Mon, 09 Mar 2015 17:03:53 +0100
From: Howard Guo <hguo@suse.com>
To: openldap-its@OpenLDAP.org
CC: michael@stroeder.com
Subject: Re: (ITS#7145) cn=Connection 0
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



Followup 4

Download message
Date: Mon, 09 Mar 2015 17:41:56 +0100
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
This is a cryptographically signed message in MIME format.

--------------ms090109090403050107010203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hguo@suse.com wrote:
> After experimenting with monitoring DB myself, I have figured out a=20
> minimal reproducable test case, I am afraid that the issue still shows =

> up in 2.4.39 (distributed by SUSE Server 12).
>=20
> The 2.4.40 changelog does not seem to suggest any relevant bug fix, but=
=20
> 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:/netwo=
rk:/ldap/SLE_12/

I hope these will make it into mainstream:

https://build.opensuse.org/package/show/home:stroeder:branches:network:ld=
ap/openldap2

Ciao, Michael.



--------------ms090109090403050107010203
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1
WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD
DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl
ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk
M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ
OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y
0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5
wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS
j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ
tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud
EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE
AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj
eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo
ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw
b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs
aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap
oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB
BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx
L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2F

Message of length 6883 truncated


Followup 5

Download message
Date: Tue, 10 Mar 2015 11:25:43 +0100
From: Howard Guo <hguo@suse.com>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, 
 openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.
>
>




Followup 6

Download message
Date: Fri, 10 Apr 2015 10:57:54 +0200
From: Howard Guo <hguo@suse.com>
To: openldap-its@OpenLDAP.org, michael@stroeder.com
Subject: Re: (ITS#7145) cn=Connection 0
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





Followup 7

Download message
Date: Fri, 10 Apr 2015 11:41:14 +0200
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.



Followup 8

Download message
Date: Fri, 10 Apr 2015 11:46:39 +0200
From: Howard Guo <hguo@suse.com>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, 
 openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.
>




Followup 9

Download message
Date: Fri, 10 Apr 2015 14:29:31 +0200
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.



Followup 10

Download message
Date: Fri, 10 Apr 2015 14:38:56 +0200
From: Howard Guo <hguo@suse.com>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, 
 openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.
> .




Followup 11

Download message
Date: Fri, 10 Apr 2015 15:08:50 +0200
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
This is a cryptographically signed message in MIME format.

--------------ms040201060806000805040605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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=20
installation if it's still an issue.

But IMO it's not the correct solution to completely mask out Connection 0=
=2E

Ciao, Michael.



--------------ms040201060806000805040605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG
9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw
NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG
A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4
uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk
Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK
JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih
34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v
KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj
z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf
BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL
KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0
byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodH

Message of length 6820 truncated


Followup 12

Download message
Date: Fri, 10 Apr 2015 15:20:20 +0200
From: Howard Guo <hguo@suse.com>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, 
 openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.
>
>




Followup 13

Download message
Date: Fri, 10 Apr 2015 15:23:39 +0200
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.




Followup 14

Download message
Date: Fri, 10 Apr 2015 15:41:27 +0200
From: Howard Guo <hguo@suse.com>
To: =?windows-1252?Q?Michael_Str=F6der?= <michael@stroeder.com>, 
 openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.
>
>




Followup 15

Download message
Date: Fri, 10 Apr 2015 15:44:13 +0200
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <michael@stroeder.com>
To: hguo@suse.com, openldap-its@OpenLDAP.org
Subject: Re: (ITS#7145) cn=Connection 0
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.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org