openldap-bugs February 2007

openldap-bugs@openldap.org

32 participants
125 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2007