openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by quanah＠zimbra.com 24 Feb '09

24 Feb '09

--On Tuesday, February 24, 2009 11:11 AM +0100 Adrien Futschik <adrien.futschik(a)atosorigin.com> wrote: > I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine > with OpenLDAP 2.4.15. > > I guess this ITS is a "duplicate" of ITS#5955 That would seem to indicate that your various settings you pass on to configure are incorrect in some manner then, since the changes made only affect builds of OpenLDAP that would be compiled against GnuTLS, not OpenSSL. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 24 Feb '09

24 Feb '09

Le lundi 23 février 2009 09:25:39, Adrien Futschik a écrit : > The same build instructions and the same product versions are working just > fine on RHEL 5 64bits ! > > I still believe this is a bug with OpenLDAP 2.4.14. > > Adrien I confirme that it was a problem with OpenLDAP 2.4.14, it now works fine with OpenLDAP 2.4.15. I guess this ITS is a "duplicate" of ITS#5955 Best regards, Adrien

1 0

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

24 Feb '09

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. -- Kurt

1 0

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

24 Feb '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms090802080307060909050508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Any update on this? It looks as though there is some rearchitecture > work ongoing to make it easier to support openssl, gnutls, and moznss - > what's the status of this work? Would some additional resources be of > any assistance? Thanks for the offer. It was just a matter of timing, I wanted to make sure the new organization was stable before completing the moznss integration. Now that it looks like we've shaken out the loose ends, it won't take long to pull in the rest of the moznss support. I'm still uncertain about how configure should detect the NSS header files though; they are not in any standardized location yet AFAICS. -- -- 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 rmeggins＠redhat.com 24 Feb '09

24 Feb '09

This is a cryptographically signed message in MIME format. --------------ms090802080307060909050508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Any update on this? It looks as though there is some rearchitecture work ongoing to make it easier to support openssl, gnutls, and moznss - what's the status of this work? Would some additional resources be of any assistance? --------------ms090802080307060909050508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwMjIzMjM0MzM0WjAjBgkqhkiG9w0BCQQxFgQUBMDGPgsl hqwc4LZEb5iv05gl45cwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQCqaJgb/auboz1MF7Bew2dsfNNGktv0Y54aHHiZ 3AP2XhbVP73KuRsx8n1t1vL/7L8vHuPkHSS/Q2Q/bX+VTccxFG7wUMHv4KKN93rXg2kNmNSX sQClvusTS0F5CgBtNO/08YWkaL6SERP3auh19Oik2bK7S4VUt6Q732OZ3JOoLu1J5dRApPA9 zS8m+Z5w/PdAJZ5xkYwmKqeOTEJANH3L0ECon+J4o/IlzJR2HC+3HQcTNN0IaXDRnzO5CFKy B7evjPpfxw6FwZy8OysT3dMbwe0GryKjPHOv4tSEwuX8zXVnF8LBbeKGMusIIP8YDoFXIyR1 PUeSx9IgeQU6rXVFAAAAAAAA --------------ms090802080307060909050508--

1 0

Re: (ITS#5971) Debug mode "fixes" authentication issue
by ngarratt＠gmail.com 23 Feb '09

23 Feb '09

> I'll look at the bug; in the meanwhile, you may want to fix your > configuration by adding > > chase-referrals no > > overlay chain > chain-uri <the referred URI with no DN> > chain-idassert-bind <info to allow proxyauthz of users> > # ... > > See slapo-chain for details. Another option is to use > > chase-referrals no > rebind-as-user yes > Thanks Pierangelo The fact that it worked under debug mode was throwing me off. Referrals have been fixed and it's working as expected now. Neil

1 0

Re: (ITS#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 23 Feb '09

23 Feb '09

Le dimanche 22 février 2009 19:36:31, Quanah Gibson-Mount a écrit : > --On Sunday, February 22, 2009 6:56 PM +0100 Adrien Futschik > > <adrien.futschik(a)atosorigin.com> wrote: > > I have just used OpenLDAP 2.4.13, with BDB 4.7.25 & OpenSSL 0.9.8j and it > > worked fine. I used the same options. > > > > > > I guess there really is a problem with Openldap 2.4.14. > > Or, your OpenSSL build is missing required features. ;) > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration There seems to be a big change between OpenLDAP 2.4.13 and OpenLDAP 2.4.14 in the way configure script chooses OpenSSL or gnutls. They used to be only on file in OpenLDAP 2.4.13 and lower handeling tls support : tls.c in librairies/libldap directory. In OpenLDAP 2.4.14 we now have : tls2.c, tls_o.c, tls_g.c and tls_m.c I guess tls_g.c should be used when specifying --with-tls=gnutls, tls_o.c should be used when specifying --with-tls=openssl tls_m.c referes to Mozilla (note sure what option trigeres this one). tls2.c is used when ? I believe that configure doesn't care about my --with-tls=openssl option. Can anyone explain to me why ? Thanks in advance, Adrien

1 0

Re: (ITS#5970) slapd
by ando＠sys-net.it 23 Feb '09

23 Feb '09

wmoreno3(a)yahoo.com wrote: > Full_Name: William Moreno > Version: openldap-server-2.4.14_1 > OS: FreeBSD 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.221.158.199) > > > Feb 22 22:09:33 micro1 slapd[841]: @(#) $OpenLDAP: slapd 2.4.14 (Feb 22 2009 > 20:44:07) $ root@micro1.domain.com.co:/usr/ports/net/openldap24-server/work/openldap-2.4.14/servers/slapd > Feb 22 22:09:33 micro1 slapd[842]: slapd starting > Feb 23 00:53:54 micro1 slapd[842]: daemon: shutdown requested and initiated. > Feb 23 00:53:54 micro1 slapd[842]: slapd shutdown: waiting for 0 > operations/tasks to finish > Feb 23 00:53:54 micro1 slapd[842]: slapd stopped. > Feb 23 01:17:16 micro1 slapd[841]: @(#) $OpenLDAP: slapd 2.4.14 (Feb 22 2009 > 20:44:07) $ root@micro1.domain.com.co:/usr/ports/net/openldap24-server/work/openldap-2.4.14/servers/slapd > Feb 23 01:17:16 micro1 slapd[842]: slapd starting > > ..... > That's into my /var/log/debug.log after system reload... > that I see is.. when started, slapd first time, it tried to start from > "/usr/ports/net/open...etc". that's OK? I don't see any indication of a bug. That string indicates where slapd was *built*, not what executable is running. This ITS will be closed. Please direct software usage questions to the openldap-software list. 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#5971) Debug mode "fixes" authentication issue
by ando＠sys-net.it 23 Feb '09

23 Feb '09

ngarratt(a)gmail.com wrote: > I'm testing OpenLDAP 2.4.14 on Centos 5.2, used as a reverse proxy to AD. When > slapd is run with debugging disabled (or set to 0), search requests throw the > following error: > > DSID-0C090627: In order to perform this operation a successful bind must be > completed on the connection. > > When run with any other debug value, it returns the results correctly. In both > cases, the logs show a successful bind with the acl-bind user, the search finds > the correct result, and acl's show access granted to read. The only difference > is what is returned. > > If I hammer the requests through, I do occasionally get the correct answer when > using -d 0, and I also occasionally get the error with -d 1. > > http://www.nu.co.za/slapd/slapd.conf > http://www.nu.co.za/slapd/d0-ldapsearch.txt > http://www.nu.co.za/slapd/d0-slapdlog.txt > http://www.nu.co.za/slapd/d1-ldapsearch.txt > http://www.nu.co.za/slapd/d1-slapdlog.txt > > The d0 files are from slapd started with -d 0 (failing) > The d1 files are from slapd started with -d 1 (working) The problem seems to be not so repeatable. First of all, the right response is the error, since it fails while chasing referrals, and you didn't instruct it to chase referrals with authentication. Moreover, I've set up a system that mimics your setup, and the host containing the referred object is always returning the error, but the proxy is presenting it only occasionally. So the proxy's behavior looks erratic, and this is a bug, but your configuration looks broken. I'll look at the bug; in the meanwhile, you may want to fix your configuration by adding chase-referrals no overlay chain chain-uri <the referred URI with no DN> chain-idassert-bind <info to allow proxyauthz of users> # ... See slapo-chain for details. Another option is to use chase-referrals no rebind-as-user yes but I suspect it's broken and, in any case, it does not allow you to control what hosts are actually given the user's credentials, or to proxyauthz as. 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#5967) build failure with openssl : error: structure has no member named `ldo_tls_crlcheck'
by adrien.futschik＠atosorigin.com 23 Feb '09

23 Feb '09

The same build instructions and the same product versions are working just fine on RHEL 5 64bits ! I still believe this is a bug with OpenLDAP 2.4.14. Adrien

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs