- openldap-bugs - openldap.org

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 5:49 PM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > > From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the > cases that the slappasswd user has also write access to back-config? The tool has allowed the ability to generate password values for years. It is not uncommon to use it to do just that. I've often used it to generate base-64 encoded SSHA values to push into LDIF I will be writing to the server via ldapmodify. That should not require access to cn=config/slapd.conf. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

hyc(a)symas.com wrote: > Why should X user ever need to run this tool to generate a value? >From slappasswd(8): DESCRIPTION Slappasswd is used to generate an userPassword value suitable for use with ldapmodify(1), slapd.conf(5) rootpw configuration directive or the slapd-config(5) olcRootPW configuration directive. Do you want to restrict this text regarding ldapmodify(1) only for the cases that the slappasswd user has also write access to back-config? Of course your are the OpenLDAP boss. You can change everything to make it work for you. But it breaks existing operational procedures for other people. Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Doesn't this ask for fully integrating SHA-2 password support into >> libraries/liblutil/passwd.c? > > Clearly you haven't thought this through. Maybe. But one question: Why is SHA-1 in the core and SHA-2 isn't? IMO that's just an arbitrary choice. > No, because that doesn't solve the problem of how to use other contrib passwd > modules. If you come up with another overall solution to avoid reading the config when using slappasswd I'm of course fine with that too. Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

Quanah Gibson-Mount wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: > >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrator >> access already you have no business running it. > > What in any way makes it administrative? You simply give it a password to > convert into whatever scheme for you. Where is the administrative > requirement? Why shouldn't X user with some particular permissions into > the database, but not the configuration, be able to run it to generate a > value? slap*(8) are all administrative tools, by definition. You should already know that. Why should X user ever need to run this tool to generate a value? slapd generates users' password values automatically. The only time anyone ever *needs* this tool is for setting a rootpw in the slapd config. That's the only reason this tool exists and it is the only valid use case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

michael(a)stroeder.com wrote: > Doesn't this ask for fully integrating SHA-2 password support into > libraries/liblutil/passwd.c? Clearly you haven't thought this through. No, because that doesn't solve the problem of how to use other contrib passwd modules. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

Kurt(a)OpenLDAP.org wrote: > I'd argue that slappassword shouldn't read the configuration and hence not > support 'contributed' hash mechanisms. Which means if SHA-2 stays in a separate overlay contrib/ there won't be practically usable SHA-2 support in OpenLDAP. I consider it falling behind other LDAP server implementations. > But if you are going to make slappassword read the configuration, then it > needs to be restricted to only users who have read access to the > configuration. Yes. > I have no real opinion about whether SHA-2 should or shouldn't be in the > core set of hashes... but personally I rather push folks towards SCRAM > compatible hashes than the same poor usages of newer hash algorithms. I concur that SCRAM would be the best choice. But IMO adding SHA-2 support to the core does not hold anybody back from developing/deploying SCRAM. In reality getting completely rid of simple bind in favour of SASL bind no matter which SASL mech is nothing done so easily with all the applications out in the wild. And last time I checked SCRAM support in cyrus-sasl required clear-text password in userPassword. So this is outside the OpenLDAP project, isn't it? Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by Kurt＠OpenLDAP.org 29 May '12

29 May '12

I'd argue that slappassword shouldn't read the configuration and hence not support 'contributed' hash mechanisms. But if you are going to make slappassword read the configuration, then it needs to be restricted to only users who have read access to the configuration. I have no real opinion about whether SHA-2 should or shouldn't be in the core set of hashes... but personally I rather push folks towards SCRAM compatible hashes than the same poor usages of newer hash algorithms. -- Kurt

1 0

(ITS#7282) Invalid Regex in Documentation
by alacer.cogitatus＠gmail.com 29 May '12

29 May '12

Full_Name: Kyle Smith Version: 2.4.30 OS: Ubuntu Server 10.04.02LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.245.87.13) In section 8.2.5 of the OpenLDAP Documentation (Access Control Examples), the example regex to allow an IP address is given by: by peername.regex=IP:10\..+ read I think it should read: by peername.regex=IP=10\..+ read

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms010700080803040702000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: >=20 >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrat= or >> access already you have no business running it. >=20 > What in any way makes it administrative? You simply give it a password= to=20 > convert into whatever scheme for you. Where is the administrative=20 > requirement? Why shouldn't X user with some particular permissions int= o=20 > the database, but not the configuration, be able to run it to generate = a=20 > value? I concur with Quanah: I know many operational procedures where slappasswd= is just used to generate pre-hashed userPassword values. This usage is suppo= rted by DESCRIPTION in slappasswd(8). I also don't see a requirement for administrative access to slapd's config at all. Doesn't this ask for fully integrating SHA-2 password support into libraries/liblutil/passwd.c? Ciao, Michael. --------------ms010700080803040702000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE2NDYzOFowIwYJKoZIhvcNAQkEMRYE FE1pvmOeFeNxFwX+H8VmVvMDK6OWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAG+NichvhG0i4Tb18NExkCpBoGmzkaf3J/WSiwU5y01mEOEct8YvtixC3EdVlpVfKYOLb pKDGt2W6yNZySAEkQqZlWffWaYou3aJF5t/DjykuqpvBR0wNO1casY8OGAHMX1g0RicGIS12 30Ulk8vJTYQy3hMovlfztgHaEE7yI8Acem9ccJAuFoXbTCyDC47HcDf/pL4en6WGyMkyruhR 0vULseO+OUQ+LY+ic4C8qPXAtSnDrCPmUaOcns7Nz2cuZFgPe7dVt4NcXpsKXihy+PIag+Tz iiskIJ7u4iQaPFW2QBDZrmpa8UPCaWOy6KjtDDF8TNj5LwewODIJZ03kMAAAAAAAAA== --------------ms010700080803040702000401--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: >> It is a problem that a slappasswd user must have read privilage >> on slapd.conf (or slapd.d) by this patch... > > slappasswd is an administrative command; if you don't have administrator > access already you have no business running it. What in any way makes it administrative? You simply give it a password to convert into whatever scheme for you. Where is the administrative requirement? Why shouldn't X user with some particular permissions into the database, but not the configuration, be able to run it to generate a value? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

fumiyas(a)osstech.co.jp wrote: > At Tue, 29 May 2012 05:49:52 GMT, > fumiyas@OSSTech wrote: >>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch >> >> In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. >> Sorry. > > FYI. > > [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules > https://gist.github.com/2632560 > > It is a problem that a slappasswd user must have read privilage > on slapd.conf (or slapd.d) by this patch... slappasswd is an administrative command; if you don't have administrator access already you have no business running it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 29 May '12

29 May '12

At Tue, 29 May 2012 05:49:52 GMT, fumiyas@OSSTech wrote: > > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch > > In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. > Sorry. FYI. [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules https://gist.github.com/2632560 It is a problem that a slappasswd user must have read privilage on slapd.conf (or slapd.d) by this patch... > > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > > to slapd-sha2 module. > > > > This patch depends on > > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 28 May '12

28 May '12

At Thu, 24 May 2012 01:32:33 GMT, fumiyas@OSSTech wrote: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. Sorry. > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > to slapd-sha2 module. > > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7280) accesslog write to subentry of log database
by openldap＠stormcloud9.net 27 May '12

27 May '12

This is a multi-part message in MIME format. --------------060900070300040405040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <hyc(a)symas.com> To: openldap(a)stormcloud9.net openldap-its(a)openldap.org Subject: Re: (ITS#7280) accesslog write to subentry of log database > openldap(a)stormcloud9.net wrote: >> Full_Name: Patrick Hemmer >> Version: 2.4.31 >> OS: Linux RHEL6 >> URL: >> Submission from: (NULL) (98.211.220.204) >> >> >> This is a feature request (mostly). >> >> Currently the accesslog overlay is only capable of writing to the >> base DN of a >> log database, and not a subentry of that database. Specifying the DN >> to a >> specific subentry for the "logdb" parameter ends up writing to the >> base DN of >> the database instead. >> >> The main reason for this is so that multiple accesslog overlays can >> write to the >> same backend database, and not have to create a separate database for >> each >> overlay. Currently if you try to give multiple accesslog overlays the >> same >> database, it causes deadlock issues (or it appears to be a deadlock) >> and write >> operations end up hanging. I'm not sure if this should be considered >> a bug, or >> just noted as "don't try and do that". > > Don't do that. Closing this ITS. > This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick --------------060900070300040405040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000066"> Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <a class="moz-txt-link-rfc2396E" href="mailto:hyc@symas.com"><hyc(a)symas.com></a> To: <a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> Subject: Re: (ITS#7280) accesslog write to subentry of log database <blockquote cite="mid:4FC2B270.9090900@symas.com" type="cite"><a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> wrote: <blockquote type="cite">Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that". </blockquote> Don't do that. Closing this ITS. </blockquote> This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick </body> </html> --------------060900070300040405040602--

1 0

Re: (ITS#7280) accesslog write to subentry of log database
by hyc＠symas.com 27 May '12

27 May '12

openldap(a)stormcloud9.net wrote: > Full_Name: Patrick Hemmer > Version: 2.4.31 > OS: Linux RHEL6 > URL: > Submission from: (NULL) (98.211.220.204) > > > This is a feature request (mostly). > > Currently the accesslog overlay is only capable of writing to the base DN of a > log database, and not a subentry of that database. Specifying the DN to a > specific subentry for the "logdb" parameter ends up writing to the base DN of > the database instead. > > The main reason for this is so that multiple accesslog overlays can write to the > same backend database, and not have to create a separate database for each > overlay. Currently if you try to give multiple accesslog overlays the same > database, it causes deadlock issues (or it appears to be a deadlock) and write > operations end up hanging. I'm not sure if this should be considered a bug, or > just noted as "don't try and do that". Don't do that. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7281) [cxx sasl] Gentoo build 2.4.31-r1 gcc-4.7 SaslInteractionHandler.cpp
by nheghathivhistha＠gmail.com 27 May '12

27 May '12

Full_Name: David Kredba Version: 2.4.31 OS: GNU/Linux-3.4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.112.13.17) make[2]: Entering directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' /bin/sh ../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c -o SaslInteractionHandler.lo SaslInteractionHandler.cpp x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c SaslInteractionHandler.cpp -fPIC -DPIC -o .libs/SaslInteractionHandler.o SaslInteractionHandler.cpp: In member function ‘virtual void DefaultSaslInteractionHandler::handleInteractions(const std::list<SaslInteraction*>&)’: SaslInteractionHandler.cpp:56:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:67:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:85:23: error: ‘STDIN_FILENO’ was not declared in this scope make[2]: *** [SaslInteractionHandler.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make: *** [all-recursive] Error 1 * ERROR: net-nds/openldap-2.4.31-r1 failed (compile phase): * emake failed I tried to add someof Google suggested header files (unistd.h etc) but no luck. Thank you.

1 0

Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by quanah＠zimbra.com 26 May '12

26 May '12

--On Monday, May 21, 2012 5:27 PM +0000 o.loch(a)gmx.net wrote: > > --Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=iso-8859-1 > > Hello, > > thanks for the reply. I followed your advice and played a bit with it = > and now it's working. > > It's interesting that you always have to include the core.schema even if = > you use a replicated config. <http://dictionary.reference.com/browse/core?s=t> noun 2. the central, innermost, or most essential part of anything. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7280) accesslog write to subentry of log database
by openldap＠stormcloud9.net 24 May '12

24 May '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that".

1 0

Re: (ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by brandon.hume＠dal.ca 24 May '12

24 May '12

On 05/24/12 02:08 PM, Michael Ströder wrote: > Are these the exact logs lines? I'm asking because $DN sounds to me like a > variable name used in a configuration template. Can cou please check that? No, that was me editing the line. Sorry, I should have labeled it as such.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 24 May '12

24 May '12

This is a cryptographically signed message in MIME format. --------------ms080105030301050607030109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master > OS:=20 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.p= atch > Submission from: (NULL) (220.100.28.128) >=20 >=20 > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes= > to slapd-sha2 module. >=20 > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=3D7269). I've not tested the patch yet. But I'd appreciate if SHA-2 support would = be available in the main source and not only under contrib/. Any objections against extending libraries/liblutil/passwd.c? Ciao, Michael. --------------ms080105030301050607030109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNDE4MDEzOFowIwYJKoZIhvcNAQkEMRYE FBBgedro2DSLuBwkyOrjr9ML7MbLMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAV8R0Hvk9iikbkpo4qm7yXeMwCsMbrDGhTWapYclEgt0tOJNJ945Zejk4slxyhECYfRDf 0BSn5GX8RKSzas408ybxgWfCeviPhHZhjB5+akya8OcFmyQ/eoGHFeK0uZNlG2PPs42dNgf9 Zi6P0vrfF/L+Nn9PsurDrKIkV5HOMwbm7tAJdpfkOVsmW1S50Wx18PjgjSs2DujKh8HYq211 BsdE19cU3IfMZPOdVW+GTSZmpJdzr4Zl8H9jtoyNiH4JHoSqI2eXlIQGqP+2x2Koj6F/il0r BXIxhEMN88wcp0QhX2TERg32wqKhLUK2kns2n75NyKEFh1sbo5v+SAQndQAAAAAAAA== --------------ms080105030301050607030109--

1 0

Re: (ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by michael＠stroeder.com 24 May '12

24 May '12

This is a cryptographically signed message in MIME format. --------------ms060600050204060402060803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable brandon.hume(a)dal.ca wrote: > May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 > May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=3D001 be_add $D= N failed > (80) Are these the exact logs lines? I'm asking because $DN sounds to me like = a variable name used in a configuration template. Can cou please check that= ? Ciao, Michael. --------------ms060600050204060402060803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNDE3MDgyNVowIwYJKoZIhvcNAQkEMRYE FAiOlD00zt7MfnmG7hCZfrsEL7koMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAQKcLJh/AADvbF4KTIcbr8XbQ/WRU+LfEJf3+n70z//r4/LIvlyCVT7Wld9rfI/14pmzS UOvfchywdnHEV4n4WCCOsBp0aqJQZUv3CA6n7mAqTHPYvORyjJ+YpNiLZj5u5W1qCXXn1Vwy 1pF+Lorl4t4yY3kC2v7wFHVV2KGaz/EMATMdoCeRSHW8x1gq8KMrblcKr2TzCT0HJkY+5ZJ8 qZRYlC8rjZIToht1dYIK5ZfHvMsLN7nz/ltPM4s5yuu7VGZFNCo3m5MIamZlKvSflK/0cHIQ VolbZgmDoogion7BSeeTp7pHsHuIlKuXLJXCIvnhvnDb8rgUBDEMLM80hgAAAAAAAA== --------------ms060600050204060402060803--

1 0

(ITS#7279) Apparently mdb "approx" index generation failure for mdb_add for syncrepl consumer
by brandon.hume＠dal.ca 24 May '12

24 May '12

Full_Name: Brandon Hume Version: 2.4.31 OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 URL: http://den.bofh.ca/~hume/mdb_approx_indexfail.tar Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) An empty syncrepl consumer using mdb backend will suffer index generator failures when populating its database from the provider and using "approx" index options. The failure manifests in syslog (with olcLogLevel=Stats) as the following: May 24 11:50:41 node2 slapd[25282]: null_callback : error code 0x50 May 24 11:50:41 node2 slapd[25282]: syncrepl_entry: rid=001 be_add $DN failed (80) These problems don't seem to occur when populating the provider using slapadd. The problem only seems to manifest when the new entry arrives via syncrepl. Playing with gdb, it seems like indexer() ends up being called with { bv_len = 0, bv_val = "" } when indexing "givenName". Could be because "givenName" on the troublesome entry is only one character? A minimalist DIT and config are provided in the tarfile in the link. The two nodes are running in mirrormode, and I'm not sure if that makes a difference. To reproduce: - On provider: slapadd -b cn=config -l mdb_approx_indexfail_config.ldif - On provider: slapadd -b dc=dal,dc=ca -l mdb_approx_indexfail_dit.ldif - On consumer: slapadd -b cn=config -l mdb_approx_indexfail_config.ldif - Start provider, confirm no errors - Start consumer, null_callback errors should appear immediately.

1 0

(ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 23 May '12

23 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch Submission from: (NULL) (220.100.28.128) This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes to slapd-sha2 module. This patch depends on ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch (http://www.openldap.org/its/index.cgi?findid=7269).

1 0

Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by o.loch＠gmx.net 21 May '12

21 May '12

--Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello, thanks for the reply. I followed your advice and played a bit with it = and now it's working. It's interesting that you always have to include the core.schema even if = you use a replicated config. Sorry for the wrong bug report and thanks again! KR, Oliver=20 Am 21.05.2012 um 01:46 schrieb Howard Chu: >> I played with it a bit and as soon as one adds "ou=3D..." or "dc=3D..."= to the >> binddn it raises an error. In this example config and in the "real = world". >>=20 >> Imho there aren't any limitations to the binddn option? >=20 > No, there are no limitations on binddn. Your example is invalid since = you have not loaded any schema to define the "ou" or "dc" attributes. = The error message from slapadd is correct. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20 --Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHCDCCBfCg AwIBAgIDA6CuMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwMTI5MTQ0MTM3WhcNMTMwMTI5MjE0MTE4WjBTMRkwFwYDVQQNExB6N0V1VjY4Q0xvemRSRHkx MRcwFQYDVQQDDA5vLmxvY2hAZ214Lm5ldDEdMBsGCSqGSIb3DQEJARYOby5sb2NoQGdteC5uZXQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmfq20gcAUPUePSPavAqfHQTuq75yNv9dj TkYkP1kWeohKxHnznc1so0WuaMo1Azt/01Z1zdMZ3m5Ix3Q1UxuVRh+ciRockHJZ36uWWesMLdwh /cdvgEeR+wqfceYuuW4Du8MDh9/+z4NCBJ6kvYQUXKZibthLaLssazBoHmvVDiwvmvDk2bLim+sC ywRelWWFAnlVDGFTsHN9DKe1jXljLDnNwcHRzJroSx01Dh4AhMMkz8ZUQtx3GInhZLjErRCdZ3Oj HDmZ8U2ABo1W7Hccux1U/70y6fOVOrQW7hkv1jPpGp1+713ONg4wc8PiGOHZHnIENBGBKOCGjd70 7zU9AgMBAAGjggOpMIIDpTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBF4b2lWP7cPi3uyf1fhXOfHBuA7MB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBkGA1UdEQQSMBCBDm8ubG9jaEBnbXgubmV0MIICIQYDVR0g BIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5n IHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAn FiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMi IG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwu c3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGG LWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEA aFgkPDQLgfzA2OCcUUaavf3yBb0JX83kkHtqpPJPs8AM7MEHgSwPtvDPfrArLZRVleQ5rE42QDrl UJQ1FBrSaRaGERjihOvbXy3UglGk23zZfpV+tG3FM/K6r3aoOTghqldly/nnXptgUiV+Xc8GVZgZ 3v9M8bqx4ypL4VTxZ9FrIKQ6IoLyuxCFRUutk/UaN9bT4bVjLrlC3E5jltmtdjFPcQOGsZ3B5IeC A8wWWiUrClvj1WJvBvgJ7o48F6mjdJYWZqzAQkQVkA0GmPsEb9YdWEyqygCnb1/oHmPYLzd7GZMS 8Yr0BFbSWB4vFdCI+eQg+xwBLD+bp8s4M+DodTGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0ECAwOgrjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1MjExNzI3MDFaMCMGCSqGSIb3DQEJBDEWBBR7+zXEwhx2 T0J+cWFbzao725HBOjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwOgrjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDA6CuMA0GCSqGSIb3DQEBAQUABIIBACE6nneTvZzl9cCgd7q/2Ee65O3vXs3BzLCeXlCC iS1yOOvo9udFSZlwY8tpSo8fKX6YDHAmRVliE/X+dUOPtIboyYJPIx+pJM66sULMDya194rYd9He VeHA0//o0hTeGBzVBoWto3+qH3fmQKNCrHd1mZOhfVgkWAn0W9K2YayJGV0sFDJaTYQ+2jlgrZHM AC1vhQltCcdOh5qF1X6YaOueFupm86bVo3YKuwY42VxkCAl9fAanwKR61pmXcH0wvACPgjO0d81w oUwhlNJ7aTJ2/yMrAh13qn06nwLMxjjUE1HzYH78zHLLoSZVmo0p49ykzLYVVRQzZVMtBpmMy7UA AAAAAAA= --Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D--

1 0

Re: (ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 21 May '12

21 May '12

Dear OpenLDAP Devs, I would like to ask if there is anything else I can do to speed up the inclusion of my patch?

1 0

Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by hyc＠symas.com 20 May '12

20 May '12

> I played with it a bit and as soon as one adds "ou=..." or "dc=..." to the > binddn it raises an error. In this example config and in the "real world". > > Imho there aren't any limitations to the binddn option? No, there are no limitations on binddn. Your example is invalid since you have not loaded any schema to define the "ou" or "dc" attributes. The error message from slapadd is correct. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by o.loch＠gmx.net 19 May '12

19 May '12

Full_Name: Oliver Loch Version: 2.4.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.134.36.68) Hello, first of all some basic information: OpenLDAP Version: [root@ls1 slapd.d]# slapd -V @(#) $OpenLDAP: slapd 2.4.31 (Apr 24 2012 01:06:25) $ nobody@ovide:/build/src/openldap-2.4.31/servers/slapd [root@ls1 slapd.d]# OS: Linux ls1 3.3.6-1-ARCH #1 SMP PREEMPT Sun May 13 10:52:32 CEST 2012 x86_64 GNU/Linux Distribution: ArchLinux What I'm doing: I have a Master/Master setup with actually two masters. To roll out the second master I created a small configuration that is added to the OpenLDAP database via slapadd. The config: ======>8========SNIP======================== dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 ldap://server1.foo.bar olcServerID: 2 ldap://server2.foo.bar dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb.la olcModuleLoad: {1}back_hdb.la olcModuleLoad: {2}accesslog olcModuleLoad: {3}memberof olcModuleLoad: {4}refint olcModuleLoad: {5}unique olcModuleLoad: {6}syncprov olcModulePath: /usr/lib/openldap dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=master,cn=config olcRootPW: {SSHA}5e/wtWWZVQPCNf+92o8jYiO56wvh5cRQ olcSyncrepl: rid=001 provider=ldap://server1.foo.bar bindmethod=simple timeout=0 network-timeout=0 binddn="cn=syncer1,ou=users,cn=foo,cn=bar" credentials="supersecret" keepalive=0:0:0 starttls=no searchbase="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 +" olcMirrorMode: TRUE dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ===========SNAP========8<==================== When adding the configuration to the - empty - slapd.d configuration directory via: slapadd -F /etc/openldap/slapd.d -n 0 -l /root/base.ldif "slapadd" segfaults as soon as the "binddn" parameter inside the olcSyncrepl attribute contains things like "ou" or "dc". So using "cn=syncer1,ou=users,dc=foo,dc=bar" as binddn is not possible: =========SNIP=======>8======================= [root@ls1 slapd.d]# slapadd -F /etc/openldap/slapd.d/ -n 0 -l /root/base.ldif 4fb89a89 invalid bind config value binddn=cn=syncer1,ou=users,dc=foo,dc=bar 4fb89a89 olcSyncrepl: value #0: Error: parse_syncrepl_line: unable to parse "binddn=cn=syncer1,ou=users,dc=foo,dc=bar" . 4fb89a89 failed to add syncinfo slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=19): _################# 86.13% eta none elapsed none spd 313.2 k/s Closing DB...Segmentation fault [root@ls1 slapd.d]# ===========SNAP========8<==================== But using "cn=syncer1,cn=users,cn=foo,cn=bar" is: ========>8==================SNIP============== [root@ls1 slapd.d]# slapadd -F /etc/openldap/slapd.d/ -n 0 -l /root/base.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... [root@ls1 slapd.d]# ======SNAP================8<================= I played with it a bit and as soon as one adds "ou=..." or "dc=..." to the binddn it raises an error. In this example config and in the "real world". Imho there aren't any limitations to the binddn option? If you need further information feel free to contact me. Thanks! Kr, Oliver Loch

1 0

(ITS#7276) [PATCH] MozNSS: allow CA certdb together with PEM CA bundle file
by jvcelak＠redhat.com 18 May '12

18 May '12

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120518-update-nss-allow-ca-certdb… Submission from: (NULL) (209.132.186.34) With Mozilla NSS crypto backend: Prior to this patch, if TLS_CACERTDIR was set to Mozilla NSS certificate database and TLS_CACERT was set to a PEM bundle file with CA certificates, the PEM file content was not loaded. With this patch and the same settings, OpenLDAP can verify certificates which are signed by CAs stored both in certdb and PEM bundle file. This problem was found with FreeIPA which is setting CA PEM bundle using ldap_set_option(&ld, LDAP_OPT_X_TLS_CACERTFILE, ...), while TLS_CACERTDIR with certdb is set in system ldap.conf file. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠zimbra.com 17 May '12

17 May '12

--On Wednesday, May 16, 2012 10:27 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) We can see that the script turning it into a master ran here: Thu May 17 16:05:46 2012 *** Running as zimbra user: /opt/zimbra/libexec/zmldapenable-mmr -s 2 -m ldap://zre-ldap002.eng.vmware.com:389/ so 16:05:46 In the accesslog, we see: dn: cn=accesslog objectClass: auditContainer cn: accesslog structuralObjectClass: auditContainer contextCSN: 20120517225152.913667Z#000000#000#000000 contextCSN: 20120517230823.615364Z#000000#001#000000 contextCSN: 20120517230546.409118Z#000000#002#000000 dn: reqStart=20120517230546.000019Z,cn=accesslog objectClass: auditAdd structuralObjectClass: auditAdd reqStart: 20120517230546.000019Z reqEnd: 20120517230546.000020Z reqType: add reqSession: 100 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: objectClass:+ organizationalRole reqMod: description:+ Zimbra Systems Application Data reqMod: cn:+ zimbra reqMod: structuralObjectClass:+ organizationalRole reqMod: entryUUID:+ 40f78bea-34be-1031-8a5d-e1466f667e19 reqMod: creatorsName:+ cn=config reqMod: createTimestamp:+ 20120517224907Z reqMod: entryCSN:+ 20120517224907.221672Z#000000#000#000000 reqMod: modifiersName:+ cn=config reqMod: modifyTimestamp:+ 20120517224907Z reqEntryUUID: 40f78bea-34be-1031-8a5d-e1466f667e19 entryUUID: 948929e2-34c0-1031-9a14-c93bd10ff0f2 creatorsName: cn=config createTimestamp: 20120517224907Z entryCSN: 20120517224907.221672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120517224907Z so it is tracking "000" as a third master? This seems to be why the original server (which was 000 before being promoted to 001) replicates these entries back to itself. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by openldap＠stormcloud9.net 16 May '12

16 May '12

I too am experiencing this issue. I attempted to apply the patch from commit 7ff18967d7d2e49baa9d80f1b9408b276f3982e0, but it wont apply cleanly to 2.4.31. I was going to apply it by hand, but it appears the last 2 chunks have had a lot of changes in that area of the code. Is there any chance of getting the patch re-based for 2.4.31? Thanks

1 0

(ITS#7274) delta-syncrepl MMR infinite loop
by quanah＠OpenLDAP.org 16 May '12

16 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) The following problem did not occur for me in previous OpenLDAP releases. However, I can reproduce it 100% of the time with OpenLDAP 2.4.31. Basic configuration scenario is as follows: Set up a stand alone OpenLDAP server -- Just cn=config and primary DB. Basic database for the server is created (note all entries now have SID value 0) Update the server to be delta-sync MMR -- Set sid=1, Mirror Mode, and add accesslog DB. Add syncrepl stanza for a second server Install second server as a delta-sycnrepl MMR pair -- cn=config, accesslog DB, primary DB, SID=2 Servers now go into infinite loops due to the SID=0 entries. Server SID=1 logs: May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced 20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x4699f50 20120516212017.543213Z#000000#000#000000 May 16 14:33:24 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add cn=zimbra (68) May 16 14:33:24 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zimbra 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=admins,cn=zimbra, UUID: add18ab2-33e8-1031-8f63-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add18ab2-33e8-1031-8f63-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=admins,cn=zimbra 20120516212017.544170Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=admins,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=admins,cn=zimbra) (etc, going through all 000 SID entries). Once it finishes, it starts over: May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra 20120516212615.543144Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=com_zimbra_click2call_mitel,cn=zimlets,cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra, UUID: 5a64830a-33ea-1031-8fbb-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID 5a64830a-33ea-1031-8fbb-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra 20120516213323.905859Z#000000#001#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra) May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=100,sid=002,csn=20120516213323.905859Z#000000#001#000000;20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x5805da0 20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x5805620 20120516213237.680889Z#000000#002#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 cookie=rid=000,sid=002,csn=20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_queue_csn: queing 0x58d2ced 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: slap_graduate_commit_csn: removing 0x5805bc0 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_op: rid=100 be_add cn=zimbra (68) May 16 14:33:25 zre-ldap002 slapd[17422]: do_syncrep2: rid=100 delta-sync lost sync on (reqStart=20120516213237.000019Z,cn=accesslog), switching to REFRESH May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_message_to_entry: rid=100 DN: cn=zimbra, UUID: add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 inserted UUID add167b2-33e8-1031-8f62-f1c6fd57f8b3 May 16 14:33:25 zre-ldap002 slapd[17422]: dn_callback : entries have identical CSN cn=zimbra 20120516212017.543213Z#000000#000#000000 May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 be_search (0) May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 cn=zimbra May 16 14:33:25 zre-ldap002 slapd[17422]: syncrepl_entry: rid=100 entry unchanged, ignored (cn=zimbra) On the second MMR master server, it logs: May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138856 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138857 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response: cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138858 ABANDON msg=138858 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138859 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138860 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138861 ABANDON msg=138861 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138862 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138863 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138864 ABANDON msg=138864 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SRCH attr=* + May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138865 SEARCH RESULT tag=101 err=0 nentries=0 text= May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138866 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN May 16 14:36:15 zre-ldap003 slapd[26137]: syncprov_search_response: cookie=rid=100,sid=002,csn=20120516212644.426510Z#000000#000#000000;20120516213448.200519Z#000000#001#000000;20120516213237.680085Z#000000#002#000000 May 16 14:36:15 zre-ldap003 slapd[26137]: conn=1002 op=138867 ABANDON msg=138867 However, I can get a working delta-sync MMR pair if I do the following: Set up a stand alone OpenLDAP server -- Just cn=config and primary DB. Basic database for the server is created (note all entries now have SID value 0) Update the server to be delta-sync master: add accesslog DB. Install second server as a replica. Update first server to be delta-sync MMR: Set sid=1, mirrormode=true on primary DB, add syncrepl stanza for second server Update second server to be delta-sync MMR: Set sid=2, mirrormode=true on primary DB, add accesslog DB, add syncprel stanza for first server In this scenario everything works as expected. The issue seems to be caused in the first scenario by server 2 replicating the DB with SID=0 bits from the primary server, and that looping back to the first server endlessly, instead of being permanently ignored. --Quanah

1 0

(ITS#7273) Sig abort crash in slapd using GSSAPI auth in slap_listener at daemon.c:1891
by stefan.wold＠su.se 15 May '12

15 May '12

Full_Name: Stefan Wold Version: 2.4.31 OS: Ubuntu and Lunar Linux URL: Submission from: (NULL) (77.238.32.111) I can reproduce a sig abort crash in both Ubuntu and Lunar Linux using OpenLDAP 2.4.31. This crash only seem occur when I run ~20 concurrent ldap searches using -YGSSAPI for authentication, using simple bind (-x) I can't reproduce the crash. Usually slapd crash within a couple of hours using GSSAPI. My test case is quite simple, I start 20 threads that loop the following command: ldapsearch -h server -YGSSAPI uid=user In Ubuntu openldap is linked against cyrus-sasl which links to MIT kerberos. In Lunar Linux cyrus-sasl is linked against heimdal. In this case it doesn't seem to matter which kerberos implementation is used. Here's a brief gdb backtrace: Core was generated by `/usr/lib/slapd -d 0 -h ldap:/// ldaps:/// -f /etc/openldap/slapd.conf'. Program terminated with signal 6, Aborted. #0 0x00007f70313293c5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f70313293c5 in raise () from /lib/libc.so.6 #1 0x00007f703132a83b in abort () from /lib/libc.so.6 #2 0x00007f703132226e in __assert_fail_base () from /lib/libc.so.6 #3 0x00007f7031322312 in __assert_fail () from /lib/libc.so.6 #4 0x00000000004310e7 in slap_listener (sl=0x15c30d0) at daemon.c:1891 #5 0x0000000000431109 in slap_listener_thread (ctx=<optimized out>, ptr=<optimized out>) at daemon.c:2093 #6 0x00007f7032e7dcda in ldap_int_thread_pool_wrapper (xpool=0x15ff920) at tpool.c:688 #7 0x00007f703165cce0 in start_thread () from /lib/libpthread.so.0 #8 0x00007f70313c7abd in clone () from /lib/libc.so.6 For a full backtrace: https://gist.github.com/a82d5b3dfdac7abc8e27 -- Sincerely Stefan Wold IT services, Stockholm University Sweden

1 0

Re: (ITS#7272) Implement hasSubordinates in back-ldif
by h.b.furuseth＠usit.uio.no 14 May '12

14 May '12

michael(a)stroeder.com wrote: > It would be handy to have operational attribute 'hasSubordinates' > returned for entries under cn=config. If so, that can hopefully be done in back-config. It'd be a bit costly in back-ldif - one stat() per read_entry, plus an attempted rmdir(parent dir) in delete/modifyDN so that read_entry can assume there are subordinates if the dir exists. Hallvard

1 0

(ITS#7272) Implement hasSubordinates in back-ldif
by michael＠stroeder.com 13 May '12

13 May '12

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.227.175.236) It would be handy to have operational attribute 'hasSubordinates' returned for entries under cn=config.

1 0

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 12 May '12

12 May '12

--DKU6Jbt7q3WqK7+M Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I forgot to add the notice to the patch I just submitted. Here's the notice: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by W. Trevor King wking(a)tremily.us. I have not assigned rights and/or interest in this work to any party. I, W. Trevor King, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. I've attached the patch again, since that matches the language in the notice. Cheers, Trevor --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tool-nocanon.patch" Content-Transfer-Encoding: quoted-printable ITS#7271 fix SASL_NOCANON clobbering in tools/common.c. diff --git a/clients/tools/common.c b/clients/tools/common.c index 9c98b62..9868658 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1214,6 +1214,7 @@ LDAP * tool_conn_setup( int dont, void (*private_setup)( LDAP * ) ) { LDAP *ld =3D NULL; + int i; =20 if ( debug ) { if( ber_set_option( NULL, LBER_OPT_DEBUG_LEVEL, &debug ) @@ -1410,13 +1411,22 @@ dnssrv_free:; =20 #ifdef HAVE_CYRUS_SASL /* canon */ - if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, - nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + if( ldap_get_option( ld, LDAP_OPT_X_SASL_NOCANON, &i ) + !=3D LDAP_OPT_SUCCESS ) { - fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", - nocanon ? "on" : "off" ); + fprintf( stderr, "Could not get LDAP_OPT_X_SASL_NOCANON\n" ); tool_exit( ld, EXIT_FAILURE ); } + if (!i) { + fprintf( stderr, "Set NOCANON to %s\n", nocanon ? "on" : "off" ); + if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, + nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + { + fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", + nocanon ? "on" : "off" ); + tool_exit( ld, EXIT_FAILURE ); + } + } /* otherwise SASL_NOCANON already set to true (e.g. via ~/.ldaprc) */ #endif if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) !=3D LDAP_OPT_SUCCESS ) --Nq2Wo0NMKNjxTN9z-- --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBAgAGBQJPrw4RAAoJEPe7CdOcrcTZAiUH/RJN9EcOW0HdIr60/vrHQ01r et05+CMhoSM9OQST7KxVz0IOA0tzgIu6y7KHFSirUFOmb8KNyS+u0uI2b4OMINoF 0qVHo3Ed4gYYQtc9TsTPOTNw0/HfRwiLxYHh6Xrmeq0Z9o+rL1wsFoEwVBQTXc4W 3xsYtjoyRFK5KbmMw+iA1zsIWOTD9cs+PqQ0EWDXl2ptMHjhrBOs8/Demi495UA7 iCmrPbD8uv8T5NMCiqIB3yOkyrX2+0wLsLVO/B21qTb8swFOrSFjlACZ4SjvVYmy ZJ6njl7vu0h7vPF12Z+NQW5xMFCYz6wbesrhCNbj0k7eJ5gbD+Zd2tP8VQOS3C4= =9g7U -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M--

1 0

(ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 12 May '12

12 May '12

Full_Name: W. Trevor King Version: git commit 22bf5188 OS: Gentoo URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch Submission from: (NULL) (72.68.88.202) The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment variable) should set the default behaviour for OpenLDAP tools such as ldapwhoami. This configuration option should allow users to use the tools without having to use the matching command line option (-N). Unfortunately, the current code sets the option to true/false after only querying the command line option. I'm linking to a patch that looks at the current value of the option first, and if it's true, skips processing the command line option (which would either be a redundant -N keeping the option true, or an absence of -N which implies the user wants to use the configured value (true)). Another approach would be to set the initial value of nocanon to UNINITIALIZED (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, --canon?). Then we would only call ldap_set_option if nocanon was not UNINITIALIZED. I can work up a patch using this second approach if people prefer. If so, let me know if you want me to define UNINITIALIZED, or to just use -1. I didn't check, but I would not be surprised if this same clobbering occurred for other command line options.

1 0

ITS#6997
by michael＠stroeder.com 12 May '12

12 May '12

I think it's worth to note that such a setup with this stacking order works with OpenLDAP 2.4.23 (in a more complex variant done by Manuel). So the big question is what was changed in 2.4.24+ which leads to the crash? Ciao, Michael.

1 0

(ITS#7270) Double free in ldap_int_initialize
by fdeweerdt＠cloudmark.com 11 May '12

11 May '12

Full_Name: Frederik Deweerdt Version: current HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch Submission from: (NULL) (72.5.239.5) [PATCH] Protect accesses to ldap_int_hostname with a mutex Not protecting the accesses to ldap_int_hostname would lead to a double free with the following trace: #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 No symbol table info available. #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 No symbol table info available. #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 No symbol table info available. #10 0x000000328902333e in ldap_int_initialize () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. The race in init.c:ldap_int_initialize is as follows: 646 char *name = ldap_int_hostname; 647 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); 649 650 if ( name != NULL && name != ldap_int_hostname ) { 651 LDAP_FREE( name ); 652 } - T1 and T2 enter ldap_int_initialize, both assign to name the current address of ldap_int_hostname, say 0x1234. - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 and 0x1236 respectively. - T1 and T2 reach the name != ldap_int_hostname check. In both threads it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. - T1 and T2 both try to free 0x1234 => Crash. --- libraries/libldap/init.c | 2 ++ libraries/libldap/ldap-int.h | 1 + libraries/libldap/util-int.c | 3 +++ 3 files changed, 6 insertions(+), 0 deletions(-)

1 0

Re: (ITS#7268) syncrepl issue
by quanah＠zimbra.com 10 May '12

10 May '12

--On Thursday, May 10, 2012 9:41 AM +0000 Nithya.narasimhan(a)hp.com wrote: > Full_Name: Nithya Narasimhan > Version: Symas OpenLDAP version 2.4.26 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > We have configured 2 nodes in an n way multimaster configuration. The ITS system is for reporting bug, not asking usage questions. Please (a) upgrade to the lastest version of OpenLDAP (2.4.31) and (b) direct your questions to the openldap-technical(a)openldap.org discussion list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7269) [PATCH] Make slapd-sha2 module thread-safe
by fumiyas＠osstech.co.jp 10 May '12

10 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch Submission from: (NULL) (125.2.180.244) In contrib/slapd-modules/passwd/sha2/slapd-sha2.c:sha*_hex_hash(), a static buffer "static char real_hash[]" is declared and is used by threads, but it is not TLS (Thread Local Storage) and no lock. This patch removes sha*_hex_hash() and replaces chk_sha*() with libraries/liblutil/passwd.c:chk_sha1() implementation to fix this problem.

1 0

(ITS#7268) syncrepl issue
by Nithya.narasimhan＠hp.com 10 May '12

10 May '12

Full_Name: Nithya Narasimhan Version: Symas OpenLDAP version 2.4.26 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.219.201.69) We have configured 2 nodes in an n way multimaster configuration. Server Definition is configured as follows - Slapd.conf entry in first server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Slapd.conf entry in second server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Offline replication does not occur.ie:Bring down node1, add entries to node2 which is up.Then bring up the node1 after sometime.In this case the entries added in node2 are not available in node1. However when ServerID is configured as follows in slapd.conf file - Slapd.conf entry in first server serverID 1 Slapd.conf entry in second server serverID 2 offline replication occurs correctly. My Questions are - 1) What is the correct Server Definition for n way multimaster. 2) Is there any other configuration we need to change to make this work? 3) If we are adding LDAP URL to Server Definition , what is the correct format we must use ? 4) If N-way multi-master mode for 2 servers (2-way multi-master Mode), should both nodes information be configured in both servers under syncrepl. Should the syncrepl ID be different in both servers ? Can you share me a sample 2-way multi-master mode setup. 5) Offline data load (Node 1 is up and Node 2 is down Now entries are added in Node 1 and then Node 2 is brought up) How does this synchronization work ? Will it work in Physical server and Virtual Machine as well ? Scenarios of addition/deletion/modification of entries/attributes. 6) What happens if I define an interval even if I have it refreshandpersist type Will it ignore that parameter or does it have any side effects ?

1 0

Re: (ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠zimbra.com 09 May '12

09 May '12

--On Monday, May 07, 2012 6:05 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.30+patches > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > With a database maxsize of 1GB, found that when the DB hit 1GB in size, > slapd stopped. After upping the maxsize, the mdb database was unreadable > via ldapsearch. Slapcat also failed to pull any data out of the database. > Appears related to ITS7266, this ITS can be closed. There was a size mismatch between data sizes in slapd & libmdb. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7267) [PATCH] Make slapd-sha2 portable
by hyc＠symas.com 08 May '12

08 May '12

fumiyas(a)osstech.jp wrote: > Hi, > >> Full_Name: SATOH Fumiyasu >> Version: master >> OS: >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch > > Revised patch: > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch > > Sorry. Thanks for the patch. It's always better to preserve comments than to delete them, you should have changed the C++ comments to regular C comments. I'll tweak this and commit. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.jp 08 May '12

08 May '12

Hi, > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Revised patch: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch Sorry. > Submission from: (NULL) (125.2.180.244) -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: https://github.com/fumiyas/

1 0

(ITS#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.co.jp 07 May '12

07 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Submission from: (NULL) (125.2.180.244) contrib/slapd-modules/passwd/sha2/sha2.[ch] need portable.h and some macros to be portable source.

1 0

(ITS#7266) back-mdb deletion failures
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Create an MDB database with approximately 130,000 entries. Delete the entries sequentially. Deletes will sporadically fail in blocks: deleting entry "uid=testuser44968,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser44969,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser44970,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed ... continues to fail up to: deleting entry "uid=testuser45093,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45094,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45095,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45096,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45097,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45098,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45099,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" then deletes work for a while again, then fail again for a while, etc.

1 0

(ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30+patches OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) With a database maxsize of 1GB, found that when the DB hit 1GB in size, slapd stopped. After upping the maxsize, the mdb database was unreadable via ldapsearch. Slapcat also failed to pull any data out of the database.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 07 May '12

07 May '12

--nextPart2505210.xvcxic42sH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday 27 of April 2012 12:26:22, Howard Chu wrote: > jvcelak(a)redhat.com wrote: > >> What happens is that the memberof overlay, when stacked on the frontend > >> database, keeps looping until the stack is exhausted, since internal > >> modifications keep calling the frontend's modify hook rather than the > >> actual one that needs to be called. > > > > I have no idea how to fix it. I probably do not understand the > > manipulation > > with BackedInfo structures fully. > > > > It is obious that it is caused by doing a search from the modrdn operation > > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). > > Other backends does not call any backend operation at the same moment > > (op->callback). > > > > Frontend fe_op_search() is called. It tries to choose the right backend > > with select_backend(). Which returns the overlay backend (bi_type == > > "over"), over_op_walk() then selects fe_op_search() again, and we are > > looping infinitely. > > > > I have no clue how to hide or temporarily deactivate the overlay in > > memberof_res_modrdn() to make the select_backend() function to choose the > > right underlaying backend. Or maybe I have choosen a wrong way of fixing > > it. > > > > All ideas are welcomed. :-) > > The attached diff fixes this particular problem. I haven't spent any time to > see if the other be_* invocations need to be protected the same way. Thank you. I have added this check to another places (attaching patch). But it seems that it is not sufficient. In certain situations I can still trigger the segfault - from memberof_res_modrdn() by calling backend_attribute(). At a first glance, the circumstances are a little bit different but I see no difference in the structures when calling the function with overlay set on frontend and backend database. I hope I will have some time to look at it soon. (gdb) bt -30 #35697 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35698 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35699 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35700 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35701 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35702 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35703 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35704 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35705 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35706 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35707 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35708 0x000000000044fc46 in be_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backend.c:1366 #35709 0x0000000000450990 in fe_acl_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1658 #35710 0x00000000004d9cdb in over_acl_attribute (op=0x7fffe40028f0, target=0x0, entry_ndn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backover.c:589 #35711 0x0000000000450ed5 in backend_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1778 #35712 0x00000000005a4c9f in memberof_res_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/overlays/memberof.c:1558 #35713 0x000000000045252c in slap_response_play (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:507 #35714 0x0000000000452768 in send_ldap_response (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:582 #35715 0x0000000000453952 in slap_send_ldap_result (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:860 #35716 0x000000000050dfa9 in bdb_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #35717 0x00000000004625be in fe_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:314 #35718 0x00000000004d9ed4 in overlay_op_walk (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn, oi=0x7fffe41050e0, on=0x0) at ../../../servers/slapd/backover.c:671 #35719 0x00000000004da125 in over_op_func (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #35720 0x00000000004da2b2 in over_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/backover.c:768 #35721 0x0000000000461d20 in do_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:186 #35722 0x000000000043a8df in connection_operation (ctx=0x7ffff23d9ba0, arg_v=0x7fffe40028f0) at ../../../servers/slapd/connection.c:1150 #35723 0x000000000043ae9c in connection_read_thread (ctx=0x7ffff23d9ba0, argv=0x15) at ../../../servers/slapd/connection.c:1286 #35724 0x00000000005d12ce in ldap_int_thread_pool_wrapper (xpool=0x9b0bf0) at ../../../libraries/libldap_r/tpool.c:688 #35725 0x00007ffff73e4d90 in start_thread () from /lib64/libpthread.so.0 #35726 0x00007ffff5cf5f5d in clone () from /lib64/libc.so.6 --nextPart2505210.xvcxic42sH Content-Disposition: attachment; filename="memberof_partial.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="memberof_partial.patch" diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c index 502cb46..356c1e6 100644 --- a/servers/slapd/overlays/memberof.c +++ b/servers/slapd/overlays/memberof.c @@ -190,7 +190,16 @@ typedef struct memberof_cbinfo_t { BerVarray memberof; memberof_is_t what; } memberof_cbinfo_t; - + +static void +memberof_set_backend(Operation *op_target, Operation *op, slap_overinst *on) +{ + BackendInfo *bi = op->o_bd->bd_info; + + if (bi->bi_type == memberof.on_bi.bi_type) + op_target->o_bd->bd_info = (BackendInfo *)on->on_info; +} + static int memberof_isGroupOrMember_cb( Operation *op, SlapReply *rs ) { @@ -285,7 +294,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_groupFilterstr; op2.ors_filter = &mo->mo_groupFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -307,7 +316,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_memberFilterstr; op2.ors_filter = &mo->mo_memberFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -407,7 +416,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); @@ -449,7 +458,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); --nextPart2505210.xvcxic42sH--

1 0

ITS#7263 published: SECURITY: ldap_bind: Invalid credentials (49)
by openldap-its＠OpenLDAP.org 06 May '12

06 May '12

Private ITS#7263 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=7263

1 0

Re: (ITS#7255) back-mdb hangs during mdb_tool_entry_modify
by hyc＠symas.com 02 May '12

02 May '12

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… > Submission from: (NULL) (62.168.56.1) > > > When calling mdb_tool_entry_modify, a new transaction is being set up and this > hangs the process on a mutex that the thread already holds. > > For a possible patch see the last patch in the series at the above URL. Thanks for the report. Your fix is incomplete, a working fix is in git master now. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs