openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by quanah＠zimbra.com 21 Oct '11

21 Oct '11

--On Friday, October 21, 2011 6:34 PM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> There's no evidence of an OpenLDAP bug here. All we can see from the >> testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to >> complete, which was long enough for the initial startup check to time >> out. You need to check your system to see why SASL took so long to >> initialize, most likely a DNS failure or some other transient issue. > > Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on > GSSAPI in another test. I will retry with cyrus-sasl package shipped with > openSUSE 11.4. There was a patch posted to the cyrus-sasl list the other day for issues with the gssapi plugin in 2.1.25. It's working fine for me once it is fixed up. quanah@zre-ldap001:~/p4/main/ThirdParty/cyrus-sasl/patches$ cat gssapi.patch --- cyrus-sasl-2.1.25/plugins/gssapi.c.orig 2011-10-07 14:47:07.461866240 -0700 +++ cyrus-sasl-2.1.25/plugins/gssapi.c 2011-10-07 14:47:45.891872589 -0700 @@ -370,7 +370,7 @@ } if (output_token->value && output) { - unsigned char * p = (unsigned char *) text->encode_buf; + unsigned char * p; ret = _plug_buf_alloc(text->utils, &(text->encode_buf), @@ -384,6 +384,8 @@ return ret; } + p = (unsigned char *) text->encode_buf; + p[0] = (output_token->length>>24) & 0xFF; p[1] = (output_token->length>>16) & 0xFF; p[2] = (output_token->length>>8) & 0xFF; --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

hyc(a)symas.com wrote: > There's no evidence of an OpenLDAP bug here. All we can see from the > testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, > which was long enough for the initial startup check to time out. You need to > check your system to see why SASL took so long to initialize, most likely a > DNS failure or some other transient issue. Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on GSSAPI in another test. I will retry with cyrus-sasl package shipped with openSUSE 11.4. Ciao, Michael.

1 0

Re: (ITS#7069) test061-syncreplication-initiation failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.45.214) > > >>>>>> test061-syncreplication-initiation failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 Not enough info in your testrun directory, what was the output from the script up this point? From reading the slapd.?.log files, it also looks like something in your environment is slowing down the SASL init here, enough to make the script timeout. On all of my tests here the timestamp for slap_sasl_init is always identical to the preceding timestamp, i.e., slap_sasl_init should never even take as long as 1 second. Fix your environment before submitting any more bug reports. -- -- 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#7070) test058-syncrepl-asymmetric failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git master) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.51.243) > > >>>>>> Starting test058-syncrepl-asymmetric for hdb... > running defines.sh > Initializing master configurations... > Initializing search configurations... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Waiting 1 seconds for slapd to start... > Waiting 2 seconds for slapd to start... > Waiting 3 seconds for slapd to start... > Waiting 4 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ldapsearch failed (255)! >>>>>> test058-syncrepl-asymmetric failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 There's no evidence of an OpenLDAP bug here. All we can see from the testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, which was long enough for the initial startup check to time out. You need to check your system to see why SASL took so long to initialize, most likely a DNS failure or some other transient issue. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

See testrun/ here: http://www.stroeder.com/temp/openldap-its7070-testrun.tar.gz

1 0

(ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

Full_Name: Michael Ströder Version: HEAD (from git master) OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.51.243) >>>>> Starting test058-syncrepl-asymmetric for hdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Waiting 1 seconds for slapd to start... Waiting 2 seconds for slapd to start... Waiting 3 seconds for slapd to start... Waiting 4 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! >>>>> test058-syncrepl-asymmetric failed for hdb (exit 255) make[2]: *** [hdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#7067) openldap not properly starting
by Pierangelo Masarati 21 Oct '11

21 Oct '11

Current release is OpenLDAP 2.4.26. In any case, there is no clear indication in your report of a software bug. Please direct your message to the openldap-technical mailing list. p.

1 0

(ITS#7069)
by michael＠stroeder.com 21 Oct '11

21 Oct '11

See testrun/ here: http://www.stroeder.com/temp/openldap-its7069-testrun.tar.gz

1 0

(ITS#7069) test061-syncreplication-initiation failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

Full_Name: Michael Ströder Version: HEAD (from git) OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.45.214) >>>>> test061-syncreplication-initiation failed for hdb (exit 255) make[2]: *** [hdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by pm＠datasphere.ch 20 Oct '11

20 Oct '11

--=-H9Xw5XBDhIDPupeYRJLz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am the author of the patch at: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o= f-tls-options.patch and I want to argue in favor of it: 1) In a configuration using a simple bind to authenticate a client, you have no choice but using ldaps to protect password sniffing: this requires a SERVER certificate only. 2) Since primary and replicated servers can have their role reversed (i.e.: after failure and/or recovery of the former primary server), the configurations should be kept as symmetric as possible (except for syncrepl) in order to speed-up switch: SSL in both servers should thus have the same configuration. 3) syncrepl then forces SSL to use a client certificate rather than a simple bind for authentication: this implies "normal" clients will also need a certificate... we are then in a situation lying very far from using ldaps for encryption only :-( 4) Using separate server and client certificates within a server, although safer, does not resolve my problem. For the above reason, I would really like to see my patch included in openldap code, or at least an equivalent solution. Because "third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches.", do you need me to re-submit it ? Thanks in advance for your reply. Regards, Patrick Monnerat DATASPHERE S.A. 16, chemin des Aulx CH-1228 Plan-les-Ouates (GE) --=-H9Xw5XBDhIDPupeYRJLz Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH/DCCA9Mw ggK7oAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaIxCzAJBgNVBAYTAkNIMQ8wDQYDVQQIEwZHZW5l dmExGDAWBgNVBAcTD1BsYW4tbGVzLU91YXRlczEYMBYGA1UEChMPREFUQVNQSEVSRSBTLkEuMSQw IgYDVQQDExtEQVRBU1BIRVJFIG1haWwgc2VjdXJpdHkgQ0ExKDAmBgkqhkiG9w0BCQEWGWJ1cmVh dXRpcXVlQGRhdGFzcGhlcmUuY2gwHhcNMTEwODIzMTM1MzAwWhcNMTIxMjMxMjM1OTAwWjCBvDEL MAkGA1UEBhMCQ0gxDzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3VhdGVzMRcw FQYDVQQKEw5EQVRBU1BIRVJFIFMuQTEZMBcGA1UEAxMQUGF0cmljayBNb25uZXJhdDEtMCsGCSqG SIb3DQEJARYecGF0cmljay5tb25uZXJhdEBkYXRhc3BoZXJlLmNoMR8wHQYJKoZIhvcNAQkBFhBw bUBkYXRhc3BoZXJlLmNoMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzpT/ufabbhCa1JFvX ZWLCDP8tPBxTilXjEFKAnNirdOc8Sj667iey7ypcgkA2QUZu+gHDSVD3iNRro2rQPdTzjnLCml5P Up+AOB48X5jUwVbxihmAvtM21KQGZZwcmGdlj6AgY/Vxci48CRn+DzW6lY+VYCtf7HWhNHih4G1Y IwIDAQABo3wwejAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR79vf/tmNLu8XwC0nU02j0WQLCzjAL BgNVHQ8EBAMCA7gwKwYDVR0lBCQwIgYIKwYBBQUHAwQGCisGAQQBgjcCARUGCisGAQQBgjcCARYw EQYJYIZIAYb4QgEBBAQDAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQA8gckFW7PMcfcFhZoVkI1ePP2f XQ1UM4tChxfuPmKYXb2VbM2bYn33MiKnswlzsH/gDvQawYFKvRCehE5JiPUa42kGd8jXNzU8sRnm uMHpjengOO3aLKZLAZRXS1dGjD9q3CQa/KDT31+ODWG7vztY8ZMBv008lb/eJvKt9ssm0cPTeKA9 /YenJzklzyY/MlNnW+zRce+3Ms4171wnrjKcA4J+Zyr0Ow1eEYzoIVEphT1WmybDPr0EJoueDUvH 9uz5cxRpxlIFY4jgTqhUQid/7uHrkaKU/OrADsOy2sGr4YpcvRpHseZZIA3Z8ovOHQ9J4WGviz9w Z6gcTLtQu6baMIIEITCCAwmgAwIBAgIBEzANBgkqhkiG9w0BAQUFADCBsDELMAkGA1UEBhMCQ0gx DzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3VhdGVzMRgwFgYDVQQKEw9EQVRB U1BIRVJFIFMuQS4xMjAwBgNVBAMTKURBVEFTUEhFUkUgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAyMSgwJgYJKoZIhvcNAQkBFhlidXJlYXV0aXF1ZUBkYXRhc3BoZXJlLmNoMB4XDTExMDgy MzEzNTEwMFoXDTMwMTIzMTIzNTkwMFowgaIxCzAJBgNVBAYTAkNIMQ8wDQYDVQQIEwZHZW5ldmEx GDAWBgNVBAcTD1BsYW4tbGVzLU91YXRlczEYMBYGA1UEChMPREFUQVNQSEVSRSBTLkEuMSQwIgYD VQQDExtEQVRBU1BIRVJFIG1haWwgc2VjdXJpdHkgQ0ExKDAmBgkqhkiG9w0BCQEWGWJ1cmVhdXRp cXVlQGRhdGFzcGhlcmUuY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTbQAxPu9L skt5ddMLzbS+bLQlW+gtcecHp9zL+x44dSXc663y6s+/XWxDbLZ0s+w6vp5CMB6pXxR5s8KfMDSC 22s7nq0t/BpQ1WfLkszG2JRs8BXIyrsDrFqYBBxcxiyyjzyQYVJg7qtPveUw9aQs53QCnZfXwG9s H2crPnAzoOzx5jptWvA5aHLMKqaZbGztUANABqZfZEwwGS/YG3nHxOKnl+UvmueJWiMs+plendlA 5+UBrUAk46/1IFNyjMqaBR8bug7IovHB9sn/k999eHVeBiu1qeTo0tcDEMvSBTh5JqIkl5lH7TU+ wgVCBA2/Eo1ccrvFkgTmztocbMczAgMBAAGjUjBQMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE FFxbVp/ZdU5YlwvAFPbbFg+jGWehMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAAcwDQYJ KoZIhvcNAQEFBQADggEBAH6oFynXqL8Tk6sA032VbJyibS8woHni0/ayhrcBdEORc/wvfmhEA2kK 9Yy4xEaprsxT0fFyBJ4YGYyXX4SkQdr0pRCDO/niL2woQmar5vq4v9xa2FgrWOh7jKcXuh/SMpGq WZzQQTvYY0+X7SXX1+Ioje7rqzEDWNmzpp+mtPr/ENVmIxwTGEtXbDDLJN48sTmBDnKrca2UJrfU EFDDHon9CBBg53u+JodQiJfSbraqwje1QrGCvOHkyBr3ulBmssePVQzPphON39pPgbJCoE7sd/WK UX02QIorkbdaA8K/S38Ggc1xN9kNDE5tuClAYJSZUHeDnROgz1QncevRdKMxggGuMIIBqgIBATCB qDCBojELMAkGA1UEBhMCQ0gxDzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3Vh dGVzMRgwFgYDVQQKEw9EQVRBU1BIRVJFIFMuQS4xJDAiBgNVBAMTG0RBVEFTUEhFUkUgbWFpbCBz ZWN1cml0eSBDQTEoMCYGCSqGSIb3DQEJARYZYnVyZWF1dGlxdWVAZGF0YXNwaGVyZS5jaAIBFDAJ BgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEx MDIwMTYxMjEwWjAjBgkqhkiG9w0BCQQxFgQU/0S6iq+obCv1FnngaSJRbdoGRygwDQYJKoZIhvcN AQEBBQAEgYBXOHzJGvDyRJTXk7jxmGjef5QY39Ziyodp0BIYwRukyAgQ273nzPxBga96lZog7obN 2qsnWxGi9RtGEyua27OacgUPOb9+vjX5/xb3DGol81GnBqOusj8ZrdNTa7i7lKmA+o7cFD3hM6o0 PLi3EqA3rsEgu65uGpWuuyS8rzeRFAAAAAAAAA== --=-H9Xw5XBDhIDPupeYRJLz--

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