openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

(ITS#5927) assertion error when using pcache
by mhardin＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Hardin Version: 2.4.13 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We have an LDAP server that is proxying for Active Directory. Periodically slapd throws an assertion: slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: Assertion `i > 0' failed. /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS Howard Chu's examination of the core file showed that the remote AD server returned a member attribute with no values. This is only legal in LDAP when a client sets the attrsonly flag in its search request, and that flag was not set here. The indexer rightly asserts because pcache handed it an attribute with nothing to index. I'm not sure what the correct thing to do might be here, but it should not take down the slapd. Thanks, -Matt

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > gavin.henry(a)gmail.com wrote: >> Ok, but wouldn't that detail be best served staying in the man page? I >> mean, what "user" will want to enter hex for loglevels? > > Actually, I wonder what user would use the decimal notation. I > introduced the hexadecimal because I find it a little more intuitive in > terms of bitwise (then I decided to move to string-based :) After giving many training sessions, I can assure you many "doing their best" users trust the decimal notation. Their managers, trying to help analyze problems, also. I know one such guy, head of infrastructure for a multinational company, with little or no background in IT, who speaks fluently in decimal OpenLDAP log levels :) Also, specifying "255" is much shorter than "Trace Packets Args Conns BER Filter Config Args". Thus, I feel it's still useful to find decimal notations in the guide. At least, to understand existing configs. On the same basis, hex could be useful. Jonathan

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 05 Feb '09

05 Feb '09

And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: ITS#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> If it works, then we still have an issue: operations for "o=1,o=2" will >>> probably be intercepted by the back-bdb. However, I understand that >>> since the first database is glued, it wants to know whom it's glued to. >> A fix is in HEAD. It will allow this scenario to succeed, but it will >> also allow completely broken subordinate configs to be dynamically >> created in cn=config. (configs read from slapd.conf/slapd.d will still >> be error checked appropriately.) As such, it needs a bit more thought. > > Need ldap-txn, don't we? I guess that could help. We haven't figured out yet how to propagate TXNs in syncrepl though. -- -- 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#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > If it works, then we still have an issue: operations for "o=1,o=2" will > probably be intercepted by the back-bdb. However, I understand that > since the first database is glued, it wants to know whom it's glued to. A fix is in HEAD. It will allow this scenario to succeed, but it will also allow completely broken subordinate configs to be dynamically created in cn=config. (configs read from slapd.conf/slapd.d will still be error checked appropriately.) As such, it needs a bit more thought. -- -- 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#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> If it works, then we still have an issue: operations for "o=1,o=2" will >> probably be intercepted by the back-bdb. However, I understand that >> since the first database is glued, it wants to know whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will still > be error checked appropriately.) As such, it needs a bit more thought. Need ldap-txn, don't we? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 05 Feb '09

05 Feb '09

This is now fixed in HEAD: modifications to the objectClass attribute that change the structural objectClass are automatically reflected by in the structuralObjectClass attribute. What's missing right now is that structuralObjectClass should no longer be manageable (I believe). test037 also needs to be cleaned up. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

ITS#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Does it work if you change the order of the databases? I mean: +++ original dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] +++ original +++ modified dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn: olcDatabase={3}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] +++ modified If it works, then we still have an issue: operations for "o=1,o=2" will probably be intercepted by the back-bdb. However, I understand that since the first database is glued, it wants to know whom it's glued to. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Should be fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Hardin Version: 2.4.12 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active directory domain. The clients are all current versions of PADL's nss_ldap libraries. Every once in a while (sometimes twice a day, sometimes once every two weeks) one of the slapd servers will peg CPU use at 100% and stop answering requests. The only way to stop slapd is with a kill -9. There doesn't seem to be anything to explain the lockup or allow us to reproduce it. We are using redundant AD servers and they are not going offline. A third slapd server running as a test server using the same AD servers and configured identically but serving a much lighter nss_ldap load does not fail at all. We have ruled out hardware, OS, and connectivity as possible causes. We are unfortunately unable to attach gdb to the running processes, as these are production servers and need to be restarted immediately. Our smaller test system does not exhibit the same behavior, either. There is nothing unusual in the server logs, either. We do have core files generated from kill -6 commands, and they are all eerily similar to the back-trace below in that they have one or more threads waiting for a search or a bind response from AD. I am also enclosing relevant portions of slapd.conf for these systems. Please let me know if any additional information would be useful. Thanks, -Matt ----- (gdb) thr apply all bt Thread 18 (process 24520): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038b557 in pthread_join () from /lib/libpthread.so.0 #2 0x00a118dc in ldap_pvt_thread_join (thread=20691856, thread_return=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x08070f79 in slapd_daemon () at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2656 #4 0x08058544 in main (argc=7, argv=0xbf90dec4) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/main.c:948 Thread 17 (process 24525): #0 0x005fa410 in __kernel_vsyscall () #1 0x005862c6 in epoll_wait () from /lib/libc.so.6 #2 0x080704ab in slapd_daemon_task (ptr=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2291 #3 0x0038a45b in start_thread () from /lib/libpthread.so.0 #4 0x00585c4e in clone () from /lib/libc.so.6 Thread 16 (process 24526): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 15 (process 24527): #0 0x005fa410 in __kernel_vsyscall () #1 0x00586ca8 in send () from /lib/libc.so.6 #2 0x00582269 in __vsyslog_chk () from /lib/libc.so.6 #3 0x005825aa in syslog () from /lib/libc.so.6 #4 0x08085093 in slap_send_ldap_result (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/result.c:656 #5 0x00149c3c in bdb_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-bdb/search.c:1025 #6 0x080e09b1 in overlay_op_walk (op=0x9b5d968, rs=0x17bc120, which=op_search, oi=0x95d0e90, on=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:667 #7 0x080e0b41 in over_op_func (op=0x9b5d968, rs=0x17bc120, which=op_search) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:719 #8 0x080e0bb9 in over_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:741 #9 0x08076577 in fe_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #10 0x08075fa2 in do_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #11 0x08073682 in connection_operation (ctx=0x17bc220, arg_v=0x9b5d968) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #12 0x08073acf in connection_read_thread (ctx=0x17bc220, argv=0x19c) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #13 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #14 0x0038a45b in start_thread () from /lib/libpthread.so.0 #15 0x00585c4e in clone () from /lib/libc.so.6 Thread 14 (process 24528): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 13 (process 24935): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 12 (process 26566): #0 0x005fa410 in __kernel_vsyscall () #1 0x0057c033 in poll () from /lib/libc.so.6 #2 0x00a2af30 in ldap_int_select (ld=0xaaf60a28, timeout=0x1bbbdb0) at os-ip.c:1053 #3 0x00a12eb8 in wait4msg (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:355 #4 0x00a12881 in ldap_result (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:127 #5 0x00d73bba in meta_back_search (op=0xaaff7ce0, rs=0x1bbd120) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-meta/search.c:1027 #6 0x08076577 in fe_op_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #7 0x08075fa2 in do_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #8 0x08073682 in connection_operation (ctx=0x1bbd220, arg_v=0xaaff7ce0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #9 0x08073acf in connection_read_thread (ctx=0x1bbd220, argv=0x146) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #10 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #11 0x0038a45b in start_thread () from /lib/libpthread.so.0 #12 0x00585c4e in clone () from /lib/libc.so.6 Thread 11 (process 26567): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 10 (process 29015): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 9 (process 11659): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 ---Type <return> to continue, or q <return> to quit--- #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 8 (process 29762): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080727c1 in connection_destroy (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:664 #6 0x08072d05 in connection_close (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:799 #7 0x080741e3 in connection_read (s=333, cri=0x328b1a0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1386 #8 0x08073a4d in connection_read_thread (ctx=0x328b220, argv=0x14d) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1203 #9 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #10 0x0038a45b in start_thread () from /lib/libpthread.so.0 #11 0x00585c4e in clone () from /lib/libc.so.6 Thread 7 (process 29763): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 6 (process 29764): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080d36b9 in do_syncrep2 (op=0x3a8cd70, si=0x95d0ff8) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1174 #6 0x080d3b93 in do_syncrepl (ctx=0x3a8d220, arg=0x95d1250) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1301 ---Type <return> to continue, or q <return> to quit--- #7 0x08073aeb in connection_read_thread (ctx=0x3a8d220, argv=0xe) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1212 #8 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #9 0x0038a45b in start_thread () from /lib/libpthread.so.0 #10 0x00585c4e in clone () from /lib/libc.so.6 Thread 5 (process 29765): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 4 (process 29766): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 3 (process 29767): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 2 (process 29768): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 ---Type <return> to continue, or q <return> to quit--- #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 1 (process 29769): #0 0x005fa410 in __kernel_vsyscall () #1 0x004ddd10 in raise () from /lib/libc.so.6 #2 0x004df621 in abort () from /lib/libc.so.6 #3 0x004d715b in __assert_fail () from /lib/libc.so.6 #4 0x0806eec8 in slap_listener (sl=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 #8 0x00585c4e in clone () from /lib/libc.so.6 (gdb) ------ slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include /opt/symas/etc/openldap/schema/core.schema #include /opt/symas/etc/openldap/schema/ppolicy.schema #include /opt/symas/etc/openldap/schema/corba.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema #include /opt/symas/etc/openldap/schema/eduperson.schema #include /opt/symas/etc/openldap/schema/java.schema #include /opt/symas/etc/openldap/schema/krb5-kdc.schema #include /opt/symas/etc/openldap/schema/misc.schema include /opt/symas/etc/openldap/schema/nis.schema.my-customer #include /opt/symas/etc/openldap/schema/connexitor.schema #include /opt/symas/etc/openldap/schema/openldap.schema #include /opt/symas/etc/openldap/schema/samba.schema # TLS Setup Section # # TLSCACertificateFile <filename> # Specifies the file that contains certificates for all # of the Certificate Authorities that slapd will # recognize. #TLSCACertificateFile /opt/symas/ssl/cacert.pem TLSCACertificatePath /opt/symas/ssl/certs # # TLSCertificateFile <filename> # Specifies the file that contains the slapd server # certificate. TLSCertificateFile /opt/symas/etc/openldap/ldap-server1-4-cert.pem # # TLSCertificateKeyFile <filename> # Specifies the file that contains the slapd server # private key that matches the certificate stored in the # TLSCertificateFile file. Currently, the private key # must not be protected with a password, so it is of # critical importance that it is protected carefully. TLSCertificateKeyFile /opt/symas/etc/openldap/ldap-server1-4-key.pem # # TLSRandFile <filename> # Specifies the file from which to obtain random bits when # /dev/[u]random is not available. Generally set to the # name of the EGD/PRNGD socket. The environment variable # RANDFILE can also be used to specify the filename. #TLSRandFile /var/symas/egd-pool TLSVerifyClient never pidfile /var/symas/slapd.pid argsfile /var/symas/slapd.args modulepath /opt/symas/lib/openldap moduleload back_bdb.la moduleload syncprov.la moduleload back_ldap.la moduleload back_meta.la moduleload back_monitor.la # Access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn="" by * read access to * by self write by users read by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! ####################################################################### # Logging configuration loglevel none ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=nisdata" rootdn "ou=nisdata" rootpw xxxxxx # Indices to maintain. index default eq index objectClass index cn,sn,uid index uidNumber,gidNumber,memberUid,uniqueMember index oncRpcNumber,ipServicePort,ipServiceProtocol index ipNetworkNumber,ipHostNumber,ipProtocolNumber index entryCSN index entryUUID directory /var/symas/openldap-data/my-customer-nis cachesize 5000 idlcachesize 5000 checkpoint 512 60 # syncrepl consumer # Note that RIDs in mirrormode pair must be identical syncrepl rid=7 provider=ldaps://server01.my-customer.com searchbase=ou=nisdata type=refreshAndPersist retry="30 +" bindmethod=simple binddn=ou=nisdata credentials=xxxxxx tls_cacertdir=/opt/symas/ssl/certs tls_cert=/opt/symas/etc/openldap/ldap-server1-4-cert.pem tls_key=/opt/symas/etc/openldap/ldap-server1-4-key.pem tls_reqcert=demand syncdata=default # syncrepl Provider overlay syncprov syncprov-checkpoint 1000 60 mirrormode on ####################################################################### # Definitions for proxy and cache to AD ####################################################################### database meta suffix "dc=my-customer,dc=com" rootdn "cn=proxy,dc=my-customer,dc=com" rootpw xxxxxx limits users time.soft=30 time.hard=soft # The link to AD: uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com ldaps://ldap-prd-dc02.my-customer.com/ # Switch(es) we need for this target rewriteEngine on chase-referrals no conn-ttl 300 network-timeout 10 pseudoroot-bind-defer yes idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=my-customer,dc=com" # We are putting the AD information under 'dc=ad' because it's going to # end up there in an upcoming change to the AD environment. This is also # a good thing because it helps back-meta unambiguously resolve references # to the AD target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=ad,dc=my-customer,dc=com"). This suffixmassage can be removed when that # change has been made in AD. suffixmassage "dc=ad,dc=my-customer,dc=com" "dc=my-customer,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map objectClass posixAccount user map attribute uid samAccountName map attribute "" gecos map attribute gecos displayName map attribute homeDirectory unixHomeDirectory map attribute "" homeDirectory map attribute shadowLastChange pwdLastSet map attribute cn * map attribute gidNumber * map attribute sn * map attribute uidNumber * map attribute loginShell * map attribute "" accountExpires map attribute "" badPasswordTime map attribute "" badPwdCount map attribute "" codePage map attribute "" company map attribute "" countryCode map attribute "" department map attribute "" distinguishedName map attribute "" homeDrive map attribute "" initials map attribute "" instanceType map attribute "" lastLogoff map attribute "" lastLogon map attribute "" lastLogonTimeStamp map attribute "" logonCount #map attribute "" memberOf map attribute "" name map attribute "" objectCategory map attribute "" objectGuid map attribute "" objectSid map attribute "" primaryGroupId map attribute "" samAccountType map attribute "" userAccountControl map attribute "" userPrincipalName map attribute "" usnChanged map attribute "" usnCreated map attribute "" whenChanged map attribute "" whenCreated map attribute "" dscoRepropagationData map attribute "" groupType map objectClass posixGroup group # # The link to the NIS data directory (yes, we could chain/glue, that's # for later) uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com # Switch(es) needed for this target rewriteEngine on idassert-authzFrom "cn=proxy,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" credentials=xxxxxxx mode=legacy # We are putting the NIS information under 'dc=nis' so that back-meta can # unambiguously resolve references to the NIS target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=nis,dc=my-customer,dc=com"). suffixmassage "dc=nis,dc=my-customer,dc=com" "ou=nisdata" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map attribute member uniqueMember ####################################################################### # Monitor database ####################################################################### database monitor

1 0

← Newer
1
...
23
24
25
26
27
28
29
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009