- openldap-bugs - openldap.org

Re: (ITS#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

ando(a)sys-net.it wrote: > Malformed perl can cause a double free in str2entry2(). Steps to reproduce: > from back-perl's "search" routine, generate a malformed entry that begins with > "dn : ..." ends with "...\n\t". Fixed in HEAD/re23; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Malformed perl can cause a double free in str2entry2(). Steps to reproduce: from back-perl's "search" routine, generate a malformed entry that begins with "dn : ..." ends with "...\n\t". Backtrace (from HEAD; similar in re23) follows: (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003d57a5 in raise () from /lib/tls/libc.so.6 #2 0x003d7209 in abort () from /lib/tls/libc.so.6 #3 0x0040971a in __libc_message () from /lib/tls/libc.so.6 #4 0x0040ffbf in _int_free () from /lib/tls/libc.so.6 #5 0x0041033a in free () from /lib/tls/libc.so.6 #6 0x08226022 in ber_memfree_x (p=0x84e5960, ctx=0x0) at memory.c:149 #7 0x080a11fe in ch_free (ptr=0x84e5960) at ch_malloc.c:139 #8 0x0808d12a in str2entry2 (s=0x0, checkvals=1) at entry.c:374 #9 0x0808c1a0 in str2entry (s=0x84e5838 "dn") at entry.c:100 #10 0x0813c7c8 in perl_back_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:78 #11 0x080846f4 in fe_op_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:374 #12 0x08084078 in do_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:217 #13 0x08081083 in connection_operation (ctx=0xb78f02a4, arg_v=0x84e50f8) at connection.c:1129 #14 0x08081550 in connection_read_thread (ctx=0xb78f02a4, argv=0x9) at connection.c:1257 #15 0x081f38d4 in ldap_int_thread_pool_wrapper (xpool=0x8364c08) at tpool.c:704 #16 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #17 0x00475ffe in clone () from /lib/tls/libc.so.6

1 0

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Xavier Beaudouin wrote: >> Unless you can prove that back-perl LDIF parser doesn't work with >> decently >> formatted LDIF, I'll consider this ITS closed. > > It *is* buggy proove me the contrary and be not so arrogant. OK, I'll be less "arrogant". I've tested back-perl with your script corrected, and it works exactly as expected both with OpenLDAP 2.3 and with OpenLDAP 2.4. What are corrections? 1) <attr>: <value> 2) eliminate nonsensical "\t" at end of each line. What is really offending is the space between "attr" and ":" and the last "\t", while the other "\t" seem to be tolerated (I suggest to fix str2entry() in order to detect this malformation as well). It took me 5 minutes to rebuild with back-perl and find the error, and it's the first time in my life that I program perl. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: Antwort: Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Michael.Heep(a)o2.com wrote: > Hello Pierangelo, > >> ando(a)sys-net.it wrote: >> >> The above had nothing to do with your problem. Your problem is related >> to the fact that you intermixed overlay and database configuration >> statements, so the idletimeout statement after the accesslog overlay >> instantiation was causing invalid memory write (beyond the private data >> of the accesslog overlay instead of in the private data of the bdb >> database) resulting in heap corruption. > > You meant the limits option, not the idletimeout, right? Because when I > remove it slapd starts and runs properly. > But now I'm quite lost here. With that statement I intended to disable the > default limits for all users below ou=CNO-LDC when viewing the accesslog > (as it's bound to grow beyond the 500 entries sooner or later). The > manpage lists limits as a general database option, so I assumed placing it > at the end of the accesslog db options would impose these limits on it. > Now where would be the proper placement to achive that? > Under 2.3.33 in my test environment with an accesslog > 500 entries and > the limits directive at just this place in the conf everything worked as > expected. The limits was just a false track. It was idlcachesize to trigger the dangling memory access, but the root cause is the config statement ordering which triggered something much more subtle: basically, if database statements follow overlay instantiation, slapd is fooled into writing to the database (in this case back-bdb) private structure using a pointer to the overlay's (in this case accesslog) structure. This is now fixed in HEAD (thanks to Howard), but backporting to re23 may not be trivial, so please stick with strict ordering of configure statements. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Antwort: Re: (ITS#4848) Another slapd startup segfault
by Michael.Heep＠o2.com 26 Feb '07

26 Feb '07

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002D0ED3C125728E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gUGllcmFuZ2VsbywNCg0KPiBhbmRvQHN5cy1uZXQuaXQgd3JvdGU6DQo+DQo+IFRoZSBh Ym92ZSBoYWQgbm90aGluZyB0byBkbyB3aXRoIHlvdXIgcHJvYmxlbS4gIFlvdXIgcHJvYmxlbSBp cyByZWxhdGVkDQo+IHRvIHRoZSBmYWN0IHRoYXQgeW91IGludGVybWl4ZWQgb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbg0KPiBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQg c3RhdGVtZW50IGFmdGVyIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheQ0KPiBpbnN0YW50aWF0aW9uIHdh cyBjYXVzaW5nIGludmFsaWQgbWVtb3J5IHdyaXRlIChiZXlvbmQgdGhlIHByaXZhdGUgZGF0YQ0K PiBvZiB0aGUgYWNjZXNzbG9nIG92ZXJsYXkgaW5zdGVhZCBvZiBpbiB0aGUgcHJpdmF0ZSBkYXRh IG9mIHRoZSBiZGINCj4gZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNvcnJ1cHRpb24uDQoN CllvdSBtZWFudCB0aGUgbGltaXRzIG9wdGlvbiwgbm90IHRoZSBpZGxldGltZW91dCwgcmlnaHQ/ IEJlY2F1c2Ugd2hlbiBJIA0KcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS4NCkJ1dCBub3cgSSdtIHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0IHN0YXRlbWVudCBJIGlu dGVuZGVkIHRvIGRpc2FibGUgdGhlIA0KZGVmYXVsdCBsaW1pdHMgZm9yIGFsbCB1c2VycyBiZWxv dyBvdT1DTk8tTERDIHdoZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIA0KKGFzIGl0J3MgYm91bmQg dG8gZ3JvdyBiZXlvbmQgdGhlIDUwMCBlbnRyaWVzIHNvb25lciBvciBsYXRlcikuIFRoZSANCm1h bnBhZ2UgbGlzdHMgbGltaXRzIGFzIGEgZ2VuZXJhbCBkYXRhYmFzZSBvcHRpb24sIHNvIEkgYXNz dW1lZCBwbGFjaW5nIGl0IA0KYXQgdGhlIGVuZCBvZiB0aGUgYWNjZXNzbG9nIGRiIG9wdGlvbnMg d291bGQgaW1wb3NlIHRoZXNlIGxpbWl0cyBvbiBpdC4gDQpOb3cgd2hlcmUgd291bGQgYmUgdGhl IHByb3BlciBwbGFjZW1lbnQgdG8gYWNoaXZlIHRoYXQ/DQpVbmRlciAyLjMuMzMgaW4gbXkgdGVz dCBlbnZpcm9ubWVudCB3aXRoIGFuIGFjY2Vzc2xvZyA+IDUwMCBlbnRyaWVzIGFuZCANCnRoZSBs aW1pdHMgZGlyZWN0aXZlIGF0IGp1c3QgdGhpcyBwbGFjZSBpbiB0aGUgY29uZiBldmVyeXRoaW5n IHdvcmtlZCBhcyANCmV4cGVjdGVkLg0KDQpXaXRoIGtpbmQgcmVnYXJkcy4NCk1pY2hhZWwgSGVl cA0KVE8tQ05TLUxEQw0KbzIgKEdlcm1hbnkpIEdtYkggJiBDby5PSEcNCkJlcm5lciBTdHJhw59l IDc2LCBELTYwNDM3IEZyYW5rZnVydCBhLiBNLg0KVGVsICs0OSgwKTY5LTUwMDItNjE1OA0KTW9i aWwgKzQ5KDApMTc2LTIwNjMxMzcyDQpGYXggKzQ5KDApNjktNTAwMi02MTY5DQptaWNoYWVsLmhl ZXBAbzIuY29tDQoNCm8yIChHZXJtYW55KSBHbWJIICYgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNo bGUtUmluZyAyMy0yNSDigKIgODA5OTIgTcO8bmNoZW4g4oCiIA0KRGV1dHNjaGxhbmQg4oCiIHd3 dy5vMi5jb20vZGUNCg0KVXN0Li1JZC4tTnIuIERFIDgxMSA4ODkgNjM4LiBBbXRzZ2VyaWNodCBN w7xuY2hlbiBIUkEgNzAzNDMuIA0KR2VzZWxsc2NoYWZ0ZXI6IG8yIChHZXJtYW55KSBNYW5hZ2Vt ZW50IEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiANCjEwOTA2MSB1bmQNCm8yIChHZXJt YW55KSBWZXJ3YWx0dW5ncyBHbWJILiBBbXRzZ2VyaWNodCBNw7xuY2hlbiBIUkIgMTIxMzg5LCBi ZWlkZSANCmViZW5kYS4NCkdlc2Now6RmdHNmw7xocmVyIGJlaWRlciBHZXNlbGxzY2hhZnRlcjog RHIuIGguYy4gUnVkb2xmIEdyw7ZnZXIsIA0KVm9yc2l0emVuZGVyLiBEaWV0cmljaCBCZWVzZS4g QW5kcsOpIEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIA0KS2FybC1XaWxoZWxt IFJvaHJzZW4uIEx1dHogU2Now7xsZXIuDQoNCg== --=_alternative 002D0ED3C125728E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIFBpZXJhbmdlbG8sPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGFuZG9A c3lzLW5ldC5pdCB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg VGhlIGFib3ZlIGhhZCBub3RoaW5nIHRvIGRvIHdpdGgNCnlvdXIgcHJvYmxlbS4gJm5ic3A7WW91 ciBwcm9ibGVtIGlzIHJlbGF0ZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZndDsgdG8gdGhlIGZhY3QgdGhhdCB5b3UgaW50ZXJtaXhlZA0Kb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQNCnN0YXRlbWVudCBh ZnRlciB0aGUgYWNjZXNzbG9nIG92ZXJsYXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgaW5zdGFudGlhdGlvbiB3YXMgY2F1c2luZyBpbnZhbGlkDQptZW1v cnkgd3JpdGUgKGJleW9uZCB0aGUgcHJpdmF0ZSBkYXRhPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IG9mIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheSBpbnN0ZWFk DQpvZiBpbiB0aGUgcHJpdmF0ZSBkYXRhIG9mIHRoZSBiZGI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNv cnJ1cHRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Zb3UgbWVhbnQgdGhlIGxpbWl0cyBvcHRpb24sIG5vdCB0aGUNCmlkbGV0aW1lb3V0LCByaWdo dD8gQmVjYXVzZSB3aGVuIEkgcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBub3cgSSdt IHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0DQpzdGF0ZW1lbnQgSSBpbnRlbmRlZCB0byBkaXNh YmxlIHRoZSBkZWZhdWx0IGxpbWl0cyBmb3IgYWxsIHVzZXJzIGJlbG93DQpvdT1DTk8tTERDIHdo ZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIChhcyBpdCdzIGJvdW5kIHRvIGdyb3cgYmV5b25kIHRo ZQ0KNTAwIGVudHJpZXMgc29vbmVyIG9yIGxhdGVyKS4gVGhlIG1hbnBhZ2UgbGlzdHMgbGltaXRz IGFzIGEgZ2VuZXJhbCBkYXRhYmFzZQ0Kb3B0aW9uLCBzbyBJIGFzc3VtZWQgcGxhY2luZyBpdCBh dCB0aGUgZW5kIG9mIHRoZSBhY2Nlc3Nsb2cgZGIgb3B0aW9ucw0Kd291bGQgaW1wb3NlIHRoZXNl IGxpbWl0cyBvbiBpdC4gTm93IHdoZXJlIHdvdWxkIGJlIHRoZSBwcm9wZXIgcGxhY2VtZW50DQp0 byBhY2hpdmUgdGhhdD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlVuZGVyIDIuMy4zMyBpbiBteSB0ZXN0IGVudmlyb25tZW50DQp3aXRoIGFuIGFjY2Vzc2xvZyAm Z3Q7IDUwMCBlbnRyaWVzIGFuZCB0aGUgbGltaXRzIGRpcmVjdGl2ZSBhdCBqdXN0IHRoaXMNCnBs YWNlIGluIHRoZSBjb25mIGV2ZXJ5dGhpbmcgd29ya2VkIGFzIGV4cGVjdGVkLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2l0aCBraW5kIHJlZ2FyZHMu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NaWNoYWVsIEhlZXA8 YnI+DQpUTy1DTlMtTERDPGJyPg0KbzIgKEdlcm1hbnkpIEdtYkggJmFtcDsgQ28uT0hHPGJyPg0K QmVybmVyIFN0cmHDn2UgNzYsIEQtNjA0MzcgRnJhbmtmdXJ0IGEuIE0uPGJyPg0KVGVsICs0OSgw KTY5LTUwMDItNjE1ODxicj4NCk1vYmlsICs0OSgwKTE3Ni0yMDYzMTM3Mjxicj4NCkZheCArNDko MCk2OS01MDAyLTYxNjk8YnI+DQptaWNoYWVsLmhlZXBAbzIuY29tPGJyPg0KPGJyPg0KbzIgKEdl cm1hbnkpIEdtYkggJmFtcDsgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNobGUtUmluZyAyMy0yNSDi gKIgODA5OTIgTcO8bmNoZW4NCuKAoiBEZXV0c2NobGFuZCDigKIgd3d3Lm8yLmNvbS9kZTxicj4N Cjxicj4NClVzdC4tSWQuLU5yLiBERSA4MTEgODg5IDYzOC4gQW10c2dlcmljaHQgTcO8bmNoZW4g SFJBIDcwMzQzLiBHZXNlbGxzY2hhZnRlcjoNCm8yIChHZXJtYW55KSBNYW5hZ2VtZW50IEdtYkgu IEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMDkwNjEgdW5kPGJyPg0KbzIgKEdlcm1hbnkpIFZl cndhbHR1bmdzIEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMjEzODksIGJlaWRlIGVi ZW5kYS48YnI+DQpHZXNjaMOkZnRzZsO8aHJlciBiZWlkZXIgR2VzZWxsc2NoYWZ0ZXI6IERyLiBo LmMuIFJ1ZG9sZiBHcsO2Z2VyLCBWb3JzaXR6ZW5kZXIuDQpEaWV0cmljaCBCZWVzZS4gQW5kcsOp IEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIEthcmwtV2lsaGVsbSBSb2hyc2Vu Lg0KTHV0eiBTY2jDvGxlci48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 002D0ED3C125728E_=--

1 0

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 25 Feb '07

25 Feb '07

--Apple-Mail-19-845722018 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Le 25 f=E9vr. 07 =E0 17:40, Pierangelo Masarati a =E9crit : >> [...] >> Note that this "simpified" back-perl backend what working very well >> on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to >> show some big changes in this part... > > The question is: have you ever read RFC2849 (LDIF specs)? I know the > answer: NO. The point is: you're developing code (back-perl =20 > scripting is > considered code development) and you don't even care to find out =20 > what the > specs say for a minimal detail like code interoperability! Have =20 > you even > looked at an LDIF example? How can you pretend to guess, by trial and > error, when your LDIF formatting will be finally accepted by a =20 > (decent) > LDIF parser? The syntax (made easy) is clear: > > <attribute name> (no space) : (space) <value> > that's it. Apparently you tried all combinations __except__ the =20 > one that > works, but looking, e.g., to the output of ldapsearch would have =20 > put you > in the right direction even without reading RFC 2849. I am sorry *but* I have tried this combination : We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass: top objectClass: kazarPerson uid: kiwi(a)oav.net cn: Nom Prenom description: Sample description uidNumber: 10 gidNumber: 10 userPassword: Password homeDirectory: /home/test mailQuota: 50 CouriermailQuota: 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08539150 ptr=3D0x08539150 end=3D0x08539155 len=3D5 0000: 02 01 03 42 00 ...B. conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL > Unless you can prove that back-perl LDIF parser doesn't work with =20 > decently > formatted LDIF, I'll consider this ITS closed. It *is* buggy proove me the contrary and be not so arrogant. /Xavier= --Apple-Mail-19-845722018 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxODAwNTBaMCMGCSqGSIb3DQEJBDEWBBQWG+Gb4d19rwPE aRI6PmdcJ9AsYTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAHi4NB/J3cucstsrftaOUUAQMNtT 3KEWDBGoYOmtTTDAxa48+6arC2V5DOc6Wob9M4qZOeQ3PmOYId+aq+ItQLQPtuAo7TsqtdjgMCKj JXR/k0iVobcJF1JNYEVWazm69fOtonEBQSRCwXS02NlO+amfDSLNfBuICfS9w78xDNnnIk3QDSyf GJX2M1muvJuZYCUNkSiHKmmxb9zXW4Mfp61mih1JOfrjDdwg2ZGX8NKgkuOFKlDNp/8HjAKsPAYN yA6N1zwdT4s8XjLRJIW2jZL2Xom0lYRVYPU3LmV1zb5YWXMrDElOY5YyPiTUXP0l9yhMipCIEKH0 /6On1ERVnRgAAAAAAAA= --Apple-Mail-19-845722018--

1 0

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 25 Feb '07

25 Feb '07

>> If the above is the way your LDIF is formatted, then back-perl >> (actually, str2entry, a helper function in the core of slapd) is >> working >> as intended. There's supposed to be no space between attribute >> names or >> "dn" and the colon ":". Please fix you PERL and report. > > I did several tests : one too less, I fear. > > - No space between attribute and data : ... > > Still getting no results. > > But there is an interressing error : "ldif_parse_line: missing ':' > after" > > So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't > seems to be bad. ... > Note that this "simpified" back-perl backend what working very well > on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to > show some big changes in this part... The question is: have you ever read RFC2849 (LDIF specs)? I know the answer: NO. The point is: you're developing code (back-perl scripting is considered code development) and you don't even care to find out what the specs say for a minimal detail like code interoperability! Have you even looked at an LDIF example? How can you pretend to guess, by trial and error, when your LDIF formatting will be finally accepted by a (decent) LDIF parser? The syntax (made easy) is clear: <attribute name> (no space) : (space) <value> that's it. Apparently you tried all combinations __except__ the one that works, but looking, e.g., to the output of ldapsearch would have put you in the right direction even without reading RFC 2849. Unless you can prove that back-perl LDIF parser doesn't work with decently formatted LDIF, I'll consider this ITS closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 25 Feb '07

25 Feb '07

--Apple-Mail-17-824115749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, Le 21 f=E9vr. 07 =E0 23:02, Pierangelo Masarati a =E9crit : > kiwi(a)oav.net wrote: >> Full_Name: Xavier Beaudouin >> Version: 2.3.33 >> OS: FreeBSD 6.2 >> URL: http://www.oav.net/tmp/openldap/ >> Submission from: (NULL) (82.225.248.92) > >> Sending -> dn : uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet >> objectClass : top >> objectClass : kazarPerson >> uid : kiwi(a)oav.net >> cn : Nom Prenom >> description : Sample description >> uidNumber : 10 >> gidNumber : 10 >> userPassword : Password >> homeDirectory : /home/test >> mailQuota : 50 >> CouriermailQuota : 50S >> >> str2entry: entry -1 has no dn >> str2entry(dn) failed >> send_ldap_result: err=3D0 matched=3D"" text=3D"" >> connection_get(8) > > If the above is the way your LDIF is formatted, then back-perl > (actually, str2entry, a helper function in the core of slapd) is =20 > working > as intended. There's supposed to be no space between attribute =20 > names or > "dn" and the colon ":". Please fix you PERL and report. I did several tests : - No space between attribute and data : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn:uid=3Dkiwi@oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass:top objectClass:kazarPerson uid:kiwi@oav.net cn:Nom Prenom description:Sample description uidNumber:10 gidNumber:10 userPassword:Password homeDirectory:/home/test mailQuota:50 CouriermailQuota:50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253a00 ptr=3D0x08253a00 end=3D0x08253a05 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed - No space between attribute 'dn' and ':' : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass : top objectClass : kazarPerson uid : kiwi(a)oav.net cn : Nom Prenom description : Sample description uidNumber : 10 gidNumber : 10 userPassword : Password homeDirectory : /home/test mailQuota : 50 CouriermailQuota : 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(objectClass): AttributeDescription =20 contains inappropriate characters str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253830 ptr=3D0x08253830 end=3D0x08253835 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed Still getting no results. But there is an interressing error : "ldif_parse_line: missing ':' =20 after" So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't =20 seems to be bad. What are the changes in str2entry() that may change ? Here is the kind of string I sent to : my $entry =3D "dn : uid=3D$mailaddr,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet\= n\t". "objectClass : top\n\t". "objectClass : kazarPerson\n\t"; $entry .=3D "uid : $mailaddr\n\t"; $entry .=3D "cn : Nom Prenom\n\t"; $entry .=3D "description : Sample description\n\t"; $entry .=3D "uidNumber : 10\n\t"; $entry .=3D "gidNumber : 10\n\t"; $entry .=3D "userPassword : Password\n\t"; $entry .=3D "homeDirectory : /home/test\n\t"; $entry .=3D "mailQuota : 50\n\t"; $entry .=3D "CouriermailQuota : 50S\n\t"; print STDERR "Sending -> $entry\n"; push @match_entries, $entry; return(0, @match_entries); Note that this "simpified" back-perl backend what working very well =20 on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to =20 show some big changes in this part... THanks, /Xavier= --Apple-Mail-17-824115749 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxMjAwNDRaMCMGCSqGSIb3DQEJBDEWBBTEQXOv2cw7Da2M Gxgl5MPnGXmD1zCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAD3RgUWLs5Si0VF628WxzJOIIzRd 3DyKLsc54IrVo60ReQxWJOS1GKH6T+r5kfbGnyhUXIwtMBpBF8Pvr6z/TlQIF+4XJKvVnW2YD3ML Rw2jHQjl8Dm73/Md+ViJ3E6PsQwkuRsONYl93CkqsET8UL1AFg9wc2fjI9vDT9SKgUzppK4nY7py aKJuTm3avopBaZyOQNrcr4LOrdWDQM/xh/n1u8VX5u3CanOum2sHyHqbcxTuHj2p3yKaxpigFiO2 L0fMc4ZY1baLuPDXHj8mbY36edl6TqxoFilGz5E9a9rVgSA5tMciRtZge2R3ZjxoaKRvCy7wNBMx iQKGpG/tL24AAAAAAAA= --Apple-Mail-17-824115749--

1 0

Re: (ITS#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

hyc(a)symas.com wrote: > erici(a)motown.cc.utexas.edu wrote: >> Full_Name: Eric Irrgang >> Version: 2.3.34 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.83.217.14) >> >> >> Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared >> memory segment for the db cache, the automatic bdb database recovery fails after >> a reboot (because the shared memory segment doesn't exist yet). > > In fact there is no automatic DB recovery happening here, this is a regular > Open that fails because the (shared memory) environment is missing. We don't > detect that recovery is needed because presumably slapd exited cleanly at the > previous shutdown. > > I guess we'll have to add a check for this condition (e.g., if ENV open fails > and we're using shared memory, recover and try again). This is now fixed in HEAD, back-bdb/init.c 1.272 -- -- Howard Chu Chief Architect, 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#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.34 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared > memory segment for the db cache, the automatic bdb database recovery fails after > a reboot (because the shared memory segment doesn't exist yet). In fact there is no automatic DB recovery happening here, this is a regular Open that fails because the (shared memory) environment is missing. We don't detect that recovery is needed because presumably slapd exited cleanly at the previous shutdown. I guess we'll have to add a check for this condition (e.g., if ENV open fails and we're using shared memory, recover and try again). > slapd logs show the following: > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable > to attach to shared system memory region: Invalid argument > [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore > from backup! > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): > DB_ENV->lock_id_free interface requires an environment configured for the > locking subsystem > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint > interface requires an environment configured for the transaction subsystem > [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument > (22) > [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) > [ID 948119 local3.debug] bdb_db_close: alock_close failed > [ID 486161 local3.debug] slapd stopped. > [ID 432338 local3.debug] connections_destroy: nothing to destroy. > > > db_recover must be used to clean up the environment. It gives the message > "db_recover: shmat: id 0: unable to attach to shared system memory region: > Invalid argument" but completes with return code 0, removes the __db.001 file, > and slapd is then able to start without errors. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4851) improper database recovery at startup when using shared memory for db cache
by erici＠motown.cc.utexas.edu 24 Feb '07

24 Feb '07

Full_Name: Eric Irrgang Version: 2.3.34 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared memory segment for the db cache, the automatic bdb database recovery fails after a reboot (because the shared memory segment doesn't exist yet). slapd logs show the following: [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable to attach to shared system memory region: Invalid argument [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore from backup! [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint interface requires an environment configured for the transaction subsystem [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument (22) [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) [ID 948119 local3.debug] bdb_db_close: alock_close failed [ID 486161 local3.debug] slapd stopped. [ID 432338 local3.debug] connections_destroy: nothing to destroy. db_recover must be used to clean up the environment. It gives the message "db_recover: shmat: id 0: unable to attach to shared system memory region: Invalid argument" but completes with return code 0, removes the __db.001 file, and slapd is then able to start without errors.

1 0

Re: (ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by ando＠sys-net.it 24 Feb '07

24 Feb '07

azia(a)techxact.com wrote: > Full_Name: Ahmad Zia > Version: openldap-2.3.31 > OS: Redhat ES 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.227.142.2) > > > I have successfully compiled, make openldad but when I get to the point where I > have to run "make test" it says cannot connect to the openldap server after > timing out. You should ask software usage related questions on the openldap-software mailing list. The ITS is intended to track software bugs or development issues, and you are not pointing out any evidence of software malfunction yet. > When I use this command , I get the following: > > [root@TXDXB openldap]# rpm -qa | grep openldap > openldap-devel-2.2.13-6.4E > openldap-2.2.13-6.4E > openldap-clients-2.2.13-6.4E > > its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I > only have ldap.conf and I do not have slapd.conf, so what I gather so far is > that I am not able to install the server module. This has nothing to do with OpenLDAP software; OpenLDAP software is released only in source form, and it's up to dofwtare distributors to package it in binary form. It is very unlikely that by simply compiling OpenLDAP software as distributed by OpenLDAP you may see anything show up with rpm -qa, since building OpenLDAP software does not result in any rpm package (and, in any case, you'd need to explicitly __install__ any rpm package to see it appear with rpm -qa). > I have used the parameter --enable-slapd with ./configure command but its still > the same thing. Slapd is built by default; the --enable-slapd switch is provided to allow users to __disable__ it. > Can you please tell me what am I doing wrong Testing may fail for hundreds of reasons beyond a bug in the software. You should check trivial things first, e.g. by inspecting any log messages resulting from the tests. See <http://www.openldap.org/faq/data/cache/1089.html> and <http://www.openldap.org/faq/data/cache/56.html> for possible directions. This ITS will be closed. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 24 Feb '07

24 Feb '07

cyril wrote: > The message is located in > > isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) > > located in file bin/named/dlz_ldap_driver.c provided by > ctrix_dlz_9.3.3.patch OK. In your initial posting you claimed to be using bind 9.3.4, I assume you patched 9.3.4 with 9.3.3 patch. Anyway, in that patch I still don't see the message you reported; did you copy it verbatim, or did you elaborate it?. Anyway, that patch looks definitely similar to the analogous code in bind 9.4.0. That code seems to make use of LDAP URLs only as a means to define a LDAP search in compact form; but URLs have a specific syntax with restrictions, as indicated in RFC4516 and RFC3986; pretending to parse them with standards compliant library functions while they don't comply with their definition sounds a bit hazardous. In any case, it's astonishing that the URL syntax is used along with a marker for macro replacement that's the most reserved char in URLs. Sounds like someone chose the largest available gun to shoot in his own foot. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

RE: (ITS#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 24 Feb '07

24 Feb '07

Il s'agit d'un message ` parties multiples au format MIME. ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI =20 -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it]=20 Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 =20 cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; = but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a = bind > problem. > However, I will transmit this information to the BIND/DLZ team. =20 I have few more comments; see below. =20 =20 > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or = %client%) is >> replaced with the ns domain (the client name). >>=20 >> It was working well since I upgrade to 2.3.30-r2. =20 There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. This is a Gentoo relase based on 2.3.30 (the latest relase available is 2.3.33) =20 Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex = values". =20 The message is located in =20 isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch =20 Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? =20 =20 p. =20 =20 =20 Ing. Pierangelo Masarati OpenLDAP Core Team =20 SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------ =20 ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=3DFR link=3Dblue vlink=3Dpurple> <div class=3DSection1> FYI<o:p></o:p> <o:p> </o:p> -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with = bind9<o:p></o:p> <o:p> </o:p> cyril(a)coupel.net wrote:<o:p></o:p> > Tanks for your answer.<o:p></o:p> > I tested by removing the %xxxx% from the = URL and the tests are passed; but<o:p></o:p> > there is an error saying that there is no = %xxx% token.<o:p></o:p> > I already open a case to the BIND team, but = they reply this is not a bind<o:p></o:p> > problem.<o:p></o:p> > However, I will transmit this information = to the BIND/DLZ team.<o:p></o:p> <o:p> </o:p> I have few more comments; see = below.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> > Cyril COUPEL wrote:<o:p></o:p> >> I agree with this = information.<o:p></o:p> >> The fact is the ldapURL is not used as = it, the key %zone% (or %client%) is<o:p></o:p> >> replaced with the ns domain (the client = name).<o:p></o:p> >><o:p> </o:p> >> It was working well since I upgrade to 2.3.30-r2.<o:p></o:p> <o:p> </o:p> There is no = OpenLDAP 2.3.30-r2; the current version is 2.3.34.<o:p></o:p> This = is a Gentoo relase based on 2.3.30 (the latest relase available is = 2.3.33)<o:p></o:p> <o:p> </o:p> Also, you mentioned an error message = "failed to parse ldap URL"; there's<o:p></o:p> no such message in bind 9.3.4 code, nor in = 9.4.0rc2.=A0 Also, there's no<o:p></o:p> explicit ldap_url_parse() call, so the problem = could only arise when<o:p></o:p> performing an operation with that broken DN.=A0 = However, I don't see how<o:p></o:p> the error message could be raised by bind, since = the URL is parsed by<o:p></o:p> bind itself, without using the OpenLDAP API = function, and the DN is only<o:p></o:p> used as base for other operations, so OpenLDAP = API cannot have any<o:p></o:p> notion of that DN being part of an URL.=A0 = Finally, bind itself, while<o:p></o:p> parsing the URL, checks for badly encoded = portions of the URL, and the<o:p></o:p> corresponding error message is "LDAP sdb = zone '%s': URL: bad hex values".<o:p></o:p> <o:p> </o:p> The = message is located in =A0=A0=A0 <o:p></o:p> isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg)<o:p></o:p> located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch<o:p></o:p> <o:p> </o:p> Could you point us to the __real__ version of = OpenLDAP __and__ bind you<o:p></o:p> pretend to be broken?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Ing. Pierangelo Masarati<o:p></o:p> OpenLDAP Core Team<o:p></o:p> <o:p> </o:p> SysNet s.n.c.<o:p></o:p> Via Dossi, 8 - 27100 Pavia - = ITALIA<o:p></o:p> http://www.sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > Office:=A0=A0 +39.02.23998309<o:p></o:p> Mobile:=A0=A0 +39.333.4963172<o:p></o:p> Email:=A0=A0=A0 = pierangelo.masarati(a)sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > <o:p> </o:p> </div> </body> </html> ------=_NextPart_000_0163_01C75810.9E49DBB0--

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

ando(a)sys-net.it wrote: >> # No limits for CNO-LDC >> limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited >> time=unlimited > > Is this "time=unlimited" starting in the first column a wrap of the > mailer or is it really there? Something absurd is happening: that limit > option starting in the first column is a syntax error, but 2.3 ignores > it. What's odd is that with this syntax error I exactly get your crash, > while without it I don't get any crash. The above had nothing to do with your problem. Your problem is related to the fact that you intermixed overlay and database configuration statements, so the idletimeout statement after the accesslog overlay instantiation was causing invalid memory write (beyond the private data of the accesslog overlay instead of in the private data of the bdb database) resulting in heap corruption. Maybe it hasn't been stressed enough, but the order of directives is: - global [- global overlay [- global overlay [...] ]] [- database [- overlay [- overlay [...] ]] [- database [- overlay [- overlay [...] ]]]] and each overlay's directives have to appear before any other overlay's. I'll see if sanity checks may be added to avoid your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Just one quick question: > # No limits for CNO-LDC > limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited > time=unlimited Is this "time=unlimited" starting in the first column a wrap of the mailer or is it really there? Something absurd is happening: that limit option starting in the first column is a syntax error, but 2.3 ignores it. What's odd is that with this syntax error I exactly get your crash, while without it I don't get any crash. >From valgrind, there appears to be some invalid write and an invalid free. I keep investigating... p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Few preliminary comments: 1) could easily reproduce 2) doesn't core with HEAD/2.4 code 3) you probably don't need the unique overlay on the consumer, since it's supposed to trust consistency of data coming from the producer The direct cause of the crash is that the LDAPDN structure that's being used to rebuild a normalized string representation of the unique_base is corrupted. I'm investigating how it got corrupted. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a bind > problem. > However, I will transmit this information to the BIND/DLZ team. I have few more comments; see below. > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or %client%) is >> replaced with the ns domain (the client name). >> >> It was working well since I upgrade to 2.3.30-r2. There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex values". Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4850) back-meta stops returning data
by ando＠sys-net.it 23 Feb '07

23 Feb '07

hyc(a)symas.com wrote: >> I am experiencing problems with back_meta. It does return search results for >> some time, but at some point starts returning empty search results, with SEARCH >> RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 >> minutes. > > Significant changes were made to back-meta between 2.3.32 and 2.3.33. The > current version is 2.3.34. Please upgrade and see if the issue is still present. I believe the reported behavior does no longer occur with 2.3.34. What you report seems to be related to broken behavior when the remote server closes the connection as a consequence of an idletimeout. 2.3.33 saw a lot of improvements on this side, resulting from significant development efforts and stress testing in a harsh environment, where resilience to odd target behavior was a key requirement. 2.3.34 fixed minor issues after that upgrade, and more minor fixes already are in re23 for next 2.3 release, if any. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

quanah(a)stanford.edu wrote: > --On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > >> It might be nice to set up an automated script to pull the updated >> manpages from CVS onto the web site. > >>From CVS for the current primary release. I.e., I think it would be bad if > the manpages for 2.4 showed up right now on the website. You'll note that the web site has a selector for the release you want to view. In some respects I like the old pages being on there because their dates establish a ballpark for when a feature first appeared (well, was first documented). But I think we should always have a "Current" selection as well, that always corresponds to the latest general-use release. -- -- Howard Chu Chief Architect, 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#3812
by quanah＠stanford.edu 23 Feb '07

23 Feb '07

--On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > It might be nice to set up an automated script to pull the updated > manpages from CVS onto the web site. >From CVS for the current primary release. I.e., I think it would be bad if the manpages for 2.4 showed up right now on the website. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

It might be nice to set up an automated script to pull the updated manpages from CVS onto the web site. -- -- Howard Chu Chief Architect, 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="ando(a)sys-net.it"> >>> ghenry(a)suretecsystems.com wrote: >>> >>>> Just a quick to note that there are some overlays missing from >>>> slapd.overlays.5 >>>> in 2.4.4alpha and actual man pages. >>> Please enumerate them; some are intentionally not present because they >>> are not intended for real use. >> >> * dyngroup has no man page, but is listed slapd.overlays.5 >> * slapo-valsort.5 isn't in slapd.overlays.5 >> * slapo-dds.5 isn't listed in slapd.overlays.5 >> * constraint.c has no docs or listed in slapd.overlays.5 > > slapo-constraint.5 was added to CVS April 29 2006. Ok, it wasn't in the 2.4.4alpha though. > >> * seqmod.c has no docs or listed in slapd.overlays.5 > > This is a demo overlay, not intended for actual use. Ah, ok. > > -- > -- Howard Chu > Chief Architect, 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#4850) back-meta stops returning data
by hyc＠symas.com 23 Feb '07

23 Feb '07

ulf.moeller(a)secardeo.com wrote: > Full_Name: Ulf Moeller > Version: 2.3.32 > OS: SLES 9 > URL: > Submission from: (NULL) (62.245.244.226) > > > I am experiencing problems with back_meta. It does return search results for > some time, but at some point starts returning empty search results, with SEARCH > RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 > minutes. Significant changes were made to back-meta between 2.3.32 and 2.3.33. The current version is 2.3.34. Please upgrade and see if the issue is still present. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 23 Feb '07

23 Feb '07

Full_Name: Ulf Moeller Version: 2.3.32 OS: SLES 9 URL: Submission from: (NULL) (62.245.244.226) I am experiencing problems with back_meta. It does return search results for some time, but at some point starts returning empty search results, with SEARCH RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 minutes. It doesn't return data from either of the ldap servers it is connected to. The problem also occurs in a minimal configuration with just one "uri" defined. After slapd is restarted, it again works properly for some time. When running in GDB, I get the following backtrace: Program received signal SIGPIPE, Broken pipe. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4003a55b in __write_nocancel () from /lib/tls/libpthread.so.0 #2 0x08127f34 in sb_stream_write (sbiod=0x81e69c0, buf=0x81deb60, len=64) at sockbuf.c:521 #3 0x081287b6 in sb_debug_write (sbiod=0x81e69d8, buf=0x81deb60, len=64) at sockbuf.c:820 #4 0x08127e50 in ber_int_sb_write (sb=0x81e6d38, buf=0x81deb60, len=64) at sockbuf.c:431 #5 0x08124dd6 in ber_flush (sb=0x81e6d38, ber=0x81e6e40, freeit=0) at io.c:232 #6 0x08111813 in ldap_int_flush_request (ld=0x81e6c00, lr=0x81dfb88) at request.c:151 #7 0x08111c1a in ldap_send_server_request (ld=0x81e6c00, ber=0x81e6e40, msgid=21, parentreq=0x0, srvlist=0x0, lc=0x81dfb40, bind=0x0) at request.c:301 #8 0x081117ca in ldap_send_initial_request (ld=0x81e6c00, msgtype=99, dn=0x40a1300c "", ber=0x81e6e40, msgid=21) at request.c:135 #9 0x08104661 in ldap_search_ext (ld=0x81e6c00, base=0x40a1300c "", scope=2, filter=0x81e6e18 "(mail=someone(a)domain.de)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x40a10f18, sizelimit=500, msgidp=0x81e6b60) at search.c:109 #10 0x080c8194 in meta_back_search_start (op=0x40c007b0, rs=0x40a12210, dc=0x40a110f0, msc=0x81e6bb8, candidate=0, candidates=0x81e6b58) at search.c:208 #11 0x080c83f3 in meta_back_search (op=0x40c007b0, rs=0x40a12210) at search.c:285 #12 0x08063944 in fe_op_search (op=0x40c007b0, rs=0x40a12210) at search.c:355 #13 0x08063465 in do_search (op=0x40c007b0, rs=0x40a12210) at search.c:217 #14 0x08061180 in connection_operation (ctx=0x40a122a0, arg_v=0x40c007b0) at connection.c:1132 #15 0x0810052f in ldap_int_thread_pool_wrapper (xpool=0x81b8b18) at tpool.c:478 #16 0x40035cf7 in start_thread () from /lib/tls/libpthread.so.0 #17 0x400fa21e in clone () from /lib/tls/libc.so.6 #18 0x40a12bb0 in ?? () Here is an (anonymized) log: Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: >>> slap_listener(ldap://:3389) Feb 22 15:16:17 server slapd[14494]: daemon: listen=8, new connection on 11 Feb 22 15:16:17 server slapd[14494]: daemon: added 11r (active) listener=(nil) Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:34632 (IP=0.0.0.0 :3389) Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_bind Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: do_bind: version=3 dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=0 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=0 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=1 tag=97 err=0 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 RESULT tag=97 err=0 text= Feb 22 15:16:17 server slapd[14494]: do_bind: v3 anonymous bind Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_search Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: SRCH "" 2 0 Feb 22 15:16:17 server slapd[14494]: 0 0 0 Feb 22 15:16:17 server slapd[14494]: begin get_filter Feb 22 15:16:17 server slapd[14494]: EQUALITY Feb 22 15:16:17 server slapd[14494]: end get_filter 0 Feb 22 15:16:17 server slapd[14494]: filter: (mail=someone(a)domain.de) Feb 22 15:16:17 server slapd[14494]: attrs: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SRCH base="" scope=2 deref=0 filter="(mail=someone(a)domain.de)" Feb 22 15:16:17 server slapd[14494]: ==> limits_get: conn=5 op=1 dn="[anonymous]" Feb 22 15:16:17 server slapd[14494]: conn=5 op=1: meta_back_getconn[0] Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_getconn: candidates=1 conn=-1 fet ched Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 bound=1 Feb 22 15:16:17 server slapd[14494]: [rw] searchBase: "" -> "" Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=1 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=32 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=2 tag=101 err=32 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SEARCH RESULT tag=101 err=32 nentries=0 tex t= Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: ber_get_next on fd 11 failed errno=0 (Success) Feb 22 15:16:17 server slapd[14494]: connection_read(11): input error=-2 id=5, closing. Feb 22 15:16:17 server slapd[14494]: connection_closing: readying conn=5 sd=11 for close Feb 22 15:16:17 server slapd[14494]: connection_close: deferring conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_unbind Feb 22 15:16:17 server slapd[14494]: conn=5 op=2 UNBIND Feb 22 15:16:17 server slapd[14494]: connection_resched: attempting closing conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: connection_close: conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: =>meta_back_conn_destroy: fetching conn=5 DN="" Feb 22 15:16:17 server slapd[14494]: daemon: removing 11 Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 closed ()

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs