- openldap-bugs - openldap.org

Re: (ITS#7210) back-mdb endless database growth
by hyc＠symas.com 20 Mar '12

20 Mar '12

hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.30 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> If you create a script to add& delete the same 50,000 users, and then re-run >> that script multiple times, the MDB database on disk continues to grow, despite >> the fact that we are only adding and deleting the same data repeatedly. There >> should be zero growth to the database. >> >> Instead, the data.mdb file went from 108MB in size to over 1.2GB after 5-6 runs. >> Time to add/delete all the users went from 3 minutes 32 seconds on the first >> run to over 90 minutes on the final run (5th or 6th, I lost count). > > At present, MDB is working as intended. In your test a number of overflow > pages are being used. Currently libmdb always allocates overflow pages from > new space, because it's not smart enough to search the free list for > contiguous pages. Can treat this ITS as an enhancement request for that > purpose, but this is not a new issue nor is it unexpected in the current > version of MDB. > Hm, I take this back. The overflow pages are not enough to account for the difference. Still looking. -- -- 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#7210) back-mdb endless database growth
by hyc＠symas.com 20 Mar '12

20 Mar '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.30 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > If you create a script to add& delete the same 50,000 users, and then re-run > that script multiple times, the MDB database on disk continues to grow, despite > the fact that we are only adding and deleting the same data repeatedly. There > should be zero growth to the database. > > Instead, the data.mdb file went from 108MB in size to over 1.2GB after 5-6 runs. > Time to add/delete all the users went from 3 minutes 32 seconds on the first > run to over 90 minutes on the final run (5th or 6th, I lost count). At present, MDB is working as intended. In your test a number of overflow pages are being used. Currently libmdb always allocates overflow pages from new space, because it's not smart enough to search the free list for contiguous pages. Can treat this ITS as an enhancement request for that purpose, but this is not a new issue nor is it unexpected in the current version of MDB. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 20 Mar '12

20 Mar '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120319-back-config-slapmodi… Submission from: (NULL) (62.168.56.1) For slapmodify to be usable on a database, that database needs to implement the bi_tool_dn2id_get and bi_tool_entry_modify functions, which is not the case of the back-config. I've put together a minimal (and maybe too naive) implementation of these for back-config and back-ldif at the above link. Currently, there is no validation whether the modification passes back-config checks since config_modify_internal takes a modify operation, while bi_tool_entry_modify receives only the new version of the entry to be modified. Also, for slapmodify to be really useful, it would have to allow entry deletion, for which there is no tool mode callback. To implement deletes, do you think it is better that deletion of an entry with children fail or delete the entire subtree? While the former seems both easier to implement and more sensible to me, I would like your know opinion. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7211) mdb inconsistency without LAZY_LOCKS
by h.b.furuseth＠usit.uio.no 19 Mar '12

19 Mar '12

I wrote: > I'm sleeping for write transactions only since that's when the > inconsistent copy is written back to disk. Please ignore that, that was another too-paranoid patch -- Hallvard

1 0

(ITS#7211) mdb inconsistency without LAZY_LOCKS
by h.b.furuseth＠usit.uio.no 19 Mar '12

19 Mar '12

Full_Name: Hallvard B Furuseth Version: master, af3a23a1ec93220be392a8ea6372475b7357c171 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard A write transaction can overwrite env->me_metas[]->mm_dbs, me_numdbs and me_dbxs while another txn is copying them in mdb_txn_renew0(), resulting in an inconsistent copy. '#define LAZY_LOCKS 0' fixes it. Without it, test054 dumps core with this patch: diff --git a/libraries/libmdb/mdb.c b/libraries/libmdb/mdb.c index b714119..5e22827 100644 --- a/libraries/libmdb/mdb.c +++ b/libraries/libmdb/mdb.c @@ -1519,2 +1519,4 @@ mdb_txn_renew0(MDB_txn *txn) memcpy(txn->mt_dbs, env->me_metas[txn->mt_toggle]->mm_dbs, 2 * sizeof(MDB_db)); + if ((rand() & 1)) usleep(100000); + assert(!memcmp(txn->mt_dbs, env->me_metas[txn->mt_toggle]->mm_dbs, 2 * sizeof(MDB_db))); if (txn->mt_numdbs > 2) I'm sleeping for write transactions only since that's when the inconsistent copy is written back to disk.

1 0

(ITS#7210) back-mdb endless database growth
by quanah＠OpenLDAP.org 19 Mar '12

19 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If you create a script to add & delete the same 50,000 users, and then re-run that script multiple times, the MDB database on disk continues to grow, despite the fact that we are only adding and deleting the same data repeatedly. There should be zero growth to the database. Instead, the data.mdb file went from 108MB in size to over 1.2GB after 5-6 runs. Time to add/delete all the users went from 3 minutes 32 seconds on the first run to over 90 minutes on the final run (5th or 6th, I lost count).

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by ghenry＠suretecsystems.com 19 Mar '12

19 Mar '12

It is on the list for updating and a migration section. -- 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: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html On 19 Mar 2012, at 14:51, Bruno Schrade <bs(a)schwarzwald-software.de> wrote: > Sehr geehrter Herr Henry, > > i just moved an OpenLDAP-Server from Debian-5 to Debian-6. Expecting it would simply run using the same configuration file i just copied slapd.conf. This resulted in error messages along the line "missing credentials". So i looked up the QuickStartGuide and continued debugging the authorization process - finally found the reason and cure by reading /etc/init.d/slapd. > > I would like to suggest two changes: > > 1 May i suggest a quick fix: add something like "don't read this" > to the top of the QuickStartGuide. > 2 If possible change your mind on dropping slapd.conf-Support. > - Dropping it will break existing configurations. > - People are quite accustomed to /etc/.../.. .conf-files > > I would like to add that i really appreciate the work you are doing. > > Mit freundlichen Grüssen > > Schwarzwald Software Engineering * Bruno Schrade > Theodor-Kreuz-Strasse 6 * D-79868 Feldberg * Tel. +49 (0)7655 618 > http://www.schwarzwald-software.de >

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by bs＠schwarzwald-software.de 19 Mar '12

19 Mar '12

Sehr geehrter Herr Henry, i just moved an OpenLDAP-Server from Debian-5 to Debian-6. Expecting it would simply run using the same configuration file i just copied slapd.conf. This resulted in error messages along the line "missing credentials". So i looked up the QuickStartGuide and continued debugging the authorization process - finally found the reason and cure by reading /etc/init.d/slapd. I would like to suggest two changes: 1 May i suggest a quick fix: add something like "don't read this" to the top of the QuickStartGuide. 2 If possible change your mind on dropping slapd.conf-Support. - Dropping it will break existing configurations. - People are quite accustomed to /etc/.../.. .conf-files I would like to add that i really appreciate the work you are doing. Mit freundlichen Grüssen Schwarzwald Software Engineering * Bruno Schrade Theodor-Kreuz-Strasse 6 * D-79868 Feldberg * Tel. +49 (0)7655 618 http://www.schwarzwald-software.de

1 0

Re: (ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by h.b.furuseth＠usit.uio.no 16 Mar '12

16 Mar '12

Thanks for your report. We need to hear of OSes which do not provide O_DSYNC and fdatasync() and how to deal with them, so for now MDB demands them unless explicitly disabled. But the solution will not be a bunch of '#if <OS>'es. Maybe some POSIX feature test macros will be enough, or maybe we can use configure and wrap libmdb/mdb in back-mdb/mdb-wrap.c which makes use of the configure macros. On Wed, 14 Mar 2012 21:34:37 GMT, 4glitch(a)gmail.com wrote: > Why ANDROID and __APPLE__ special? I can't speak for Howard, but: Got there during development. MDB is still evolving. The solution will not be a bunch of '#ifdef <OS>'es. Maybe some POSIX feature test macros will be enough, or maybe we can use configure and wrap libmdb/mdb in back-mdb/mdb-wrap.c which makes use of the configure macros. -- Hallvard

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 16 Mar '12

16 Mar '12

Hi, I finally had the opportunity to get a valgrind analysis of my problem. You can find it below. Thank you for any help. D. ==19496== 12 bytes in 1 blocks are definitely lost in loss record 16 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) ==19496== by 0x80E0297: do_syncrepl (syncrepl.c:706) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) ==19496== ==19496== 155 (32 direct, 123 indirect) bytes in 1 blocks are definitely lost in loss record 47 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x4057054: ber_bvarray_dup_x (memory.c:756) ==19496== by 0x80E0212: do_syncrepl (syncrepl.c:699) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) ==19496== ==19496== 270 (228 direct, 42 indirect) bytes in 3 blocks are definitely lost in loss record 49 of 52 ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) ==19496== by 0x8195E91: syncprov_op_search (syncprov.c:2473) ==19496== by 0x80E3333: overlay_op_walk (backover.c:661) ==19496== by 0x80E3A09: over_op_func (backover.c:723) ==19496== by 0x807BE85: fe_op_search (search.c:402) ==19496== by 0x807C772: do_search (search.c:247) ==19496== by 0x807988B: connection_operation (connection.c:1150) ==19496== by 0x807A0FC: connection_read_thread (connection.c:1286) ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) Le 20/02/2012 10:32, David Coutadeur a écrit : > > Hi, > > Concerning the cpu : > model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz > However, OpenLDAP is used in a virtual machine, with only one dedicated > core. This is 32 bits version of OpenLDAP, on a 32 bits OS. > Linux OS : > Red Hat Enterprise Linux Server release 5.7 (Tikanga) > kernel : > 2 2.6.18-274.3.1.el5 > > You can get the server configuration below. > > Concerning the client, you can find the source code here : > http://loadtesting.sourceforge.net/index.php?lang=en > > > > # > ---------------------------------------------------------------------------- > # Global section > # > ---------------------------------------------------------------------------- > > sizelimit 15000 > > allow bind_v2 > password-hash {SSHA} > threads 8 > loglevel 256 > > serverID 2 > > include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf > > pidfile /opt/openldap/var/run/slapd.pid > argsfile /opt/openldap/var/run/slapd.args > > # ACLs definition (cutted here) > > ####################################################################### > # SSL definitions > ####################################################################### > # Definition of cert files > # --------------------------------- > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > > TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert > TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert > TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key > > TLSVerifyClient never > > > > ####################################################################### > # BDB database definitions > ####################################################################### > database monitor > > ####################################################################### > # suffix dc=example,dc=com > # -------------------- > ####################################################################### > database bdb > directory /opt/openldap/var/openldap-data > # some indexes > > # > ---------------------------------------------------------------------------- > # root suffix > # > ---------------------------------------------------------------------------- > suffix "dc=example,dc=com" > checkpoint 512 10 > > # > ---------------------------------------------------------------------------- > # cache settings > # > ---------------------------------------------------------------------------- > > cachesize 60000 > dncachesize 60000 > idlcachesize 60000 > cachefree 100 > > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > > # Password policy : hash the clear passwords > overlay ppolicy > ppolicy_hash_cleartext > > > # > ---------------------------------------------------------------------------- > # REPLICATION definitions > # > ---------------------------------------------------------------------------- > ####################################################################### > > # I am a master (provider) > # ------------------------------------------ > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > # syncrepl directive (consummer infos) > # ------------------------------------------ > syncrepl rid=001 > provider=ldap://ldap-master-1.example.com > bindmethod=simple > binddn="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" > credentials=secret > searchbase="dc=example,dc=com" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > mirrormode on > > > # > ---------------------------------------------------------------------------- > # limits > # > ---------------------------------------------------------------------------- > > limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > > > ####################################################################### > # suffix o=edition > # ---------------- > ####################################################################### > database bdb > > directory /opt/openldap/var/openldap-data-edition > # some indexes > > > # > ---------------------------------------------------------------------------- > # root suffix > # > ---------------------------------------------------------------------------- > suffix "o=edition" > checkpoint 512 10 > > # > ---------------------------------------------------------------------------- > # cache settings > # > ---------------------------------------------------------------------------- > > cachesize 50000 > dncachesize 50000 > idlcachesize 50000 > cachefree 100 > > > > # > ---------------------------------------------------------------------------- > # rootdn > # > ---------------------------------------------------------------------------- > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > rootdn "cn=Manager,o=edition" > rootpw secret > > # Password policy : hash the clear passwords > overlay ppolicy > ppolicy_hash_cleartext > > > ####################################################################### > # REPLICATION definitions > ####################################################################### > > # I am a master (provider) > # ------------------------------------------ > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > # syncrepl directive (consummer infos) > # ------------------------------------------ > syncrepl rid=002 > provider=ldap://vspar-ldap-master-1.example.com > bindmethod=simple > binddn="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" > credentials=secret > searchbase="o=edition" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > mirrormode on > > # > ---------------------------------------------------------------------------- > # Limits for current BDB > # > ---------------------------------------------------------------------------- > > limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special > Users,dc=example,dc=com" size=unlimited time=unlimited > > > > > > Le 17/02/2012 19:00, Howard Chu a écrit : >> dcoutadeur(a)linagora.com wrote: >>> Full_Name: dcoutadeur >>> Version: 2.4.28 >>> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (109.197.176.10) >>> >>> >>> >>> Hello, >>> >>> >>> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >>> tests, each >>> interrupted by Ctrl+C. (see what's a test below) >>> The segfault is also reproduced in version 2.4.28. >>> >>> I think I won't be able to reproduce the bug with Valgrind. >> >> If you expect us to try to reproduce the bug, you'll have to provide >> more information. Since this crash is in syncprov there's obviously at >> least two servers involved; what are their configurations? What hardware >> are they running on (in particular, how many CPU cores per server)? >> Since you're using a custom client, can you provide the client source code? >>> >>> Thank you in advance for any help. >>> >>> D. >>> >>> >>> Note : A test is 100 times 100 threads, each doing a bind, an add, a >>> modify, a >>> delete, and a logout. >>> >>> >>> >>> >>> >>> (gdb) bt full >>> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >>> rc =<value optimized out> >>> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >>> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >>> p =<value optimized out> >>> q =<value optimized out> >>> r =<value optimized out> >>> top =<value optimized out> >>> side =<value optimized out> >>> side_bf =<value optimized out> >>> shorter =<value optimized out> >>> nside =<value optimized out> >>> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >>> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >>> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >>> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >>> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >>> 0x823c27} >>> pdir = >>> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >>> >>> depth = 0 >>> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >>> syncprov.c:1401 >>> cb = 0x8cb91258 >>> opc = 0x8cb91268 >>> si = 0xa255610 >>> sm = 0xa255688 >>> snext =<value optimized out> >>> mt = 0x8b4004c8 >>> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >>> result.c:541 >>> sc_next = 0x8d994dec >>> sc = 0x8cb91258 >>> scp = 0x8d994928 >>> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >>> result.c:733 >>> berbuf = { >>> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >>> '\000'<repeats 12 times>, >>> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >>> >>> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >>> >>> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >>> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >>> dalign = 5.4323095486619588e-312, >>> palign = 0x10000<Address 0x10000 out of bounds>} >>> ber =<value optimized out> >>> rc = 32768 >>> bytes = 14 >>> __PRETTY_FUNCTION__ = "send_ldap_response" >>> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >>> result.c:860 >>> tmp = 0x0 >>> otext = 0x0 >>> oref = 0x0 >>> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >>> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >>> pdn = {bv_len = 23, bv_val = 0x8b40372f >>> "ou=people,dc=afp,dc=com"} >>> p = 0x8fc4c0fc >>> oe = 0x8fc4c804 >>> ei = 0xa37d1c8 >>> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >>> times>, "\001", '\000'<repeats 198 times> >>> children = 0xa223b20 >>> entry = 0xa223980 >>> ltid = 0x0 >>> lt2 = 0x8b402bf0 >>> eid = 57976 >>> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >>> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >>> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >>> lock = {off = 133260, ndx = 772, gen = 2004, mode = >>> DB_LOCK_READ} >>> num_retries = 0 >>> success = 0 >>> postread_ctrl = 0x0 >>> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >>> num_ctrls = 0 >>> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >>> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >>> rc = 32768 >>> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >>> which=op_add) at backover.c:723 >>> oi = 0xa254ff0 >>> on = 0xa255508 >>> be = 0xa252560 >>> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >>> be_ctrls = >>> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >>> >>> be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = >>> {sss_ssf = 0, >>> sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf >>> = 0, sss_update_transport = 0, sss_update_tls = 0, >>> sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = >>> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >>> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >>> bv_val = 0x0}, be_rootdn = {bv_len = 24, >>> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >>> {bv_len = 24, >>> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >>> {bv_len = 38, >>> bv_val = 0xa2876f0 >>> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >>> be_def_limit = { >>> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >>> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >>> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >>> 0xa255748, be_acl = 0x0, be_dfltaccess = ACL_READ, >>> be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = >>> 0x0}, be_update_refs = 0x0, >>> be_pending_csn_list = 0xa363388, be_pcl_mutex = {__data = >>> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >>> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >>> __size = '\000'<repeats 23 times>, __align = 0}, >>> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >>> be_private = 0xa252660, be_next = { >>> stqe_next = 0xa288538}} >>> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >>> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >>> sc =<value optimized out> >>> rc =<value optimized out> >>> __PRETTY_FUNCTION__ = "over_op_func" >>> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >>> repl_user = 0 >>> rc =<value optimized out> >>> bd = 0x82234c0 >>> textbuf = >>> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >>> >>> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >>> >>> .\"\b\314h\032\216\030O\231\215\245\063\b\b >>> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >>> >>> __PRETTY_FUNCTION__ = "fe_op_add" >>> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >>> ber =<value optimized out> >>> last = 0x8b402e71 "" >>> dn = {bv_len = 38, bv_val = 0x8b402d98 >>> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >>> len = 28 >>> tag =<value optimized out> >>> modlist = 0x8b4015f0 >>> modtail = 0x8b403694 >>> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >>> sm_nvalues = 0x0, sm_numvals = 2375635128, >>> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >>> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >>> textbuf = >>> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >>> >>> '\000'<repeats 20 times>, >>> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >>> >>> rc =<value optimized out> >>> freevals =<value optimized out> >>> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >>> oe_db = 0x0} >>> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >>> at connection.c:1150 >>> rc =<value optimized out> >>> cancel =<value optimized out> >>> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, sr_err = >>> 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, >>> sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, >>> r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, >>> r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = >>> 0x0}, sru_extended = {r_rspoid = 0x0, >>> r_rspdata = 0x0}}, sr_flags = 0} >>> tag = 104 >>> opidx = SLAP_OP_ADD >>> conn = 0xb7f3bc10 >>> memctx = 0xa372570 >>> memctx_null = 0x0 >>> __PRETTY_FUNCTION__ = "connection_operation" >>> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >>> connection.c:1286 >>> s =<value optimized out> >>> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >>> tpool.c:688 >>> task = 0xa382e10 >>> work_list =<value optimized out> >>> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >>> ltk_data = 0xa372570, >>> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >>> 0xa363398, ltk_data = 0xa371a88, >>> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >>> 0x8078320, ltk_data = 0xa37de68, >>> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >>> 0x808dde0, ltk_data = 0x0, >>> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >>> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >>> kctx =<value optimized out> >>> keyslot = 241 >>> hash = 5278961 >>> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >>> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >>> No symbol table info available. >>> #15 0x002f746e in clone () from /lib/libc.so.6 >>> No symbol table info available. >>> >>> >>> >>> >>> >> >>

1 0

Re: ITS#7208
by hyc＠symas.com 15 Mar '12

15 Mar '12

andre.cardinal(a)bell.ca wrote: > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Has anyone tried to reproduce this at 2.4.24 We only investigate bugs reported against a current release. 2.4.24 is over a year old. There is nothing for us to reproduce, you have not provided any configuration information nor initial database contents nor explicit steps to reproduce. You have not provided a backtrace from any core dump. You have not read any of the relevant documentation: http://www.openldap.org/faq/data/cache/56.html > I have not seen anything in the latest releases that points to that. > > > > From: Cardinal, Andre (520972) > Sent: March-14-12 10:18 AM > To: 'openldap-its(a)openldap.org' > Subject: ITS#7208 > > In order to speed up reproducing the bug, I changed the keep_alive_interval= > to 600000 (10 minutes) > > The Slave coredumped after 10 minutes of not being able to communicate with= > it's Master. > > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= > icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= > :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= > uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= > t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= > m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= > t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= > :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= > soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = > xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= > icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= > schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= > point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= > /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= > =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= > schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= > .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= > /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= > ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= > repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= > xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= > schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= > /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= > ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= > p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= > /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= > mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= > crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= > s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= > ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= > om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= > ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= > partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= > 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= > 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= > deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= > Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= > st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi= > v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen= > erator content=3D"Microsoft Word 12 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vli= > nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= > olor:#1F497D'>Has anyone tried to reproduce this at 2.4.24<o:p></o:p></span= >> </p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></= > span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>I have not seen= > anything in the latest releases that points to that.<o:p></o:p></span></p>= > <p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span>= > </p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></s= > pan></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p= >> </span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;p= > adding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span lang=3DEN-US style= > =3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><sp= > an lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= > '> Cardinal, Andre (520972)<br><b>Sent:</b> March-14-12 10:18 AM<br><b>To:= > </b> 'openldap-its(a)openldap.org'<br><b>Subject:</b> ITS#7208<o:p></o:p></sp= > an></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso= > Normal>In order to speed up reproducing the bug, I changed the keep_alive_i= > nterval to 600000 (10 minutes)<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbs= > p;</o:p></p><p class=3DMsoNormal>The Slave coredumped after 10 minutes of n= > ot being able to communicate with it’s Master.<o:p></o:p></p></div></= > body></html>= > > --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_-- > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#7208
by andre.cardinal＠bell.ca 15 Mar '12

15 Mar '12

--_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has anyone tried to reproduce this at 2.4.24 I have not seen anything in the latest releases that points to that. From: Cardinal, Andre (520972) Sent: March-14-12 10:18 AM To: 'openldap-its(a)openldap.org' Subject: ITS#7208 In order to speed up reproducing the bug, I changed the keep_alive_interval= to 600000 (10 minutes) The Slave coredumped after 10 minutes of not being able to communicate with= it's Master. --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi= v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen= erator content=3D"Microsoft Word 12 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>Has anyone tried to reproduce this at 2.4.24<o:p></o:p></span= ></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></= span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>I have not seen= anything in the latest releases that points to that.<o:p></o:p></span></p>= <p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span>= </p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></s= pan></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p= ></span></p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;p= adding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span lang=3DEN-US style= =3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><sp= an lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= '> Cardinal, Andre (520972) <br><b>Sent:</b> March-14-12 10:18 AM<br><b>To:= </b> 'openldap-its(a)openldap.org'<br><b>Subject:</b> ITS#7208<o:p></o:p></sp= an></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso= Normal>In order to speed up reproducing the bug, I changed the keep_alive_i= nterval to 600000 (10 minutes)<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbs= p;</o:p></p><p class=3DMsoNormal>The Slave coredumped after 10 minutes of n= ot being able to communicate with it’s Master.<o:p></o:p></p></div></= body></html>= --_000_7B0942425E628C468907C3029A0F33E49DBC85FAMBX16bellcorpbc_--

1 0

Re: (ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by 4glitch＠gmail.com 14 Mar '12

14 Mar '12

03/14/2012 11:08 PM, Howard Chu написав(ла): > No. Compile with -DMDB_SYNC and -DMDB_FDATASYNC yourself like it says > in the comments in mdb.c. > Why ANDROID and __APPLE__ special? mdb.c contains definitions of fdatasync(fd) for it.

1 0

Re: (ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by hyc＠symas.com 14 Mar '12

14 Mar '12

4glitch(a)gmail.com wrote: > Full_Name: Dmitri Bogomolov > Version: 2.4.28 > OS: Gentoo/FreeBSD > URL: ftp://ftp.openldap.org/incoming/dmitri-bogomolov-120314.patch > Submission from: (NULL) (176.36.139.33) > > > As I can see, FreeBSD have no O_DSYNC, no fdatasync(fd). I've been able to build > openldap-2.4.30 with trivial fix. > > Can you please include it in next version? No. Compile with -DMDB_SYNC and -DMDB_FDATASYNC yourself like it says in the comments in mdb.c. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7209) Changes to libraries/libmdb/mdb.c needed to build on FreeBSD
by 4glitch＠gmail.com 14 Mar '12

14 Mar '12

Full_Name: Dmitri Bogomolov Version: 2.4.28 OS: Gentoo/FreeBSD URL: ftp://ftp.openldap.org/incoming/dmitri-bogomolov-120314.patch Submission from: (NULL) (176.36.139.33) As I can see, FreeBSD have no O_DSYNC, no fdatasync(fd). I've been able to build openldap-2.4.30 with trivial fix. Can you please include it in next version?

1 0

ITS#7208
by andre.cardinal＠bell.ca 14 Mar '12

14 Mar '12

--_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to speed up reproducing the bug, I changed the keep_alive_interval= to 600000 (10 minutes) The Slave coredumped after 10 minutes of not being able to communicate with= it's Master. --_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 12 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>In order to spee= d up reproducing the bug, I changed the keep_alive_interval to 600000 (10 m= inutes)<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D= MsoNormal>The Slave coredumped after 10 minutes of not being able to commun= icate with it’s Master.<o:p></o:p></p></div></body></html>= --_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_--

1 0

Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com 14 Mar '12

14 Mar '12

This is a cryptographically signed message in MIME format. --------------ms080104040202090104060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Typo on my part > > It is 2.4.24 Anyway you should try to reproduce this with 2.4.30 since there have been= =20 numerous fixes to syncrepl since 2.4.24: http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3DCH= ANGES;h=3D1c68a45c430b4d3ebaea83294c05c242a3ba91bf;hb=3Drefs/heads/OPENLD= AP_REL_ENG_2_4 Ciao, Michael. > -----Original Message----- > From: Michael Str=F6der [mailto:michael@stroeder.com] > Sent: March-14-12 9:41 AM > To: Cardinal, Andre (520972) > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode > > andre.cardinal(a)bell.ca wrote: >> Full_Name: Andre Cardinal >> Version: 2.2.24 > > Are you really using 2.2.24? This is an ancient version. 2.2.x has been= set to > historic years ago. > > Could you please try to reproduce this with currently recent release 2.= 4.30? > > Ciao, Michael. --------------ms080104040202090104060807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDE0MDQzMVowIwYJKoZIhvcNAQkEMRYE FJkgOqb2gdGaFMxe/XPrSXGdLw6HMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAAaOKi3q8/1dU7oRpxVYTBXb8WNOy0GFbA7awAAfhetQq68cq/+HwY5H+grPXuMZdOgce WJ09MEeAHlz4aExR2qOsClu5EBpHQoTOu20U8ByFpUU1xS6x5ZB7wv4JN8GpHe7sV/nTSDcJ bpA0kjurXc6UkwfLionQKJkdz//PTzkdCw+wGsz4UiRRayEbcq4BRi5KTp1IewrQwcid/qaN hfNATAhn1dbFfBv4mvyIYyEnSNG85XYwRdAyVSl8hVsfgWmSH6K/goGxeEMlnWPNxBk7F9ui AXpsiljAnNn4vl/uny5SFPKJkkn4mtDO7jK8RZKvxU+Pb2DBkjmBIaM/dgAAAAAAAA== --------------ms080104040202090104060807--

1 0

RE: (ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca 14 Mar '12

14 Mar '12

Typo on my part It is 2.4.24 -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: March-14-12 9:41 AM To: Cardinal, Andre (520972) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.2.24 Are you really using 2.2.24? This is an ancient version. 2.2.x has been set to historic years ago. Could you please try to reproduce this with currently recent release 2.4.30? Ciao, Michael.

1 0

Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com 14 Mar '12

14 Mar '12

This is a cryptographically signed message in MIME format. --------------ms050408060208030303010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.2.24 Are you really using 2.2.24? This is an ancient version. 2.2.x has been s= et to=20 historic years ago. Could you please try to reproduce this with currently recent release 2.4.= 30? Ciao, Michael. --------------ms050408060208030303010805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDEzNDA0NFowIwYJKoZIhvcNAQkEMRYE FPblbthmkMffgP3cgCbuBPtlezT2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAklodZ8Q0BtBXDb6m8/1q/UI1uoBf+3YPCUPFCgJteK48aBPZDpd6PQuhapmF9z+CuTJk JXV1J6uro8pBxQddbe6u8nPM2N9uwR9PVw58CKM3je2K7b2h10umwmiWZKiN/fG26nGFBM7B HKRoQw/oZ1lbsXH4kF22dMt9KRDL+vfNs5VfnNFuB9K7fxKySxB98gWbsPFx5giPOLLLqdKd SKjSK2+myZw8gTvKVfgI3fMOelvXvMtvTlkKMOY+12dECeFrbe51g5N1h0+rP08XnbrkMJsT H4Uz3DfJIt9tJkAXAiZ+l9sXzsxv2unUpGehzogR7Ss/DBKKWW+/Gb2hcQAAAAAAAA== --------------ms050408060208030303010805--

1 0

(ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca 14 Mar '12

14 Mar '12

Full_Name: Andre Cardinal Version: 2.2.24 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.247) Replica core dumps if unable to contact it's Master after 2 hours. Replica is set to refresh and persist. To reproduce... Shut down slapd on Master server and/or, if multihomed server, shutdown the replication interface. After 2 hours (the os keep_alive_interval) the log will report: Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 539778 local4.debug] do_syncrep2: rid=123 (-1) Can't contact LDAP server Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 664938 local4.debug] do_syncrepl: rid=123 rc -1 retrying And ldap will coredump shortly there after. The log entry mentionned above do appear in the log (every 2 hours) if there is no traffic from the Master to the Slave and the Master can be contacted, so no coredump.

1 0

(ITS#7207) Re-binding to a failed connection segfaults
by jsynacek＠redhat.com 14 Mar '12

14 Mar '12

Full_Name: Jan Synacek Version: 2.4.30 OS: Fedora 16 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) I've created a small reproducer, that calls ldap_sasl_interactive_bind_s after it has been called once and failed, which causes a segfault. I've traced this bug with gdb: $ gdb ./reproducer GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jsynacek/work/bz784989-openldap-rebinding/reproducer...done. (gdb) r Starting program: /home/jsynacek/work/bz784989-openldap-rebinding/reproducer [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 7 ldap_prepare_socket: 7 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 7 tm: -1 async: 0 TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_msgfree ldap_err2string bind failed: Can't contact LDAP server, retrying for fun and profit! ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI Program received signal SIGSEGV, Segmentation fault. ldap_int_sasl_bind (ld=0x603130, dn=0x0, mechs=0x401a30 "GSSAPI", sctrls=0x0, cctrls=0x0, flags=1, interact=0x401660 <lutil_sasl_interact>, defaults=0x60cae0, result=0x0, rmech=0x7fffffffd878, msgid=0x7fffffffd88c) at ../../../libraries/libldap/cyrus.c:444 444 oldctx = ld->ld_defconn->lconn_sasl_authctx; (gdb) p ld->ldc->ldc_defconn $1 = (LDAPConn *) 0x0 If you set slapd to use TLS certs (uncomment the 'TLS*' lines in the config), there is no segfault. The reproducer and the config can be found here: URL1: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/reproducer.c URL2: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/cn=config.ldif

1 0

Re: (ITS#7206) ldaprc: TLS_REQCERT demand does not terminate session, if a bad certicate comes from the server
by hyc＠symas.com 14 Mar '12

14 Mar '12

mkeller(a)psi.de wrote: > Full_Name: Michael Keller > Version: 2.4.20 > OS: SLES 11 SP1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.131.98.154) > > > I have configured slapd to accept only TLS connections with: > > security ssf=1 update_ssf=112 simple_bind=64 > > A ldapsearch -x returns correctly a > "# search result > search: 2 > result: 13 Confidentiality required > text: confidentiality required" > > When using TLS_REQCERT=demand a > ldapsearch -x -Z still returns results, even if a bad certificate comes from the > server. See debug output below. > ldapsearch -x -Z Works as designed. Read the description for the -Z flag again. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7206) ldaprc: TLS_REQCERT demand does not terminate session, if a bad certicate comes from the server
by mkeller＠psi.de 14 Mar '12

14 Mar '12

Full_Name: Michael Keller Version: 2.4.20 OS: SLES 11 SP1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.131.98.154) I have configured slapd to accept only TLS connections with: security ssf=1 update_ssf=112 simple_bind=64 A ldapsearch -x returns correctly a "# search result search: 2 result: 13 Confidentiality required text: confidentiality required" When using TLS_REQCERT=demand a ldapsearch -x -Z still returns results, even if a bad certificate comes from the server. See debug output below. ldapsearch -x -Z ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate # extended LDIF # # LDAPv3 # base <dc=ee,dc=psi> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # ee.psi dn: dc=ee,dc=psi objectClass: dcObject objectClass: organization dc: ee o: PSI-EE # People, ee.psi dn: ou=People,dc=ee,dc=psi ou: People objectClass: top objectClass: organizationalUnit # Group, ee.psi dn: ou=Group,dc=ee,dc=psi ou: Group objectClass: top objectClass: organizationalUnit # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 Only when using "-ZZ" the connection isn't established. But the man page stated, that the connection is terminated immediatly if a bad certificate is supplied ("ldap_start_tls returns with an error). I think with "TLS_REQCERT demand" and a bad certificate the connection should be terminated even if just a "-Z" is used. At the moment the behaviour is the same for TLS_REQCERT = allow|try|demand Debug output: ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 2, err: 0, subject: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi, issuer: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi TLS certificate verification: depth: 1, err: 0, subject: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=EE-SigningCA@ldap-srv11, issuer: /DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi TLS certificate verification: depth: 0, err: 0, subject: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=ldap-srv11.ee.psi, issuer: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=EE-SigningCA@ldap-srv11 TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A TLS: hostname (ldap-srv11) does not match common name in certificate (ldap-srv11.ee.psi). ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 14 bytes to sd 3 ldap_result ld 0x615150 msgid 2 wait4msg ld 0x615150 msgid 2 (infinite timeout) wait4msg continue ld 0x615150 msgid 2 all 1 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid 2 all 1 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x615150 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x615150 0 new referrals read1msg: mark request completed, ld 0x615150 msgid 2 request done: ld 0x615150 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_search_ext put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 51 bytes to sd 3 ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 89 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 89 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 87 contents: read1msg: ld 0x615150 msgid 3 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ldap_dn2ufn ldap_dn_normalize ber_scanf fmt ({xx) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x615150 msgid -1 wait4msg ld 0x615150 msgid -1 (infinite timeout) wait4msg continue ld 0x615150 msgid -1 all 0 ** ld 0x615150 Connections: * host: ldap-srv11 port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 14 08:49:55 2012 ** ld 0x615150 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x615150 request count 1 (abandoned 0) ** ld 0x615150 Response Queue: Empty ld 0x615150 response count 0 ldap_chkResponseList ld 0x615150 msgid -1 all 0 ldap_chkResponseList returns ld 0x615150 NULL ldap_int_select read1msg: ld 0x615150 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x615150 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x615150 0 new referrals read1msg: mark request completed, ld 0x615150 msgid 3 request done: ld 0x615150 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed

1 0

(ITS#7205) olcSuffix does not support modifications
by elecharny＠apache.org 13 Mar '12

13 Mar '12

Full_Name: Emmanuel Lecharny Version: 2.4.24 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) The olcSuffix AT, which is not declared as SINGLE-VALUED, does not support more than one value. Per se, the definition of this AT should be explicit about it. However, this is not the main issue. Trying to modify its value using such a LDIF file : dn: olcDatabase={3}ldif,cn=config changetype: modify delete: olcSuffix olcSuffix: cn=test2 - add: olcSuffix olcSuffix: cn=test3 - leads to an error : #!ERROR [LDAP: error code 80 - <olcSuffix> Only one suffix is allowed on this ldif backend] It seems that there is an internal check that is done to insure that the olcSuffix does not contain more than one value, bypassing the AT definition, and that this check is not correctly done when a modify operation is sent. Deleting the olcSuffix AT and injcting a new one works.

1 0

(ITS#7204) test044-dynlist broken with --disable-monitor
by h.b.furuseth＠usit.uio.no 09 Mar '12

09 Mar '12

Full_Name: Hallvard B Furuseth Version: 2.4->2.4.30 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard test044-dynlist uses olcDatabase={2}$BACKEND,cn=config. This breaks when back-monitor is omitted as database {1}. Fixing.

1 0

(ITS#7203) approxIndexer should not return zero-length keys
by hyc＠OpenLDAP.org 09 Mar '12

09 Mar '12

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc The approxIndexer generates a key for every word in the input string. Short words produce no actual key value, and leave a slot in the list of keys with bv_len=0. These results should be omitted; the underlying database can't do anything with zero length keys anyway.

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 09 Mar '12

09 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/12/2012 12:27 PM, hyc(a)symas.com wrote: > This ITS still appears to me to be invalid. bconfig treats all siblings *of > the same type* as a single ordering. Your demonstration code is claiming your > entries are all of the same type, even though they aren't. I.e., all entries > in cn=config of a given type have only one distinguished naming attribute. You > have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config > doesn't distinguish them in its sort order. I tried implementing a check for Cft_Misc that considers only siblings of the same distinguished naming attribute: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987.patch During an IRC conversation in January you suggested not renumbering Cft_Misc entries at all, like the patch below. Such a change might however affect other overlays since captive backends seem to be regarded as Cft_Misc entries too, based on my tests with it: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20120309-ITS-6987-no-renumber… The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9aHu0ACgkQ9GWxeeH+cXvpGgCeN5iMhB6iyq3MjFJVx45AWmX+ uykAnjidKeewlH1EhlBBr+BTFgxZNodM =+FEP -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7202) slapo-memeberof crashing OL 2.4.30
by marco.pizzoli＠gmail.com 09 Mar '12

09 Mar '12

Full_Name: Marco Pizzoli Version: 2.4.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the day before the release, but nothing changed in the meantime). I have a consumer starting from scratch with an empty db. During his starting he populates his db by connecting to 4 servers which are part of a 4-way multi-master cluster. They are running a previous version of OpenLDAP. We are doing an upgrade of our deployment just to solve an issue we face from time to time consisting in data corruption. This bug, which is not the target of this ITS, is able to trigger a crash of the slave slapd 2.4.30. During the first synchronization the consumer is receiving the entire db and I can see on this slave, in the logs, coming two odd entries, like this one: ldap15.log:Feb 28 15:45:02 ldap15 slapd[5219]: conn=-1 op=0: memberof_value_modify DN="p?v#007" add memberOf="cn=mynetbk,ou=allnetbk,ou=systems,ou=mygroups,dc=my_dc1,dc=my_dc2.it" failed err=32 and after that slapd crashes. I produced a core dump and generated the full back trace. And I can see this is due to slapo-memberof. This is my memberof configuration: overlay memberof memberof-group-oc groupOfNames memberof-member-ad member memberof-memberof-ad memberOf memberof-dn cn=Manager,dc=my_dc1,dc=my_dc2.it memberof-dangling ignore memberof-dangling-error 80 memberof-refint FALSE Here is the output. As I said, this output is taken from a slapd 2.4.30. The platform is Linux x86_64. [ldap@ldap15 ~]$ gdb /opt/openldap/libexec/slapd /tmp/core.11359 GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /opt/openldap-PRE2.4.30/libexec/slapd...done. [New Thread 11363] [New Thread 11361] [New Thread 11359] [New Thread 11360] [New Thread 11365] [New Thread 11362] [New Thread 11364] Missing separate debuginfo for /opt/berkeleydb/lib/libdb-5.2.so Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/25/3444cedd507ae54ca793376010c027664ab639 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/memberof-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/29/1997818b36184bdbf6921e2b597f1d961122a4 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/accesslog-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/87/d14b81be9ec6d6a7a515d61d8b15d4b9e9f439 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/auditlog-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/d1/a0f526dbc9986c4c167ccc2d7f72496c16a8e5 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/ppolicy-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ca/ba01f02f5db752891321c3a3a871b72d827634 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/sssvlv-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/72/29edebf6dad9245753fbca44c3395edfee0999 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/syncprov-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/e9/1d213453b9bef5f9ff991e0cbba93114595cca Missing separate debuginfo for /opt/openldap/libexec/openldap/lastbind.so.0 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/13/d1a7451281081ce9fcf0a3db11144b63819464 Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/constraint-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/a3/c9c4184844cd493c88212b73f82893500554fb Missing separate debuginfo for /opt/openldap-PRE2.4.30/libexec/openldap/valsort-2.4.so.2 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/5b/6df9a919708465a54252a0e5b402de239475d3 Missing separate debuginfo for Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/08/f634a1d22deff00461d50a7699dacdc97657bf Reading symbols from /usr/lib64/libltdl.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libltdl.so.7 Reading symbols from /opt/berkeleydb/lib/libdb-5.2.so...(no debugging symbols found)...done. Loaded symbols for /opt/berkeleydb/lib/libdb-5.2.so Reading symbols from /usr/lib64/perl5/CORE/libperl.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/perl5/CORE/libperl.so Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libutil.so.1 Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libodbc.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libodbc.so.2 Reading symbols from /usr/lib64/libicuuc.so.42...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libicuuc.so.42 Reading symbols from /usr/lib64/libicudata.so.42...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libicudata.so.42 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /usr/lib64/libtcmalloc.so.0...done. Loaded symbols for /usr/lib64/libtcmalloc.so.0 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /usr/lib64/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libstdc++.so.6 Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libgcc_s.so.1 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /usr/lib64/libunwind.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libunwind.so.8 Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_ldap.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_ldap.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/memberof-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/memberof-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/accesslog-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/accesslog-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/auditlog-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/auditlog-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/ppolicy-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/ppolicy-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/sssvlv-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/sssvlv-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/syncprov-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/syncprov-2.4.so.2 Reading symbols from /opt/openldap/libexec/openldap/lastbind.so.0...(no debugging symbols found)...done. Loaded symbols for /opt/openldap/libexec/openldap/lastbind.so.0 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/constraint-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/constraint-2.4.so.2 Reading symbols from /opt/openldap-PRE2.4.30/libexec/openldap/valsort-2.4.so.2...done. Loaded symbols for /opt/openldap-PRE2.4.30/libexec/openldap/valsort-2.4.so.2 Core was generated by `/opt/openldap//libexec/slapd -h ldap://10.10.114.15:389 ldaps://10.10.114.15:63'. Program terminated with signal 11, Segmentation fault. #0 0x00007f5291ed6245 in memberof_res_add (op=0x7f527a0e5380, rs=<value optimized out>) at memberof.c:1273 1273 memberof.c: No such file or directory. in memberof.c Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-13.el6.x86_64 db4-4.7.25-16.el6.x86_64 glibc-2.12-1.47.el6.x86_64 google-perftools-1.7-1.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6.x86_64 libcom_err-1.41.12-11.el6.x86_64 libgcc-4.4.6-3.el6.x86_64 libicu-4.2.1-9.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libstdc++-4.4.6-3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 libunwind-1.0.1-1.el6.x86_64 nss-pam-ldapd-0.7.5-14.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6.x86_64 perl-libs-5.10.1-119.el6_1.1.x86_64 unixODBC-2.2.14-11.el6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) bt #0 0x00007f5291ed6245 in memberof_res_add (op=0x7f527a0e5380, rs=<value optimized out>) at memberof.c:1273 #1 0x000000000044c9ae in slap_response_play (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:507 #2 0x000000000044d539 in send_ldap_response (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:582 #3 0x000000000044e22c in slap_send_ldap_result (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:860 #4 0x0000000000510730 in hdb_add (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at add.c:511 #5 0x00000000004a49b7 in overlay_op_walk (op=0x7f527a0e5380, rs=0x7f527a0e4f80, which=op_add, oi=0x1c40000, on=0x0) at backover.c:671 #6 0x00000000004a5397 in over_op_func (op=0x7f527a0e5380, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 #7 0x000000000049b3cb in syncrepl_entry (op=0x7f527a0e5380, si=0x1ca8000) at syncrepl.c:2842 #8 do_syncrep2 (op=0x7f527a0e5380, si=0x1ca8000) at syncrepl.c:1012 #9 0x00000000004a0dc2 in do_syncrepl (ctx=<value optimized out>, arg=0x1aa4dd0) at syncrepl.c:1522 #10 0x000000000056ae70 in ldap_int_thread_pool_wrapper (xpool=0x1b90000) at tpool.c:688 #11 0x00007f5296ee97f1 in start_thread () from /lib64/libpthread.so.0 #12 0x00007f529488170d in clone () from /lib64/libc.so.6 (gdb) bt full #0 0x00007f5291ed6245 in memberof_res_add (op=0x7f527a0e5380, rs=<value optimized out>) at memberof.c:1273 a = 0x220c530 mci = <value optimized out> on = <value optimized out> mo = 0x1b7b4f0 i = <value optimized out> #1 0x000000000044c9ae in slap_response_play (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:507 sc_next = 0x7f527a0e47f0 sc_nextp = 0x27f0038 rc = 32768 sc = 0x27f0080 scp = 0x27f0080 #2 0x000000000044d539 in send_ldap_response (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:582 berbuf = { buffer = "\005", '\000' <repeats 23 times>"\230, SOR\177\000\000PB\016zR\177\000\000!\004`\377\377\377\377\377\236BWO\000\000\000\000\000\315\306\001", '\000' <repeats 12 times>, "@\237\274\001\000\000\000\000\230SOR\177\000\000\000\000\000\000\000\000\000\000W?\357\000\000\000\000\257\361\n\230R\177\000\000\000\000\000\000R\177\000\000 \000\000\000\000\000\000\000\000S/\230R\177\000\000\001\000\000\000\000\000\000\000\236BWO\000\000\000\000W?\357", '\000' <repeats 12 times>, "@\035x\a\000\000\000\000\b\255\v\002\000\000\000\000\000\a\277\001\000\000\000\000\a", '\000' <repeats 47 times>"\300, sb\a\000\000\000\000\t\000\000\000\000\000\000", ialign = 5, lalign = 5, falign = 7.00649232e-45, dalign = 2.4703282292062327e-323, palign = 0x5 <Address 0x5 out of bounds>} ber = 0x7f527a0e4200 rc = 0 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #3 0x000000000044e22c in slap_send_ldap_result (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #4 0x0000000000510730 in hdb_add (op=0x7f527a0e5380, rs=0x7f527a0e4f80) at add.c:511 bdb = 0x1bf0700 pdn = {bv_len = 50, bv_val = 0x76273ca "ou=ldap,ou=systems,ou=mygroups,dc=my_dc1,dc=my_dc2.it"} p = <value optimized out> oe = 0x20bad08 ei = 0x7783de0 textbuf = "\000\000\000\000\000\000\000\000\000DP\a\000\000\000\000\334\071w\a\000\000\000\000\200S\016zR\177\000\000\200O\016zR\177\000\000`\t\304\001\000\000\000\000\300\266\307\001\000\000\000\000\300\364\213\221R\177\000\000\000\000\000\000\000\000\000\000\320D\016zR\177\000\000\000\000\000\000\000\000\000\000\240F\016zR\177", '\000' <repeats 26 times>"\300, D\016zR\177\000\000\000\000\000\000\001\000\000\000\002\000\000\000\000\000\000\000\320\000w\a\001\000\000\000\b", '\000' <repeats 31 times>, "\f", '\000' <repeats 23 times>, "\020R\016zR\177\000\000\320\000w\a\000\000\000\000\241\000\000\000\000\000\000\000\020R\016zR\177\000\000\000\000\000\000\000\000\000\000\200S\016zR\177\000" children = 0x0 entry = 0x1a99300 ltid = 0x0 lt2 = 0x1c69ce0 eid = 2243 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x1c6cd00, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} ---Type <return> to continue, or q <return> to quit--- lock = {off = 2389256, ndx = 993, gen = 962, mode = DB_LOCK_READ} num_retries = <value optimized out> success = 0 postread_ctrl = 0x0 ctrls = {0x0, 0x7f527a0e4558, 0xf, 0xffffffffffffffff, 0x1b7b4f0, 0x77b6381} num_ctrls = <value optimized out> #5 0x00000000004a49b7 in overlay_op_walk (op=0x7f527a0e5380, rs=0x7f527a0e4f80, which=op_add, oi=0x1c40000, on=0x0) at backover.c:671 func = <value optimized out> rc = 32768 #6 0x00000000004a5397 in over_op_func (op=0x7f527a0e5380, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 oi = <value optimized out> on = <value optimized out> be = 0x1b98d00 db = {bd_info = 0x8393a0, bd_self = 0x1b98d00, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001\001\001\001\001\000\000\000\000\000\000\000\000\001", be_flags = 694536, be_restrictops = 0, be_requires = 6, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1c7aea0, be_nsuffix = 0x1c7b080, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 32, bv_val = 0x1aaee10 "cn=Manager,dc=my_dc1,dc=my_dc2.it"}, be_rootndn = {bv_len = 32, bv_val = 0x1aaede0 "cn=manager,dc=my_dc1,dc=my_dc2.it"}, be_rootpw = {bv_len = 38, bv_val = 0x1aaed80 "{SSHA}mypw"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x1af9080, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2061aa0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x1ca8000, be_pb = 0x0, be_cf_ocs = 0x83eac0, be_private = 0x1bf0700, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7f527a0e51b0, sc_response = 0x4a4640 <over_back_response>, sc_cleanup = 0, sc_private = 0x1c40000} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x000000000049b3cb in syncrepl_entry (op=0x7f527a0e5380, si=0x1ca8000) at syncrepl.c:2842 rs_add = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} syncuuid_inserted = <value optimized out> freecsn = 0 be = 0x1b98d00 ava = {aa_desc = 0x1a98a80, aa_value = {bv_len = 16, bv_val = 0x779f9e7 "?\344\025L\202C\003\275vc\027b_\343", <incomplete sequence \304>}} dni = {new_entry = 0x20bad08, dn = {bv_len = 0, bv_val = 0x0}, ndn = {bv_len = 0, bv_val = 0x0}, nnewSup = {bv_len = 0, bv_val = 0x0}, renamed = 0, delOldRDN = 0, modlist = 0x7f527a0e5300, mods = 0x0, oldNcount = 0, oldDesc = 0x0, newDesc = 0x0} retry = <value optimized out> cb = {sc_next = 0x0, sc_response = 0x493eb0 <null_callback>, sc_cleanup = 0, sc_private = 0x1ca8000} rs_search = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} f = {f_choice = 163, f_un = {f_un_result = 2047758832, f_un_desc = 0x7f527a0e51f0, f_un_ava = 0x7f527a0e51f0, f_un_ssa = 0x7f527a0e51f0, f_un_mra = 0x7f527a0e51f0, f_un_complex = 0x7f527a0e51f0}, f_next = 0x0} rc = <value optimized out> ---Type <return> to continue, or q <return> to quit--- pdn = {bv_len = 0, bv_val = 0x0} #8 do_syncrep2 (op=0x7f527a0e5380, si=0x1ca8000) at syncrepl.c:1012 match = <value optimized out> cookie = {bv_len = 0, bv_val = 0x0} rctrls = 0x7772cb0 rctrlp = <value optimized out> syncUUIDs = 0x0 bdn = {bv_len = 60, bv_val = 0x1cf6e09 "cn=myldap05,ou=ldap,ou=systems,ou=mygroups,dc=my_dc1,dc=my_dc2.it"} syncUUID = {{bv_len = 16, bv_val = 0x779f9e7 "?\344\025L\202C\003\275vc\027b_\343", <incomplete sequence \304>}, {bv_len = 36, bv_val = 0x27f0008 "da89e415-4c82-4303-bd76-6317625fe3c4"}} si_tag = <value optimized out> entry = 0x20bad08 punlock = -1 syncstate = 1 retdata = 0x7f527a0e5330 retoid = 0x1ca8258 "" len = 0 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>"\340, \371y\a\000\000\000\000\367\371y\a\000\000\000\000\367\371y\a", '\000' <repeats 28 times>"\200, \a\277\001\000\000\000\000X`\002\230R\177\000\000P\001\000\000\000\000\000\000\025\000\000\000\000\000\000\000\240\260\307\001\000\000\000\000\000\226\306\001\000\000\000\000\370'OR\177\000\000@\237\274\001", '\000' <repeats 12 times>"\231, \004\357\226R\177\000\000\000\000\000\000\000\000\000\000ilY\000\000\000\000\000\a\000\000\200\000\000\000\000\030O\016zR\177\000\000X2OR\177\000\000\202\030Y\000\000\000\000\000PO\016zR\177\000\000\202\030Y\000\000\000\000\000PO\016zR\177\000\000\\\031Y\000\000\000\000\000;\000\000\000\000\000\000\000\b \245\002\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7f527a0e4cf0 msg = 0x29d6800 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 0, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 0, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 1, octet_str = {bv_len = 15, bv_val = 0x2a1e0c0 "rid=001,sid=00f"}, sid = 15, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x7504900 m = 0 tout_p = 0x0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" #9 0x00000000004a0dc2 in do_syncrepl (ctx=<value optimized out>, arg=0x1aa4dd0) at syncrepl.c:1522 rtask = 0x1aa4dd0 si = 0x1ca8000 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x5d0241 ""}, c_peer_name = {bv_len = 0, bv_val = 0x5d0241 ""}, c_listener = 0x5a0d20, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = { bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, ---Type <return> to continue, or q <return> to quit--- stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x44e0b0 <slap_send_ldap_result>, c_send_search_entry = 0x44ed90 <slap_send_search_entry>, c_send_search_reference = 0x44e6c0 <slap_send_search_reference>, c_send_ldap_extended = 0x44dbe0 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x44da80 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f527a0e54f0, o_tag = 104, o_time = 1331118750, o_tincr = 206, o_bd = 0x7f527a0e4660, o_req_dn = {bv_len = 60, bv_val = 0x7627140 "cn=myldap05,ou=ldap,ou=mysystems,ou=groups,dc=my_dc1,dc=my_dc2.it"}, o_req_ndn = {bv_len = 60, bv_val = 0x76273c0 "cn=myldap05,ou=ldap,ou=mysystems,ou=groups,dc=my_dc1,dc=my_dc2.it°}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0x20bad08}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 34319624, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x83c8c0 "\001"}, rb_ssf = 2047758864, rb_mech = {bv_len = 48, bv_val = 0x27f0038 "\360G\016zR\177"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = 8 '\b'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 8 '\b'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x83c8c0 "\001"}, rs_nnewrdn = {bv_len = 139992211804688, bv_val = 0x30 <Address 0x30 out of bounds>}, rs_newSup = 0x27f0038, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = 34319624, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x83c8c0, rs_filter = 0x7f527a0e5210, rs_filterstr = { bv_len = 48, bv_val = 0x27f0038 "\360G\016zR\177"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = { bv_len = 2, bv_val = 0x20bad08 "\303\b"}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x20bad08 "\303\b"}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 8636608, bv_val = 0x7f527a0e5210 "\243"}, rs_new = { bv_len = 48, bv_val = 0x27f0038 "\360G\016zR\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 16 times>, "\002", '\000' <repeats 14 times>, o_controls = 0x7f527a0e5638, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 32, bv_val = 0x1aaee10 "cn=Manager,dc=my_dc1,dc=my_dc2.it"}, sai_ndn = {bv_len = 32, bv_val = 0x1aaede0 "cn=manager,dc=my_dc1,dc=my_dc2.it"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x27f0038, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x77b6360 "\200\n|\a"}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 1, oh_conn = 0x7f527a0e5740, oh_msgid = 0, oh_protocol = 3, oh_tid = 139992211810048, oh_threadctx = 0x7f527a0e5a70, oh_tmpmemctx = 0x27aa2c0, oh_tmpmfuncs = 0x83cca0, oh_counters = 0x895160, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7f527a0e5380 rc = <value optimized out> dostop = 0 s = <value optimized out> i = <value optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0x1b98d00 #10 0x000000000056ae70 in ldap_int_thread_pool_wrapper (xpool=0x1b90000) at tpool.c:688 pool = 0x1b90000 ---Type <return> to continue, or q <return> to quit--- task = 0x206bca0 work_list = <value optimized out> ctx = {ltu_id = 139992211810048, ltu_key = {{ltk_key = 0x490a10, ltk_data = 0x27aa2c0, ltk_free = 0x490a30 <slap_sl_mem_destroy>}, { ltk_key = 0x1c21000, ltk_data = 0x1c69600, ltk_free = 0x512780 <bdb_reader_free>}, {ltk_key = 0x4c1aa0, ltk_data = 0x2a68000, ltk_free = 0x4c1b70 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = <value optimized out> keyslot = 576 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x00007f5296ee97f1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007f529488170d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) q Please let me know if you keed other details. Thanks Marco

1 0

Re: (ITS#7194) tlso_session_chkhost issue for OpenSSL TLS
by hyc＠symas.com 08 Mar '12

08 Mar '12

dimosthenis.pettas(a)nsn.com wrote: > Full_Name: Dimosthenis Pettas > Version: 2.4.23 > OS: SOLARIS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.159.77.167) Thanks for the report, fixed in git master. > > I use OpenLDAP version 2.4.23 client to connect via TLS to an LDAP > server(slapd). > i initialize connection with an IPV6 address using url > ldap://[fd00:1111:1111:72:20c:29ff:fec5:4ade]:389 and then try to extend > connection to TLS with calling ldap_start_tls_s. when trying to match > client-server certificates hosts inside tlso_session_chkhost in tls_o.c we try > to determine client host type(IS_DNS,IS_IP4,IS_IP6) but for IPV6 it expects to > find "[" at first position and "]" at latst one to determine IPV6 address: > > #ifdef LDAP_PF_INET6 > if (name[0] == '['&& strchr(name, ']')) { > char *n2 = ldap_strdup(name+1); > *strchr(n2, ']') = 0; > if (inet_pton(AF_INET6, n2,&addr)) > ntype = IS_IP6; > LDAP_FREE(n2); > } else > > but it seems that [] have been removed inside ldap_url_parse_ext in Url.c: > > > /* If [ip address]:port syntax, url is [ip and we skip the [ */ > ludp->lud_host = LDAP_STRDUP( url + is_v6 ); > > So name is not [fd00:1111:1111:72:20c:29ff:fec5:4ade] but > fd00:1111:1111:72:20c:29ff:fec5:4ade and code above fails to determine ntype = > IS_IP6. > > i modified code to: > > #ifdef LDAP_PF_INET6 > > if (inet_pton(AF_INET6, name,&addr)) > { > ntype = IS_IP6; > > } else > #endif > if ((ptr = strrchr(name, '.'))&& isdigit((unsigned char)ptr[1])) { > if (inet_aton(name, (struct in_addr *)&addr)) > { > ntype = IS_IP4; > > } > } > > letting functions inet_pton and inet_aton determing IP type.Scenario worked. > Let me know if i miss anything or this should be corrected. > > Sorry for submitting again ,i wanted to correct email address > > -- -- 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#7188) slapschema.8 manpage formatting problems
by hyc＠symas.com 08 Mar '12

08 Mar '12

peb(a)mppmu.mpg.de wrote: > Full_Name: Peter Breitenlohner > Version: 2.4.30 > OS: Linux.GNU > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (134.107.24.63) > > > The slapschema.8 manpage exhibits some formatting problems (already present in > 2.4.23 and maybe earlier): > > In line 30 a font change '\fR' is misspelled as '\FR' > > Line 56 ought to end after the word 'slapschema'; the rest should be on a > separate line. > > Thanks for the report, fixed in git master. In the future, please submit actual diffs/patches. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7201) back-shell slapd.conf->cn=config conversion broken
by quanah＠OpenLDAP.org 07 Mar '12

07 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported to the debian bug tracker. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662940

1 0

(ITS#7200) serverID 0 after serverID should fail loudly
by ebackes＠symas.com 05 Mar '12

05 Mar '12

Full_Name: Emily Backes Version: 2.4 OS: any URL: Submission from: (NULL) (98.155.30.248) This is an enhancement request, based on discussions and common failing use-cases we've encountered. Very often, people configure: serverID 1 ldap:... serverID 2 ldap:... ...etc... And for various reasons none of the ldap URIs match the local server and they end up in a faux-mmr where every server believes itself to be zero, resulting in great consternation when replication then fails awkwardly farther down the line. It's only meaningful to set serverID on "master" servers-- those accepting changes, so it seems reasonable to require that one of the serverIDs matches. This is probably easiest to enforce by requiring: * If serverID is zero, mirrormode must be off. Turning mirrormode on should require a non-zero serverID beforehand. It would be nice to test this at serverID setting time, but that requires state checking beyond what is easily provided to the config table, I think. Namely, if any serverIDs are specified, one of them must match and set to a non-zero value; any null serverID after all serverID num/uri pairs are considered should cause the config change or slapd.conf to be rejected. It's also possible that the is-this-a-local-change checks in syncprov.c may want to handle serverID 0 CSNs specially; they must exist only as part of a shared change-set that existed before the current mmr topology. New CSNs appearing with serverID 0 are evidence of unrecoverable misconfiguration.

1 0

(ITS#7199) back-mdb virtual process size unreasonable
by quanah＠OpenLDAP.org 05 Mar '12

05 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) A slapd server with accesslog & primary DB, where primary DB is 131MB and accesslog is 4.1MB has the following profile in top: 5929 zimbra 21 0 160g 105m 52m S 0.7 2.7 19:35.62 slapd where 160g is the virtual size, 105m is RES, 52m is shared 160gb for this seems somewhat... obscene. ;) My guess would be a memory leak?

1 0

RE: (ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca 05 Mar '12

05 Mar '12

Thanks for your reply. These systems are in PRODuction...(not a playground) I am in the process of building our lab with the same configs. Just one question. When selecting refreshandpersist as the replication type, do we need to specify intervals, and retriess values? I think my setting of Intervals=00:00:00:10 Retries="30 +" May have starved the system by running out of file descriptors. -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: March-05-12 10:16 AM To: Cardinal, Andre (520972) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7198) slapd coredumps when Master server unavailable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.24 > OS: Oracle (Solaris) 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) > > > Our Openldap Master server crashed with a hardware memory error and the > slave/replica, which is read only, coredumped 2 hours later, and would coredump > 4 minutes after restarting slapd thereafter. Can you check whether that also happens with recent release 2.4.30? If yes, it would be helpful if you install OpenLDAP with debug symbols and grab a stack trace etc. See "What information should I provide when reporting an issue (bug)?": http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#7198) slapd coredumps when Master server unavailable
by michael＠stroeder.com 05 Mar '12

05 Mar '12

This is a cryptographically signed message in MIME format. --------------ms080906060103080409010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.24 > OS: Oracle (Solaris) 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) > > > Our Openldap Master server crashed with a hardware memory error and the= > slave/replica, which is read only, coredumped 2 hours later, and would= coredump > 4 minutes after restarting slapd thereafter. Can you check whether that also happens with recent release 2.4.30? If ye= s, it=20 would be helpful if you install OpenLDAP with debug symbols and grab a st= ack=20 trace etc. See "What information should I provide when reporting an issue (bug)?": http://www.openldap.org/faq/data/cache/59.html Ciao, Michael. --------------ms080906060103080409010309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTE1MTYxNFowIwYJKoZIhvcNAQkEMRYE FKAKYri2D9e4IJCdixF14t7Nk/MyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAoUCDo8hQNS6bro13hDJb4XbtSNMWvrlHx6haTIwDJbarSKJlBo8TVnax1cCdgC6SByGB 6wIejSS1yfC0Lh+yg+kQebnXY975kCMKjvUcDdjAIuEfYT6NCa1MxWzakprkkIH2YPDyILNx Tc5wqNn/EZX/2aMLrMlvvaGiN3nlqp0IgRzpMTMibOD/oX2oIm4vd5cJqCNBc9N0LTbHhoAK VoD/knw3ELQnQ+Kmi7Q6cJDVQRrIeUK6UqIP1edIMKT/UsYXucZziE8SzGmoTmv+EQwnefEx Y/FVgQ2ETRu3e5iwIYOMZorSTjUsw++yIuIDXz/mT7BA+ZHX+1w7tsyLxQAAAAAAAA== --------------ms080906060103080409010309--

1 0

(ITS#7198) slapd coredumps when Master server unavailable
by andre.cardinal＠bell.ca 05 Mar '12

05 Mar '12

Full_Name: Andre Cardinal Version: 2.4.24 OS: Oracle (Solaris) 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) Our Openldap Master server crashed with a hardware memory error and the slave/replica, which is read only, coredumped 2 hours later, and would coredump 4 minutes after restarting slapd thereafter. Disabling syncrepl stopped the coredumps. (i.e. commenting out all the lines in the syncrepl portion of slapd.conf in the replica. See following. Text in <> is sanitized for obvious reasons. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/ces.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/openldap-run/slapd.pid argsfile /usr/local/var/openldap-run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la allow bind_v2 loglevel 256 #loglevel 4095 #logfile /var/log/ldap.log # The next three lines allow use of TLS for encrypting connections using a # test certificate #TLSCACertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateFile /usr/local/etc/openldap/certs/test_with_ca.pem #TLSCertificateKeyFile /usr/local/etc/openldap/certs/test_with_ca.pem #ICM Certs for PROD TLSCACertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateFile /usr/local/etc/openldap/certs/Slave-ICM.pem TLSCertificateKeyFile /usr/local/etc/openldap/certs/Slave-ICM.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! #configure timelimits and sizelimits sizelimit unlimited timelimit unlimited ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "<suffix>" rootdn "<Root DN>" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}<encrypted password> # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data #directory /data/openldap # Indices to maintain index objectClass eq index cesSubjectDN eq,pres index cn eq # #Equality Indexing for Replication # index entryCSN,entryUUID eq syncrepl rid=123 provider=ldap://<Master Server> type=refreshAndPersist interval=00:00:00:10 retry="30 +" searchbase="<suffix>" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=<bindDN>" credentials=<password>

1 0

(ITS#7197) olcTLSVerifyClient missing options
by quanah＠OpenLDAP.org 04 Mar '12

04 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the manual page: olcTLSVerifyClient: <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. The <level> can be specified as one of the following keywords: never This is the default. slapd will not ask the client for a certificate. allow The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the ses- sion proceeds normally. try The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately ter- minated. demand | hard | true These keywords are all equivalent, for compatibility rea- sons. The client certificate is requested. If no cer- tificate is provided, or a bad certificate is provided, the session is immediately terminated. Note that a valid client certificate is required in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default olcTLSVerifyClient setting must be chosen to enable SASL EXTERNAL authenti- cation. However, the code has: static slap_verbmasks vfykeys[] = { { BER_BVC("never"), LDAP_OPT_X_TLS_NEVER }, { BER_BVC("demand"), LDAP_OPT_X_TLS_DEMAND }, { BER_BVC("try"), LDAP_OPT_X_TLS_TRY }, { BER_BVC("hard"), LDAP_OPT_X_TLS_HARD }, { BER_BVNULL, 0 } }; Which means: a) allow is missing b) true is missing c) demand and hard set different flags. Not sure if that means any difference functionality wise, but according to the manual page, demand/true/hard are supposed to be the same behavior.

1 0

(ITS#7196) libmdb: MDB_COMMIT_PAGES greater than IOV_MAX causes mdb_txn_commit failures
by roy.keene＠us.army.mil 02 Mar '12

02 Mar '12

Full_Name: Roy Keene Version: 2.4.30 OS: Solaris 10 URL: Submission from: (NULL) (140.194.193.14) libmdb uses writev() to write data to a file descriptor, however it can request that writev() write more blocks than IOV_MAX causing mdb txn errors to be reported to the LDAP client. MDB_COMMIT_PAGES should not be defined to be greater than IOV_MAX. IOV_MAX on Solaris 10 is 16.

1 0

Re: (ITS#7195) delta-syncrepl fails to fallback on some errors
by hyc＠symas.com 02 Mar '12

02 Mar '12

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.155.30.248) > > > The delta-syncrepl code checks an explicit list of failure codes for cases that > merit falling back to syncrepl to regain syncronization. This list is missing a > few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop. Thanks, fixed in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7195) delta-syncrepl fails to fallback on some errors
by ebackes＠symas.com 02 Mar '12

02 Mar '12

Full_Name: Emily Backes Version: 2.4 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.155.30.248) The delta-syncrepl code checks an explicit list of failure codes for cases that merit falling back to syncrepl to regain syncronization. This list is missing a few; in particular, rc=66 (Not a leaf!) slips through and creates a retry loop.

1 0

Re: (ITS#7191) libmdb: Alignment of MDB_db members
by roy.s.keene＠usace.army.mil 02 Mar '12

02 Mar '12

Hallvard, This also works. My naive approach was due to working out what the issue was with the original assigment and then trying to determine which members were not aligned correctly. Thanks, Roy Keene On Fri, 2 Mar 2012, Hallvard B Furuseth wrote: > On Fri, 2 Mar 2012 08:03:00 GMT, roy.keene(a)us.army.mil wrote: >> Breaking the assignment into an assignment of its members and using >> the existing COPY_PGNO() alleviates this fault. > > memcpy would be simpler, if it is 'db' which is unaligned. > Try this instead. > > --- mdb.c~ 2012-03-02 11:23:21 > +++ mdb.c 2012-03-02 11:25:06 > @@ -4699,4 +4699,3 @@ mdb_xcursor_init1(MDB_cursor *mc, MDB_no > if (node->mn_flags & F_SUBDATA) { > - MDB_db *db = NODEDATA(node); > - mx->mx_db = *db; > + memcpy(&mx->mx_db, NODEDATA(node), sizeof(MDB_db)); > mx->mx_cursor.mc_snum = 0; > > -- (U) Roy Keene (U) US Army Corps of Engineers IT (ACE-IT) (U) Contractor

1 0

(ITS#7193)
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Good day! I found problem: function under macro BACKSQL_STR2ID incorrectly work with 'zerofilled' values/fields (for example "000009") ------------------------------------------ Best regards, mailto:barlone@yandex.ru

1 0

(ITS#7193)
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Good day! I found some hint: if define BACKSQL_ARBITRARY_KEY in back-sql.h, then all records presents in search result, BUT LDAP entry do not contain any attribute! Just empty. Maybe it is another bug? ------------------------------------------ Best regards, mailto:barlone@yandex.ru

1 0

(ITS#7194) tlso_session_chkhost issue for OpenSSL TLS
by dimosthenis.pettas＠nsn.com 02 Mar '12

02 Mar '12

Full_Name: Dimosthenis Pettas Version: 2.4.23 OS: SOLARIS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.159.77.167) I use OpenLDAP version 2.4.23 client to connect via TLS to an LDAP server(slapd). i initialize connection with an IPV6 address using url ldap://[fd00:1111:1111:72:20c:29ff:fec5:4ade]:389 and then try to extend connection to TLS with calling ldap_start_tls_s. when trying to match client-server certificates hosts inside tlso_session_chkhost in tls_o.c we try to determine client host type(IS_DNS,IS_IP4,IS_IP6) but for IPV6 it expects to find "[" at first position and "]" at latst one to determine IPV6 address: #ifdef LDAP_PF_INET6 if (name[0] == '[' && strchr(name, ']')) { char *n2 = ldap_strdup(name+1); *strchr(n2, ']') = 0; if (inet_pton(AF_INET6, n2, &addr)) ntype = IS_IP6; LDAP_FREE(n2); } else but it seems that [] have been removed inside ldap_url_parse_ext in Url.c: /* If [ip address]:port syntax, url is [ip and we skip the [ */ ludp->lud_host = LDAP_STRDUP( url + is_v6 ); So name is not [fd00:1111:1111:72:20c:29ff:fec5:4ade] but fd00:1111:1111:72:20c:29ff:fec5:4ade and code above fails to determine ntype = IS_IP6. i modified code to: #ifdef LDAP_PF_INET6 if (inet_pton(AF_INET6, name, &addr)) { ntype = IS_IP6; } else #endif if ((ptr = strrchr(name, '.')) && isdigit((unsigned char)ptr[1])) { if (inet_aton(name, (struct in_addr *)&addr)) { ntype = IS_IP4; } } letting functions inet_pton and inet_aton determing IP type.Scenario worked. Let me know if i miss anything or this should be corrected. Sorry for submitting again ,i wanted to correct email address

1 0

(ITS#7193) SQL backend lost part of data on request
by barlone＠yandex.ru 02 Mar '12

02 Mar '12

Full_Name: barlone Version: 2.4.30 OS: FreeBSD 7.3 URL: Submission from: (NULL) (217.12.195.21) Good day. I have MySQL database (server 5.5.20) which contain data about peoples and organizations. (Dump of this database and others files I have place on our ftp server: ftp://46.28.65.114 user: alien password: neversaynever - read only access). We need to get from LDAP accounts of peoples and organizations which have email (to Mozilla Thunderbird mail client). I setup OpenLDAP server with SQL backend, unixODBC etc. This bridge work, but have serious problem - slapd gives not all objects. I record to openldap.log full trace of loading slapd, connection of LDAP browser (Apache Directory Studio) and searching the request with base: "dc=ffsua,dc=com" and filter: "(mail=*@*)". At line #1432 backend-sql construct and run such query: SELECT DISTINCT ldap_entries.id, orgs.id, 'ffsOrganization' AS objectClass, ldap_entries.dn AS dn FROM ldap_entries, orgs WHERE orgs.id = ldap_entries.keyval AND ldap_entries.oc_map_id = 2 AND 9 = 9 AND orgs.omail IS NOT NULL AND (upper(orgs.omail) LIKE '%@%') Further in the log can be seen that backend-sql retrieves 19 records, but really in database - 22 suitable records (records with id=83,92,93 losted, look to file sql_query_result.csv). But if we watch in LDAP browser, we seen 17(!) records - look to file ldap_search_result.csv, lines with o=... I can not understand the principle on which the records drop out... Please answer, what are your opportunity to address this problem. If you have not - I'd rather know about it immediately - I will have to deal with the source. P.S. Sorry for my English...

1 0

Re: (ITS#7191) libmdb: Alignment of MDB_db members
by h.b.furuseth＠usit.uio.no 02 Mar '12

02 Mar '12

On Fri, 2 Mar 2012 08:03:00 GMT, roy.keene(a)us.army.mil wrote: > Breaking the assignment into an assignment of its members and using > the existing COPY_PGNO() alleviates this fault. memcpy would be simpler, if it is 'db' which is unaligned. Try this instead. --- mdb.c~ 2012-03-02 11:23:21 +++ mdb.c 2012-03-02 11:25:06 @@ -4699,4 +4699,3 @@ mdb_xcursor_init1(MDB_cursor *mc, MDB_no if (node->mn_flags & F_SUBDATA) { - MDB_db *db = NODEDATA(node); - mx->mx_db = *db; + memcpy(&mx->mx_db, NODEDATA(node), sizeof(MDB_db)); mx->mx_cursor.mc_snum = 0; -- Hallvard

1 0

(ITS#7191) libmdb: Alignment of MDB_db members
by roy.keene＠us.army.mil 02 Mar '12

02 Mar '12

Full_Name: Roy Keene Version: 2.4.30 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.30-mdb-alignment-1rsk.diff Submission from: (NULL) (140.194.193.14) Several members of the MDB_db members are not aligned in the "db" or "mx->mx_db" objects. This causes a SIGBUS upon assignment. Breaking the assignment into an assignment of its members and using the existing COPY_PGNO() alleviates this fault. Patch attached is a naive approach.

1 0

(ITS#7190) back-mdb database corruption
by quanah＠OpenLDAP.org 01 Mar '12

01 Mar '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Thread 6 (Thread 1115703648 (LWP 3574)): #0 0x0000002a9785dac7 in mdb_dup_compare (usrkey=0x42803020, curkey=0x42800bb0) at dn2id.c:65 un = (diskNode *) 0x2a984a82b8 cn = (diskNode *) 0x38a64d8480 rc = 0 nrlen = 32799 #1 0x0000002a97868719 in mdb_node_search (mc=0xb5dae8, key=0x42803020, exactp=0x42800c18) at ../../../libraries/libmdb/mdb.c:3027 i = 3402 nkeys = 6804 low = 1 high = 6803 rc = 0 mp = (MDB_page *) 0x3254934000 node = (MDB_node *) 0x3254937932 nodekey = {mv_size = 7977944, mv_data = 0x38a64d8480} cmp = (MDB_cmp_func *) 0x2a9785da94 <mdb_dup_compare> __PRETTY_FUNCTION__ = "mdb_node_search" #2 0x0000002a97868afe in mdb_page_search_root (mc=0xb5dae8, key=0x42803020, modify=0) at ../../../libraries/libmdb/mdb.c:3193 exact = 0 node = (MDB_node *) 0x32549cdb14 i = 17 mp = (MDB_page *) 0x3254934000 rc = 0 __PRETTY_FUNCTION__ = "mdb_page_search_root" #3 0x0000002a97868ed4 in mdb_page_search (mc=0xb5dae8, key=0x42803020, modify=0) at ../../../libraries/libmdb/mdb.c:3309 rc = 0 root = 3223 __PRETTY_FUNCTION__ = "mdb_page_search" #4 0x0000002a97869c5b in mdb_cursor_set (mc=0xb5dae8, key=0x42803020, data=0x0, op=MDB_SET_RANGE, exactp=0x42800f18) at ../../../libraries/libmdb/mdb.c:3651 rc = 0 mp = (MDB_page *) 0x32549ca000 leaf = (MDB_node *) 0x32549caf5c __PRETTY_FUNCTION__ = "mdb_cursor_set" #5 0x0000002a97869e8c in mdb_cursor_set (mc=0xb5d960, key=0x42803030, data=0x42803020, op=MDB_GET_BOTH, exactp=0x42800f8c) at ../../../libraries/libmdb/mdb.c:3699 ex2 = 0 ex2p = (int *) 0x42800f18 rc = 0 mp = (MDB_page *) 0x32549ca000 leaf = (MDB_node *) 0x32549caf5c __PRETTY_FUNCTION__ = "mdb_cursor_set" #6 0x0000002a9786a538 in mdb_cursor_get (mc=0xb5d960, key=0x42803030, data=0x42803020, op=MDB_GET_BOTH) at ../../../libraries/libmdb/mdb.c:3844 rc = -1739947303 exact = 1 __PRETTY_FUNCTION__ = "mdb_cursor_get" #7 0x0000002a9785e3d2 in mdb_dn2id (op=0x428037b0, txn=0xb7cfd0, mc=0xb5d960, in=0x428037e8, id=0x428030f8, matched=0x428030e0, nmatched=0x428030d0) at dn2id.c:317 mdb = (struct mdb_info *) 0x7c0e80 cursor = (MDB_cursor *) 0xb5d960 dbi = 3 key = {mv_size = 8, mv_data = 0x42800ff8} data = {mv_size = 43, mv_data = 0x2a984a82b8} rc = 0 nrlen = 32 d = (diskNode *) 0x2a984a82b8 ptr = 0x2a984a82d9 "" dn = "p?\177@\000\000\000\000@\200J\230*", '\0' <repeats 11 times>, "?\000\000\000\000\000?\000\000\000\000\000\030\000\000\000\000\000\000\000\0201\200B\000\000\000\000??\205\227*", '\0' <repeats 31 times>, "\f\000\000\000\f\000\000\000\000\000\000\000?>{\000\000\000\000\000\001", '\0' <repeats 6751 times>, "\235?N\000\000\000\000\000\2201\200B\000\000\000\000\017\000\000\000\000\000\000\000\020?\000\000\000\000\000\224?N\000\000\000\000\000\000\000\000\0002\000\000\000\000\000\234T2\000\000\000?-\200B\000\000\000\0000\030?\000\000\000\000\000p-\200B\000\000\000\000 -\200B\000\000\000\000?\216\206\227*", '\0' <repeats 11 times>... pid = 1 nid = 1 tmp = {bv_len = 31, bv_val = 0xb5eb10 "reqStart=20120222211913.000001Z,cn=accesslog"} #8 0x0000002a9785d991 in mdb_dn2entry (op=0x428037b0, tid=0xb7cfd0, m2=0xb5d960, dn=0x428037e8, e=0x428032f8, matched=0) at dn2entry.c:50 mdb = (struct mdb_info *) 0x7c0e80 rc = 0 rc2 = 0 id = 18446744073709551615 mbv = {bv_len = 12, bv_val = 0x42802ff1 "cn=accesslog"} nmbv = {bv_len = 0, bv_val = 0xb5eb30 "cn=accesslog"} mc = (MDB_cursor *) 0xb5dce0 #9 0x0000002a9784e0f8 in mdb_delete (op=0x428037b0, rs=0x42803730) at delete.c:171 mdb = (struct mdb_info *) 0x7c0e80 pdn = {bv_len = 12, bv_val = 0xb5eb30 "cn=accesslog"} e = (Entry *) 0x0 p = (Entry *) 0x2a984a80c0 manageDSAit = 0 children = (AttributeDescription *) 0x6c9970 entry = (AttributeDescription *) 0x6c96c0 txn = (MDB_txn *) 0xb7cfd0 mc = (MDB_cursor *) 0xb5d960 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7c0e80}, moi_txn = 0xb7cfd0, moi_ref = 1, moi_flag = 0 '\0'} moi = (mdb_op_info *) 0x428032a0 preread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0x42803661, 0x4280365e, 0x428038f8, 0x42803340, 0x2a97abcb0b} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #10 0x00000000004c2539 in overlay_op_walk (op=0x428037b0, rs=0x42803730, which=op_delete, oi=0x7af320, on=0x0) at backover.c:671 func = (BI_op_bind **) 0x2a97979178 rc = 32768 #11 0x00000000004c2701 in over_op_func (op=0x428037b0, rs=0x42803730, which=op_delete) at backover.c:723 oi = (slap_overinfo *) 0x7af320 on = (slap_overinst *) 0x7b8cf0 be = (BackendDB *) 0x7b1d60 db = {bd_info = 0x2a97979120, bd_self = 0x7b1d60, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\0' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x7b03d0, be_nsuffix = 0x717690, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x7a0190 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x7a1f40 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x7a1e40, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xb416f0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x2a97978f20, be_private = 0x7c0e80, be_next = {stqe_next = 0x7b7d20}} cb = {sc_next = 0x2a97ccf5e0, sc_response = 0x4c16b8 <over_back_response>, sc_cleanup = 0, sc_private = 0x7af320} sc = (slap_callback **) 0x428038e8 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x00000000004c2890 in over_op_delete (op=0x428037b0, rs=0x42803730) at backover.c:780 No locals. #13 0x0000002a97bc6e96 in accesslog_purge (ctx=0x42803ea0, arg=0x7b2690) at accesslog.c:689 i = 0 rtask = (struct re_s *) 0x7b2690 li = (struct log_info *) 0x7b2960 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x4e5d30 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4e5d30 ""}, c_listener = 0x4edca0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write1_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 15 times>, __align = 0}, c_write2_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write2_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 15 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\0', c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = { ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x44d934 <slap_send_ldap_result>, c_send_search_entry = 0x44e703 <slap_send_search_entry>, c_send_search_reference = 0x4506a4 <slap_send_search_reference>, c_send_ldap_extended = 0x44e22d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x44e4e0 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x42803920, o_tag = 74, o_time = 1330639543, o_tincr = 4, o_bd = 0x428033d0, o_req_dn = {bv_len = 44, bv_val = 0xb4c7a0 "reqStart=20120222211913.000001Z,cn=accesslog"}, o_req_ndn = {bv_len = 44, bv_val = 0xb5eb10 "reqStart=20120222211913.000001Z,cn=accesslog"}, o_request = { oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 1, bv_val = 0x649420 "\003"}, rb_ssf = 1115698928, rb_mech = {bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}}, oq_compare = {rs_ava = 0x1}, oq_modify = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '?'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '?'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x649420 "\003"}, rs_nnewrdn = {bv_len = 1115698928, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x2a984a8018, rs_nnewSup = 0x0}, oq_search = { rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x649420, rs_filter = 0x428036f0, rs_filterstr = {bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = {bv_len = 6591520, bv_val = 0x428036f0 "?"}, rs_new = { bv_len = 27, bv_val = 0x2a984a8018 "?3\200B"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x42803a68, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x7a0190 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x7a1f40 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x2a984a8018, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x42803640 "20120223220228.083128Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x428032a0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x42803b70, oh_msgid = 0, oh_protocol = 0, oh_tid = 1115703648, oh_threadctx = 0x42803ea0, oh_tmpmemctx = 0xb5bdf0, oh_tmpmfuncs = 0x6499c0, oh_counters = 0x64cde0, oh_log_prefix = "conn=-1 op=0", '\0' <repeats 243 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = (Operation *) 0x428037b0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x2a97bc686c <log_old_lookup>, sc_cleanup = 0, sc_private = 0x428036a0} f = {f_choice = 166, f_un = {f_un_result = 1115698896, f_un_desc = 0x428036d0, f_un_ava = 0x428036d0, f_un_ssa = 0x428036d0, f_un_mra = 0x428036d0, f_un_complex = 0x428036d0}, f_next = 0x0} ava = {aa_desc = 0x71f2e0, aa_value = {bv_len = 15, bv_val = 0x42803680 "20120223220543Z"}} pd = {slots = 1300, used = 1218, dn = 0xb864c0, ndn = 0xb90690, csn = {bv_len = 40, bv_val = 0x42803640 "20120223220228.083128Z#000000#000#000000"}} timebuf = "20120223220543Z\000\000\000\000\000\000" csnbuf = "20120223220228.083128Z#000000#000#000000", '\0' <repeats 23 times> old = 1330034743 __PRETTY_FUNCTION__ = "accesslog_purge" #14 0x0000002a9556992e in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:688 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0xb5bcb0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1115703648, ltu_key = {{ltk_key = 0x4a4a80, ltk_data = 0xb5bdf0, ltk_free = 0x4a48b0 <slap_sl_mem_destroy>}, {ltk_key = 0x2a981a4010, ltk_data = 0xb5c070, ltk_free = 0x2a9786039f <mdb_reader_free>}, {ltk_key = 0x2a97856c53, ltk_data = 0x2a988aa010, ltk_free = 0x2a97856c33 <search_stack_free>}, {ltk_key = 0x2a978549bd, ltk_data = 0x2a985a9010, ltk_free = 0x2a97854978 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 299 hash = 3142175019 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #16 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 1107310944 (LWP 3573)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1107310944, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 155 hash = 3239160987 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 1098918240 (LWP 3572)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1098918240, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 138 hash = 468719754 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 1090525536 (LWP 3571)): #0 0x0000003252c089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ae8c in ldap_pvt_thread_cond_wait (cond=0x6ce580, mutex=0x6ce558) at thr_posix.c:277 No locals. #2 0x0000002a955698af in ldap_int_thread_pool_wrapper (xpool=0x6ce550) at tpool.c:675 pool = (struct ldap_int_thread_pool_s *) 0x6ce550 task = (ldap_int_thread_task_t *) 0x0 work_list = (ldap_int_tpool_plist_t *) 0x6ce5e8 ctx = {ltu_id = 1090525536, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 32 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 1018 hash = 565705722 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #4 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 1082132832 (LWP 3570)): #0 0x00000032523c63dc in epoll_wait () from /lib64/tls/libc.so.6 No symbol table info available. #1 0x0000000000434488 in slapd_daemon_task (ptr=0x7fbffff6e4) at daemon.c:2539 ns = 1 at = 0 nfds = 6 revents = (struct epoll_event *) 0x6a4b90 tvp = (struct timeval *) 0x40800170 cat = {tv_sec = 1330639843, tv_usec = 0} i = 1 nwriters = 0 now = 1330639543 tv = {tv_sec = 300, tv_usec = 0} tdelta = 1 rtask = (struct re_s *) 0x798870 l = 5 last_idle_check = 1330639543 ebadf = 0 tid = 0 #2 0x0000003252c0610a in start_thread () from /lib64/tls/libpthread.so.0 No symbol table info available. #3 0x00000032523c6003 in clone () from /lib64/tls/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 182905778400 (LWP 3567)): #0 0x0000003252c06ffb in pthread_join () from /lib64/tls/libpthread.so.0 No symbol table info available. #1 0x0000002a9556ade4 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x00000000004355fe in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 listener_tid = (ldap_pvt_thread_t *) 0x7b2720 #3 0x000000000041500a in main (argc=11, argv=0x7fbffff8d8) at main.c:1012 i = 11 no_detach = 1 rc = 0 urls = 0x69e030 "ldap:/// ldaps:/// ldapi:///" username = 0x69e010 "localhost" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 1376822842 waitfds = {0, 0} g_argc = 11 g_argv = (char **) 0x7fbffff8d8 configfile = 0x0 configdir = 0x69e060 "/opt/zimbra/data/ldap/config" serverName = 0x7fbffffb3f "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x4e5845 "" l = 0 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7189) OPEN LDAP - Bug
by quanah＠zimbra.com 01 Mar '12

01 Mar '12

--On Thursday, March 01, 2012 2:51 PM +0000 jose.gomez(a)cafedecolombia.com wrote: > Full_Name: Jose Alberto G?mez Ruiz > Version: OpenLDAP: pkg/ldap/servers/slapd/schema/openldap.schema,v > 1.24.2.4 This is not a valid OpenLDAP version. > deleting entry > cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com > ldap_delete: Unknown error > ldap_delete: additional info: could not locate parent of entry This message says you somehow deleted the parent of the entry without deleting this entry first, leaving it orphaned. I would suggest you use slapcat & slapadd to fix your database. --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

(ITS#7189) OPEN LDAP - Bug
by jose.gomez＠cafedecolombia.com 01 Mar '12

01 Mar '12

Full_Name: Jose Alberto Gómez Ruiz Version: OpenLDAP: pkg/ldap/servers/slapd/schema/openldap.schema,v 1.24.2.4 OS: Solaris 10 10/08 s10s_u6wos_07b SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.3.164.196) Hello, I have a problem with OPEN LDAP V.2.4 : I am trying to add the th following entry by console : -bash-3.00$ ldapadd -f empleado-103.txt -v -D "cn=Manager,dc=fnc-federacion,dc=com" -w password ldapadd: started Wed Feb 29 16:56:24 2012 ldap_init( localhost, 389 ) add cn: 1093735269 add sn: ROCHEL ORTEGA ELIZABETH add mail: add userPassword: 1093735269 add objectclass: inetOrgPerson FNCPerson adding new entry cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com ldap_add: Already exists The entry exists agree with the message. Then I want search thy entry : -bash-3.00$ ldapsearch -x -b 'dc=fnc-federacion,dc=com' '(cn=1093735269*)' -bash-3.00$ I do not get the data from this input. Then I cant delete the same entry: -bash-3.00$ ldapmodify -D "cn=Manager,dc=fnc-federacion,dc=com" -w password dn: cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com changetype: delete deleting entry cn=1093735269,ou=ServicioExtension,ou=Usuarios,dc=fnc-federacion,dc=com ldap_delete: Unknown error ldap_delete: additional info: could not locate parent of entry I Can't modify or delete this entry, Please, I need help to fix this error. Thanks in advance

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs