openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7164) Prevent change of TLS setting if invalid (Dynamic Config)
by nick＠eurobjects.com 13 Feb '12

13 Feb '12

Full_Name: Nikolaos Milas Version: 2.4.28 OS: CentOS 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.22.12) If, in a working OpenLDAP installation with dynamic configuration, we inadvertently change the value of: olcTLSCertificateKeyFile: /path/to/key.pem to some invalid value, like: olcTLSCertificateKeyFile: /path/to/non/existing/key.pem then OpenLDAP Server continues to work (and we see no error message whatsoever), but if it is stopped, it refuses to restart. In the logs, while OpenLDAP is starting, we see: Feb 11 16:20:44 vdev slapd[15272]: main: TLS init def ctx failed: -1 and then service is immediately stopped. OpenLDAP Server should check whether the new parameter value points to an existing file, and, if not, it should refuse to change the attribute value. For a more complete procedure, it could also check whether the indicated file includes a valid certificate, suitable for this parameter, and, again, if not, it should refuse to change the attribute value. Also, in case it's possible that one of the TLS File parameters gets an invalid value (e.g. through slapadd), then a meaningful message during startup failure would be helpful, e.g.: "olcTLSCertificateKeyFile: File /path/to/key.pem not found or contains invalid certificate."

1 0

Re: (ITS#7162)
by hyc＠symas.com 12 Feb '12

12 Feb '12

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> FWIW: >>> With back-mdb I ran 64 iterations without this error. >>> Testing with back-bdb and back-hdb the failure occurs on my system after max. >>> 10 iterations. >> >> This sounds like it may be related to the issue I've been chasing down with >> ITS#7052. It appears that this bug was caused by the patch for ITS#6024. I'm >> about to revert that patch in master. Please re-test with d4b3c2af ... >> > Hm, no, that patch seemed to have no bearing here. But reverting ba4366eae > appears to clear things up. Now I just need to re-read test054 to see if this > is really what we want. > Just to sum up - this bug was a regression caused by ba4366eae. That patch was written in an attempt to resolve other bugs related to ITS#7052. But the actual cause of the remaining ITS#7052 issues was the ITS#6024 patch. Both of these patches have been reverted in git master. -- -- 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#7162)
by hyc＠symas.com 12 Feb '12

12 Feb '12

Howard Chu wrote: > michael(a)stroeder.com wrote: >> FWIW: >> With back-mdb I ran 64 iterations without this error. >> Testing with back-bdb and back-hdb the failure occurs on my system after max. >> 10 iterations. > > This sounds like it may be related to the issue I've been chasing down with > ITS#7052. It appears that this bug was caused by the patch for ITS#6024. I'm > about to revert that patch in master. Please re-test with d4b3c2af ... > Hm, no, that patch seemed to have no bearing here. But reverting ba4366eae appears to clear things up. Now I just need to re-read test054 to see if this is really what we want. -- -- 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#6024
by hyc＠symas.com 12 Feb '12

12 Feb '12

This patch has been partially reverted in master. The cookies are required for MMR loop detection. If it's confusing you when you analyze logs, too bad. Don't make "cosmetic" changes to working code. -- -- 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#7162)
by hyc＠symas.com 12 Feb '12

12 Feb '12

michael(a)stroeder.com wrote: > FWIW: > With back-mdb I ran 64 iterations without this error. > Testing with back-bdb and back-hdb the failure occurs on my system after max. > 10 iterations. This sounds like it may be related to the issue I've been chasing down with ITS#7052. It appears that this bug was caused by the patch for ITS#6024. I'm about to revert that patch in master. Please re-test with d4b3c2af ... -- -- 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#7162)
by michael＠stroeder.com 12 Feb '12

12 Feb '12

FWIW: With back-mdb I ran 64 iterations without this error. Testing with back-bdb and back-hdb the failure occurs on my system after max. 10 iterations.

1 0

(ITS#7162)
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Same problem with master branch 8e7af6331ec2d0edaeb203b1c52d4016bc2bbcbf

1 0

Re: (ITS#7163) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Uuumpf! Please close this dup of ITS#7162 caused by browser reload.

1 0

Re: (ITS#7162) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

See also: http://www.stroeder.com/temp/openldap-its-7162-testrun.tar.gz

1 0

(ITS#7163) ./scripts/test054-syncreplication-parallel-load: test failed - provider and consumer databases differ
by michael＠stroeder.com 12 Feb '12

12 Feb '12

Full_Name: Version: RE24 git 80b64f93e85f8e8705cb154d2a1630672b8fb30d OS: openSUSE 11.4 x86_64 URL: Submission from: (NULL) (84.163.58.63) test054 fails occassionally with latest RE24 git 80b64f93e85f8e8705cb154d2a1630672b8fb30d: $ ./run -l 100 -b bdb test054 Cleaning up test run directory leftover from previous run. Running ./scripts/test054-syncreplication-parallel-load for bdb... Running 1 of 100 iterations running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify provider directory... Using ldappasswd to change some passwords... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the provider... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Trying to change some passwords on the consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ Failed after 1 of 100 iterations

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