openldap-bugs June 2013

openldap-bugs@openldap.org

19 participants
65 discussions

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

13 Jun '13

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

1 0

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

13 Jun '13

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

1 0

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

13 Jun '13

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

1 0

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

12 Jun '13

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

1 0

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

12 Jun '13

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

1 0

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

12 Jun '13

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

1 0

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

12 Jun '13

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

1 0

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

12 Jun '13

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

1 0

(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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2013