- openldap-bugs - openldap.org

(ITS#6623) segmentation fault
by nareshyathapu＠gmail.com 16 Aug '10

16 Aug '10

Full_Name: Naresh Reddy Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.166.63.98) Trying to connect to ldapserver and ldap server is down. Core dump is happening below is the code and gdb.. Code ------- u32_t rc=ldap_sasl_bind(ld, loginDN, LDAP_SASL_SIMPLE, &cred, NULL, NULL, &msgid); //asynchronous bind if (rc != LDAP_SUCCESS ) { ldapErrorLog(":connect: LDAP Bind send Failed:%s \n ", ldap_err2string(rc)); ldap_unbind_ext_s(ld, NULL,NULL); m_connInitialized = false; return(LDAPRC_FAIL); } GDB ----- warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4 Core was generated by `/usr/UMR/current/bin/ldapMgr --start=cold'. Program terminated with signal 11, Segmentation fault. #0 0x43b91cc9 in free () from /lib/libc.so.6 (gdb) bt #0 0x43b91cc9 in free () from /lib/libc.so.6 #1 0x080a6854 in ldap_free_select_info (sip=0x118) at os-ip.c:936 #2 0x080a29ab in ldap_ld_free (ld=0xf3ebec20, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:131 #3 0x080a2aab in ldap_unbind_ext (ld=0xf3ebec20, sctrls=0x0, cctrls=0x0) at unbind.c:52 #4 0x0808368f in LdapConnection::connect (this=0xd252888, loginDN=0xd258ddc "bwLoginname=sms_ldap_bind", pwd=0xd258edd "metropcs_sms") at LdapConnection.cpp:159 #5 0x08051731 in LdapPeer::LdapWorkerProcess (this=0xd2586b0) at LdapPeer.cpp:322 #6 0x080827b2 in run (handle=0xd2586b0) at LdapCommonDefs.cpp:47 #7 0x43c5be49 in ?? () from /lib/libpthread.so.0

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 13 Aug '10

13 Aug '10

Doug Leavitt wrote: > I have been testing pretty consistently on Solaris this year, > most recent on HEAD versus RELEASE. thats how I noticed > the ITS 6621 issue. > > I may be able to do some specific testing on specific hardware > platforms, depending on what is desired, and what I can get > access to. I do regulary test on both x86 and sparc platforms. > > Also, I now have Oracle legal permission to pass OpenLDAP > enhancements and fixes upstream. > > I am almost ready to submit a proposed patch to libldap to deliver > a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt > functionality for OpenLDAP libldap. > > My proposed patch so far implements the ldap_dup and > ldap_destroy portions of the specification, but I have not > yet implemented the LDAP_OPT_SESSION_REFCNT or > added any LDAP_API_FEATURE* style macros. > > I would like some guidance if/what macros in ldap.h are desired. > > I am working on the assumption that some public discussion > and peer review will be expected before any patch submission > would be accepted. > > Should I start with a discussion on openldap-technical first? Other? Sounds very interesting; discussions of this nature (modifications to OpenLDAP code) are most appropriate for the -devel list. Looking forward to continuing this conversation there. > > Doug. > > > > On 08/12/10 06:21 PM, hyc(a)symas.com wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? >> > -- -- 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#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 13 Aug '10

13 Aug '10

I have been testing pretty consistently on Solaris this year, most recent on HEAD versus RELEASE. thats how I noticed the ITS 6621 issue. I may be able to do some specific testing on specific hardware platforms, depending on what is desired, and what I can get access to. I do regulary test on both x86 and sparc platforms. Also, I now have Oracle legal permission to pass OpenLDAP enhancements and fixes upstream. I am almost ready to submit a proposed patch to libldap to deliver a revised version of draft-zeilenga-ldap-c-api-concurrency-00.txt functionality for OpenLDAP libldap. My proposed patch so far implements the ldap_dup and ldap_destroy portions of the specification, but I have not yet implemented the LDAP_OPT_SESSION_REFCNT or added any LDAP_API_FEATURE* style macros. I would like some guidance if/what macros in ldap.h are desired. I am working on the assumption that some public discussion and peer review will be expected before any patch submission would be accepted. Should I start with a discussion on openldap-technical first? Other? Doug. On 08/12/10 06:21 PM, hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? >

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 13 Aug '10

13 Aug '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> Blind-fixed in HEAD. Thanks, p. >> >> By the way Ando, any more ideas about the devpoll implementation? Have you >> tested it against select on Solaris recently? > > I haven't had access to Solaris in years... p. Me neither. Too bad, a Niagara might actually show more than a 1% gain from the multi-listener patch. -- -- 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 13 Aug '10

13 Aug '10

> masarati(a)aero.polimi.it wrote: >> Blind-fixed in HEAD. Thanks, p. > > By the way Ando, any more ideas about the devpoll implementation? Have you > tested it against select on Solaris recently? I haven't had access to Solaris in years... p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 13 Aug '10

13 Aug '10

masarati(a)aero.polimi.it wrote: > Blind-fixed in HEAD. Thanks, p. By the way Ando, any more ideas about the devpoll implementation? Have you tested it against select on Solaris recently? -- -- 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#6621) Compile time error in daemon.c 1.446
by masarati＠aero.polimi.it 13 Aug '10

13 Aug '10

Blind-fixed in HEAD. Thanks, p.

1 0

Re: (ITS#6621) Compile time error in daemon.c 1.446
by hyc＠symas.com 13 Aug '10

13 Aug '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Doug Leavitt > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) > > > Two syntax errors were introduced into daemon.c as a result of: > the commits to change daemon.c 1.444 -> 1.445 -> 1.446 > > > Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. > > > --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 > +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 > @@ -521,7 +521,7 @@ > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > int i; \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > for ( i=0; i<readfds.fd_count; i++) { \ > int fd = slapd_sock2fd(readfds.fd_array[i]); \ > @@ -666,7 +666,7 @@ > # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd),&writefds) > > # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ > - *(nsp) = select( SLAP_EVENT_MAX,&readfds, \ > + *(nsp) = select( SLAP_EVENT_MAX(t),&readfds, \ > nwriters> 0 ?&writefds : NULL, NULL, (tvp) ); \ > } while (0) > # endif /* !HAVE_WINSOCK */ > > Nice catch, thanks. -- -- 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#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1000000000 with a parent of > 9999999999 (and > a row 9999999999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1410065407 = 32-bit rollover of 9999999999). A (blind) fix is in HEAD; you need to pull modifications related to this ITS and to ITS#6622. Please test and report. p.

1 0

(ITS#6622) Add support for [unsigned] long long parsing
by masarati＠aero.polimi.it 12 Aug '10

12 Aug '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando A patch that adds support for parsing long long and unsigned long long is coming.

1 0

(ITS#6621) Compile time error in daemon.c 1.446
by doug.leavitt＠oracle.com 12 Aug '10

12 Aug '10

Full_Name: Doug Leavitt Version: HEAD OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) Two syntax errors were introduced into daemon.c as a result of: the commits to change daemon.c 1.444 -> 1.445 -> 1.446 Specifically two calls to SLAP_EVENT_MAX are missing the new (t) argument. --- a/servers/slapd/daemon.c Thu Aug 12 10:55:06 2010 -0500 +++ b/servers/slapd/daemon.c Thu Aug 12 15:19:02 2010 -0500 @@ -521,7 +521,7 @@ # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ int i; \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ for ( i=0; i<readfds.fd_count; i++) { \ int fd = slapd_sock2fd(readfds.fd_array[i]); \ @@ -666,7 +666,7 @@ # define SLAP_EVENT_CLR_WRITE(fd) FD_CLR((fd), &writefds) # define SLAP_EVENT_WAIT(t, tvp, nsp) do { \ - *(nsp) = select( SLAP_EVENT_MAX, &readfds, \ + *(nsp) = select( SLAP_EVENT_MAX(t), &readfds, \ nwriters > 0 ? &writefds : NULL, NULL, (tvp) ); \ } while (0) # endif /* !HAVE_WINSOCK */

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

>> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >> >> >> Hello, >> >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. > > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", while it > is a request to shutdown a connection between client and server. As such, > it should be honored also when the connection is bound as the rootdn. Also, unbind operations are not supposed to return any response (see RFC4511 for details; note that no unbind response tag is defined). p.

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by Kurt＠OpenLDAP.org 11 Aug '10

11 Aug '10

On Aug 11, 2010, at 8:29 AM, masarati(a)aero.polimi.it wrote: >> Full_Name: Gareth Palmer >> Version: CVS HEAD >> OS: Ubuntu 9.04 >> URL: >> = http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch >> Submission from: (NULL) (202.21.137.14) >>=20 >>=20 >> Hello, >>=20 >> This patch adds support for passing through unbind requests to the >> underlying >> module when using the perl backend. >=20 > In this patch, the unbind operation is bypassed if requested by the > rootdn. You seem to consider "unbind" as the opposite of "bind", = while it > is a request to shutdown a connection between client and server. As = such, > it should be honored also when the connection is bound as the rootdn. More to the point, backends should not be dependent on close (nor open) = connection events. Hence this patch ought to be rejected. -- Kurt=

1 0

Re: (ITS#6618) Add support for unbind requests in perl backend
by masarati＠aero.polimi.it 11 Aug '10

11 Aug '10

> Full_Name: Gareth Palmer > Version: CVS HEAD > OS: Ubuntu 9.04 > URL: > http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch > Submission from: (NULL) (202.21.137.14) > > > Hello, > > This patch adds support for passing through unbind requests to the > underlying > module when using the perl backend. In this patch, the unbind operation is bypassed if requested by the rootdn. You seem to consider "unbind" as the opposite of "bind", while it is a request to shutdown a connection between client and server. As such, it should be honored also when the connection is bound as the rootdn. p.

1 0

(ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 11 Aug '10

11 Aug '10

Full_Name: Martin Evans Version: 2.4.20 OS: CentOS 5.X URL: Submission from: (NULL) (138.37.8.59) I've attached a proposed patch to fix an error that sometimes occurs when attempting to delete a userPassword attribute from an entry whilst the ppolicy overlay is active. The OL 2.4.20 code seems to assume that this operational attribute always exists (but it clearly cannot always exist otherwise the error would not occur). I think it can be reproduced by adding a fresh entry that contains a userPassword. Then simply deleting the userPassword fails resulting in: ldap_modify: No such attribute (16) additional info: modify/delete: pwdChangedTime: no such attribute Further experiments show that if the userPassword is modified before then deleted the error does not occur (presumably because something else sets pwdChangedTime on a mod operation but not when the attribute is added in an entire new entry). I've modified our OL 2.4.20 test systems with the patch below and the problem goes away: Cheerio! Martin. -bash-3.2# diff -u servers/slapd/overlays/ppolicy.c.0 servers/slapd/overlays/ppolicy.c --- servers/slapd/overlays/ppolicy.c.0 2009-08-26 00:07:41.000000000 +0100 +++ servers/slapd/overlays/ppolicy.c 2010-08-11 14:28:53.000000000 +0100 @@ -1880,22 +1880,31 @@ slap_timestamp( &now, &timestamp ); mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 ); - mods->sml_desc = ad_pwdChangedTime; + + /* MDTE PATCH 20100811: modify to not do delete non existing pwdChangedTime */ if (pwmop != LDAP_MOD_DELETE) { + mods->sml_desc = ad_pwdChangedTime; mods->sml_op = LDAP_MOD_REPLACE; mods->sml_numvals = 1; mods->sml_values = (BerVarray) ch_malloc( 2 * sizeof( struct berval ) ); ber_dupbv( &mods->sml_values[0], &timestamp ); BER_BVZERO( &mods->sml_values[1] ); assert( !BER_BVISNULL( &mods->sml_values[0] ) ); - + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; } else { - mods->sml_op = LDAP_MOD_DELETE; + if (attr_find(e->e_attrs, ad_pwdChangedTime )) { + mods->sml_desc = ad_pwdChangedTime; + mods->sml_op = LDAP_MOD_DELETE; + mods->sml_flags = SLAP_MOD_INTERNAL; + mods->sml_next = NULL; + modtail->sml_next = mods; + modtail = mods; + } } - mods->sml_flags = SLAP_MOD_INTERNAL; - mods->sml_next = NULL; - modtail->sml_next = mods; - modtail = mods; + /* END OF MDTE PATCH */ if (attr_find(e->e_attrs, ad_pwdGraceUseTime )) { mods = (Modifications *) ch_calloc( sizeof( Modifications ), 1 );

1 0

(ITS#6619) CSN too old
by heinz.hoelzl＠gvcc.net 11 Aug '10

11 Aug '10

Full_Name: Heinz Hölzl Version: 2.4.23 OS: Linux Ubuntu Hardy LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.18.132.37) If i sync a part of my DIT with syncrepl, the first sync works fine. Then if i modify some objects on the provider, on the consumer appears: "do_syncrep2: rid=105 CSN too old, ignoring 20100811125159.871757Z#000000#001#000000" If i sync the hole DIT all works fine. If i use openldap 2.4.19 for syncing only a part of the DIT all works fine too. The version of the provider is 2.4.23 too. slapd.conf on the provider: ...snip.... database ldap lastmod on suffix "dc=krb" rootdn "cn=admin,dc=krb" uri "ldaps://lbackend.s2.dc.gvcc.net:10636" readonly on ...snip... slapd.conf on the consumer: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/sgv.schema include /etc/openldap/schema/mozillaOrgPerson.schema include /etc/openldap/schema/kerberos.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 # Schema check allows for forcing entries to # match schemas for their objectClasses's #schemacheck on loglevel none ####################################################################### # ldbm database definitions ####################################################################### modulepath /usr/lib/ldap moduleload back_hdb moduleload rwm sizelimit unlimited tool-threads 1 access to * by * write include /etc/openldap/tls.conf backend hdb # KERBEROS database hdb dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 lastmod on suffix "dc=krb" checkpoint 512 30 directory "/var/lib/ldap/krb" rootdn "cn=admin,dc=krb" rootpw blabla include /etc/openldap/slapd.replica.consumer-krb index objectClass eq index krbPrincipalName eq,pres,sub index krbPwdPolicyReference eq,pres index entryUUID,aliasedObjectName eq index default sub ############################################################################### /etc/openldap/slapd.replica.consumer-krb: # syncrepl syncrepl rid=101 searchbase="dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=102 searchbase="cn=princs,dc=krb" scope=base provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncrepl rid=103 searchbase="cn=krbcontainer,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=104 searchbase="o=zid,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default syncrepl rid=105 searchbase="o=klingons,cn=princs,dc=krb" scope=sub provider=ldaps://syncrepl.zid.gvcc.net type=refreshAndPersist retry="5 5 300 +" schemachecking=off bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/.ssl/usercert.pem tls_key=/etc/openldap/.ssl/user.key tls_cacert=/etc/ssl/cacert.pem tls_reqcert=try syncdata=default ################################################################## buid-options for both versions (2.4.19 and 2.4.23) used on the consumer an on the provider: ./configure --prefix=${prefix} --bindir=${prefix}/bin --sbindir=${prefix}/sbin --libexecdir=${prefix}/lib --libdir=${prefix}/lib --sysconfdir=/etc --localstatedir=/var --mandir=${prefix}/share/man --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod --disable-ndb --enable-overlays=mod --with-subdir=ldap --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc --build x86_64-linux-gnu

1 0

(ITS#6618) Add support for unbind requests in perl backend
by gareth＠acsdata.co.nz 11 Aug '10

11 Aug '10

Full_Name: Gareth Palmer Version: CVS HEAD OS: Ubuntu 9.04 URL: http://www.acsdata.co.nz/patches/openldap-back_perl-unbind-100811.patch Submission from: (NULL) (202.21.137.14) Hello, This patch adds support for passing through unbind requests to the underlying module when using the perl backend. Regards Gareth

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 09 Aug '10

09 Aug '10

> masarati(a)aero.polimi.it wrote: >>> Attempting to create an inetOrgPerson interface to a proprietary >>> database >>> schema. >>> Obviously something wrong at this stage, causes slapd to SEGV. >>> >>> gdb tells me that in >>> servers/slapd/back-sql/entry-id.c:backsql_id2entry() >>> bsi->bsi_oc is null going into this call. >>> >>> rc = attr_merge_normalize_one( bsi->bsi_e, >>> slap_schema.si_ad_objectClass, >>> &bsi->bsi_oc->bom_oc->soc_cname, >>> bsi->bsi_op->o_tmpmemctx ); >>> >>> Without any time to absorb any implications, adding this just before >>> the >>> above >>> call >>> >>> // added without any clue... Rex >>> if ( eid->eid_oc == NULL ) >>> return LDAP_NO_SUCH_OBJECT; >>> >>> fixes the SEGV, but not my interface. >>> >> >> This should not happen, since that objectClass mapping is explicitly >> obtained few lines above if missing, and if the entry's OC was known by >> ID >> it must be available in the ID to OC mapping. I suspect something like >> ITS#6617, where the obejctClass' ID overflows the unsigned long. Can >> you >> investigate? >> >> A backtrace and a description of the expected and actual values would >> help >> (e.g. what ID has the "offending" objectClass, and what ID is >> backsql_id2entry() actually trying to fetch). >> >> It should be OK, at this point, to give up, but a clear indication that >> mapping did not succeed needs to be returned. >> >> p. >> >> > > I've finished my interface and i'm reluctant to share the mess it was in > when it caused the server to crash. > > What i found was that the call to avl_find() in backsql_id2oc() returned > NULL, which got passed back up the > stack, used as a pointer and boom. > > Without spending a long time trying to decipher the code, i could only > guess what any of this means, i'm not > an LDAP expert (or even really all that familiar with it). Please keep replies in CC to the ITS. In principle, avl_find() must return a valid objectClass; logically, we should assert() that a non-NULL pointer is returned. Determining why this occurs could help fixing the issue. Right now, you're just wiping it under the carpet, by returning a generic error instead of the expected data. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Tentatively, the "right" patch would be like this > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> This patch, although apparently fixing this specific case, breaks test020; investigating... p.

1 0

Re: (ITS#6616) back-sql crashing
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> Attempting to create an inetOrgPerson interface to a proprietary database > schema. > Obviously something wrong at this stage, causes slapd to SEGV. > > gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() > bsi->bsi_oc is null going into this call. > > rc = attr_merge_normalize_one( bsi->bsi_e, > slap_schema.si_ad_objectClass, > &bsi->bsi_oc->bom_oc->soc_cname, > bsi->bsi_op->o_tmpmemctx ); > > Without any time to absorb any implications, adding this just before the > above > call > > // added without any clue... Rex > if ( eid->eid_oc == NULL ) > return LDAP_NO_SUCH_OBJECT; > > fixes the SEGV, but not my interface. This should not happen, since that objectClass mapping is explicitly obtained few lines above if missing, and if the entry's OC was known by ID it must be available in the ID to OC mapping. I suspect something like ITS#6617, where the obejctClass' ID overflows the unsigned long. Can you investigate? A backtrace and a description of the expected and actual values would help (e.g. what ID has the "offending" objectClass, and what ID is backsql_id2entry() actually trying to fetch). It should be OK, at this point, to give up, but a clear indication that mapping did not succeed needs to be returned. p.

1 0

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999). Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.

1 0

(ITS#6617) back-sql: 64-bit parent IDs get munged
by 7003＠blargh.com 07 Aug '10

07 Aug '10

Full_Name: Andrew Gray Version: 2.4.23 OS: Debian 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.216.14.1) 64-bit values for (at least) parent IDs do not get resolved correctly - only the lower 32 bits are preserved. This leads up to a crash as it tries to resolve a non-existant ID: To reproduce: ldap_entries has a row with an ID of 1000000000 with a parent of 9999999999 (and a row 9999999999 for the parent). When back-sql goes to resolve this, the following shows in the ODBC trace: SELECT COUNT(*) FROM ldap_entry_objclasses,ldap_entries,ldap_static_entries WHERE ldap_static_entries.id=1410065407 AND ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 (1410065407 = 32-bit rollover of 9999999999).

1 0

(ITS#6616) back-sql crashing
by rex.johnston＠gmail.com 06 Aug '10

06 Aug '10

Full_Name: Rex Johnston Version: cvs OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.255.40.107) Attempting to create an inetOrgPerson interface to a proprietary database schema. Obviously something wrong at this stage, causes slapd to SEGV. gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() bsi->bsi_oc is null going into this call. rc = attr_merge_normalize_one( bsi->bsi_e, slap_schema.si_ad_objectClass, &bsi->bsi_oc->bom_oc->soc_cname, bsi->bsi_op->o_tmpmemctx ); Without any time to absorb any implications, adding this just before the above call // added without any clue... Rex if ( eid->eid_oc == NULL ) return LDAP_NO_SUCH_OBJECT; fixes the SEGV, but not my interface.

1 0

Re: (ITS#6615) objectClass definition and error 65
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 10:43 PM +0000 philippe.eychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: 2.4.21 > OS: Ubuntu 9.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.86.106) This is a question better suited to openldap-technical(a)openldap.org, but inheritance works by having included the previous parent. I.e., person <- organizationalPerson <- inetOrgPerson, as in, inetOrgPerson inherits from organizationalPerson, which inherits from person. person <- organizationalPerson and person <- referencePerson are different inheritance trees. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6614) Checking Pre-Requisities
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 9:06 PM +0000 tcssuneelkumar(a)gmail.com wrote: > Full_Name: Suneel > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.95.226.224) The ITS system is for reporting bugs. For help with building the software, etc, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6615) objectClass definition and error 65
by philippe.eychart＠mail.pf 04 Aug '10

04 Aug '10

Full_Name: Philippe EYCHART Version: 2.4.21 OS: Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.86.106) Hi, Two structural (top) classes are not allowed in the same entry. (a person is not a posixGroup ...) Multiple inheritance is not allowed. (although "oc_sup_oids" is a "char **" in the structure "LDAPObjectClass" ... 8-| ) But, why "organisationalPerson" and "residentialPerson" are they not allowed (error returned: 65) in the same entry of type "person"? Yet, they both inherit from the same objectClass "person"?!... (And these two concepts are not incompatible...) Is this fact a misinterpretation of the "simple inheritance" or this return is correct?... (On the other hand, it's true that "person" and "posixGroup" inherit both from the same -abstract- objectClass : "top" ...) None of my research does the answer (Is this a bugg in the server or must I implement it like that?), so I turn to you ... Regards. PE <http://home.gna.org/ldapcppei/Frontends/Howto-7.fr.html#ss7.2>

1 0

(ITS#6614) Checking Pre-Requisities
by tcssuneelkumar＠gmail.com 03 Aug '10

03 Aug '10

Full_Name: Suneel Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.95.226.224) Hi, I am not a experienced unix admin, but i need to setup OpenLdap 2.4.23 on RedHat Linux environments. As per the Admin guide, There are pre-requisites before we install the openldap. Could you please help me to identify if i have the required pre-install libraries / packages. 1. 4.2.1. Transport Layer Security: [root@tmp]# rpm -q openssl openssl-0.9.8e-12.el5_4.6 2. 4.2.2. Simple Authentication and Security Layer [root@tmp]# rpm -qa | grep -i cyr xorg-x11-drv-cyrix-1.1.0-4 cyrus-sasl-devel-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-plain-2.1.22-5.el5_4.3 cyrus-sasl-2.1.22-5.el5_4.3 3. Kerberos Authentication Service [root@astro tmp]# rpm -qa | grep krb krb5-devel-1.6.1-36.el5_4.1 krb5-auth-dialog-0.7-1 krb5-libs-1.6.1-36.el5_4.1 pam_krb5-2.2.14-15 krb5-workstation-1.6.1-36.el5_4.1 4. Database Software I have downloaded the latest Oracle Berkley DB (5.0.26) and set it up as per the Berkley install guide. IS this good enough to continue with OpenLdap installation ? Are the 2nd and 3rd pre-requisites are good enough to continue ? Could you also please let me know how to check if the specified pre-requisite is already existing in the server or not. Your help is much appreciated. Thanks

1 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 31 Jul '10

31 Jul '10

Am 31.07.2010 04:46, schrieb masarati(a)aero.polimi.it: >> Every other write gets chained just fine when a slave is in this >> condition. It's only the PASSMOD operations that are stuck. > > One quick question: can you tell the parameters of the offending PASSMOD > operations? I mean: old/new password, password generated automatically or > provided, operation performed for self or by a privileged identity, and > so? > > Thanks, p. > > The PASSMODs are done by Linux 'passwd', using pam_ldap (mostly on Debian Lenny, if that matters). The new passwords are provided by the user and the operation is perfomed as "self". I don't know if pam_ldap provides the old password as a parameter to the PASSMOD operation. Binding is done with 'simple bind'. The whole SASL/Kerberos stuff is configured and working, but not yet deployed. I could add the client config (PAM, ldap.conf and so on) to the server related stuff in the linked directory, if you need it. Regards, Christian Manal

1 0

Re: (ITS#6612) Back SQL / Mysql / InnoDB
by f.bosch＠genkgo.nl 31 Jul '10

31 Jul '10

This is a multi-part message in MIME format. --------------020601050300000509070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly. Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read." http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html SQL 2000 by Microsoft and PostgreSQL have read committed as default option. http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx http://www.postgresql.org/docs/8.1/static/transaction-iso.html -- * Frederik Bosch* Partner - Genkgo email: f.bosch(a)genkgo.nl <mailto:f.bosch@genkgo.nl> tel: +31(0)6 241 97 443 *Genkgo V.o.f.* <http://www.genkgo.nl> adres: Rooseveltlaan 162-II postcode : 1078 NT Amsterdam web: www.genkgo.nl <http://www.genkgo.nl> Genkgo logo <http://www.genkgo.nl> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 --------------020601050300000509070509 Content-Type: multipart/related; boundary="------------040401040908020101090801" --------------040401040908020101090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly.<br> <br> Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read."<br> <a class="moz-txt-link-freetext" href="http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html">http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html</a><br> <br> SQL 2000 by Microsoft and PostgreSQL have read committed as default option.<br> <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx">http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx</a><br> <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/8.1/static/transaction-iso.html">http://www.postgresql.org/docs/8.1/static/transaction-iso.html</a><br> <br> <br> <div class="moz-signature">-- <br> <div class="vcard" style="border-top: 1px dotted rgb(153, 153, 153) ! important; padding: 8px ! important; line-height: 14px ! important; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> <div style="border-bottom: 1px dotted rgb(153, 153, 153) ! important; margin: 6px 0pt ! important; width: 420px ! important;"> <strong style="color: rgb(0, 170, 173) ! important; font-size: 12px ! important;"> <span class="n">Frederik Bosch</span></strong><br> <span class="role">Partner</span> - Genkgo<br> <br> email: <a class="email" href="mailto:f.bosch@genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">f.bosch(a)genkgo.nl</a><br> tel: <span class="tel cell">+31(0)6 241 97 443</span><br> <br> <a class="organization-name" href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;"><strong>Genkgo V.o.f.</strong></a><br> <span class="adr" style="color: rgb(85, 85, 85) ! important;">adres: Rooseveltlaan 162-II<br> postcode : <span class="postal-code">1078 NT</span> <span class="locality">Amsterdam</span> <br> <span class="url">web: <a href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">www.genkgo.nl</a><br> <br> <br> <a href="http://www.genkgo.nl"><img class="logo" src="cid:part1.09000506.03080001@genkgo.nl" alt="Genkgo logo" style="border: 0pt none ! important;"></a><br> <br> </span></span></div> <div class="note" style="width: 420px ! important; line-height: 14px; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. <br> <br> Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 </div> </div> </div> </body> </html> --------------040401040908020101090801 Content-Type: image/png; name="genkgo_signature_logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.09000506.03080001(a)genkgo.nl> Content-Disposition: attachment; filename="genkgo_signature_logo.png" iVBORw0KGgoAAAANSUhEUgAAAF4AAAAYCAMAAABEDbotAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAAKhQTFRFIh8fAKqs////WVdXyMfHv+rqkI+P8fHxEK+xQL/B MC0tYMrLg4GBz+/v7/r6TElJr+TlILW2Z2VlrKur3/T1dXNzPjs7f9TVnp2dMLq8n9/gcM/Q UMXGurm5gNXW4+Pj1dXVj9rbDXZ3BJmaAqGjF0pLICgoFVNUEWVm1tXVCYeJGkJCHDk5C3+A BpCSS0lJodbXE1xdU3FxHjAxKZKTsdzcgszN////7KRBsQAAADh0Uk5T//////////////// /////////////////////////////////////////////////////////wA7XBHKAAADR0lE QVR42qyW6ZbbNgyFQVGUZO3raLOssWfLLEnbLOX7v1kvSEnj9CSe+pzih0hr+QACl6BJL+ZP Hqy71VdZLGV16TnZYW5osRvPvwJ/Q+R9iPdjotfTFyHEy1/fKJz+Ox7xfBi9n9HbixB97qid EKdHiq/Bux/gQX9C4EXqwCIh7t4uL/hKfGPo4sB054jZ/dvlb67Cu/QqIqUOBj8UtVNHXx5v 1ue3ZUgUNhBVpTsZkkTlPSljt4QKqgUP/cgpR2JFP7ZtpNM2ECKIasZLuosAzkfHSRwhEsz7 T2vBJtrMy+yY+RIO7dw1+ArXMhKbJYUdg0TTTA8GWQTwnu/FkV3dU2bxwGRux3qV0GDoQWIU S+MFv4nl7M780p/AjWrPC9jxMiJ2V2iq6GTwxwE3+nrPBVbiwe4Hjg4bDYkobaDaA4qjd43m 2ZHmn3OLj7VOwRxyXJTWA4acPLpDVaM9qOkhcPJgcJy9+GQrxkyfi0+lx0zXrAQ8iYdySZoJ AfidxauRw4Zh3uJdDDsBzSs4cA5IHfx+tviZc2GcdJLO7QxvXtGsuJydiGRnPGndI12MDwDk kIsxT/BagMq8LHqL11bh/xYf8lOd9ktdI73ioZ4Ia7sfkRbgByfpxeEQ1bVYk2NyzTRfLxnR lrvg2UNnw093Riyt1uOCN8np6DMkeTR7yqlFwDUoxBPZxgbNNa47L+sw7dSff8Zz4REMRHNU KsV9ZCjAqDhRdEtPQZ1EFu8UA1978Zhtu1JOqKjrz6abul0cloCWZ3if0/PDCBOWaCxe7FUe GGHqDNLp0XBSlmfuGF2eqNt0v1i1tWzKbBde8Wbvfd02VZCO61QBX2Ff4eYu4AQdolwN4v4x XJr+9M5fy5xV0uJX3Zt9Qd83fqS5J6AAiWlpEhsLW21XA59gDMTrGrwfhxSj35QG47tT5/7m sEkgvLZtx8LWFVmq14Yc0kk57/b3AzXLR+V6GCG7FztnjXgNT3H0Px8ntyFNZ/h4o3Nls2n2 uT02F/HKlDOth4J3178PQ/mHv9Gfw/fD5Kycl0/gNNhSP/ziKK/KeHKfnWe3apr57HFnu3BZ fXSu1JFxEETqV/8UkKGuwaEQV77+P+0fAQYAR9P6f2qWAZwAAAAASUVORK5CYII= --------------040401040908020101090801-- --------------020601050300000509070509--

1 0

(ITS#6613) Back SQL / Mysql / InnoDB
by frederik.bosch＠gmail.com 31 Jul '10

31 Jul '10

Full_Name: Frederik Bosch Version: openldap_2.4.11-1+lenny1 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.56.158.179) http://www.openldap.org/lists/openldap-technical/201007/msg00390.html Problem Description: using InnoDB as MySQL table engine prevents records from updating. This is due to the autocommit=0 implementation in InnoDB. There are two possible solutions. 1. Execute COMMIT before every SELECT statement 2. Disable autocommit My suggestion is to use the latter one by adding a configuration option for slapd.conf to enable autocommit. Something like disable_autocommit no|yes, which defaults to yes (current implementation). Perhaps, this will have issues for write mode (INSERT), but this backend is intended for read only usage, isn't it? My C knowledge is too limited to add a patch myself. More details can be found in pasted mailing list thread.

1 0

(ITS#6612) Back SQL / Mysql / InnoDB
by frederik.bosch＠gmail.com 31 Jul '10

31 Jul '10

Full_Name: Frederik Bosch Version: openldap_2.4.11-1+lenny1 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.56.158.179) http://www.openldap.org/lists/openldap-technical/201007/msg00390.html Problem Description: using InnoDB as MySQL table engine prevents records from updating. This is due to the autocommit=0 implementation in InnoDB. There are two possible solutions. 1. Execute COMMIT before every SELECT statement 2. Disable autocommit My suggestion is to use the latter one by adding a configuration option for slapd.conf to enable autocommit. Something like disable_autocommit no|yes, which defaults to yes (current implementation). Perhaps, this will have issues for write mode (INSERT), but this backend is intended for read only usage, isn't it? My C knowledge is too limited to add a patch myself. More details can be found in pasted mailing list thread.

1 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by masarati＠aero.polimi.it 31 Jul '10

31 Jul '10

> Every other write gets chained just fine when a slave is in this > condition. It's only the PASSMOD operations that are stuck. One quick question: can you tell the parameters of the offending PASSMOD operations? I mean: old/new password, password generated automatically or provided, operation performed for self or by a privileged identity, and so? Thanks, p.

1 0

ITS#6611
by masarati＠aero.polimi.it 31 Jul '10

31 Jul '10

Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in servers/slapd/aclparse.c); you can workaround this issue by increasing that value to something *very* large, while the code is fixed. However, you should fix your configuration by assigning those DNs to a group, and using a group ACL instead. p.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 31 Jul '10

31 Jul '10

> Hey Pierangelo, > > I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this > looks like it fixes the issue I mentioned in > http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion > correct? I couldn't specifically look at your issue (apart from the simple fix to allow cn=config to work). ITS#6574 should have nothing to do with your issue, as it affects back-meta in a part that has no code commonality with back-ldap, and slapo-chain is built on top of back-ldap. I'm sorry I went back through this thread and got somehow lost; what's the exact topic now? I infer (from followup #14) that there seems to be an issue about chaining because slapo-chain seems not to rebind as expected. Could you isolate the problem in a minimal setup (slapd.conf or the corresponding back-config's LDIF, a database and a simple operation that can be performed with ldapmodify/ldappasswd or so) to clearly reproduce the issue? Thanks, p.

1 0

(ITS#6611) slapd: segmentation fault caused by large ACL
by leonardo＠ngdn.org 30 Jul '10

30 Jul '10

Full_Name: Leonardo Chiquitto Version: 2.4.23 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.101.104.29) Setting up a large ACL entry (as the example below) in slapd.conf will make slapd crash with a segmentation fault when starting up. access to dn.subtree="ou=autofs,ou=l,dc=ngdn,dc=org" by dn.base="cn=1,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=2,ou=autofs,ou=l,dc=ngdn,dc=org" read (...) by dn.base="cn=149,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=150,ou=autofs,ou=l,dc=ngdn,dc=org" read Here's the back trace: Program terminated with signal 11, Segmentation fault. #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 545 while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { (gdb) bt #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 #1 0x00007fd98e13ef9f in at_bvfind (name=0x7fffa163d0c0) at at.c:126 #2 0x00007fd98e13d61d in slap_bv2ad (bv=0x7fd98e5b7880, ad=0x7fffa163d5a8, text=0x7fffa163d5a0) at ad.c:201 #3 0x00007fd98e10c81b in LDAPRDN_rewrite (rdn=0x7fd98e5b78c0, flags=<value optimized out>, ctx=0x0) at dn.c:285 #4 0x00007fd98e10c970 in LDAPDN_rewrite (dn=<value optimized out>, flags=0, ctx=0x0) at dn.c:406 #5 0x00007fd98e10e495 in dnNormalize (use=<value optimized out>, syntax=<value optimized out>, mr=<value optimized out>, val=0x7fd98e4bc1e8, out=0x7fd98e4bc1f8, ctx=0x0) at dn.c:446 #6 0x00007fd98e0ea70d in read_config ( fname=0x7fd98e535030 "/etc/openldap/slapd.conf", dir=0x0) at bconfig.c:4101 #7 0x00007fd98e0dbbf9 in main (argc=13, argv=0x7fffa163d8c8) at main.c:767

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 30 Jul '10

30 Jul '10

The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch.2 passive ftp rules - sorry for the confusion

1 0

Re: (ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by hyc＠symas.com 29 Jul '10

29 Jul '10

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.23 > OS: Linux > URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 > Submission from: (NULL) (209.132.186.34) > > > When running slapd listening on local socket (ldapi:///), clients connecting to > it will sometimes SIGPIPE when using TLS. This happens in about 70% times. > > How to reproduce: > generate a pem certificate > slapd -h ldapi:/// > ldapsearch -H ldapi:/// -ZZ -x -d -1 > > I'm attaching straces from both slapd and ldapsearch. What seems to be happening > is that slapd receives EAGAIN during the read from socket, marks it for another > read, but then terminates a reading thread and closes the connection, while > client still wants to write some data. When doing ldapsearch, it does this after > result was returned, that's why it can be seen probably only in debugging mode. > > The issue was originally reported on 2.3.43, but I successfully reproduced it on > newer versions, including 2.4.23. The only exception was Fedora rawhide version > (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) > doesn't seem to support local sockets at all, so it is not possible to use ldapi > with -ZZ any more. Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages. > I'm attaching straces from both successful and unsuccessful run. For complete > information here is URL of relevant redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=564108 In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 29 Jul '10

29 Jul '10

Howard Chu schrieb: > The patch in the URL you specified appears to be empty. Although I'm pretty sure I've successfully uploaded the patch as I (think I) always check the URLs twice right after posting I just tried to upload it again some minutes ago using the filename: servers-slapd-schema_init_2.patch The ftp-server let me successfully log in but does not allow me to upload anything into /incoming: "425 Can't build data connection: Connection refused." Possibly this is also the cause the patch file currently seems to be empty after your download? I've tried the upload from different hosts and networks (IPv6 with IPv4 fallback) without success. Have not investigated in deep but I think it does not seem to be a problem of my/our firewalls. daniel@tingletangle:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:daniel): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> ascii 200 Type set to A. ftp> put servers-slapd-schema_init_2.patch local: servers-slapd-schema_init_2.patch remote: servers-slapd-schema_init_2.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> quit

1 0

(ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by jzeleny＠redhat.com 29 Jul '10

29 Jul '10

Full_Name: Jan Zeleny Version: 2.4.23 OS: Linux URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 Submission from: (NULL) (209.132.186.34) When running slapd listening on local socket (ldapi:///), clients connecting to it will sometimes SIGPIPE when using TLS. This happens in about 70% times. How to reproduce: generate a pem certificate slapd -h ldapi:/// ldapsearch -H ldapi:/// -ZZ -x -d -1 I'm attaching straces from both slapd and ldapsearch. What seems to be happening is that slapd receives EAGAIN during the read from socket, marks it for another read, but then terminates a reading thread and closes the connection, while client still wants to write some data. When doing ldapsearch, it does this after result was returned, that's why it can be seen probably only in debugging mode. The issue was originally reported on 2.3.43, but I successfully reproduced it on newer versions, including 2.4.23. The only exception was Fedora rawhide version (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) doesn't seem to support local sockets at all, so it is not possible to use ldapi with -ZZ any more. I'm attaching straces from both successful and unsuccessful run. For complete information here is URL of relevant redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=564108

1 0

(ITS#6609) Admin Guide Documentation typo's
by paul＠mawsonlakes.org 29 Jul '10

29 Jul '10

Full_Name: Paul Schulz Version: CVS OS: Linux/Ubuntu URL: Submission from: (NULL) (116.212.217.6) Patch.. diff --git a/admin/access-control.sdf b/admin/access-control.sdf index f18dba3..1ff6815 100644 --- a/admin/access-control.sdf +++ b/admin/access-control.sdf @@ -826,7 +826,7 @@ This ACL grants read permissions to authenticated users while denying others H3: Controlling rootdn access -You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without +You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without specifying a {{rootpw}}. Then you have to add an actual directory entry with the same dn, e.g.: @@ -876,7 +876,7 @@ One can then grant access to the members of this this group by adding appropriat > by group.exact="cn=Administrators,dc=example,dc=com" write > by * auth -Like by {[dn}} clauses, one can also use {{expand}} to expand the group name +Like by {{dn}} clauses, one can also use {{expand}} to expand the group name based upon the regular expression matching of the target, that is, the to {{dn.regex}}). For instance, diff --git a/admin/appendix-common-errors.sdf b/admin/appendix-common-errors.sdf index b285cd2..be901f1 100644 --- a/admin/appendix-common-errors.sdf +++ b/admin/appendix-common-errors.sdf @@ -11,7 +11,7 @@ H2: Common causes of LDAP errors H3: ldap_*: Can't contact LDAP server -The {[B:Can't contact LDAP server}} error is usually returned when the LDAP +The {{B:Can't contact LDAP server}} error is usually returned when the LDAP server cannot be contacted. This may occur for many reasons: * the LDAP server is not running; this can be checked by running, for example,

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 29 Jul '10

29 Jul '10

Rein Tollevik wrote: > On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > >> Also in terms of logical abstraction the current behavior is wrong; the >> frontend should of course generate the default_referral responses but >> updateref is a per-backend item and should be generated at the backend layer. >> Ideally this would all have been fixed to behave correctly by moving all >> replication support into an overlay, where it properly belongs. As an interim >> step it would be trivial to write an updateref overlay that supersedes the >> current updateref behavior. > > Updateref processing should imo be kept out of any replication modules, > it is needed in databases where syncrepl isn't configured too. I'm > using it on my subordinate databases (with an artificial updatedn so > that slapd accepts it..) when syncrepl is configured on the superior > glue database without managing all of the subordinate databases. I.e, > the infamous test058... > > I was having the same "chain only on some of the databases" requirement > and is using a patch that allows it. I consider this patch more of a > hack than a correct solution, which is why I haven't contributed it. A > separate updateref overlay apear to me as the best solution. But for > what it's worth, my patch is now in: > > ftp://ftp.openldap.org/incoming/rein-ITS6531.patch > > An advantage with this patch over a new overlay is that it should be > usable without any configuration changes (provided the chain overlay > have already been configured in the databases and found to not work as > expected there that is ... ;-). I didn't quite follow the intended usage for this patch. Are other overlays expected to override the default over_mod_ref() handler? -- -- 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#6532) Support for common orderingMatching rules in extensible match filters
by Howard Chu 29 Jul '10

29 Jul '10

The patch in the URL you specified appears to be empty.

1 0

Re: (ITS#6607) forwarded bind failure messages cause success
by hyc＠symas.com 28 Jul '10

28 Jul '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: RE24 > OS: > URL: > Submission from: (NULL) (76.88.107.46) > > > As noted in > > http://www.openldap.org/lists/openldap-technical/201004/msg00247.html > > setting up a chain overlay on the frontend and then configuring ppolicy with > ppolicy_forward_updates causes BIND operations with invalid credentials to > return success, apparently from the result of the chain operation. > > This is independent of the value of chain-return-error. > > WHOAMI reports anonymous after these "successful" BINDs with invalid passwords, > so there is no security compromise within the directory itself, however this has > (as noted in the above email) catastrophic results for external apps trying to > authenticate with BIND. > > This was already fixed in HEAD by back-ldap/chain.c rev 1.77 (apparently fixed for unrelated reasons). -- -- 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#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hey Pierangelo, I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this looks like it fixes the issue I mentioned in http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion correct? Ryan Steele wrote: > Hi Pierangelo, > >>> Try this patch: >>> >>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >>> >>> It removes the offending check. I don't quite remember the reason (it >>> dates 4.5 years ago). However, I've checked and all tests pass fine, >>> including the one you pointed out. To reproduce, I modified test022 to >>> write the configuration on disk (-F option to consumer slapd); at the end >>> of the test, I tried slapd on the resulting database. Fails with >>> 2.4.22/HEAD, succeeds with this patch. >>> >>> Please test and report. >>> >>> p. > > I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch > does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not > passed correctly upstream to the read/write master. Thoughts? > -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hi Pierangelo, >> Try this patch: >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >> >> It removes the offending check. I don't quite remember the reason (it >> dates 4.5 years ago). However, I've checked and all tests pass fine, >> including the one you pointed out. To reproduce, I modified test022 to >> write the configuration on disk (-F option to consumer slapd); at the end >> of the test, I tried slapd on the resulting database. Fails with >> 2.4.22/HEAD, succeeds with this patch. >> >> Please test and report. >> >> p. I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not passed correctly upstream to the read/write master. Thoughts? -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

Hi, In short, this works: Deleting cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Deleted cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com While this fails: Deleting cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Searching cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) Searched cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) LDAP Connection error happend LDAPException: Connection lost waiting for results from cin0575.vanenburg.com:6,366 (91) Connect Error java.net.SocketException: Connection reset Thanks and regards, Binoy Joseph

1 0

Fwd: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

Sending 1 more time as plain text. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 ---------- Forwarded message ---------- From: Binoy Joseph <binoy(a)cordys.com> Date: Wed, Jul 28, 2010 at 6:39 PM Subject: Re: (ITS#6599) slapd not responding To: openldap-its(a)openldap.org Hi, 1) I downloaded OpenLDAP=A02.4.23 (20100719).=A0I checked servers/slapd/back-bdb/cache.c. I see that the fix for=A0ITS#6577 dated July 1 is not available in the release build. I checked out the latest sources and did a build and tested. 2) The issue still persists in Windows. Here are some useful logs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This is a SUCCESSFUL scenario: conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#000000 bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xa96: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xa96: 0 =3D> index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [a0795064] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [26382a68] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [b9195d83] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [64447e0e] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [403d84ed] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [600c0260] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [d66e2c29] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [547b3983] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [1610f370] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [0096defd] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [f612c92d] <=3D key_change 0 <=3D index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D> bdb_cache_delete( 2710 ) hdb_delete: deleted id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" send_ldap_result: conn=3D1000 op=3D8703 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D43189 tag=3D107 err=3D0 ber_flush2: 16 bytes to sd 1832 =A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 0a 01 00 04 00 04 00 =A0 0....= ..k........ tls_write: want=3D90, written=3D90 =A0=A00000: =A017 03 01 00 20 d3 72 46 =A05c 99 ae 97 cd 90 f5 64 =A0 .... = .rF\......d =A0=A00010: =A047 53 38 1d 26 6c c7 d4 =A021 45 28 e2 27 31 bd 5f =A0 GS8.&= l..!E(.'1._ =A0=A00020: =A0bc c4 92 eb 6e 17 03 01 =A000 30 e5 be 97 76 6c cc =A0 ....n= ....0...vl. =A0=A00030: =A029 c0 21 05 d9 f6 55 d6 =A02a dc d5 68 0b f6 73 6a =A0 ).!..= .U.*..h..sj =A0=A00040: =A07f ff 24 8b fa 9e 57 41 =A027 ee d3 9a e5 9a 17 11 =A0 ..$..= .WA'....... =A0=A00050: =A0ee 87 0d 55 ae 98 81 53 =A02d 7d =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 ...U...S-} ldap_write: want=3D16, written=3D16 =A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 0a 01 00 04 00 04 00 =A0 0....= ..k........ conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D slap_graduate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000 daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL connection_get(5) daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL connection_get(5): got connid=3D1000 daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_read(5): checking for input on id=3D1000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is where it FAILS conn=3D1000 op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#000000 bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_get(5) connection_get(5): got connid=3D1000 connection_read(5): checking for input on id=3D1000 ber_get_next tls_read: want=3D5, got=3D5 =A0..... op tag 0x63, time 1280314986 ber_get_next tls_read: want=3D5 error=3DUnknown error ldap_read: want=3D8 error=3DUnknown error daemon: activity on 1 descriptor daemon: waked daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xc4b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xc4b: 0 =3D> index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [aec1526a] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [27382a68] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [ce175d82] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [2230817c] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [8b4384f1] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [600c0260] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [58802faf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [547b3983] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [9821f6f6] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [0096defd] conn=3D1000 op=3D9271 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113 =A0=A00000: =A063 6f 04 4e 63 6e 3d 54 =A065 73 74 33 36 37 2c 63 =A0 co.Nc= n=3DTest367,c =A0=A00010: =A06e 3d 54 65 73 74 33 36 =A037 2c 63 6e 3d 73 6f 61 =A0 n=3DT= est367,cn=3Dsoa =A0=A00020: =A070 20 6e 6f 64 65 73 2c =A06f 3d 73 79 73 74 65 6d =A0 p nod= es,o=3Dsystem =A0=A00030: =A02c 63 6e 3d 63 6f 72 64 =A079 73 2c 63 6e 3d 74 32 =A0 ,cn= =3Dcordys,cn=3Dt2 =A0=A00040: =A037 34 2c 6f 3d 76 61 6e =A065 6e 62 75 72 67 2e 63 =A0 74,o= =3Dvanenburg.c =A0=A00050: =A06f 6d 0a 01 00 0a 01 00 =A002 02 07 d0 02 01 00 01 =A0 om...= ........... =A0=A00060: =A001 00 87 0b 6f 62 6a 65 =A063 74 63 6c 61 73 73 30 =A0 ....o= bjectclass0 =A0=A00070: =A000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,c= n=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> =3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com,0) <=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 <<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" 0 0 =A0 =A02000 0= 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15 =A0=A00000: =A087 0b 6f 62 6a 65 63 74 =A063 6c 61 73 73 30 00 =A0 =A0 =A0.= .objectclass0. end get_filter 0 =A0=A0 =A0filter: (objectClass=3D*) ber_scanf fmt ({M}}) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAFA3 end=3D015AAFA5 len=3D2 =A0=A00000: =A000 00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.. =A0=A0 =A0attrs: conn=3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" scope=3D0 deref= =3D0 filter=3D"(objectClass=3D*)" =3D> hdb_search bdb_dn2entry("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> hdb_dn2id("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [f612c92d] <=3D key_change 0 <=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please help. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 On Wed, Jul 28, 2010 at 12:49 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> w= rote: > > --On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com>= wrote: > >> >> Hi Quanah, >> >> >> Thanks a lot for your reply. >> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in >> Linux. >> But somehow the issue still occurs in Windows. >> Can you mention which file/issue you are talking about regarding the >> locking behavior you mentioned? >> Thanks and regards, >> Binoy Joseph > > ITS#6577 > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =A0the leader in open source messaging and collaboration

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

--0016361e878249aeff048c7254d0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, 1) I downloaded OpenLDAP 2.4.23 (20100719)<ftp://ftp.openldap.org/pub/OpenLDAP/openldap-stable/openldap-sta= ble-20100719.tgz> . I checked servers/slapd/back-bdb/cache.c. I see that the fix for ITS#6577 dated July 1 is not available in the release build. I checked out the lates= t sources and did a build and tested. 2) The issue still persists in Windows. Here are some useful logs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This is a SUCCESSFUL scenario: conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#000000 bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xa96: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xa96: 0 =3D> index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [a0795064] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [26382a68] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [b9195d83] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [64447e0e] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [403d84ed] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [600c0260] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [d66e2c29] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [547b3983] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [1610f370] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [0096defd] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [f612c92d] <=3D key_change 0 <=3D index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D> bdb_cache_delete( 2710 ) hdb_delete: deleted id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" send_ldap_result: conn=3D1000 op=3D8703 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D43189 tag=3D107 err=3D0 ber_flush2: 16 bytes to sd 1832 0000: 30 0e 02 03 00 a8 b5 6b 07 0a 01 00 04 00 04 00 0......k.......= . tls_write: want=3D90, written=3D90 0000: 17 03 01 00 20 d3 72 46 5c 99 ae 97 cd 90 f5 64 .... .rF\......= d 0010: 47 53 38 1d 26 6c c7 d4 21 45 28 e2 27 31 bd 5f GS8.&l..!E(.'1.= _ 0020: bc c4 92 eb 6e 17 03 01 00 30 e5 be 97 76 6c cc ....n....0...vl= . 0030: 29 c0 21 05 d9 f6 55 d6 2a dc d5 68 0b f6 73 6a ).!...U.*..h..s= j 0040: 7f ff 24 8b fa 9e 57 41 27 ee d3 9a e5 9a 17 11 ..$...WA'......= . 0050: ee 87 0d 55 ae 98 81 53 2d 7d ...U...S-} ldap_write: want=3D16, written=3D16 0000: 30 0e 02 03 00 a8 b5 6b 07 0a 01 00 04 00 04 00 0......k.......= . conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D slap_graduate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000 daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL connection_get(5) daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL connection_get(5): got connid=3D1000 daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_read(5): checking for input on id=3D1000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is where it FAILS conn=3D1000 op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#000000 bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_get(5) connection_get(5): got connid=3D1000 connection_read(5): checking for input on id=3D1000 ber_get_next tls_read: want=3D5, got=3D5 ..... op tag 0x63, time 1280314986 ber_get_next tls_read: want=3D5 error=3DUnknown error ldap_read: want=3D8 error=3DUnknown error daemon: activity on 1 descriptor daemon: waked daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xc4b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xc4b: 0 =3D> index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [aec1526a] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [27382a68] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [ce175d82] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [2230817c] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [8b4384f1] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [600c0260] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [58802faf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [547b3983] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [9821f6f6] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [0096defd] conn=3D1000 op=3D9271 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113 0000: 63 6f 04 4e 63 6e 3d 54 65 73 74 33 36 37 2c 63 co.Ncn=3DTest36= 7,c 0010: 6e 3d 54 65 73 74 33 36 37 2c 63 6e 3d 73 6f 61 n=3DTest367,cn= =3Dsoa 0020: 70 20 6e 6f 64 65 73 2c 6f 3d 73 79 73 74 65 6d p nodes,o=3Dsys= tem 0030: 2c 63 6e 3d 63 6f 72 64 79 73 2c 63 6e 3d 74 32 ,cn=3Dcordys,cn= =3Dt2 0040: 37 34 2c 6f 3d 76 61 6e 65 6e 62 75 72 67 2e 63 74,o=3Dvanenbur= g.c 0050: 6f 6d 0a 01 00 0a 01 00 02 02 07 d0 02 01 00 01 om.............= . 0060: 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 ....objectclass= 0 0070: 00 . >>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> =3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com,0) <=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 <<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com> SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com" 0 0 2000 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=3D*) ber_scanf fmt ({M}}) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAFA3 end=3D015AAFA5 len=3D2 0000: 00 00 .. attrs: conn=3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" scope=3D0 deref= =3D0 filter=3D"(objectClass=3D*)" =3D> hdb_search bdb_dn2entry("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> hdb_dn2id("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [f612c92d] <=3D key_change 0 <=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please help. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 On Wed, Jul 28, 2010 at 12:49 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wr= ote: > --On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com> > wrote: > > >> Hi Quanah, >> >> >> Thanks a lot for your reply. >> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in >> Linux. >> But somehow the issue still occurs in Windows. >> Can you mention which file/issue you are talking about regarding the >> locking behavior you mentioned? >> Thanks and regards, >> Binoy Joseph >> > > ITS#6577 > > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --0016361e878249aeff048c7254d0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div>Hi,</div><div><br></div><div>1) I downloaded OpenLDAP=A0<span class=3D= "Apple-style-span" style=3D"font-family: Arial, Verdana, Helvetica; font-si= ze: medium; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical= -spacing: 2px; "><a href=3D"ftp://ftp.openldap.org/pub/OpenLDAP/openldap-st= able/openldap-stable-20100719.tgz">2.4.23 (20100719)</a>.=A0</span>I checke= d servers/slapd/back-bdb/cache.c. I see that the fix for=A0ITS#6577 dated J= uly 1 is not available in the release build. I checked out the latest sourc= es and did a build and tested.</div> <div><br></div><div>2) The issue still persists in Windows. Here are some u= seful logs.</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>This is a SUCCES= SFUL scenario:</div> <div><br></div><div><div>conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,= cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vane= nburg.com">vanenburg.com</a>"</div><div>bdb_dn2entry("cn=3Dtest22= 0,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://va= nenburg.com">vanenburg.com</a>")</div> <div>=3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dco= rdys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a></div>= <div>slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#0000= 00</div><div> bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</div> <div>=3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsys= tem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.co= m</a>" "children" requested</div><div><=3D root access gr= anted</div> <div> =3D> access_allowed: delete access granted by manage(=3Dmwrscxd)</div><d= iv>=3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap no= des,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">v= anenburg.com</a>" "entry" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> hdb_dn2id_delete 0xa9= 6: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D= <a href=3D"http://vanenburg.com">vanenburg.com</a>"</div> <div><=3D hdb_dn2id_delete 0xa96: 0</div><div>=3D> index_entry_del( 2= 710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" )</div><div>=3D= > key_change(DELETE,a96)</div> <div>bdb_idl_delete_key: a96=A0</div><div><=3D key_change 0</div><div>= =3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [a0795064]= </div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a96)</d= iv><div> bdb_idl_delete_key: a96 [78d8fcbf]</div><div><=3D key_change 0</div><div= >=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [26382a68= ]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a96)</= div> <div>bdb_idl_delete_key: a96 [b9195d83]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [644= 47e0e]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [815b06f7]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [403= d84ed]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [600c0260]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [d66= e2c29]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [547b3983]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [161= 0f370]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [0096defd]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [f61= 2c92d]</div><div><=3D key_change 0</div><div><=3D index_entry_del( 27= 10, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" ) success</div> <div>=3D=3D=3D=3D> bdb_cache_delete( 2710 )</div><div>hdb_delete: delete= d id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcor= dys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>"<= /div><div>send_ldap_result: conn=3D1000 op=3D8703 p=3D3</div> <div>send_ldap_result: err=3D0 matched=3D"" text=3D""</= div><div>send_ldap_response: msgid=3D43189 tag=3D107 err=3D0</div><div>ber_= flush2: 16 bytes to sd 1832</div><div>=A0=A00000: =A030 0e 02 03 00 a8 b5 6= b =A007 0a 01 00 04 00 04 00 =A0 0......k........ =A0</div> <div>tls_write: want=3D90, written=3D90</div><div>=A0=A00000: =A017 03 01 0= 0 20 d3 72 46 =A05c 99 ae 97 cd 90 f5 64 =A0 .... .rF\......d =A0</div><div= >=A0=A00010: =A047 53 38 1d 26 6c c7 d4 =A021 45 28 e2 27 31 bd 5f =A0 GS8.= &l..!E(.'1._ =A0</div> <div>=A0=A00020: =A0bc c4 92 eb 6e 17 03 01 =A000 30 e5 be 97 76 6c cc =A0 = ....n....0...vl. =A0</div><div>=A0=A00030: =A029 c0 21 05 d9 f6 55 d6 =A02a= dc d5 68 0b f6 73 6a =A0 ).!...U.*..h..sj =A0</div><div>=A0=A00040: =A07f = ff 24 8b fa 9e 57 41 =A027 ee d3 9a e5 9a 17 11 =A0 ..$...WA'....... = =A0</div> <div>=A0=A00050: =A0ee 87 0d 55 ae 98 81 53 =A02d 7d =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ...U...S-} =A0 =A0 =A0 =A0</div><div>ldap_write: want= =3D16, written=3D16</div><div>=A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 = 0a 01 00 04 00 04 00 =A0 0......k........ =A0</div> <div> conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D</div><div>slap_gradu= ate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000<= /div><div>daemon: activity on 6 descriptors</div><div>daemon: activity on: = 5r</div> <div>daemon: read activity on 5</div><div>daemon: WSselect: listen=3D2 acti= ve_threads=3D0 tvp=3DNULL</div><div>connection_get(5)</div><div>daemon: WSs= elect: listen=3D3 active_threads=3D0 tvp=3DNULL</div><div>connection_get(5)= : got connid=3D1000</div> <div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL</div><div>c= onnection_read(5): checking for input on id=3D1000</div></div><div>=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D</div> <div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>This is wh= ere it FAILS</div><div><br></div><div><div><br></div><div><div>conn=3D1000 = op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordy= s,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>"</d= iv> <div>bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys= ,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</d= iv><div>=3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn= =3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a><= /div> <div>slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#0000= 00</div><div>bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn= =3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>&= quot;)</div> <div>daemon: activity on 6 descriptors</div><div>daemon: activity on: 5r</d= iv><div>daemon: read activity on 5</div><div>daemon: WSselect: listen=3D2 a= ctive_threads=3D0 tvp=3DNULL</div><div>daemon: WSselect: listen=3D3 active_= threads=3D0 tvp=3DNULL</div> <div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL</div><div>c= onnection_get(5)</div><div>connection_get(5): got connid=3D1000</div><div>c= onnection_read(5): checking for input on id=3D1000</div><div>ber_get_next</= div><div> tls_read: want=3D5, got=3D5</div><div>=A0.....=A0</div><div>op tag 0x63, ti= me 1280314986</div><div>ber_get_next</div><div>tls_read: want=3D5 error=3DU= nknown error</div><div>ldap_read: want=3D8 error=3DUnknown error</div><div>= daemon: activity on 1 descriptor</div> <div>daemon: waked</div><div>daemon: WSselect: listen=3D2 active_threads=3D= 0 tvp=3DNULL</div><div>daemon: WSselect: listen=3D3 active_threads=3D0 tvp= =3DNULL</div><div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNUL= L</div><div>=3D> access_allowed: delete access to "cn=3Dsoap nodes,= o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanen= burg.com</a>" "children" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> access_allowed: delet= e access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3D= t274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" "ent= ry" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> hdb_dn2id_delete 0xc4= b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D= <a href=3D"http://vanenburg.com">vanenburg.com</a>"</div> <div><=3D hdb_dn2id_delete 0xc4b: 0</div><div>=3D> index_entry_del( 3= 147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" )</div><div>=3D= > key_change(DELETE,c4b)</div> <div>bdb_idl_delete_key: c4b=A0</div><div><=3D key_change 0</div><div>= =3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [aec1526a]= </div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</d= iv><div> bdb_idl_delete_key: c4b [78d8fcbf]</div><div><=3D key_change 0</div><div= >=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [27382a68= ]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</= div> <div>bdb_idl_delete_key: c4b [ce175d82]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [223= 0817c]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [815b06f7]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [8b4= 384f1]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [600c0260]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [588= 02faf]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [547b3983]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [982= 1f6f6]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [0096defd]</div><div>conn=3D1000 op=3D9271 do_= search</div><div>ber_scanf fmt ({miiiib) ber:</div><div>ber_dump: buf=3D015= AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113</div><div>=A0=A00000: =A063 6= f 04 4e 63 6e 3d 54 =A065 73 74 33 36 37 2c 63 =A0 co.Ncn=3DTest367,c =A0</= div> <div>=A0=A00010: =A06e 3d 54 65 73 74 33 36 =A037 2c 63 6e 3d 73 6f 61 =A0 = n=3DTest367,cn=3Dsoa =A0</div><div>=A0=A00020: =A070 20 6e 6f 64 65 73 2c = =A06f 3d 73 79 73 74 65 6d =A0 p nodes,o=3Dsystem =A0</div><div>=A0=A00030:= =A02c 63 6e 3d 63 6f 72 64 =A079 73 2c 63 6e 3d 74 32 =A0 ,cn=3Dcordys,cn= =3Dt2 =A0</div> <div>=A0=A00040: =A037 34 2c 6f 3d 76 61 6e =A065 6e 62 75 72 67 2e 63 =A0 = 74,o=3Dvanenburg.c =A0</div><div>=A0=A00050: =A06f 6d 0a 01 00 0a 01 00 =A0= 02 02 07 d0 02 01 00 01 =A0 om.............. =A0</div><div>=A0=A00060: =A00= 1 00 87 0b 6f 62 6a 65 =A063 74 63 6c 61 73 73 30 =A0 ....objectclass0 =A0<= /div> <div>=A0=A00070: =A000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0</div><div>>>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367= ,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://van= enburg.com">vanenburg.com</a>></div> <div>=3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsyste= m,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com<= /a>,0)</div><div><=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>)=3D0=A0</div> <div>=3D> ldap_dn2bv(272)</div><div><=3D ldap_dn2bv(cn=3DTest367,cn= =3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"= http://vanenburg.com">vanenburg.com</a>)=3D0=A0</div><div>=3D> ldap_dn2b= v(272)</div><div><=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>)=3D0=A0</div> <div><<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap n= odes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">= vanenburg.com</a>>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsy= stem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.c= om</a>></div> <div>SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dc= ordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>&quot= ; 0 0 =A0 =A02000 0 0</div><div>begin get_filter</div><div>PRESENT</div><di= v>ber_scanf fmt (m) ber:</div> <div>ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15</div><= div>=A0=A00000: =A087 0b 6f 62 6a 65 63 74 =A063 6c 61 73 73 30 00 =A0 =A0 = =A0..objectclass0. =A0=A0</div><div>end get_filter 0</div><div>=A0=A0 =A0fi= lter: (objectClass=3D*)</div> <div> ber_scanf fmt ({M}}) ber:</div><div>ber_dump: buf=3D015AAF30 ptr=3D015AAFA3= end=3D015AAFA5 len=3D2</div><div>=A0=A00000: =A000 00 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</div><div>=A0=A0 =A0attrs:</div><div>conn= =3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)&= quot;</div> <div>=3D> hdb_search</div><div>bdb_dn2entry("cn=3Dtest367,cn=3Dtest= 367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://= vanenburg.com">vanenburg.com</a>")</div><div>=3D> hdb_dn2id("c= n=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</div> <div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</div><di= v>bdb_idl_delete_key: c4b [f612c92d]</div><div><=3D key_change 0</div><d= iv><=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsy= stem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.c= om</a>" ) success</div> </div></div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>= <div><br></div><div>Please help.</div><br clear=3D"all">Thanks and regards,= <br><br>Binoy Joseph<br> Sr. Software Engineer<br>T +91 406656 1498 =95 M +91 9849176132<br> <br><br><div class=3D"gmail_quote">On Wed, Jul 28, 2010 at 12:49 AM, Quanah= Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com">qu= anah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">--On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph &l= t;<a href=3D"mailto:binoy@cordys.com" target=3D"_blank">binoy(a)cordys.com</a= >> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Hi Quanah,<br> <br> <br> Thanks a lot for your reply.<br> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in<br> Linux.<br> But somehow the issue still occurs in Windows.<br> Can you mention which file/issue you are talking about regarding the<br> locking behavior you mentioned?<br> Thanks and regards,<br> Binoy Joseph<br> </blockquote> <br></div> ITS#6577<div><div></div><div class=3D"h5"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Principal Software Engineer<br> Zimbra, Inc<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </div></div></blockquote></div><br> --0016361e878249aeff048c7254d0--

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 28 Jul '10

28 Jul '10

Thanks a lot for looking into this issue. On Thu, Jul 22, 2010 at 3:07 AM, Howard Chu <hyc(a)symas.com> wrote: > asifiqbal.desai(a)gmail.com wrote: >> >> Full_Name: Asif Iqbal Desai >> Version: 2.4.16 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (130.214.64.6) >> >> >> This is a consulation bug for clarification on close() being called from >> ldap_unbind_s with fd =3D 1. >> >> The application uses ldap client apis for user authentication. >> We recently upgraded to use OpenLDAP version 2.4.16 and are getting an >> unexpected AIO error issue when ldap user authentication is enabled. >> >> Investigating further revealed that from ldap_unbind_s ( close(-1) is >> getting >> called. However the close function of solaris libaio does a special >> handling >> when fd< =A00 which causes AIO errors. >> >> The application needs solaris aio support and hence cannot link libc >> before >> libaio. >> >> Is there any specific reason for close being called with fd =3D -1 from >> ldap_unbind_s. >> This issue didnot exist with OpenLDAP 2.3.27. > > I've checked 2.3.43 and 2.4.23; in both cases ber_int_sb_close() is being > called twice on the same sockbuf. I suppose that might be considered a bu= g, > but certainly the behavior has not changed between 2.3 and 2.4. > >> Following is the stacktrace: >> =A0 [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, = 0x0, >> 0x0), >> at 0xffffffff7f406a64 >> =A0 [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, >> 0x0), at >> 0xffffffff7d21eafc >> =A0 [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, >> 0x0), at >> 0xffffffff7d21e160 >> =A0 [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, >> 0xffffffff7dbad2ec, >> 0xd), at 0xffffffff7d21cebc >> =A0 [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at >> 0xffffffff7d26a4bc >> =A0 [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, >> 0x100121a00), at 0xffffffff7d26a048 >> =A0 [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, >> 0xfffffffffffffff2, >> 0x0, 0x100117728), at 0xffffffff7d26a55c >> ... >> ... >> >> Thanks in Advance, >> Asif Iqbal Desai >> >> > > > -- > =A0-- Howard Chu > =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ >

1 0

(ITS#6608) ppolicy internal modifications break replication
by mbackes＠symas.com 28 Jul '10

28 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) The current ppolicy draft standard does not address replication issues, and the resulting implementation has trouble. If frontend-chaining to the master and ppolicy_forward_updates is enabled, invalid binds return success (ITS 6607). If they are disabled, the local changes increase the CSNs in the local copy beyond the contextCSN of the provider, which results in broken replication. (ITS 6606) Possible fixes include: * disallowing shadow contexts the use of ppolicy (probably unpopular) * requiring frontend-chaining once that works * not updating operational attributes at all for ppolicy changes. (allows replicas to diverge on bind failure data but is probably safest)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs