- openldap-bugs - openldap.org

(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

(ITS#7619) Unable to start OpenLDAP 2.4.35 with Oracle 10g
by lokesh.kumar1＠thomsonreuters.com 11 Jun '13

11 Jun '13

Full_Name: Lokesh Kumar Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.231.6.66) I am unable to start the LDAP on my linux machine with openldap-2.4.35 using back-sql with Oracle 10g as my datasource. I am able to connect to the Oracle database, but it fails to load the data on to the LDAP object schema. I am using the default sample data for Oracle RDBMS and the schema files which comes with the installable. Can you please look into this and let me know if I am missing something here? My sladp.config file looks like this: include <InstallFolder>/etc/openldap/schema/core.schema include <InstallFolder>/etc/openldap/schema/cosine.schema include <InstallFolder>/etc/openldap/schema/inetorgperson.schema pidfile <InstallFolder>/var/run/slapd.pid argsfile <InstallFolder>/var/run/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw secret dbname OracleODBC-10g dbuser username dbpasswd password subtree_cond "UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?))" insentry_stmt "INSERT INTO ldap_entries (id,dn,oc_map_id,parent,keyval) VALUES (ldap_entry_ids.nextval,?,?,?,?)" upper_func UPPER has_ldapinfo_dn_ru no The startup console output looks something like this: . . . 51b70f81 backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" 51b70f81 objectClass: id="1" name="inetOrgPerson" keytbl="persons" keycol="id" create_proc="call create_person(?)" create_keyval="" delete_proc="call delete_person(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" 51b70f81 create_proc="call create_person(?)" 51b70f81 delete_proc="call delete_person(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="2" name="document" keytbl="documents" keycol="id" create_proc="call create_document(?)" create_keyval="" delete_proc="call delete_document(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" 51b70f81 create_proc="call create_document(?)" 51b70f81 delete_proc="call delete_document(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 objectClass: id="3" name="organization" keytbl="institutes" keycol="id" create_proc="call create_org(?)" create_keyval="" delete_proc="call delete_org(?)" expect_return="0"create_hint="" 51b70f81 backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" 51b70f81 create_proc="call create_org(?)" 51b70f81 delete_proc="call delete_org(?)" 51b70f81 expect_return: add=0, del=0; attributes: 51b70f81 backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" 51b70f81 backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 backsql_oc_get_attr_mapping(): error executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id=2 51b70f81 Return code: -1 51b70f81 <==backsql_load_schema_map() 51b70f81 backsql_db_open(): schema mapping failed, exiting 51b70f81 backend_startup_one (type=sql, suffix="dc=example,dc=com"): bi_db_open failed! (1) 51b70f81 slapd shutdown: initiated . . .

1 0

Re: (ITS#7618) pcache overlay does not allow the use of NOT ("!") in templates
by hyc＠symas.com 10 Jun '13

10 Jun '13

amoneger(a)cisco.com wrote: > Full_Name: Alex Moneger > Version: 2.4.35 > OS: centos 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > Hi, > > When trying to define a template which query contains a '!', slapd complains > about a syntax issue in the config file and refuses to start. This is by design. Read the Proxy Cache design paper. http://www.openldap.org/pub/ -- -- 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#7618) pcache overlay does not allow the use of NOT ("!") in templates
by amoneger＠cisco.com 10 Jun '13

10 Jun '13

Full_Name: Alex Moneger Version: 2.4.35 OS: centos 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) Hi, When trying to define a template which query contains a '!', slapd complains about a syntax issue in the config file and refuses to start. This is because there seems to be a missing check for '!' in template_attrs() in pcache.c, so '!' char is passed to slap_bv2ad() which correctly errors out. i.e: May 27 20:53:53 centos63 slapd[44623]: line 71 (pcacheTemplate (&(gidNumber=)(objectClass=)(cn=*)(&(gidNumber=*)(!(gidNumber=)))) 0 3600) May 27 20:53:53 centos63 slapd[44623]: /etc/openldap/pcache.conf: line 71: unable to parse template: AttributeDescription contains inappropriate characters. I believe the use of "not" should be allowed in cacheable templates, since they appear to be a valid search filter definition as per RFC 2254. The fix is very easy. I cannot upload the diff to the ftp server, since it errors with space related errors when uploading the file. Content of the diff: --- openldap-2.4.35/servers/slapd/overlays/pcache.c 2013-03-28 15:41:51.000000000 +0000 +++ openldap-2.4.35/servers/slapd/overlays/pcache.c0 2013-05-27 21:27:20.847919253 +0100 @@ -523,7 +523,7 @@ allop = an_find( attrs, slap_bv_all_operational_attrs ); for (;;) { - while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' ) p1++; + while ( *p1 == '(' || *p1 == '&' || *p1 == '|' || *p1 == ')' || *p1 == '!') p1++; p2 = strchr( p1, '=' ); if ( !p2 ) break; It can be applied this way if you consider this of any use: cd "${HOME}"/openldap-2.4.35 patch -p0 --verbose < ~/pcache.p0 Cheers, Alex

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by quanah＠zimbra.com 07 Jun '13

07 Jun '13

--On Friday, June 07, 2013 8:34 AM +0000 lily.zhang(a)emc.com wrote: > Hi > > Thank you for looking at it. > > A dump is generated when user login via LDAP account. > [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 OpenLDAP 2.4.16 is years old. Please confirm you see the issue using a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Hi Thank you for looking at it. A dump is generated when user login via LDAP account. 1. This is the code call in my code: NAVsint32 status = ldap_unbind_s( _ldapHandle ); 2. Below is the call stack and the content of _ldapHandle(dap 0x1b4b3d58). From the call stack, it seems call stack corrupts in function call ldap_unbind_s(). 3. Issue can be solved by restarting the process, but issue can reproduced once in while in the user's environment. 4. Please let me if you need other material about this issue. 0:112:x86> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213] 1fd5c2c4 0cafd615 eedd5f4e 1fd5c35c 1fd5c4ec SecurityProvider!ecom::caprovider::OpenLDAPLogin::_disconnect+0x1e [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 1344] 1fd5c2e0 0caf98dd eedd5956 1fd5c324 1fd5c324 SecurityProvider!ecom::caprovider::OpenLDAPLogin::~OpenLDAPLogin+0x35 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldaplogin.cpp @ 198] 1fd5c4f8 0cada203 1fd5c63c 1fd5c64c 1fd5c5d4 SecurityProvider!ecom::caprovider::OpenLDAPAuthLoginContext::login+0x37d [z:\naviservices\providers\securityprovider\commonauthenticationprovider\openldapauthlogincontext.cpp @ 159] 1fd5c604 0cabd419 1fd5c63c 1fd5c64c 1fd5c724 SecurityProvider!ecom::caprovider::NaviCA_LDAPFeature::AuthenticateUser+0x203 [z:\naviservices\providers\securityprovider\commonauthenticationprovider\generated\mynavica_ldapfeature.cpp @ 1415] 1fd5c634 0ca668db 4aab2ba0 00000006 00000007 SecurityProvider!NaviSec_SecurityAdmin::AuthenticateCAUser+0x69 [z:\naviservices\providers\securityprovider\generated\navisec_securityadminmethods.cpp @ 4211] 1fd5c734 0ca63e3b 1fd5c85c 4aab2ba0 00000006 SecurityProvider!NaviSec_Authentication::CanUserAccess+0x1bb [z:\naviservices\providers\securityprovider\generated\navisec_authenticationmethods.cpp @ 154] 0:112:x86> dt -r8 ldap 0x1b4b3d58 Openldap!ldap +0x000 ld_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcaf60 sockbuf_io +0x000 sbi_setup : 0x0cd2f700 int Openldap!sb_stream_setup+0 +0x004 sbi_remove : (null) +0x008 sbi_ctrl : 0x0cd2f740 int Openldap!sb_stream_ctrl+0 +0x00c sbi_read : 0x0cd2f5b0 long Openldap!sb_stream_read+0 +0x010 sbi_write : 0x0cd2f620 long Openldap!sb_stream_write+0 +0x014 sbi_close : 0x0cd2f690 int Openldap!sb_stream_close+0 +0x00c sbiod_pvt : (null) +0x010 sbiod_next : 0x390b8950 sockbuf_io_desc +0x000 sbiod_level : 10 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x000 lbo_valid : 3 +0x002 lbo_options : 0 +0x004 lbo_debug : 0 +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x000 sb_opts : lber_options +0x008 sb_iod : 0x390c45b0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdc8b04 sockbuf_io +0x000 sbi_setup : 0x0cd264c0 int Openldap!tlso_sb_setup+0 +0x004 sbi_remove : 0x0cd26550 int Openldap!tlso_sb_remove+0 +0x008 sbi_ctrl : 0x0cd26630 int Openldap!tlso_sb_ctrl+0 +0x00c sbi_read : 0x0cd26700 long Openldap!tlso_sb_read+0 +0x010 sbi_write : 0x0cd267e0 long Openldap!tlso_sb_write+0 +0x014 sbi_close : 0x0cd265d0 int Openldap!tlso_sb_close+0 +0x00c sbiod_pvt : 0x4aaaf310 +0x010 sbiod_next : 0x390c13d0 sockbuf_io_desc +0x000 sbiod_level : 20 +0x004 sbiod_sb : 0x390b7c10 sockbuf +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x00c sbiod_pvt : 0x4aab1d40 +0x010 sbiod_next : 0x390b51d0 sockbuf_io_desc +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x008 sbiod_io : 0x0cdcb4f4 sockbuf_io +0x000 sbi_setup : 0x0cd2fca0 int Openldap!sb_debug_setup+0 +0x004 sbi_remove : 0x0cd2fd20 int Openldap!sb_debug_remove+0 +0x008 sbi_ctrl : 0x0cd2fd80 int Openldap!sb_debug_ctrl+0 +0x00c sbi_read : 0x0cd2fdc0 long Openldap!sb_debug_read+0 +0x010 sbi_write : 0x0cd2fea0 long Openldap!sb_debug_write+0 +0x014 sbi_close : (null) +0x00c sbiod_pvt : 0x4aab2c30 +0x010 sbiod_next : (null) +0x00c sb_fd : -1 +0x010 sb_max_incoming : 0 +0x014 sb_trans_needs_read : 0y0 +0x014 sb_trans_needs_write : 0y0 +0x004 ld_options : ldapoptions +0x000 ldo_valid : 2 +0x004 ldo_debug : 0 +0x008 ldo_tm_api : timeval +0x000 tv_sec : -1 +0x004 tv_usec : 0 +0x010 ldo_tm_net : timeval +0x000 tv_sec : 30 +0x004 tv_usec : 0 +0x018 ldo_version : 3 +0x01c ldo_deref : 0 +0x020 ldo_timelimit : 0 +0x024 ldo_sizelimit : 0 +0x028 ldo_tls_ctx : (null) +0x02c ldo_tls_connect_cb : (null) +0x030 ldo_tls_connect_arg : (null) +0x034 ldo_tls_info : ldaptls +0x000 lt_certfile : (null) +0x004 lt_keyfile : (null) +0x008 lt_dhfile : (null) +0x00c lt_cacertfile : (null) +0x010 lt_cacertdir : (null) +0x014 lt_ciphersuite : (null) +0x018 lt_crlfile : (null) +0x01c lt_randfile : (null) +0x020 lt_protocol_min : 0 +0x058 ldo_tls_mode : 0 +0x05c ldo_tls_require_cert : 0 +0x060 ldo_tls_impl : 0 +0x064 ldo_tls_crlcheck : 0 +0x068 ldo_defludp : (null) +0x06c ldo_defport : 389 +0x070 ldo_defbase : (null) +0x074 ldo_defbinddn : (null) +0x078 ldo_def_sasl_mech : (null) +0x07c ldo_def_sasl_realm : (null) +0x080 ldo_def_sasl_authcid : (null) +0x084 ldo_def_sasl_authzid : (null) +0x088 ldo_sasl_secprops : sasl_security_properties +0x000 min_ssf : 0 +0x004 max_ssf : 0x7fffffff +0x008 maxbufsize : 0xffffff +0x00c security_flags : 0x11 +0x010 property_names : (null) +0x014 property_values : (null) +0x0a0 ldo_refhoplimit : 5 +0x0a4 ldo_sctrls : (null) +0x0a8 ldo_cctrls : (null) +0x0ac ldo_rebind_proc : (null) +0x0b0 ldo_rebind_params : (null) +0x0b4 ldo_nextref_proc : (null) +0x0b8 ldo_nextref_params : (null) +0x0bc ldo_urllist_proc : (null) +0x0c0 ldo_urllist_params : (null) +0x0c4 ldo_conn_cbs : (null) +0x0c8 ldo_booleans : 0 +0x0d0 ld_lberoptions : 1 +0x0d4 ld_errno : 0 +0x0d8 ld_error : (null) +0x0dc ld_matched : (null) +0x0e0 ld_referrals : (null) +0x0e4 ld_msgid : 4 +0x0e8 ld_requests : (null) +0x0ec ld_responses : (null) +0x0f0 ld_nabandoned : 0 +0x0f4 ld_abandoned : (null) +0x0f8 ld_cache : (null) +0x0fc ld_defconn : (null) +0x100 ld_conns : (null) +0x104 ld_selectinfo : (null) -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2013$BG/(B6$B7n(B7$BF|(B 16:19 To: Zhang, Lily (USD) Subject: Re: (ITS#7617) Stack issue Openldap!ldap_unbind_s *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#7617. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#7617) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7617) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=7617 Please remember to retain your issue tracking number (ITS#7617) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#7617) Stack issue Openldap!ldap_unbind_s
by lily.zhang＠emc.com 07 Jun '13

07 Jun '13

Full_Name: Zhang, Lily Version: 2.4.16 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.159.144.57) Here is the code we call ldap_unbind_s(). void OpenLDAPLogin::_disconnect() { if (_ldapHandle == NULL) { return; } // ldap_unbind_s will free up the space // allocated for the LDAP handle NAVsint32 status = ldap_unbind_s( _ldapHandle ); if (status != LDAP_SUCCESS) { return; } _ldapHandle = NULL; } Here is the call stack, eip become an invalid pointer. If the process was restarted, issue was disappeared, but it may be reproduced sometimes later. Please help me have a look that whether is a bug that fixed in the latest version. *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 1fd5c19c 0cb83b74 12ad21c8 1b291110 0cb839e8 0x56414e24 1fd5c1a8 0cb839e8 23fb4c18 23fa62f0 0cd41433 SecurityProvider!ri_cert_ctx_free+0x30 1fd5c1b4 0cd41433 1b291110 0cd4e533 1b291110 SecurityProvider!ri_cert_free+0x6d 1fd5c1bc 0cd4e533 1b291110 4173e2a8 00000000 Openldap!R_CERT_free+0x19 1fd5c1d0 0cd41a41 23fa62f0 4173e1d8 4173e1d8 Openldap!R_SSL_SESSION_free+0x9a 1fd5c1e8 0cd35e32 4173e1d8 0000002f 4173e1d8 Openldap!R_SSL_free+0x11e 1fd5c214 0cd265a7 00000168 4aaaf310 1fd5c238 Openldap!SSL_free+0xe2 1fd5c224 0cd2eefe 390c45b0 390b7c18 390c45b0 Openldap!tlso_sb_remove+0x57 [w:\thirdparty\openldap-2.4.16\libraries\libldap\tls_o.c @ 793] 1fd5c238 0cd2f3e6 390b7c10 0cdc8b04 00000014 Openldap!ber_sockbuf_remove_io+0x9e [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 230] 1fd5c250 0cd2eb03 390b7c10 1fd5c280 0cd272a8 Openldap!ber_int_sb_destroy+0x76 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 405] 1fd5c25c 0cd272a8 390b7c10 74834c39 00000000 Openldap!ber_sockbuf_free+0x53 [w:\thirdparty\openldap-2.4.16\libraries\liblber\sockbuf.c @ 75] 1fd5c280 0cd26f41 1b4b3d58 00000001 00000000 Openldap!ldap_ld_free+0x2f8 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 195] 1fd5c29c 0cd272e0 1b4b3d58 00000000 00000000 Openldap!ldap_unbind_ext+0x71 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 52] 1fd5c2b0 0cb019fe 1b4b3d58 1fd5c35c 48d8e868 Openldap!ldap_unbind_s+0x10 [w:\thirdparty\openldap-2.4.16\libraries\libldap\unbind.c @ 213]

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 05 Jun '13

05 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> If a cursor is at a clean subDB page, and its current item is deleted >>> by another cursor, then MDB_GET_CURRENT returns the deleted item. >> >> Fixed now in mdb.master. The subcursor on the clean page will be invalidated >> when the page is touched. > > MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) > since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the > patch below to the test program. OK, I've reverted that commit. > mdb.master output with patched test program: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. No longer asserts. Also, [0] was the wrong result here. Also fixed. > Branch mdb/its7594 output: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable > > That assert is OK since it's the test program asserting success. > > --- its7594.c > +++ its7594a.c > @@ -28,4 +28,6 @@ > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); > > if (argc < 2) { > @@ -42,8 +44,8 @@ > > E(mdb_cursor_del(mc, 0)); > - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); > - SHOW("m2/del"); /* Should output the same as... */ > - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); > - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ > + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); > + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ > + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); > + SHOW("m2/del"); /* ...and this should output the same. */ > > mdb_txn_abort(txn); > -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

Michael Ströder wrote: > hyc(a)symas.com wrote: >> I was considering returning LDAP_BUSY for this case, but it may make more >> sense to return a REFERRAL to the provider instead. (Although again, if we >> have two MMR servers pointed at each other starting at the same time, they >> would just refer to each other and clients would get nowhere until one of them >> finishes its refresh.) > > IMO referrals are harmful. > Just returning LDAP_BUSY seems best to me because if reliable HA is really > important for a deployment you have decent load-balancers in front of your > LDAP server which should do a proper health-check. Agreed. > Just a question: Is this database-specific? Maybe only one of several DBs is > in this initial syncrepl phase and access to others should simply work. Overlays are db-specific. -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by michael＠stroeder.com 05 Jun '13

05 Jun '13

This is a cryptographically signed message in MIME format. --------------ms020809020606000104080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > I was considering returning LDAP_BUSY for this case, but it may make mo= re=20 > sense to return a REFERRAL to the provider instead. (Although again, if= we=20 > have two MMR servers pointed at each other starting at the same time, t= hey=20 > would just refer to each other and clients would get nowhere until one = of them=20 > finishes its refresh.) IMO referrals are harmful. Just returning LDAP_BUSY seems best to me because if reliable HA is reall= y important for a deployment you have decent load-balancers in front of you= r LDAP server which should do a proper health-check. Just a question: Is this database-specific? Maybe only one of several DBs= is in this initial syncrepl phase and access to others should simply work. Ciao, Michael. --------------ms020809020606000104080607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA1MTgxNDAzWjAj BgkqhkiG9w0BCQQxFgQUiEZEhMlpWaio/7q/OgE6XehCSTswbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEA0dEsxfOK4N2Ee5bXv8bgeDj+DFV5pK4X YH8lJkCSkq9qberav4nqRGq7Ka50HZuIzMmWj2t6JR4Y/gIJfCZpSJ6fGtEMKXmuFmT9Kj8l IwlvnmoVyMnrQYVLXz/pnl1AG7vj0n00eYIe2ZlYYT2mVDT9RwBXe5T1UZoOvRmm4fy6AgSU wlNIuyClUgk/5z4jsYb8bf+abz2MWKwNA3Pv3mwB/pTUMdB90WmgfnKI1u0G5aBIsidLd7Ec aVMirzK3Ur7fNSj59/lQdnZixG2p37F+1ZkFXwtAFub5d01osWoCVePJJF16DUzJVgzZBv3Q wtcP0eJdkAwf3tBY4mkfJgAAAAAAAA== --------------ms020809020606000104080607--

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

hyc(a)OpenLDAP.org wrote: > 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 > > > We've discussed this on -devel a few times in the past. Sometimes it would be > desirable to prevent a consumer from answering client requests if it has just > started up and needs to perform an lengthy refresh. > > In prior discussions, there was a concern that in an MMR situation, two servers > coming up at the same time would deadlock waiting for each other. We can avoid > this problem by allowing any search request with a Sync control to proceed as > normal. Or, any search request with a Sync control and a non-empty, valid > cookie. > > Implementation can be done using an overlay hook. Note that syncrepl already > installs an overlay hook now for delta-mmr, this would just expand the scope of > that internal overlay. I was considering returning LDAP_BUSY for this case, but it may make more sense to return a REFERRAL to the provider instead. (Although again, if we have two MMR servers pointed at each other starting at the same time, they would just refer to each other and clients would get nowhere until one of them finishes its refresh.) -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠OpenLDAP.org 05 Jun '13

05 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 We've discussed this on -devel a few times in the past. Sometimes it would be desirable to prevent a consumer from answering client requests if it has just started up and needs to perform an lengthy refresh. In prior discussions, there was a concern that in an MMR situation, two servers coming up at the same time would deadlock waiting for each other. We can avoid this problem by allowing any search request with a Sync control to proceed as normal. Or, any search request with a Sync control and a non-empty, valid cookie. Implementation can be done using an overlay hook. Note that syncrepl already installs an overlay hook now for delta-mmr, this would just expand the scope of that internal overlay.

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Eric S. Raymond wrote: > You have drastically misunderstood what you saw. This isn't an error > in doclifter, it's a result of a basic ontological mismatch between > the source and target markups that doclifter tries to bridge across. > > There are no line breaks in DocBook's XML, structure-oriented world. > The closest thing to one ia special-purpose <sbr/> tag that is only valid > inside command synoposes. Thus there is no "line break" equivalent > that .br can be mapped to. Nor should there be; that is fundamentally > a presentation-level concept. > > Thus, one of either ignoring the .br or interpreting it as a paragraph > boundary is exactly what doclifter *should* be doing. This is not a > bug, it is correct behavior because those are the only alternatives > XML-DocBook supports. This is absolutely ludicrous. This is like saying "my language processor doesn't support the Addition operator, it only supports multiplcation or division. So when you write 'x+y' in your input a result of either 'x*y' or 'x/y' is *exactly* what it should be doing." The fact that your document language or tool only supports two alternatives doesn't make either one of them correct. If you hadn't caused me to waste this much time on this issue already it would be laughable. -- -- 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#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Eric S. Raymond wrote: > Howard Chu <hyc(a)symas.com>: >> OK, I ran Docbook 4.5 on the output from doclifter and I see it's >> complaining on one line of slapd.conf.5.xml. It appears doclifter is >> misinterpreting the .br request. Instead of inserting a line break >> it is either ignoring it completely or doing a paragraph break. >> >> I'm going to reject your submitted patch because it is not the >> minimal patch needed to fix the error, nor is the error actually in >> our manpage source, it is in the doclifter tool. > > You have drastically misunderstood what you saw. This isn't an error > in doclifter, it's a result of a basic ontological mismatch between > the source and target markups that doclifter tries to bridge across. > > There are no line breaks in DocBook's XML, structure-oriented world. > The closest thing to one ia special-purpose <sbr/> tag that is only valid > inside command synoposes. Thus there is no "line break" equivalent > that .br can be mapped to. Nor should there be; that is fundamentally > a presentation-level concept. A line-break may well be only a presentation-level concept, but it is also something that a document author explicitly chooses to insert. A tool (or markup language) that ignores an author's explicit wishes is a broken tool. > My patch adds the structural information required for doclifter to > get traction. The requirement for this is rare, and getting more so > as man page maintainers clean up their sources. Please be part of > that solution rather than part of the problem. Your solution is broken or unfit for the purpose if it cannot process simple and correct manpage source. -- -- 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#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 04 Jun '13

04 Jun '13

Howard Chu <hyc(a)symas.com>: > OK, I ran Docbook 4.5 on the output from doclifter and I see it's > complaining on one line of slapd.conf.5.xml. It appears doclifter is > misinterpreting the .br request. Instead of inserting a line break > it is either ignoring it completely or doing a paragraph break. > > I'm going to reject your submitted patch because it is not the > minimal patch needed to fix the error, nor is the error actually in > our manpage source, it is in the doclifter tool. You have drastically misunderstood what you saw. This isn't an error in doclifter, it's a result of a basic ontological mismatch between the source and target markups that doclifter tries to bridge across. There are no line breaks in DocBook's XML, structure-oriented world. The closest thing to one ia special-purpose <sbr/> tag that is only valid inside command synoposes. Thus there is no "line break" equivalent that .br can be mapped to. Nor should there be; that is fundamentally a presentation-level concept. Thus, one of either ignoring the .br or interpreting it as a paragraph boundary is exactly what doclifter *should* be doing. This is not a bug, it is correct behavior because those are the only alternatives XML-DocBook supports. doclifter has to deduce which interpretation is correct by applying certain parsing and pattern-matching rules. Usually it succeeds, but there are rare (single-digit-percentage) cases in which it fails. Yours is one. I repeat: the error is *not in the tool*. It's a result of attempting to deduce structure out of the troff tag soup that the tag soup does not intrinsically possess. After 11 years of development doclifter does a pretty heroic job of this, but a perfect one is not possible - there's too much chaos ot there. My patch adds the structural information required for doclifter to get traction. The requirement for this is rare, and getting more so as man page maintainers clean up their sources. Please be part of that solution rather than part of the problem. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Howard Chu wrote: > Eric S. Raymond wrote: >> Howard Chu <hyc(a)symas.com>: >>> For fear of opening up another can of worms, surely slapd.conf.5 is >>> not the only manpage that needs this patch? Other manpages in the >>> distro also use .nf/.fi and .RS/.RE. >>> >>> We need consistency in our source as well. >> >> Agreed. I have analogous patches for slapd-config.5 and slapo-constraint.5. >> Whatever other OpenLDAP pages are in stock Ubuntu are not throwing >> warnings. How would you like these submitted? >> > I just ran doclifter on all 3 of these man pages and the only warning I got > was about the ../Project file. Please tell me how to reproduce the original > error you're reporting because I'm not seeing it. > > Also, how do we fix it so that the content of ../Project is included as it > should be? > OK, I ran Docbook 4.5 on the output from doclifter and I see it's complaining on one line of slapd.conf.5.xml. It appears doclifter is misinterpreting the .br request. Instead of inserting a line break it is either ignoring it completely or doing a paragraph break. I'm going to reject your submitted patch because it is not the minimal patch needed to fix the error, nor is the error actually in our manpage source, it is in the doclifter tool. -- -- 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#7612) {CLEARTEXT} password scheme broken
by Kurt＠OpenLDAP.org 03 Jun '13

03 Jun '13

On Jun 3, 2013, at 1:08 PM, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > ...OTOH perhaps it's too late to change {cleartext} now if > it has an established useful meaning. Could introduce a new > scheme called {plaintext} or {raw} instead for this purpose. {CLEARTEXT} isn't an RFC 2307 hash scheme... it's a string used in configuration and command line cases to indicate that no RFC 2307 hash scheme is used, that is, the password is cleartext. In the code, IIRC, it's referred to as pseudo-scheme for this reason. The restrictions on clear text passwords that look like RFC 2307 hashed password exist because of the conflict between standard LDAPv3 behavior and RFC 2307 behavior. Adding some RFC 2307 plain-text hash scheme doesn't remove the conflict between standard LDAPv3 behavior RFC 2307 hashed passwords, so IMO the restriction should remain, at least by default. If such an option were introduced, the documentation should make clear that disabling the check can be problematic if ever stored hash passwords are to restored (on Bind) to LDAPv3 compliant LDAPv3 passwords over a period of time. -- Kurt

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 03 Jun '13

03 Jun '13

Howard Chu <hyc(a)symas.com>: > Hm. I use my own man2html http://highlandsun.com/hyc/man2html.c > which gives pretty good looking output for us. Really, if you're > developing a tool that claims to read troff input, it has to > actually do so. I mean, the point of tools such as this is to be > able to convert existing documents without modifying them, isn't it? There's a subtle difference between tools that translate purely at a presentation level and tools that do content analysis. A purely presentation-level translation such as your man2html is indeed less likely to be thrown by weird troff markup. And much of the time it will produce markup that doesn't look bad, especially on a relatively small collection of pages in a consistent house style. But there are things such a tool cannot do that become more important when you are translating a very large corpus of man pages with multiple authors - such as an entire Linux distribution's man page tree. Here is an example: the treatment of file paths in FILES sections. Some man-page authors mark them up as bold text. Some mark them up as italic. And some give them no highlight at all. A purely presentation-level translator will simply translate any font change from troff to HTML. In the resulting output, filenames will have three different visual signatures. Readers will thus have to work a little harder than they should to recognize filenames. A tool that does content analysis, on the other hand, can recognize presentation-level cliches that mean "this is a filename", such as a line in FILES beginning with .B or .I and containing a /, and map it to a DocBook <filename> pair. The DocBook stylesheet will then ensure that all filenames are visually marked in the *same* way in generated HTML, rather than three different ways. Now multiply this effect by all the different things that can be recognized by content - things like Unix error codes, program listings, command synopses, C function prototypes, references to other manual pages. The effect is a higher-quality and more visually uniform translation. The gain in quality increases with the diversity of the author population. For very large collections like an entire Linux distribution's man page tree it is quite significant. The tradeoff is that, while a presentation-level translator will cheerfully produce a visual garble from ill-formed troff, a tool with a real parser and a content analyzer will have a few more cases in which it just can't cope at all. Not *many* cases, mind you; in the decade I've been developing mine, perhaps 2-3%. But these are worth fixing anyway, because they're likely to break third-party man-page readers. Nothing but troff itself interprets troff perfectly. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by h.b.furuseth＠usit.uio.no 03 Jun '13

03 Jun '13

I wrote: > This does not imply that a scheme can't be used which simply > represents the passwords as-is, nor that slapd or slap tools have > any business stripping away such a {scheme} prefix. In particular > not when that's the only way to represent cleartext passwords > starting with "{letters}". ...OTOH perhaps it's too late to change {cleartext} now if it has an established useful meaning. Could introduce a new scheme called {plaintext} or {raw} instead for this purpose. -- Hallvard

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by h.b.furuseth＠usit.uio.no 03 Jun '13

03 Jun '13

On 2013-06-03 20:46, Kurt(a)OpenLDAP.org wrote: > Not a bug... > > Clear text passwords appear in userPassword without any RFC 2307 > scheme, as in > > userPassword: secret > > not: > > userPassword: {CLEARTEXT}secret That's backwards. userPassword values without a {scheme} prefix are cleartext passwords. Values with a {scheme} prefix use that scheme. This does not imply that a scheme can't be used which simply represents the passwords as-is, nor that slapd or slap tools have any business stripping away such a {scheme} prefix. In particular not when that's the only way to represent cleartext passwords starting with "{letters}". Though possibly this would mean slapd needs a tweak to how it represents non-prefixed passwords internally, if it currently uses "{cleartext}" to tell itself that. I have not looked yet. -- Hallvard

1 0

Re: (ITS#7612) {CLEARTEXT} password scheme broken
by Kurt＠OpenLDAP.org 03 Jun '13

03 Jun '13

On May 31, 2013, at 2:38 AM, wferi(a)niif.hu wrote: > Full_Name: Ferenc Wágner > Version: 2.4.31 > OS: Debian GNU/Linux squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.101.52.7) > > > I'm trying to store the hypothetical password "{SSHA}" in cleartext, but > slappasswd refuses to help: > > $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} > Password verification failed. > > On #openldap hbf suggested that I file an ITS ("work" in the following means > allowing binding): > > hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: > {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret > can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be > valid. > > As I agree with him, here it is. > Not a bug... Clear text passwords appear in userPassword without any RFC 2307 scheme, as in userPassword: secret not: userPassword: {CLEARTEXT}secret A cleartext password of {SSHA} is disallowed for what should be obvious reasons. -- Kurt

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 03 Jun '13

03 Jun '13

Eric S. Raymond wrote: > Howard Chu <hyc(a)symas.com>: >> The patch changes much more than your bug report mentions. The error >> message you provide is pretty ambiguous, in particular you haven't >> mentioned exactly which markup element is out of order. Without this >> information we can't confirm what you're fixing. > > Globally, I'm trying to fix up the entire Linux manual page corpus so > it can be automatically lifted to clean HTML. I've been working in > this intermittently since 2002, and am not far from the goal. In > approximately 12,000 pages carried in stock Ubuntu, 94% now lift > without errors or warnings. For all but 17 of the 6% remaining I have > fix patches which I'm trying to get merged upstream. > > I entered one of those patches in your bugtracker, but failed to notice > that the error code in my bug database entry for slapd.conf.5 was > incorrect (failed to match the patch). I apologize for this; > full explanation follows. > > My conversion tool is doclifter, which you can read about at > <http://www.catb.org/~esr/doclifter/>. It lifts manual pages to > XML-DocBook, which in turn is very easily rendered to HTML. This > sequence produces better-quality HTML than tools like man2html > can generate, because of the amount of content analysis done > in the doclifter intermediate step. > There are some legal troff constructions that doclifter cannot > parse well. These are the same sorts of things that any man-page > renderer other than groff itself is likely to get wrong; thus, they > are likely to confuse tools such as XMan, TkMan, and Rosetta as well > as doclifter. Hm. I use my own man2html http://highlandsun.com/hyc/man2html.c which gives pretty good looking output for us. Really, if you're developing a tool that claims to read troff input, it has to actually do so. I mean, the point of tools such as this is to be able to convert existing documents without modifying them, isn't it? > Thhe patch I sent you introduces an .EX/.EE macro pair for framing > code examples, a common extension often found on older Unix manual > pages (I believe it originated in DEC Ultrix). This macro > encapsulates a bunch of low-level troff operations that are hard to > lift well in isolation. There's a ruleset in doclifter that recognizes > .EX/.EE, analyzes the example content, and generates <programlisting> > or <literallayout> tags as appropriate. > > In some cases .EX/.EE replaces .RS/.RE pairs; in others it replaces > .nf/.fi pairs, in still others it replaces .TP, and I think there > are a couple of odd combinations of .RS/.RE with .TP in there too. The fact > that it has to mess with all of these is what makes the patch so > complex. But the result is simple: to express the "example" intention > better so it can be structurally translated. > -- -- 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#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 03 Jun '13

03 Jun '13

Howard Chu <hyc(a)symas.com>: > The patch changes much more than your bug report mentions. The error > message you provide is pretty ambiguous, in particular you haven't > mentioned exactly which markup element is out of order. Without this > information we can't confirm what you're fixing. Globally, I'm trying to fix up the entire Linux manual page corpus so it can be automatically lifted to clean HTML. I've been working in this intermittently since 2002, and am not far from the goal. In approximately 12,000 pages carried in stock Ubuntu, 94% now lift without errors or warnings. For all but 17 of the 6% remaining I have fix patches which I'm trying to get merged upstream. I entered one of those patches in your bugtracker, but failed to notice that the error code in my bug database entry for slapd.conf.5 was incorrect (failed to match the patch). I apologize for this; full explanation follows. My conversion tool is doclifter, which you can read about at <http://www.catb.org/~esr/doclifter/>. It lifts manual pages to XML-DocBook, which in turn is very easily rendered to HTML. This sequence produces better-quality HTML than tools like man2html can generate, because of the amount of content analysis done in the doclifter intermediate step. There are some legal troff constructions that doclifter cannot parse well. These are the same sorts of things that any man-page renderer other than groff itself is likely to get wrong; thus, they are likely to confuse tools such as XMan, TkMan, and Rosetta as well as doclifter. Thhe patch I sent you introduces an .EX/.EE macro pair for framing code examples, a common extension often found on older Unix manual pages (I believe it originated in DEC Ultrix). This macro encapsulates a bunch of low-level troff operations that are hard to lift well in isolation. There's a ruleset in doclifter that recognizes .EX/.EE, analyzes the example content, and generates <programlisting> or <literallayout> tags as appropriate. In some cases .EX/.EE replaces .RS/.RE pairs; in others it replaces .nf/.fi pairs, in still others it replaces .TP, and I think there are a couple of odd combinations of .RS/.RE with .TP in there too. The fact that it has to mess with all of these is what makes the patch so complex. But the result is simple: to express the "example" intention better so it can be structurally translated. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7615) NetBSD sem_open limited to 14 characters
by hyc＠symas.com 03 Jun '13

03 Jun '13

Greg(a)Akua.com wrote: > Full_Name: Greg Kerr > Version: 2.4.35 > OS: NetBSD & FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.88.130.68) > > > MDB is not usable on NetBSD because mdb.c has > > sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); > > To create the semaphore name. > > This results in a 21 character name which is beyond the 14 allowed per "man > sem_open" That's unfortunate. In Linux this limit is 251 characters. Seems you'd need to use the btoa algorithm to safely fit a hash into this size limit. Pretty sure we've tested successfully on FreeBSD and MacOSX already, so apparently they don't suffer from this same limit. > "less than 14 characters in length not including the terminating null > character." > > I will make a local patch ... and maybe it's a NetBSD bug - or at least the > package maintainers ... I will report to him. > > At any rate, the failure of mdb with result code 63 (name too long) was very > confusing ... better error reporting in this file would be nice. > > -- -- 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#7614) Markup error in slapd.conf.5
by hyc＠symas.com 03 Jun '13

03 Jun '13

esr(a)thyrsus.com wrote: > Full_Name: Eric S. Raymond > Version: > OS: Linux > URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch > Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) > > > List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. > Common causes include .TP just before a section header, .TP entries > with tags but no bodies, and mandoc lists with no trailing .El. > These confuse doclifter, and may also mess up stricter man-page > browsers like Xman and Rosetta. > > Fix patch at link. The patch changes much more than your bug report mentions. The error message you provide is pretty ambiguous, in particular you haven't mentioned exactly which markup element is out of order. Without this information we can't confirm what you're fixing. -- -- 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#7615) NetBSD sem_open limited to 14 characters
by Greg＠Akua.com 03 Jun '13

03 Jun '13

Full_Name: Greg Kerr Version: 2.4.35 OS: NetBSD & FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.88.130.68) MDB is not usable on NetBSD because mdb.c has sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); To create the semaphore name. This results in a 21 character name which is beyond the 14 allowed per "man sem_open" "less than 14 characters in length not including the terminating null character." I will make a local patch ... and maybe it's a NetBSD bug - or at least the package maintainers ... I will report to him. At any rate, the failure of mdb with result code 63 (name too long) was very confusing ... better error reporting in this file would be nice.

1 0

(ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 02 Jun '13

02 Jun '13

Full_Name: Eric S. Raymond Version: OS: Linux URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. Common causes include .TP just before a section header, .TP entries with tags but no bodies, and mandoc lists with no trailing .El. These confuse doclifter, and may also mess up stricter man-page browsers like Xman and Rosetta. Fix patch at link.

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 02 Jun '13

02 Jun '13

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> If a cursor is at a clean subDB page, and its current item is deleted >> by another cursor, then MDB_GET_CURRENT returns the deleted item. > > Fixed now in mdb.master. The subcursor on the clean page will be invalidated > when the page is touched. MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the patch below to the test program. One partial fix: Instead return a new error code MDB_BAD_CURSOR or maybe MDB_UNSPECIFIED. Also make mdb_cursor_<next/prev>() less forgiving of errors, otherwise the user gets different success results for the two cursors again. Branch mdb/its7594 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> does this. I did not look at how to get the cursors return the same result. mdb.master output with patched test program: With clean page: Name: Key -> Data (mv_data[mv_len]): m2: a[2] -> x[2] mc/del: a[2] -> [0] a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. Branch mdb/its7594 output: With clean page: Name: Key -> Data (mv_data[mv_len]): m2: a[2] -> x[2] mc/del: a[2] -> [0] its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable That assert is OK since it's the test program asserting success. --- its7594.c +++ its7594a.c @@ -28,4 +28,6 @@ E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); if (argc < 2) { @@ -42,8 +44,8 @@ E(mdb_cursor_del(mc, 0)); - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); - SHOW("m2/del"); /* Should output the same as... */ - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); + SHOW("m2/del"); /* ...and this should output the same. */ mdb_txn_abort(txn); -- Hallvard

1 0

(ITS#7612) {CLEARTEXT} password scheme broken
by wferi＠niif.hu 31 May '13

31 May '13

Full_Name: Ferenc Wágner Version: 2.4.31 OS: Debian GNU/Linux squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.101.52.7) I'm trying to store the hypothetical password "{SSHA}" in cleartext, but slappasswd refuses to help: $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} Password verification failed. On #openldap hbf suggested that I file an ITS ("work" in the following means allowing binding): hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be valid. As I agree with him, here it is.

1 0

Re: (ITS#7611) [Patch] Fix loglevel2bvarray
by hyc＠symas.com 29 May '13

29 May '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch > Submission from: (NULL) (209.132.186.34) > > > When using slaptest to convert a slapd.conf file to the new DIT integrated > configuration (-f and -F options), the directive 'loglevel 0' is not converted > to 'olcLogLevel: 0' in file cn=config.ldif. > > The 'loglevel 0' seems to be a special case, so this patch treats it as such. > > Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637 Thanks for the patch, committed to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7611) [Patch] Fix loglevel2bvarray
by jsynacek＠redhat.com 29 May '13

29 May '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch Submission from: (NULL) (209.132.186.34) When using slaptest to convert a slapd.conf file to the new DIT integrated configuration (-f and -F options), the directive 'loglevel 0' is not converted to 'olcLogLevel: 0' in file cn=config.ldif. The 'loglevel 0' seems to be a special case, so this patch treats it as such. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637

1 0

Re: (ITS#7610) scope index isn't used correctly with the filter index
by meike.stone＠googlemail.com 28 May '13

28 May '13

2013/5/28 Howard Chu <hyc(a)symas.com>: > meike.stone(a)googlemail.com wrote: >> >> Full_Name: Meike Stone >> Version: 2.4.33 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.200.138.3) >> >> >> I have a directory with about 2,000,000 objects at all. >> >> In one conteiner (basedn for search) are about 84,000 objects >> but only one of this is a person with objectclass=inetOrgperson. >> I have about 420,000 objectclass=inetOrgperson. >> >> The search with the specified basedn where only the one inetOrgperson >> is located needs about 5 minutes ... >> >> see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html > > > Sorry, digging further into the code I see I was mistaken. The two indices > are being combined correctly and the code works in my own tests. > > The search looks up the scope index (IDs of all the entries in the target > scope) and the filter indices and computes their intersection. Not sure why > this would be so slow in your case. hmm, while search, the one entry with the objectclass is shown immediately, but then, it takes a long time to "recognize" that that is all ... How does the slapd calculate/determine the scope index? Tomorrow I try to check this in test environment .. Are there any special things/hints I can test or see? Thanks Meike

1 0

RE: (ITS#7610) scope index isn't used correctly with the filter index
by ctcard＠hotmail.com 28 May '13

28 May '13

---------------------------------------- > Date: Tue, 28 May 2013 16:13:29 +0000 > From: hyc(a)symas.com > To: openldap-its(a)openldap.org > Subject: Re: (ITS#7610) scope index isn't used correctly with the filter index > > meike.stone(a)googlemail.com wrote: >> Full_Name: Meike Stone >> Version: 2.4.33 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.200.138.3) >> >> >> I have a directory with about 2,000,000 objects at all. >> >> In one conteiner (basedn for search) are about 84,000 objects >> but only one of this is a person with objectclass=inetOrgperson. >> I have about 420,000 objectclass=inetOrgperson. >> >> The search with the specified basedn where only the one inetOrgperson >> is located needs about 5 minutes ... >> >> see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html > > Sorry, digging further into the code I see I was mistaken. The two indices are > being combined correctly and the code works in my own tests. > > The search looks up the scope index (IDs of all the entries in the target > scope) and the filter indices and computes their intersection. Not sure why > this would be so slow in your case. This sounds very similar to problem I was having, and I had to increase BDB_IDL_LOGN to 18 for the (rebuilt) objectclass index to be used. Chris

1 0

Re: (ITS#7610) scope index isn't used correctly with the filter index
by hyc＠symas.com 28 May '13

28 May '13

meike.stone(a)googlemail.com wrote: > Full_Name: Meike Stone > Version: 2.4.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.200.138.3) > > > I have a directory with about 2,000,000 objects at all. > > In one conteiner (basedn for search) are about 84,000 objects > but only one of this is a person with objectclass=inetOrgperson. > I have about 420,000 objectclass=inetOrgperson. > > The search with the specified basedn where only the one inetOrgperson > is located needs about 5 minutes ... > > see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html Sorry, digging further into the code I see I was mistaken. The two indices are being combined correctly and the code works in my own tests. The search looks up the scope index (IDs of all the entries in the target scope) and the filter indices and computes their intersection. Not sure why this would be so slow in your case. -- -- 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#7610) scope index isn't used correctly with the filter index
by meike.stone＠googlemail.com 28 May '13

28 May '13

Full_Name: Meike Stone Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.200.138.3) I have a directory with about 2,000,000 objects at all. In one conteiner (basedn for search) are about 84,000 objects but only one of this is a person with objectclass=inetOrgperson. I have about 420,000 objectclass=inetOrgperson. The search with the specified basedn where only the one inetOrgperson is located needs about 5 minutes ... see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html Thanks Meike

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 28 May '13

28 May '13

Hi Howard, On Tue, 28 May 2013, Howard Chu wrote: >> Thanks a lot for the prompt fix. > > You're welcome. Thanks for confirming. could you commit both patches to RE24 so they would end up in 2.4.36 when it gets released. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 28 May '13

28 May '13

Hallvard Breien Furuseth wrote: > On 2013-05-28 15:03, hyc(a)symas.com wrote: >>> It looks like mdb_drop0() should also reset/uninitialize >>> other cursors in the same (sub)database. Currently such >>> cursors keep any references to the deleted pages. >>> >> Just doc this. No cursors should be open on a DB that is being >> dropped. > > Doesn't help mdb_cursor_del's call to mdb_drop0 when F_SUBDATA. > Is that safe? > Probably not but again, it's a doc issue. Someone has to call specifically with the flag mdb_cursor_del(MDB_NODUPDATA) so they must know what they're intending. -- -- 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#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 28 May '13

28 May '13

On 2013-05-28 15:03, hyc(a)symas.com wrote: >> It looks like mdb_drop0() should also reset/uninitialize >> other cursors in the same (sub)database. Currently such >> cursors keep any references to the deleted pages. >> > Just doc this. No cursors should be open on a DB that is being > dropped. Doesn't help mdb_cursor_del's call to mdb_drop0 when F_SUBDATA. Is that safe? -- Hallvard

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 28 May '13

28 May '13

Christian Kratzer wrote: > Hi Howard, > > On Mon, 27 May 2013, Howard Chu wrote: > <snipp/> >> This is now fixed in git master. Nothing fishy about the entry besides the >> modifiersName. I've now tweaked slapadd to allow it. > > I can confirm my test cases all work now on openlap master on CentOS 6.4: > > I also applied following two patches to openldap-2.4.35 and tested with the customers full configuration: > > From 6dab36e97afb680452a13efd41e8653a8949e2aa Mon Sep 17 00:00:00 2001 > From: Howard Chu <hyc(a)openldap.org> > Date: Mon, 27 May 2013 08:57:15 -0700 > Subject: [PATCH] ITS#7608 promoted attrs must have valid ad_index > > From b7df586674c65f1637ab5a59bd0a386f2031e95f Mon Sep 17 00:00:00 2001 > From: Howard Chu <hyc(a)openldap.org> > Date: Mon, 27 May 2013 18:51:34 -0700 > Subject: [PATCH] ITS#7608 allow slapadd w/unknown RDNs for config DB > > Thanks a lot for the prompt fix. You're welcome. Thanks for confirming. > > Greetings > Christian > -- -- 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#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 28 May '13

28 May '13

h.b.furuseth(a)usit.uio.no wrote: > Stealing this ITS for delete-related cursor problems, > since the ITSed problem is more general anyway: > > It looks like mdb_drop0() should also reset/uninitialize > other cursors in the same (sub)database. Currently such > cursors keep any references to the deleted pages. > Just doc this. No cursors should be open on a DB that is being dropped. -- -- 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#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 28 May '13

28 May '13

Hi Howard, On Mon, 27 May 2013, Howard Chu wrote: <snipp/> > This is now fixed in git master. Nothing fishy about the entry besides the > modifiersName. I've now tweaked slapadd to allow it. I can confirm my test cases all work now on openlap master on CentOS 6.4: I also applied following two patches to openldap-2.4.35 and tested with the customers full configuration: From 6dab36e97afb680452a13efd41e8653a8949e2aa Mon Sep 17 00:00:00 2001 From: Howard Chu <hyc(a)openldap.org> Date: Mon, 27 May 2013 08:57:15 -0700 Subject: [PATCH] ITS#7608 promoted attrs must have valid ad_index From b7df586674c65f1637ab5a59bd0a386f2031e95f Mon Sep 17 00:00:00 2001 From: Howard Chu <hyc(a)openldap.org> Date: Mon, 27 May 2013 18:51:34 -0700 Subject: [PATCH] ITS#7608 allow slapadd w/unknown RDNs for config DB Thanks a lot for the prompt fix. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 28 May '13

28 May '13

Stealing this ITS for delete-related cursor problems, since the ITSed problem is more general anyway: It looks like mdb_drop0() should also reset/uninitialize other cursors in the same (sub)database. Currently such cursors keep any references to the deleted pages. -- Hallvard

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 27 May '13

27 May '13

Christian Kratzer wrote: > Hi, > > On Mon, 27 May 2013, Howard Chu wrote: >>> great. Will the changes be automatically included in 2.4.36 when its >>> released ? >> >> Assuming you test and send positive feedback, yes. > > I checked out master using git://git.openldap.org/openldap.git and built my rpm from it. > > My config-3-fail.ldif sample still fails to import into cn=config on centos-64 > > [root@test-centos64 test]# slapadd -v -n0 -F config-3 -l config-3-fail.ldif > 51a3b6c1 str2entry: invalid value for attributeType modifiersName #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) > slapadd: could not parse entry (line=1) > _# 7.35% eta none elapsed none spd 8.1 M/s > Closing DB... > [root@test-centos64 test]# > > It fails on the first entry. Do you see anything obviously fishy in it ? This is now fixed in git master. Nothing fishy about the entry besides the modifiersName. I've now tweaked slapadd to allow it. > > dn: cn=config > objectClass: olcGlobal > cn: config > olcConfigFile: slapd.conf.test > olcConfigDir: slapd.d/ > olcArgsFile: /var/run/openldap/slapd.args > olcAttributeOptions: lang- > olcAuthzPolicy: none > olcConcurrency: 0 > olcConnMaxPending: 100 > olcConnMaxPendingAuth: 1000 > olcGentleHUP: FALSE > olcIdleTimeout: 0 > olcIndexSubstrIfMaxLen: 4 > olcIndexSubstrIfMinLen: 2 > olcIndexSubstrAnyLen: 4 > olcIndexSubstrAnyStep: 2 > olcIndexIntLen: 4 > olcLocalSSF: 71 > olcPidFile: /var/run/openldap/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSaslSecProps: noplain,noanonymous > olcSockbufMaxIncoming: 262143 > olcSockbufMaxIncomingAuth: 16777215 > olcThreads: 16 > olcTLSCRLCheck: none > olcTLSVerifyClient: never > olcToolThreads: 1 > olcWriteTimeout: 0 > olcAttributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' > RFC2256: organizational unit this object belongs to' SUP name ) > olcAttributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone > nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST > R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA > LUE ) > structuralObjectClass: olcGlobal > entryUUID: 3b1e9034-58d9-1032-8161-d3a3b8e342e7 > creatorsName: cn=config > createTimestamp: 20130524161753Z > olcLogLevel: Conns > olcLogLevel: Stats > olcLogLevel: Stats2 > entryCSN: 20130524161850.764209Z#000000#000#000000 > modifiersName: cn=Alice,ou=People,dc=test > modifyTimestamp: 20130524161850Z > > Can you verify above error on your setup. > > In the meantime I will build manually with default options without any rpm magic just to be sure. > > Greetings > Christian > -- -- 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#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 27 May '13

27 May '13

Hi, On Mon, 27 May 2013, Howard Chu wrote: >> great. Will the changes be automatically included in 2.4.36 when its >> released ? > > Assuming you test and send positive feedback, yes. I checked out master using git://git.openldap.org/openldap.git and built my rpm from it. My config-3-fail.ldif sample still fails to import into cn=config on centos-64 [root@test-centos64 test]# slapadd -v -n0 -F config-3 -l config-3-fail.ldif 51a3b6c1 str2entry: invalid value for attributeType modifiersName #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) slapadd: could not parse entry (line=1) _# 7.35% eta none elapsed none spd 8.1 M/s Closing DB... [root@test-centos64 test]# It fails on the first entry. Do you see anything obviously fishy in it ? dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf.test olcConfigDir: slapd.d/ olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0 olcAttributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' RFC2256: organizational unit this object belongs to' SUP name ) olcAttributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone nt' ) DESC 'RFC1274/2247: domain component' EQUALITY caseIgnoreIA5Match SUBST R caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VA LUE ) structuralObjectClass: olcGlobal entryUUID: 3b1e9034-58d9-1032-8161-d3a3b8e342e7 creatorsName: cn=config createTimestamp: 20130524161753Z olcLogLevel: Conns olcLogLevel: Stats olcLogLevel: Stats2 entryCSN: 20130524161850.764209Z#000000#000#000000 modifiersName: cn=Alice,ou=People,dc=test modifyTimestamp: 20130524161850Z Can you verify above error on your setup. In the meantime I will build manually with default options without any rpm magic just to be sure. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by hyc＠symas.com 27 May '13

27 May '13

Christian Kratzer wrote: > Hi Howard, > > On Mon, 27 May 2013, Howard Chu wrote: > >> Christian Kratzer wrote: >>> Hi Howard, >> >> Never mind, this was actually a bug in the handling of proxied attributes. >> Fixed now in master, your test case should work fine there. > > great. Will the changes be automatically included in 2.4.36 when its released ? Assuming you test and send positive feedback, yes. > > I'll test against master and deploy a workaround with an acl to the customer site in the meantime. > > Greetings > Christian > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs