openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(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

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

05 Feb '09

Using valgrind, I note few issues conn=0 op=1 MODRDN dn="olcDatabase={2}bdb,cn=config" ==17038== Thread 3: ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715C1: config_rename_kids (bconfig.c:3816) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F140 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071583: config_rename_kids (bconfig.c:3814) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715EE: config_rename_kids (bconfig.c:3818) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F1A0 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071594: config_rename_kids (bconfig.c:3815) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) conn=0 op=1 RESULT tag=109 err=0 text= which eventually result in the screwed name of the children entries of the renamed database. I'm investigating... 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ando＠sys-net.it 05 Feb '09

05 Feb '09

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 :) 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by gavin.henry＠gmail.com 05 Feb '09

05 Feb '09

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? I'll make the same anyway. Thanks. On 05/02/2009, quanah(a)zimbra.com <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Awww, aren't we nice! ;-) >> >> Patch applied, > > The new patch is definitely an improvement, however it fails to document > the hexadecimal notation for log levels, which is also perfectly valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) > > > and the description therein: > > The desired log level can be input as a single integer that > combines the (ORed) desired levels, both in decimal or in > hexadecimal notation, as a list of integers (that are ORed > internally), or as a list of the names that are shown between > brackets, such that > > loglevel 129 > loglevel 0x81 > loglevel 128 1 > loglevel 0x80 0x1 > loglevel acl trace > > are equivalent. > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Fixed in HEAD for back-bdb & back-hdb; back-ldif does not suffer from this issue. proxy backends and so should neither. Not sure about other backends like back-sql and back-ndb. 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

Re: (ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > A fix is coming (hopefully for 2.4.14 :). p. Fixed in HEAD. 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) [backend config] glue: no superior found in N-Way Multi-Master replication
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) When : when a replica replicates its entire cn=config from a provider, and the configuration has gluing databases. Suppose you have into your config backend the following : 8<-------- dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://1.2.3.4/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 olcSyncrepl: {1}rid=002 provider=ldap://1.2.3.5/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 [...] dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config [...] dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config [...] 8<-------- slaptest passes successfully, and OpenLDAP starts. When a new provider joins the N-Way Multi-Master replication, it replicates all the configuration from the primary provider (which is indicated in its minimalistic configuration). But, the replication failed on the following error : 8<-------- Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_search (0) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 olcDatabase={2}ldap,cn=config Feb 5 18:25:04 server2 slapd[6202]: glue: no superior found for sub o=1,o=2! Feb 5 18:25:04 server2 slapd[6202]: olcSubordinate: value #0: <olcSubordinate> handler exited with 32! Feb 5 18:25:04 server2 slapd[6202]: null_callback : error code 0x50 Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add (80) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add failed (80) Feb 5 18:25:04 server2 slapd[6202]: do_syncrepl: rid=001 retrying 8<-------- It appears that ldap's backend which is subordinate to an other backend should be declared after this gluing database. This is exactly the contrary on how works slapd.conf. Thomas.

1 0

(ITS#5924) [backend config] modify rdn on a backend entry will cause bad renaming of all subentries when retrieving by ldapsearch
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Renaming an entry of a configugred OpenLDAP backend causes bad renaming of its subentries and all subentries of all other backends, when retrieving them by a simple LDAP search. For example, suppose you have these configuration into slapd.conf : 8<-------- database bdb suffix "o=1" directory /usr/local/openldap-2.4/var/openldap-data-1 overlay rwm rwm-suffixmassage o=1 dc=1 database bdb suffix "o=2" overlay glue rootdn "cn=Directory Manager,o=2" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-2 database bdb suffix "o=3" rootdn "cn=Directory Manager,o=3" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-3 8<-------- When you convert slapd.conf to slapd.d (backend config), then you should obtain something like the following (slapcat -b cn=config -F ...) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=1 [...] dn: olcOverlay={0}rwm,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}glue dn: olcDatabase={4}bdb,cn=config olcSuffix: o=3 [...] 8<-------- Now, for some reason, you want to rename olcDatabase={2}bdb,cn=config into olcDatabase={3}bdb,cn=config (to invert declaration for example). This operation works successfully but causes all subentries DN to be rename improperly. You obtain someting like the following via ldapsearch (not via slapcat) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn:: IHFbGSxvbGNEYXRhYmFzZT17Mn1iZGIsY249Y29uZmlnAGJkYixjbj1jb25maWc= objectClass: olcOverlayConfig olcOverlay: {0}glue [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=1 [...] dn:: LG9sY0RhdGFiYXNlPXszfWJkYixjbj1jb25maWcAezJ9YmRiLGNuPWNvbmZpZw== objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={4}bdb,cn=config [...] 8<-------- When decoding DN, we obtain bad characters. This issue provide broken replication in a N-Way Multi-Master cluster. Thomas.

1 0

Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

adrien.futschik(a)atosorigin.com wrote: > >> No. Replication is supposed to work regardless of mode, refreshOnly / >> refreshAndPersist should yield identical results. > ... > >> There is still a bug here. > > You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? > > But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? > > What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? I would wait for 2.4.14. -- 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/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

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

05 Feb '09

--On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > Awww, aren't we nice! ;-) > > Patch applied, The new patch is definitely an improvement, however it fails to document the hexadecimal notation for log levels, which is also perfectly valid. See slapd.conf(5): 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging (function args) and the description therein: The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that loglevel 129 loglevel 0x81 loglevel 128 1 loglevel 0x80 0x1 loglevel acl trace are equivalent. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, 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