- openldap-bugs - openldap.org

(ITS#6891) pcache crashes after 2.4.25 upgrade; complains of unclean shutdowns and missing DB_CONFIGs after every restart
by tgates81＠gmail.com 05 Apr '11

05 Apr '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.184.61.44) After upgrading from 2.4.24 to 2.4.25 my pcache overlay using hdb backend first failed to start with messages complaining about a missing suffix. Now that I've added one I'm getting the following message: hdb_db_open: database "dc=example,dc=com": unclean shutdown detected; attempting recovery. hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=example,dc=com". slapd starting bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery last message repeated 3 times But DB_CONFIG does exist and has proper permissions and the unclean shutdown message repeats after every restart. I've never had to add the suffix to the pcache backend database before and the documentation examples (http://www.openldap.org/doc/admin24/proxycache.html) never mention it either. PCACHE OVERLAY: dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: hdb 100000 3 1000 100 olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber cn homeDirectory logi nShell gecos description memberUid uniqueMember objectClass olcPcacheAttrset: 1 cn automountInformation olcPcacheAttrset: 2 cn mail olcPcacheTemplate: "(|(cn=)(mail=)(sn=))" 2 7200 0 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(cn=)(cn=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(cn=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(|(cn=)(gidNumber=)))" 1 3600 600 0 0 olcPcacheTemplate: "(&(objectClass=)(gidNumber=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uidNumber=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uniqueMember=))" 0 1800 900 0 0 olcPcacheTemplate: "(&(objectClass=)(memberUid=))" 0 1800 900 0 0 olcPcacheTemplate: "(objectClass=)" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(cn=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(uid=))" 0 1800 0 0 0 olcPcacheTemplate: "(&(objectClass=)(|(memberUid=)(uniqueMember=)))" 0 1800 0 0 0 olcPcachePosition: tail olcPcacheMaxQueries: 10000 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: FALSE HDB backend: dn: olcDatabase={0}hdb objectClass: olcHdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}hdb olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 3000 olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 createTimestamp: 20110225174535Z olcDbConfig: {0}set_cachesize 0 10485760 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE olcDbConfig: {4}set_lg_max 10485760 olcDbIndex: objectClass eq olcDbIndex: cn eq,subinitial olcDbIndex: uid eq,subinitial olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: userPassword eq olcDbIndex: description eq olcDbIndex: loginShell eq olcDbIndex: homeDirectory eq olcDbIndex: memberUid eq olcDbIndex: gecos eq olcDbIndex: automountInformation eq olcDbIndex: uniqueMember eq olcDbIndex: mail eq,subinitial olcDbIndex: sn eq,subinitial olcDbIndex: givenName eq,subinitial olcDbIndex: member eq olcDbIndex: nisMapName eq olcDbIndex: pcacheQueryID eq olcSuffix: dc=example,dc=com slapd doesn't actually 'crash' as in stops running but querying is rendered useless. Here's the output from gdb: >>> slap_listener(ldapi:///) daemon: listen=9, new connection on 12 daemon: added 12r (active) listener=(nil) conn=1000 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0xb891a5a0 ptr=0xb891a5a0 end=0xb891a5ac len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ op tag 0x60, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0xb891a5a0 ptr=0xb891a5a3 end=0xb891a5ac len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0xb891a5a0 ptr=0xb891a5aa end=0xb891a5ac len=2 0000: 00 00 .. >>> dnPrettyNormal: <> daemon: activity on 1 descriptor <<< dnPrettyNormal: <>, <> conn=1000 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=1000 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=1000 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 02 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 16 64 63 3d 63 61 73 74 6c 65 62 72 61 6e 63 68 .dc=castlebranch 0010: 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 02 01 00 ,dc=com......... 0020: 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 69 64 04 ............uid. 0030: 07 74 6a 67 61 74 65 73 30 04 04 02 64 6e .tjgates0...dn ber_get_next: tag 0x30 len 68 contents: ber_dump: buf=0xb891a570 ptr=0xb891a570 end=0xb891a5b4 len=68 0000: 02 01 02 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 ...c?..dc=castle 0010: 62 72 61 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 branch,dc=com... 0020: 0a 01 03 02 01 00 02 01 00 01 01 00 a0 10 a3 0e ................ 0030: 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 30 04 ..uid..tjgates0. 0040: 04 02 64 6e ..dn op tag 0x63, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0xb891a570 ptr=0xb891a573 end=0xb891a5b4 len=65 0000: 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 62 72 61 c?..dc=castlebra 0010: 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 nch,dc=com...... 0020: 02 01 00 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 ...............u 0030: 69 64 04 07 74 6a 67 61 74 65 73 30 04 04 02 64 id..tjgates0...d 0040: 6e n >>> dnPrettyNormal: <dc=castlebranch,dc=com> => ldap_bv2dn(dc=castlebranch,dc=com,0) <= ldap_bv2dn(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 <<< dnPrettyNormal: <dc=castlebranch,dc=com>, <dc=castlebranch,dc=com> SRCH "dc=castlebranch,dc=com" 2 3 0 0 0 begin get_filter AND begin get_filter_list daemon: activity on 1 descriptor begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a59e end=0xb891a5b4 len=22 0000: a3 0e 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 ....uid..tjgates 0010: 30 04 04 02 64 6e 0...dn end get_filter 0 end get_filter_list end get_filter 0 filter: (&(uid=tjgates)) ber_scanf fmt ({M}}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a5ae end=0xb891a5b4 len=6 0000: 00 04 04 02 64 6e ....dn attrs: dn conn=1000 op=1 SRCH base="dc=castlebranch,dc=com" scope=2 deref=3 filter="(&(uid=tjgates))" conn=1000 op=1 SRCH attr=dn ==> limits_get: conn=1000 op=1 self="[anonymous]" this="dc=castlebranch,dc=com" => hdb_search bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=80 matched="" text="internal error" send_ldap_response: msgid=2 tag=101 err=80 ber_flush2: 28 bytes to sd 12 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error ldap_write: want=28, written=28 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error conn=1000 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1000 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xb88fc8f8 ptr=0xb88fc8f8 end=0xb88fc8fd len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1302056893 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1000 op=2 do_unbind conn=1000 op=2 UNBIND connection_closing: readying conn=1000 sd=12 for close connection_resched: attempting closing conn=1000 sd=12 connection_close: conn=1000 sd=12 =>ldap_back_conn_destroy: fetching conn 1000 daemon: removing 12 conn=1000 fd=12 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(9): daemon: epoll: listen=9 busy >>> slap_listener(ldapi:///) daemon: listen=9, new connection on 12 daemon: added 12r (active) listener=(nil) conn=1001 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0xb891acc8 ptr=0xb891acc8 end=0xb891acd4 len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ op tag 0x60, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0xb891acc8 ptr=0xb891accb end=0xb891acd4 len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0xb891acc8 ptr=0xb891acd2 end=0xb891acd4 len=2 0000: 00 00 .. >>> dnPrettyNormal: <> daemon: activity on 1 descriptor <<< dnPrettyNormal: <>, <> conn=1001 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=1001 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=8 0000: 30 44 02 01 02 63 3f 04 0D...c?. ldap_read: want=62, got=62 0000: 16 64 63 3d 63 61 73 74 6c 65 62 72 61 6e 63 68 .dc=castlebranch 0010: 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 02 01 00 ,dc=com......... 0020: 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 69 64 04 ............uid. 0030: 07 74 6a 67 61 74 65 73 30 04 04 02 64 6e .tjgates0...dn ber_get_next: tag 0x30 len 68 contents: ber_dump: buf=0xb891a570 ptr=0xb891a570 end=0xb891a5b4 len=68 0000: 02 01 02 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 ...c?..dc=castle 0010: 62 72 61 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 branch,dc=com... 0020: 0a 01 03 02 01 00 02 01 00 01 01 00 a0 10 a3 0e ................ 0030: 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 30 04 ..uid..tjgates0. 0040: 04 02 64 6e ..dn op tag 0x63, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0xb891a570 ptr=0xb891a573 end=0xb891a5b4 len=65 0000: 63 3f 04 16 64 63 3d 63 61 73 74 6c 65 62 72 61 c?..dc=castlebra 0010: 6e 63 68 2c 64 63 3d 63 6f 6d 0a 01 02 0a 01 03 nch,dc=com...... 0020: 02 01 00 02 01 00 01 01 00 a0 10 a3 0e 04 03 75 ...............u 0030: 69 64 04 07 74 6a 67 61 74 65 73 30 04 04 02 64 id..tjgates0...d 0040: 6e n >>> dnPrettyNormal: <dc=castlebranch,dc=com> daemon: activity on 1 descriptor => ldap_bv2dn(dc=castlebranch,dc=com,0) <= ldap_bv2dn(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=castlebranch,dc=com)=0 <<< dnPrettyNormal: <dc=castlebranch,dc=com>, <dc=castlebranch,dc=com> SRCH "dc=castlebranch,dc=com" 2 3 0 0 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a59e end=0xb891a5b4 len=22 0000: a3 0e 04 03 75 69 64 04 07 74 6a 67 61 74 65 73 ....uid..tjgates 0010: 30 04 04 02 64 6e 0...dn end get_filter 0 end get_filter_list end get_filter 0 filter: (&(uid=tjgates)) ber_scanf fmt ({M}}) ber: ber_dump: buf=0xb891a570 ptr=0xb891a5ae end=0xb891a5b4 len=6 0000: 00 04 04 02 64 6e ....dn attrs: dn conn=1001 op=1 SRCH base="dc=castlebranch,dc=com" scope=2 deref=3 filter="(&(uid=tjgates))" conn=1001 op=1 SRCH attr=dn ==> limits_get: conn=1001 op=1 self="[anonymous]" this="dc=castlebranch,dc=com" => hdb_search bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery daemon: activity on: daemon: epoll: listen=9 active_threads=1 tvp=zero bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery bdb(dc=castlebranch,dc=com): PANIC: fatal region error detected; run recovery send_ldap_result: conn=1001 op=1 p=3 send_ldap_result: err=80 matched="" text="internal error" send_ldap_response: msgid=2 tag=101 err=80 ber_flush2: 28 bytes to sd 12 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error ldap_write: want=28, written=28 0000: 30 1a 02 01 02 65 15 0a 01 50 04 00 04 0e 69 6e 0....e...P....in 0010: 74 65 72 6e 61 6c 20 65 72 72 6f 72 ternal error conn=1001 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error daemon: activity on 1 descriptor daemon: activity on: 12r daemon: read active on 12 daemon: epoll: listen=9 active_threads=1 tvp=zero connection_get(12) connection_get(12): got connid=1001 connection_read(12): checking for input on id=1001 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xb88f9d00 ptr=0xb88f9d00 end=0xb88f9d05 len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1302056901 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=2 do_unbind conn=1001 op=2 UNBIND connection_closing: readying conn=1001 sd=12 for close connection_resched: attempting closing conn=1001 sd=12 connection_close: conn=1001 sd=12 =>ldap_back_conn_destroy: fetching conn 1001 daemon: removing 12 conn=1001 fd=12 closed daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=9 active_threads=0 tvp=NULL I don't know if it is related but I have been having crashing issues with previous versions of openldap using pcache which I have submitted and ITS(6878) for: http://www.openldap.org/its/index.cgi/Incoming?selectid=6878;statetype=-1

1 0

(ITS#6890) SHA2 Password Hashing not working
by sudharma.thikkavarapu＠siemens.com 04 Apr '11

04 Apr '11

Full_Name: SUDHARMA Version: $OpenLDAP: slapd 2.4.23 (Apr 4 2011 13:48:06) OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.134.39.30) Hello, we are planning to encrypt the password using SHA2 so i have followed the steps that are required to use slapd-modules/passwd/sha2 in openLDAP code. I have modified the slapd.conf file to load the correct libraries etc.. when i try to generate the hash value for a password i get the following error. testdev# slappasswd -h {SHA512} New password: Re-enter new password: Password generation failed for scheme {SHA512}: scheme not recognized I have to mention that i had problems compiling the sha2 source code with the cc compiler but when i use the xlc i had no issues and compiled the source successfully. Here are the commands xlc -I/home/openldap-2.4.23/include -g -c slapd-sha2.c xlc -I/home/openldap-2.4.23/include -g -c sha2.c xlc -G -I/home/openldap-2.4.23/include -g sha2.o slapd-sha2.o -o slapd-sha2.so hope i haven't done anything wrong. Please suggest me how to make this work. Thank you much for your help. Best Regards, Sudharma

1 0

(ITS#6889) client libraries not linked against libfetch when building with it
by delphij＠FreeBSD.org 04 Apr '11

04 Apr '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) When OpenLDAP is configured with fetch(3) support on FreeBSD, client libraries are not linked against libfetch.so, but rather link it against management binaries. This would cause problem when the consumer does not explicitly request libfetch.so linkage. We currently have a very brute force fix in FreeBSD port to solve this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/openldap24-server/files/pat…

1 0

Re: (ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

The reason we are running 5 clients (each with 10 threads) performing concurrent wildcard searches on "unindexed attributes", is purely and simply.... load testing. the test seems reasonable enough that (with our current configuration) slapd should be able to handle it with terminating with a 'SIGABRT'... am i wrong in assuming this? J

1 0

Re: (ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

Additional info about our server: we are running 32 bit for all installed /compiled programs Josiah

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 03 Apr '11

03 Apr '11

------=_Part_481677_474224743.1301865460773 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Just checking in.. Is there anything I can do to help? If it helps, running slapd in debug mode wouldn't crash on me after over 2 1/2 weeks of running. Maybe a race condition among all the different threads? -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. ------=_Part_481677_474224743.1301865460773 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'>Just checking in.. Is there anything I can do to help? If it helps, running slapd in debug mode wouldn't crash on me after over 2 1/2 weeks of running. Maybe a race condition among all the different threads? -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. </div></body></ html> ------=_Part_481677_474224743.1301865460773--

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 03 Apr '11

03 Apr '11

Update: The above report belongs to Version 2.4.24

1 0

(ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by jwebb＠localnet.com 03 Apr '11

03 Apr '11

Full_Name: Josiah Webb Version: 2.4.23 OS: Debian Lenny (5.0.2) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (146.115.147.2) When running 5 concurrent ldapsearch clients (each with 10 concurrent threads) for unindexed attributes, slapd terminates with a SIGABRT about 3/4 of the way through all dn's. here is the gdb interpreted core file dump and backtrace: ----------------------------------------------------------------- awesome@ldapmaster-dev:~$ gdb /usr/local/libexec/slapd core.12907 GNU gdb 6.8-debian Copyright (C) 2008 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 "i486-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/local/lib/libtcmalloc.so.0...done. Loaded symbols for /usr/local/lib/libtcmalloc.so.0 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/i686/cmov/libdl.so.2...done. Loaded symbols for /lib/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /lib/i686/cmov/libpthread.so.0...done. Loaded symbols for /lib/i686/cmov/libpthread.so.0 Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.8 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.8 Reading symbols from /lib/i686/cmov/libcrypt.so.1...done. Loaded symbols for /lib/i686/cmov/libcrypt.so.1 Reading symbols from /lib/i686/cmov/libresolv.so.2...done. Loaded symbols for /lib/i686/cmov/libresolv.so.2 Reading symbols from /lib/i686/cmov/libc.so.6...done. Loaded symbols for /lib/i686/cmov/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/i686/cmov/libm.so.6...done. Loaded symbols for /lib/i686/cmov/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/i686/cmov/libnss_files.so.2...done. Loaded symbols for /lib/i686/cmov/libnss_files.so.2 Core was generated by `/usr/local/libexec/slapd -d -1'. Program terminated with signal 6, Aborted. [New process 12911] [New process 12935] [New process 12934] [New process 12933] [New process 12932] [New process 12931] [New process 12930] [New process 12929] [New process 12928] [New process 12927] [New process 12926] [New process 12925] [New process 12924] [New process 12912] [New process 12907] [New process 12910] [New process 12909] [New process 12908] #0 0xb7f43424 in __kernel_vsyscall () (gdb) backtrace #0 0xb7f43424 in __kernel_vsyscall () #1 0xb7a7c640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7a7e018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7a755be in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0x0809853b in ch_malloc (size=1407) at ch_malloc.c:57 #5 0x08132a7a in hdb_id2entry (be=0x15ef5f64, tid=0xbb232d0, id=170395, e=0x15e35d08) at id2entry.c:143 #6 0x08128fea in hdb_cache_find_id (op=0xc429000, tid=0xbb232d0, id=170395, eip=0x15ef5eec, flag=2, lock=0x15ef5e44) at cache.c:998 #7 0x08103923 in hdb_search (op=0xc429000, rs=0x15ef7148) at search.c:707 #8 0x080e40dc in overlay_op_walk (op=0xc429000, rs=0x15ef7148, which=op_search, oi=0x9e39100, on=0x9e39400) at backover.c:669 #9 0x080e4ba1 in over_op_func (op=0xc429000, rs=0x15ef7148, which=op_search) at backover.c:721 #10 0x0807dc63 in fe_op_search (op=0xc429000, rs=0x15ef7148) at search.c:366 #11 0x0807e4d8 in do_search (op=0xc429000, rs=0x15ef7148) at search.c:217 #12 0x0807b546 in connection_operation (ctx=0x15ef7228, arg_v=0xc429000) at connection.c:1109 #13 0x0807c17f in connection_read_thread (ctx=0x15ef7228, argv=0x13) at connection.c:1245 #14 0x081590ec in ldap_int_thread_pool_wrapper (xpool=0x9e0a0b0) at tpool.c:685 #15 0xb7d924c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #16 0xb7b316de in clone () from /lib/i686/cmov/libc.so.6 --------------------------------------------------------------- the slapd standard log (/var/log/syslog), logged no errors whatsoever, slapd simply "stopped: no "out of memory" issues either free -m (taken at the exact time of the SIGABRT): total used free shared buffers cached Mem: 8115 7492 623 0 226 1895 -/+ buffers/cache: 5370 2744 Swap: 2055 0 2055 Running a freshly compiled 2.4.23 openldap, which was compiled against tcmalloc (malloc replacement) from google-perftools-1.7 (standard build commands: ./configure, make, make install (no errors) openldap compiled as follows: ./configure LDFLAGS="-fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -ltcmalloc" --enable-slapd --enable-bdb --enable-modules --enable-accesslog --enable-syncprov --enable-crypt --enable-cleartext --enable-syslog --enable-debug make depend make make test make install STRIP="" no errors during build. backend is Berkely DB 4.6.21-16, which contains the following patches: http://www.oracle.com/technetwork/database/berkeleydb/patch-098875.html slapd.conf as follows: ##################### # Global Directives # ##################### allow bind_v2 include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/qmail.schema include /usr/local/etc/openldap/schema/radius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync config none threads 16 gentlehup on sizelimit 500 tool-threads 4 backend hdb ############################## # Main Backend DB Directives # ############################## database hdb suffix "dc=localnet,dc=com" rootdn "cn=Manager,dc=localnet,dc=com" rootpw {SSHA}Kcv02GxN6YBuUVV+ct10VAxrc3c1iPei directory "/local/var/openldap-bdb" dbconfig set_cachesize 2 147483648 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 cachesize 50000 idlcachesize 200000 cachefree 1000 index objectClass eq index cn eq index sn eq index uid eq index mail eq index mailAlternateAddress eq index mailForwardingAddress eq index radiusUID eq index uidNumber eq index gidNumber eq index overquota eq index mailhost eq index entryCSN eq index entryUUID eq overlay accesslog logdb "cn=accesslog" logops writes logsuccess TRUE logpurge 02+00:00 01+00:00 overlay syncprov syncprov-checkpoint 10 5 checkpoint 1024 5 limits dn.exact="cn=Manager,dc=localnet,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ################################### # Accesslog Backend DB Directives # ################################### database hdb suffix "cn=accesslog" directory "/usr/local/var/openldap-data" dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /usr/local/var/openldap-data dbconfig set_tmp_dir /tmp dbconfig set_flags DB_LOG_AUTOREMOVE cachesize 2000 idlcachesize 8000 cachefree 100 checkpoint 1024 5 lastmod on index default eq index objectClass index entryCSN index reqEnd index reqResult index reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.exact="cn=Manager,dc=localnet,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ######################### # Access ACL Directives # ######################### access to * by dn="cn=Manager,dc=localnet,dc=com" write by * read by anonymous auth by self write # end slapd.conf Server is a 4 core Intel Xeon E5320 Debian Lenny box with 2.6.26-2-686-bigmem kernel and 8GB of physical memory. Our entire data set (.bdb) including indexes totals 1.3GB. we have a large enough set_cachesize to store our entire data set in memory. Our LDAP tree contains around 200,000 dn's please advise, or let me know if you need further details or information thanks!

1 0

(ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 02 Apr '11

02 Apr '11

Full_Name: Daniel Pluta Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:fe15::1) 1.) Following authz-regexp statement looks and works fine with slapd: authz-regexp uid=([^,]+)@([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain@user,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain@user,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain@user,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain@user,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain@user,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)@([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain@user,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user)'} slap_parseURI: parsing ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user) ldap_url_parse_ext(ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=user)) put_filter: "(mail=user)" put_filter: simple put_simple_filter: "mail=user" ber_scanf fmt ({mm}) ber: >>> dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> <<< dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> slap_sasl2dn: performing internal search (base=ou=users,ou=domain,dc=foo,dc=bar, scope=1) => hdb_search bdb_dn2entry("ou=users,ou=domain,dc=foo,dc=bar") => hdb_dn2id("ou=domain,dc=foo,dc=bar") ========================================================================== 1.) Following authz-regexp where the @-separator is replaced by a \-separator seems to cause problems: authz-regexp uid=([^,]+)\\([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" Looks strange: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain\5Cuser,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain\5Cuser,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)\([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain\5Cuser,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=domain\5Cuser,cn=digest-md5,cn=auth'} slap_parseURI: parsing uid=domain\5Cuser,cn=digest-md5,cn=auth ldap_url_parse_ext(uid=domain\5Cuser,cn=digest-md5,cn=auth) >>> dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> <==slap_sasl2dn: Converted SASL name to uid=domain\5Cuser,cn=digest-md5,cn=auth slap_sasl_getdn: dn:id converted to uid=domain\5Cuser,cn=digest-md5,cn=auth ========================================================================== 3. Just one more try to using "[\\]" instead of "\\" authz-regexp uid=([^,]+)[\\]([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth "ldap:///ou=users,ou=$1,dc=foo,dc=bar??one?(mail=$2)" Looks strange too: do_bind: dn () SASL mech DIGEST-MD5 SASL [conn=1000] Debug: DIGEST-MD5 server step 2 slap_sasl_getdn: u:id converted to uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=domain\5Cuser,cn=DIGEST-MD5,cn=auth> <<< dnNormalize: <uid=domain\5Cuser,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=domain\5Cuser,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=domain\5Cuser,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=([^,]+)[\]([^,]+),cn=(PLAIN|LOGIN|DIGEST-MD5|CRAM-MD5),cn=auth' string='uid=domain\5Cuser,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser)'} slap_parseURI: parsing ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser) ldap_url_parse_ext(ldap:///ou=users,ou=domain,dc=foo,dc=bar??one?(mail=5Cuser)) put_filter: "(mail=5Cuser)" put_filter: simple put_simple_filter: "mail=5Cuser" ber_scanf fmt ({mm}) ber: >>> dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> <<< dnNormalize: <ou=users,ou=domain,dc=foo,dc=bar> slap_sasl2dn: performing internal search (base=ou=users,ou=domain,dc=foo,dc=bar, scope=1)

1 0

[PATCH] More for ITS#6872
by cmikk＠qwest.net 30 Mar '11

30 Mar '11

[Note: The previous patch did not fix the problem when the consumer's access was restricted to the replicated subtree. This patch fixes that.] Perform the internal FIND_CSN search based at the backend's suffix with the privileges of the backend's root DN. --- servers/slapd/overlays/syncprov.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 0c148f9..a058e19 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -661,6 +661,8 @@ again: if ( BER_BVISEMPTY( &cf.f_av_value )) { cf.f_av_value = *csn; } + fop.o_dn = op->o_bd->be_rootdn; + fop.o_ndn = op->o_bd->be_rootndn; fop.o_req_dn = op->o_bd->be_suffix[0]; fop.o_req_ndn = op->o_bd->be_nsuffix[0]; /* Look for exact match the first time */ -- 1.7.1.1

1 0

(ITS#6886) slapo-dds: Wrong tag in Refresh Response
by michael＠stroeder.com 30 Mar '11

30 Mar '11

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (195.145.144.134) The Refresh Response sent back by slapo-dds contains tag [0] instead of [1] as described in section 4.2 of RFC 2589: The response field will contain as a value the DER-encoding of the following ASN.1 data type: SEQUENCE { responseTtl [1] INTEGER } If I assume [0] in my client when decoding it works...

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 30 Mar '11

30 Mar '11

Just crashed: Program received signal SIGABRT, Aborted. [Switching to Thread 0xb07f3b70 (LWP 24359)] 0xb77a7430 in __kernel_vsyscall () (gdb) (gdb) bt #0 0xb77a7430 in __kernel_vsyscall () #1 0xb727a651 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb727da82 in *__GI_abort () at abort.c:92 #3 0xb72b149d in __libc_message (do_abort=2, fmt=0xb7385f98 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb72bb591 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0xb8d93a40) at malloc.c:6266 #5 0xb72bcde8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4794 #6 0xb72bfecd in *__GI___libc_free (mem=0xb8d93a40) at malloc.c:3738 #7 0xb7750c20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 #8 0xb7750caf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 #9 0xb7750cf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 #10 0xb7808f3d in attr_clean (a=0xb688ff64) at /tmp/buildd/openldap-2.4.24/servers/slapd/attr.c:146 #11 0xb7808fdb in attrs_free (a=0xb688ff64) at /tmp/buildd/openldap-2.4.24/servers/slapd/attr.c:196 #12 0xb6e2db0f in hdb_cache_modify (bdb=0xb8c104b0, e=0xb8c57b5c, newAttrs=0xb688ed64, txn=0xb8d93ea8, lock=0xb07f11f0) at cache.c:1226 #13 0xb6e1901c in hdb_modify (op=0xb07f152c, rs=0xb07f1368) at modify.c:669 #14 0xb6e47258 in merge_entry (op=<value optimized out>, e=0xb8c58264, dup=0, query_uuid=0xb8c9b130) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:874 #15 0xb6e4effc in cache_entries (op=<value optimized out>, query_uuid=<value optimized out>) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:2291 #16 0xb6e4f3ed in pcache_op_cleanup (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/overlays/pcache.c:2396 #17 0xb78102ee in slap_cleanup_play (op=<value optimized out>, rs=<value optimized out>) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:539 #18 0xb7810fa9 in send_ldap_response (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:724 #19 0xb781209c in slap_send_ldap_result (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/result.c:851 #20 0xb6e6a987 in ldap_back_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/back-ldap/search.c:574 #21 0xb787802b in overlay_op_walk (op=0xb8c829d8, rs=0xb07f2ffc, which=op_search, oi=0xb8c10fe0, on=0xb8c10260) at /tmp/buildd/openldap-2.4.24/servers/slapd/backover.c:669 #22 0xb7878d58 in over_op_func (op=<value optimized out>, rs=<value optimized out>, which=op_search) at /tmp/buildd/openldap-2.4.24/servers/slapd/backover.c:721 #23 0xb7800b54 in fe_op_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/search.c:372 #24 0xb78014e7 in do_search (op=0xb8c829d8, rs=0xb07f2ffc) at /tmp/buildd/openldap-2.4.24/servers/slapd/search.c:217 #25 0xb77fd994 in connection_operation (ctx=0xb07f31dc, arg_v=0xb8c829d8) at /tmp/buildd/openldap-2.4.24/servers/slapd/connection.c:1113 #26 0xb77fe492 in connection_read_thread (ctx=0xb07f31dc, argv=0x28) at /tmp/buildd/openldap-2.4.24/servers/slapd/connection.c:1249 #27 0xb77634f4 in ?? () from /usr/lib/libldap_r-2.4.so.2 #28 0xb73af96e in start_thread (arg=0xb07f3b70) at pthread_create.c:300 #29 0xb731da4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) she gdb shell is still open, let me know if I can provide any further information. On 03/24/2011 01:34 PM, Quanah Gibson-Mount wrote: > --On Thursday, March 24, 2011 4:28 PM +0000 tjgates(a)castlebranch.com > wrote: > >> Full_Name: Tyler Gates >> Version: 2.4.21 >> OS: Ubuntu 10.04.2 LTS/CentOS 5.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.106.216.17) >> >> >> I have a caching proxy server (2.4.21) in front of two multi-masters. >> After about 1 to 3 days it will segfault only when caching is enabled. >> Log files are normally pretty useless but are normally in the operation >> of removing stale queries: > > Bug reports with 2.4.21 are not being pursued. Please use a current > release (2.4.24) and verify whether or not the issue still exists there. > > --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 -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

1 0

Re: (ITS#6885) Compile error in liblutil/meter.c without HAVE_GETTIMEOFDAY
by h.b.furuseth＠usit.uio.no 30 Mar '11

30 Mar '11

adam(a)anope.org writes: > Line 92 should be: > *now = (double) tm; Thanks. Fixed in the master branch. -- Hallvard

1 0

(ITS#6885) Compile error in liblutil/meter.c without HAVE_GETTIMEOFDAY
by adam＠anope.org 29 Mar '11

29 Mar '11

Full_Name: Adam Version: 2.4 OS: cygwin on Windows URL: Submission from: (NULL) (97.101.44.106) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… Line 92 should be: *now = (double) tm;

1 0

Re: (ITS#6884) contrib: password syntax checking overlay
by Kurt＠OpenLDAP.org 29 Mar '11

29 Mar '11

On Mar 29, 2011, at 2:11 PM, mathieu.baeumler(a)gmail.com wrote: > Full_Name: Mathieu Baeumler > Version: 2.4.24 > OS: Debian GNU/Linux > URL: ftp://ftp.openldap.org/incoming/mathieu-baeumler-110329.tgz > Submission from: (NULL) (94.252.66.219) > > > Hello, > > Please find a new overlay that enforces syntactic constraints on passwords. This > overlay can also be used in conjunction with the ppolicy overlay, as it > implements the check_password function. > > See the man page (slapo-pwdconstraint.5) for details on how to use it. > > Regards, > > Mathieu Baeumler > > /* > * Copyright 2011 Mathieu Baeumler, Dimension Data. All rights reserved. > * > * OIDs under 1.3.6.1.4.1.10076 courtesy of European Commission. This doesn't seem like text appropriately placed in a copyright notice. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted only as authorized by the OpenLDAP > * Public License. > * > * A copy of this license is available in the file LICENSE in the > * top-level directory of the distribution or, alternatively, at > * <http://www.OpenLDAP.org/license.html>. > */ Your submission lacks a notice of origin. Please review http://www.openldap.org/devel/contributing.html Please also note that git-format-patch(1) format submissions are now preferred. -- Kurt

1 0

[PATCH] ITS#6872
by cmikk＠qwest.net 29 Mar '11

29 Mar '11

--- servers/slapd/overlays/syncprov.c | 19 +++++++------------ 1 files changed, 7 insertions(+), 12 deletions(-) diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 3c64763..0c148f9 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -586,7 +586,7 @@ findpres_cb( Operation *op, SlapReply *rs ) } static int -syncprov_findcsn( Operation *op, find_csn_t mode ) +syncprov_findcsn( Operation *op, find_csn_t mode, struct berval *csn ) { slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; syncprov_info_t *si = on->on_bi.bi_private; @@ -659,15 +659,10 @@ again: break; case FIND_CSN: if ( BER_BVISEMPTY( &cf.f_av_value )) { - cf.f_av_value = srs->sr_state.ctxcsn[0]; - /* If there are multiple CSNs, use the smallest */ - for ( i=1; i<srs->sr_state.numcsns; i++ ) { - if ( ber_bvcmp( &cf.f_av_value, &srs->sr_state.ctxcsn[i] ) - > 0 ) { - cf.f_av_value = srs->sr_state.ctxcsn[i]; - } - } + cf.f_av_value = *csn; } + fop.o_req_dn = op->o_bd->be_suffix[0]; + fop.o_req_ndn = op->o_bd->be_nsuffix[0]; /* Look for exact match the first time */ if ( findcsn_retry ) { cf.f_choice = LDAP_FILTER_EQUALITY; @@ -2624,7 +2619,7 @@ no_change: if ( !(op->o_sync_mode & SLAP_SYNC_PERSIST) ) { } } /* Is the CSN still present in the database? */ - if ( syncprov_findcsn( op, FIND_CSN ) != LDAP_SUCCESS ) { + if ( syncprov_findcsn( op, FIND_CSN, &mincsn ) != LDAP_SUCCESS ) { /* No, so a reload is required */ /* the 2.2 consumer doesn't send this hint */ if ( si->si_usehint && srs->sr_rhint == 0 ) { @@ -2648,7 +2643,7 @@ no_change: if ( !(op->o_sync_mode & SLAP_SYNC_PERSIST) ) { } else { gotstate = 1; /* If changed and doing Present lookup, send Present UUIDs */ - if ( do_present && syncprov_findcsn( op, FIND_PRESENT ) != + if ( do_present && syncprov_findcsn( op, FIND_PRESENT, 0 ) != LDAP_SUCCESS ) { if ( ctxcsn ) ber_bvarray_free_x( ctxcsn, op->o_tmpmemctx ); @@ -2976,7 +2971,7 @@ syncprov_db_otask( void *ptr ) { - syncprov_findcsn( ptr, FIND_MAXCSN ); + syncprov_findcsn( ptr, FIND_MAXCSN, 0 ); return NULL; } -- 1.7.1.1

1 0

(ITS#6884) contrib: password syntax checking overlay
by mathieu.baeumler＠gmail.com 29 Mar '11

29 Mar '11

Full_Name: Mathieu Baeumler Version: 2.4.24 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/mathieu-baeumler-110329.tgz Submission from: (NULL) (94.252.66.219) Hello, Please find a new overlay that enforces syntactic constraints on passwords. This overlay can also be used in conjunction with the ppolicy overlay, as it implements the check_password function. See the man page (slapo-pwdconstraint.5) for details on how to use it. Regards, Mathieu Baeumler /* * Copyright 2011 Mathieu Baeumler, Dimension Data. All rights reserved. * * OIDs under 1.3.6.1.4.1.10076 courtesy of European Commission. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. */

1 0

Re: (ITS#6883) Improved Makefiles for contrib modules
by quanah＠zimbra.com 29 Mar '11

29 Mar '11

--On Tuesday, March 29, 2011 3:25 PM +0000 bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.124.16) > > > While the code in contrib is not supported, some overlays provide make > files, some don't, and there were variations in a lot of the make files > (e.g. use of DESTDIR or not). > > In order to add make files for overlays that don't have them, improve the > consistency of the make files between overlays that had them, and to > provide some basic sanity testing in a 'test' target, I have created the > patch at: > http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap/curre > nt/SOURCES/openldap-2.4.25-contrib-makefiles-with-tests.patch?revision=64 > 8744&view=markup > > The patch is against 2.4.25, but should apply to master (except that > there two additional overlays are present in master). Where feasible I > have retained the majority of an existing make file, in other cases, > where modifications would exceed the original content, I have replaced > existing make files wholesale. > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) > were developed by Buchan Milne (bgmilne(a)staff.telkomsa.net). I have not > assigned rights and/or interest in this work to any party. Hi Buchan, Can you make the patch available via git-format-patch? Thanks, 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

Re: Another fix for (ITS#6872)
by quanah＠zimbra.com 29 Mar '11

29 Mar '11

--On Tuesday, March 29, 2011 5:46 PM +0000 cmikk(a)qwest.net wrote: > I've corrected the above patch (si->si_contextdn was only > coincidentally the correct value to use there), combined > it with the previous patch, and posted the result at: > > http://mikk.net/~chris/syncprov/patch-syncprov.c Hi Chris, We just finished our migration to git. As git is now available, patches via git-format-patch are now preferred. Thanks! --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

Re: Another fix for (ITS#6872)
by cmikk＠qwest.net 29 Mar '11

29 Mar '11

I've corrected the above patch (si->si_contextdn was only coincidentally the correct value to use there), combined it with the previous patch, and posted the result at: http://mikk.net/~chris/syncprov/patch-syncprov.c Thanks, -Chris

1 0

(ITS#6883) Improved Makefiles for contrib modules
by bgmilne＠staff.telkomsa.net 29 Mar '11

29 Mar '11

Full_Name: Buchan Milne Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.124.16) While the code in contrib is not supported, some overlays provide make files, some don't, and there were variations in a lot of the make files (e.g. use of DESTDIR or not). In order to add make files for overlays that don't have them, improve the consistency of the make files between overlays that had them, and to provide some basic sanity testing in a 'test' target, I have created the patch at: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap/current… The patch is against 2.4.25, but should apply to master (except that there two additional overlays are present in master). Where feasible I have retained the majority of an existing make file, in other cases, where modifications would exceed the original content, I have replaced existing make files wholesale. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Buchan Milne (bgmilne(a)staff.telkomsa.net). I have not assigned rights and/or interest in this work to any party.

1 0

Re: (ITS#6882) Mirror in Hamburg, germany
by Kurt Zeilenga 29 Mar '11

29 Mar '11

While we appreciate your re-newed offer, as our needs have not changed we continue not to accept new official mirrors. This, and well as your previous offer, will remain on file in case our needs do change. Regards, Kurt

1 0

(ITS#6882) Mirror in Hamburg, germany
by mirror＠artfiles.org 29 Mar '11

29 Mar '11

Full_Name: Andreas Worbs Version: OS: URL: Submission from: (NULL) (80.252.98.63) Hi, i wrote you a few months ago about our mirror but you weren't interested. So i want to ask you if you are interested now? Our mirror is in Hamburg, Germany and has a bandwith of 1 Gbit/s. The URLs: http://artfiles.org/openldap.org/ ftp://artfiles.org/openldap.org/

1 0

Re: (ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by h.b.furuseth＠usit.uio.no 29 Mar '11

29 Mar '11

Note, this bug is not related to auxiliary classes. The same thing happens if you add a superclass like 'top' instead of extensibleObject. ali.pouya(a)free.fr writes: > Can someone help me about this problem ? > We use Samba in our project and it needs some auxiliary classes which > disappear in this configuration. > The design of my project depends on the correction of this bug. OpenLDAP is volunteer-driven, currently busy with migration from CVS to Git, and we'll get to the bug when we get to it. If you can't wait to see if that'll be soon, the openldap-technical mailinglist has a wider readership than the bug database. Maybe your problem can be solved differently if you describe what you want in more detail, and someone there can think of how: http://www.openldap.org/lists/mm/listinfo/openldap-technical Or you can pay someone to fix the bug: http://www.openldap.org/support/ I can think of a things to try myself. Maybe you can rearrange your setup to put rwm on another database, or maybe it's a recent bug and it works with an earlier OpenLDAP version. -- Hallvard

1 0

Re: (ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by ali.pouya＠free.fr 29 Mar '11

29 Mar '11

Hi all, Can someone help me about this problem ? We use Samba in our project and it needs some auxiliary classes which disappear in this configuration. The design of my project depends on the correction of this bug. Thanks a lot Best Regards Ali Pouya

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs