- openldap-bugs - openldap.org

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

I wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Argh, something ate the part which says what I'm talking about: mdb_open() and mdb_close(), and partly mdb_drop() Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Related doc bug: > > I expect it should be "only one thread at a time". I doubt > it's about pinning some operation to a particular thread:-) Wrong. For write txns I suppose that could be relaxed. For readers, the reader slot is set when the txn is created, and that slot is owned by a particular thread. > However, maybe it should rather be something like "No other > transaction doing mdb_open() may exist at the same time, nor > a write transaction (since that also updates the databases), > nor may such a transaction exist during mdb_close()" ? > > I note mdb_drop() also updates the databases and can > likely not coexist with the others, but that's covered by > mentioning write txns. > > Regarding mdb_drop(), while I'm at it: > @brief Delete a database and/or free all its pages. > @param[in] del non-zero to delete the DB from > the environment, otherwise just free its pages. > Free which pages? In the DB, or some malloced ones? This is single-level-store, there is no distinction. In the DB or in memory, all the same. -- -- 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#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

On Sun, 8 Apr 2012 00:49:28 GMT, h.b.furuseth(a)usit.uio.no wrote: > './run -b ldif test045-syncreplication-proxied' crashed > in connection_abandon() with LDAP_MEMORY_DEBUG: > It dereferenced o_hdr which is NULL in the uninitialized or > freed op 'o'. (op 'o' is full of 0xFF bytes, which I > assume is the poiosin from liblber/memory.c.) Reproduced with bdb. It's a freed op sitting in the c->c_ops list when entering connection_abandon(). (Checked my modifying the "poison" in liblber and inspecting the list before the be_abandon loop.) Not reproduced under valgrind so far. -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 09 Apr '12

09 Apr '12

Related doc bug: I expect it should be "only one thread at a time". I doubt it's about pinning some operation to a particular thread:-) However, maybe it should rather be something like "No other transaction doing mdb_open() may exist at the same time, nor a write transaction (since that also updates the databases), nor may such a transaction exist during mdb_close()" ? I note mdb_drop() also updates the databases and can likely not coexist with the others, but that's covered by mentioning write txns. Regarding mdb_drop(), while I'm at it: @brief Delete a database and/or free all its pages. @param[in] del non-zero to delete the DB from the environment, otherwise just free its pages. Free which pages? In the DB, or some malloced ones? I expect it should be "delete a database or empty its contents", and "del non-zero ... otherwise just empty the database." -- Hallvard

1 0

Re: (ITS#7238) Multiple txns in same thread break mdb
by hyc＠symas.com 09 Apr '12

09 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > mdb.h says a transaction must only be used by a single thread, > but libmdb also assumes a thread only has one transaction: Yes, this is a design requirement. Doc should be updated if it doesn't already state this explicitly. -- -- 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#7238) Multiple txns in same thread break mdb
by h.b.furuseth＠usit.uio.no 08 Apr '12

08 Apr '12

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard mdb.h says a transaction must only be used by a single thread, but libmdb also assumes a thread only has one transaction: If there have been some commits since the oldest txn, and a new txn then starts in the same thread as an oldest txn, the oldest txnid is overwritten in the reader table. Writers can then modify pages the oldest txn still uses. Example: This should print A, but prints AEFG. It commits an "A", starts a reader and reads the A, then several commits delete the lowest letter and add two newer letter: -A +BC, -B +DE, -C +FG... while starting new readers, then reads more with 1st reader. #include "mdb.h" #include <assert.h> #include <pthread.h> #include <stdio.h> #include <unistd.h> #define E(expr) assert(!(expr)) enum { Count = 6 }; static char dbname[] = "testdb.mdb"; static MDB_env *env; static MDB_dbi dbi; static pthread_barrier_t barrier; static void *reader(void *arg) { int i, rc; MDB_txn *txns[Count]; MDB_cursor *cursor; MDB_val key, data; pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[0])); E(mdb_cursor_open(txns[0], dbi, &cursor)); E(mdb_cursor_get(cursor, &key, &data, MDB_NEXT)); fputs((char *) key.mv_data, stdout); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, MDB_RDONLY, &txns[i])); pthread_barrier_wait(&barrier); } while ((rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT)) == 0) fputs((char *) key.mv_data, stdout); puts("."); assert(rc == MDB_NOTFOUND); return arg; } int main(void) { char add[2] = "A", del[2] = "A"; MDB_val key = {2, add}, dkey = {2, del}, data = {3, "Hi"}; MDB_txn *txn; pthread_t tid; int i; unlink(dbname); E(mdb_env_create(&env)); E(mdb_env_open(env, dbname, MDB_NOSUBDIR, 0660)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); E(pthread_barrier_init(&barrier, NULL, 2)); E(pthread_create(&tid, NULL, reader, NULL)); pthread_barrier_wait(&barrier); for (i = 1; i < Count; i++) { pthread_barrier_wait(&barrier); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_del(txn, dbi, &dkey, NULL )); ++*del; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_put(txn, dbi, &key, &data, 0)); ++*add; E(mdb_txn_commit(txn)); pthread_barrier_wait(&barrier); } pthread_barrier_wait(&barrier); E(pthread_join(tid, NULL)); return 0; } I have not looked at what happens if some of the readers are in the same thread as the writer.

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 08 Apr '12

08 Apr '12

On 04.04.2012 17:45, Hrvoje Habjanić wrote: > On 03.04.2012 17:41, Howard Chu wrote: >> You may be able to avoid this bug by using an alternate malloc >> library, such as Google tcmalloc. >> > Hi. > > I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is > that this happened in "pthread_mutex_lock" which is in libpthread.so ...? > > Another bug in centos libs? I would appreciate if you could take a look. > > Thx. > > H. > > p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log Hi. And, one more SIGSEGV ... Should i open a new ITS? H. p.s. http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ssegv.log

1 0

Re: (ITS#7202) slapo-memeberof crashing OL 2.4.30
by marco.pizzoli＠gmail.com 08 Apr '12

08 Apr '12

--20cf300fa9cf6deac304bd27f749 Content-Type: multipart/alternative; boundary=20cf300fa9cf6deabd04bd27f747 --20cf300fa9cf6deabd04bd27f747 Content-Type: text/plain; charset=ISO-8859-1 Hi Howard, On Sat, Apr 7, 2012 at 7:07 PM, Howard Chu <hyc(a)symas.com> wrote: > marco.pizzoli(a)gmail.com wrote: > >> Full_Name: Marco Pizzoli >> Version: 2.4.30 >> OS: Linux >> URL: ftp://ftp.openldap.org/**incoming/<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: >> > > Please send the complete consumer config. Also the provider config and > sample DB. > In attachment you can find the sanitized consumer configurations of both the consumer and the provider. I cannot share my db, but I cannot be of help anyway because ldifs produced both by ldapsearch and slapcat produced a clean database / clean db entries. The problem arises only after a corruption on the data as *published* from the provider. As I wrote, this was a problem we already were having. Other times we simply found one server which doesn't publish wrong data and then clearing the other ones: drop the db and starting from scratch replicating from this one. > > Please let me know if you keed other details. >> Thanks >> Marco >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/**project/<http://www.openldap.org/project/> > --20cf300fa9cf6deabd04bd27f747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard,<br><br><div class=3D"gmail_quote">On Sat, Apr 7, 2012 at 7:07 PM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> <a href=3D"mailto:marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli@= gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Marco Pizzoli<br> Version: 2.4.30<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (213.174.164.11)<br> <br> <br> Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the d= ay before<br> the release, but nothing changed in the meantime).<br> <br> I have a consumer starting from scratch with an empty db. During his starti= ng he<br> populates his db by connecting to 4 servers which are part of a 4-way<br> multi-master cluster. They are running a previous version of OpenLDAP.<br> We are doing an upgrade of our deployment just to solve an issue we face fr= om<br> time to time consisting in data corruption.<br> This bug, which is not the target of this ITS, is able to trigger a crash o= f the<br> slave slapd 2.4.30.<br> <br> During the first synchronization the consumer is receiving the entire db an= d I<br> can see on this slave, in the logs, coming two odd entries, like this one:<= br> </blockquote> <br> Please send the complete consumer config. Also the provider config and samp= le DB.<br></blockquote><div><br></div><div>In attachment you can find the= =A0sanitized=A0consumer configurations of both the consumer and the provide= r.</div> <div><br></div><div>I cannot share my db, but I cannot be of help anyway be= cause ldifs produced both by ldapsearch and slapcat produced a clean databa= se / clean db entries. The problem arises only after a corruption on the da= ta as *published* from the provider.</div> <div>As I wrote, this was a problem we already were having. Other times we = simply found one server which doesn't publish wrong data and then clear= ing the other ones: drop the db and starting from scratch replicating from = this one.</div> <div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Please let me know if you keed other details.<br> Thanks<br> Marco<span><font color=3D"#888888"><br> </font></span></blockquote><span><font color=3D"#888888"> <br> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br> --20cf300fa9cf6deabd04bd27f747-- --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="consumer.conf" Content-Disposition: attachment; filename="consumer.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8deb0 c2NoZW1hZG4JY249U3Vic2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvY29yZS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5sZGFw L3NjaGVtYS9jb3NpbmUuc2NoZW1hDQppbmNsdWRlCQkvb3B0L29wZW5sZGFwL2V0Yy9vcGVubGRh cC9zY2hlbWEvcHBvbGljeS5zY2hlbWENCmluY2x1ZGUJCS9vcHQvb3BlbmxkYXAvZXRjL29wZW5s ZGFwL3NjaGVtYS9yZmMyMzA3YmlzLnNjaGVtYQ0KaW5jbHVkZQkJL29wdC9vcGVubGRhcC9ldGMv b3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hDQppbmNsdWRlCQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9jdXN0b20uc2NoZW1hDQoNCm1vZHVsZXBhdGgJL29wdC9vcGVubGRhcC9saWJl eGVjL29wZW5sZGFwDQptb2R1bGVsb2FkCW1lbWJlcm9mLmxhDQptb2R1bGVsb2FkCWFjY2Vzc2xv Zy5sYQ0KbW9kdWxlbG9hZAlhdWRpdGxvZy5sYQ0KbW9kdWxlbG9hZAlwcG9saWN5LmxhDQptb2R1 bGVsb2FkCXNzc3Zsdi5sYQ0KbW9kdWxlbG9hZAlzeW5jcHJvdi5sYQ0KbW9kdWxlbG9hZAlsYXN0 YmluZC5sYQ0KbW9kdWxlbG9hZAljb25zdHJhaW50LmxhDQptb2R1bGVsb2FkCXZhbHNvcnQubGEN Cg0KcGlkZmlsZQkJIi9vcHQvb3BlbmxkYXAvdmFyL3J1bi9zbGFwZC5waWQiDQphcmdzZmlsZQki L29wdC9vcGVubGRhcC92YXIvcnVuL3NsYXBkLmFyZ3MiDQoNCnRocmVhZHMgMTYNCg0KaWRsZXRp bWVvdXQgMTgwMA0KcmV2ZXJzZS1sb29rdXAgb2ZmDQoNCmdlbnRsZWh1cCBvbg0KDQp0b29sLXRo cmVhZHMgMQ0KDQpzaXplbGltaXQgdW5saW1pdGVkDQoNClRMU0NpcGhlclN1aXRlIEhJR0g6TUVE SVVNDQoNClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteXBhdGg+DQpUTFNDZXJ0aWZpY2F0ZUZpbGUg PG15cGF0aD4NClRMU0NlcnRpZmljYXRlS2V5RmlsZSA8bXlwYXRoPg0KVExTVmVyaWZ5Q2xpZW50 IG5ldmVyDQoNCg0KaW5jbHVkZSA8cGF0aF90b19hY2xzX2ZpbGU+DQoNCmRhdGFiYXNlICAgICAg IG1vbml0b3INCnJvb3RkbiAgICAgICAgIGNuPW1vbml0b3INCnJvb3RwdyAgICAgICAgIG15X3Nl Y3JldA0KDQptb25pdG9yaW5nIG9uDQoNCmRhdGFiYXNlICAgICAgICBoZGINCnN1ZmZpeCAgICAg ICAgICAiZGM9bXlfc3VmZml4Ig0Kcm9vdGRuICAgICAgICAgICJjbj1NYW5hZ2VyLGRjPW15X3N1 ZmZpeCINCnJvb3RwdwkJe1NTSEF9bXlfc3NoYV9wYXNzd29yZA0KZGlyZWN0b3J5ICAgICAgIDxt eV9kaXI+DQppbmRleCAgICAgICAgICAgY24gICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAg ICAgb3UgICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgb2JqZWN0Q2xhc3MgICAgIGVx DQppbmRleCAgICAgICAgICAgdWlkICAgICAgICAgICAgIGVxDQppbmRleCAgICAgICAgICAgZ2lk TnVtYmVyICAgICAgIGVxDQppbmRleCAgICAgICAgICAgdWlkTnVtYmVyICAgICAgIGVxDQppbmRl eCAgICAgICAgICAgbWVtYmVyICAgICAgICAgIHByZXMsZXENCmluZGV4ICAgICAgICAgICBtZW1i ZXJVaWQgICAgICAgZXENCmluZGV4CQltZW1iZXJPZgllcQ0KaW5kZXggICAgICAgICAgIGVudHJ5 Q1NOICAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIGVudHJ5VVVJRCAgICAgICBlcQ0KaW5kZXgJ CXVzZXJQYXNzd29yZAlwcmVzDQppbmRleAkJdW5pcXVlTWVtYmVyCWVxDQppbmRleAkJZGVzY3Jp cHRpb24JcHJlcw0KaW5kZXgJCWNzZUFtYmllbnRlCWVxDQppbmRleAkJY3NlV2VibWluQW1iaWVu dGUJZXENCmluZGV4CQljc2VVZmZpY2lvCWVxDQppbmRleAkJY3NlUHJvZ2V0dG8JZXENCmluZGV4 CQljc2VUaXBvR3J1cHBvCWVxDQppbmRleAkJY3NlREIyR3J1cHBpUHJpdmlsZWdpCWVxDQoNCmxp bWl0cyAgICAgICAgICBkbj0iY249TWFuYWdlcixkYz1teV9zdWZmaXgiIHNpemU9dW5saW1pdGVk DQpsaW1pdHMJCWRuPSI8bXlfc3luY3JlcGxfdXNlcnM+IiAgICAgc2l6ZT11bmxpbWl0ZWQNCg0K cmVxdWlyZQkJYXV0aGMgTERBUHYzDQphZGRfY29udGVudF9hY2wJb24NCmNhY2hlc2l6ZSAgICAg ICA0MDAwDQpkbmNhY2hlc2l6ZSAgICAgMA0KaWRsY2FjaGVzaXplICAgIDUwMDAwDQpjYWNoZWZy ZWUgICAgICAgMTANCmNoZWNrcG9pbnQgICAgICAxMDI0IDMwDQpzaG1fa2V5CQkxMDAwDQoNCmRi Y29uZmlnCXNldF9sZ19kaXIJCTxteV9kYmRpcj4NCmRiY29uZmlnCXNldF9sZ19tYXgJCTEwNDg1 NzYwDQpkYmNvbmZpZwlzZXRfbGdfcmVnaW9ubWF4CTI2MjE0NA0KZGJjb25maWcJc2V0X2xnX2Jz aXplCQkyMDk3MTUyDQpkYmNvbmZpZwlzZXRfY2FjaGVzaXplCQkwIDI2ODQzNTQ1NiAxDQpkYmNv bmZpZwlzZXRfbGtfbWF4X29iamVjdHMJMzAwMA0KZGJjb25maWcJc2V0X2xrX21heF9sb2Nrcwkz MDAwDQpkYmNvbmZpZwlzZXRfbGtfbWF4X2xvY2tlcnMJMzAwMA0KZGJjb25maWcJc2V0X2ZsYWdz CQlEQl9MT0dfQVVUT1JFTU9WRQ0KDQpvdmVybGF5IHZhbHNvcnQNCnZhbHNvcnQtYXR0ciBtZW1i ZXJVaWQgb3U9Z3JvdXBzLDxteV9zdWZmaXg+IGFscGhhLWFzY2VuZA0KdmFsc29ydC1hdHRyIG1l bWJlciAgICBvdT1ncm91cHMsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQp2YWxzb3J0LWF0dHIg bWVtYmVyVWlkIG91PXNlcnZpY2UsPG15X3N1ZmZpeD4gYWxwaGEtYXNjZW5kDQoNCm92ZXJsYXkg bGFzdGJpbmQNCg0Kb3ZlcmxheSBwcG9saWN5DQpwcG9saWN5X2RlZmF1bHQgY249ZGVmYXVsdCxv dT1Qb2xpY2llcyw8bXlfc3VmZml4Pg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNo X2NsZWFydGV4dA0KcHBvbGljeV9mb3J3YXJkX3VwZGF0ZXMNCg0Kb3ZlcmxheSBzeW5jcHJvdg0K c3luY3Byb3YtY2hlY2twb2ludCA1MCAxMA0Kc3luY3Byb3Ytc2Vzc2lvbmxvZyAxNTANCg0Kb3Zl cmxheSBhdWRpdGxvZw0KYXVkaXRsb2cgPHBhdGhfdG9fbXlfYXVkaXRsb2dfZmlsZT4NCg0Kb3Zl cmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBPZk5hbWVzDQptZW1iZXJvZi1t ZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBtZW1iZXJPZg0KbWVtYmVyb2Yt ZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFuZ2xpbmcgaWdub3JlDQptZW1i ZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50IEZBTFNFDQoNCm92ZXJsYXkg c3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zsdi1tYXhrZXlzIDUNCg0Kc2VydmVySUQgICAgICAg MDE1DQoNCnN5bmNyZXBsIHJpZD0wMDENCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAxDQogIHR5 cGU9cmVmcmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15 X3N1ZmZpeCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9 bXl0cmVlIg0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAg dGxzX3JlcWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoN CnN5bmNyZXBsIHJpZD0wMDINCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAyDQogIHR5cGU9cmVm cmVzaEFuZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZp eCINCiAgYXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVl Ig0KICBiaW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3Jl cWNlcnQ9bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNy ZXBsIHJpZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFu ZFBlcnNpc3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAg YXR0cnM9IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBi aW5kbWV0aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9 bmV2ZXINCiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCnN5bmNyZXBsIHJp ZD0wMDMNCiAgcHJvdmlkZXI9bGRhcDovL215bGRhcDAzDQogIHR5cGU9cmVmcmVzaEFuZFBlcnNp c3QNCiAgcmV0cnk9IjMwICsiDQogIHNlYXJjaGJhc2U9ImRjPW15X3N1ZmZpeCINCiAgYXR0cnM9 IiosKyINCiAgYmluZGRuPSJjbj1zeW5jcmVwbC1sZGFwMTUsb3U9bXl0cmVlIg0KICBiaW5kbWV0 aG9kPXNpbXBsZQ0KICBjcmVkZW50aWFscz1teV9zZWNyZXQNCiAgdGxzX3JlcWNlcnQ9bmV2ZXIN CiAgaW50ZXJ2YWw9MDA6MDA6MDA6MTANCiAgdGltZW91dD0xDQoNCm1pcnJvcm1vZGUgICAgIFRS VUUNCg0KbG9nbGV2ZWwgODMyDQo= --20cf300fa9cf6deac304bd27f749 Content-Type: application/octet-stream; name="provider.conf" Content-Disposition: attachment; filename="provider.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0rx8gti1 aW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL2NvcmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEvY29zaW5lLnNj aGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1hL3Bwb2xp Y3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIuNC9zY2hlbWEv bmlzLnNjaGVtYQ0KaW5jbHVkZSAgICAgICAgIC91c3Ivc2hhcmUvb3BlbmxkYXAyLjQvc2NoZW1h L3JmYzIzMDdiaXMuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9zaGFyZS9vcGVubGRhcDIu NC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWENCg0KaW5jbHVkZQkJL2V0Yy9vcGVubGRhcDIu NC9zY2hlbWEvY3VzdG9tLnNjaGVtYQ0KDQptb2R1bGVwYXRoICAgL3Vzci9sb2NhbC9vcGVubGRh cC9saWI2NC8NCm1vZHVsZWxvYWQgbGFzdGJpbmQubGENCg0KcGlkZmlsZSAgICAgICAgIC92YXIv cnVuL2xkYXAyLjQvc2xhcGQucGlkDQphcmdzZmlsZSAgICAgICAgL3Zhci9ydW4vbGRhcDIuNC9z bGFwZC5hcmdzDQp0aHJlYWRzIDE2DQppZGxldGltZW91dCAxODAwDQpyZXZlcnNlLWxvb2t1cCBv ZmYNCmdlbnRsZWh1cCBvbg0KdG9vbC10aHJlYWRzIDMNCnNpemVsaW1pdCB1bmxpbWl0ZWQNCg0K VExTQ2lwaGVyU3VpdGUgSElHSDpNRURJVU0NClRMU0NBQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRo Pg0KVExTQ2VydGlmaWNhdGVGaWxlIDxteV9wYXRoPg0KVExTQ2VydGlmaWNhdGVLZXlGaWxlIDxt eV9wYXRoPg0KVExTVmVyaWZ5Q2xpZW50IG5ldmVyDQoNCmluY2x1ZGUgPHBhdGhfdG9fYWNsc19m aWxlPg0KDQpkYXRhYmFzZSAgICAgICBtb25pdG9yDQpyb290ZG4gICAgICAgICBjbj1tb25pdG9y DQpyb290cHcgICAgICAgICBteV9zZWNyZXQNCg0KbW9uaXRvcmluZyBvbg0KDQpkYXRhYmFzZSAg ICAgICAgaGRiDQpzdWZmaXggICAgICAgICAgImRjPW15X3N1ZmZpeCINCnJvb3RkbiAgICAgICAg ICAiY249TWFuYWdlcixkYz1teV9zdWZmaXgiDQpyb290cHcJCXtTU0hBfW15X3NzaGFfcGFzc3dv cmQNCmRpcmVjdG9yeSAgICAgICA8bXlfZGlyPg0KaW5kZXggICAgICAgICAgIGNuICAgICAgICAg ICAgICBlcQ0KaW5kZXggICAgICAgICAgIG91ICAgICAgICAgICAgICBlcQ0KaW5kZXggICAgICAg ICAgIG9iamVjdENsYXNzICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVpZCAgICAgICAgICAgICBl cQ0KaW5kZXggICAgICAgICAgIGdpZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIHVp ZE51bWJlciAgICAgICBlcQ0KaW5kZXggICAgICAgICAgIG1lbWJlciAgICAgICAgICBwcmVzLGVx DQppbmRleCAgICAgICAgICAgbWVtYmVyVWlkICAgICAgIGVxDQppbmRleAkJbWVtYmVyT2YJZXEN CmluZGV4ICAgICAgICAgICBlbnRyeUNTTiAgICAgICAgZXENCmluZGV4ICAgICAgICAgICBlbnRy eVVVSUQgICAgICAgZXENCmluZGV4CQl1c2VyUGFzc3dvcmQJcHJlcw0KaW5kZXgJCXVuaXF1ZU1l bWJlcgllcQ0KaW5kZXgJCWRlc2NyaXB0aW9uCXByZXMNCmluZGV4CQlteUFtYmllbnRlCWVxDQpp bmRleAkJbXlXZWJtaW5BbWJpZW50ZQllcQ0KaW5kZXgJCW15VWZmaWNpbwllcQ0KaW5kZXgJCW15 UHJvZ2V0dG8JZXENCmluZGV4CQlteVRpcG9HcnVwcG8JZXENCmluZGV4CQlteURCMkdydXBwaVBy aXZpbGVnaQllcQ0KDQpsaW1pdHMgICAgICAgICAgZG49ImNuPU1hbmFnZXIsZGM9bXlfc3VmZml4 IiBzaXplPXVubGltaXRlZA0KDQpjYWNoZXNpemUgICAgICAgMzUwMA0KZG5jYWNoZXNpemUgICAg IDANCmlkbGNhY2hlc2l6ZSAgICA1MDAwMA0KY2FjaGVmcmVlICAgICAgIDEwDQpjaGVja3BvaW50 ICAgICAgMTAyNCAzMA0KDQpvdmVybGF5IGxhc3RiaW5kDQoNCm92ZXJsYXkgcHBvbGljeQ0KcHBv bGljeV9kZWZhdWx0IGNuPWRlZmF1bHQsb3U9UG9saWNpZXMsPG15X3N1ZmZpeD4NCnBwb2xpY3lf dXNlX2xvY2tvdXQNCnBwb2xpY3lfaGFzaF9jbGVhcnRleHQNCnBwb2xpY3lfZm9yd2FyZF91cGRh dGVzDQoNCm92ZXJsYXkgc3luY3Byb3YNCnN5bmNwcm92LWNoZWNrcG9pbnQgNTAgMTANCnN5bmNw cm92LXNlc3Npb25sb2cgMTUwDQoNCm92ZXJsYXkgYXVkaXRsb2cNCmF1ZGl0bG9nIDxwYXRoX3Rv X215X2F1ZGl0bG9nX2ZpbGU+DQoNCm92ZXJsYXkgc3Nzdmx2DQpzc3N2bHYtbWF4IDQNCnNzc3Zs di1tYXhrZXlzIDUNCg0Kb3ZlcmxheSBtZW1iZXJvZg0KbWVtYmVyb2YtZ3JvdXAtb2MgZ3JvdXBP Zk5hbWVzDQptZW1iZXJvZi1tZW1iZXItYWQgbWVtYmVyDQptZW1iZXJvZi1tZW1iZXJvZi1hZCBt ZW1iZXJPZg0KbWVtYmVyb2YtZG4gY249TWFuYWdlciw8bXlfc3VmZml4Pg0KbWVtYmVyb2YtZGFu Z2xpbmcgaWdub3JlDQptZW1iZXJvZi1kYW5nbGluZy1lcnJvciA4MA0KbWVtYmVyb2YtcmVmaW50 IEZBTFNFDQoNCnNlcnZlcklEICAgICAgICAwMDENCg0Kc3luY3JlcGwgcmlkPTAwMg0KICBwcm92 aWRlcj1sZGFwOi8vbXlsZGFwMDINCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0i MzAgKyINCiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5k ZG49ImNuPXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQog IGNyZWRlbnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0w MDowMDowMDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwMw0KICBwcm92aWRlcj1s ZGFwOi8vbXlsZGFwMDMNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyIN CiAgc2VhcmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNu PXN5bmNyZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRl bnRpYWxzPW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDow MDoxMA0KICB0aW1lb3V0PTENCg0Kc3luY3JlcGwgcmlkPTAwNA0KICBwcm92aWRlcj1sZGFwOi8v bXlsZGFwMDQNCiAgdHlwZT1yZWZyZXNoQW5kUGVyc2lzdA0KICByZXRyeT0iMzAgKyINCiAgc2Vh cmNoYmFzZT0iZGM9bXlfc3VmZml4Ig0KICBhdHRycz0iKiwrIg0KICBiaW5kZG49ImNuPXN5bmNy ZXBsLWxkYXAwMSxvdT1teXRyZWUiDQogIGJpbmRtZXRob2Q9c2ltcGxlDQogIGNyZWRlbnRpYWxz PW15X3NlY3JldA0KICB0bHNfcmVxY2VydD1uZXZlcg0KICBpbnRlcnZhbD0wMDowMDowMDoxMA0K ICB0aW1lb3V0PTENCg0KbWlycm9ybW9kZSAgICAgVFJVRQ0KDQpsb2dsZXZlbCA4MzI= --20cf300fa9cf6deac304bd27f749--

1 0

(ITS#7237) Crash abandoning freed/unused operation
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24 + master patches OS: Linux x86_64 URL: http://folk.uio.no/hbf/test045.testrun.tgz Submission from: (NULL) (195.1.106.125) Submitted by: hallvard './run -b ldif test045-syncreplication-proxied' crashed in connection_abandon() with LDAP_MEMORY_DEBUG: It dereferenced o_hdr which is NULL in the uninitialized or freed op 'o'. (op 'o' is full of 0xFF bytes, which I assume is the poiosin from liblber/memory.c.) The code is RE24 + recent master patches: RE24 (0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f) + ITS#7228 check for unexpected result from ldapsearch + ITS#7231 fix idl_append when b has only 1 element + ITS#7231 simplify prev commit + ITS#7233 Fix slapd listener initialization. + ITS#7234 Fix syncprov entry leak: Set op->o_tag + ITS#7235 prevent sop from being freed during init Configured with --enable-overlays --enable-backends --disable-sql --disable-ndb --enable-cleartext --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rlookups --enable-slapi --enable-wrappers CFLAGS="-O0 -g" CPPFLAGS="-DLDAP_MEMORY_DEBUG -DLDAP_THREAD_DEBUG=2 -DUSE_RS_ASSERT". Test output and some GDB trace info enclosed.

1 0

Re: (ITS#7235) test058 hanging in slapd shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

No hang/failure in 250 test058 runs, on RE24 + master commit 9e6245f87e5d2fc0b0c52c7aacf5e5ccac115839 "ITS#7235 prevent sop from being freed during init". Reproduced it *without* that commit after 70 runs on a busy host. Quite similar. <http://folk.uio.no/hbf/its7235.testdir2.tgz> has output, gdb trace and testrun/ if that is of any interest. Both tested RE24 variants also have the latest other master fixes: ITS#7228, #7231, #7233, #7234. -- Hallvard

1 0

Re: (ITS#7236) new test030-relay failure in old code
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 15:25:34 GMT, hyc(a)symas.com wrote: > you had a server listening on 9012 when no such server should > have been present. Some test scripts hard-code default values that can be configured differently in scripts/defines.sh. In this case, $SLAPD_BASEPORT. I'll look into that later. Hallvard

1 0

Re: (ITS#7221) Support private keys in PKCS #8 in slapd when linked with gnutls
by hyc＠symas.com 07 Apr '12

07 Apr '12

komyagin(a)altell.ru wrote: > Full_Name: Alexander Komyagin > Version: 2.4.23 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.16.156.18) > > > Hi! I found out that when slapd is linked with gnutls, it fails to parse private > key on startup if the one is given in PKCS #8 form (TLS init def ctx failed: > -207). > > The problem is in tlsg_ctx_init() (tls_g.c) function, which calls > gnutls_x509_privkey_import() from gnutls. But gnutls_x509_privkey_import() is > designed to support only RSA/DSA keys, while for PKCS#8 > gnutls_x509_privkey_import_pkcs8() shall be used. > > I think that incorporating such enhancement for slapd would make it even better > (for example, some popular commands like "openssl req" generate keys in PKCS #8) > :) Especially when such enhancement can be done in a few lines of code (just > like certtool does): Please read http://www.openldap.org/devel/contributing.html and submit an actual patch if you want this suggestion to be considered. > if (!info.pkcs8) > ret = gnutls_x509_privkey_import (key,&pem, info.incert_format); > > /* If we failed to import the certificate previously try PKCS #8 */ > if (info.pkcs8 || ret == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) > { > /* first try to import the key without asking any password */ > ret = gnutls_x509_privkey_import_pkcs8 (key,&pem, > info.incert_format, > NULL, GNUTLS_PKCS_PLAIN); > if (ret< 0) > { > if (info.pass) > pass = info.pass; > else > pass = get_pass (); > ret = gnutls_x509_privkey_import_pkcs8 (key,&pem, > info.incert_format, > pass, 0); > } > } > > -- -- 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#7202) slapo-memeberof crashing OL 2.4.30
by hyc＠symas.com 07 Apr '12

07 Apr '12

marco.pizzoli(a)gmail.com wrote: > 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: Please send the complete consumer config. Also the provider config and sample DB. > Please let me know if you keed other details. > Thanks > Marco -- -- 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#7110) cn=config mixes values
by hyc＠symas.com 07 Apr '12

07 Apr '12

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.26 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.232.151) > > > Hi, > > I try to modify valuse of eg. olcAccess with a certain order, I get different > values if numbered values are in the correct order or not. > > Case 1 (normal): > > dn: olcDatabase={3}bdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write > > Result: > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write Cannot confirm. I get 0, 1, and 2 in the expected order. > Case 2 (inversed values): > > dn: olcDatabase={3}bdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > > Result: > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write > > The two last values are incorrectly mixed. Wrong, this works as designed. See draft-chu-ldap-xordered-xx section 3.3. 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

Re: (ITS#7224) Core dump while trying to run slapd
by hyc＠symas.com 07 Apr '12

07 Apr '12

ashish gawarikar wrote: > On 4/6/2012 10:22 AM, Howard Chu wrote: >> >> Find out why oc->oc_names is NULL. It should not be. Seems like you >> have an invalid schema definition. >> > I have fixed the objectClasses that were violating by adding > "extensibleObject". > > Also, the slapadd-ing should not "core", and give the right error message. Agreed. But since you haven't provided us with the steps to reproduce the error, we have nothing to go on. -- -- 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#7236) new test030-relay failure in old code
by hyc＠symas.com 07 Apr '12

07 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.10->latest RE24 > OS: Linux x86_64 > URL: http://folk.uio.no/hbf/testrun.test030.ldif.tgz > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > ./run -b<bdb/hdb/mdb/ldif> test030-relay > all fail in openldap-2.4.10 and current RE24 (I did not test earlier). > > It always fails on my laptop, but succeeds on my older workstation. > Both have > Red Hat Enterprise Linux Workstation release 6.2 (Santiago) > gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) > Also it succeeds on a host with RHEL 5.8; gcc 4.1.2. > > OpenLDAP confiruation: > ./configure (--disable-backends) --enable-relay --enable-ldap --enable-rwm > > Output, slapcat output and testrun directory enclosed. Seems to have something to do with IPv6 support and whether there's a listener on ::1 port 9012. Here's your slapd.1.log at the point of divergence: ldap_chase_v3referral: msgid 3, url "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9012 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying ::1 9012 ldap_pvt_connect: fd: 16 tm: -1 async: 0 anonymous rebind via ldap_sasl_bind("") 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 16 ldap_result ld 0x7fd9a0002120 msgid 5 wait4msg ld 0x7fd9a0002120 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x7fd9a0002120 msgid 5 all 1 ** ld 0x7fd9a0002120 Connections: * host: localhost port: 9012 refcnt: 2 status: Connected last used: Fri Apr 6 22:32:52 2012 rebind in progress queue is empty Here's mine, from a successful run: ldap_chase_v3referral: msgid 3, url "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9012 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying 127.0.0.1:9012 ldap_pvt_connect: fd: 16 tm: -1 async: 0 ldap_close_socket: 16 ldap_err2string Unable to chase referral "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" (-1: Can't contact LDAP server) ber_scanf fmt ({v) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_url_parse_ext(ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub) 4f805943 ==> rewrite_context_apply [depth=1] string='ou=Referrals,o=Beispiel,c=DE' 4f805943 ==> rewrite_context_apply [depth=1] res={0,'NULL'} 4f805943 [rw] referralDN: "ou=Referrals,o=Beispiel,c=DE" -> "ou=Referrals,o=Beispiel,c=DE" 4f805943 => send_search_reference: dn="(null)" ber_flush2: 64 bytes to sd 9 4f805943 <= send_search_reference I believe your test environment is corrupted; you had a server listening on 9012 when no such server should have been present. -- -- 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#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

I wrote: > Aha, slapd_daemon() sets i=0 after starting the threads. > Reproduced the crash now by sleeping before setting i=0. Reproduced in unpatched RE24, I mean. It's fixed in master. Hallvard

1 0

Re: (ITS#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 12:38:30 GMT, h.b.furuseth(a)usit.uio.no wrote: > Fixed in master, e6a25b2db6d7f4dc5d3370e06e3a3e03c5a6635d. > > Or at least, fixed some broken code in master. But I wonder > why it usually worked before. Testing with sleep(1) before > reading tid = *(int*)ptr in slapd_daemon_task() ought > to fail (lets caller increment i first), but doesn't. Aha, slapd_daemon() sets i=0 after starting the threads. Reproduced the crash now by sleeping before setting i=0. This ITS probably explains a bunch of other problems, in that all 'slapd_daemon_task's usually have been running with tid=0, even if there were more listeners. assert(tid==0) in slapd_daemon_task does not crash when starting slapd with multiple URLs, unless I sleep after the loop which starts the threads. -- Hallvard

1 0

Re: (ITS#7231) back0hdb search results disappear depending on search base
by hyc＠symas.com 07 Apr '12

07 Apr '12

hume-ol(a)bofh.ca wrote: > Full_Name: Brandon Hume > Version: -OPENLDAP_REL_ENG_2_4-0e03b13 > OS: Redhat AS6 > URL: http://den.bofh.ca/~hume/ldap_missing_results.tar.gz > Submission from: (NULL) (2610:170:2c00:7:224:1ff:fed4:b4ff) Thanks for the report and test case. Fixed now in git master. > Firstly, using RE24 built with the following ./configure: > > > #!/bin/sh > env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib > -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ > ./configure --prefix=/appl/ldap \ > --libexecdir=/appl/ldap/sbin --localstatedir=/var/run > --datadir=/appl/ldap/data \ > --sysconfdir=/appl/ldap/etc --mandir=/appl/ldap/man > --with-subdir=no \ > --disable-rlookups --with-tls=openssl \ > --enable-slapd --enable-crypt --with-cyrus-sasl=no > --enable-debug \ > --enable-dynamic --enable-modules \ > --enable-backends=mod --enable-overlays=mod --enable-sql=no \ > --enable-perl=no --enable-ndb=no --enable-shell=no > > Paired with BerkeleyDB built with the following: > > #!/bin/sh > env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib > -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ > ../dist/configure --prefix=/appl/ldap > > DIT has 131207 entries. Search results will come and go as you shorten the > search base. For example, when searching for "maillocaladdress=vbroken(a)dal.ca", > which has the full DN of > "cn=broken129251,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA", the following > will occur: > > Searching with base=cn=dal,cn=Mailmaps,cn=services,dc=dal,dc=ca: Found. > Searching with base=cn=Mailmaps,cn=services,dc=dal,dc=ca: NOT found. > Searching with base=cn=services,dc=dal,dc=ca: NOT found. > Searching with base=dc=dal,dc=ca: Found. > > cn=dal has 123312 children, which is very high. However, breaking the branch up > into subcontainers, none of which had more than 10k entries, did not cure the > problem. > > With olcLogLevel=any, the following is notable: > > Successful search: > > > Apr 5 21:09:01 kil-ds-3 slapd[17628]: => > hdb_dn2idl("cn=dal,cn=mailmaps,cn=services,dc=dal,dc=ca") > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011AND > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011OR > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_index_read: failed (-30988) > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=0, > first=0, last=0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=0 > last=0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates > (mailLocalAddress) > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_index_read 1 candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=1, > first=129301, last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_search_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: entry_decode: "" > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= entry_decode() > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => test_filter > > Unsuccessful search: > > > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => > hdb_dn2idl("cn=mailmaps,cn=services,dc=dal,dc=ca") > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011AND > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011OR > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_index_read: failed (-30988) > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=0, > first=0, last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=0 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates > (mailLocalAddress) > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_index_read 1 candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=1, > first=129301, last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_search_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: hdb_search: no candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: conn=1001 op=1 p=3 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: err=0 matched="" > text="" > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_response: msgid=2 tag=101 > err=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: conn=1001 op=1 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > I'm including a link to a tarball that contains: > - My (simplified) config, that still produces the problem. I'm managed to > remove locally-created schemas. > - My test LDIF, containing the entries that can produce the problem. > They've been anonymized, but it doesn't affect the problem. A server loaded > with the above config and this DIT will be consistently unable to find the > "maillocaladdress=vbroken(a)dal.ca" entry at cn=services,dc=dal,dc=ca search > base. > - My test script, test_ldap.sh, that searches for the above entry at the > levels in between it and the base naming context (dc=dal,dc=ca). > > I can provide more if needed, up to and including the compiled binaries. > > -- -- 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#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 05:52:15 GMT, h.b.furuseth(a)usit.uio.no wrote: > test058(hdb): SLAP_SOCK_NOT_ACTIVE() crashed during shutdown > because slap_daemon[id].sd_index is NULL: Fixed in master, e6a25b2db6d7f4dc5d3370e06e3a3e03c5a6635d. Or at least, fixed some broken code in master. But I wonder why it usually worked before. Testing with sleep(1) before reading tid = *(int*)ptr in slapd_daemon_task() ought to fail (lets caller increment i first), but doesn't. -- Hallvard

1 0

Re: (ITS#7232) Searching for Deleted Objects
by michael＠stroeder.com 07 Apr '12

07 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030803070108020903050607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rai.abhishek(a)yahoo.com wrote: > i am try to developed a small c# application through which i want to ge= t all > deleted objects information from OpenLDAP.i am using SQL db as a back-e= nd at the > time of set up the OpenLDAP server.i am enable to search deleted entity= > information (person,group etc) from openldap.as per my finding i am ena= ble to > find any procedure or trigger in OpenLDAP database. so please suggest m= e how can > i get this information from OpenLDAP. Such a question should be posted to the openldap-technical mailing list n= ot to this bug tracker. Ciao, Michael. --------------ms030803070108020903050607 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNzExMjEzMlowIwYJKoZIhvcNAQkEMRYE FJpFJ3gQjj84ntWcodllfXVA507OMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAN+l1npom/EjJA6uxbA3grjEpbs/7EUdcbvW2I+dEq+3x649TnKH2nscM8WYzZohzScQD VdOIar7XyX0PaviT5n4MyfguwO2OGSZ3LIJ1ELaR5xxKNl9c/gd5/4CMNhuyrkQFnhY4gDQv VKSq3LdReTtyTBQ/OIEKceaLUcUUt/Fi+66aE8kdT8DhDE1ujF7a9ED1vFDNFVw4NtNsfE7+ KCJJKuMt23qBHikwa2YKb4RBEPPggFlKRCjtpoDpnrxJ24KmAlxsCmRN8t5L78lGSctfCEVJ XJVpASIgKvgjX+q9DoDNzxPyDLZv8PXJLk5rOc7T6lnCWmRd5yqEKfJ/BwAAAAAAAA== --------------ms030803070108020903050607--

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Howard Chu wrote: > Also, you're using monitor_entry_stub() directly in the back-ldap code. It is > forbidden for modules to directly reference each other's symbols. If you need > this function, add it to monitor_extra_t first and call it through there. Thus, currently './configure --enable-ldap --disable-monitor' does not compile in master. .../back-ldap/monitor.c:752: undefined reference to `monitor_entry_stub' .../back-ldap/monitor.c:782: undefined reference to `monitor_entry_stub' .../back-ldap/monitor.c:592: undefined reference to `monitor_entry_stub' .../back-ldap/monitor.c:514: undefined reference to `monitor_entrypriv_create' -- Hallvard

1 0

(ITS#7236) new test030-relay failure in old code
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Full_Name: Hallvard B Furuseth Version: 2.4.10->latest RE24 OS: Linux x86_64 URL: http://folk.uio.no/hbf/testrun.test030.ldif.tgz Submission from: (NULL) (195.1.106.125) Submitted by: hallvard ./run -b <bdb/hdb/mdb/ldif> test030-relay all fail in openldap-2.4.10 and current RE24 (I did not test earlier). It always fails on my laptop, but succeeds on my older workstation. Both have Red Hat Enterprise Linux Workstation release 6.2 (Santiago) gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) Also it succeeds on a host with RHEL 5.8; gcc 4.1.2. OpenLDAP confiruation: ./configure (--disable-backends) --enable-relay --enable-ldap --enable-rwm Output, slapcat output and testrun directory enclosed.

1 0

Re: (ITS#7235) test058 hanging in slapd shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Testrun directory is in <http://folk.uio.no/hbf/its7235.testdir.tgz>. slapd.2.log has some extra stuff from other tests. I haven't stopped this test, and forgot to change test port when running other tests. -- Hallvard

1 0

(ITS#7235) test058 hanging in slapd shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24, 0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard >>>>> Starting test058-syncrepl-asymmetric for hdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Starting site1 master slapd on TCP/IP port 9012... Using ldapsearch to check that site1 master is running... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master is running... Starting central search slapd on TCP/IP port 9014... Using ldapsearch to check that central search slapd is running... Starting site1 search slapd on TCP/IP port 9015... Using ldapsearch to check that site1 search slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Adding schema on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/... Adding schema on ldap://localhost:9014/... Adding schema on ldap://localhost:9015/... Adding schema on ldap://localhost:9016/... Adding database config on central master... Adding database config on site1 master... Adding database config on site2 master... Adding access rules on central master... Adding access rules on site1 master... Adding access rules on site2 master... Adding database config on central search... Adding database config on site1 search... Adding database config on site2 search... Populating central master... Adding syncrepl on site1 master... Adding syncrepl on site2 master... Using ldapsearch to check that site1 master received changes... Using ldapsearch to check that site2 master received changes... Populating site1 master... Populating site2 master... Stopping site1 master... Adding syncrepl on central master... Using ldapsearch to check that central master received site2 entries... Using ldapmodify to modify central master... Restarting site1 master slapd on TCP/IP port 9012... Using ldapsearch to check that site1 master is running... Using ldapsearch to check that central master received site1 entries... Using ldapsearch to check that site1 master received central master update... Using ldapsearch to check that site2 master received central master update... Adding syncrepl consumer on central search... Adding syncrepl consumer on site1 search... Adding syncrepl consumer on site2 search... Using ldapsearch to check that central search received changes... Using ldapsearch to check that site1 search received changes... Using ldapsearch to check that site2 search received changes... Checking contextCSN after initial replication... Using ldapmodify to modify first backend on central master... Using ldapsearch to check replication to central search... Using ldapsearch to check replication to site1 search... Using ldapsearch to check replication to site2 search... Checking contextCSN after modify of first backend on central master... Using ldapmodify to modify second backend on central master... Using ldapsearch to check replication to site2 search... Using ldapsearch to check no replication to site1 master... Using ldapsearch to check no replication to central search... Checking contextCSN after modify of second backend on central master... Using ldapmodify to modify first backend on site1 master... Using ldapsearch to check replication to site1 search... Using ldapsearch to check replication to site2 master... Using ldapsearch to check no replication to site2 search... Using ldapsearch to check no replication to central search... Checking contextCSN after modify of first backend on site1 master... Using ldapmodify to modify second backend on site1 master... Using ldapsearch to check replication to site1 search... Using ldapsearch to check no replication to central master... Checking contextCSN after modify of second backend on site1 master... Using ldapmodify to modify first backend on site2 master... Using ldapsearch to check replication to central master... Using ldapsearch to check replication to site2 search... Using ldapsearch to check no replication to site1 master... Using ldapsearch to check no replication to central search... Checking contextCSN after modify of first backend on site2 master... Using ldapmodify to modify second backend on site2 master... Using ldapsearch to check replication to site2 search... Using ldapsearch to check no replication to central master... Checking contextCSN after modify of second backend on site2 master... Stopping central master and site2 servers to test start with emtpy db... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Using ldapsearch to check that site2 master received base... Using ldapsearch to check that site2 search received base... Waiting 1 seconds for syncrepl to receive changes... Checking contextCSN after site2 servers repopulated... Adding syncrepl of second site1 master backend on central master... Using ldapsearch to check that central master received second site1 backend... Waiting 1 seconds for syncrepl to receive changes... Waiting 2 seconds for syncrepl to receive changes... Waiting 3 seconds for syncrepl to receive changes... Waiting 4 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ERROR: Second site1 backend not replicated to central master Restarting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Waiting 1 seconds for slapd to start... Using ldapsearch to check that central master received second site1 backend... Using ldapsearch to check that central search received second site1 backend... Waiting 1 seconds for syncrepl to receive changes... Waiting 2 seconds for syncrepl to receive changes... Waiting 3 seconds for syncrepl to receive changes... Waiting 4 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ERROR: Second site1 backend not replicated to central search Restarting central search slapd on TCP/IP port 9014... Using ldapsearch to check that central search slapd is running... Waiting 1 seconds for slapd to start... Using ldapsearch to check that central search received second site1 backend... Running 1 of 10 syncrepl race tests... Stopping central master... Using ldapadd to add entry on site1 master... Starting central master again... Using ldapsearch to check that central master received entry... Using ldapsearch to check that central search received entry... Stopping central master... Using ldapdelete to delete entry on site1 master... Starting central master again... Using ldapsearch to check that entry was deleted on central master... Using ldapsearch to check that entry was deleted on central search... Running 2 of 10 syncrepl race tests... Stopping central master... (gdb) p slapd_shutdown $14 = 1 (gdb) thread apply all backtrace full 3 threads: Thread 1 in pthread_join () in main() Thread 3 in pthread_cond_wait, ldap_pvt_thread_pool_destroy Thread 2 (Thread 0x7f037bfff700 (LWP 9735)): #0 0x000000321d20dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000321d209328 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x000000321d2091f7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f038875055d in ldap_int_thread_mutex_lock (mutex=0x7f037410e208) at thr_posix.c:296 No locals. #4 0x00007f0388751a31 in ldap_pvt_thread_mutex_lock (mutex=0x7f037410e208) at thr_debug.c:1000 rc = 1946161144 #5 0x00000000005ea3eb in syncprov_op_search (op=0x7f037410e460, rs=0x7f037bffe970) at syncprov.c:2731 fand = 0x7f0374000fb0 fava = 0x7f0374000fd0 on = 0x22c1ae0 si = 0x22c1ce0 cb = 0x7f037bffd650 gotstate = 1 changed = 2 do_present = 1 sop = 0x7f037410e1b0 ss = 0x7f037bffe970 srs = 0x7f0374000c20 ctxcsn = 0x7f0374000ea8 i = 3 sids = 0x7f0374000f98 numcsns = 3 mincsn = { bv_len = 40, bv_val = 0x7f0374000d58 "20120405104436.067185Z#000000#002#000000" } maxcsn = { bv_len = 40, bv_val = 0x7f0374000d58 "20120405104436.067185Z#000000#002#000000" } minsid = 2 maxsid = 2 dirty = 0 #6 0x00000000004c8d9a in overlay_op_walk (op=0x7f037410e460, rs=0x7f037bffe970, which=op_search, oi=0x22c0f90, on=0x22c1ae0) at backover.c:661 func = 0x22c1b38 rc = 32768 #7 0x00000000004c9049 in over_op_func (op=0x7f037410e460, rs=0x7f037bffe970, which=op_search) at backover.c:723 oi = 0x22c0f90 on = 0x22c1ae0 be = 0x22bf2b0 db = { bd_info = 0x22c1ae0, bd_self = 0x22bf2b0, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\000\001\000\000\000\000\000\000\000\000\000\000\001", be_flags = 2328, 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 = 0x22b7980, be_nsuffix = 0x22ba3e0, be_schemadn = { bv_len = 0, bv_val = 0x0 }, be_schemandn = { bv_len = 0, bv_val = 0x0 }, be_rootdn = { bv_len = 28, bv_val = 0x22bf800 "cn=Manager,dc=example,dc=com" }, be_rootndn = { bv_len = 28, bv_val = 0x22bbee0 "cn=manager,dc=example,dc=com" }, be_rootpw = { bv_len = 6, bv_val = 0x22bdfd0 "secret" }, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, 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 = 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 = 0x28e5d90, be_pcl_mutex = { __data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 2, __spins = 0, __list = { __prev = 0x0, __next = 0x0 } }, __size = '\000' <repeats 16 times>, "\002", '\000' <repeats 22 times>, __align = 0 }, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8b27c0, be_private = 0x22bf460, be_next = { stqe_next = 0x0 } } cb = { sc_next = 0x0, sc_response = 0x4c7e0f <over_back_response>, sc_cleanup = 0, sc_private = 0x22c0f90 } sc = 0x7f037bffe970 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00000000004c9131 in over_op_search (op=0x7f037410e460, rs=0x7f037bffe970) at backover.c:750 No locals. #9 0x000000000044553a in fe_op_search (op=0x7f037410e460, rs=0x7f037bffe970) at search.c:402 bd = 0x8ba380 #10 0x0000000000444d7e in do_search (op=0x7f037410e460, rs=0x7f037bffe970) at search.c:247 base = { bv_len = 17, bv_val = 0x7f037410dfd7 "dc=example,dc=com" } siz = 2 off = 0 i = 2 #11 0x0000000000441d6c in connection_operation (ctx=0x7f037bffeaa0, arg_v=0x7f037410e460) at connection.c:1150 rc = 80 cancel = 33 op = 0x7f037410e460 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 } tag = 99 opidx = SLAP_OP_SEARCH conn = 0x22f2960 memctx = 0x7f03740008d0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #12 0x00000000004422db in connection_read_thread (ctx=0x7f037bffeaa0, argv=0x21) at connection.c:1286 rc = 0 cri = { op = 0x7f037410e460, func = 0, arg = 0x0, ctx = 0x7f037bffeaa0, nullop = 0 } s = 33 #13 0x00007f038874ef12 in ldap_int_thread_pool_wrapper (xpool=0x2178a40) at tpool.c:688 pool = 0x2178a40 task = 0x7f037c000bd0 work_list = 0x2178ad8 ctx = { ltu_id = 139652942001920, ltu_key = {{ ltk_key = 0x4ab5f3, ltk_data = 0x7f03740008d0, ltk_free = 0x4ab418 <slap_sl_mem_destroy> }, { ltk_key = 0x28e5dc0, ltk_data = 0x7f0374108fd0, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x441924, ltk_data = 0x7f037410e840, ltk_free = 0x441768 <conn_counter_destroy> }, { ltk_key = 0x45a695, ltk_data = 0x0, ltk_free = 0x45a5e8 <slap_op_q_destroy> }, { ltk_key = 0x4f3113, ltk_data = 0x7f036afff020, ltk_free = 0x4f30f0 <search_stack_free> }, { ltk_key = 0x22392a0, ltk_data = 0x7f0374109630, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x2298a30, ltk_data = 0x7f0374109b00, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x2240020, ltk_data = 0x7f03741098a0, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x2244460, ltk_data = 0x7f037410e1b0, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x280ab40, ltk_data = 0x7f037410e2f0, ltk_free = 0x550307 <bdb_reader_free> }, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0 } <repeats 22 times>} } kctx = 0x0 i = 32 keyslot = 947 hash = 2196128691 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"

1 0

(ITS#7234) syncprov entry not freed in result.c
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24, 0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard syncprov_db_open() does not set op->o_tag before submitting syncprov_db_otask. This prevents rs_flush_entry() before slap_send_search_entry()'s error return. Seen in test018 and test048 with back-ldif. Two possible fixes: --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -3088,2 +3088,3 @@ syncprov_db_open( if ( si->si_ctxcsn && !SLAP_DBCLEAN( be )) { + op->o_tag = LDAP_REQ_SEARCH; op->o_req_dn = be->be_suffix[0]; Hopefully the lack of o_tag is not a feature, deliberately preventing some things from assuming it's a search request. E.g. maybe more fields in the fake op must be filled in. Or this test could be less paranoid: --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1466,3 +1466,3 @@ error_return:; - if ( op->o_tag == LDAP_REQ_SEARCH && rs->sr_type == REP_SEARCH ) { + if ( rs->sr_type == REP_SEARCH ) { rs_flush_entry( op, rs, NULL ); It was a bad idea to trust sr_type when the test was written. The SlapReply cleanup (ITS#6758) mostly fixed that, but is not complete. OpenLDAP passes make alltests with both patches and USE_RS_ASSERT, except an unrelated error which also fails in unpatched RE24.

1 0

Re: (ITS#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

I wrote: > test058(hdb): SLAP_SOCK_NOT_ACTIVE() crashed during shutdown > because slap_daemon[id].sd_index is NULL: Correction: Startup, not shutdown. slapd_shutdown == 0. Testrun currently in <http://folk.uio.no/hbf/its7233.testrun.tgz>, output in testrun/OUTPUT, the core file was in testrun/sm2/.

1 0

(ITS#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 06 Apr '12

06 Apr '12

Full_Name: Hallvard B Furuseth Version: RE24, 0e03b1369f4da5db9d0bdd2445b3a7ccc0c5638f OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard test058(hdb): SLAP_SOCK_NOT_ACTIVE() crashed during shutdown because slap_daemon[id].sd_index is NULL: #0 in slapd_add (s=-1, isactive=0, sl=0x0, id=1) at daemon.c:856 856 assert( SLAP_SOCK_NOT_ACTIVE(id, s) ); # define SLAP_EPOLL_SOCK_IX(t,s) (slap_daemon[t].sd_index[(s)]) # define SLAP_SOCK_NOT_ACTIVE(t,s) (SLAP_EPOLL_SOCK_IX(t,s) == -1) (gdb) backtrace full #0 0x000000000042433a in slapd_add (s=-1, isactive=0, sl=0x0, id=1) at daemon.c:856 __PRETTY_FUNCTION__ = "slapd_add" #1 0x00000000004285dc in slapd_daemon_task (ptr=0x7ffff6b550a8) at daemon.c:2136 l = 0 last_idle_check = 0 ebadf = 0 tid = 1 #2 0x000000321d2077f1 in start_thread () from /lib64/libpthread.so.0 #3 0x000000321cae5ccd in clone () from /lib64/libc.so.6 (gdb) p slap_daemon[id] $1 = { sd_mutex = { __data = { __lock = 1, __count = 0, __owner = 12683, __nusers = 1, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0 } }, __size = "\001\000\000\000\000\000\000\000\213\061\000\000\001", '\000' <repeats 26 times>, __align = 1 }, sd_nactives = 0, sd_nwriters = 0, sd_nfds = 0, sd_epolls = 0x0, sd_index = 0x0, sd_epfd = 0 } The only other thread is waiting in pthread_join().

1 0

Re: (ITS#7227) Problem to add new entry
by quanah＠zimbra.com 06 Apr '12

06 Apr '12

--On Friday, April 06, 2012 5:20 AM +0000 rai.abhishek(a)yahoo.com wrote: Stop filing ITSes because you don't know how to use the software. Again, subscribe to the openldap-technical(a)openldap.org mailing list, and ask your questions there. All of your ITSes will be ignored unless they are reporting an actual problem. --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#7232) Searching for Deleted Objects
by rai.abhishek＠yahoo.com 06 Apr '12

06 Apr '12

Full_Name: Abhishek Rai Version: V3 OS: windows server 2008 r2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.245.33.179) Hi All i am try to developed a small c# application through which i want to get all deleted objects information from OpenLDAP.i am using SQL db as a back-end at the time of set up the OpenLDAP server.i am enable to search deleted entity information (person,group etc) from openldap.as per my finding i am enable to find any procedure or trigger in OpenLDAP database. so please suggest me how can i get this information from OpenLDAP. thanks Abhishek

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

On 4/6/2012 10:22 AM, Howard Chu wrote: > > Find out why oc->oc_names is NULL. It should not be. Seems like you > have an invalid schema definition. > I have fixed the objectClasses that were violating by adding "extensibleObject". Also, the slapadd-ing should not "core", and give the right error message.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by hyc＠symas.com 06 Apr '12

06 Apr '12

ashish(a)sendmail.com wrote: > Same place when I am trying to slapadd. Find out why oc->oc_names is NULL. It should not be. Seems like you have an invalid schema definition. > [root@qa-perf13 ~]# gdb /usr/local/sendmail/smd/sbin/slapadd > GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) > Copyright (C) 2009 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 /usr/local/sendmail/smd-5.0/sbin/slapadd...done. > (gdb) core /var/core/core.slapadd.3064.11 > [New Thread 3064] > Reading symbols from /lib64/libdl.so.2...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libresolv.so.2...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libresolv.so.2 > 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 /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 > warning: no loadable sections found in added symbol-file system-supplied > DSO at 0x7fff4d324000 > Core was generated by `/usr/local/sendmail/smd/sbin/slapadd -l > newldif.new.new.6 -w -c'. > Program terminated with signal 11, Segmentation fault. > #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 > 403 oc.c: No such file or directory. > in oc.c > (gdb) where > #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 > #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, > argv=<value optimized out>) at slapadd.c:493 > #5 0x0000000000404f32 in main (argc=5, argv=0x7fff4d2c1cf8) at main.c:410 > (gdb) p * names > Cannot access memory at address 0x0 > (gdb) p names > $1 = (char **) 0x0 > (gdb) p *oc > $2 = {soc_oclass = {oc_oid = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16", > oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, > oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions > = 0x0}, soc_cname = { > bv_len = 26, bv_val = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16"}, > soc_sups = 0x1bbbf3a0, soc_required = 0x1bbbf3c0, soc_allowed = 0x0, > soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next > = 0x1bbc0fd0}} > (gdb) p oc > $3 = (ObjectClass *) 0x1bbbf6f0 > > > -- -- 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#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

Errors like this are logged while slapadd-ing: 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery 4f7e23f3 => hdb_tool_entry_put: txn_commit failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) slapadd: could not add entry dn="sendmailMTAKey=69261@imcnamxe.ssmb.com,sendmailMTAMapName=emailtopnl,sendmailMTACluster=qqq,dc=maps,dc=repo" (line=3980378): txn_commit failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery 4f7e23f3 => hdb_tool_entry_put: txn_begin failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) slapadd: could not add entry dn="sendmailMTAKey=69262@imcnamxe.ssmb.com,sendmailMTAMapName=emailtopnl,sendmailMTACluster=qqq,dc=maps,dc=repo" (line=3980389): txn_begin failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

Same place when I am trying to slapadd. [root@qa-perf13 ~]# gdb /usr/local/sendmail/smd/sbin/slapadd GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) Copyright (C) 2009 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 /usr/local/sendmail/smd-5.0/sbin/slapadd...done. (gdb) core /var/core/core.slapadd.3064.11 [New Thread 3064] Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 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 /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 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff4d324000 Core was generated by `/usr/local/sendmail/smd/sbin/slapadd -l newldif.new.new.6 -w -c'. Program terminated with signal 11, Segmentation fault. #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 403 oc.c: No such file or directory. in oc.c (gdb) where #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:493 #5 0x0000000000404f32 in main (argc=5, argv=0x7fff4d2c1cf8) at main.c:410 (gdb) p * names Cannot access memory at address 0x0 (gdb) p names $1 = (char **) 0x0 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = { bv_len = 26, bv_val = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x1bbbf3a0, soc_required = 0x1bbbf3c0, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x1bbc0fd0}} (gdb) p oc $3 = (ObjectClass *) 0x1bbbf6f0

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 06 Apr '12

06 Apr '12

quanah(a)zimbra.com wrote: > --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> 2. add an equality matching rule. >>>> >>>> My approach with config attrs has been to skip the equality rule for >>>> single-valued attrs. Since they are single-valued, there's obviously >>>> no need >>>> to allow for comparing multiple values. >> >> Users always find more ways to use a feature than its creator imagined. >> >> I wish people would give attributes all matching rules they can. >> Equality, ordering, substring. Except when: >> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >> - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. > > I agree. I think defining matching rules where possible is extremely > useful. Patch welcome. This is a pretty trivial patch to write, but I have more urgent things to attend to. -- -- 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#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 06 Apr '12

06 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030508030008000509010204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please revisit this ITS. I'd like to implement something like "svn revert= " based on accesslog entries. Having the entry's UUID in an indexable attri= bute would make this more robust. This could also be handy for delta-replication if "conflicting" modrdn requests were sent by a client which result in same reqDN. Ciao, Michael. --------------ms030508030008000509010204 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNjA5NDgyNVowIwYJKoZIhvcNAQkEMRYE FEygunV2ggv0vvJFXsDT6osh9+aiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAd3aWU7Cwit2Su125+MLAv0K6Ar9XJF9Uhm+X68eeerTXodk1MKIG9JX7PsdFrQyAX3KE R1PjeWVfQvUnVMlutKSem29k6q6pd+iATl+bSB3PgJXWyPKk2K3S2gAGPmL8vubRwEfoCCqt OJBAxseomsPbO1310vSt1KsJYxnLYIQIsBuY0mGWmNcwYCnLitW3erW1ipvancsxwVI4Uy4D EiwtVrP75c1f20VRdiUA5dCeBfi2f18bsyUyaLTccC7vHCMkwSx4VXJk8rEyYB74UpHM/Zbv a5tNipz5K3YDkSJbRhB+Qma2+hMSzvFhbq1XwI6HBladZ8hDmqOYZqGBhwAAAAAAAA== --------------ms030508030008000509010204--

1 0

Re: (ITS#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 05 Apr '12

05 Apr '12

--1454997657-1528916171-1333689558=:73347 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi All=0A=0AI am using OpenLDAP server and use .net application as a client= but face issue regarding add new entry like (Country and Organization etc)= . the error message are =0A=0AAn error occurred while creating entry.=0AThe= server is not willing to handle directory requests.=0A=0Abut with the same= setting and access rights=A0i am able to create some entry like (Person,Gr= oup,Organizational Unit) i am new for OpenLDAP but as per my understanding = it's a access problem in slapd.conf file.=0A=0Afor safe point i am modifyed= the slapd.conf file and provide below access slapd.conf =0Aaccess to * by= * write=0A=A0=0Ato achieve this operation.=0A=A0=0APlease suggest what acc= ess rights need to provide or what changes need to done to resolve this pro= blem.=0A=A0=0AI am waiting for your replay.=0A=0A=0A=0A=0AThanks & Regards= =0AAbhishek Rai=0AHCL Technolog=0A =0A=0A________________________________= =0A From: Quanah Gibson-Mount <quanah(a)zimbra.com>=0ATo: rai.abhishek(a)yahoo.= com; openldap-its(a)openldap.org =0ASent: Friday, April 6, 2012 12:54 AM=0ASu= bject: Re: (ITS#7227) Problem to add new entry=0A =0A--On Thursday, April = 05, 2012 12:38 PM +0000 rai.abhishek(a)yahoo.com wrote:=0A=0A> Full_Name: Abh= ishek Rai=0A> Version: 3=0A> OS: Windows Server 2008 R2=0A> URL: ftp://ftp.= openldap.org/incoming/=0A> Submission from: (NULL) (207.46.55.29)=0A=0ATHe = ITS system is for reporting bugs, not asking usage questions.=A0 I suggest = you subscribe to the openldap-technical(a)openldap.org list, and ask your usa= ge questions there.=0A=0AThis ITS will be closed.=0A=0A--Quanah=0A=0A=0A--= =0A=0AQuanah Gibson-Mount=0ASr. Member of Technical Staff=0AZimbra, Inc=0AA= Division of VMware, Inc.=0A--------------------=0AZimbra ::=A0 the leader = in open source messaging and collaboration --1454997657-1528916171-1333689558=:73347 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ve= rdana, helvetica, sans-serif;font-size:12pt"><div><span>Hi All<br><br>I am = using OpenLDAP server and use .net application as a client but face issue r= egarding add new entry like (Country and Organization etc). the error messa= ge are <br><br>An error occurred while creating entry.<br>The server is not= willing to handle directory requests.<br><br>but with the same setting and= access rights i am able to create some entry like (Person,Group,Organ= izational Unit) i am new for OpenLDAP but as per my understanding it's a ac= cess problem in slapd.conf file.<br><br>for safe point i am modifyed the sl= apd.conf file and provide below access slapd.conf <br>access to * by * wri= te</span></div><div><span></span> </div><div><span>to achieve this ope= ration.</span></div><div><span></span> </div><div><span>Please suggest= what access rights need to provide or what changes need to done to resolve this problem.</span></div><div><span></span> </div><div><span= >I am waiting for your replay.</div><div><br><br><br></div></span><div></di= v><div> </div><div>Thanks & Regards<br>Abhishek Rai<br>HCL Technol= og<br></div> <div style=3D"font-family: verdana, helvetica, sans-serif; fo= nt-size: 12pt;"> <div style=3D"font-family: times new roman, new york, time= s, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Ari= al"> <div style=3D"margin: 5px 0px; padding: 0px; border: 1px solid rgb(204= , 204, 204); height: 0px; line-height: 0; font-size: 0px;" class=3D"hr" con= tentEditable=3D"false" readonly=3D"true"></div> <b><span style=3D"font-wei= ght: bold;">From:</span></b> Quanah Gibson-Mount <quanah(a)zimbra.com><= br> <b><span style=3D"font-weight: bold;">To:</span></b> rai.abhishek@yahoo= .com; openldap-its(a)openldap.org <br> <b><span style=3D"font-weight: bold;">= Sent:</span></b> Friday, April 6, 2012 12:54 AM<br> <b><span style=3D"font-= weight: bold;">Subject:</span></b> Re: (ITS#7227) Problem to add new entry<br> </f= ont> </div> <br>=0A--On Thursday, April 05, 2012 12:38 PM +0000 <a href=3D"= mailto:rai.abhishek@yahoo.com" ymailto=3D"mailto:rai.abhishek@yahoo.com">ra= i.abhishek(a)yahoo.com</a> wrote:<br><br>> Full_Name: Abhishek Rai<br>>= Version: 3<br>> OS: Windows Server 2008 R2<br>> URL: <a href=3D"ftp:= //ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/inco= ming/</a><br>> Submission from: (NULL) (207.46.55.29)<br><br>THe ITS sys= tem is for reporting bugs, not asking usage questions.  I suggest you = subscribe to the <a href=3D"mailto:openldap-technical@openldap.org" ymailto= =3D"mailto:openldap-technical@openldap.org">openldap-technical(a)openldap.org= </a> list, and ask your usage questions there.<br><br>This ITS will be clos= ed.<br><br>--Quanah<br><br><br>--<br><br>Quanah Gibson-Mount<br>Sr. Member = of Technical Staff<br>Zimbra, Inc<br>A Division of VMware, Inc.<br>--------= ------------<br>Zimbra ::  the leader in open source messaging and col= laboration<br><br><br> </div> </div> </div></body></html> --1454997657-1528916171-1333689558=:73347--

1 0

(ITS#7231) back0hdb search results disappear depending on search base
by hume-ol＠bofh.ca 05 Apr '12

05 Apr '12

Full_Name: Brandon Hume Version: -OPENLDAP_REL_ENG_2_4-0e03b13 OS: Redhat AS6 URL: http://den.bofh.ca/~hume/ldap_missing_results.tar.gz Submission from: (NULL) (2610:170:2c00:7:224:1ff:fed4:b4ff) Firstly, using RE24 built with the following ./configure: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ./configure --prefix=/appl/ldap \ --libexecdir=/appl/ldap/sbin --localstatedir=/var/run --datadir=/appl/ldap/data \ --sysconfdir=/appl/ldap/etc --mandir=/appl/ldap/man --with-subdir=no \ --disable-rlookups --with-tls=openssl \ --enable-slapd --enable-crypt --with-cyrus-sasl=no --enable-debug \ --enable-dynamic --enable-modules \ --enable-backends=mod --enable-overlays=mod --enable-sql=no \ --enable-perl=no --enable-ndb=no --enable-shell=no Paired with BerkeleyDB built with the following: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ../dist/configure --prefix=/appl/ldap DIT has 131207 entries. Search results will come and go as you shorten the search base. For example, when searching for "maillocaladdress=vbroken(a)dal.ca", which has the full DN of "cn=broken129251,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA", the following will occur: Searching with base=cn=dal,cn=Mailmaps,cn=services,dc=dal,dc=ca: Found. Searching with base=cn=Mailmaps,cn=services,dc=dal,dc=ca: NOT found. Searching with base=cn=services,dc=dal,dc=ca: NOT found. Searching with base=dc=dal,dc=ca: Found. cn=dal has 123312 children, which is very high. However, breaking the branch up into subcontainers, none of which had more than 10k entries, did not cure the problem. With olcLogLevel=any, the following is notable: Successful search: Apr 5 21:09:01 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=dal,cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011AND Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011OR Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_search_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: entry_decode: "" Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= entry_decode() Apr 5 21:09:03 kil-ds-3 slapd[17628]: => test_filter Unsuccessful search: Apr 5 21:10:34 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011AND Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011OR Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_search_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: hdb_search: no candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: conn=1001 op=1 p=3 Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: err=0 matched="" text="" Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_response: msgid=2 tag=101 err=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= I'm including a link to a tarball that contains: - My (simplified) config, that still produces the problem. I'm managed to remove locally-created schemas. - My test LDIF, containing the entries that can produce the problem. They've been anonymized, but it doesn't affect the problem. A server loaded with the above config and this DIT will be consistently unable to find the "maillocaladdress=vbroken(a)dal.ca" entry at cn=services,dc=dal,dc=ca search base. - My test script, test_ldap.sh, that searches for the above entry at the levels in between it and the base naming context (dc=dal,dc=ca). I can provide more if needed, up to and including the compiled binaries.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by quanah＠zimbra.com 05 Apr '12

05 Apr '12

--On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> 2. add an equality matching rule. >>> >>> My approach with config attrs has been to skip the equality rule for >>> single-valued attrs. Since they are single-valued, there's obviously >>> no need >>> to allow for comparing multiple values. > > Users always find more ways to use a feature than its creator imagined. > > I wish people would give attributes all matching rules they can. > Equality, ordering, substring. Except when: > - flexibility would be a misfeature, e.g. SUBSTR for userPassword, > - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. I agree. I think defining matching rules where possible is extremely useful. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by h.b.furuseth＠usit.uio.no 05 Apr '12

05 Apr '12

On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >hyc(a)symas.com wrote: >>michael(a)stroeder.com wrote: >>> 2. add an equality matching rule. >> >> My approach with config attrs has been to skip the equality rule for >> single-valued attrs. Since they are single-valued, there's obviously >> no need >> to allow for comparing multiple values. Users always find more ways to use a feature than its creator imagined. I wish people would give attributes all matching rules they can. Equality, ordering, substring. Except when: - flexibility would be a misfeature, e.g. SUBSTR for userPassword, - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. > They are not searchable either then. Does it add too much overhead to > add an > equality matching rule? > > Personally I currently can't imagine a use-case for searching an > entry using > attribute olcAuditlogFile but one never knows... "Which database gets logged to file /whatever"? Also, as you mention, an EQUALITY rule allows sanity checking, like an atomic "verify old value and then change to new value" operation. -- Hallvard

1 0

Re: (ITS#7227) Problem to add new entry
by quanah＠zimbra.com 05 Apr '12

05 Apr '12

--On Thursday, April 05, 2012 12:38 PM +0000 rai.abhishek(a)yahoo.com wrote: > Full_Name: Abhishek Rai > Version: 3 > OS: Windows Server 2008 R2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.46.55.29) THe ITS system is for reporting bugs, not asking usage questions. I suggest you subscribe to the openldap-technical(a)openldap.org list, and ask your usage questions there. This ITS will be closed. --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#7230) back-mdb: slapadd fails when not run in quickmode
by quanah＠OpenLDAP.org 05 Apr '12

05 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/4/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Running slapadd without quickmode quickly results in failure: zimbra@zre-ldap001:~$ time /opt/zimbra/openldap/sbin/slapadd -b "" -l /tmp/ldap.bak -F /opt/zimbra/data/ldap/config * 0.63% eta 01h08m elapsed 26s spd 1.1 M/s slapadd: ./../../../libraries/libmdb/mdb.c:3459: mdb_page_search: Assertion `root > 1' failed. Aborted

1 0

(ITS#7229) back-mdb: unable to load large databases
by quanah＠OpenLDAP.org 05 Apr '12

05 Apr '12

Full_Name: Quanah Gibson-Mount Version: RE24 4/4/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) When loading a large database via slapadd -q, back-mdb fails: zimbra@zre-ldap001:~$ time /opt/zimbra/openldap/sbin/slapadd -q -b "" -l /tmp/ldap.bak -F /opt/zimbra/data/ldap/config -## 13.49% eta 51m39s elapsed 08m03s spd 1.2 M/s 4f7dee09 mdb_id2entry_put: mdb_put failed: No space left on device(28) "uid=yyyyyyy,ou=people,dc=xxxxxx,dc=com" 4f7dee09 => mdb_tool_entry_put: id2entry_add failed: err=80 4f7dee09 => mdb_tool_entry_put: txn_aborted! Internal error (80) slapadd: could not add entry dn="uid=yyyyyy,ou=people,dc=xxxxx,dc=com" (line=17539364): txn_aborted! Internal error (80) .## 13.50% eta 51m39s elapsed 08m03s spd 1.5 M/s Closing DB...Error, entries missing! entry 20241: uid=zzzzzz,ou=people,dc=xxx,dc=com entry 83243: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 85232: uid=zzzzzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 93399: uid=zzzzzzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 113549: uid=zzzzzzzzz,ou=people,dc=xxxxx,dc=com entry 138089: uid=zzzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 140319: uid=zzzzzzzz,ou=people,dc=xxxxx,dc=com entry 152722: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 154989: uid=zzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 164912: uid=zzzzzzzzz,ou=people,dc=xxxxx,dc=net entry 166738: uid=zzzzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 167049: uid=zzzzzzzzzzz,ou=people,dc=xxxxxxxxxx,dc=com entry 177778: uid=zzzzzzzz,ou=people,dc=xxxxxx,dc=com entry 195907: uid=zzz,ou=people,dc=xxxxxx,dc=com (etc)

1 0

RE: (ITS#7228) Authentication Problem When Using PPolicy and Chaining
by Jong.Limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

I have built and tested 2.4.30, and it works as expected. I now get invalid credentials when I hit the consumer with an incorrect password. However, I believe that the script should still be modified to check the return code from the first ldapsearch in order to prevent something like this developing in the future. You can close this ITS. Thanks. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Limb, Jong (VDSS) Sent: Thursday, April 05, 2012 11:31 AM To: 'Howard Chu' Cc: openldap-its(a)OpenLDAP.org Subject: RE: (ITS#7228) Authentication Problem When Using PPolicy and Chaining I believe the test is incorrect. Near the bottom of the script, there is this section of code: $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` echo "jkl 13" if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi The first LDAPSEARCH should have its return code checked, and for an incorrect password, it should be 49. If the script is modified to check for 49 and fail otherwise, it will fail. Unfortunately, I am not in a position to use a newer version of OpenLDAP, but I will build it and run the tests to see if the problem exists there as well. I will report back with my findings. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, April 05, 2012 10:17 AM To: Limb, Jong (VDSS) Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- 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#7228) Authentication Problem When Using PPolicy and Chaining
by Jong.Limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

I believe the test is incorrect. Near the bottom of the script, there is this section of code: $LDAPSEARCH -H $URI2 -D "$USER" -w wrongpw >$SEARCHOUT 2>&1 $LDAPSEARCH -H $URI1 -D "$MANAGERDN" -w $PASSWD -b "$USER" \* \+ >> $SEARCHOUT 2>&1 COUNT=`grep "pwdFailureTime" $SEARCHOUT | wc -l` echo "jkl 13" if test $COUNT != 1 ; then echo "Policy state forwarding failed" test $KILLSERVERS != no && kill -HUP $KILLPIDS exit 1 fi The first LDAPSEARCH should have its return code checked, and for an incorrect password, it should be 49. If the script is modified to check for 49 and fail otherwise, it will fail. Unfortunately, I am not in a position to use a newer version of OpenLDAP, but I will build it and run the tests to see if the problem exists there as well. I will report back with my findings. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, April 05, 2012 10:17 AM To: Limb, Jong (VDSS) Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- 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#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000601060706020001090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Michael Str=F6der wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> 2. add an equality matching rule. >>> >>> My approach with config attrs has been to skip the equality rule for >>> single-valued attrs. Since they are single-valued, there's obviously = no need >>> to allow for comparing multiple values. >> >> They are not searchable either then. Does it add too much overhead to = add an >> equality matching rule? >> >> Personally I currently can't imagine a use-case for searching an entry= using >> attribute olcAuditlogFile but one never knows... >=20 > True, depends on the syntax and whether it requires a normalizer, and I= =20 > couldn't think of a use-case for searching either. Overall if there's n= o=20 > obvious use for it, I choose to omit it. Hmm, I come to the opposite conclusion. Why? When generating the diff between old and new entry my web2ldap looks whet= her an EQUALITY matching rule is defined for a certain attribute type and it'= s also published in attributes matchingRules in the subschema subentry. In = that case old attribute values are explicitly deleted (not just the whole attr= ibute). This is done to provoke collisions on the server's side during processing= the modify request to be more on the safe side in case different users alter = the same entries. This has also been discussed some time ago on the OpenLDAP = lists. (Additionally the assertion control with appopriate filter is sent along with the modify request for that purpose. But not if the server is OpenLDAP because of ITS#6916 which renders assertion control completely u= nusable.) =3D> If there's no objection against an equality rule (e.g. because of overhead) *every* attribute type which uses a LDAP syntax for which an equality rule exists should have one. Ciao, Michael. --------------ms000601060706020001090605 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTE0MjAyOVowIwYJKoZIhvcNAQkEMRYE FFzAsG3+dnjGgCIuHe9WJ6JWCSCgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA2W9KZ+2wjxLM0svAhmhXXcOJGksGQI+N0u4ta2/ddnRZwYmlX2ff0OeC0XRom5x6dmIV SzO9Hiw2syv7FRq7dIEI+lz0XWC1OttnG5QQTxyLR52EW/0kXt+eP+HEIcNqMbeZAC8JPKmr XEnpOC1ZwhxZYx2Gq72V379rkohDiW8hWuJdnqKcxFnlpzYd/XtmOhhnOLhOUKF7mYiqnTuz dhPETknUf+0rLjGCBMXVuZ94kWbU3Ia4gxtwVbRfruhadNBO61Dx3zccWqIdmBjzdNkFmIpo i4pjcwfRzgyagZxcazpOihioFxEu8bA3PQN8PUgAlvMdbU9RHrmwICrUPwAAAAAAAA== --------------ms000601060706020001090605--

1 0

Re: (ITS#7228) Authentication Problem When Using PPolicy and Chaining
by hyc＠symas.com 05 Apr '12

05 Apr '12

jong.limb(a)dss.virginia.gov wrote: > Full_Name: Jong K. Limb > Version: 2.4.23 > OS: RHEL 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (166.67.66.5) > > > I have the following setup: > - Provider LDAP server used only by those applications that change passwords > - Consumer LDAP servers used by all applications that want to authenticate > users > - The provider and consumers have password policy configured so that the > accounts lock after 3 failed attempts > - In order to maintain synchronization of failed login attempts across all > consumers, I also enabled chaining from the consumers to the master > > If an attempt is made to authenticate against the consumer with an invalid > password (for example, using ldapsearch), the pwdFailureTime attribute is > added/updated on the provider and eventually synced to the consumer, but the > operation succeeds when it should not have. > > If I remove the password policy overlay (leaving all other configuration the > same) and run ldapsearch with an invalid password against a consumer, the > operation will fail with invalid credentials as it should. > > I have done a little debugging, and it looks like the response that gets > returned to the client is the response to the modify operation that the consumer > makes to the provider to add/update the pwdFailureTime attribute, and not the > response to the bind operation. The modify operation is successful here, so the > client continues on with the search or other operation. Unable to confirm this. Note that this is tested explicitly in test022 of the test suite, and no such behavior occurs there. You're running a pretty old release, perhaps you should update. Regardless, unless you can provide more details to reproduce this situation, this ITS will be closed. -- -- 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#7228) Authentication Problem When Using PPolicy and Chaining
by jong.limb＠dss.virginia.gov 05 Apr '12

05 Apr '12

Full_Name: Jong K. Limb Version: 2.4.23 OS: RHEL 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (166.67.66.5) I have the following setup: - Provider LDAP server used only by those applications that change passwords - Consumer LDAP servers used by all applications that want to authenticate users - The provider and consumers have password policy configured so that the accounts lock after 3 failed attempts - In order to maintain synchronization of failed login attempts across all consumers, I also enabled chaining from the consumers to the master If an attempt is made to authenticate against the consumer with an invalid password (for example, using ldapsearch), the pwdFailureTime attribute is added/updated on the provider and eventually synced to the consumer, but the operation succeeds when it should not have. If I remove the password policy overlay (leaving all other configuration the same) and run ldapsearch with an invalid password against a consumer, the operation will fail with invalid credentials as it should. I have done a little debugging, and it looks like the response that gets returned to the client is the response to the modify operation that the consumer makes to the provider to add/update the pwdFailureTime attribute, and not the response to the bind operation. The modify operation is successful here, so the client continues on with the search or other operation.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 05 Apr '12

05 Apr '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> 2. add an equality matching rule. >> >> My approach with config attrs has been to skip the equality rule for >> single-valued attrs. Since they are single-valued, there's obviously no need >> to allow for comparing multiple values. > > They are not searchable either then. Does it add too much overhead to add an > equality matching rule? > > Personally I currently can't imagine a use-case for searching an entry using > attribute olcAuditlogFile but one never knows... True, depends on the syntax and whether it requires a normalizer, and I couldn't think of a use-case for searching either. Overall if there's no obvious use for it, I choose to omit it. -- -- 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#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 05 Apr '12

05 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030905050806080408090400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> 2. add an equality matching rule. >=20 > My approach with config attrs has been to skip the equality rule for=20 > single-valued attrs. Since they are single-valued, there's obviously no= need=20 > to allow for comparing multiple values. They are not searchable either then. Does it add too much overhead to add= an equality matching rule? Personally I currently can't imagine a use-case for searching an entry us= ing attribute olcAuditlogFile but one never knows... Ciao, Michael. --------------ms030905050806080408090400 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNTEzMTE1MlowIwYJKoZIhvcNAQkEMRYE FKSAdbqqyHLXa1gjxrZTVmU3u7tyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA19nxcp9VtMesBkigrXCwA3bb5d6mDGvRHxlHY98mpA/uVI5tjiEgya9H2Eby+z34Ws7o UtaSyQ4WbDT2SmtuGt7SKd9+DqpBRQnsOu52rXo31vBoQ+RCASOfix72v8geh3Cn6Ft5ZDX4 lZ2qYc8UmEYiY04nLkW4cIvCChd5eREiPBECxHhcrAXt/Rv4JNUhqOsQ90uFZvy6d90ZMHMZ kRtBF7O36gV9Wu/K6Oa3yWrOIdDyXeWIpIeIh2UrU3ZPDjeiRvtB0iHgmbhnOLEeWMMtA9bU XmQdTqL977WN4Ga3xY952sNExcEmoHMcvgqFeFoLvp0hfrCEbGFTVmmH0wAAAAAAAA== --------------ms030905050806080408090400--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs