I've often thought about adding support here, but it looks like an
all-or-nothing proposition. I.e., when you have a server that uses
ditStructureRules, you must actually define a full set of rules otherwise you
cannot add any user entries to the directory at all. This would be a pretty
drastic change for people accustomed to the current behavior, where you can
put any entry you like anywhere you like. Beginners have a hard enough time
just getting their first two entries into the directory; requiring the use of
ditStructureRules would seem to just make a bad situation worse.
Possibly we could make it a configurable option - enable them with a
per-database setting, defaulting to off to preserve the current behavior.
Fully aligning with X.500 practices would have to wait for a new generation
of server. E.g., we currently support the use of subdatabases using
subordinate/glue. These provide some of the notion of X.500 Administrative
Areas, except their definitions reside in the cn=config tree, not as
subentries of the main DIT. Providing full subentry-based administration
would be a major change in how the server is operated and how the DIT is
administered. Something for OpenLDAP 3.0.
--
-- 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/
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/
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
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.
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 ?? ()
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.
(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/
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/
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.loghttp://www.perl.me.uk/test49/slapd.2.loghttp://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.