openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#6167) back-ldap: TLS: uri list broken
by christian.fischer＠fischundfischer.com 09 Jun '09

09 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) back-ldap hangs on ldap_back_bind() while starting TLS if the first mirror in uri list is down ldap_pvt_thread_mutex_lock() in back-ldap/bind.c:1584 never returns and slapd hangs reproducible: always steps to reproduce: - configure a uri list with two mirrors, the first one offline, start TLS database ldap suffix "dc=foo,dc=bar" uri "ldap://mirror01.foo.bar ldap://mirror02.foo.bar" tls start tls_reqcert=never

1 0

(ITS#6166) Overlay/backend restructuring
by h.b.furuseth＠usit.uio.no 09 Jun '09

09 Jun '09

Full_Name: Hallvard B Furuseth Version: RE25/RE30 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some wishes/loose thoughts about overlay/backend code: * Remove backends internally, making them like overlays? (RE30) * Reduce copying of overlay data -op->o_bd->bd_info (RE25?) * Lose slap_overinst, move its members into BackendInfo. <hbf> Could we reduce complexity if there internally were no (programmable) backends, only overlays? Backends would be thinly disguised overlays. Maybe over a single fixed "core overlay" which intercepts all calls, or the opposite - a fixed empty backend. <hbf> .what do overlays cost compared to backends? Must reduce copying, but that seems already to be the plan. And slapd must repair some data structures which overlays are not required to clean up - must that stay? Am I talking sense at all? <hyc> eh, not sure what you're really talking about. turn all backends into overlays, to keep the API completely uniform? <hbf> yes. and return values the same way - SLAP_CB_CONTINUE when they don't know what to do, for example. <hbf> there seems to be code snippets around doing similar things for backends and overlays, and they mostly share the same data structure. so i wondered if the backend stuff could simply go away. <hyc> so we'd still need special cases in the frontend to handle SLAP_CB_CONTINUE falling out at the end <hyc> ideally, sure. <hyc> that seems like more of a 3.0 move than a 2.5 <hbf> yes, i suppose so <hbf> and it depends on overlays being as fast as backends <hyc> fast at what? <hyc> there's no measurable overhead for overlays on top of backends <hbf> handling a request. slapd does all this copying of overlay structures that I haven't even tried to figure out, I assume that costs time compared to a backend. <hyc> well, a lot of that copying can go away if we just rationalize the on_info stuff <hyc> I already mentioned that on -devel a while back <hyc> op->o_bd->bd_info <hyc> if we referenced those pointers from op instead of op->o_bd we'd need no copying at all <hyc> but i think that would require changes to a lot of existing backend code. <hyc> the copying approach was taken to allow overlays to be slotted in without modifying any backend code <hbf> oh well, we've more pressing problems in that case <hyc> actually come to think of it most backends don't care as it is. at this point it's the overlays and bconfig that would need to be changed <hyc> I guess we should have made that change sooner rather than later, as now the number of overlays is quite large :P <hyc> hindsight, oh well. <hyc> I wouldn't be opposed to attempting that change for 2.5. sooner is obviously better now. <hbf> related loose thought: overlays could lose all those (slap_overinst *)op->o_bd->bd_info casts if the slap_overinst members were inserted in BackendInfo and slap_overinst became an obsolete wrapper about just BackendInfo. Costs ~24 bytes/backend. <hyc> ok <hyc> that sounds smart

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 09 Jun '09

09 Jun '09

rein(a)OpenLDAP.org wrote: > michael(a)stroeder.com wrote: > >> Found 6 errors >>>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) > > Do you have the entire output from the test script? You mean the console output? Unfortunately not. As said I've generated a tar.gz of the whole testrun/ directory though: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz > [..] without it I'm tempted to assume it > failed due to some timing glitch within the test script itself.. Hmm, how to find out? Ciao, Michael.

1 0

(ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠OpenLDAP.org 09 Jun '09

09 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The slapmodify function already exists, but we've never built a tool around it. It would be useful to be able to have a utility that validates commands that users can use to modify cn=config while slapd is offline, rather than resorting to text editors that don't do validation of the changes being made.

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by rein＠OpenLDAP.org 08 Jun '09

08 Jun '09

michael(a)stroeder.com wrote: > Found 6 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) Do you have the entire output from the test script? It is required to tell what actually went wrong, and without it I'm tempted to assume it failed due to some timing glitch within the test script itself.. Rein

1 0

(ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 08 Jun '09

08 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard send_ldap_ber() has a suspicious-looking waitloop doing this: if ( ldap_pvt_thread_mutex_trylock( &conn->c_mutex )) { ldap_pvt_thread_mutex_unlock( &conn->c_write1_mutex ); ldap_pvt_thread_mutex_lock( &conn->c_write1_mutex ); Unlock does not mean a thread waiting for c_write1_mutex will acquire it immediately. Such a thread may have to wait until it is scheduled, at which time the looping thread has locked the mutex again. On the Linux box on my desk, a pure unlock-lock loop goes through 50000-100000 iterations before another thread waiting for the lock acquires it. OTOH, on a heavily used box it takes ~50 iterations. A sched_yield() between the unlock and lock reduces #iterations to 1. No idea if that is the right solution, nor how serious the problem is. The lock/unlock statements themselves are from result.c rev 1.323, but then with some more locking between them which disappeared in later revisions. My lock-unlock test program: #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <sys/select.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static unsigned count; static void *waiter(void *arg) { pthread_mutex_lock(&m); printf("Locked after %u iterations.\n", count); exit(0); } int main() { pthread_t t; pthread_mutex_lock(&m); pthread_create(&t, NULL, waiter, NULL); select(0, NULL, NULL, NULL, &(struct timeval){0, 100000}); for (count = 1 ;; ++count) { pthread_mutex_unlock(&m); pthread_mutex_lock(&m); } }

1 0

(ITS#6163) back-sql DoS when searching for empty attr
by karavelov＠spnet.net 08 Jun '09

08 Jun '09

Full_Name: Luben Karavelov Version: 2.4.11-15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.83.96.32) We use ldap for some user accounts authentication here and we have found that queries of this kind : ldapsearch -b "dc=users,dc=example,dc=com" "(&(objectClass=posixAccount)(uid=))" kill slapd. It exits on assert( 0 ) at line 1366 of back-sql/search.c It is even nastier because it could be remotely triggered with ssh -l "" server-with-ldap-accounts-in-nss.example.com or through ftp using the same technique.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 08 Jun '09

08 Jun '09

Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ciao, Michael.

1 0

(ITS#6162) hexadecimal log levels are not recognized in configuration
by jonathan＠phillipoux.net 08 Jun '09

08 Jun '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-bconfig-20090608.patch Submission from: (NULL) (80.65.230.146) The slapd-config(5) and slapd.conf(5) man pages state: olcLogLevel: <integer> [...] The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation [...] as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, This is not the case. Integers and names (strings) are accepted, but hex notation is refused, with, from slapd.conf: /opt/openldap-RE24/etc/openldap/slapd.conf: line 10: <loglevel> unable to parse level "0x40" And using ldapmodify on cn=config: ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcLogLevel> unable to parse level Hexadecimal values are, however, accepted as arguments to the -d argument to slapd on the command line. The above patch fixes bconfig.c to accept hex values. On a side note, according to man strtol(3), this also means that loglevels can be typed in octal, for the more masochist among us :)

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Download content of directory testrun/ here: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz I cannot reproduce this within directory tests/. It usually ends with this message: ERROR: Entry not removed on central search! Race error found after 1 of 10 iterations Found 3 errors >>>>>> Exiting with a false success status for now

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