openldap-bugs February 2007

openldap-bugs@openldap.org

32 participants
125 discussions

Re: (ITS#4833) Back-config chokes when adding database
by hyc＠symas.com 07 Feb '07

07 Feb '07

Thanks, fixed. rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.144.248) > > > When adding a database without an explicit index set olcDatabase-Attribute slapd > crashes (find stack backtrace below). > > This is the LDIF I tried to add: > > dn: olcDatabase=ldap,cn=config > objectclass: olcDatabaseConfig > objectclass: olcldapconfig > olcDatabase: ldap > olcsuffix: cn=test > olcrootdn: cn=admin,cn=test > olcrootpw: secret > olcdburi: ldap://my.ldap.server > > When using the correct index, '{1}' in my case it works as expected. I suspect > something's wrong the special handling of the {-1} index of frontendDB, but > wasn't able to track it down completely. > > Here's the backtrace: -- -- Howard Chu Chief Architect, 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#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 07 Feb '07

07 Feb '07

Suggestion: Generalize a bit and support the slapd.conf statement index attr :matchingRule Can be used with the extended filter (attr:matchingRule:=foo), or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. -- Regards, Hallvard

1 0

(ITS#4834) DN matching rules should be indexed
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The dnSubtreeMatch, dnOneLevelMatch, dnSubordinateMatch, and dnSuperiorMatch matching rules added in OpenLDAP 2.3 can be used in extended filter clauses to get finer control over the scope of a search. Currently back-bdb/back-hdb don't do any indexing for extended filters, which can make these filters pretty expensive to evaluate. But these specific rules can take advantage of the dn2id index, which already maintains all the necessary index information. If these extensions are going to be used frequently, we should add index support here.

1 0

(ITS#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.144.248) When adding a database without an explicit index set olcDatabase-Attribute slapd crashes (find stack backtrace below). This is the LDIF I tried to add: dn: olcDatabase=ldap,cn=config objectclass: olcDatabaseConfig objectclass: olcldapconfig olcDatabase: ldap olcsuffix: cn=test olcrootdn: cn=admin,cn=test olcrootpw: secret olcdburi: ldap://my.ldap.server When using the correct index, '{1}' in my case it works as expected. I suspect something's wrong the special handling of the {-1} index of frontendDB, but wasn't able to track it down completely. Here's the backtrace: #0 0x0000000000415083 in config_add_internal (cfb=0x7f11c0, e=0x88af68, ca=0x40fff6c0, rs=0x41000cb0, renum=0x41000884, op=0x8ad530) at bconfig.c:4385 #1 0x00000000004156a7 in config_back_add (op=0x8ad530, rs=0x41000cb0) at bconfig.c:4523 #2 0x000000000043057b in fe_op_add (op=0x8ad530, rs=0x41000cb0) at add.c:330 #3 0x000000000042feaf in do_add (op=0x8ad530, rs=0x41000cb0) at add.c:182 #4 0x00000000004276db in connection_operation (ctx=0x41000de0, arg_v=0x8ad530) at connection.c:1129 #5 0x0000000000427bb9 in connection_read_thread (ctx=0x41000de0, argv=0xc) at connection.c:1257 #6 0x000000000053d552 in ldap_int_thread_pool_wrapper (xpool=0x85e630) at tpool.c:704 #7 0x00002b374570309e in start_thread () from /lib64/libpthread.so.0 #8 0x00002b37459d94cd in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

syncrepl.c rev 1.310 Provided a successful test: Cleaning up test run directory leftover from previous run. Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved configs from producer and consumer... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded Many thanks, Gavin.

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

(gdb) attach 15790 Attaching to process 15790 Reading symbols from /anything/src/openldap-devel/servers/slapd/.libs/lt-slapd...done. Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0 Reading symbols from /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0 Reading symbols from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libssl.so.6...done. Loaded symbols for /lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libwrap.so.0...done. Loaded symbols for /usr/lib/libwrap.so.0 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread -1208633664 (LWP 15790)] [New Thread -1210299504 (LWP 15804)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libcrypt.so.1...done. Loaded symbols for /usr/lib/libcrypt.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 0x007de402 in __kernel_vsyscall () (gdb) n Single stepping until exit from function __kernel_vsyscall, which has no line number information. [Switching to Thread -1208633664 (LWP 15790)] 0x008554b7 in pthread_join () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function pthread_join, which has no line number information. [New Thread -1220789360 (LWP 15865)] [New Thread -1231279216 (LWP 15873)] Error while mapping shared library sections: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Error while reading shared library symbols: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1220789360 (LWP 15865)] 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 2225 csn = si->si_syncCookie.ctxcsn[0]; (gdb) bt #0 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 #2 0x080c961c in do_syncrepl (ctx=0xb73c3238, arg=0x81ecf90) at syncrepl.c:1107 #3 0x00d3cf00 in ldap_int_thread_pool_wrapper (xpool=0x81cc150) at tpool.c:704 #4 0x008543db in start_thread () from /lib/libpthread.so.0 #5 0x005bf26e in clone () from /lib/libc.so.6 (gdb) p si->si_syncCookie $1 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8d90 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) frame 1 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 818 syncrepl_del_nonpresent( op, si, NULL, (gdb) p syncCookie $4 = {ctxcsn = 0x81eca90, octet_str = {bv_len = 52, bv_val = 0x81fa810 "rid=001,csn=20070206232910.544649Z#000000#000#000000"}, rid = 1, sid = -1, numcsns = 1, sids = 0x81eca50, sc_next = {stqe_next = 0x0}} (gdb) p syncCookie{ A syntax error in expression, near `{'. (gdb) print syncCookie_req $5 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8da0 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) p m $6 = 1 Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by hyc＠symas.com 06 Feb '07

06 Feb '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > >>>>>> Starting test049-sync-config ... > running defines.sh > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F > ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: > /src/openldap-devel/tests/testrun/con) > Waiting 10 seconds for syncrepl to receive changes.. > > Logs at: > > http://www.perl.me.uk/test49/slapd.1.log > http://www.perl.me.uk/test49/slapd.2.log > http://www.perl.me.uk/test49/test.out We also need a stack trace from the crash. Set your coresize to unlimited so that crashes will generate a core file. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

Full_Name: Gavin Henry Version: HEAD OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) >>>>> Starting test049-sync-config ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: /src/openldap-devel/tests/testrun/con) Waiting 10 seconds for syncrepl to receive changes.. Logs at: http://www.perl.me.uk/test49/slapd.1.log http://www.perl.me.uk/test49/slapd.2.log http://www.perl.me.uk/test49/test.out Was trying to test test050, but died on 049. Is it possible to just run this test? I can't seem to figure out how, without doing a "make test" again. Gavin.

1 0

Re: (ITS#4626) "glue" objectclass in syncrepl consumer
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Sep 22, 2006 at 07:48:33PM +0000, hyc(a)symas.com wrote: >> Yes, this makes sense. >> >> Since all of the CSNs under ou=global are greater than any CSN under >> dc=example,dc=com, none of those entries are sent. In server B your >> consumer should be configured on dc=example,dc=com, with a searchbase of >> ou=global,dc=example,dc=com. That will allow the server B provider to >> stay in sync with its consumer. > > With this change, the replication is better, but the B server cannot be > written to anymore: moving the syncrepl directive to the > dc=example,dc=com database makes it read-only because it is then > considered a consumer. This portion of your report is the same as ITS#4623. The fix for ITS#4623 is in HEAD and probably will only be in 2.4. The other part of the problem, where objects get turned into glue objects, is fixed by ITS#4813. This fix is in RE23 and will be in 2.3.34. I'm closing this ITS, you can followup to #4623 or #4813 if you need to make any further comments. -- -- Howard Chu Chief Architect, 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#4623) syncprov and glued databases: findbase failed
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: REL_ENG_2_3 (2.3.24+) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > I have a provider with two databases glued together: > dc=example,dc=com > ou=global,dc=example,dc=com > > One consumer has the syncrepl base search pointing to ou=global on the > provider. > The slapd.conf(5) manpage says that in this scenario, one should load the > overlays at the provider in this order: > > overlay glue > overlay syncprov > > If my provider config is as follows, however, I get a "findbase failed! 32" > error at the provider: The docs were wrong in this case; the required hooks for the overlay support here were not implemented. These hooks have been added to CVS HEAD and this configuration works correctly there. The changes will be part of 2.4. I don't think they'll be backported for 2.3. > I was under the impression (caused by the slapd.conf(5) manpage) that one should > only need to load the syncprov overlay once, right after glue, and it would > attend to both databases. But if I do that, then I get the error I mentioned > above when attempting to replicate the subordinate database. Right, that was the intent, but because of the missing hooks, it couldn't work. -- -- Howard Chu Chief Architect, 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 February 2007