- openldap-bugs - openldap.org

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 05 Mar '09

05 Mar '09

mariusp44(a)gmail.com wrote: > sorry, if I was misunderstood. I am not asking to do my legwork. Just > trying to understand what is going wrong. Sorry, if it seemed that way. > > I installed Sun Studio 12 (latest) and the problem is the same. I don't > think Sun Studio is not working compiler. Just looks very unlikely. IT > compiles everything without single problem. both 32 and 64 bit memory > models. > > Perhaps I was not entirely clear. Weird thing is that it is only not > working when changing password using ldappasswd and hash is set to SMD5 > SSHA or CRYPT. If I manually change the password setting userPassword > after generating it with slappasswd using say SSHA, it works fine. I > mean user can bind using password that is stored in SSHA or SMD5. That > tells me that slapd can still do encryption properly and check against > hashes in question. At some point it needs to generate a hash and does > it properly. Only when slapd is asked to change a password with > ldappasswd it is unable to generate proper hash. Unless process is > entirely different when changing password and authorizing against password. > I am not insisting it is a bug in slapd code. But I am running out of > ideas what else could be wrong and was just hoping that somebody else is > using openldap on the same architecture and perhaps experienced > something similar. Since no one else is seeing the problem, I already recommended that you step in the (non-optimized) code with a debugger and see why this happens. The right place to start is slap_passwd_hash_type(), whose failure is setting the error message you see. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 04 Mar '09

04 Mar '09

sorry, if I was misunderstood. I am not asking to do my legwork. Just trying to understand what is going wrong. Sorry, if it seemed that way. I installed Sun Studio 12 (latest) and the problem is the same. I don't think Sun Studio is not working compiler. Just looks very unlikely. IT compiles everything without single problem. both 32 and 64 bit memory models. Perhaps I was not entirely clear. Weird thing is that it is only not working when changing password using ldappasswd and hash is set to SMD5 SSHA or CRYPT. If I manually change the password setting userPassword after generating it with slappasswd using say SSHA, it works fine. I mean user can bind using password that is stored in SSHA or SMD5. That tells me that slapd can still do encryption properly and check against hashes in question. At some point it needs to generate a hash and does it properly. Only when slapd is asked to change a password with ldappasswd it is unable to generate proper hash. Unless process is entirely different when changing password and authorizing against password. I am not insisting it is a bug in slapd code. But I am running out of ideas what else could be wrong and was just hoping that somebody else is using openldap on the same architecture and perhaps experienced something similar. /M. hyc(a)symas.com wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, this ITS will be closed. >>> >>> -- >>> -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> mathias.gug(a)canonical.com wrote: >>> Full_Name: Mathias Gug >>> Version: 2.4.15 >>> OS: Ubuntu Linux (Jaunty - 9.04) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (64.56.226.136) >>> >>> >>> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >>> does. >>> >>> openldap version: 2.4.15 >>> gnutls version: 2.4.2 >>> openssl version: 0.9.8g > > I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? > Hm, I may have been testing the wrong code before, I see it now. A fix is coming in HEAD. -- -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

hyc(a)symas.com wrote: > mathias.gug(a)canonical.com wrote: >> Full_Name: Mathias Gug >> Version: 2.4.15 >> OS: Ubuntu Linux (Jaunty - 9.04) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (64.56.226.136) >> >> >> slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl >> does. >> >> openldap version: 2.4.15 >> gnutls version: 2.4.2 >> openssl version: 0.9.8g I'm unable to reproduce this using GnuTLS 2.6. Why are you using 2.4? -- -- 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#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty - 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl > does. > > openldap version: 2.4.15 > gnutls version: 2.4.2 > openssl version: 0.9.8g > > Here are two systems running slapd 2.4.15 - one compiled with gnutls > (t-slapd-gnutls), the other with openssl (t-slapd-openssl). This appears to be a logical disconnect between the GnuTLS and OpenSSL APIs; the OpenLDAP docs were written for OpenSSL... The way we use the OpenSSL library, it's assumed that only a single cert and key are present in the configured certfile and keyfile, and all of the relevant CAs for that cert are present in the CA file/path. In the GnuTLS library, the library expects the entire cert chain to be present in the certfile. I think it's clear from this message http://groups.google.com/group/linux.debian.bugs.dist/msg/8fec96a62571d6e9 that this is a weakness in the GnuTLS API, one that prevents it from distinguishing between CA certs and end-entity certs, and thus the reason the whole V1 trust problem arose in the first place. As an immediate workaround, you can simply copy the appropriate CA certs into your server cert file. In the meantime it looks like we'll just have to use gnutls_certificate_set_x509_key() to address this. > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-gnutls. > Processed 2 CA certificate(s). > Resolving 't-slapd-gnutls.'... > Connecting to '172.19.42.87:636'... > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIICyTCCAjKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJDQTEL > MAkGA1UECBMCUUMxEDAOBgNVBAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FW > MSAtIEhBUkRZMB4XDTA5MDMwNDE5NTcxMVoXDTEwMDMwNDE5NTcxMVowRjELMAkG > A1UEBhMCQ0ExCzAJBgNVBAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRgwFgYDVQQD > Ew90LXNsYXBkLWdudXRscy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5X > ERAGYnqTCJae2FnEB1qT2Hk0sNiD1n+mnyhNDespomTINPLKpZZmqOSlD7x71zuy > DQ/Z6uxgIxOhuUV9VVo2cISi9MmEOYn4qxGq2YIHyra5FJZf6O43qajicDaRRzGz > UA17ap7vDqgig9T4qFvwCllz4EFlcTzxV+N99m1RAgMBAAGjgcQwgcEwCQYDVR0T > BAIwADALBgNVHQ8EBAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh > dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBSii4L1Po9xGWrMD2oG8VeFuTQtfzBa > BgNVHSMEUzBRoUykSjBIMQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxEDAOBgNV > BAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FWMSAtIEhBUkRZggEAMA0GCSqG > SIb3DQEBBQUAA4GBAEEQMsEc0VQOt1y8B22xfRewUmwMKk34J80aFkKuG/RQJoBw > TSnlHpqyZFvmOu4JaCJAh6IdTdxfsuDB5vu/5kpNMc3jJX1Ale17l1MuxB6lvcKn > zG3A17BIIZh3aoJcVQgDAQ8Vr/I9z8y51i1Qr37E5HF2GjuuyF+5BJz9lITq > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-gnutls.'. > # valid since: Wed Mar 4 14:57:11 EST 2009 > # expires at: Thu Mar 4 14:57:11 EST 2010 > # fingerprint: 72:5A:24:83:6C:5C:3F:0E:80:52:F1:61:CD:C3:0D:31 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-gnutls. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.1 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 > t-slapd-openssl. > Processed 2 CA certificate(s). > Resolving 't-slapd-openssl.'... > Connecting to '172.19.42.220:636'... > - Certificate type: X.509 > - Got a certificate list of 2 certificates. > > - Certificate[0] info: > > -----BEGIN CERTIFICATE----- > MIIB/jCCAWcCAQcwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDQyMDExMTRaFw0xMDAzMDQyMDExMTRaMEcxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEZMBcGA1UEAxMQdC1z > bGFwZC1vcGVuc3NsLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzTEuHfVR > ELoXxSyVTwWrfIIsoKqBfbZYJSGQcTTEtuvxABxX8AoKyc9T+AkhR4wsSmRZGOBz > opH9u0LReaGyhWkUA/XaFF24jkSogi6yDsh478P/ayZjushPLh9LpIeW/2lD9xkh > t5LGW255lXIMGI5+/x8EgiaU1pS5OO9wz/kCAwEAATANBgkqhkiG9w0BAQUFAAOB > gQBlg/lIawsDYFqqNz61BNl2nix4LrIRFxiOA/p14VFkRyuCVHXDjhBtlb13wBZk > wVTDfUdykvy2nlJq8bLQ7OYYdiA4h64HMnLTMyMALKBFiVwyrg/GvF7TsUg3K41K > uFTF0H1bQOmqrJPcIu8r+h3gQLkCRvBLssZaQtA4M4jw4A== > -----END CERTIFICATE----- > > # The hostname in the certificate matches 't-slapd-openssl.'. > # valid since: Wed Mar 4 15:11:14 EST 2009 > # expires at: Thu Mar 4 15:11:14 EST 2010 > # fingerprint: 85:7F:06:0A:EC:3A:9E:6C:78:BC:FC:C3:8F:4D:4B:E9 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-openssl. > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > - Certificate[1] info: > > -----BEGIN CERTIFICATE----- > MIIB/zCCAWgCAQAwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV > BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI > QVJEWTAeFw0wOTAzMDMxODI1NTBaFw0xMjAzMDIxODI1NTBaMEgxCzAJBgNVBAYT > AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEaMBgGA1UEAxMRVEVT > VCBDQVYxIC0gSEFSRFkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZSKqDg > Y5rn4SgJUgnO0IAM2Us/5sQ18mu8gxoDeLkIcHHuiwYHeT4BcOit2hemmOCIEolh > XPKkMD4MVAbafDFtJjhuEgPtWoUuZcOa9gRi3eH+h7QEYhhwnwLewrQGhx4tsfY4 > wR3LIUm/lxkJISy17v3uc5yNLcAlreUrrdJ1AgMBAAEwDQYJKoZIhvcNAQEFBQAD > gYEAAsaBDAMUKofwOZPNNV/9EKglG7O3G5p/i9h8n5C3bXy6E6vWtVxqpWd5qBEt > uMXU1vIIop7FrKornuPWtEy4jKSw12Sv9EXaUJ9rfXQTWh6GpgUmTjlZtOwjABT9 > fAU4M9MdLDTBaZA11NqtdMMPKTwTHXjmv9bKcgOLh1g5WhQ= > -----END CERTIFICATE----- > > # valid since: Tue Mar 3 13:25:50 EST 2009 > # expires at: Fri Mar 2 13:25:50 EST 2012 > # fingerprint: 66:D2:B7:8E:03:DD:BF:24:4D:A1:D8:EA:8E:6F:8B:80 > # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY > > > - Peer's certificate is trusted > - Version: TLS1.0 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > ^C > > -- -- 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#5998) jitterbug
by Kurt＠OpenLDAP.org 04 Mar '09

04 Mar '09

On Mar 4, 2009, at 6:53 PM, hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 1.0 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Where are these resubmits coming from? My guess: the user. -- Kurt

1 0

Re: (ITS#5992) libldap with gnutls don't trust V1 CAs.
by hyc＠symas.com 04 Mar '09

04 Mar '09

mathias.gug(a)canonical.com wrote: > Full_Name: Mathias Gug > Version: 2.4.15 > OS: Ubuntu Linux (Jaunty - 9.04) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.56.226.136) > > > Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a > CA chain is checked. Thus libldap+gnutls breaks in existing environement when > one of the CA certs uses a V1 certificate. However libldap+openssl still > supports V1 certificates in the CA chain. > > See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more > information. > > Could libldap+gnutls be updated to also support V1 CA certificates to match > features provided by libldap+openssl? Just to be clear, are you requesting that libldap unconditionally call gnutls_certificate_set_verify_flags() with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter? -- -- 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#5998) jitterbug
by hyc＠OpenLDAP.org 04 Mar '09

04 Mar '09

Full_Name: Howard Chu Version: 1.0 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Where are these resubmits coming from?

1 0

Re: (ITS#5997) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

Quanah Gibson-Mount wrote: > --On Thursday, March 05, 2009 1:15 AM +0000 michael(a)stroeder.com wrote: > >> I take this ITS number since it seems you filed the same issue four >> times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be >> ignored by everyone responding. > > Not really. if you check the ITS system, you'll see 5995, 5996, and > 5997 are all closed, marked as duplicates of 5993. Ah, sorry. Somebody was faster than me. Didn't see any response though. I'll repost to ITS#5993. Ciao, Michael.

1 0

Re: (ITS#5993) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

duramaxlb7(a)gmail.com wrote: > Master log file when slapo-chain runs > --------------- > TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert > unknown ca. > > Slave log file when slapo-chain runs > ----------------- > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. To me both messages look like the trusted CA cert (directory) is not properly configured. > I had the same problem with LUMA and that problem went away when I put the > starttls=critical in the chain-idassert-bind Hmm, are you sure you didn't add "tls_cacertdir=/etc/openldap/cacerts" to chain-idassert-bind at the same time when testing? Ciao, Michael.

1 0

Re: (ITS#5997) slapo-chain TLS issues
by quanah＠zimbra.com 04 Mar '09

04 Mar '09

--On Thursday, March 05, 2009 1:15 AM +0000 michael(a)stroeder.com wrote: > I take this ITS number since it seems you filed the same issue four > times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be > ignored by everyone responding. Not really. if you check the ITS system, you'll see 5995, 5996, and 5997 are all closed, marked as duplicates of 5993. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5997) slapo-chain TLS issues
by michael＠stroeder.com 04 Mar '09

04 Mar '09

I take this ITS number since it seems you filed the same issue four times. AFAICS the others (ITS#5993, ITS#5995 and ITS#5996) should be ignored by everyone responding. duramaxlb7(a)gmail.com wrote: > Master log file when slapo-chain runs > --------------- > TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert > unknown ca. > > Slave log file when slapo-chain runs > ----------------- > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. To me both messages look like the trusted CA cert (directory) is not properly configured. > I had the same problem with LUMA and that problem went away when I put the > starttls=critical in the chain-idassert-bind Hmm, are you sure you didn't add "tls_cacertdir=/etc/openldap/cacerts" to chain-idassert-bind at the same time when testing? Ciao, Michael.

1 0

(ITS#5997) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5996) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5995) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5994) replica segfault after syncing final entry
by quanah＠zimbra.com 04 Mar '09

04 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) With a replica doing a full refresh from the master, it segfaults on the final entry. The line in question is: rc = bdb_cache_find_id( op, ltid, eip->bei_id, &eip, 0, locker, &plock ); Core data: Program terminated with signal 11, Segmentation fault. #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 There is only one active thread in the core: (gdb) thr apply all bt Thread 4 (process 23189): #0 0x0000003167a075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd817 in ldap_pvt_thread_join (thread=1082132800, thread_return=0x0) at thr_posix.c:193 #2 0x0000000000429c79 in slapd_daemon () at daemon.c:2579 #3 0x0000000000412183 in main (argc=10, argv=0x7fffca15ec78) at main.c:859 Thread 3 (process 23190): #0 0x0000003166ecec48 in ?? () #1 0x0000000000000000 in ?? () Thread 2 (process 23192): #0 0x0000003167a0a4a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002aaaaaabd8c4 in ldap_pvt_thread_cond_wait (cond=0x6579a50, mutex=0x6579a28) at thr_posix.c:299 #2 0x00002aaaaaabc609 in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:466 #3 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003166ece85d in ?? () #5 0x0000000000000000 in ?? () Thread 1 (process 23191): #0 0x00002aaaaf76ddee in bdb_delete (op=0x41000840, rs=0x41000430) at delete.c:178 #1 0x00000000004a0fe9 in overlay_op_walk (op=0x41000840, rs=0x41000430, which=op_delete, oi=0x66a3550, on=0x0) at backover.c:650 #2 0x00000000004a11ec in over_op_func (op=0x41000840, rs=0x41000430, which=op_delete) at backover.c:702 #3 0x00000000004a1336 in over_op_delete (op=0x41000840, rs=0x41000430) at backover.c:754 #4 0x00000000004985fc in syncrepl_del_nonpresent (op=0x41000840, si=0x66a3170, uuids=0x0, cookiecsn=0x41000640) at syncrepl.c:2167 #5 0x0000000000493849 in do_syncrep2 (op=0x41000840, si=0x66a3170) at syncrepl.c:823 #6 0x00000000004946e9 in do_syncrepl (ctx=0x41000e00, arg=0x66a3350) at syncrepl.c:1102 #7 0x00002aaaaaabc56a in ldap_int_thread_pool_wrapper (xpool=0x6579a20) at tpool.c:478 #8 0x0000003167a062f7 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003166ece85d in ?? () #10 0x0000000000000000 in ?? () The operation data is: (gdb) print *op $1 = {o_hdr = 0x410009a0, o_tag = 74, o_time = 1236201040, o_tincr = 2166, o_bd = 0x41000080, o_req_dn = {bv_len = 0, bv_val = 0x6902820 ""}, o_req_ndn = {bv_len = 0, bv_val = 0x6b8dcd0 ""}, o_request = {oq_add = {rs_e = 0x2, rs_modlist = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x41000370 "\t"}, rb_ssf = 159460192, rb_tmp_mech = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = { rs_modlist = 0x2, rs_increment = -1}, oq_modrdn = {rs_newrdn = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x41000370, rs_nnewSup = 0x9812b60, rs_deleteoldrdn = 15}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x41000370, rs_filter = 0x9812b60, rs_filterstr = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = { rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = { rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 1090519920, bv_val = 0x9812b60 "�5\221\t"}, rs_new = {bv_len = 15, bv_val = 0x66a2ac0 "(objectclass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_ctrlflag = '\0' <repeats 12 times>, "\002", '\0' <repeats 18 times>, o_controls = 0x41000a18, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x66a2690 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x66a0a20 "cn=config"}, sai_ssf = 256, sai_transport_ssf = 0, sai_tls_ssf = 256, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x980ebf0, o_ctrls = 0x0, o_csn = {bv_len = 32, bv_val = 0x9417220 "20090304090011Z#000000#00#000000"}, o_private = 0x40fffef0, o_next = {stqe_next = 0x0}} (gdb) print *ltid $3 = {mgrp = 0x675ea50, parent = 0x0, last_lsn = {file = 0, offset = 0}, txnid = 2147483701, tid = 0, off = 16056, lock_timeout = 0, expire = 0, txn_list = 0x0, links = {tqe_next = 0x0, tqe_prev = 0x675ea58}, xalinks = {tqe_next = 0x0, tqe_prev = 0x0}, events = {tqh_first = 0x0, tqh_last = 0x68dc978}, logs = {stqh_first = 0x0, stqh_last = 0x68dc988}, kids = { tqh_first = 0x0, tqh_last = 0x68dc998}, klinks = {tqe_next = 0x0, tqe_prev = 0x0}, api_internal = 0x0, cursors = 0, abort = 0x2aaaafa4ca70 <__txn_abort_pp>, commit = 0x2aaaafa4caf0 <__txn_commit_pp>, discard = 0x2aaaafa4c9f0 <__txn_discard_pp>, id = 0x2aaaafa4a690 <__txn_id>, prepare = 0x2aaaafa4bf70 <__txn_prepare>, set_timeout = 0x2aaaafa4b0b0 <__txn_set_timeout>, flags = 16} And here's the last few lines of debug output when I ran slapd with '-d32767': => test_filter PRESENT => access_allowed: search access to "cn=serverX,cn=servers,cn=zimbra" "objectClass" requested <= root access granted <= test_filter 6 send_ldap_result: conn=-1 op=0 p=3 send_ldap_result: err=0 matched="" text="" ==> bdb_delete: bdb_dn2entry("") entry_decode: "" <= entry_decode() (serverX is the last dn in an ldif produced with slapcat, and it's also the name of the replica server).

1 0

(ITS#5993) slapo-chain TLS issues
by duramaxlb7＠gmail.com 04 Mar '09

04 Mar '09

Full_Name: Chad Richards Version: 2.4.15 OS: CentOS 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.178.116.129) overlay chain chain-rebind-as-user FALSE chain-uri "ldap://XXX" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XXX,dc=com" credentials="secret" mode="self" starttls=critical tls_reqcert=never tls_cacertdir=/etc/openldap/cacerts chain-tls start chain-return-error TRUE slapo-chain and TLS work fine connecting to the slave with LUMA, I can do password updates and everything is fine. At first TLS slapo-chain wouldn't work in LUMA until I added starttls=critical inside chain-idassert-bind Now the problem I'm having is that I cannot do a passwd as root or an ldap user from the shell prompt. ldap.conf ssl start_tls tls_reqcert never tls_checkpeer no tls_cacertdir /etc/openldap/cacerts Master log file when slapo-chain runs --------------- TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(18): got connid=6 connection_read(18): checking for input on id=6 TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. connection_read(18): TLS accept failure error=-1 id=6, closing connection_close: conn=6 sd=18 Slave log file when slapo-chain runs ----------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX, issuer: /C=US/ST=XX/O=XX/OU=XX/CN=XX/emailAddress=XX TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. I had the same problem with LUMA and that problem went away when I put the starttls=critical in the chain-idassert-bind my ldap.conf works fine for everything else but just dies on passwd with TLS errors with slapo-chain. Any ideas? Thanks!

1 0

(ITS#5992) libldap with gnutls don't trust V1 CAs.
by mathias.gug＠canonical.com 04 Mar '09

04 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty - 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) Starting with GnuTLS 2.6.3, V1 CA certs are no longer trusted by default when a CA chain is checked. Thus libldap+gnutls breaks in existing environement when one of the CA certs uses a V1 certificate. However libldap+openssl still supports V1 certificates in the CA chain. See https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/305264 for more information. Could libldap+gnutls be updated to also support V1 CA certificates to match features provided by libldap+openssl? To reproduce: 0. Need two versions of openldap : one compiled with gnutls, the other with openssl. 1. Create a V1 CA. 2. Create a certificate to be used by slapd and sign it with the V1 CA. 3. Configure a slapd+openssl system with certificates issues above. 4. Try to connect to the slapd+openssl system with a libldap+gnutls client: mathiaz@t-slapd-gnutls:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ -d 1 ldap_url_parse_ext(ldaps://t-slapd-openssl./) ldap_create ldap_url_parse_ext(ldaps://t-slapd-openssl.:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP t-slapd-openssl.:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.42.220:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: peer cert untrusted or revoked (0x82) TLS: can't connect: (unknown error code). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) On a system with libldap+openssl: mathiaz@t-slapd-openssl:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w mypwd -H ldaps://t-slapd-openssl./ # extended LDIF # # LDAPv3 # base <dc=vmnet> with scope subtree # filter: (objectclass=*) # requesting: ALL # # vmnet dn: dc=vmnet objectClass: top objectClass: dcObject objectClass: organization o: vmnet dc: vmnet # admin, vmnet dn: cn=admin,dc=vmnet objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fWtlVHlnV1lleFBDWFU= # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 $ ldapsearch is able to connect to the slapd+openssl server.

1 0

(ITS#5991) slapd+gnutls doesn't send all of the CA certs available in the certficate chain while slapd+openssl does
by mathias.gug＠canonical.com 04 Mar '09

04 Mar '09

Full_Name: Mathias Gug Version: 2.4.15 OS: Ubuntu Linux (Jaunty - 9.04) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.56.226.136) slapd+gnutls doesn't send all the certificates in the chain while slapd+openssl does. openldap version: 2.4.15 gnutls version: 2.4.2 openssl version: 0.9.8g Here are two systems running slapd 2.4.15 - one compiled with gnutls (t-slapd-gnutls), the other with openssl (t-slapd-openssl). mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 t-slapd-gnutls. Processed 2 CA certificate(s). Resolving 't-slapd-gnutls.'... Connecting to '172.19.42.87:636'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: -----BEGIN CERTIFICATE----- MIICyTCCAjKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJDQTEL MAkGA1UECBMCUUMxEDAOBgNVBAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FW MSAtIEhBUkRZMB4XDTA5MDMwNDE5NTcxMVoXDTEwMDMwNDE5NTcxMVowRjELMAkG A1UEBhMCQ0ExCzAJBgNVBAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRgwFgYDVQQD Ew90LXNsYXBkLWdudXRscy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL5X ERAGYnqTCJae2FnEB1qT2Hk0sNiD1n+mnyhNDespomTINPLKpZZmqOSlD7x71zuy DQ/Z6uxgIxOhuUV9VVo2cISi9MmEOYn4qxGq2YIHyra5FJZf6O43qajicDaRRzGz UA17ap7vDqgig9T4qFvwCllz4EFlcTzxV+N99m1RAgMBAAGjgcQwgcEwCQYDVR0T BAIwADALBgNVHQ8EBAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBSii4L1Po9xGWrMD2oG8VeFuTQtfzBa BgNVHSMEUzBRoUykSjBIMQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxEDAOBgNV BAoTB01hdGhpYXoxGjAYBgNVBAMTEVRFU1QgQ0FWMSAtIEhBUkRZggEAMA0GCSqG SIb3DQEBBQUAA4GBAEEQMsEc0VQOt1y8B22xfRewUmwMKk34J80aFkKuG/RQJoBw TSnlHpqyZFvmOu4JaCJAh6IdTdxfsuDB5vu/5kpNMc3jJX1Ale17l1MuxB6lvcKn zG3A17BIIZh3aoJcVQgDAQ8Vr/I9z8y51i1Qr37E5HF2GjuuyF+5BJz9lITq -----END CERTIFICATE----- # The hostname in the certificate matches 't-slapd-gnutls.'. # valid since: Wed Mar 4 14:57:11 EST 2009 # expires at: Thu Mar 4 14:57:11 EST 2010 # fingerprint: 72:5A:24:83:6C:5C:3F:0E:80:52:F1:61:CD:C3:0D:31 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-gnutls. # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Peer's certificate is trusted - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: mathiaz@t-slapd-gnutls:~$ gnutls-cli --x509cafile allca.pem --print-cert -p 636 t-slapd-openssl. Processed 2 CA certificate(s). Resolving 't-slapd-openssl.'... Connecting to '172.19.42.220:636'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: -----BEGIN CERTIFICATE----- MIIB/jCCAWcCAQcwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI QVJEWTAeFw0wOTAzMDQyMDExMTRaFw0xMDAzMDQyMDExMTRaMEcxCzAJBgNVBAYT AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEZMBcGA1UEAxMQdC1z bGFwZC1vcGVuc3NsLjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzTEuHfVR ELoXxSyVTwWrfIIsoKqBfbZYJSGQcTTEtuvxABxX8AoKyc9T+AkhR4wsSmRZGOBz opH9u0LReaGyhWkUA/XaFF24jkSogi6yDsh478P/ayZjushPLh9LpIeW/2lD9xkh t5LGW255lXIMGI5+/x8EgiaU1pS5OO9wz/kCAwEAATANBgkqhkiG9w0BAQUFAAOB gQBlg/lIawsDYFqqNz61BNl2nix4LrIRFxiOA/p14VFkRyuCVHXDjhBtlb13wBZk wVTDfUdykvy2nlJq8bLQ7OYYdiA4h64HMnLTMyMALKBFiVwyrg/GvF7TsUg3K41K uFTF0H1bQOmqrJPcIu8r+h3gQLkCRvBLssZaQtA4M4jw4A== -----END CERTIFICATE----- # The hostname in the certificate matches 't-slapd-openssl.'. # valid since: Wed Mar 4 15:11:14 EST 2009 # expires at: Thu Mar 4 15:11:14 EST 2010 # fingerprint: 85:7F:06:0A:EC:3A:9E:6C:78:BC:FC:C3:8F:4D:4B:E9 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=t-slapd-openssl. # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Certificate[1] info: -----BEGIN CERTIFICATE----- MIIB/zCCAWgCAQAwDQYJKoZIhvcNAQEFBQAwSDELMAkGA1UEBhMCQ0ExCzAJBgNV BAgTAlFDMRAwDgYDVQQKEwdNYXRoaWF6MRowGAYDVQQDExFURVNUIENBVjEgLSBI QVJEWTAeFw0wOTAzMDMxODI1NTBaFw0xMjAzMDIxODI1NTBaMEgxCzAJBgNVBAYT AkNBMQswCQYDVQQIEwJRQzEQMA4GA1UEChMHTWF0aGlhejEaMBgGA1UEAxMRVEVT VCBDQVYxIC0gSEFSRFkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMZSKqDg Y5rn4SgJUgnO0IAM2Us/5sQ18mu8gxoDeLkIcHHuiwYHeT4BcOit2hemmOCIEolh XPKkMD4MVAbafDFtJjhuEgPtWoUuZcOa9gRi3eH+h7QEYhhwnwLewrQGhx4tsfY4 wR3LIUm/lxkJISy17v3uc5yNLcAlreUrrdJ1AgMBAAEwDQYJKoZIhvcNAQEFBQAD gYEAAsaBDAMUKofwOZPNNV/9EKglG7O3G5p/i9h8n5C3bXy6E6vWtVxqpWd5qBEt uMXU1vIIop7FrKornuPWtEy4jKSw12Sv9EXaUJ9rfXQTWh6GpgUmTjlZtOwjABT9 fAU4M9MdLDTBaZA11NqtdMMPKTwTHXjmv9bKcgOLh1g5WhQ= -----END CERTIFICATE----- # valid since: Tue Mar 3 13:25:50 EST 2009 # expires at: Fri Mar 2 13:25:50 EST 2012 # fingerprint: 66:D2:B7:8E:03:DD:BF:24:4D:A1:D8:EA:8E:6F:8B:80 # Subject's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY # Issuer's DN: C=CA,ST=QC,O=Mathiaz,CN=TEST CAV1 - HARDY - Peer's certificate is trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: ^C

1 0

Re: (ITS#5990) Segmentation Fault with slapd with two olcSyncrepl directives in the config database
by hyc＠symas.com 04 Mar '09

04 Mar '09

crispy(a)cluenet.org wrote: > Full_Name: Chris Breneman > Version: 2.4.15 > OS: Debian Lenny > URL: > Submission from: (NULL) (207.38.203.80) > > > Using this configuration on a replication consumer, it segfaults almost > immediately, and on startup. > === ./slapd.d/cn=config/olcDatabase={0}config.ldif === > dn: olcDatabase={0}config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW:: XXXXXXXXXXX > olcMonitoring: FALSE > structuralObjectClass: olcDatabaseConfig > entryUUID: 410b0970-9d47-102d-8854-57b95f7e164c > creatorsName: cn=config > createTimestamp: 20090304203158Z > olcSyncrepl: {0}rid=3 provider=ldap://ldap.cluenet.org type=refreshAndPersist > interval=00:00:01:00 retry="60 10 300 +" searchbase="cn=schema,cn=config" bin > dmethod=simple binddn="cn=replicator,dc=cluenet,dc=org" credentials="xxxxxxxx > xxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/certs/Cluenet.pem tls_reqcer > t=demand > olcSyncrepl: {1}rid=4 provider=ldap://ldap.cluenet.org type=refreshAndPersist > interval=00:00:01:00 retry="60 10 300 +" searchbase="olcDatabase={0}config,cn > =config" attrs=olcAccess bindmethod=simple binddn="cn=replicator,dc=cluenet,d > c=org" credentials="xxxxxxxxxxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/ > certs/Cluenet.pem tls_reqcert=demand > entryCSN: 20090304203402.651594Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090304203402Z This replication config is not currently supported. Fractional replication means the consumer gets a subset of the provider's attributes. But it also means that the consumer can *only* have that subset. Here, cn=config needs all of its attributes in order to function, but the consumer code will attempt to delete the non-replicated ones because they aren't part of the info received from the provider. -- -- 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#5990) Segmentation Fault with slapd with two olcSyncrepl directives in the config database
by crispy＠cluenet.org 04 Mar '09

04 Mar '09

Full_Name: Chris Breneman Version: 2.4.15 OS: Debian Lenny URL: Submission from: (NULL) (207.38.203.80) Using this configuration on a replication consumer, it segfaults almost immediately, and on startup. Config (standard schema files left out): === ./slapd.d/cn=config.ldif === dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /home/slapd/slapd.conf.skel olcConfigDir: /home/slapd/usr/etc/openldap/slapd.d olcArgsFile: /home/slapd/usr/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /home/slapd/usr/var/run/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 410a9404-9d47-102d-884d-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={-1}frontend.ldif === dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b05ba-9d47-102d-8853-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z entryCSN: 20090304203158.642980Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203158Z === ./slapd.d/cn=config/olcDatabase={0}config.ldif === dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcRootPW:: XXXXXXXXXXX olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 410b0970-9d47-102d-8854-57b95f7e164c creatorsName: cn=config createTimestamp: 20090304203158Z olcSyncrepl: {0}rid=3 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="cn=schema,cn=config" bin dmethod=simple binddn="cn=replicator,dc=cluenet,dc=org" credentials="xxxxxxxx xxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/certs/Cluenet.pem tls_reqcer t=demand olcSyncrepl: {1}rid=4 provider=ldap://ldap.cluenet.org type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="olcDatabase={0}config,cn =config" attrs=olcAccess bindmethod=simple binddn="cn=replicator,dc=cluenet,d c=org" credentials="xxxxxxxxxxxxxxxxx" starttls=critical tls_cacert=/etc/ssl/ certs/Cluenet.pem tls_reqcert=demand entryCSN: 20090304203402.651594Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20090304203402Z Backtrace: #0 0x0805a0e7 in config_add_internal (cfb=0x8207ba0, e=0x8fe5554, ca=0xb68fc568, rs=0xb68fd974, renum=0xb68fd6e0, op=0xb68fdd24) at bconfig.c:4521 #1 0x0805a9c8 in config_back_add (op=0xb68fdd24, rs=0xb68fd974) at bconfig.c:4730 #2 0x080dda6c in syncrepl_entry (si=0x900bd08, op=0xb68fdd24, entry=0x8fe5554, modlist=0xb68fdb38, syncstate=1, syncUUID=0xb68fdb90, syncCSN=0x0) at syncrepl.c:2153 #3 0x080d9622 in do_syncrep2 (op=0xb68fdd24, si=0x900bd08) at syncrepl.c:890 #4 0x080daf2c in do_syncrepl (ctx=0xb68fe210, arg=0x900c008) at syncrepl.c:1333 #5 0x0806cf10 in connection_read_thread (ctx=0xb68fe210, argv=0xd) at connection.c:1225 #6 0x0816ba54 in ldap_int_thread_pool_wrapper (xpool=0x8fccf08) at tpool.c:663 #7 0xb7e4bf3b in start_thread () from /lib/libpthread.so.0 #8 0xb7be0bee in clone () from /lib/libc.so.6 Last lines with -d -1: syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=003 inserted UUID 3d9f90aa-9ba6-102d-9a95-995804f089ee => access_allowed: search access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => test_filter EQUALITY => access_allowed: search access to "cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={2}nis,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 => test_filter EQUALITY => access_allowed: search access to "cn={3}inetorgperson,cn=schema,cn=config" "entryUUID" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 5 send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncrepl_entry: rid=003 be_search (0) syncrepl_entry: rid=003 cn=schema,cn=config => access_allowed: add access to "cn=schema,cn=config" "entry" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) <= acl_access_allowed: granted to database root => access_allowed: add access to "olcDatabase={0}config,cn=config" "children" requested <= root access granted => access_allowed: add access granted by manage(=mwrscxd) Segmentation fault (core dumped)

1 0

Re: (ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by ando＠sys-net.it 04 Mar '09

04 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24/HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > In the slapd-ldap man page, the section on idassert-bind is missing the fact > that you can configure: > > starttls=no|yes|critical > > while listing all the other tls related keywords you can configure. tls_protocol_min is missing as well. Also, I note the values of starttls should be changed from "no,yes,critical" to "no,try,yes" (with "critical" synonym of "yes"), to remove the false security perception given by the current semantics of "yes". The change would create minor backward compatibility issues, but no security concern, since the meaning of "yes" would be promoted from optional to required. Incautious users that still use "yes" would just need to change it to "try" to restore the previous unsafe behavior. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5989) slapd-ldap(5) idassert-bind missing starttls
by quanah＠OpenLDAP.org 03 Mar '09

03 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In the slapd-ldap man page, the section on idassert-bind is missing the fact that you can configure: starttls=no|yes|critical while listing all the other tls related keywords you can configure.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 03 Mar '09

03 Mar '09

Thanks for your help. Would you be able to email your Makefile that you generated for gcc 4.0.3 on Solaris/SPARC? I am seriously missing something. I installed lated Sun Studio 12 and compiled with it and it's the same problem. /M. On Tue, Mar 3, 2009 at 2:49 PM, <hyc(a)symas.com> wrote: > mariusp44(a)gmail.com wrote: >> as I have pointed out in earlier post not only it doesn't work when I >> compile it myself but also the one that was downloaded form >> sunfreeware.com. It is not possible to tell what version of gcc was >> used to compile openldap that is distributed but explanation that it >> doesn't work because of compiler bug seems to me highly unlikely. >> Unless you can specifically point to which bug in gcc on SPARC >> contributes to this erratic behaviour of openldap. > > It's not our responsibility to do your legwork for you. You can easily email > the maintainers at sunfreeware.com and ask them. Since they currently host gcc > 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. > > Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris > and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy > on my system, nor do I see any reason to install a known-bad compiler just to > further demonstrate what has already been plainly documented by other folks. >> >> Either way, thanks for comments. >> >> /M. >> >> On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >>> ando(a)sys-net.it wrote: >>>> mariusp44(a)gmail.com wrote: >>>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>>> >>>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>>> I have no chance to test on that arch. You should figure our why those >>>> hashes are not supported. Did you enable crypt (--enable-crypt)? >>> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >>> >>> and is known to have many bugs. It's also already known that old gcc releases >>> have other problems on Sparc. (E.g. ITS#5875.) >>> >>> Please use a working compiler. >>> >>> As a workaround, recompile the offending functions with optimization disabled. >>> That usually helps in cases like this. >>> >>> There is no bug in OpenLDAP Software here, this ITS will be closed. >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>> >>> >>> >> >> >> > > > -- > -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by hyc＠symas.com 03 Mar '09

03 Mar '09

mariusp44(a)gmail.com wrote: > as I have pointed out in earlier post not only it doesn't work when I > compile it myself but also the one that was downloaded form > sunfreeware.com. It is not possible to tell what version of gcc was > used to compile openldap that is distributed but explanation that it > doesn't work because of compiler bug seems to me highly unlikely. > Unless you can specifically point to which bug in gcc on SPARC > contributes to this erratic behaviour of openldap. It's not our responsibility to do your legwork for you. You can easily email the maintainers at sunfreeware.com and ask them. Since they currently host gcc 3.4.6 on their site it's a safe bet they're still using gcc 3.4.x overall. Fyi, I have just now built the 2.4.15 source using gcc 4.0.3 on SPARC/Solaris and all of the hash mechanisms work fine. I don't have a gcc 3.x build handy on my system, nor do I see any reason to install a known-bad compiler just to further demonstrate what has already been plainly documented by other folks. > > Either way, thanks for comments. > > /M. > > On Mon, Mar 2, 2009 at 5:56 PM,<hyc(a)symas.com> wrote: >> ando(a)sys-net.it wrote: >>> mariusp44(a)gmail.com wrote: >>>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>>> md5 and sha works, smd5, ssha and crypt doesn't. >>>> >>>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >>> I have no chance to test on that arch. You should figure our why those >>> hashes are not supported. Did you enable crypt (--enable-crypt)? >> gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ >> >> and is known to have many bugs. It's also already known that old gcc releases >> have other problems on Sparc. (E.g. ITS#5875.) >> >> Please use a working compiler. >> >> As a workaround, recompile the offending functions with optimization disabled. >> That usually helps in cases like this. >> >> There is no bug in OpenLDAP Software here, this ITS will be closed. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> > > > -- -- 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#5926) slapd proxying AD with back-meta locks up
by ando＠sys-net.it 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Thank you for looking into this. The new configuration does not rely > on loopbacks and instead uses back-glue. We are also running 2.4.14 > with additional patches. Though it might quickly lead to unnecessary and excessive code duplication, I wonder whether a proxy backend couldn't just detect it would call self, and use an internal operation instead? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 03 Mar '09

03 Mar '09

Thank you for looking into this. The new configuration does not rely on loopbacks and instead uses back-glue. We are also running 2.4.14 with additional patches. Cheers, -Matt On Mar 3, 2009, at 10:46 AM, Howard Chu wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.12 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We are using a pair of OpenLDAP 2.4.12 servers with back-meta to >> proxy an active >> directory domain. The clients are all current versions of PADL's >> nss_ldap >> libraries. >> >> Every once in a while (sometimes twice a day, sometimes once every >> two weeks) >> one of the slapd servers will peg CPU use at 100% and stop >> answering requests. >> The only way to stop slapd is with a kill -9. >> >> There doesn't seem to be anything to explain the lockup or allow us >> to reproduce >> it. We are using redundant AD servers and they are not going >> offline. A third >> slapd server running as a test server using the same AD servers and >> configured >> identically but serving a much lighter nss_ldap load does not fail >> at all. We >> have ruled out hardware, OS, and connectivity as possible causes. >> >> We are unfortunately unable to attach gdb to the running processes, >> as these are >> production servers and need to be restarted immediately. Our >> smaller test system >> does not exhibit the same behavior, either. There is nothing >> unusual in the >> server logs, either. We do have core files generated from kill -6 >> commands, and >> they are all eerily similar to the back-trace below in that they >> have one or >> more threads waiting for a search or a bind response from AD. >> >> I am also enclosing relevant portions of slapd.conf for these >> systems. Please >> let me know if any additional information would be useful. >> >> Thanks, >> >> -Matt >> >> ----- >> >> >> (gdb) thr apply all bt > >> Thread 1 (process 29769): >> #0 0x005fa410 in __kernel_vsyscall () >> #1 0x004ddd10 in raise () from /lib/libc.so.6 >> #2 0x004df621 in abort () from /lib/libc.so.6 >> #3 0x004d715b in __assert_fail () from /lib/libc.so.6 >> #4 0x0806eec8 in slap_listener (sl=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1803 >> #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/ >> daemon.c:1997 >> #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) >> at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/ >> libldap_r/tpool.c:663 >> #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 >> #8 0x00585c4e in clone () from /lib/libc.so.6 >> (gdb) > > It seems you sent the wrong backtrace; this one doesn't show any > signs of looping or anything that would indicate heavy CPU usage. It > shows an assert which would kill the process, leading to 0% CPU > usage. This assert was most likely fixed in 2.4.14. > >> slapd.conf > >> ####################################################################### >> # bdb database definitions >> ####################################################################### >> database bdb >> suffix "ou=nisdata" > >> ####################################################################### >> # Definitions for proxy and cache to AD >> ####################################################################### >> database meta >> suffix "dc=my-customer,dc=com" > >> # The link to AD: >> uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my- >> customer,dc=com >> ldaps://ldap-prd-dc02.my-customer.com/ > >> # The link to the NIS data directory (yes, we could chain/glue, >> that's >> # for later) >> uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my- >> customer,dc=com > > Pointing back-meta at its own slapd will inevitably exhaust the > thread pool since incoming operations will always use 2x the number > of available threads. > > This ITS will be closed. > -- > -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 03 Mar '09

03 Mar '09

as I have pointed out in earlier post not only it doesn't work when I compile it myself but also the one that was downloaded form sunfreeware.com. It is not possible to tell what version of gcc was used to compile openldap that is distributed but explanation that it doesn't work because of compiler bug seems to me highly unlikely. Unless you can specifically point to which bug in gcc on SPARC contributes to this erratic behaviour of openldap. Either way, thanks for comments. /M. On Mon, Mar 2, 2009 at 5:56 PM, <hyc(a)symas.com> wrote: > ando(a)sys-net.it wrote: >> mariusp44(a)gmail.com wrote: >>> I have just compiled and tested 2.4.15 and result is same: cleartext, >>> md5 and sha works, smd5, ssha and crypt doesn't. >>> >>> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. >> >> I have no chance to test on that arch. You should figure our why those >> hashes are not supported. Did you enable crypt (--enable-crypt)? > > gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ > > and is known to have many bugs. It's also already known that old gcc releases > have other problems on Sparc. (E.g. ITS#5875.) > > Please use a working compiler. > > As a workaround, recompile the offending functions with optimization disabled. > That usually helps in cases like this. > > There is no bug in OpenLDAP Software here, this ITS will be closed. > > -- > -- 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#5926) slapd proxying AD with back-meta locks up
by hyc＠symas.com 03 Mar '09

03 Mar '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.12 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active > directory domain. The clients are all current versions of PADL's nss_ldap > libraries. > > Every once in a while (sometimes twice a day, sometimes once every two weeks) > one of the slapd servers will peg CPU use at 100% and stop answering requests. > The only way to stop slapd is with a kill -9. > > There doesn't seem to be anything to explain the lockup or allow us to reproduce > it. We are using redundant AD servers and they are not going offline. A third > slapd server running as a test server using the same AD servers and configured > identically but serving a much lighter nss_ldap load does not fail at all. We > have ruled out hardware, OS, and connectivity as possible causes. > > We are unfortunately unable to attach gdb to the running processes, as these are > production servers and need to be restarted immediately. Our smaller test system > does not exhibit the same behavior, either. There is nothing unusual in the > server logs, either. We do have core files generated from kill -6 commands, and > they are all eerily similar to the back-trace below in that they have one or > more threads waiting for a search or a bind response from AD. > > I am also enclosing relevant portions of slapd.conf for these systems. Please > let me know if any additional information would be useful. > > Thanks, > > -Matt > > ----- > > > (gdb) thr apply all bt > Thread 1 (process 29769): > #0 0x005fa410 in __kernel_vsyscall () > #1 0x004ddd10 in raise () from /lib/libc.so.6 > #2 0x004df621 in abort () from /lib/libc.so.6 > #3 0x004d715b in __assert_fail () from /lib/libc.so.6 > #4 0x0806eec8 in slap_listener (sl=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 > #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 > #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) > at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 > #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 > #8 0x00585c4e in clone () from /lib/libc.so.6 > (gdb) It seems you sent the wrong backtrace; this one doesn't show any signs of looping or anything that would indicate heavy CPU usage. It shows an assert which would kill the process, leading to 0% CPU usage. This assert was most likely fixed in 2.4.14. > slapd.conf > ####################################################################### > # bdb database definitions > ####################################################################### > database bdb > suffix "ou=nisdata" > ####################################################################### > # Definitions for proxy and cache to AD > ####################################################################### > database meta > suffix "dc=my-customer,dc=com" > # The link to AD: > uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com > ldaps://ldap-prd-dc02.my-customer.com/ > # The link to the NIS data directory (yes, we could chain/glue, that's > # for later) > uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com Pointing back-meta at its own slapd will inevitably exhaust the thread pool since incoming operations will always use 2x the number of available threads. This ITS will be closed. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Probably a side-effect of fixing ITS#5853: >> This seems to be unrelated from ITS#5853, actually. > > Fixed now in HEAD Thanks. I did not realize I was trying an exceptional configuration. >> Another note: if a search reference is received, it is returned by >> libldap and additionally it is chased, so one gets both the search >> reference and the chased search reference results. > > 2.3 does this as well, seems to be intentional. I tested the scenario I described in a previous mail, and nothing weird showed up. I might have screwed up something? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Probably a side-effect of fixing ITS#5853: > > This seems to be unrelated from ITS#5853, actually. Fixed now in HEAD > Another note: if a search reference is received, it is returned by > libldap and additionally it is chased, so one gets both the search > reference and the chased search reference results. 2.3 does this as well, seems to be intentional. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (82.63.140.131) >>> Submitted by: ando >>> >>> >>> Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, >>> libldap automatically chases any referrals, but at the end returns a response >>> with ld_errno set to 10 and ld_matched set to the portion of DN that was matched >>> in the initial request. This is because the corresponding fields in the parent >>> request are not cleared when the referral is successfully chased. I'm trying to >>> fix this, but it's not clear to me when success should be detected: at >>> successful referral chasing request submission, I guess? >> When does this behavior? It doesn't show up in e.g. test009... > > If you have a subordinate reference in server1 that points to server2 > and you search server1 using the DN of the subordinate reference. What > I do is: > > - fire test003 > > - create a slapd.2.conf with suffix "ou=Other,dc=example,dc=com" > > - populate server1 with > > dn: ou=Other,dc=example,dc=com > objectClass: referral > objectClass: extensibleObject > ou: Other > ref: ldap://:9012/ou=Other,dc=example,dc=com > > - populate server2 with > > dn: ou=Other,dc=example,dc=com > objectClass: organizationalUnit > ou: Other > > dn: cn=Foo Bar,ou=Other,dc=example,dc=com > objectClass: device > cn: Foo Bar > > - search server1 for "ou=Other,dc=example,dc=com" According to libldap/request.c this test is invalid; find_connection will not match URLs with empty hostname. That code has been like that for several years. Perhaps the test for empty hostname should be dropped, but in real deployments a referral to localhost doesn't make a lot of sense anyway. > > Apparently, test009 is only testing the superior reference. test016 > tests subordinate references, but without even trying -C. I think the > test should be modified to be run once without and once with -C in order > to test the library's behavior. I believe automatic referral chasing > should be deprecated, but I fear there are tons of code out there that > rely on 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, >> libldap automatically chases any referrals, but at the end returns a response >> with ld_errno set to 10 and ld_matched set to the portion of DN that was matched >> in the initial request. This is because the corresponding fields in the parent >> request are not cleared when the referral is successfully chased. I'm trying to >> fix this, but it's not clear to me when success should be detected: at >> successful referral chasing request submission, I guess? > > When does this behavior? It doesn't show up in e.g. test009... If you have a subordinate reference in server1 that points to server2 and you search server1 using the DN of the subordinate reference. What I do is: - fire test003 - create a slapd.2.conf with suffix "ou=Other,dc=example,dc=com" - populate server1 with dn: ou=Other,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: Other ref: ldap://:9012/ou=Other,dc=example,dc=com - populate server2 with dn: ou=Other,dc=example,dc=com objectClass: organizationalUnit ou: Other dn: cn=Foo Bar,ou=Other,dc=example,dc=com objectClass: device cn: Foo Bar - search server1 for "ou=Other,dc=example,dc=com" Apparently, test009 is only testing the superior reference. test016 tests subordinate references, but without even trying -C. I think the test should be modified to be run once without and once with -C in order to test the library's behavior. I believe automatic referral chasing should be deprecated, but I fear there are tons of code out there that rely on it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5988) entries skipped in n-way mutimaster replication
by adrien.futschik＠atosorigin.com 03 Mar '09

03 Mar '09

Full_Name: Adrien Futschik Version: 2.4.15 OS: Linux RHEL 4-5 & Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.54.193.59) Hello, As suggested by Howard Chu, I am filling an ITS for a problem I encountered when testing N-way multimaster with OpenLDAP 2.4.15. Here is the situation : I have been testing n-way multimaster replication with OpenLDAP for a while now (from 2.4.11, to 2.4.15) and just when I though that everything was working perfectly, I dicided to test N-way multimaster not only with 2 masters on different servers, but with 4 ! (all 4 servers are time-synced using NTP) 2 OpenLDAP instances per server. I have been configuring syncprov and syncrepl accordingly : olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 I am starting with all instances synced and I am trying to add entries en all four instances (in //). If I do so, I have a few entries that are not replicated on the others. I am getting this kind of messages : do_syncrep2: cookie=rid=011,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=011 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=013,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=014,sid=002,csn=20090227130003.946474Z#000000#004#000000 Did someone face the same issue ? Here is my configuration : (I am using refreshAndPersist mode for both cn=config and olcDatabase={1}bdb) M1 on IP1 / PORT1 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 createTimestamp: 20090227085748Z entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M2 on IP2 / PORT2 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8da75037-65e6-4375-8c21-7e5c0194a60b creatorsName: cn=config createTimestamp: 20090227085723Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085725.003182Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20090227085725Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M3 on IP1 / PORT3 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: cf068647-318f-4848-9c72-9c7745a8a4b3 creatorsName: cn=config createTimestamp: 20090227085742Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085743.825685Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20090227085743Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M4 on IP2 / PORT4 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 creatorsName: cn=config createTimestamp: 20090227085748Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z Considering that M1 & M3 are on the same server and therefore have exactly the same time, if this was a time related problem, I shouldn't get any "CSN too old" messages between M1&M3 and M2&M4, should I ? I have also noticed that when M1 gets a new entry and passes it to M2&M3&M4, when M2&M3&M4 receive it, they also pass it to M2&M3&M4 ! I don't understand why this appends but it look's very much like this is what's happening, because sometimes, M2 would have passed-it to M4, before M4 has actually received the add order from M1. I therefore happen to notice that sometimes, entries send from M1 are received in the wrong order by other masters and therefore some entries may be skipped !!! Here is a example : I add cn=M1client1 & cn=M1client2 on M1, M1client1 & M1client2 are successfully replicated on M2&M4 but on M3, only M1client2 is inserted and I am getting an "CSN too old" message for M1client1 on M3. I guess that M2 or M4 are not managing there queues in the right order. I don't exactly understand why M2&M3&M4 should propagate en entry sent by M1, because they will eventually receive the entry sent by M1. Adrien Futschik

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 02 Mar '09

02 Mar '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, > libldap automatically chases any referrals, but at the end returns a response > with ld_errno set to 10 and ld_matched set to the portion of DN that was matched > in the initial request. This is because the corresponding fields in the parent > request are not cleared when the referral is successfully chased. I'm trying to > fix this, but it's not clear to me when success should be detected: at > successful referral chasing request submission, I guess? When does this behavior? It doesn't show up in e.g. test009... -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 02 Mar '09

02 Mar '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> ando(a)sys-net.it wrote: >>> >>>> Probably a side-effect of fixing ITS#5853: >>> This seems to be unrelated from ITS#5853, actually. >> Have you found the same behavior in earlier releases? > > 2.3 is OK. > 2.4.11,15 are affected. No relevant diff in libldap from 2.4.7 to .11. But quite a lot of changes in result.c from 2.4.1ALPHA to 2.4.7... -- -- 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#5987) replication documentation
by francis＠badape.net 02 Mar '09

02 Mar '09

Full_Name: Version: 2.4.15 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.6.103.253) I've had a number of issues getting replications working, I noticed that my multi-homed server was trying to replicate to itself. however I was pointed to http://www.openldap.org/its/index.cgi/?findid=5942 If the documentation could state when setting up replication that slap -H $URI needs to match all other references, even to the point where it has to match port, ie ldap://ldap01 != ldap://ldap01:389 making everything match has fixed a lot of my problems.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by hyc＠symas.com 02 Mar '09

02 Mar '09

ando(a)sys-net.it wrote: > mariusp44(a)gmail.com wrote: >> I have just compiled and tested 2.4.15 and result is same: cleartext, >> md5 and sha works, smd5, ssha and crypt doesn't. >> >> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. > > I have no chance to test on that arch. You should figure our why those > hashes are not supported. Did you enable crypt (--enable-crypt)? gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ and is known to have many bugs. It's also already known that old gcc releases have other problems on Sparc. (E.g. ITS#5875.) Please use a working compiler. As a workaround, recompile the offending functions with optimization disabled. That usually helps in cases like this. There is no bug in OpenLDAP Software here, this ITS will be closed. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 02 Mar '09

02 Mar '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Probably a side-effect of fixing ITS#5853: >> >> This seems to be unrelated from ITS#5853, actually. > > Have you found the same behavior in earlier releases? 2.3 is OK. 2.4.11,15 are affected. >> Another note: if a search reference is received, it is returned by >> libldap and additionally it is chased, so one gets both the search >> reference and the chased search reference results. > > That certainly wouldn't have changed due to any of the recent patches. > Probably the response gets added to the message chain unconditionally, > but obviously doesn't belong there if chasing occurred. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5985) replication lockout with syncrepl
by hyc＠symas.com 02 Mar '09

02 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3/2.4/HEAD > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of > changes, and you have 3+ replicas, usually 2 replicas will end up getting all of > the changes while the 3rd+ replicas have to wait until those 2 finish before > getting changes. If the high rate of changes goes on for a long enough period > of time, this can cause the other replicas to get so far out of sync that it is > more efficient to reload them than to wait on them to re-sync. I discussed this > with Howard, and in reviewing the code, he sees there's an underlying design > issue with updates that is causing this. His comments: > > Once a thread for a psearch wakes up, it sends all the changes that were queued > so it may hog an entire thread for a long time before the next psearch comes off > the queue > Fixing this issue would require a complete redesign of the psearch queue handling. Instead of queuing up a separate response per psearch, there should be a single queue of responses, and the qplayer should iterate thru to match a response to each of the active psearches. That would guarantee that all replicas receive a given change before any of them receives the next change. This would also help with the ordering issues discussed recently on -technical and -devel. I suspect this is too big a change to target the next (.16) release, since we're focusing on re-stabilizing the code right now. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 02 Mar '09

02 Mar '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Probably a side-effect of fixing ITS#5853: > > This seems to be unrelated from ITS#5853, actually. Have you found the same behavior in earlier releases? > > Another note: if a search reference is received, it is returned by > libldap and additionally it is chased, so one gets both the search > reference and the chased search reference results. That certainly wouldn't have changed due to any of the recent patches. Probably the response gets added to the message chain unconditionally, but obviously doesn't belong there if chasing occurred. -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 02 Mar '09

02 Mar '09

mariusp44(a)gmail.com wrote: > I have just compiled and tested 2.4.15 and result is same: cleartext, > md5 and sha works, smd5, ssha and crypt doesn't. > > Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. I have no chance to test on that arch. You should figure our why those hashes are not supported. Did you enable crypt (--enable-crypt)? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5986) backglue tool entry_{first, next} may fail when DBs are empty
by ando＠sys-net.it 02 Mar '09

02 Mar '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Under some special circumstances, like sequences of empty/full/empty databases, the glue_tool_entry_first/glue_tool_entry_next sequence may fail. I think I've fixed the problem; please review. p.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 02 Mar '09

02 Mar '09

I have just compiled and tested 2.4.15 and result is same: cleartext, md5 and sha works, smd5, ssha and crypt doesn't. Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. /Marius On Mon, Mar 2, 2009 at 8:55 AM, <ando(a)sys-net.it> wrote: > michael(a)stroeder.com wrote: >> mariusp44(a)gmail.com wrote: >>> I am running openldap 2.4.11 >> >> Note that this release is already a bit old. If you're testing it is >> more helpful to use a recent release (like 2.4.15 at the moment). > > The fact is that there is no point in chasing a bug in an old release. > If the bug exists in the latest, fine. Otherwise one needs to upgrade > anyway, either to the latest release or to the forthcoming when the bug > is fixed. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > >

1 0

Re: (ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 8:37 PM +0000 quanah(a)zimbra.com wrote: > --On Monday, March 02, 2009 9:28 PM +0100 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> It's working just fine here (HEAD/re24). The main differences in >> configuration are modules (everything here is built statically) and few >> paths, URIs and so. You should walk through it with a debugger, after >> identifying (with -d -1) how far it gets before going berserk. > > But -d -1, as I pasted before, didn't actually show anything I saw useful > at all. And I don't have access to their system. :/ > > Once my servers are back online, I can play with this more. I'd guess > it's one of those weird load dependencies we've been seeing. Changing compilers/libc/kernel (i.e. using a different OS) resolved it, so it must be a libc/compiler/optimization/kernel bug of some sort. Pick any one or more. :P I'll close the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 02 Mar '09

02 Mar '09

I would like to end the patch of dnssrv.c by implementing the weighty notion in SRV searchs (according to the rfc2782); but the use of a file disk to store the previous answers does seem to me a very successful solution. Would anybody have better one idea?...

1 0

Re: (ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 9:28 PM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > It's working just fine here (HEAD/re24). The main differences in > configuration are modules (everything here is built statically) and few > paths, URIs and so. You should walk through it with a debugger, after > identifying (with -d -1) how far it gets before going berserk. But -d -1, as I pasted before, didn't actually show anything I saw useful at all. And I don't have access to their system. :/ Once my servers are back online, I can play with this more. I'd guess it's one of those weird load dependencies we've been seeing. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5984) chain/syncprov problems
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)zimbra.com wrote: > Same problem once it is changed to: > > overlay chain > chain-uri "ldap://xxx" > chain-idassert-bind bindmethod="simple" > binddn="cn=Manager,dc=XYZ,dc=com" > credentials="secrets" > mode="self" > chain-tls start > chain-return-error TRUE > > > slapd still fails to start as long as both chain and syncprov are enabled. > It also fails to log any reason as to why it's failing to start up. It's working just fine here (HEAD/re24). The main differences in configuration are modules (everything here is built statically) and few paths, URIs and so. You should walk through it with a debugger, after identifying (with -d -1) how far it gets before going berserk. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 7:58 PM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> chain-idassert-bind >> bindmethod="simple" >> binddn="cn=Manager,dc=XYX,dc=com" >> credentials="secret" >> mode="self" >> chain-tls start >> chain-return-error TRUE > > chain-tls start > chain-return-error TRUE > > are not allowed within a "chain-idassert-bind"; probably the leading > whitespace is not intended. Same problem once it is changed to: overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYZ,dc=com" credentials="secrets" mode="self" chain-tls start chain-return-error TRUE slapd still fails to start as long as both chain and syncprov are enabled. It also fails to log any reason as to why it's failing to start up. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5985) replication lockout with syncrepl
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 7:59 PM +0000 ando(a)sys-net.it wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3/2.4/HEAD >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> I noticed back in testing with OpenLDAP 2.3 that if a master gets a high >> rate of changes, and you have 3+ replicas, usually 2 replicas will end >> up getting all of the changes while the 3rd+ replicas have to wait until >> those 2 finish before getting changes. If the high rate of changes goes >> on for a long enough period of time, this can cause the other replicas >> to get so far out of sync that it is more efficient to reload them than >> to wait on them to re-sync. I discussed this with Howard, and in >> reviewing the code, he sees there's an underlying design issue with >> updates that is causing this. His comments: >> >> Once a thread for a psearch wakes up, it sends all the changes that were >> queued so it may hog an entire thread for a long time before the next >> psearch comes off the queue > > Is this supposed to hit 2.4 as well, as you indicated in the ITS' > "Version"? Yes. It affects OL2.3, OL2.4, and remains this way in current HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5985) replication lockout with syncrepl
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3/2.4/HEAD > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of > changes, and you have 3+ replicas, usually 2 replicas will end up getting all of > the changes while the 3rd+ replicas have to wait until those 2 finish before > getting changes. If the high rate of changes goes on for a long enough period > of time, this can cause the other replicas to get so far out of sync that it is > more efficient to reload them than to wait on them to re-sync. I discussed this > with Howard, and in reviewing the code, he sees there's an underlying design > issue with updates that is causing this. His comments: > > Once a thread for a psearch wakes up, it sends all the changes that were queued > so it may hog an entire thread for a long time before the next psearch comes off > the queue Is this supposed to hit 2.4 as well, as you indicated in the ITS' "Version"? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5984) chain/syncprov problems
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)zimbra.com wrote: > chain-idassert-bind > bindmethod="simple" > binddn="cn=Manager,dc=XYX,dc=com" > credentials="secret" > mode="self" > chain-tls start > chain-return-error TRUE chain-tls start chain-return-error TRUE are not allowed within a "chain-idassert-bind"; probably the leading whitespace is not intended. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5985) replication lockout with syncrepl
by quanah＠OpenLDAP.org 02 Mar '09

02 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of changes, and you have 3+ replicas, usually 2 replicas will end up getting all of the changes while the 3rd+ replicas have to wait until those 2 finish before getting changes. If the high rate of changes goes on for a long enough period of time, this can cause the other replicas to get so far out of sync that it is more efficient to reload them than to wait on them to re-sync. I discussed this with Howard, and in reviewing the code, he sees there's an underlying design issue with updates that is causing this. His comments: Once a thread for a psearch wakes up, it sends all the changes that were queued so it may hog an entire thread for a long time before the next psearch comes off the queue

1 0

(ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a discussion with a user on the #openldap channel in IRC, they noted that if they had both the chain and syncprov overlays enabled in their configuration, slapd would refuse to start. Commenting out either one allowed slapd to start. I didn't see any obvious misconfigurations on their part. Configs as follows: include /usr/local/openldap-2.4.15/etc/openldap/schema/core.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/cosine.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/misc.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/nis.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/dyngroup.schema pidfile /usr/local/openldap-2.4.15/var/run/slapd.pid argsfile /usr/local/openldap-2.4.15/var/run/slapd.args modulepath /usr/local/openldap-2.4.15/libexec/openldap moduleload accesslog.la moduleload auditlog.la moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload dyngroup.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la # TLS Section TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSCACertificateFile /usr/local/openldap-2.4.15/etc/openldap/cacert.pem TLSCertificateFile /usr/local/openldap-2.4.15/etc/openldap/servercert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.15/etc/openldap/serverkey.pem TLSVerifyClient never security tls=256 password-crypt-salt-format "$1$%.8s$" loglevel 256 loglevel stats sync overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYX,dc=com" credentials="secret" mode="self" chain-tls start chain-return-error TRUE database bdb suffix "dc=XYZ,dc=com" rootdn "cn=Manager,dc=XYZ,dc=com" rootpw secret directory /usr/local/openldap-2.4.15/var/openldap-data/XYZ.com-slave overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=010 provider=ldap://xxx type=refreshAndPersist interval=00:00:00:05 searchbase="dc=XYZ,dc=com" bindmethod=simple binddn="cn=SyncRepl,dc=XYZ,dc=com" credentials=secret retry="5 5 300 5" starttls=yes tls_reqcert=never slapd -d -1 output wasn't too helpful, either: @(#) $OpenLDAP: slapd 2.4.15 (Mar 2 2009 11:27:50) $ bill@crash:/home/bill/openldap-2.4.15/servers/slapd ldap_pvt_gethostbyname_a: host=crash, r=0 daemon_init: listen on ldap:// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) daemon: listener initialized ldap:// daemon_init: 2 listeners opened ldap_create slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008) bdb_db_init: Initializing BDB database >>> dnPrettyNormal: <dc=XYZ,dc=com> <<< dnPrettyNormal: <dc=XYZ,dc=com>, <dc=XYZ,dc=com> >>> dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com> <<< dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com>, <cn=manager,dc=XYZ,dc=com> >>> dnNormalize: <cn=Manager,dc=XYZ,dc=com> <<< dnNormalize: <cn=manager,dc=XYZ,dc=com> slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 02 Mar '09

02 Mar '09

michael(a)stroeder.com wrote: > mariusp44(a)gmail.com wrote: >> I am running openldap 2.4.11 > > Note that this release is already a bit old. If you're testing it is > more helpful to use a recent release (like 2.4.15 at the moment). The fact is that there is no point in chasing a bug in an old release. If the bug exists in the latest, fine. Otherwise one needs to upgrade anyway, either to the latest release or to the forthcoming when the bug is fixed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by michael＠stroeder.com 02 Mar '09

02 Mar '09

mariusp44(a)gmail.com wrote: > I am running openldap 2.4.11 Note that this release is already a bit old. If you're testing it is more helpful to use a recent release (like 2.4.15 at the moment). Ciao, Michael.

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 02 Mar '09

02 Mar '09

Howard, Thank you for your great knowledge in the OpenLDAP internals. I will also give a try and check but looks like you could pinpoint the issue and solve it. I would like to say this will greatly allow many users to control better memory usage and then have DBs bigger than available memory, what can be very common nowadays. I normally will not have 2 process searching DB simultaneously, this was just a test. In this way performance, in average, will be reasonable. Thanks a lot! Rodrigo. --- On Mon, 3/2/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Monday, March 2, 2009, 4:36 AM > Rodrigo Costa wrote: > > Howard, > > > > One more comment. If you take a longer time between > the ldapsearches the > issue doesn't appear sometimes. > > > > So you need to start the first ldapsearh and like 15 > seconds later start > > the > second one. With this scenario the problem will for sure > appear. > > I was finally able to reproduce this issue, by running two > identical searches simultaneously on a server with more than > 2 CPU cores. Given any delay between the two search > invocation, the problem did not appear. > > This is now fixed in HEAD. Thanks for your help in > providing data for reproducing the issue. > > > In this way we will see large chunks of memory being > allocated and after > > it > stabilizes the query get stuck returning as the issue > before 16 records per > minute, or very slow and getting stuck all the time. > > I should point out - the memory use is stabilized now (as > it should be) but the search performance of a configuration > such as yours will be extremely poor due to the unavoidable > thrashing that such a query pattern exerts on the cache. > Setting a larger minfree can help reduce some of the > contention but it will still be much slower than normal. > > > Regards, > > > > Rodrigo. > > > -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by Pierangelo Masarati 02 Mar '09

02 Mar '09

> Full_Name: Marius Paulauskas > Version: 2.4.11 > OS: Solaris 10 (SPARC) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.201.141.149) Please retry with latest. p.

1 0

Re: (ITS#5982) man page for ldapexop
by Gavin Henry 02 Mar '09

02 Mar '09

Thanks for your contribution! Could you take a read of: http://www.openldap.org/devel/contributing.html#notice with an example of the format at the top of: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Thanks and always appreciated! Gavin.

1 0

ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC openldap 2.4.11
by Marius Paulauskas 02 Mar '09

02 Mar '09

Hello, I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc. Wondering if anyone experienced similar issue. Regards, /Marius

3 2

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 01 Mar '09

01 Mar '09

Rodrigo Costa wrote: > Howard, > > One more comment. If you take a longer time between the ldapsearches the issue doesn't appear sometimes. > > So you need to start the first ldapsearh and like 15 seconds later start > the second one. With this scenario the problem will for sure appear. I was finally able to reproduce this issue, by running two identical searches simultaneously on a server with more than 2 CPU cores. Given any delay between the two search invocation, the problem did not appear. This is now fixed in HEAD. Thanks for your help in providing data for reproducing the issue. > In this way we will see large chunks of memory being allocated and after > it stabilizes the query get stuck returning as the issue before 16 records per minute, or very slow and getting stuck all the time. I should point out - the memory use is stabilized now (as it should be) but the search performance of a configuration such as yours will be extremely poor due to the unavoidable thrashing that such a query pattern exerts on the cache. Setting a larger minfree can help reduce some of the contention but it will still be much slower than normal. > Regards, > > Rodrigo. -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 01 Mar '09

01 Mar '09

Full_Name: Marius Paulauskas Version: 2.4.11 OS: Solaris 10 (SPARC) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.201.141.149) I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc.

1 0

Re: (ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by hyc＠symas.com 01 Mar '09

01 Mar '09

peter(a)adpm.de wrote: > Full_Name: Peter Marschall > Version: 2.4.15 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > Submission from: (NULL) (92.75.56.86) > > > Hi, > > when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting > TLSVerifyClient Try > in slapd.conf makes TLS connections without certificates impossible. > > This is caused by incomplete decoding in tls_g.c > > The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > fixes this issue together with a few other little cleanups: > - remove unused variables (less compiler warnings) > - use correct types (less compiler warnings) > - detect failed calls for activation/exiration functions to > avoid giving wrong information > > Please consider adding this patch to OpenLDAP Thanks for the patch, committed to HEAD. > > Regards > Peter > -- -- 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#5982) man page for ldapexop
by peter＠adpm.de 01 Mar '09

01 Mar '09

Full_Name: Peter Marschall Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 Submission from: (NULL) (94.217.131.234) Hi, doing a little bug triaging for Debian, I noticed there is not man page for ldapexop. At ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 you can find my first draft for it. Please adapt as you please and add it to the next release. Regards Peter

1 0

(ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by peter＠adpm.de 01 Mar '09

01 Mar '09

Full_Name: Peter Marschall Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch Submission from: (NULL) (92.75.56.86) Hi, when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting TLSVerifyClient Try in slapd.conf makes TLS connections without certificates impossible. This is caused by incomplete decoding in tls_g.c The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch fixes this issue together with a few other little cleanups: - remove unused variables (less compiler warnings) - use correct types (less compiler warnings) - detect failed calls for activation/exiration functions to avoid giving wrong information Please consider adding this patch to OpenLDAP Regards Peter

1 0

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 28 Feb '09

28 Feb '09

ando(a)sys-net.it wrote: > Probably a side-effect of fixing ITS#5853: This seems to be unrelated from ITS#5853, actually. Another note: if a search reference is received, it is returned by libldap and additionally it is chased, so one gets both the search reference and the chased search reference results. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 28 Feb '09

28 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, libldap automatically chases any referrals, but at the end returns a response with ld_errno set to 10 and ld_matched set to the portion of DN that was matched in the initial request. This is because the corresponding fields in the parent request are not cleared when the referral is successfully chased. I'm trying to fix this, but it's not clear to me when success should be detected: at successful referral chasing request submission, I guess? p.

1 0

Re: (ITS#5979) ppolicy & access log crashes server
by hyc＠symas.com 27 Feb '09

27 Feb '09

Peter Giesin wrote: > Since the database was corrupted (we were getting a Segmentation Fault > when restarting the server) we simply removed the database. I guess if > we recovered the database instead we would have gotten the same results. Recovery is preformed automatically on startup. Wiping the DB and starting over isn't necessary; if the disks holding the transaction logs don't burn up/fail then corruption simply isn't an issue. > Thanks for the quick fix. You're welcome... > > Pete > > On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > pgiesin(a)gmail.com <mailto:pgiesin@gmail.com> wrote: > > Full_Name: Peter Giesin > Version: 2.4.13 > OS: Red Hat 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.187.213.234) > > > Enabled both accesslog and ppolicy overlays (configurations > included below). All > attempts to bind with an invalid password causes the server to > crash and > database to be corrupted. If you disable either of the overlays > or just the > "logold" setting of the accesslog the behavior is no longer noticed. > > > Interesting, for me only the first attempt crashed; after restarting > the same attempt just failed normally. Anyway, thanks for the > report, this is now fixed in HEAD. -- -- 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#5979) ppolicy & access log crashes server
by pgiesin＠gmail.com 27 Feb '09

27 Feb '09

--000e0cd4d91a91c2d40463f28568 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Since the database was corrupted (we were getting a Segmentation Fault when restarting the server) we simply removed the database. I guess if we recovered the database instead we would have gotten the same results. Thanks for the quick fix. Pete On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com> wrote: > pgiesin(a)gmail.com wrote: > >> Full_Name: Peter Giesin >> Version: 2.4.13 >> OS: Red Hat 5.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.187.213.234) >> >> >> Enabled both accesslog and ppolicy overlays (configurations included >> below). All >> attempts to bind with an invalid password causes the server to crash and >> database to be corrupted. If you disable either of the overlays or just >> the >> "logold" setting of the accesslog the behavior is no longer noticed. >> > > Interesting, for me only the first attempt crashed; after restarting the > same attempt just failed normally. Anyway, thanks for the report, this is > now fixed in HEAD. > > overlay ppolicy >> ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com >> ppolicy_use_lockout TRUE >> ppolicy_hash_cleartext TRUE >> >> overlay accesslog >> logdb cn=log >> logops all >> logold (objectclass=*) >> logpurge 5+00:00 1+00:00 >> logsuccess TRUE >> >> dn: cn=Standard,ou=Policies,dc=amwater,dc=com >> cn: Standard >> description: Standard password policy. >> pwdAttribute: 2.5.4.35 >> pwdMinAge: 60 >> # 30 days: 60 sec * 60 min * 24 hr * 30 days >> pwdMaxAge: 2592000 >> pwdCheckQuality: 1 >> pwdMinLength: 7 >> # Warn three days in advance >> pwdExpireWarning: 259200 >> pwdGraceAuthNLimit: 3 >> pwdLockout: TRUE >> pwdLockoutDuration: 1200 >> pwdMaxFailure: 3 >> pwdFailureCountInterval: 1200 >> pwdMustChange: TRUE >> pwdAllowUserChange: TRUE >> pwdSafeModify: TRUE >> objectclass: device >> objectclass: pwdPolicy >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000e0cd4d91a91c2d40463f28568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since the database was corrupted (we were getting a Segmentation Fault when= restarting the server) we simply removed the database. I guess if we recov= ered the database instead we would have gotten the same results. Thanks for the quick fix. Pete <div class=3D"gmail_quote">On = Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <<a href=3D"= mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote: <blockquote cl= ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar= gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <a href=3D"mailto:pgiesin@gmail.com" target=3D"_blank">pgiesin(a)gmail.com</a= > wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Full_Name: Peter Giesin Version: 2.4.13 OS: Red Hat 5.2 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (24.187.213.234) Enabled both accesslog and ppolicy overlays (configurations included below)= . All attempts to bind with an invalid password causes the server to crash and<br= > database to be corrupted. If you disable either of the overlays or just the= "logold" setting of the accesslog the behavior is no longer notic= ed. </blockquote> Interesting, for me only the first attempt crashed; after restarting the sa= me attempt just failed normally. Anyway, thanks for the report, this is now= fixed in HEAD. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> overlay ppolicy ppolicy_default cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom ppolicy_use_lockout TRUE ppolicy_hash_cleartext TRUE overlay accesslog logdb cn=3Dlog logops all logold (objectclass=3D*) logpurge 5+00:00 1+00:00 logsuccess TRUE dn: cn=3DStandard,ou=3DPolicies,dc=3Damwater,dc=3Dcom cn: Standard description: Standard password policy. pwdAttribute: 2.5.4.35 pwdMinAge: 60 # 30 days: 60 sec * 60 min * 24 hr * 30 days pwdMaxAge: 2592000 pwdCheckQuality: 1 pwdMinLength: 7 # Warn three days in advance pwdExpireWarning: 259200 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxFailure: 3 pwdFailureCountInterval: 1200 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectclass: device objectclass: pwdPolicy </blockquote> -- =C2=A0-- Howard Chu =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --000e0cd4d91a91c2d40463f28568--

1 0

Re: (ITS#5979) ppolicy & access log crashes server
by hyc＠symas.com 27 Feb '09

27 Feb '09

pgiesin(a)gmail.com wrote: > Full_Name: Peter Giesin > Version: 2.4.13 > OS: Red Hat 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.187.213.234) > > > Enabled both accesslog and ppolicy overlays (configurations included below). All > attempts to bind with an invalid password causes the server to crash and > database to be corrupted. If you disable either of the overlays or just the > "logold" setting of the accesslog the behavior is no longer noticed. Interesting, for me only the first attempt crashed; after restarting the same attempt just failed normally. Anyway, thanks for the report, this is now fixed in HEAD. > overlay ppolicy > ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com > ppolicy_use_lockout TRUE > ppolicy_hash_cleartext TRUE > > overlay accesslog > logdb cn=log > logops all > logold (objectclass=*) > logpurge 5+00:00 1+00:00 > logsuccess TRUE > > dn: cn=Standard,ou=Policies,dc=amwater,dc=com > cn: Standard > description: Standard password policy. > pwdAttribute: 2.5.4.35 > pwdMinAge: 60 > # 30 days: 60 sec * 60 min * 24 hr * 30 days > pwdMaxAge: 2592000 > pwdCheckQuality: 1 > pwdMinLength: 7 > # Warn three days in advance > pwdExpireWarning: 259200 > pwdGraceAuthNLimit: 3 > pwdLockout: TRUE > pwdLockoutDuration: 1200 > pwdMaxFailure: 3 > pwdFailureCountInterval: 1200 > pwdMustChange: TRUE > pwdAllowUserChange: TRUE > pwdSafeModify: TRUE > objectclass: device > objectclass: pwdPolicy > > -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 27 Feb '09

27 Feb '09

Name of the tarball posted on ftp.openldap.org : philippe_eychart_openldap_x-dnssrv_20090227.tgz. Content: - file1 : openldap-2.4.13-i486-1.x-dnssrv.open.c.20090227.patch (8918 bytes) - file2 : openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.20090227.patch (5437 bytes) (necessary to patch1 because of the possible empty domain argument option - and, of course, to implement the priority notion ...) Regards

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 27 Feb '09

27 Feb '09

I must be tired !... ;) The good result is ... : "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap2.backup.gov.pf.:390/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:389/o=gov%2cc=pf" yes!!! -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoyé : vendredi 27 février 2009 13:39 À : openldap-its(a)openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf:389/o=gov%2cdc=pf" -- PE

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 27 Feb '09

27 Feb '09

Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/o=gov%2cdc=pf" -- PE

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 27 Feb '09

27 Feb '09

Hi, Here is the description of use of the current version of the "x-dnssrv" extension through some examples: CONTEXT OF EXAMPLE : /etc/resolv.conf: search gov.pf nameserver localhost /var/named/pz/gov.pf: $ORIGIN gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap IN SRV 1 1 389 ldap1.backup.gov.pf. IN SRV 1 1 390 ldap2.backup.gov.pf. ... and /var/named/pz/backup.gov.pf: $ORIGIN backup.gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap0 IN SRV 0 1 389 ldap1 ... LDAP URI EXAMPLES FOR THE "x-dnssrv" EXTENSION: For: "ldap:///ou=person,dc=gov,dc=pf??sub??x-dnssrv=dc=gov%2cdc=pf" -> the result URI will be: "ldap://ldap.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap1.backup.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap2.backup.gov.pf.:390/ou=person,dc=gov,dc=pf??sub" For: "ldap:///????x-dnsSRV=gov.pf." -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap2.backup.gov.pf.:390 / ldap://ldap1.backup.gov.pf.:389" For: "ldap:///dc=gov%2cdc=pf????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:390/dc=gov%2cdc=pf" For: "ldap://gov.pf.:389/????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap1.backup.gov.pf.:389" For: "ldap:///????x-dnssrv[,extension]*" -> because of resolv.conf, the result URI will be: "ldap://ldap.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap1.backup.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap2.backup.gov.pf.:390/????[extension[,extension]*]*" WARNING: "ldap://goov.pf./????x-dnssrv" -> give: "" "ldap://gov.pf./????x-dnssrv,x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" "ldap:///dc=gov%2cdc=pf???sub?x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap0.backup.gov.pf.:389/dc=gov,dc=pf???sub \ ldap://ldap1.backup.gov.pf.:389/dc=gov,dc=pf???sub" "ldap://ldap.gov.pf/dc=backup%2cdc=gov%2cdc=pf????x-dnssrv" -> give: "ldap://ldap.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/dc=backup%2cdc=gov%2cdc=pf" "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of default the domain research ... -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" SYNTAX ERROR (the resultant URI will remain unchanged): "ldap://ldap.gov.pf/dc=gov%2cdc=pf????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=gov.pf." "ldap://dc=gov%2cdc=pf/????x-dnssrv" "ldap://gov.pf[/[?[?[?[?]]]]]" etc ... I proceed in the last check of sources and I post patchs (open.c & dnssrv.c) ... -- PE

1 0

(ITS#5979) ppolicy & access log crashes server
by pgiesin＠gmail.com 27 Feb '09

27 Feb '09

Full_Name: Peter Giesin Version: 2.4.13 OS: Red Hat 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.187.213.234) Enabled both accesslog and ppolicy overlays (configurations included below). All attempts to bind with an invalid password causes the server to crash and database to be corrupted. If you disable either of the overlays or just the "logold" setting of the accesslog the behavior is no longer noticed. overlay ppolicy ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com ppolicy_use_lockout TRUE ppolicy_hash_cleartext TRUE overlay accesslog logdb cn=log logops all logold (objectclass=*) logpurge 5+00:00 1+00:00 logsuccess TRUE dn: cn=Standard,ou=Policies,dc=amwater,dc=com cn: Standard description: Standard password policy. pwdAttribute: 2.5.4.35 pwdMinAge: 60 # 30 days: 60 sec * 60 min * 24 hr * 30 days pwdMaxAge: 2592000 pwdCheckQuality: 1 pwdMinLength: 7 # Warn three days in advance pwdExpireWarning: 259200 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxFailure: 3 pwdFailureCountInterval: 1200 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectclass: device objectclass: pwdPolicy

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 27 Feb '09

27 Feb '09

On Tue, 2008-12-16 at 14:52 +0000, Neil Dunbar wrote: > Andrew: > > One suggestion following a very quick scan of the code: I think it > > would be worth bringing the warning about turning off TLS checks > > into the manual page. > > Agreed. Done. > > > In particular, there is no reason for this > > to be AD-specific and it should be easy to adapt it to authenticate > > against any [collection of] remote LDAP servers. > > Actually, it may not be AD specific as is. Are we any further forward to getting this rolled into contrib? Is there more we need to do to make it fit better? The tarball has been sitting there a while, it would seem. Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by hyc＠symas.com 26 Feb '09

26 Feb '09

imjustmatthew(a)gmail.com wrote: > Full_Name: Matthew Roy > Version: 2.4.9 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.94.128.99) > > > In the Administrater's Guide, Section 18.3.1.3 > (http://www.openldap.org/doc/admin24/replication.html) there is no mention of > needing to explicitly load the "syncprov" module with a loadmodule directive. It > is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously > in 18.3.1 when setting up "plain" syncrepl between servers. Modules are an optional part of the configuration. You're expected to know that you need to use loadmodule if you configured module support. > > Simply adding it to the example server configuration so new users realize that > this module may need to be loaded would be sufficient. Otherwise, we try the > sample code and the testing server won't start and needs to be debugged. Sure > it's not a big deal, but first experiences should be as positive as possible. > -- -- 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

"error in SSLv3 flush data" when connecting from network again!
by Lifeng Wang 26 Feb '09

26 Feb '09

Hi All, After many googling, I find one thread in openldap mailing list year 2007, Feb to March about this issue, but no solution, and now it happened to me again. So I'm write to this mailing list to report this bug. I'm running openldap 2.3.27 on CentOS 5.2 x86_64. I configured TLS on the server, and localhost successfully connected to 389 port with start_tls. However when I try to connect to this ldap server with start_tls from a Fedora 10 x86_64 client, it hangs. As previous reported, if I launch slapd with -d2, remote client can connect to the server with TLS. by using -d1 on both server and client, server hangs at some where: TLS trace: SSL_accept:error in SSLv3 write certificate request B and client hangs at TLS trace: SSL_accept:SSLv3 read certificate A So, I rung -d2 on client, and find: tls_read: want=179, got=179 ... tls_read: want=5, got=5 ... tls_read: want=14771, got=9952 ... So, the last seconds shows client expecting 14771 bytes of data, but server only send 9952 bytes, so client thinking server will send more, but server get error? if I run same ldapsearch command from server (localhost), that line read as: tls_read: want=14771, got=14771 Does this ring the bell? Thanks Noodle

1 0

(ITS#5978) Addition to syncrepl Documentation in Administrater's Guide
by imjustmatthew＠gmail.com 26 Feb '09

26 Feb '09

Full_Name: Matthew Roy Version: 2.4.9 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.94.128.99) In the Administrater's Guide, Section 18.3.1.3 (http://www.openldap.org/doc/admin24/replication.html) there is no mention of needing to explicitly load the "syncprov" module with a loadmodule directive. It is mentioned when talking about Delta-syncrepl in 18.3.2, but is not previously in 18.3.1 when setting up "plain" syncrepl between servers. Simply adding it to the example server configuration so new users realize that this module may need to be loaded would be sufficient. Otherwise, we try the sample code and the testing server won't start and needs to be debugged. Sure it's not a big deal, but first experiences should be as positive as possible.

1 0

Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it 26 Feb '09

26 Feb '09

hyc(a)symas.com wrote: > Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on > attributes that were configured for sorting. I suppose a config option to > check all attrs may be useful, but for now it seems unnecessary. OK, I was working on a fix that always eliminated duplicates, but yours is saving the effort when not strictly needed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com 26 Feb '09

26 Feb '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> mhardin(a)symas.com wrote: >>> Full_Name: Matthew Hardin >>> Version: 2.4.14 >>> OS: RHEL4 x86 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.44.226.116) >>> >>> >>> Given an Active Directory group object containing the following two members: >>> >>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >>> >>> and >>> >>> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >>> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >>> >>> (note the extra space between "Frank" and "Y" in the second member) >>> >>> Active Directory sees these as different entries and allows them to both be >>> members of the same group. Back-LDAP and back-meta happily return both of these >>> values. >> I'd expect slapd-ldap to return two identical values, since value >> prettification also eliminates multiple spaces in directoryString values. > > Right. It's strange that the value with two spaces was preserved. Never mind, cn is DirectoryString and has no pretty function. > >>> When 'sortvals member' is turned on, the pcache overlay will cache this value >>> but will not return it on subsequent searches because it sees these two values >>> as duplicates. According to Howard Chu, this is because the equality matching >>> rule for the 'member' attribute collapses multiple spaces into one before doing >>> the comparison and so reports these two values as duplicates. >>> >>> Howard asked me to file this ITS as a means to solicit guidance from others as >>> to the best way/place to fix this. >> After value normalization, slapd-ldap I think should also check for >> duplicates (possibly leaving this as an option), and discard them. In >> fact, it is the proxy backend that injects broken data into the loop. Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on attributes that were configured for sorting. I suppose a config option to check all attrs may be useful, but for now it seems unnecessary. >> Of course, the best solution in your case would probably be to fix your >> data... :) > > Agreed on all points... -- -- 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#5977) pcache and broken Active Directory equality matching rules
by hyc＠symas.com 26 Feb '09

26 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.14 >> OS: RHEL4 x86 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.44.226.116) >> >> >> Given an Active Directory group object containing the following two members: >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> and >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> (note the extra space between "Frank" and "Y" in the second member) >> >> Active Directory sees these as different entries and allows them to both be >> members of the same group. Back-LDAP and back-meta happily return both of these >> values. > > I'd expect slapd-ldap to return two identical values, since value > prettification also eliminates multiple spaces in directoryString values. Right. It's strange that the value with two spaces was preserved. >> When 'sortvals member' is turned on, the pcache overlay will cache this value >> but will not return it on subsequent searches because it sees these two values >> as duplicates. According to Howard Chu, this is because the equality matching >> rule for the 'member' attribute collapses multiple spaces into one before doing >> the comparison and so reports these two values as duplicates. >> >> Howard asked me to file this ITS as a means to solicit guidance from others as >> to the best way/place to fix this. > > After value normalization, slapd-ldap I think should also check for > duplicates (possibly leaving this as an option), and discard them. In > fact, it is the proxy backend that injects broken data into the loop. > > Of course, the best solution in your case would probably be to fix your > data... :) Agreed on all points... -- -- 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#5977) pcache and broken Active Directory equality matching rules
by ando＠sys-net.it 26 Feb '09

26 Feb '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.14 > OS: RHEL4 x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.44.226.116) > > > Given an Active Directory group object containing the following two members: > > member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User > Accounts,ou=Common,dc=ad,dc=foobar,dc=com > > and > > member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User > Accounts,ou=Common,dc=ad,dc=foobar,dc=com > > (note the extra space between "Frank" and "Y" in the second member) > > Active Directory sees these as different entries and allows them to both be > members of the same group. Back-LDAP and back-meta happily return both of these > values. I'd expect slapd-ldap to return two identical values, since value prettification also eliminates multiple spaces in directoryString values. > When 'sortvals member' is turned on, the pcache overlay will cache this value > but will not return it on subsequent searches because it sees these two values > as duplicates. According to Howard Chu, this is because the equality matching > rule for the 'member' attribute collapses multiple spaces into one before doing > the comparison and so reports these two values as duplicates. > > Howard asked me to file this ITS as a means to solicit guidance from others as > to the best way/place to fix this. After value normalization, slapd-ldap I think should also check for duplicates (possibly leaving this as an option), and discard them. In fact, it is the proxy backend that injects broken data into the loop. Of course, the best solution in your case would probably be to fix your data... :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5977) pcache and broken Active Directory equality matching rules
by mhardin＠symas.com 26 Feb '09

26 Feb '09

Full_Name: Matthew Hardin Version: 2.4.14 OS: RHEL4 x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.44.226.116) Given an Active Directory group object containing the following two members: member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User Accounts,ou=Common,dc=ad,dc=foobar,dc=com and member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User Accounts,ou=Common,dc=ad,dc=foobar,dc=com (note the extra space between "Frank" and "Y" in the second member) Active Directory sees these as different entries and allows them to both be members of the same group. Back-LDAP and back-meta happily return both of these values. When 'sortvals member' is turned on, the pcache overlay will cache this value but will not return it on subsequent searches because it sees these two values as duplicates. According to Howard Chu, this is because the equality matching rule for the 'member' attribute collapses multiple spaces into one before doing the comparison and so reports these two values as duplicates. Howard asked me to file this ITS as a means to solicit guidance from others as to the best way/place to fix this. Comments? -Matt

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 26 Feb '09

26 Feb '09

ando(a)sys-net.it writes: > Correct. However I'm not sure whether the man page or the code needs to > be fixed. I'm open to suggestions. I'm inclined towards following the > man page, as the use of -d implies one may not need the pid, and knows > the args. It _may_ mean that. But the existence of the pidfile also means one need not save the pid after running slapd &. So I think it's best to keep the existing behavior, in case someone depends on the pidfile. -- Hallvard

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: hyc> aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. >> >> When starting it under debugging -d-1, I got to this: hyc> I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now hyc> in HEAD. Yes, 2.4, once I typed one wrong, I copied my mistake again and again.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by aej＠WPI.EDU 25 Feb '09

25 Feb '09

>>>>> "quanah" == Quanah Gibson-Mount <quanah(a)zimbra.com> writes: quanah> --On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: >> Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: >> Submission from: (NULL) (130.215.36.68) >> >> >> I somehow missed installing 2.1.14, and was still running 2.1.13. I found >> that 2.1.15 did not run on one of my servers (but worked on the other 2). >> Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked >> again on that same client still worked ok, so it doesn't appear that >> libraries went sour. The failure is on a gssapi syncrepl client on an >> opteron. The gssapi syncrepl client on Intel works ok. The master appears >> to work ok, too. The ldap server was running on appliance4 and was >> accessing the master on appliance1. quanah> OpenLDAP 2.1? That's years ancient, and no longer supported. Use a quanah> modern supported release. Well, there are a bunch of typos. It's 2.4 in all cases. I meant the 2.4.15 that was announced recently. I'd not installed 2.4.14, but that exhibits the same problem.

1 0

Re: (ITS#5976) seg fault problem starting with version 2.1.14
by hyc＠symas.com 25 Feb '09

25 Feb '09

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I found that > 2.1.15 did not run on one of my servers (but worked on the other 2). Looking > back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that > same client still worked ok, so it doesn't appear that libraries went sour. The > failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl > client on Intel works ok. The master appears to work ok, too. The ldap server > was running on appliance4 and was accessing the master on appliance1. > > When starting it under debugging -d-1, I got to this: I presume you meant 2.4.15, not 2.1.15. Thanks for the report, fixed now in HEAD. -- -- 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#5976) seg fault problem starting with version 2.1.14
by quanah＠zimbra.com 25 Feb '09

25 Feb '09

--On Wednesday, February 25, 2009 8:24 PM +0000 aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.1.15 > OS: Red Hat Linux E5 > URL: > Submission from: (NULL) (130.215.36.68) > > > I somehow missed installing 2.1.14, and was still running 2.1.13. I > found that 2.1.15 did not run on one of my servers (but worked on the > other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled > and linked again on that same client still worked ok, so it doesn't > appear that libraries went sour. The failure is on a gssapi syncrepl > client on an opteron. The gssapi syncrepl client on Intel works ok. The > master appears to work ok, too. The ldap server was running on > appliance4 and was accessing the master on appliance1. OpenLDAP 2.1? That's years ancient, and no longer supported. Use a modern supported release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5976) seg fault problem starting with version 2.1.14
by aej＠wpi.edu 25 Feb '09

25 Feb '09

Full_Name: Allan E. Johannesen Version: 2.1.15 OS: Red Hat Linux E5 URL: Submission from: (NULL) (130.215.36.68) I somehow missed installing 2.1.14, and was still running 2.1.13. I found that 2.1.15 did not run on one of my servers (but worked on the other 2). Looking back, 2.1.14 had the same problem. 2.1.13, compiled and linked again on that same client still worked ok, so it doesn't appear that libraries went sour. The failure is on a gssapi syncrepl client on an opteron. The gssapi syncrepl client on Intel works ok. The master appears to work ok, too. The ldap server was running on appliance4 and was accessing the master on appliance1. When starting it under debugging -d-1, I got to this: ldap_sasl_interactive_bind_s: user selected: gssapi ldap_int_sasl_bind: gssapi ldap_int_sasl_open: host=appliance1.wpi.edu Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43377940 (LWP 21161)] ber_get_tag (ber=0x433762c0) at decode.c:110 110 tag = *(unsigned char *)ber->ber_ptr; (gdb) where #0 ber_get_tag (ber=0x433762c0) at decode.c:110 #1 0x0000000000506bdb in ber_skip_tag (ber=0x433762c0, len=0x433763f8) at decode.c:169 #2 0x0000000000507653 in ber_peek_tag (ber=0x433762c0, len=0x433763f8) at decode.c:228 #3 0x0000000000502794 in ldap_X509dn2bv (x509_name=<value optimized out>, bv=0x43376520, func=0, flags=0) at tls2.c:1016 #4 0x0000000000502e6b in ldap_pvt_tls_get_my_dn (s=<value optimized out>, dn=0x43376520, func=0, flags=0) at tls2.c:876 #5 0x00000000004ebd8f in ldap_int_sasl_bind (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", sctrls=0x0, cctrls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at cyrus.c:479 #6 0x00000000004ed41c in ldap_sasl_interactive_bind_s (ld=0x16c76810, dn=0x0, mechs=0x1699c490 "gssapi", serverControls=0x0, clientControls=0x0, flags=2, interact=0x4dc160 <lutil_sasl_interact>, defaults=0x16d1c370) at sasl.c:464 #7 0x000000000041584b in slap_client_connect (ldp=0x1699d120, sb=0x1699cf20) at config.c:1764 #8 0x0000000000479dfa in do_syncrepl (ctx=0x43376d70, arg=<value optimized out>) at syncrepl.c:560 #9 0x00000000004e588a in ldap_int_thread_pool_wrapper (xpool=0x1693a410) at tpool.c:663 #10 0x0000003dedc06367 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003ded0d30ad in clone () from /lib64/libc.so.6

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by ando＠sys-net.it 25 Feb '09

25 Feb '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to make > any difference whether or not you use the -d option with slapd. > > This phrasing could be replaced with something that indicates if it is not > specified, the file will not be created. Correct. However I'm not sure whether the man page or the code needs to be fixed. I'm open to suggestions. I'm inclined towards following the man page, as the use of -d implies one may not need the pid, and knows the args. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 25 Feb '09

25 Feb '09

On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > The -compat code is LGPL. I'm considering copying the ciphersuite > handling and > a few other pieces out of there, directly into our tree. There's a > lot of > other baggage in the compat library we don't need, and there's some > OpenSSL > emulation that would interfere with the NSS code we already have. > Any problem > with excerpting the bits we need? I would need to take a very careful look at this. In general, the answer is "NO", don't bring in LGPL code into our primary code base (standalone LGPL in contrib is another matter). -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 25 Feb '09

25 Feb '09

hyc(a)symas.com wrote: > Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code > in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency > as well. That's a key requirement to me personally, because otherwise it will > not interoperate with Mozilla/Seamonkey, and right now that's my primary goal > for this work. The -compat code is LGPL. I'm considering copying the ciphersuite handling and a few other pieces out of there, directly into our tree. There's a lot of other baggage in the compat library we don't need, and there's some OpenSSL emulation that would interfere with the NSS code we already have. Any problem with excerpting the bits we need? > It's been a few months since I last looked at this and it took me a while to > remember all the issues surrounding it... > > There are two major problems with the current MozNSS support in HEAD: > 1) It does no initialization of its own. This works with Seamonkey/Thunderbird > because the main app has already initialized the NSS library; libldap just > uses the state that's already there. Code to initialize properly when NSS > hasn't already been initialized still needs to be written. > 2) It cannot shutdown safely. This is a weakness in the NSS API that was > discussed at length in the Mozilla newsgroups. Unfortunately that discussion > went nowhere. (The NSS_Shutdown() function tears down the library > unconditionally; if there were multiple callers of the library and one of them > shuts down because it's going away, all of the other callers lose the library > too.) It appears that not much progress has been made on the latter problem. Here's a relevant wiki http://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Unfortunately this aspect of NSS is still too broken for it to be used safely in libldap, when other apps also use NSS directly. There's still no technical advantage to using this over OpenSSL, and there's still a significant usability/app-safety disadvantage to adopting it. (GnuTLS at least offers TLS1.2 support, which neither OpenSSL or MozNSS do yet. Both OpenSSL and MozNSS have FIPS-140 validations, but FIPS mode is incompatible with the way most existing software uses these libraries, so it's kind of a moot point.) -- -- 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#5975) minor issue with slapd.conf manpage
by eric＠huss.org 24 Feb '09

24 Feb '09

Full_Name: Eric Huss Version: 2.4.15 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.81.244.185) There appears to be a couple slightly incorrect statements in the slapd.conf manpage. It says that the argsfile and pidfile values are used "if started without the debugging command line option". However, it doesn't appear to make any difference whether or not you use the -d option with slapd. This phrasing could be replaced with something that indicates if it is not specified, the file will not be created.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: >> Perhaps a better question is - how would you like it to work? > I prefer that we leave the builder with as freedom as possible. Right, that makes the most sense. >> I'm assuming there must be some way specify which crypto you want to >> build >> openldap with - is that a configure option? > > Presently there is: > --with-tls=[auto,openssl,gnutls] > > I assume we'd just add an 'nss' option to the above. However, Howard > might have other things in mind. Yes (but the option will be "moznss"). >>>> Note >>>> that both NSPR and NSS support pkg-config >>> Here would be to ensure that the proper pkg-config is in the PATH. >>> >>> Of course, pkg-config stuff gets stuff into the environment in some >>> fixed order, which does take away some freedom from the builder. I >>> guess the builder can always manually adjust the order (by providing >>> CPPFLAGS, etc., directly) and then provide a pkg_config which does >>> little. So the freedom is there, just harder to take advantage of. >> The original patch - >> ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - >> assumes the use of pkg-config - I suppose that is not sufficient. > > My only concern would be whether or not pkg-config use here is > specific to a particular 3rd party packaging of NSS versus something > available with all installs of NSS. I currently build against a copy of NSS in my Mozilla build tree. There's nothing installed with pkg-config. I would like to avoid a dependency on pkg-config. Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency as well. That's a key requirement to me personally, because otherwise it will not interoperate with Mozilla/Seamonkey, and right now that's my primary goal for this work. It's been a few months since I last looked at this and it took me a while to remember all the issues surrounding it... There are two major problems with the current MozNSS support in HEAD: 1) It does no initialization of its own. This works with Seamonkey/Thunderbird because the main app has already initialized the NSS library; libldap just uses the state that's already there. Code to initialize properly when NSS hasn't already been initialized still needs to be written. 2) It cannot shutdown safely. This is a weakness in the NSS API that was discussed at length in the Mozilla newsgroups. Unfortunately that discussion went nowhere. (The NSS_Shutdown() function tears down the library unconditionally; if there were multiple callers of the library and one of them shuts down because it's going away, all of the other callers lose the library too.) Another problem I've had in integrating is that the documentation is out of date with the code - the docs recommend certain APIs and practices that are actually deprecated in the actual code. This has led down a lot of blind alleys/dead ends that could otherwise have been avoided... > I'll be leaving the actual technical review of your patch to Howard or > other active committers. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: > Kurt Zeilenga wrote: >> >> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>>> >>>> >>>>> I'm still uncertain about how configure should detect the NSS >>>>> header >>>>> files >>>>> though; they are not in any standardized location yet AFAICS. >>>>> >>>> >>>> Like with other things, I would assume the environment to be >>>> adjusted >>>> to find the right NSS prior to running configure. >>>> >>> I'm not sure I understand what you mean by "environment to be >>> adjusted" >> >> CPPFLAGS, CFLAGS, ... and PATH environmental variables. >> >>> >>> - How does openldap detect the header files for other components? >> >> autoconf is used, which uses the compiler to check if necessary >> headers are there, with the (additional to those built into the >> compiler) header path specified via CPPFLAGS. >> >> The idea here is to give the builder the freedom over which header >> directories are searched, and the order in which they are searched. > What's the usual way that openldap does this for packages installed in > non-standard locations e.g. if I want to have my own private build of > cyrus-sasl? Is it up to the user to specify > CPPFLAGS=-I/path/to/nonstd/sasl/include and > LDFLAGS=-L/path/to/nonstd/lib ? Yes. > Does openldap configure have a > --with-sasl=/path/to/nonstd/sasl option? No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more control to the builder. > > > Perhaps a better question is - how would you like it to work? I prefer that we leave the builder with as freedom as possible. > I'm assuming there must be some way specify which crypto you want to > build > openldap with - is that a configure option? Presently there is: --with-tls=[auto,openssl,gnutls] I assume we'd just add an 'nss' option to the above. However, Howard might have other things in mind. > >> >>> Note >>> that both NSPR and NSS support pkg-config >> >> Here would be to ensure that the proper pkg-config is in the PATH. >> >> Of course, pkg-config stuff gets stuff into the environment in some >> fixed order, which does take away some freedom from the builder. I >> guess the builder can always manually adjust the order (by providing >> CPPFLAGS, etc., directly) and then provide a pkg_config which does >> little. So the freedom is there, just harder to take advantage of. > The original patch - > ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - > assumes the use of pkg-config - I suppose that is not sufficient. My only concern would be whether or not pkg-config use here is specific to a particular 3rd party packaging of NSS versus something available with all installs of NSS. I'll be leaving the actual technical review of your patch to Howard or other active committers. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt Zeilenga wrote: > > On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>> >>> >>>> I'm still uncertain about how configure should detect the NSS header >>>> files >>>> though; they are not in any standardized location yet AFAICS. >>>> >>> >>> Like with other things, I would assume the environment to be adjusted >>> to find the right NSS prior to running configure. >>> >> I'm not sure I understand what you mean by "environment to be adjusted" > > CPPFLAGS, CFLAGS, ... and PATH environmental variables. > >> >> - How does openldap detect the header files for other components? > > autoconf is used, which uses the compiler to check if necessary > headers are there, with the (additional to those built into the > compiler) header path specified via CPPFLAGS. > > The idea here is to give the builder the freedom over which header > directories are searched, and the order in which they are searched. What's the usual way that openldap does this for packages installed in non-standard locations e.g. if I want to have my own private build of cyrus-sasl? Is it up to the user to specify CPPFLAGS=-I/path/to/nonstd/sasl/include and LDFLAGS=-L/path/to/nonstd/lib ? Does openldap configure have a --with-sasl=/path/to/nonstd/sasl option? Perhaps a better question is - how would you like it to work? I'm assuming there must be some way specify which crypto you want to build openldap with - is that a configure option? > >> Note >> that both NSPR and NSS support pkg-config > > Here would be to ensure that the proper pkg-config is in the PATH. > > Of course, pkg-config stuff gets stuff into the environment in some > fixed order, which does take away some freedom from the builder. I > guess the builder can always manually adjust the order (by providing > CPPFLAGS, etc., directly) and then provide a pkg_config which does > little. So the freedom is there, just harder to take advantage of. The original patch - ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - assumes the use of pkg-config - I suppose that is not sufficient. > > -- Kurt > >

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >> >> >>> I'm still uncertain about how configure should detect the NSS header >>> files >>> though; they are not in any standardized location yet AFAICS. >>> >> >> Like with other things, I would assume the environment to be adjusted >> to find the right NSS prior to running configure. >> > I'm not sure I understand what you mean by "environment to be > adjusted" CPPFLAGS, CFLAGS, ... and PATH environmental variables. > > - How does openldap detect the header files for other components? autoconf is used, which uses the compiler to check if necessary headers are there, with the (additional to those built into the compiler) header path specified via CPPFLAGS. The idea here is to give the builder the freedom over which header directories are searched, and the order in which they are searched. > Note > that both NSPR and NSS support pkg-config Here would be to ensure that the proper pkg-config is in the PATH. Of course, pkg-config stuff gets stuff into the environment in some fixed order, which does take away some freedom from the builder. I guess the builder can always manually adjust the order (by providing CPPFLAGS, etc., directly) and then provide a pkg_config which does little. So the freedom is there, just harder to take advantage of. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > > >> I'm still uncertain about how configure should detect the NSS header >> files >> though; they are not in any standardized location yet AFAICS. >> > > Like with other things, I would assume the environment to be adjusted > to find the right NSS prior to running configure. > I'm not sure I understand what you mean by "environment to be adjusted" - How does openldap detect the header files for other components? Note that both NSPR and NSS support pkg-config > -- Kurt > > > > >

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by hyc＠symas.com 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > Wait for 2.5 to break binary compatibility. If a function is there and > is useful, people will dig it out and use it. Agreed. But we can probably fix slapd's use of ldap_int APIs. > Just like back-bdb used > (uses?) some internal Berkeley DB locking function. (Not any more...) -- -- 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