openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7383) slapd startup issue with mdb
by hyc＠symas.com 11 Sep '12

11 Sep '12

marco(a)schirrmeister.net wrote: > Full_Name: Marco Schirrmeister > Version: 2.4.32 > OS: CentOS6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.59.6.160) > > > I'm testing mdb since the last versions with our dataset. > If I use my production config slapd does't start up. > > The following is in the log file. > > Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 > 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd > Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": > mdb_open(omgPublishDate) failed: Too many open files in system (23). > Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, > suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) > Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. > > My /etc/security/limits.conf file has already the following entries. > * soft nofile 65535 > * hard nofile 65535 > > No matter what I try on the OS side, the error above comes up. > > I have about 130 index attributes in my config. Looks to me that this is the > problem. > If I comment 8 attributes, slapd starts fine. There is a hardcoded limit of 128. This same limit exists in back-bdb/hdb. You can just edit back-mdb.h (or back-bdb.h) to raise the limit. Change the MDB_INDICES (or BDB_INDICES) definition. Congratulations, no one else has hit this limit in back-bdb in the past 12 years. Seems likely to me that you're indexing too much, but there's not enough information here to judge. -- -- 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#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com 11 Sep '12

11 Sep '12

Full_Name: Duncan Idaho Version: 2.4.32 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.148.0.72) We are seeing this a few times a week in our environment. #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, oldctrls=0x11251620) at ppolicy.c:870 #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) at ppolicy.c:895 #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at result.c:541 #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at result.c:733 #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) at result.c:860 #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) at op.c:210 #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at op.c:243 #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:383 #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, arg_v=0x11144d40) at connection.c:1150 #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at connection.c:1286 #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at tpool.c:688 #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 #24 0x0000000000000000 in ?? ()

1 0

(ITS#7383) slapd startup issue with mdb
by marco＠schirrmeister.net 11 Sep '12

11 Sep '12

Full_Name: Marco Schirrmeister Version: 2.4.32 OS: CentOS6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.59.6.160) I'm testing mdb since the last versions with our dataset. If I use my production config slapd does't start up. The following is in the log file. Sep 11 16:48:37 ds71 slapd2.4[8349]: @(#) $OpenLDAP: slapd 2.4.32 (Sep 6 2012 13:50:54) $#012#011mschirrmeister@defrsl6bh2.ogilvy.com:/home/mschirrmeister/rpmbuild/BUILD/openldap-2.4.32/servers/slapd Sep 11 16:48:37 ds71 slapd2.4[8349]: mdb_attr_dbs: database "dc=ogilvy,dc=com": mdb_open(omgPublishDate) failed: Too many open files in system (23). Sep 11 16:48:37 ds71 slapd2.4[8349]: backend_startup_one (type=mdb, suffix="dc=ogilvy,dc=com"): bi_db_open failed! (23) Sep 11 16:48:37 ds71 slapd2.4[8349]: slapd stopped. My /etc/security/limits.conf file has already the following entries. * soft nofile 65535 * hard nofile 65535 No matter what I try on the OS side, the error above comes up. I have about 130 index attributes in my config. Looks to me that this is the problem. If I comment 8 attributes, slapd starts fine. I did not find anything about index limits. Is this a bug in mdb? I'm not able to create stacktrace. When I run slapd via gdb, output is this. Program exited with code 01. (gdb) bt full No stack. (gdb) If you can let me know how to do it, I can provide a trace. My config looks like below. I omitted all our internal attributes. --------- include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/java.schema include /usr/share/openldap2.4/schema/krb5-kdc.schema include /usr/share/openldap2.4/schema/kerberosobject.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/autofs.schema include /usr/share/openldap2.4/schema/samba.schema include /usr/share/openldap2.4/schema/kolab.schema include /usr/share/openldap2.4/schema/calendar.schema include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/dhcp.schema include /usr/share/openldap2.4/schema/ldapns.schema include /etc/openldap2.4/slapd.access.ogilvy.conf pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la moduleload accesslog.la moduleload syncprov.la moduleload auditlog.la TLSCertificateFile /etc/pki/tls/certs/ogilvy.com.crt TLSCertificateKeyFile /etc/pki/tls/private/ogilvy.com_unsec.rsa TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt loglevel stats sasl-secprops noplain,noanonymous,noactive serverID 40 ldap://ds71.ogilvy.com database mdb suffix "dc=ogilvy,dc=com" rootdn "cn=manager,dc=ogilvy,dc=com" rootpw xxx directory /var/lib/ldap2.4/ogilvy.com limits dn.exact="cn=manager,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="uid=replicator,ou=admin,dc=ogilvy,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group/ogilvyGroup/uniqueMember="cn=svcgrp-unlimitedsearch,ou=groups,dc=ogilvy,dc=com" size.soft=unlimited size.hard=unlimited sizelimit 90000 checkpoint 256 5 conn_max_pending_auth 2000 dbnosync maxsize 10485760000 monitoring on overlay syncprov syncprov-checkpoint 256 5 syncprov-sessionlog 5000 database config rootdn "cn=admin,cn=config" rootpw xxx include /etc/openldap2.4/slapd.access.config.conf database monitor rootdn cn=monitor rootpw xxx ------- -- Marco

1 0

Re: (ITS#7382) slapadd segfaults (during freeing resources)
by hyc＠symas.com 09 Sep '12

09 Sep '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: OPENLDAP_REL_ENG > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) > > > Hi, Looks like you're mixing different libldaps in the same process. libldap init.c:484 is not what your backtrace shows. At least, not in the RE24 branch. Closing this ITS, your environment is invalid. > root@srv:/home/tester/src/openldap# gdb > /home/tester/src/openldap/servers/slapd/slapadd > GNU gdb (GDB) 7.4.1-debian > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. > (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l > /tmp/example_data.ldif > Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F > /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already > exists(-30799) "dc=example,dc=com" > 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 > 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already > exists (-30799) > slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! > MDB_KEYEXIST: Key/data pair already exists (-30799) > _### 16.13% eta none elapsed none spd 501.5 k/s > Closing DB... > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt full > #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 > No locals. > #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 > ludp = 0x8fcd10 > next = 0x7375632f6374652f > #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 > gopts = 0x7ffff6599080 > #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 > No symbol table info available. > #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 > No symbol table info available. > #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #11 0x00007ffff77bfae1 in sasl_common_done () from > /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > No symbol table info available. > #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 > No locals. > #13 0x0000000000482039 in slap_destroy () at init.c:249 > rc = 0 > #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 > rc = 0 > #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at > slapadd.c:502 > textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists > (-30799)", '\000' <repeats 191 times> > textlen = 256 > erec = {e = 0x8db288, lineno = 1, nextline = 14} > bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} > thr = 4270934 > id = 18446744073709551615 > prev = 0x0 > ldifrc = 1 > rc = 1 > stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = > 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, > st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, > tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { > tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} > #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 > i = 0 > no_detach = 0 > ---Type <return> to continue, or q <return> to quit--- > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > pid = 32767 > waitfds = {0, 0} > g_argc = 8 > g_argv = 0x7fffffffe648 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffffffe8c3 "slapadd" > serverMode = 1 > scp = 0x0 > scp_entry = 0x0 > debug_unknowns = 0x0 > syslog_unknowns = 0x0 > serverNamePrefix = 0x596388 "" > l = 140733193388033 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __PRETTY_FUNCTION__ = "main" > > -- -- 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#7382) slapadd segfaults (during freeing resources)
by daniel＠pluta.biz 09 Sep '12

09 Sep '12

Full_Name: Daniel Pluta Version: OPENLDAP_REL_ENG OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:2958:c83c:2589:166d) Hi, root@srv:/home/tester/src/openldap# gdb /home/tester/src/openldap/servers/slapd/slapadd GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/tester/src/openldap/servers/slapd/slapadd...done. (gdb) run -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif Starting program: /home/tester/src/openldap/servers/slapd/slapadd -v -F /etc/ldap/slapd_example.d_stat -b "dc=example,dc=com" -l /tmp/example_data.ldif [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 504cc479 mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already exists(-30799) "dc=example,dc=com" 504cc479 => mdb_tool_entry_put: id2entry_add failed: err=-30799 504cc479 => mdb_tool_entry_put: txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799) _### 16.13% eta none elapsed none spd 501.5 k/s Closing DB... Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007ffff6a34859 in free () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x0000000000592f46 in ber_memfree_x (p=0x426f6f462f6d6f74, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x0000000000579f5f in ldap_free_urldesc (ludp=0x8fcd10) at url.c:1528 No locals. #3 0x0000000000579f15 in ldap_free_urllist (ludlist=0x8fcd10) at url.c:1516 ludp = 0x8fcd10 next = 0x7375632f6374652f #4 0x00007ffff635b2b3 in ldap_int_destroy_global_options () at init.c:484 gopts = 0x7ffff6599080 #5 0x00007ffff7defef9 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #6 0x00007ffff7df09ce in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #7 0x00007ffff7deabd6 in ?? () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #8 0x00007ffff79d12ec in ?? () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #9 0x00007ffff79d100f in dlclose () from /lib/x86_64-linux-gnu/libdl.so.2 No symbol table info available. #10 0x00007ffff77c8291 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #11 0x00007ffff77bfae1 in sasl_common_done () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2 No symbol table info available. #12 0x00000000004b34d4 in slap_sasl_destroy () at sasl.c:1190 No locals. #13 0x0000000000482039 in slap_destroy () at init.c:249 rc = 0 #14 0x00000000004ddbc8 in slap_tool_destroy () at slapcommon.c:932 rc = 0 #15 0x00000000004db86f in slapadd (argc=8, argv=0x7fffffffe648) at slapadd.c:502 textbuf = "\000xn_aborted! MDB_KEYEXIST: Key/data pair already exists (-30799)", '\000' <repeats 191 times> textlen = 256 erec = {e = 0x8db288, lineno = 1, nextline = 14} bvtext = {bv_len = 256, bv_val = 0x7fffffffe300 ""} thr = 4270934 id = 18446744073709551615 prev = 0x0 ldifrc = 1 rc = 1 stat_buf = {st_dev = 2307, st_ino = 149868, st_nlink = 1, st_mode = 33188, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 2225, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1347128272, tv_nsec = 0}, st_mtim = {tv_sec = 1347128189, tv_nsec = 0}, st_ctim = { tv_sec = 1347128189, tv_nsec = 0}, __unused = {0, 0, 0}} #16 0x000000000041e688 in main (argc=8, argv=0x7fffffffe648) at main.c:410 i = 0 no_detach = 0 ---Type <return> to continue, or q <return> to quit--- rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32767 waitfds = {0, 0} g_argc = 8 g_argv = 0x7fffffffe648 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffe8c3 "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x596388 "" l = 140733193388033 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 06 Sep '12

06 Sep '12

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> This is worse with a database with is intended to be used by >> different users (A and B): > (...) >> mdb_env_setup_locks() can sem_unlink both semaphores before doing >> anything else, so that reopening a database as root will clean up. >> Drop the error checks of sem_unlink (so both get called), instead >> use O_EXCL in sem_open(,O_CREAT,,). Unless I'm missing something, >> the error checks just work like an emulation of O_EXCL anyway. > > The sem_unlink() and sem_open() sequence isn't ideal, certainly. I would > prefer to just use the existing semaphore. I just realized reusing the semaphores is a security problem: Anyone who can compute/read the semaphore names, can create the semaphores owned by themselves and then muck with them to sabotage someone else's mdb. I suppose the same goes for SysV semaphores. I don't know what the accepted way to deal with that is, but I suggest to unlink + O_EXCL as above for now, document the multi-uid restriction, and punt the rest until anyone who cares shows up. > Another possibility is to just use SysV semaphores instead of POSIX > semaphores. Then you can use the ipcs(1) command to manually cleanup. > (...) [later] > I'm also reminded that there is no defined behavior for SysV > semaphores in threads, they are only speciried for inter-process > synchronization. So forget that... I expect the work-around is to use them for IPC only, and wrap them in process-local mutexes in the MDB_env for thread sync. -- Hallvard

1 0

(ITS#7381) Dynamically added chaining configuration stops working after restart
by ian＠uns.ac.rs 05 Sep '12

05 Sep '12

Full_Name: Ivan Nejgebauer Version: 2.4.32 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-120905.tgz Submission from: (NULL) (2001:4170:2000:2:213:d3ff:fecf:b9ea) If a minimal chaining configuration is dynamically added to a consumer server in a provider/consumer pair running delta-syncrepl, it will stop working when the consumer is restarted. The configuration is modelled after the one used in test022 in the OpenLDAP source distribution: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials="secret" mode=self olcDbURI: "ldap://localhost:6389" Scripts and data for replicating the issue are in the referenced archive. Quick summary: # make clean-all master replica # ./start-master.sh # ./start-replica.sh # ./replica-apply.sh pmod-add.ldif # returns referral # ./replica-conf.sh chain.ldif # adds chaining configuration # ./replica-apply.sh pmod-add.ldif # chains to master # ./stop-replica.sh # ./start-replica.sh # ./replica-apply.sh pmod-del.ldif # returns referral, but shouldn't I have tested both 2.4.32 and git master (54a111907b48900e1ce5de12a9d87818a334423d).

1 0

(ITS#7380) Open LDAP and Oracle Backend
by iliyas.nadaf＠gmail.com 04 Sep '12

04 Sep '12

Full_Name: iliyas Version: openldap-2.4.31 OS: solaris-x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.160.74.254) Hi, I need to develope "ladap client in C" with OpenLdap source and backend as Oracle database 11gr2. If it is possible suggest some resources. I have done it properly with BDB. Thanks, Iliyas

1 0

(ITS#7379) Open LDAP and Oracle Backend
by iliyas.nadaf＠gmail.com 04 Sep '12

04 Sep '12

1 0

Re: (ITS#7378) Slapd hangs on bdb write lock
by nikolai＠net24.co.nz 04 Sep '12

04 Sep '12

Thanks guys - I think we will look at going to MDB as well now. On 4/09/2012, at 8:42 AM, Quanah Gibson-Mount wrote: > --On Monday, September 03, 2012 6:35 PM +0000 hyc(a)symas.com wrote: > >> Nikolai Schupbach wrote: >>> Hi Howard, >>> >>> Thank you very much for the explanation. What BDB version would you >> recommend. Obviously I have quite a few options and would like to use a >> version that is known to be very solid. >> >> I believe 4.7.25 + all 4 of its official patches was pretty stable. >> http://www.oracle.com/technetwork/products/berkeleydb/patch-088170.html >> >> I've done limited testing with 4.8.30, 5.1.19, and 5.3.21. At this point >> I'm no longer tracking BDB revisions since MDB has superior performance >> while using 1/4 as much RAM and requiring no tuning. > > We've been using BDB 4.7.25+all 4 patches without issue for several years as well. However, I will also note that we are now switching over to MDB as well for our production services starting with OpenLDAP 2.4.32. > > --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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs