openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by joke＠seiken.de 14 Jun '13

14 Jun '13

Full_Name: Joke de Buhr Version: 2.4.35 OS: fedora 18 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.5.143.82) While using the password policy overlay changing the parameter olcPasswordHash causes an error upon password update. When changing the password via ldappasswd after changing the parameter olcPasswordHash the error Constraint violation (19) Password policy only allows one password value if returned to the client. Changing the password isn't possible until slapd is restarted. After restarting slapd changing the password works again. Please refer to my postings [1] on the mailing list. [1] http://www.openldap.org/lists/openldap-technical/201306/msg00122.html

1 0

(ITS#6970)
by breuil＠craig.fr 14 Jun '13

14 Jun '13

Hi, i'm also experiencing slapd deadlocks/lockups when using memberOf & autogroup, w/ 2.4.31. Both modules/overlays seem to step on each other's toes when updating an entry. Not 100% sure if it's the same issue as the OP was experiencing though. My config is the following : - i have a ou=people branch with inetOrgPerson objects, each one having an organization attr. - i have a ou=groups branch with groupOfNames objects, each populated by autogroup by using a labeledURI doing a filter on the organization attr (among other conditions) of the inetOrgPerson objects. - and finally, i have memberOf overlay that updates the inetOrgPerson objects with the final groups membership. When modifiying the organization attribute of an inetOrgPerson (and thus triggering an update of groups & membership at the same time), slapd deadlocks. It happens both if the inetOrgPerson gets out of a group, or is now a new member of a group (only showing the tail of the debug log, but i can provide it all): 51bb233b oc_check_required entry (uid=person,ou=people,dc=myorg,dc=fr), objectClass "inetOrgPerson" 51bb233b oc_check_allowed type "cn" 51bb233b oc_check_allowed type "structuralObjectClass" 51bb233b oc_check_allowed type "entryUUID" 51bb233b oc_check_allowed type "creatorsName" 51bb233b oc_check_allowed type "createTimestamp" 51bb233b oc_check_allowed type "objectClass" 51bb233b oc_check_allowed type "uid" 51bb233b oc_check_allowed type "givenName" 51bb233b oc_check_allowed type "sn" 51bb233b oc_check_allowed type "userPassword" 51bb233b oc_check_allowed type "title" 51bb233b oc_check_allowed type "employeeType" 51bb233b oc_check_allowed type "roomNumber" 51bb233b oc_check_allowed type "mail" 51bb233b oc_check_allowed type "telephoneNumber" 51bb233b oc_check_allowed type "memberOf" 51bb233b oc_check_allowed type "o" 51bb233b oc_check_allowed type "entryCSN" 51bb233b oc_check_allowed type "modifyTimestamp" 51bb233b oc_check_allowed type "modifiersName" 51bb233b => entry_encode(0x00000006): 51bb233b <= entry_encode(0x00000006): At that point, there are three active threads in gdb: ^C Program received signal SIGINT, Interrupt. 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) info thread Id Target Id Frame 3 Thread 0x7ffff0f53700 (LWP 16492) 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 2 Thread 0x7ffff1754700 (LWP 16491) 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 * 1 Thread 0x7ffff7ebb700 (LWP 16490) 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 thread 1 & 2 seem okay... (gdb) bt #0 0x00007ffff5c67e75 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff7f0fca9 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2930 #2 0x00007ffff7ef687c in main (argc=<optimized out>, argv=<optimized out>) at ../../../../servers/slapd/main.c:1012 (gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff1754700 (LWP 16491))] #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff59b10d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7f0d721 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2540 #2 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () but thread 3 seems to lock with himself, maybe trying to modify the same entry via autogroup & memberof at the same time ? (gdb) thread 3 [Switching to thread 3 (Thread 0x7ffff0f53700 (LWP 16492))] #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x00007ffff5c6b2d4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff74fe9ab in __db_pthread_mutex_lock () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #2 0x00007ffff758d5ca in __lock_get_internal () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #3 0x00007ffff758e9b3 in __lock_vec () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #4 0x00007ffff758ef18 in __lock_vec_pp () from /usr/lib/x86_64-linux-gnu/libdb-5.1.so #5 0x00007ffff32234a0 in hdb_cache_entry_db_relock (bdb=bdb@entry=0x7ffff83226a0, txn=<optimized out>, ei=0x7ffff82db7b0, rw=rw@entry=1, tryOnly=tryOnly@entry=0, lock=lock@entry=0x7ffff0f4fc70) at cache.c:198 #6 0x00007ffff3223eb3 in hdb_cache_modify (bdb=bdb@entry=0x7ffff83226a0, e=e@entry=0x7ffff85045c8, newAttrs=0x7ffff8517f48, txn=<optimized out>, lock=lock@entry=0x7ffff0f4fc70) at cache.c:1231 #7 0x00007ffff321255a in hdb_modify (op=0x7ffff0f503b0, rs=0x7ffff0f501d0) at modify.c:711 #8 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f503b0, rs=0x7ffff0f501d0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #9 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f503b0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #10 0x00007ffff29dabb9 in memberof_value_modify (op=op@entry=0x7ffff0f50d40, ndn=<optimized out>, ad=0x7ffff82d3420, old_dn=old_dn@entry=0x0, old_ndn=old_ndn@entry=0x0, new_dn=new_dn@entry=0x7ffff0f50d68, new_ndn=new_ndn@entry=0x7ffff0f50d78) at ../../../../../servers/slapd/overlays/memberof.c:411 #11 0x00007ffff29db548 in memberof_res_modify (op=0x7ffff0f50d40, rs=<optimized out>) at ../../../../../servers/slapd/overlays/memberof.c:1457 #12 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:507 #13 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff0f50d40, rs=rs@entry=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:582 #14 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at ../../../../servers/slapd/result.c:860 #15 0x00007ffff3211e67 in hdb_modify (op=0x7ffff0f50d40, rs=0x7ffff0f50cd0) at modify.c:749 #16 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50d40, rs=0x7ffff0f50cd0, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #17 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50d40, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #18 0x00007ffff2be449f in autogroup_add_member_to_group (op=op@entry=0x7ffff82d9ab0, dn=dn@entry=0x7ffff82d9ad8, ndn=ndn@entry=0x7ffff82d9ae8, age=age@entry=0x7ffff82f8ed0) at autogroup.c:146 #19 0x00007ffff2be6aa2 in autogroup_response (op=0x7ffff82d9ab0, rs=<optimized out>) at autogroup.c:1302 #20 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #21 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #22 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82d9ab0, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #23 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #24 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at modify.c:749 #25 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d9ab0, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #26 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d9ab0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #27 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #28 0x00007ffff7f2c42d in do_modify (op=0x7ffff82d9ab0, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #29 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82d9ab0) at ../../../../servers/slapd/connection.c:1150 #30 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #31 0x00007ffff7a73ff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #32 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #33 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #34 0x0000000000000000 in ?? () If i examine the three hdb_modify() calls in that trace, the one in #7 and the one in #24 try to work on the same entry (dummy value is the modified inetOrgPerson), and the one in #15 modifies the groupOfNames from which the inetOrgPerson is a new member. I suppose it shouldn't happen... -- Landry Breuil Mouton a 5 pattes du CRAIG

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by h.b.furuseth＠usit.uio.no 13 Jun '13

13 Jun '13

Pushed to master, along with the same change to autogroup_member_search_modify_cb(). -- Hallvard

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 13 Jun '13

13 Jun '13

With help from hbf on #openldap on irc, managed to track this down to autogroup.c:autogroup_member_search_cb(). https://github.com/benegon/openldap/blob/master/contrib/slapd-modules/autog… In my usecase with labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) agf->agf_anlist is NULL since no attributes were specified, and the else branch is taken. In that branch, the e_name & e_nname from rs->sr_entry are assigned to lvals[0] & lnvals[0], and those two structs are local to the else branch. Later on, they assigned to vals & nvals, but when you get out of the else branch they're not in the scope anymore -> mod.sm_values & mod.sm_nvalues potentially get garbage. Declaring lvals & lnvals arrays outside of the branch (ie at the same spot as vals & nvals) fixes the assert for me, tested on debian sid with rebuilt 2.4.31 packages, but the fix should probably be the same for git master. Inline patch fixing the issue (probably mangled in the output....) diff --git a/contrib/slapd-modules/autogroup/autogroup.c b/contrib/slapd-modules/autogroup/autogroup.c index 06e1407..091a42f 100644 --- a/contrib/slapd-modules/autogroup/autogroup.c +++ b/contrib/slapd-modules/autogroup/autogroup.c @@ -331,6 +331,7 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) const char *text = NULL; char textbuf[1024]; struct berval *vals, *nvals; + struct berval lvals[ 2 ], lnvals[ 2 ]; int numvals; Debug(LDAP_DEBUG_TRACE, "==> autogroup_member_search_cb <%s>\n", @@ -347,7 +348,6 @@ autogroup_member_search_cb( Operation *op, SlapReply *rs ) return 0; } } else { - struct berval lvals[ 2 ], lnvals[ 2 ]; lvals[ 0 ] = rs->sr_entry->e_name; BER_BVZERO( &lvals[ 1 ] ); lnvals[ 0 ] = rs->sr_entry->e_nname; -- Landry Breuil

1 0

(ITS#7624) Active Directory schema with OpenLdap
by suresh.raja＠vernal.is 13 Jun '13

13 Jun '13

Full_Name: Suresh raja Version: 2.4.35 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.124.116.202) I want to use my Active Directory User's, and Groups same as in OpenLDAP. Ist Possible means.. 1. Need step-by-step configuration in Windows Server 2008 R2 2. How can i modify OpenLDAP server schema with Active Directory schema 3. Can i Sync Active Directory and OpenLDAP(windows) 4. Even my AD Server was Down, the schema should be in OpenLDAP, and should be connect as locally... Thanks in Advance.. Regards, Suresh

1 0

(ITS#7623) P_SUBP page inn MDB dirty_list
by h.b.furuseth＠usit.uio.no 12 Jun '13

12 Jun '13

Full_Name: Hallvard B Furuseth Version: RE24 + mdb.master 2d0b362b6f2b1247eb693008a39efaf341f15e82 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard test043-delta-syncrepl crashes in RE24 + mdb.master + this patch. A sub-cursor sees a regular (non-sub) page which has P_SUB set, in dirty_list. The flag comes from the fake page in cursor_put. Patch: - Set P_FAKE flag for debugging, to see where the flag comes from. - assert(not P_SUB) in page_get. - valloc pages so we can see from the page address that it is a regular page. --- libraries/liblmdb/mdb.c +++ libraries/liblmdb/mdb.c @@ -59,2 +59,3 @@ #include <unistd.h> +#include <malloc.h> @@ -582,2 +583,3 @@ typedef struct MDB_page { #define P_SUBP 0x40 /**< for #MDB_DUPSORT sub-pages */ +#define P_FAKE 0x80 /**< fake page */ /** @} */ @@ -1271,3 +1273,3 @@ mdb_page_malloc(MDB_cursor *mc, unsigned num) } - if ((ret = malloc(sz)) != NULL) { + if ((ret = valloc(sz)) != NULL) { VGMEMP_ALLOC(env, ret, sz); @@ -2478,2 +2480,3 @@ mdb_txn_commit(MDB_txn *txn) dp = txn->mt_u.dirty_list[i].mptr; + assert(!(dp->mp_flags & P_SUBP)); if (dp->mp_pgno != next) { @@ -4069,2 +4072,3 @@ mdb_page_get(MDB_txn *txn, pgno_t pgno, MDB_page **ret, int *lvl) p = dl[x].mptr; + /* assert(!(p->mp_flags & P_SUBP)); */ goto done; @@ -5164,3 +5168,3 @@ more: fp->mp_pgno = mc->mc_pg[mc->mc_top]->mp_pgno; - fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP; + fp->mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE; fp->mp_lower = PAGEHDRSZ; Backtrace: #4 mdb_page_get (txn=0x7f7d70104970, pgno=36, ret=0x7f7d70106e30, lvl=0x0) at ./../../../libraries/liblmdb/mdb.c:4072 p = 0x7f7d70118000 *p = {mp_p.p_pgno = 0x24, mp_pad = 0x7000, mp_flags = P_LEAF|P_DIRTY|P_SUBP|P_FAKE, mp_pb.pb = {pb_lower = 0x3c, pb_upper = 0x87e}, ...} #5 mdb_page_search (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, flags=0) at ./../../../libraries/liblmdb/mdb.c:4264 #6 mdb_cursor_set (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, data=0x7f7d7b2fbf80, op=MDB_SET, exactp=0x7f7d7b2fbf94) at ./../../../libraries/liblmdb/mdb.c:4690 #7 mdb_cursor_put (mc=0x7f7d70106de8, key=0x7f7d7b2fe6f0, data=0x7f7d7b2fe5a0, flags=16) at ./../../../libraries/liblmdb/mdb.c:5107 #8 mdb_cursor_put (mc=0x7f7d70106c60, key=0x7f7d7b2fe700, data=0x7f7d7b2fe6f0, flags=38) at ./../../../libraries/liblmdb/mdb.c:5413 #9 mdb_dn2id_add (op=0x7f7d7b2fec70, mcp=0x7f7d70106c60, mcd=0x7f7d70106c60, pid=1, nsubs=1, upsub=1, e=0x1109f98) at dn2id.c:141 #10 mdb_add (op=0x7f7d7b2fec70, rs=0x7f7d7b2fec00) at add.c:341 #11 overlay_op_walk (op=0x7f7d7b2fec70, rs=0x7f7d7b2fec00, which=op_add, oi=0x10bff00, on=0x0) at backover.c:671 #12 over_op_func (op=0x7f7d7b2fec70, rs, which) at backover.c:723 #13 over_op_add (op, rs) at backover.c:774 #14 accesslog_response (op, rs) at accesslog.c:1835 #15 over_back_response (op=0x7f7d700008f0, rs=0x7f7d7b300920) at backover.c:237 #16 slap_response_play (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:491 #17 send_ldap_response (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:566 #18 slap_send_ldap_result (op=0x7f7d700008f0, rs=0x7f7d7b300920) at result.c:844 #19 mdb_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:655 #20 overlay_op_walk (op=0x7f7d700008f0, rs=0x7f7d7b300920, which=op_modify, oi=0x10c0d50, on=0x0) at backover.c:671 #21 over_op_func (op=0x7f7d700008f0, rs, which) at backover.c:723 #22 over_op_modify (op, rs) at backover.c:762 #23 fe_op_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:303 #24 do_modify (op=0x7f7d700008f0, rs=0x7f7d7b300920) at modify.c:177 #25 connection_operation (ctx=0x7f7d7b300a70, arg_v=0x7f7d700008f0) at connection.c:1155 #26 connection_read_thread (ctx=0x7f7d7b300a70, argv) at connection.c:1291 #27 ldap_int_thread_pool_wrapper (xpool=0x106b320) at tpool.c:688

1 0

Fwd: RE: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 12 Jun '13

12 Jun '13

Fix verified. -------- Original Message -------- Subject: RE: (ITS#7577) hdb and mdb derefere aliases differently Date: Wed, 12 Jun 2013 09:49:16 +0000 From: <Juergen.Sprenger(a)swisscom.com> To: <hyc(a)symas.com> I've checked with openldap-HEAD-95241fa.tar.gz, and it looks very good now. Identical results and very good performance. Looks like the cause was Gentoo ebuild. Done everything manually and no problems anymore. Juergen Sprenger -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, June 06, 2013 8:05 PM To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently Juergen.Sprenger(a)swisscom.com wrote: > File is transferred, name is mdb-test-juergen.tar.gz I've tested your data+config using both git master and RE24 and both give identical results for mdb and hdb. Seems something is wrong in your build. > > Juergen Sprenger > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 05, 2013 5:24 PM > To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH > Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently > > Juergen.Sprenger(a)swisscom.com wrote: >> Please use this public key: > > OK, you should be able to ssh/scp to juergen(a)ada.openldap.org now. >> >> ssh-dss AAAAB3NzaC1kc3MAAAEBANJd7abNzD+Ejrg33Vbl8TZm6hMpI8Y02XnwfhP6CMy6w2IVjyvMsuuLp1ioJvIvgVFSCwp6lO1FnbxNTzKyhcY+f2Apo7DDQtT+faZkhPRaTwG+hht5ZsxDAEPQVuGxk9jVzLOK8D4hqTs43P5zKQLmAtqnTompWwtmNH8qfHSiNRlr6lmbMQigWfGoRqJ6rdyRulfA1tYo4yRsprM5OA0E6tzBukMPtCNerXDjI8C1M0IopTVfcbqaDsO9Q66UntAIonI5sESEfTd6v8dUTb4Z2ZcanMVZpjlqKWdr/MCYBuCXR2oiDiens92S2M3U9zLtcW1tTAO+sWdcJvqeugUAAAAVAOtW0p5t0Hme1wsKmG6DpDyqkp5rAAABAFyTRnAkwT9DM7BxyMOefJtY8rhP4RylINbJqoJ2H36OiYFoblk9G0Si1qMhKvLBceoaqswSIFOaIpe0vGWydlInGuJOEZxKCuhbYT+oDGRfOZzLU4668HHeK9aoBHoo5xFb/YWDQVi0+XoQDX+CpCcauthknISuCFcWqpALwrTqj9MRL3wan5oUOzRyiQXmyCwvRgsxt4Ee42Za+ZXnqP0wj255OOPy4btI82Njhx/fPJbUNA1uIE4TnO6tMkeGwZ2T/io4K2Wrmq0anigEfTf4WJX8og0PDajI4htcwOCrzWTHrqDtmFGRii4uSAMjigMVg6rt7b7IfoMYN7UCG7sAAAEAKDivKfQjbvgglMoz5vhZs95EOSGm7R0rItfCQjUHcGtYjDagGsLRDXQn0DXLUxBsbOkiymouNl1d5x0+DLhKg8IDz+RbGCTJ6CJnCbu7OQanXVwTWpPBAL7mjA8Z0sts6weuXXLVZpbgdh8RBS11pH1eW/CXgdL05mFexkgMQ1i5V6L+KgEl+X3KtbRTTYBh0VCUJN2hRjMRCqzXbp6yyq6s+pzcCGBKymiVds! C! > Q5MKlfAI87 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+kLFaC5QaGex > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+QU > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+9enlA3N7W4w > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+7g > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+oqUDTaGa5Yv > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+y4 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+jNA== > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+dsa-key-200 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+71 > 2IcWxBAngy9by2ZwpHcCWjKibUTn+EaBz6TKoeKOFaeJU5g2DwalLnTe01+012 >> >> Juergen Sprenger >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Thursday, May 30, 2013 3:03 PM >> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >> >> Juergen.Sprenger(a)swisscom.com wrote: >>> Sorry, company mail gateway removed the attached file. >>> >>> Where can I upload the mentioned archive? >> >> Send me an SSH public key and I'll set up an account on ada.openldap.org for you. >> >>> >>> Juergen Sprenger >>> >>> -----Original Message----- >>> From: Howard Chu [mailto:hyc@symas.com] >>> Sent: Wednesday, May 29, 2013 4:22 PM >>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>> >>> Juergen.Sprenger(a)swisscom.com wrote: >>>> The following file(s) has been removed because it violated the Swisscom security policy: >>>> >>>> ldap-hdb.sh >>>> ldap-mdb.sh >>>> >>>> >>>> Sorry, still can't get it working. >>>> >>>> Attached You will find my setup as a tarfile: >>> >>> There was no attachment on your email. >>>> >>>> mdb-test/ root/mdbtest.ldif # testdata >>>> mdb-test/ root/ldap-hdb.sh # script to switch config to hdb >>>> mdb-test/ root/ldap-mdb.sh # script to switch config to mdb >>>> >>>> mdb-test/etc/openldap/ # complete directory, but keys and certs removed >>>> mdb-test/etc/openldap/slapd.conf.hdb # slapd.conf using Berkeley DB >>>> mdb-test/etc/openldap/slapd.conf.mdb # slapd.conf using mdb >>>> >>>> mdb-test/etc/ldap.conf >>>> mdb-test/etc/ldap.conf.sudo link to >>>> mdb-test/etc/openldap/ldap.conf.sudo >>>> >>>> Juergen Sprenger >>>> >>>> -----Original Message----- >>>> From: Howard Chu [mailto:hyc@symas.com] >>>> Sent: Friday, May 17, 2013 6:24 PM >>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH >>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>> >>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>> Checked out 201ddbe3e4d8eb39830b96eefa559900952bc022, compiled, installed. >>>>> >>>>> # md5sum openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> 30f4e29eb7b4d0348f0e7ef100d0ba63 >>>>> openldap-2.4.35/servers/slapd/back-mdb/search.c >>>>> >>>>> But I still get different results: >>>> >>>> OK, try once more, commit a8c1438688f74081257d2aaba4e12814b9c8668f >>>> >>>>> >>>>> ## mdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> (result is empty) >>>>> >>>>> May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36262 (IP=0.0.0.0:389) May 17 14:30:54 openldap-dev >>>>> slapd[21001]: conn=1007 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=0 RESULT tag=97 err=0 text= May 17 14:30:54 openldap-dev slapd[21001]: conn=1007 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:30:57 openldap-dev slapd[21001]: conn=1007 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=0 text= May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 op=2 UNBIND May 17 14:30:57 openldap-dev >>>>> slapd[21001]: conn=1007 fd=13 closed >>>>> >>>>> ## hdb ## >>>>> # ldapsearch -xLLL -b ou=account,dc=its,dc=scom -s sub -D cn=itsAgent,ou=customerAgent,dc=scom -w ****** '(&(objectClass=posixAccount)(uid=tgdspju1))' >>>>> dn: uid=tgdspju1,ou=Person,dc=its,dc=scom >>>>> ... >>>>> >>>>> May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 fd=13 ACCEPT >>>>> from >>>>> IP=127.0.0.1:36267 (IP=0.0.0.0:389) May 17 14:33:06 openldap-dev >>>>> slapd[21089]: conn=1001 op=0 BIND >>>>> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 May 17 >>>>> 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=0 RESULT tag=97 err=0 text= May 17 14:33:06 openldap-dev slapd[21089]: conn=1001 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=2 deref=3 filter="(&(objectClass=posixAccount)(uid=tgdspju1))" >>>>> May 17 14:33:07 openldap-dev slapd[21089]: conn=1001 op=1 SEARCH >>>>> RESULT tag=101 err=0 nentries=1 text= May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 op=2 UNBIND May 17 14:33:07 openldap-dev >>>>> slapd[21089]: conn=1001 fd=13 closed >>>>> >>>>> Juergen Sprenger >>>>> >>>>> -----Original Message----- >>>>> From: Howard Chu [mailto:hyc@symas.com] >>>>> Sent: Friday, May 17, 2013 1:34 PM >>>>> To: Sprenger Jürgen, ITS-OUS-OP-IFM-MIR-UCH; >>>>> openldap-its(a)openldap.org >>>>> Subject: Re: (ITS#7577) hdb and mdb derefere aliases differently >>>>> >>>>> Juergen.Sprenger(a)swisscom.com wrote: >>>>>> tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 >>>>> >>>>> There was a followup commit also needed. >>>>> 201ddbe3e4d8eb39830b96eefa559900952bc022 >>>>> >>>>> Just get the latest. >>>>> >>>> >>>> >>> >>> >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7622) LMDB cursor _NEXT/_PREV
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Using MDB_PREV on an initialized empty DB (that was non-empty when the cursor was initialized) returns SUCCESS when it should return NOTFOUND. Bug introduced by commit 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 Fixed in c2cac4588a40480c020d320b544bc5f8e72adb11

1 0

(ITS#7621) LMDB mdb_stat() bug
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.32+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc In a0993354a603a970889ad5c160c289ecca316f81 txn_begin() was changed to defer reading a DB's root node until it was actually referenced, instead of always reading all DB root nodes at the beginning of a txn. Other ops already handled this case but mdb_stat() didn't, so if mdb_stat() was called for a named DB in a fresh txn that hadn't yet referenced any named DBs, it just returned zeroes in the stat structure. (The mainDB root node is always read so there was no issue there.) Fixed in bcb67dd22f06a7f7c85350bc548c50ccfc27dbaa

1 0

(ITS#7620) LMDB overflow page management
by hyc＠OpenLDAP.org 12 Jun '13

12 Jun '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Pages that are dirtied get pulled out of the freeDB. If they are freed in the same txn they should be returned to their original place in the freeDB instead of joining the current txn's list of freed pages. This is particularly important for overflow pages because otherwise we can consume a lot of overflow pages rapidly in some cases. Commit e7f6767ea815fe0ada1f95037dfdec176ec4d5bb in mdb.master is for this issue, but it needs additional fixes.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs