- openldap-bugs - openldap.org

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hey Pierangelo, I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this looks like it fixes the issue I mentioned in http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion correct? Ryan Steele wrote: > Hi Pierangelo, > >>> Try this patch: >>> >>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >>> >>> It removes the offending check. I don't quite remember the reason (it >>> dates 4.5 years ago). However, I've checked and all tests pass fine, >>> including the one you pointed out. To reproduce, I modified test022 to >>> write the configuration on disk (-F option to consumer slapd); at the end >>> of the test, I tried slapd on the resulting database. Fails with >>> 2.4.22/HEAD, succeeds with this patch. >>> >>> Please test and report. >>> >>> p. > > I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch > does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not > passed correctly upstream to the read/write master. Thoughts? > -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Jul '10

28 Jul '10

Hi Pierangelo, >> Try this patch: >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> >> >> It removes the offending check. I don't quite remember the reason (it >> dates 4.5 years ago). However, I've checked and all tests pass fine, >> including the one you pointed out. To reproduce, I modified test022 to >> write the configuration on disk (-F option to consumer slapd); at the end >> of the test, I tried slapd on the resulting database. Fails with >> 2.4.22/HEAD, succeeds with this patch. >> >> Please test and report. >> >> p. I just wanted to see if you'd had a chance to check into this yet? As mentioned in the last ITS response, your patch does fix the test script, but unfortunately, referrals are still not being automatically chased because the DN is not passed correctly upstream to the read/write master. Thoughts? -- Ryan Steele ryans(a)aweber.com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

Hi, In short, this works: Deleting cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Deleted cn=Test0,cn=Test0,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com While this fails: Deleting cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com Searching cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) Searched cn=Test2,cn=Test2,cn=soap nodes,o=system,cn=cordys,cn=t274,o=vanenburg.com 0 (objectclass=*) LDAP Connection error happend LDAPException: Connection lost waiting for results from cin0575.vanenburg.com:6,366 (91) Connect Error java.net.SocketException: Connection reset Thanks and regards, Binoy Joseph

1 0

Fwd: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

Sending 1 more time as plain text. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 ---------- Forwarded message ---------- From: Binoy Joseph <binoy(a)cordys.com> Date: Wed, Jul 28, 2010 at 6:39 PM Subject: Re: (ITS#6599) slapd not responding To: openldap-its(a)openldap.org Hi, 1) I downloaded OpenLDAP=A02.4.23 (20100719).=A0I checked servers/slapd/back-bdb/cache.c. I see that the fix for=A0ITS#6577 dated July 1 is not available in the release build. I checked out the latest sources and did a build and tested. 2) The issue still persists in Windows. Here are some useful logs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This is a SUCCESSFUL scenario: conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#000000 bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xa96: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xa96: 0 =3D> index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [a0795064] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [26382a68] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [b9195d83] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [64447e0e] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [403d84ed] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [600c0260] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [d66e2c29] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [547b3983] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [1610f370] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [0096defd] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [f612c92d] <=3D key_change 0 <=3D index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D> bdb_cache_delete( 2710 ) hdb_delete: deleted id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" send_ldap_result: conn=3D1000 op=3D8703 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D43189 tag=3D107 err=3D0 ber_flush2: 16 bytes to sd 1832 =A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 0a 01 00 04 00 04 00 =A0 0....= ..k........ tls_write: want=3D90, written=3D90 =A0=A00000: =A017 03 01 00 20 d3 72 46 =A05c 99 ae 97 cd 90 f5 64 =A0 .... = .rF\......d =A0=A00010: =A047 53 38 1d 26 6c c7 d4 =A021 45 28 e2 27 31 bd 5f =A0 GS8.&= l..!E(.'1._ =A0=A00020: =A0bc c4 92 eb 6e 17 03 01 =A000 30 e5 be 97 76 6c cc =A0 ....n= ....0...vl. =A0=A00030: =A029 c0 21 05 d9 f6 55 d6 =A02a dc d5 68 0b f6 73 6a =A0 ).!..= .U.*..h..sj =A0=A00040: =A07f ff 24 8b fa 9e 57 41 =A027 ee d3 9a e5 9a 17 11 =A0 ..$..= .WA'....... =A0=A00050: =A0ee 87 0d 55 ae 98 81 53 =A02d 7d =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 ...U...S-} ldap_write: want=3D16, written=3D16 =A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 0a 01 00 04 00 04 00 =A0 0....= ..k........ conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D slap_graduate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000 daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL connection_get(5) daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL connection_get(5): got connid=3D1000 daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_read(5): checking for input on id=3D1000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is where it FAILS conn=3D1000 op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#000000 bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_get(5) connection_get(5): got connid=3D1000 connection_read(5): checking for input on id=3D1000 ber_get_next tls_read: want=3D5, got=3D5 =A0..... op tag 0x63, time 1280314986 ber_get_next tls_read: want=3D5 error=3DUnknown error ldap_read: want=3D8 error=3DUnknown error daemon: activity on 1 descriptor daemon: waked daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xc4b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xc4b: 0 =3D> index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [aec1526a] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [27382a68] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [ce175d82] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [2230817c] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [8b4384f1] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [600c0260] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [58802faf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [547b3983] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [9821f6f6] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [0096defd] conn=3D1000 op=3D9271 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113 =A0=A00000: =A063 6f 04 4e 63 6e 3d 54 =A065 73 74 33 36 37 2c 63 =A0 co.Nc= n=3DTest367,c =A0=A00010: =A06e 3d 54 65 73 74 33 36 =A037 2c 63 6e 3d 73 6f 61 =A0 n=3DT= est367,cn=3Dsoa =A0=A00020: =A070 20 6e 6f 64 65 73 2c =A06f 3d 73 79 73 74 65 6d =A0 p nod= es,o=3Dsystem =A0=A00030: =A02c 63 6e 3d 63 6f 72 64 =A079 73 2c 63 6e 3d 74 32 =A0 ,cn= =3Dcordys,cn=3Dt2 =A0=A00040: =A037 34 2c 6f 3d 76 61 6e =A065 6e 62 75 72 67 2e 63 =A0 74,o= =3Dvanenburg.c =A0=A00050: =A06f 6d 0a 01 00 0a 01 00 =A002 02 07 d0 02 01 00 01 =A0 om...= ........... =A0=A00060: =A001 00 87 0b 6f 62 6a 65 =A063 74 63 6c 61 73 73 30 =A0 ....o= bjectclass0 =A0=A00070: =A000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,c= n=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> =3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com,0) <=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 <<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" 0 0 =A0 =A02000 0= 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15 =A0=A00000: =A087 0b 6f 62 6a 65 63 74 =A063 6c 61 73 73 30 00 =A0 =A0 =A0.= .objectclass0. end get_filter 0 =A0=A0 =A0filter: (objectClass=3D*) ber_scanf fmt ({M}}) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAFA3 end=3D015AAFA5 len=3D2 =A0=A00000: =A000 00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.. =A0=A0 =A0attrs: conn=3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" scope=3D0 deref= =3D0 filter=3D"(objectClass=3D*)" =3D> hdb_search bdb_dn2entry("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> hdb_dn2id("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [f612c92d] <=3D key_change 0 <=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please help. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 On Wed, Jul 28, 2010 at 12:49 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> w= rote: > > --On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com>= wrote: > >> >> Hi Quanah, >> >> >> Thanks a lot for your reply. >> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in >> Linux. >> But somehow the issue still occurs in Windows. >> Can you mention which file/issue you are talking about regarding the >> locking behavior you mentioned? >> Thanks and regards, >> Binoy Joseph > > ITS#6577 > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =A0the leader in open source messaging and collaboration

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 28 Jul '10

28 Jul '10

--0016361e878249aeff048c7254d0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, 1) I downloaded OpenLDAP 2.4.23 (20100719)<ftp://ftp.openldap.org/pub/OpenLDAP/openldap-stable/openldap-sta= ble-20100719.tgz> . I checked servers/slapd/back-bdb/cache.c. I see that the fix for ITS#6577 dated July 1 is not available in the release build. I checked out the lates= t sources and did a build and tested. 2) The issue still persists in Windows. Here are some useful logs. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This is a SUCCESSFUL scenario: conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#000000 bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xa96: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xa96: 0 =3D> index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [a0795064] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [26382a68] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [b9195d83] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [64447e0e] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [403d84ed] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [600c0260] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [d66e2c29] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [547b3983] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [1610f370] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [0096defd] <=3D key_change 0 =3D> key_change(DELETE,a96) bdb_idl_delete_key: a96 [f612c92d] <=3D key_change 0 <=3D index_entry_del( 2710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D> bdb_cache_delete( 2710 ) hdb_delete: deleted id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" send_ldap_result: conn=3D1000 op=3D8703 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D43189 tag=3D107 err=3D0 ber_flush2: 16 bytes to sd 1832 0000: 30 0e 02 03 00 a8 b5 6b 07 0a 01 00 04 00 04 00 0......k.......= . tls_write: want=3D90, written=3D90 0000: 17 03 01 00 20 d3 72 46 5c 99 ae 97 cd 90 f5 64 .... .rF\......= d 0010: 47 53 38 1d 26 6c c7 d4 21 45 28 e2 27 31 bd 5f GS8.&l..!E(.'1.= _ 0020: bc c4 92 eb 6e 17 03 01 00 30 e5 be 97 76 6c cc ....n....0...vl= . 0030: 29 c0 21 05 d9 f6 55 d6 2a dc d5 68 0b f6 73 6a ).!...U.*..h..s= j 0040: 7f ff 24 8b fa 9e 57 41 27 ee d3 9a e5 9a 17 11 ..$...WA'......= . 0050: ee 87 0d 55 ae 98 81 53 2d 7d ...U...S-} ldap_write: want=3D16, written=3D16 0000: 30 0e 02 03 00 a8 b5 6b 07 0a 01 00 04 00 04 00 0......k.......= . conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D slap_graduate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000 daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL connection_get(5) daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL connection_get(5): got connid=3D1000 daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_read(5): checking for input on id=3D1000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is where it FAILS conn=3D1000 op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") =3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#000000 bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com") daemon: activity on 6 descriptors daemon: activity on: 5r daemon: read activity on 5 daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL connection_get(5) connection_get(5): got connid=3D1000 connection_read(5): checking for input on id=3D1000 ber_get_next tls_read: want=3D5, got=3D5 ..... op tag 0x63, time 1280314986 ber_get_next tls_read: want=3D5 error=3DUnknown error ldap_read: want=3D8 error=3DUnknown error daemon: activity on 1 descriptor daemon: waked daemon: WSselect: listen=3D2 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D3 active_threads=3D0 tvp=3DNULL daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL =3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "children" reques= ted <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> access_allowed: delete access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" "entry" requested <=3D root access granted =3D> access_allowed: delete access granted by manage(=3Dmwrscxd) =3D> hdb_dn2id_delete 0xc4b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" <=3D hdb_dn2id_delete 0xc4b: 0 =3D> index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [aec1526a] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [78d8fcbf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [27382a68] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [ce175d82] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [2230817c] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [815b06f7] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [8b4384f1] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [600c0260] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [58802faf] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [547b3983] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [9821f6f6] <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [0096defd] conn=3D1000 op=3D9271 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113 0000: 63 6f 04 4e 63 6e 3d 54 65 73 74 33 36 37 2c 63 co.Ncn=3DTest36= 7,c 0010: 6e 3d 54 65 73 74 33 36 37 2c 63 6e 3d 73 6f 61 n=3DTest367,cn= =3Dsoa 0020: 70 20 6e 6f 64 65 73 2c 6f 3d 73 79 73 74 65 6d p nodes,o=3Dsys= tem 0030: 2c 63 6e 3d 63 6f 72 64 79 73 2c 63 6e 3d 74 32 ,cn=3Dcordys,cn= =3Dt2 0040: 37 34 2c 6f 3d 76 61 6e 65 6e 62 75 72 67 2e 63 74,o=3Dvanenbur= g.c 0050: 6f 6d 0a 01 00 0a 01 00 02 02 07 d0 02 01 00 01 om.............= . 0060: 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 ....objectclass= 0 0070: 00 . >>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com> =3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com,0) <=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com)=3D0 <<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274= ,o=3D vanenburg.com> SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D vanenburg.com" 0 0 2000 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=3D*) ber_scanf fmt ({M}}) ber: ber_dump: buf=3D015AAF30 ptr=3D015AAFA3 end=3D015AAFA5 len=3D2 0000: 00 00 .. attrs: conn=3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" scope=3D0 deref= =3D0 filter=3D"(objectClass=3D*)" =3D> hdb_search bdb_dn2entry("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") =3D> hdb_dn2id("cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com") <=3D key_change 0 =3D> key_change(DELETE,c4b) bdb_idl_delete_key: c4b [f612c92d] <=3D key_change 0 <=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3Dvanenburg.com" ) success =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please help. Thanks and regards, Binoy Joseph Sr. Software Engineer T +91 406656 1498 =95 M +91 9849176132 On Wed, Jul 28, 2010 at 12:49 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wr= ote: > --On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com> > wrote: > > >> Hi Quanah, >> >> >> Thanks a lot for your reply. >> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in >> Linux. >> But somehow the issue still occurs in Windows. >> Can you mention which file/issue you are talking about regarding the >> locking behavior you mentioned? >> Thanks and regards, >> Binoy Joseph >> > > ITS#6577 > > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --0016361e878249aeff048c7254d0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div>Hi,</div><div><br></div><div>1) I downloaded OpenLDAP=A0<span class=3D= "Apple-style-span" style=3D"font-family: Arial, Verdana, Helvetica; font-si= ze: medium; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical= -spacing: 2px; "><a href=3D"ftp://ftp.openldap.org/pub/OpenLDAP/openldap-st= able/openldap-stable-20100719.tgz">2.4.23 (20100719)</a>.=A0</span>I checke= d servers/slapd/back-bdb/cache.c. I see that the fix for=A0ITS#6577 dated J= uly 1 is not available in the release build. I checked out the latest sourc= es and did a build and tested.</div> <div><br></div><div>2) The issue still persists in Windows. Here are some u= seful logs.</div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>This is a SUCCES= SFUL scenario:</div> <div><br></div><div><div>conn=3D1000 op=3D8703 DEL dn=3D"cn=3DTest220,= cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vane= nburg.com">vanenburg.com</a>"</div><div>bdb_dn2entry("cn=3Dtest22= 0,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://va= nenburg.com">vanenburg.com</a>")</div> <div>=3D=3D> hdb_delete: cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dco= rdys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a></div>= <div>slap_queue_csn: queing 034EFC7C 20100728123751.496923Z#000000#000#0000= 00</div><div> bdb_dn2entry("cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn= =3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</div> <div>=3D> access_allowed: delete access to "cn=3Dsoap nodes,o=3Dsys= tem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.co= m</a>" "children" requested</div><div><=3D root access gr= anted</div> <div> =3D> access_allowed: delete access granted by manage(=3Dmwrscxd)</div><d= iv>=3D> access_allowed: delete access to "cn=3DTest220,cn=3Dsoap no= des,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">v= anenburg.com</a>" "entry" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> hdb_dn2id_delete 0xa9= 6: "cn=3Dtest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D= <a href=3D"http://vanenburg.com">vanenburg.com</a>"</div> <div><=3D hdb_dn2id_delete 0xa96: 0</div><div>=3D> index_entry_del( 2= 710, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" )</div><div>=3D= > key_change(DELETE,a96)</div> <div>bdb_idl_delete_key: a96=A0</div><div><=3D key_change 0</div><div>= =3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [a0795064]= </div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a96)</d= iv><div> bdb_idl_delete_key: a96 [78d8fcbf]</div><div><=3D key_change 0</div><div= >=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [26382a68= ]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a96)</= div> <div>bdb_idl_delete_key: a96 [b9195d83]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [644= 47e0e]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [815b06f7]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [403= d84ed]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [600c0260]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [d66= e2c29]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [547b3983]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [161= 0f370]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,a= 96)</div> <div>bdb_idl_delete_key: a96 [0096defd]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,a96)</div><div>bdb_idl_delete_key: a96 [f61= 2c92d]</div><div><=3D key_change 0</div><div><=3D index_entry_del( 27= 10, "cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" ) success</div> <div>=3D=3D=3D=3D> bdb_cache_delete( 2710 )</div><div>hdb_delete: delete= d id=3D00000a96 dn=3D"cn=3DTest220,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcor= dys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>"<= /div><div>send_ldap_result: conn=3D1000 op=3D8703 p=3D3</div> <div>send_ldap_result: err=3D0 matched=3D"" text=3D""</= div><div>send_ldap_response: msgid=3D43189 tag=3D107 err=3D0</div><div>ber_= flush2: 16 bytes to sd 1832</div><div>=A0=A00000: =A030 0e 02 03 00 a8 b5 6= b =A007 0a 01 00 04 00 04 00 =A0 0......k........ =A0</div> <div>tls_write: want=3D90, written=3D90</div><div>=A0=A00000: =A017 03 01 0= 0 20 d3 72 46 =A05c 99 ae 97 cd 90 f5 64 =A0 .... .rF\......d =A0</div><div= >=A0=A00010: =A047 53 38 1d 26 6c c7 d4 =A021 45 28 e2 27 31 bd 5f =A0 GS8.= &l..!E(.'1._ =A0</div> <div>=A0=A00020: =A0bc c4 92 eb 6e 17 03 01 =A000 30 e5 be 97 76 6c cc =A0 = ....n....0...vl. =A0</div><div>=A0=A00030: =A029 c0 21 05 d9 f6 55 d6 =A02a= dc d5 68 0b f6 73 6a =A0 ).!...U.*..h..sj =A0</div><div>=A0=A00040: =A07f = ff 24 8b fa 9e 57 41 =A027 ee d3 9a e5 9a 17 11 =A0 ..$...WA'....... = =A0</div> <div>=A0=A00050: =A0ee 87 0d 55 ae 98 81 53 =A02d 7d =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ...U...S-} =A0 =A0 =A0 =A0</div><div>ldap_write: want= =3D16, written=3D16</div><div>=A0=A00000: =A030 0e 02 03 00 a8 b5 6b =A007 = 0a 01 00 04 00 04 00 =A0 0......k........ =A0</div> <div> conn=3D1000 op=3D8703 RESULT tag=3D107 err=3D0 text=3D</div><div>slap_gradu= ate_commit_csn: removing 015CFFC8 20100728123751.496923Z#000000#000#000000<= /div><div>daemon: activity on 6 descriptors</div><div>daemon: activity on: = 5r</div> <div>daemon: read activity on 5</div><div>daemon: WSselect: listen=3D2 acti= ve_threads=3D0 tvp=3DNULL</div><div>connection_get(5)</div><div>daemon: WSs= elect: listen=3D3 active_threads=3D0 tvp=3DNULL</div><div>connection_get(5)= : got connid=3D1000</div> <div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL</div><div>c= onnection_read(5): checking for input on id=3D1000</div></div><div>=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D</div> <div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div>This is wh= ere it FAILS</div><div><br></div><div><div><br></div><div><div>conn=3D1000 = op=3D9270 DEL dn=3D"cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordy= s,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>"</d= iv> <div>bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys= ,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</d= iv><div>=3D=3D> hdb_delete: cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn= =3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a><= /div> <div>slap_queue_csn: queing 0420FC7C 20100728110306.101543Z#000000#000#0000= 00</div><div>bdb_dn2entry("cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn= =3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>&= quot;)</div> <div>daemon: activity on 6 descriptors</div><div>daemon: activity on: 5r</d= iv><div>daemon: read activity on 5</div><div>daemon: WSselect: listen=3D2 a= ctive_threads=3D0 tvp=3DNULL</div><div>daemon: WSselect: listen=3D3 active_= threads=3D0 tvp=3DNULL</div> <div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNULL</div><div>c= onnection_get(5)</div><div>connection_get(5): got connid=3D1000</div><div>c= onnection_read(5): checking for input on id=3D1000</div><div>ber_get_next</= div><div> tls_read: want=3D5, got=3D5</div><div>=A0.....=A0</div><div>op tag 0x63, ti= me 1280314986</div><div>ber_get_next</div><div>tls_read: want=3D5 error=3DU= nknown error</div><div>ldap_read: want=3D8 error=3DUnknown error</div><div>= daemon: activity on 1 descriptor</div> <div>daemon: waked</div><div>daemon: WSselect: listen=3D2 active_threads=3D= 0 tvp=3DNULL</div><div>daemon: WSselect: listen=3D3 active_threads=3D0 tvp= =3DNULL</div><div>daemon: WSselect: listen=3D4 active_threads=3D0 tvp=3DNUL= L</div><div>=3D> access_allowed: delete access to "cn=3Dsoap nodes,= o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanen= burg.com</a>" "children" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> access_allowed: delet= e access to "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3D= t274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" "ent= ry" requested</div> <div><=3D root access granted</div><div>=3D> access_allowed: delete a= ccess granted by manage(=3Dmwrscxd)</div><div>=3D> hdb_dn2id_delete 0xc4= b: "cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D= <a href=3D"http://vanenburg.com">vanenburg.com</a>"</div> <div><=3D hdb_dn2id_delete 0xc4b: 0</div><div>=3D> index_entry_del( 3= 147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>" )</div><div>=3D= > key_change(DELETE,c4b)</div> <div>bdb_idl_delete_key: c4b=A0</div><div><=3D key_change 0</div><div>= =3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [aec1526a]= </div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</d= iv><div> bdb_idl_delete_key: c4b [78d8fcbf]</div><div><=3D key_change 0</div><div= >=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [27382a68= ]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</= div> <div>bdb_idl_delete_key: c4b [ce175d82]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [223= 0817c]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [815b06f7]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [8b4= 384f1]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [600c0260]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [588= 02faf]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [547b3983]</div><div><=3D key_change 0</div= ><div>=3D> key_change(DELETE,c4b)</div><div>bdb_idl_delete_key: c4b [982= 1f6f6]</div><div><=3D key_change 0</div><div>=3D> key_change(DELETE,c= 4b)</div> <div>bdb_idl_delete_key: c4b [0096defd]</div><div>conn=3D1000 op=3D9271 do_= search</div><div>ber_scanf fmt ({miiiib) ber:</div><div>ber_dump: buf=3D015= AAF30 ptr=3D015AAF34 end=3D015AAFA5 len=3D113</div><div>=A0=A00000: =A063 6= f 04 4e 63 6e 3d 54 =A065 73 74 33 36 37 2c 63 =A0 co.Ncn=3DTest367,c =A0</= div> <div>=A0=A00010: =A06e 3d 54 65 73 74 33 36 =A037 2c 63 6e 3d 73 6f 61 =A0 = n=3DTest367,cn=3Dsoa =A0</div><div>=A0=A00020: =A070 20 6e 6f 64 65 73 2c = =A06f 3d 73 79 73 74 65 6d =A0 p nodes,o=3Dsystem =A0</div><div>=A0=A00030:= =A02c 63 6e 3d 63 6f 72 64 =A079 73 2c 63 6e 3d 74 32 =A0 ,cn=3Dcordys,cn= =3Dt2 =A0</div> <div>=A0=A00040: =A037 34 2c 6f 3d 76 61 6e =A065 6e 62 75 72 67 2e 63 =A0 = 74,o=3Dvanenburg.c =A0</div><div>=A0=A00050: =A06f 6d 0a 01 00 0a 01 00 =A0= 02 02 07 d0 02 01 00 01 =A0 om.............. =A0</div><div>=A0=A00060: =A00= 1 00 87 0b 6f 62 6a 65 =A063 74 63 6c 61 73 73 30 =A0 ....objectclass0 =A0<= /div> <div>=A0=A00070: =A000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0</div><div>>>> dnPrettyNormal: <cn=3DTest367,cn=3DTest367= ,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://van= enburg.com">vanenburg.com</a>></div> <div>=3D> ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsyste= m,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com<= /a>,0)</div><div><=3D ldap_bv2dn(cn=3DTest367,cn=3DTest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>)=3D0=A0</div> <div>=3D> ldap_dn2bv(272)</div><div><=3D ldap_dn2bv(cn=3DTest367,cn= =3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"= http://vanenburg.com">vanenburg.com</a>)=3D0=A0</div><div>=3D> ldap_dn2b= v(272)</div><div><=3D ldap_dn2bv(cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>)=3D0=A0</div> <div><<< dnPrettyNormal: <cn=3DTest367,cn=3DTest367,cn=3Dsoap n= odes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">= vanenburg.com</a>>, <cn=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsy= stem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.c= om</a>></div> <div>SRCH "cn=3DTest367,cn=3DTest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dc= ordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.com</a>&quot= ; 0 0 =A0 =A02000 0 0</div><div>begin get_filter</div><div>PRESENT</div><di= v>ber_scanf fmt (m) ber:</div> <div>ber_dump: buf=3D015AAF30 ptr=3D015AAF96 end=3D015AAFA5 len=3D15</div><= div>=A0=A00000: =A087 0b 6f 62 6a 65 63 74 =A063 6c 61 73 73 30 00 =A0 =A0 = =A0..objectclass0. =A0=A0</div><div>end get_filter 0</div><div>=A0=A0 =A0fi= lter: (objectClass=3D*)</div> <div> ber_scanf fmt ({M}}) ber:</div><div>ber_dump: buf=3D015AAF30 ptr=3D015AAFA3= end=3D015AAFA5 len=3D2</div><div>=A0=A00000: =A000 00 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0</div><div>=A0=A0 =A0attrs:</div><div>conn= =3D1000 op=3D9271 SRCH base=3D"cn=3DTest367,cn=3DTest367,cn=3Dsoap nod= es,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">va= nenburg.com</a>" scope=3D0 deref=3D0 filter=3D"(objectClass=3D*)&= quot;</div> <div>=3D> hdb_search</div><div>bdb_dn2entry("cn=3Dtest367,cn=3Dtest= 367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://= vanenburg.com">vanenburg.com</a>")</div><div>=3D> hdb_dn2id("c= n=3Dtest367,cn=3Dtest367,cn=3Dsoap nodes,o=3Dsystem,cn=3Dcordys,cn=3Dt274,o= =3D<a href=3D"http://vanenburg.com">vanenburg.com</a>")</div> <div><=3D key_change 0</div><div>=3D> key_change(DELETE,c4b)</div><di= v>bdb_idl_delete_key: c4b [f612c92d]</div><div><=3D key_change 0</div><d= iv><=3D index_entry_del( 3147, "cn=3DTest367,cn=3Dsoap nodes,o=3Dsy= stem,cn=3Dcordys,cn=3Dt274,o=3D<a href=3D"http://vanenburg.com">vanenburg.c= om</a>" ) success</div> </div></div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div>= <div><br></div><div>Please help.</div><br clear=3D"all">Thanks and regards,= <br><br>Binoy Joseph<br> Sr. Software Engineer<br>T +91 406656 1498 =95 M +91 9849176132<br> <br><br><div class=3D"gmail_quote">On Wed, Jul 28, 2010 at 12:49 AM, Quanah= Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com">qu= anah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">--On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph &l= t;<a href=3D"mailto:binoy@cordys.com" target=3D"_blank">binoy(a)cordys.com</a= >> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Hi Quanah,<br> <br> <br> Thanks a lot for your reply.<br> Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in<br> Linux.<br> But somehow the issue still occurs in Windows.<br> Can you mention which file/issue you are talking about regarding the<br> locking behavior you mentioned?<br> Thanks and regards,<br> Binoy Joseph<br> </blockquote> <br></div> ITS#6577<div><div></div><div class=3D"h5"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Principal Software Engineer<br> Zimbra, Inc<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </div></div></blockquote></div><br> --0016361e878249aeff048c7254d0--

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 28 Jul '10

28 Jul '10

Thanks a lot for looking into this issue. On Thu, Jul 22, 2010 at 3:07 AM, Howard Chu <hyc(a)symas.com> wrote: > asifiqbal.desai(a)gmail.com wrote: >> >> Full_Name: Asif Iqbal Desai >> Version: 2.4.16 >> OS: Solaris 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (130.214.64.6) >> >> >> This is a consulation bug for clarification on close() being called from >> ldap_unbind_s with fd =3D 1. >> >> The application uses ldap client apis for user authentication. >> We recently upgraded to use OpenLDAP version 2.4.16 and are getting an >> unexpected AIO error issue when ldap user authentication is enabled. >> >> Investigating further revealed that from ldap_unbind_s ( close(-1) is >> getting >> called. However the close function of solaris libaio does a special >> handling >> when fd< =A00 which causes AIO errors. >> >> The application needs solaris aio support and hence cannot link libc >> before >> libaio. >> >> Is there any specific reason for close being called with fd =3D -1 from >> ldap_unbind_s. >> This issue didnot exist with OpenLDAP 2.3.27. > > I've checked 2.3.43 and 2.4.23; in both cases ber_int_sb_close() is being > called twice on the same sockbuf. I suppose that might be considered a bu= g, > but certainly the behavior has not changed between 2.3 and 2.4. > >> Following is the stacktrace: >> =A0 [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, = 0x0, >> 0x0), >> at 0xffffffff7f406a64 >> =A0 [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, >> 0x0), at >> 0xffffffff7d21eafc >> =A0 [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, >> 0x0), at >> 0xffffffff7d21e160 >> =A0 [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, >> 0xffffffff7dbad2ec, >> 0xd), at 0xffffffff7d21cebc >> =A0 [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at >> 0xffffffff7d26a4bc >> =A0 [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, >> 0x100121a00), at 0xffffffff7d26a048 >> =A0 [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, >> 0xfffffffffffffff2, >> 0x0, 0x100117728), at 0xffffffff7d26a55c >> ... >> ... >> >> Thanks in Advance, >> Asif Iqbal Desai >> >> > > > -- > =A0-- Howard Chu > =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com > =A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/ > =A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/ >

1 0

(ITS#6608) ppolicy internal modifications break replication
by mbackes＠symas.com 27 Jul '10

27 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) The current ppolicy draft standard does not address replication issues, and the resulting implementation has trouble. If frontend-chaining to the master and ppolicy_forward_updates is enabled, invalid binds return success (ITS 6607). If they are disabled, the local changes increase the CSNs in the local copy beyond the contextCSN of the provider, which results in broken replication. (ITS 6606) Possible fixes include: * disallowing shadow contexts the use of ppolicy (probably unpopular) * requiring frontend-chaining once that works * not updating operational attributes at all for ppolicy changes. (allows replicas to diverge on bind failure data but is probably safest)

1 0

(ITS#6607) forwarded bind failure messages cause success
by mbackes＠symas.com 27 Jul '10

27 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) As noted in http://www.openldap.org/lists/openldap-technical/201004/msg00247.html setting up a chain overlay on the frontend and then configuring ppolicy with ppolicy_forward_updates causes BIND operations with invalid credentials to return success, apparently from the result of the chain operation. This is independent of the value of chain-return-error. WHOAMI reports anonymous after these "successful" BINDs with invalid passwords, so there is no security compromise within the directory itself, however this has (as noted in the above email) catastrophic results for external apps trying to authenticate with BIND.

1 0

(ITS#6606) syncrepl search reply for post-dated cookie
by mbackes＠symas.com 27 Jul '10

27 Jul '10

Full_Name: Matthew Backes Version: RE24 OS: URL: Submission from: (NULL) (76.88.107.46) When replicas try to connect to their provider and supply a cookie generated from a CSN beyond what the provider has, the provider returns success and does nothing. It'd be better to return unwilling-to-perform and squirt out an error indicating that the cookie is in the future. This can happen when the replica is actively receiving changes from the current ppolicy setup or other bug-like situations.

1 0

Re: (ITS#6605) Webmin LDAP User Module Don't Work
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

> Full_Name: Andrea Minardi > Version: 2.3.27 > OS: RedHat 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.40.179.242) > > > Webmin's LDAP Users and Groups module stopped working after upgrading from > Webmin 1.400 to webmin 1.510 > > I have been using Webmin's LDAP Users and Groups module on my company's > server > to administer users. It was working fine on Webmin 1.400, but after > upgrading I > get the error: > > "Webmin has connected to the LDAP server, but failed to fetch the schema. > Make > sure that access has not been denied in the LDAP Server module." It is not clear what this issue has to do with OpenLDAP software, since the problem appears after upgrading a third party software. Software interoperation issues can be discussed on openldap-technical. This ITS will be closed. p.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 27 Jul '10

27 Jul '10

> Indeed, looking at it with your comments, definitely overkill. I meant > to ask about this approach in the bug description but forgot, sorry. > > Here is a simpler patch which works the same for my tests: > ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100727.patch Hi. Your patch still looks a bit problematic to me. I'm not sure I understood the issue, since it doesn't work for me without further modifications to the code. Suppose I'm searching with a filter that is related to the pcache attrset "cn uid", and my search lists the attributes cn uid undefined what you're trying to accomplish is that this search behaves as if one only requested cn uid right? Well, in this case (at least in HEAD code, I didn't check in re24 yet) it does not work, because all the tests you add work fine, but later the expected attrset will not be matched because the attribute name "undefined" will still be looked for inside the attribute set. You need to add a check that does not look for attributes for which no an_desc was found. However, this case also matches wildcards '*', '+', '1.1'. Tentatively, the "right" patch would be like this <ftp://ftp.openldap.org/incoming/pierangelo-masarati-its6600.1.patch> Please test and report. p.

1 0

Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com 27 Jul '10

27 Jul '10

--On Tuesday, July 27, 2010 7:04 PM +0530 Binoy Joseph <binoy(a)cordys.com> wrote: > > Hi Quanah, > > > Thanks a lot for your reply. > Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in > Linux. > But somehow the issue still occurs in Windows. > Can you mention which file/issue you are talking about regarding the > locking behavior you mentioned? > Thanks and regards, > Binoy Joseph ITS#6577 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net 27 Jul '10

27 Jul '10

On 27/07/2010 01:08, masarati(a)aero.polimi.it wrote: >> Full_Name: Jonathan CLARKE >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch >> Submission from: (NULL) (80.13.86.63) >> >> >> While checking it's configuration, the pcache overlay verifies each >> configured >> attribute set (pcacheAttrset), to ensure that all attributes in the set >> are >> defined, via slap_str2ad. Given an attribute set with a non-existant >> attribute, >> an error is logged and slapd refuses to start (as expected): >> >> line 117 (pcacheAttrset 0 nonexistantAttr) >> /etc/ldap/slapd.conf: line 117: attribute type undefined. >> >> However, when a search request comes in, the requested attributes list is >> not >> checked by the pcache overlay to ensure that attributes are properly >> defined. In >> effect, slapd just ignores the non-existant attributes, and returns other >> attributes (or behaves as if 1.1 was requested if all requested attributes >> are >> invalid). >> >> This causes pcache's attribute set matching to fail for some requests, >> since it >> counts invalid attributes. If it were to ignore them, configured attribute >> sets >> might match, and successfully cache the search. The patch above implements >> this >> behaviour. Would you consider it for inclusion in OpenLDAP? >> >> I realize this may be considered "repairing bad requests", but sometimes >> one >> can't (easily) control what clients are requesting. Furthermore, it seems >> to >> make sense to have matching behavior all over (since slapd ignores invalid >> requested attributes, pcache should too, IMHO). > > Yours looks like a good catch; however, your patch looks a bit like an > overkill, since the an_desc field of the attribute list that is passed to > get_attr_set() should already be set if the attribute was recognized by > slapd, so you don't need to go through slap_bv2ad() once more. Thanks for your feedback. Indeed, looking at it with your comments, definitely overkill. I meant to ask about this approach in the bug description but forgot, sorry. Here is a simpler patch which works the same for my tests: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100727.patch Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6599) slapd not responding
by binoy＠cordys.com 27 Jul '10

27 Jul '10

--00163628368141a7d5048c5e92b6 Content-Type: text/plain; charset=ISO-8859-1 Hi Quanah, Thanks a lot for your reply. Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in Linux. But somehow the issue still occurs in Windows. Can you mention which file/issue you are talking about regarding the locking behavior you mentioned? Thanks and regards, Binoy Joseph On Mon, Jul 26, 2010 at 9:18 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote: > > Full_Name: Binoy Joseph >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (210.210.79.19) >> > > Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking > behavior introduced in 2.4.21 that was backed out in 2.4.23. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --00163628368141a7d5048c5e92b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Quanah,</div><div><br></div><div>Thanks a lot for your reply.</div>= <div>Looks like the issue does not appear with OpenLDAP 2.4.23 and BDB in L= inux.</div><div>But somehow the issue still occurs in Windows.</div><div> Can you mention which file/issue you are talking about regarding the lockin= g behavior you mentioned?</div><br clear=3D"all">Thanks and regards,<div>Bi= noy Joseph<br> <br><br><div class=3D"gmail_quote">On Mon, Jul 26, 2010 at 9:18 PM, Quanah = Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com">qua= nah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> --On Friday, July 23, 2010 1:13 PM +0000 <a href=3D"mailto:binoy@cordys.com= " target=3D"_blank">binoy(a)cordys.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Binoy Joseph<br> Version: 2.4.21<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (210.210.79.19)<br> </blockquote> <br> Can you reproduce this with OpenLDAP 2.4.23? =A0There was a change in locki= ng behavior introduced in 2.4.21 that was backed out in 2.4.23.<br> <br> --Quanah<br><font color=3D"#888888"> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Principal Software Engineer<br> Zimbra, Inc<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></blockquote></div><br></div> --00163628368141a7d5048c5e92b6--

1 0

(ITS#6605) Webmin LDAP User Module Don't Work
by andrea.minardi＠port.ravenna.it 27 Jul '10

27 Jul '10

Full_Name: Andrea Minardi Version: 2.3.27 OS: RedHat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.40.179.242) Webmin's LDAP Users and Groups module stopped working after upgrading from Webmin 1.400 to webmin 1.510 I have been using Webmin's LDAP Users and Groups module on my company's server to administer users. It was working fine on Webmin 1.400, but after upgrading I get the error: "Webmin has connected to the LDAP server, but failed to fetch the schema. Make sure that access has not been denied in the LDAP Server module."

1 0

(ITS#6604) nssov build error
by mhardin＠symas.com 26 Jul '10

26 Jul '10

Full_Name: Matt Hardin Version: 2.4.23 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (184.11.32.102) nssov.c doesn't compile correctly on systems that don't have a getpeereid function because it doesn't use the LUTIL_GETPEEREID macro. The following patch corrects this. --- nssov.c.orig Mon Jul 26 19:50:47 2010 +++ nssov.c Mon Jul 26 19:32:15 2010 @@ -260,9 +260,15 @@ uid_t uid; gid_t gid; char authid[sizeof("gidNumber=4294967295+uidNumber=424967295,cn=peercred,cn=external,cn=auth")]; +#ifdef LDAP_PF_LOCAL_SENDMSG + char peerbuf[8]; + struct berval peerbv = BER_BVNULL; + peerbv.bv_val = peerbuf; + peerbv.bv_len = sizeof( peerbuf ); +#endif /* log connection */ - if (lutil_getpeereid(sock,&uid,&gid)) + if( LUTIL_GETPEEREID( sock, &uid, &gid, &peerbv )) Debug( LDAP_DEBUG_TRACE,"nssov: connection from unknown client: %s\n",strerror(errno),0,0); else Debug( LDAP_DEBUG_TRACE,"nssov: connection from uid=%d gid=%d\n",

1 0

(ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando At least in libldap and liblber EAGAIN and EWOULDBLOCK are occasionally used without checking whether they are defined or not. Either the checks should be removed, counting on the fact that these error codes are always defined, or they should be used consistently.

1 0

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

> Full_Name: Jonathan CLARKE > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch > Submission from: (NULL) (80.13.86.63) > > > While checking it's configuration, the pcache overlay verifies each > configured > attribute set (pcacheAttrset), to ensure that all attributes in the set > are > defined, via slap_str2ad. Given an attribute set with a non-existant > attribute, > an error is logged and slapd refuses to start (as expected): > > line 117 (pcacheAttrset 0 nonexistantAttr) > /etc/ldap/slapd.conf: line 117: attribute type undefined. > > However, when a search request comes in, the requested attributes list is > not > checked by the pcache overlay to ensure that attributes are properly > defined. In > effect, slapd just ignores the non-existant attributes, and returns other > attributes (or behaves as if 1.1 was requested if all requested attributes > are > invalid). > > This causes pcache's attribute set matching to fail for some requests, > since it > counts invalid attributes. If it were to ignore them, configured attribute > sets > might match, and successfully cache the search. The patch above implements > this > behaviour. Would you consider it for inclusion in OpenLDAP? > > I realize this may be considered "repairing bad requests", but sometimes > one > can't (easily) control what clients are requesting. Furthermore, it seems > to > make sense to have matching behavior all over (since slapd ignores invalid > requested attributes, pcache should too, IMHO). Yours looks like a good catch; however, your patch looks a bit like an overkill, since the an_desc field of the attribute list that is passed to get_attr_set() should already be set if the attribute was recognized by slapd, so you don't need to go through slap_bv2ad() once more. p.

1 0

(ITS#6602) ldap_chase_v3referrals() modifies ld_nextref_proc
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando A fix is coming.

1 0

(ITS#6601) Document ldap_set_urllist_proc()
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando ldap_set_urllist_proc() is not documented; a patch for ldap_open.3 is coming. p.

1 0

Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com 26 Jul '10

26 Jul '10

--On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote: > Full_Name: Binoy Joseph > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.210.79.19) Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking behavior introduced in 2.4.21 that was backed out in 2.4.23. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 26 Jul '10

26 Jul '10

quanah(a)zimbra.com writes: >>> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >>> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >>> somewhere is defined to expand to an expression involving a (long) cast. >> >> Apprently so. >> >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. >> html> > > Fixed by debian. Which is nice, but doesn't help with older debian versions. I don't see what's wrong with changing our #elif to #elif defined like you originally suggested, though I remember there was some confused #elif discussion earlier. -- Hallvard

1 0

(ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net 23 Jul '10

23 Jul '10

Full_Name: Jonathan CLARKE Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch Submission from: (NULL) (80.13.86.63) While checking it's configuration, the pcache overlay verifies each configured attribute set (pcacheAttrset), to ensure that all attributes in the set are defined, via slap_str2ad. Given an attribute set with a non-existant attribute, an error is logged and slapd refuses to start (as expected): line 117 (pcacheAttrset 0 nonexistantAttr) /etc/ldap/slapd.conf: line 117: attribute type undefined. However, when a search request comes in, the requested attributes list is not checked by the pcache overlay to ensure that attributes are properly defined. In effect, slapd just ignores the non-existant attributes, and returns other attributes (or behaves as if 1.1 was requested if all requested attributes are invalid). This causes pcache's attribute set matching to fail for some requests, since it counts invalid attributes. If it were to ignore them, configured attribute sets might match, and successfully cache the search. The patch above implements this behaviour. Would you consider it for inclusion in OpenLDAP? I realize this may be considered "repairing bad requests", but sometimes one can't (easily) control what clients are requesting. Furthermore, it seems to make sense to have matching behavior all over (since slapd ignores invalid requested attributes, pcache should too, IMHO).

1 0

(ITS#6599) slapd not responding
by binoy＠cordys.com 23 Jul '10

23 Jul '10

Full_Name: Binoy Joseph Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.210.79.19) I run OpenLDAP 2.4.21 configured to bdb on Windows and Linux. We run some applications on top of our application framework which in turn is connected to OpenLDAP via JLDAP. We list children of 'cn=soap nodes' (search LDAP) very often as shown in the DIT below. I wrote a test case to create soapnode, soapproc, connectionpoint and then delete them one after the other, ie I create set1, delete set1, create set2, delete set2... Note that list children of 'cn=soap nodes' happen in parallel as mentioned above. Randomly but very consistently, suddenly we face an LDAP not responding issue. When I connect via an LDAP Explorer, I am able to see and expand most of the LDAP entries, except the 'cn=soap nodes' as shown in the DIT below, which says LDAP query did not return indefinitely. CPU: slapd shoots to 50% in Windows and 100% in Linux. Then I have to kill slapd and start again. This does not happen in OpenLDAP 2.4.16. After upgrading to 2.4.21 this started happening. When I switched to hdb, this does not occur in Linux, but continues to happen in Windows. This also looks very similar to http://www.openldap.org/its/index.cgi?findid=6322, Subject: slapd suddenly stops working, and starts using 100% CPU. o=org1 | +-cn=soap nodes | +-cn=soapnode1 | | | +cn=soapproc1 | | | +cn=connectionpoint1 | +-cn=soapnode2 . . Thanks and regards, Binoy Joseph

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by frank.offermanns＠caseris.de 23 Jul '10

23 Jul '10

Hello Quanah, thanks for your info. I compiled OpenLDAP 2.4.23 and BDB 4.8.30, but unfortunately the problem still persists. I added 10000 Users added and: with RefreshAndPersist in 136 users at least one attribute was missing. with RefreshOnly in 34 users at least one attribute was missing. In my post in March I said, that with accesslog I do not have this problem. This is not completely true. Meanwhile (also with 2.4.21) I found out that with accesslog I also have this problem, but less frequentely. So with about 40000 users added I had only about 1 or 2 attributes missing. With the new version I added 10000, 20000 and 80000 users without a single problem. So I am not sure, if this problem still persist with accesslog, but with RefreshAndPersist and RefreshOnly there is definitely still a problem. Due to the fact that no one else complains about this, maybe this problem is Windows only? Or is there someone else who also has this problem? If you are interested I could provide you my windows test-application. With this the problem can be reproduced in a few minutes. Let me know if I should send you this program. Thanks a lot so far. Best regards, Frank Offermanns > > > Full_Name: Frank Offermanns > > Version: 2.4.21 > > OS: Windwos > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (217.6.189.242) > > > > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > > testing master/slave replication while adding 10000 users with 10 filled > > attributes. I am not using a specific time synchronization. Standard > > windows time synchronization in domains is active. But as far as I > > understood, a microsecond time synchronisation is only needed for > > master-master, which I am not testing. > > BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP > 2.4.23, and report back if you still have issues. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Tuesday, March 09, 2010 12:23 PM +0000 Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.21 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > testing master/slave replication while adding 10000 users with 10 filled > attributes. I am not using a specific time synchronization. Standard > windows time synchronization in domains is active. But as far as I > understood, a microsecond time synchronisation is only needed for > master-master, which I am not testing. BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP 2.4.23, and report back if you still have issues. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Wednesday, February 17, 2010 1:05 PM +0000 worganc(a)avaya.com wrote: > Full_Name: Craig Worgan > Version: 2.4.21 > OS: RedHat Enterprise Linux 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.11.182.86) Hi Craig, Are you able to reproduce this with OpenLDAP 2.4.23? There have been some fixes around deletes since 2.4.21, and an issue that was introduced in 2.4.21 specific to cached objects as well. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Tuesday, May 25, 2010 6:37 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> quanah(a)zimbra.com writes: >>> Actually, the issue seems to be name changes in the header files under >>> BSD. This causes TIOCNOTTY to end up being undefined. >> >> That would not give the error message shown in >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021. >> html>: >> >> build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr >> aries/liblutil/detach.c:131:7: error: missing binary operator before >> token "long" >> >> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >> somewhere is defined to expand to an expression involving a (long) cast. > > Apprently so. > > <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. > html> Fixed by debian. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Fwd: Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 22 Jul '10

22 Jul '10

Hi Howard, > ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my > HEAD). ;-) This ITS can be closed - the bug was in my head rather than in CVS head (background information: unresolved cvs update conflicts). I'm sorry for the inconveniences! Best regards, Daniel

1 0

Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 22 Jul '10

22 Jul '10

On 07/21/2010 10:53 PM, Howard Chu wrote: > daniel(a)pluta.biz wrote: >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Lnx >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) >> >> >> slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig >> settings. >> >> Steps to reproduce: >> >> 1.) cat> slapd.conf<<EOF >> include /tmp/openldap/etc/openldap/schema/core.schema >> pidfile /tmp/openldap/var/run/slapd.pid >> argsfile /tmp/openldap/var/run/slapd.args >> database hdb >> dbconfig set_cachesize 0 1048576 0 >> dbconfig set_lg_bsize 2097152 >> suffix "dc=my-domain,dc=com" >> rootdn "cn=Manager,dc=my-domain,dc=com" >> rootpw secret >> directory /tmp/openldap/var/openldap-data >> index objectClass eq >> EOF >> >> 2.) convert slapd.conf into cn=config: >> mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d >> >> 3.) search slapd.d directory for "olcdbconfig" attribute values: >> grep -R -i olcDbConfig slapd.d/ >> >> the string "olcDbConfig" cannot be found (only in schema definition)... >> > I'm unable to reproduce this issue; the conversion works for me: > > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f > testrun/slapd.1.conf -F testrun/slapd.d -d -1 > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d > -n0 | less > > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: {1}bdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a > olcDbCacheSize: 1000 > olcDbCheckpoint: 1024 5 > olcDbConfig: {0}set_lg_bsize 2097152 > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 0 > olcDbIndex: objectClass eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > structuralObjectClass: olcBdbConfig > entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 > creatorsName: cn=config > createTimestamp: 20100721204954Z > entryCSN: 20100721204954.041390Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20100721204954Z > Many thanks Howard for your reply. hmmm, sounds like some kind of deadlock to me: you cannot reproduce my and I cannot re-reproduce your results. All differences I can currently see: I'm using "hdb" and I use "grep -r -i 'olcDbConfig' slapd.d/" to test whether olcDbConfig does exist in any file below slapd.d. As the contents of an existing DB_CONFIG file (within the database-dir) will be converted correctly into olcDbConfig here, are you sure you had no "DB_CONFIG" file in your database directory? Could you please provide me the (original) slapd.conf you've used above? Than I would like to reproduce your exact test procedure here. ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my HEAD). ;-)

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by hyc＠symas.com 21 Jul '10

21 Jul '10

asifiqbal.desai(a)gmail.com wrote: > Full_Name: Asif Iqbal Desai > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.214.64.6) > > > This is a consulation bug for clarification on close() being called from > ldap_unbind_s with fd = 1. > > The application uses ldap client apis for user authentication. > We recently upgraded to use OpenLDAP version 2.4.16 and are getting an > unexpected AIO error issue when ldap user authentication is enabled. > > Investigating further revealed that from ldap_unbind_s ( close(-1) is getting > called. However the close function of solaris libaio does a special handling > when fd< 0 which causes AIO errors. > > The application needs solaris aio support and hence cannot link libc before > libaio. > > Is there any specific reason for close being called with fd = -1 from > ldap_unbind_s. > This issue didnot exist with OpenLDAP 2.3.27. I've checked 2.3.43 and 2.4.23; in both cases ber_int_sb_close() is being called twice on the same sockbuf. I suppose that might be considered a bug, but certainly the behavior has not changed between 2.3 and 2.4. > Following is the stacktrace: > [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), > at 0xffffffff7f406a64 > [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21eafc > [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21e160 > [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, > 0xd), at 0xffffffff7d21cebc > [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at > 0xffffffff7d26a4bc > [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, > 0x100121a00), at 0xffffffff7d26a048 > [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, > 0x0, 0x100117728), at 0xffffffff7d26a55c > ... > ... > > Thanks in Advance, > Asif Iqbal Desai > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6595) Patch - Mozilla NSS - delay token auth until needed
by hyc＠symas.com 21 Jul '10

21 Jul '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-initauthtoken.patch > Submission from: (NULL) (76.113.111.209) > > > The code was doing all of the authentications to all of the tokens during the > init phase. This was causing problems with NSS cert/key clients, prompting for > the cert/key db password, when it isn't needed, since it is only needed to get > private key information. The patch is to just remove the token authentication > during init. The code already authenticates to the token when private key > information is needed e.g. running in TLS/SSL server mode, or using client cert > auth. > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > Committed to HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by hyc＠symas.com 21 Jul '10

21 Jul '10

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Lnx > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) > > > slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. > > Steps to reproduce: > > 1.) cat> slapd.conf<<EOF > include /tmp/openldap/etc/openldap/schema/core.schema > pidfile /tmp/openldap/var/run/slapd.pid > argsfile /tmp/openldap/var/run/slapd.args > database hdb > dbconfig set_cachesize 0 1048576 0 > dbconfig set_lg_bsize 2097152 > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /tmp/openldap/var/openldap-data > index objectClass eq > EOF > > 2.) convert slapd.conf into cn=config: > mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d > > 3.) search slapd.d directory for "olcdbconfig" attribute values: > grep -R -i olcDbConfig slapd.d/ > > the string "olcDbConfig" cannot be found (only in schema definition)... > I'm unable to reproduce this issue; the conversion works for me: violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f testrun/slapd.1.conf -F testrun/slapd.d -d -1 violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d -n0 | less dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=example,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=example,dc=com olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a olcDbCacheSize: 1000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_lg_bsize 2097152 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 creatorsName: cn=config createTimestamp: 20100721204954Z entryCSN: 20100721204954.041390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721204954Z -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by hyc＠symas.com 21 Jul '10

21 Jul '10

masarati(a)aero.polimi.it wrote: >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: NA >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> It would be extremely useful to have an extended operation that allows >>> querying >>> the number of children of a given (sub)tree, so that one can avoid >>> iterating >>> through the entire subtree to determine this number. >>> >> Might as well ask for the numSubordinates operational attribute to be >> implemented instead, this doesn't seem to merit a new exop. And for >> numSubordinates, see the -devel archives for why we chose not to implement >> it. >> >> In either case, the server still needs to iterate over all entries >> internally, >> and the result has to take ACLs and entry disclosure into account. > > An exop would allow to easily discriminate between intentional and > "catchall" requests, like "+". Moreover, it might make sense to > discriminate at least between subtree and onelevel number of subordinates; > this would require two distinct operational attributes, or a parameter in > the exop. > > I'm not endorsing either solution, I'm just pointing out possible pros and > cons. If you want to be able to distinguish results based on scope then it makes more sense to just define a Search control. Like No-op - count the entries that would be returned, instead of returning them. (And bypassing the sizelimit too, but probably not bypassing timelimit.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#6597 published: SECURITY: ldap service crash while connected AD server reboot
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6597 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6597

1 0

ITS#6593 published: SECURITY: Ldapsearch Error while using Back-NDB
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6593 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6593

1 0

ITS#6594 published: SECURITY: Ldapsearch Error while using Back-NDB
by openldap-its＠OpenLDAP.org 21 Jul '10

21 Jul '10

Private ITS#6594 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6594

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by masarati＠aero.polimi.it 21 Jul '10

21 Jul '10

> quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: NA >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> It would be extremely useful to have an extended operation that allows >> querying >> the number of children of a given (sub)tree, so that one can avoid >> iterating >> through the entire subtree to determine this number. >> > Might as well ask for the numSubordinates operational attribute to be > implemented instead, this doesn't seem to merit a new exop. And for > numSubordinates, see the -devel archives for why we chose not to implement > it. > > In either case, the server still needs to iterate over all entries > internally, > and the result has to take ACLs and entry disclosure into account. An exop would allow to easily discriminate between intentional and "catchall" requests, like "+". Moreover, it might make sense to discriminate at least between subtree and onelevel number of subordinates; this would require two distinct operational attributes, or a parameter in the exop. I'm not endorsing either solution, I'm just pointing out possible pros and cons. p.

1 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree
by hyc＠symas.com 21 Jul '10

21 Jul '10

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > It would be extremely useful to have an extended operation that allows querying > the number of children of a given (sub)tree, so that one can avoid iterating > through the entire subtree to determine this number. > Might as well ask for the numSubordinates operational attribute to be implemented instead, this doesn't seem to merit a new exop. And for numSubordinates, see the -devel archives for why we chose not to implement it. In either case, the server still needs to iterate over all entries internally, and the result has to take ACLs and entry disclosure into account. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6598) EXOP to return number of children of a (sub)tree
by quanah＠zimbra.com 21 Jul '10

21 Jul '10

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) It would be extremely useful to have an extended operation that allows querying the number of children of a given (sub)tree, so that one can avoid iterating through the entire subtree to determine this number.

1 0

(ITS#6595) Patch - Mozilla NSS - delay token auth until needed
by rmeggins＠redhat.com 20 Jul '10

20 Jul '10

Full_Name: Rich Megginson Version: 2.4.23 OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-initauthtoken.patch Submission from: (NULL) (76.113.111.209) The code was doing all of the authentications to all of the tokens during the init phase. This was causing problems with NSS cert/key clients, prompting for the cert/key db password, when it isn't needed, since it is only needed to get private key information. The patch is to just remove the token authentication during init. The code already authenticates to the token when private key information is needed e.g. running in TLS/SSL server mode, or using client cert auth. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6592) slapadd allows objects with objectClass doublets
by masarati＠aero.polimi.it 20 Jul '10

20 Jul '10

slapd(8) can handle those occurrences. slapadd(8) is intended to load LDIF files generated by slapcat(8), thus presumably consistent. In general, it deals with the most obvious errors. I don't think asking slapadd to perform these checks is a good idea, as it would slow it down without real benefit: if an error is caught, you would need to restart, wasting all the actual write effort. A sanity check tool for unreliable LDIF would probably be more appropriate. p.

1 0

(ITS#6592) slapadd allows objects with objectClass doublets
by kolbjorn.barmen＠uninett.no 20 Jul '10

20 Jul '10

Full_Name: Kolbjørn Barmen Version: 2.4.23 OS: Linux, Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:1:0:158:38:62:199) I had problems getting syncrepl working, and it the culpit turned out to be doublets of "objectClass: organizationalRole" for given objects. This seems to not have been a problem with old 2.3.30 with old replication mechanics, but for syncrepl it seems critical. When upgrading from 2.3.30 to 2.4.23 slapcat/slapadd was used. Example from ldif: dn: cn=admin,dc=foo,dc=no objectClass: organizationalRole objectClass: top objectClass: simpleSecurityObject objectClass: organizationalRole ... It would be very helpfull if slapadd could detect such obvious fail in ldif-data and spit a warning (when not using -q at least).

1 0

Re: (ITS#6591) Openldap 2.4.16 with BDB 4.7.25 slapd 200% issue
by quanah＠zimbra.com 20 Jul '10

20 Jul '10

--On Monday, July 19, 2010 10:37 PM +0000 dsbrar16(a)yahoo.com wrote: > Full_Name: Devender Singh > Version: 2.4.16 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.180.61.218) The ITS system is for submitting bugs, not asking for help. As I already told you in email, use the openldap-technical(a)openldap.org mailing list for your questions about how to properly use and tune OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org 19 Jul '10

19 Jul '10

Daniel Pluta <daniel(a)pluta.biz> wrote: > As I'm not (yet ;-)) an OTP-expert I have not tested any further because > I currently just don't know how to calculate the one-time password based > on the challenge ... skey(1) can do it for you. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#6591) Openldap 2.4.16 with BDB 4.7.25 slapd 200% issue
by dsbrar16＠yahoo.com 19 Jul '10

19 Jul '10

Full_Name: Devender Singh Version: 2.4.16 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.180.61.218) Hi All, I need help for openldap slapd 200% cpu utilization issue. I have configured three openldap servers(2 Masters and 1 Slave). I have configure PEN load balancer for failover setup on 2 master openldap servers.It means application server first of all hit the loadbalancer port and than PEN LB will forwad that request to Master 1 or 2 openldap server. Hardware configuration on all boxes: OS: RHEL5(x86_64) RAM: 2GB Number of CPU: 2(Intel(R) Xeon(R)2.00GHz) Number of BDB databases: 2 Databse1: Number of users : 830000 Number of dns: 830000 Database2: Number of users: 2000 Number of dns: 800000 My Application1 using Databse1 and Application2 using Databse2. Application2 just authenticating the users and store last 10 password history only, It means Application1 is not using openldap too much. In Application2(90% dependent on openldap) every user have 1000+ sub leafs entries. when I want to do major changes(number of leafs write) into this, its got hanged and got socket closed error in application logs and CPU utilization goes 200% and RAM 52%. My DB_CONFIG file is below: # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. # # See the Oracle Berkeley DB documentation # <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co…> # for detail description of DB_CONFIG syntax and semantics. # # Hints can also be found in the OpenLDAP Software FAQ # <http://www.openldap.org/faq/index.cgi?file=2> # in particular: # <http://www.openldap.org/faq/index.cgi?file=1075> # Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment. # one 0.25 GB cache set_cachesize 0 268435456 1 # Data Directory #set_data_dir db # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152 #set_lg_dir logs # Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option). Please help me here that what I need to do for better performance. Thanks in advance. My contact number is +919650477441

1 0

Re: (ITS#6475) SASL OTP and syncrepl
by daniel＠pluta.biz 19 Jul '10

19 Jul '10

Hi, I've received segmentation faults during some basic SASL OTP testing using CVS HEAD. Below you'll find a small patch (against HEAD) which seems to fix this issue ... Before the patch: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) (<== slapd segfault) After the patch has been applied: root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch -v -Y OTP -U test1 ldap_initialize( <DEFAULT> ) SASL/OTP authentication started Challenge: otp-md5 498 ti6311 ext Please enter your one-time password: huhu ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: (<== slapd still running ;-) ) As I'm not (yet ;-)) an OTP-expert I have not tested any further because I currently just don't know how to calculate the one-time password based on the challenge ... Best regards, Daniel Index: servers/slapd/sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v retrieving revision 1.274 diff -u -r1.274 sasl.c --- servers/slapd/sasl.c 15 Apr 2010 16:13:54 -0000 1.274 +++ servers/slapd/sasl.c 19 Jul 2010 19:55:11 -0000 @@ -548,7 +548,7 @@ op.o_req_ndn.bv_val = (char *)pr[i].values[0]; } #ifdef SLAP_AUXPROP_DONTUSECOPY - { + if ( slap_dontUseCopy_propnames != NULL ) { struct berval bv; ber_str2bv( &pr[i].name[1], 0, 1, &bv ); for ( j = 0; !BER_BVISNULL( &slap_dontUseCopy_propnames[ j ] ); j++ ) {

1 0

(ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config
by daniel＠pluta.biz 16 Jul '10

16 Jul '10

Full_Name: Daniel Pluta Version: HEAD OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. Steps to reproduce: 1.) cat > slapd.conf <<EOF include /tmp/openldap/etc/openldap/schema/core.schema pidfile /tmp/openldap/var/run/slapd.pid argsfile /tmp/openldap/var/run/slapd.args database hdb dbconfig set_cachesize 0 1048576 0 dbconfig set_lg_bsize 2097152 suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/openldap/var/openldap-data index objectClass eq EOF 2.) convert slapd.conf into cn=config: mkdir slapd.d && slaptest -f slapd.conf -F slapd.d 3.) search slapd.d directory for "olcdbconfig" attribute values: grep -R -i olcDbConfig slapd.d/ the string "olcDbConfig" cannot be found (only in schema definition)...

1 0

ITS#6576
by marco.pizzoli＠gmail.com 15 Jul '10

15 Jul '10

--0016e6de0432b2d346048b6a8223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use of grep. My initial request is motivated by a heavy trafficated deployment in which access log files are rotated every 3h and the information about the binddn/ip_src fall often in the rotated file. Worst of this, IBM Unix AIX systems permit LDAP integration using a daemon (secldapclntd) which creates a *permanent* pool of connections againts all ldap servers configured. IBM DB2 v9.5+ permit a native ldap integration and the behaviour is analogous to the AIX one. So, if I need to extract specific information about a binddn/ip I have to follow many files and correlate many informations (conn=3D<number>) For my purposes it would be sufficient an extension to slapo-accesslog permitting me to define a filter on the binddn of the activity. Thanks Marco --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --0016e6de0432b2d346048b6a8223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see only now that my ITS is in closed state, with the note about the use = of grep.<br><br>My initial request is motivated by a heavy trafficated depl= oyment in which access log files are rotated every 3h and the information a= bout the binddn/ip_src fall often in the rotated file.<br> <br>Worst of this, IBM Unix AIX systems permit LDAP integration using a dae= mon (secldapclntd) which creates a *permanent* pool of connections againts = all ldap servers configured.<br>IBM DB2 v9.5+ permit a native ldap integrat= ion and the behaviour is analogous to the AIX one.<br> <br>So, if I need to extract specific information about a binddn/ip I have = to follow many files and correlate many informations (conn=3D<number>= )<br><br>For my purposes it would be sufficient an extension to slapo-acces= slog permitting me to define a filter on the binddn of the activity.<br> <br>Thanks<br>=A0=A0=A0 Marco<br><br><br clear=3D"all"><br>-- <br>_________= ________________________________<br>Non =E8 forte chi non cade, ma chi cade= ndo ha la forza di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ji= m Morrison<br> <div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_pop= up"></div><style type=3D"text/css">#avg_ls_inline_popup { position:absolut= e; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; = width: 240px; overflow: hidden; word-wrap: break-word; color: black; fo= nt-size: 10px; text-align: left; line-height: 13px;}</style> --0016e6de0432b2d346048b6a8223--

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> Rich Megginson wrote: >>>> Howard Chu wrote: >>>>> rmeggins(a)redhat.com wrote: >>>>>> Full_Name: Rich Megginson >>>>>> Version: 2.4.23 >>>>>> OS: Fedora >>>>>> URL: >>>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>>> >>>>>> >>>>>> >>>>>> Submission from: (NULL) (76.113.111.209) >>>>>> >>>>>> >>>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>>> case >>>>>> so, see if the cert and issuer are the same cert, and allow the >>>>>> use of it (with a warning) >>>>> >>>>> If you checked to see if the issuer is already trusted, I guess the >>>>> patch is OK. >>>>> >>>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>>> documentation says to use explicit CA certs, separate from the server >>>>> cert. Is it really a good idea to break this validation check? >>>> Probably not, but openssl seems to allow it. This provides parity >>>> with >>>> the openssl implementation. >>>> >>>> This issue came up when testing openldap with NSS support in Fedora. >>>> The Fedora package creates a self signed CA cert using openssl req >>>> -x509. This works with openldap+openssl, but fails with >>>> openldap+moznss. >>> >>> In the OpenSSL case, it only succeeds if the cert is configured as >>> both a CA cert and a server cert. I.e., the client must have been >>> configured to trust the cert already. I believe for your patch, it >>> should fail when CERT_FindCertIssuer() returns NULL. No? >> You are correct. I've uploaded a new patch. > > OK, committed. Thanks for the patch. And thank you for your help. > >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> >> >> >> Here is the diff between the two patches: >> 32,34c32 >> < + /* no issuer - warn and >> allow */ >> < + status = SECSuccess; >> < + rc = 0; >> --- >> > + /* no issuer - fail */ >> 36c34 >> < + "TLS: warning: the >> server certificate %s has no issuer - " >> --- >> > + "TLS: error: the >> server certificate %s has no issuer - " >> >>> >>>>> Also, where does this check occur in the main sequence of >>>>> verification >>>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>>> been checked successfully? >>>> Yes. This check occurs in the cert chain processing, which is done >>>> last. >>> >>> OK. >>> >> >> > >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> Rich Megginson wrote: >>> Howard Chu wrote: >>>> rmeggins(a)redhat.com wrote: >>>>> Full_Name: Rich Megginson >>>>> Version: 2.4.23 >>>>> OS: Fedora >>>>> URL: >>>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>>> >>>>> >>>>> Submission from: (NULL) (76.113.111.209) >>>>> >>>>> >>>>> MozNSS doesn't like self-signed CA certs that are also used for >>>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>>> case >>>>> so, see if the cert and issuer are the same cert, and allow the >>>>> use of it (with a warning) >>>> >>>> If you checked to see if the issuer is already trusted, I guess the >>>> patch is OK. >>>> >>>> But that aside, MozNSS's behavior sounds correct to me, and our >>>> documentation says to use explicit CA certs, separate from the server >>>> cert. Is it really a good idea to break this validation check? >>> Probably not, but openssl seems to allow it. This provides parity with >>> the openssl implementation. >>> >>> This issue came up when testing openldap with NSS support in Fedora. >>> The Fedora package creates a self signed CA cert using openssl req >>> -x509. This works with openldap+openssl, but fails with >>> openldap+moznss. >> >> In the OpenSSL case, it only succeeds if the cert is configured as >> both a CA cert and a server cert. I.e., the client must have been >> configured to trust the cert already. I believe for your patch, it >> should fail when CERT_FindCertIssuer() returns NULL. No? > You are correct. I've uploaded a new patch. OK, committed. Thanks for the patch. > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2…<ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> > > Here is the diff between the two patches: > 32,34c32 > < + /* no issuer - warn and allow */ > < + status = SECSuccess; > < + rc = 0; > --- > > + /* no issuer - fail */ > 36c34 > < + "TLS: warning: the > server certificate %s has no issuer - " > --- > > + "TLS: error: the > server certificate %s has no issuer - " > >> >>>> Also, where does this check occur in the main sequence of verification >>>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>>> been checked successfully? >>> Yes. This check occurs in the cert chain processing, which is done >>> last. >> >> OK. >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > Rich Megginson wrote: >> Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 >>>> OS: Fedora >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>>> >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> MozNSS doesn't like self-signed CA certs that are also used for >>>> TLS/SSL server certs (such as generated by openssl req -x509) >>>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>>> case >>>> so, see if the cert and issuer are the same cert, and allow the >>>> use of it (with a warning) >>> >>> If you checked to see if the issuer is already trusted, I guess the >>> patch is OK. >>> >>> But that aside, MozNSS's behavior sounds correct to me, and our >>> documentation says to use explicit CA certs, separate from the server >>> cert. Is it really a good idea to break this validation check? >> Probably not, but openssl seems to allow it. This provides parity with >> the openssl implementation. >> >> This issue came up when testing openldap with NSS support in Fedora. >> The Fedora package creates a self signed CA cert using openssl req >> -x509. This works with openldap+openssl, but fails with >> openldap+moznss. > > In the OpenSSL case, it only succeeds if the cert is configured as > both a CA cert and a server cert. I.e., the client must have been > configured to trust the cert already. I believe for your patch, it > should fail when CERT_FindCertIssuer() returns NULL. No? You are correct. I've uploaded a new patch. URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714-2… <ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p…> Here is the diff between the two patches: 32,34c32 < + /* no issuer - warn and allow */ < + status = SECSuccess; < + rc = 0; --- > + /* no issuer - fail */ 36c34 < + "TLS: warning: the server certificate %s has no issuer - " --- > + "TLS: error: the server certificate %s has no issuer - " > >>> Also, where does this check occur in the main sequence of verification >>> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >>> been checked successfully? >> Yes. This check occurs in the cert chain processing, which is done >> last. > > OK. >

1 0

ITS#6570 published: SECURITY: Two OpenLDAP preauth vulnerabilities
by openldap-its＠OpenLDAP.org 14 Jul '10

14 Jul '10

Private ITS#6570 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6570

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

Rich Megginson wrote: > Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 >>> OS: Fedora >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >>> >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> MozNSS doesn't like self-signed CA certs that are also used for >>> TLS/SSL server certs (such as generated by openssl req -x509) >>> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >>> case >>> so, see if the cert and issuer are the same cert, and allow the >>> use of it (with a warning) >> >> If you checked to see if the issuer is already trusted, I guess the >> patch is OK. >> >> But that aside, MozNSS's behavior sounds correct to me, and our >> documentation says to use explicit CA certs, separate from the server >> cert. Is it really a good idea to break this validation check? > Probably not, but openssl seems to allow it. This provides parity with > the openssl implementation. > > This issue came up when testing openldap with NSS support in Fedora. > The Fedora package creates a self signed CA cert using openssl req > -x509. This works with openldap+openssl, but fails with openldap+moznss. In the OpenSSL case, it only succeeds if the cert is configured as both a CA cert and a server cert. I.e., the client must have been configured to trust the cert already. I believe for your patch, it should fail when CERT_FindCertIssuer() returns NULL. No? >> Also, where does this check occur in the main sequence of verification >> - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already >> been checked successfully? > Yes. This check occurs in the cert chain processing, which is done last. OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… >> >> Submission from: (NULL) (76.113.111.209) >> >> >> MozNSS doesn't like self-signed CA certs that are also used for >> TLS/SSL server certs (such as generated by openssl req -x509) >> CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that >> case >> so, see if the cert and issuer are the same cert, and allow the >> use of it (with a warning) > > If you checked to see if the issuer is already trusted, I guess the > patch is OK. > > But that aside, MozNSS's behavior sounds correct to me, and our > documentation says to use explicit CA certs, separate from the server > cert. Is it really a good idea to break this validation check? Probably not, but openssl seems to allow it. This provides parity with the openssl implementation. This issue came up when testing openldap with NSS support in Fedora. The Fedora package creates a self signed CA cert using openssl req -x509. This works with openldap+openssl, but fails with openldap+moznss. > > Also, where does this check occur in the main sequence of verification > - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already > been checked successfully? Yes. This check occurs in the cert chain processing, which is done last. > >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >

1 0

Re: (ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by hyc＠symas.com 14 Jul '10

14 Jul '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… > Submission from: (NULL) (76.113.111.209) > > > MozNSS doesn't like self-signed CA certs that are also used for > TLS/SSL server certs (such as generated by openssl req -x509) > CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case > so, see if the cert and issuer are the same cert, and allow the > use of it (with a warning) If you checked to see if the issuer is already trusted, I guess the patch is OK. But that aside, MozNSS's behavior sounds correct to me, and our documentation says to use explicit CA certs, separate from the server cert. Is it really a good idea to break this validation check? Also, where does this check occur in the main sequence of verification - has the BasicConstraints, KeyUsage, and/or NetscapeCertType already been checked successfully? > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6589) Patch - Mozilla NSS - support use of self signed CA certs as server certs
by rmeggins＠redhat.com 14 Jul '10

14 Jul '10

Full_Name: Rich Megginson Version: 2.4.23 OS: Fedora URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-selfsignedcacert-20100714.p… Submission from: (NULL) (76.113.111.209) MozNSS doesn't like self-signed CA certs that are also used for TLS/SSL server certs (such as generated by openssl req -x509) CERT_VerifyCertificateNow returns SEC_ERROR_UNTRUSTED_ISSUER in that case so, see if the cert and issuer are the same cert, and allow the use of it (with a warning) This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6588) Change log not up to date on www.openldap.org
by Kurt＠OpenLDAP.org 13 Jul '10

13 Jul '10

On Jul 13, 2010, at 2:39 AM, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: 2.4.23 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.14.151.50) >=20 >=20 > The page at http://www.openldap.org/software/release/changes.html only = lists > changes for the 2.4.22 release, although 2.4.23 is now released. Fixed. -- Kurt

1 0

(ITS#6588) Change log not up to date on www.openldap.org
by jonathan＠phillipoux.net 13 Jul '10

13 Jul '10

Full_Name: Jonathan Clarke Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.14.151.50) The page at http://www.openldap.org/software/release/changes.html only lists changes for the 2.4.22 release, although 2.4.23 is now released. This should be updated, I guess! In the mean time, changes can be consulted here: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/Attic/CHANGES?rev=1.5.1…

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 12 Jul '10

12 Jul '10

Can somebody take a look at this issue. Note that the issue here is with close() being called from ldap_unbind_s with fd = (-1). Please read the first line in my original bug description email as: This is a consulation bug for clarification on close() being called from ldap_unbind_s with fd = -1.

1 0

Re: (ITS#6587) lconn_refcnt is not thread-safe
by hyc＠symas.com 10 Jul '10

10 Jul '10

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.22 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.113.184.10) > > > lconn_refcnt is read and written without any sync mechanism, which may cause > subtle multi-threading issues. You're mistaken. ld->ld_res_mutex is owned in all cases where lc->lconn_refcnt is touched. > E.g. libldap/result.c -r1.172 > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > rc = try_read1msg( ld, msgid, all, lc, result ); > lnext = lc->lconn_next; > /* Only take locks if we're really freeing */ > if ( lc->lconn_refcnt<= 1 ) { > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_req_mutex ); > #endif > ldap_free_connection( ld, lc, 0, 1 ); > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6587) lconn_refcnt is not thread-safe
by test.007＠seznam.cz 09 Jul '10

09 Jul '10

Full_Name: Test Seven Version: 2.4.22 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.113.184.10) lconn_refcnt is read and written without any sync mechanism, which may cause subtle multi-threading issues. E.g. libldap/result.c -r1.172 #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif rc = try_read1msg( ld, msgid, all, lc, result ); lnext = lc->lconn_next; /* Only take locks if we're really freeing */ if ( lc->lconn_refcnt <= 1 ) { #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex ); #endif ldap_free_connection( ld, lc, 0, 1 );

1 0

(ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 01 Jul '10

01 Jul '10

Full_Name: Christian Manal Version: 2.4.21 OS: SunOS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30dd:221:85ff:fe3f:1775) I have noticed a problem regarding ExOp PASSMOD and chaining in my OpenLDAP environment. Maybe some of the other overlays are doing their part in this as well. Password changes started behaving weird at some point: When a slave runs for a few days and some user tries to change his password, the change is done in the local database only (no chaining done or referral returned), resulting in an inconsistent database between the slave and all the other servers. That way logging in to services which connect to the LDAP servers in a round-robin fashion sometimes works with the "new" password and sometimes with the old one. After I restart the slapd on the slaves, everything works again for a few days, before it goes bad again. Every other write gets chained just fine when a slave is in this condition. It's only the PASSMOD operations that are stuck. I have one master and four slaves running on Solaris 10. One of them SPARC, the others x86. Software Versions are: OpenLDAP 2.4.21 BDB 4.8.26 Cyrus SASL 2.1.23 Heimdal Kerberos 1.3.3 All the configs and the sourcecode of my self-made pwdCheckModule for ppolicy can be found here: http://www.informatik.uni-bremen.de/~moenoel/ldap/ As pointed out by Pierangelo Masarati, this may be the same issue as reported here: <http://www.openldap.org/lists/openldap-technical/201003/msg00019.html> Regards, Christian Manal

1 0

(ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 01 Jul '10

01 Jul '10

Full_Name: Asif Iqbal Desai Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.214.64.6) This is a consulation bug for clarification on close() being called from ldap_unbind_s with fd = 1. The application uses ldap client apis for user authentication. We recently upgraded to use OpenLDAP version 2.4.16 and are getting an unexpected AIO error issue when ldap user authentication is enabled. Investigating further revealed that from ldap_unbind_s ( close(-1) is getting called. However the close function of solaris libaio does a special handling when fd < 0 which causes AIO errors. The application needs solaris aio support and hence cannot link libc before libaio. Is there any specific reason for close being called with fd = -1 from ldap_unbind_s. This issue didnot exist with OpenLDAP 2.3.27. Following is the stacktrace: [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7f406a64 [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21eafc [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21e160 [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, 0xd), at 0xffffffff7d21cebc [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at 0xffffffff7d26a4bc [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, 0x100121a00), at 0xffffffff7d26a048 [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, 0x0, 0x100117728), at 0xffffffff7d26a55c ... ... Thanks in Advance, Asif Iqbal Desai

1 0

Re: ( ITS#6580)
by gianluigi.nigro＠passepartout.sm 01 Jul '10

01 Jul '10

I think that is right for new implementations, but should be guaranteed compatibility with the old interface (netscape slapi plugin). The patch serves only this purpose (and I have a set of extended operations written through that interfaces that I want to carry on openldap). -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato puo contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti.

1 0

RE: intent of pwdGraceAuthNLimit when using ppolicy overlay
by Licause, Al 30 Jun '10

30 Jun '10

I have been attempting to use the ppolicy overlay on an openldap server running on a Red Hat V5.4 platform with the following components: openldap-servers-2.3.43-3.el5 checkpassword-ldap-0.01-1.2.el5.rf mozldap-6.0.5-1.el5 openldap-2.3.43-3.el5 openldap-debuginfo-2.3.43-3.el5 nss_ldap-253-22.el5_4 openldap-clients-2.3.43-3.el5 openldap-servers-overlays-2.3.43-3.el5 I was unable to get the users password to expire by simply setting a value for pwdMaxAge without the use of the pwdReset parameter. I finally turned on all debugging in the slapd.conf file (value -1) and noticed that the value of pwdGraceAuthNLimit in the default policy, was set to 3, which allowed the ldap user access without changing the password. The disturbing thing about this was the fact that the user is not notifed that their password has expired. I would have thought that if the intent was to allow an expired password, then the user should be notified of not only the fact that their password has expired but how many more grace logins they would be allowed before either having to change the password or having the account disabled. Is this really what development had intended or are there some enhancements to this behavior in a later version ? Thanks, Al Licause HP Services Unix Network Team

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Yet good for me ... Program source : m_connectForm->getLdapHandle()->doModifyEntries( entry( "dc=mydomain", attribute("userPassword", LDAP_MOD_ADD ) ) ); -> ... Debugger trace on breakPoint: this->m_connectForm->getLdapHandle()->getErrorNumber() = 2,, this->m_connectForm->getLdapHandle()->getErrorString() = "Protocol error", Regards, PE Le samedi 26 juin 2010 à 04:46 +0200, masarati(a)aero.polimi.it a écrit : > > Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... > > Nothing to hurry about, but I had to change the fix (not related to the > issue you reported). No strict need to test again. > > p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 25 Jun '10

25 Jun '10

> Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Nothing to hurry about, but I had to change the fix (not related to the issue you reported). No strict need to test again. p.

1 0

Re: R: ITS#6580
by masarati＠aero.polimi.it 25 Jun '10

25 Jun '10

> Hi, > the issue is that in release 2.4.21 is not possible execute an exended > operation registered in a plugin: THIS way doesnt work because slapd (in > extended.c fe_extended(), line 199) only look for built-in extended > operations and not plugin-defined extended operations (in a plugin calling > slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and SLAPI_EXT_OP_RET_VALUE). > > In fe_extended() I tried to extend the search to all extended operations > and now things start to work, but the main question concerns the choice of > backend. > > Uploaded files: > > servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch > servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch I think this approach is not correct, in many senses. First of all, you should use the native API instead of SLAPI. In fact, SLAPI is essentially unsupported. It was intended to give the possibility to somehow recycle software coded according to Netscape's API, but there's little point in developing new code based on that interface. Second, the whole purpose of implementing the slapi overlay was to avoid the pervasive presence of #ifdef LDAP_SLAPI in baseline code. So a more appropriate approach would be to have the slapi overlay register the extended operation using the native API, rather than having #ifdef LDAP_SLAPI in extended.c to check that any extop was loaded using SLAPI, as in gianluigi.nigro1-100625.patch. I can't say anything about gianluigi.nigro2-100625.patch because the file looks corrupted. p.

1 0

R: ITS#6580
by gianluigi.nigro＠passepartout.sm 25 Jun '10

25 Jun '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it]=20 Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p. -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato pu=F2 contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>R: ITS#6580</TITLE> </HEAD> <BODY>  <P><FONT SIZE=3D2>Hi,<BR> the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE).<BR> <BR> In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend.<BR> <BR> Uploaded files:<BR> <BR> servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch<BR> servers-slapd-slapi-slapi_overlay.patch -> = gianluigi.nigro2-100625.patch<BR> <BR> -----Messaggio originale-----<BR> Da: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >]<BR> Inviato: mercoled=EC 23 giugno 2010 00:36<BR> A: Gianluigi Nigro<BR> Cc: openldap-its(a)openldap.org<BR> Oggetto: ITS#6580<BR> <BR> No clue about the slapi way, but extended operations can be = successfully<BR> registered using OpenLDAP's native API, load_extop2().  See for = example<BR> overlays/dds.c<BR> <BR> p.<BR> <BR> <BR> </FONT> </P>  <p> </p> <br><hr color=3D'#D2D3D2' noshade> <font size=3D"1">Il contenuto di questo messaggio di posta elettronica e = ogni eventuale documento a quest'ultimo allegato pu=F2 contenere = informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente = agli effettivi destinatari i quali prendono atto del carattere non = strettamente personale dei messaggi di risposta, che potranno essere = noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso = di questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti.</font><br></body></html> ------_=_NextPart_001_01CB14A1.5852206C--

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Thanks, PE Le jeudi 24 juin 2010 à 19:27 +0200, masarati(a)aero.polimi.it a écrit : > The error is in the server: for this specific error, no response is > returned to the client. It is now fixed in HEAD, please test. Thanks, p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 24 Jun '10

24 Jun '10

The error is in the server: for this specific error, no response is returned to the client. It is now fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 4:03 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > > Note: this comes in the form of: > > olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top > AUXILIARY MAY > ( dgIdentity $ dgAuthz ) ) > > > in dyngroup overlay (it lets you specify the internal identity to use for > the searches/auth identity). Never mind, browsing the dynlist code, I see this is implemented in there. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org wrote: Note: this comes in the form of: olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY ( dgIdentity $ dgAuthz ) ) in dyngroup overlay (it lets you specify the internal identity to use for the searches/auth identity). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

Full_Name: Quanah Gibson-Mount Version: 2.4.22 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When dynlist expands the group membership from a URI statement, it applies the bind identity to the search to expand it. This does not conform to the dyngroup behavior as was requested. Instead, dynlist should allow expansion by doing an internal search on the specified URI value, so that the binding identity is not required to have "compare" access on the attributes making up the query. This was implemented in dyngroup for security purposes, and those reasons still apply. --Quanah

1 0

(ITS#6583) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6582) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

ITS#6580
by masarati＠aero.polimi.it 22 Jun '10

22 Jun '10

No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p.

1 0

(ITS#6580) slapi extended operation not executed
by gianluigi.nigro＠passepartout.sm 22 Jun '10

22 Jun '10

Full_Name: gianluigi nigro Version: 2.4.21 OS: Linux CentOS release 5.5 ( i686) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.186.39.1) An extended operation with slapi plugin does not work, it is never executed because slapd doesnt look for an extended operation registered in a plugin (debugging slapd i verified that the list struct extop_list -extended.c, function find_extop, line 208 - contains only built-in extended operation). 1) The initialization function look like this: char** oids = (char**) slapi_ch_malloc( 2 * sizeof( char * ) ); oids[0] = 1.3.6.1.4.1.35746.2.11.1"; oids[1] = NULL; i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_OIDLIST, oids ); if( i_ret == 0 ) i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_FN, (void*) extop1_start ); if( i_ret != 0 ) slapi_log_error( SLAPI_LOG_PLUGIN, "extop1_init", "[ERROR] registrazione %s\n", pluginDescription.spd_description ); 2) slapd.conf look like this: ... pluginlog /var/log/caronte/plugin.log plugin extendedop /opt/ldap/slapi/libextop1-plugin.so extop1_init ... After server restart: a) the log file plugin.log tell me that the plugin was successfully registered: ... 06/17/10 10:43:53 plugin_pblock_new: Registered plugin my-plugin 0.1 [mycompany] (description plugin) ... b) and the rootDSE object contains information about my extended operation, an 'ldapsearch -x -s base -b "" "(objectclass=*)" +' output like this: ... supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.35746.2.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 But, when i perform the extended operation, no plugin is executed and i get the error code 2 and the slapd log file look like this: Jun 17 09:53:03 linux-setup slapd[11969]: conn=1000 op=1 EXT oid=1.3.6.1.4.1.35746.2.11.1 Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 do_extended: unsupported operation "1.3.6.1.4.1.35746.2.11.1" Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 RESULT tag=120 err=2 text=unsupported extended operation Is it a bug or a lack of implementation?

1 0

Re: (ITS#6579) syncrepl lost in refreshAndPersist mode
by quanah＠zimbra.com 21 Jun '10

21 Jun '10

--On Monday, June 21, 2010 7:42 AM +0000 haller(a)efrei.fr wrote: > Full_Name: Nicolas Haller > Version: 2.4.22 > OS: FreeBSD 8.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:7a8:1:15::143) > > > Hi, > > I have a master LDAP server and two slaves. The slaves use syncrepl in > refreshAndPersist mode. > > it's working until I see the message "connection_read(128): no > connection!" in a slave log file. Here, I must restart the slave slapd to > force the slave to be syncronized. > > I post the syncrepl slave conf: > > syncrepl rid=1 > provider=ldap://ldap-master.blah.net > type=refreshAndPersist > interval=00:00:05:00 > retry="30 +" > searchbase="dc=blah,dc=net" > schemachecking=on > bindmethod=simple > binddn="cn=root,dc=blah,dc=net" > credentials=blahblah It sounds like you have a device between the master and the replicas that cuts the connection after some period of time. If the operating system supports it, you can set a tcp keepalive in the sycnrepl configuration block in 2.4.22. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6579) syncrepl lost in refreshAndPersist mode
by haller＠efrei.fr 21 Jun '10

21 Jun '10

Full_Name: Nicolas Haller Version: 2.4.22 OS: FreeBSD 8.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:7a8:1:15::143) Hi, I have a master LDAP server and two slaves. The slaves use syncrepl in refreshAndPersist mode. it's working until I see the message "connection_read(128): no connection!" in a slave log file. Here, I must restart the slave slapd to force the slave to be syncronized. I post the syncrepl slave conf: syncrepl rid=1 provider=ldap://ldap-master.blah.net type=refreshAndPersist interval=00:00:05:00 retry="30 +" searchbase="dc=blah,dc=net" schemachecking=on bindmethod=simple binddn="cn=root,dc=blah,dc=net" credentials=blahblah thanks, Nicolas Haller

1 0

(ITS#6578) Mailman subscribtion answer update
by daniel＠pluta.biz 19 Jun '10

19 Jun '10

Full_Name: Daniel Pluta Version: NULL OS: MS-DOS URL: http://www.openldap.org/lists/openldap-software/201005/msg00096.html Submission from: (NULL) (2001:470:9feb:ff02:b173:4a10:490:24af) As the OpenLDAP-software mailinglist has been shutdown Mailman's subscribtion auto answer should perhaps be updated to mention OpenLDAP-technical instead of OpenLDAP-software... For example openldap-devel's current answer is: "... Discussions regarding the use of the software, including use of provided SDKs, should be directed to the OpenLDAP-software mailing list. ..."

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by michael＠stroeder.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. We had this request many times before. And similar the one to avoid base64-encoding of non-ASCII chars. IMO LDIF should simply comply to RFC 2849. There are enough decent LDIF parser modules out there for one of your favourite scripting languages. OpenLDAP should not support half-baked LDIF parsing. Ciao, Michael.

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by hyc＠symas.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: * > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. This is a duplicate of ITS#4269, #6149, and probably a few others. Closing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6577) OL failes to delete valid entries
by quanah＠zimbra.com 17 Jun '10

17 Jun '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When running test008 in a loop, it will occasionally fail. Investigation shows that it fails to delete an entry known to exist in the database: Here we can see a search that finds the entry: conn=1028 op=433 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(cn=james*)" conn=1028 op=433 SRCH attr=cn sn => hdb_search bdb_dn2entry("dc=example,dc=com") search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 => hdb_dn2idl("dc=example,dc=com") => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_substring_candidates (cn) => key_read bdb_idl_fetch_key: [0d554a2b] <= bdb_index_read 4 candidates <= bdb_substring_candidates: 4, first=12, last=148 bdb_search_candidates: id=4 first=12 last=148 => send_search_entry: conn 1028 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" ber_flush2: 157 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 4,ou=People,dc=example,dc=com" ber_flush2: 122 bytes to sd 34 <= send_search_entry: conn 1028 exit. A few lines further, this entry is deleted: => send_search_entry: conn 1049 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 47 bytes to sd 29 ber_flush2: 146 bytes to sd 32 <= send_search_entry: conn 1056 exit. send_ldap_result: conn=1056 op=289 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=290 tag=101 err=0 ber_flush2: 15 bytes to sd 29 conn=1056 op=289 SEARCH RESULT tag=101 err=0 nentries=1 text= bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") <=- hdb_delete: no such object cn=James A Jones 4,ou=People,dc=example,dc=com send_ldap_result: conn=1002 op=44 p=3 send_ldap_result: err=10 matched="ou=People,dc=example,dc=com" text="" send_ldap_response: msgid=45 tag=107 err=32 ber_flush2: 41 bytes to sd 14 The resulting diff show the entry still exists in the generated database: [root@build01 tests]# diff -u testrun/ldapsearch.flt testrun/ldif.flt --- testrun/ldapsearch.flt 2010-06-17 16:12:41.000000000 -0700 +++ testrun/ldif.flt 2010-06-17 16:12:41.000000000 -0700 @@ -308,25 +308,6 @@ facsimileTelephoneNumber: +1 313 555 8688 telephoneNumber: +1 313 555 7334 -dn: cn=James A Jones 4,ou=People,dc=example,dc=com -objectClass: OpenLDAPperson -cn: James A Jones 4 -cn: James Jones -cn: Jim Jones -sn: Jones -uid: jaj -postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 -seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -userPassword:: OiBhbUZx -homePostalAddress: 3882 Beverly Rd. $ Anytown, MI 48105 -homePhone: +1 313 555 4772 -description: Outstanding -title: Mad Cow Researcher, UM Alumni Association -pager: +1 313 555 3923 -mail: jaj(a)mail.alumni.example.com -facsimileTelephoneNumber: +1 313 555 4332 -telephoneNumber: +1 313 555 0895 - dn: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Jane Doe

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 17 Jun '10

17 Jun '10

--Apple-Mail-174--9407050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Daniel and Quanah. > I've tested your patch against HEAD and there seems to be a bug left = open within (or even newly introduced by?) your patch: > I've added Quanah into cc as his Call for 2.4.43RE testing seems to = depend on this ITS. > *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): = invalid pointer: 0x09d507d8 *** Heh, oops. Extra & in the add case for one of the attributes. Sorry = for the noise. See attached patch. Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-174--9407050 Content-Disposition: attachment; filename=its-6572-amendment.txt Content-Type: text/plain; x-unix-mode=0644; name="its-6572-amendment.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.19.2.14 diff -u -r1.19.2.14 refint.c --- refint.c 13 Jun 2010 17:38:37 -0000 1.19.2.14 +++ refint.c 17 Jun 2010 18:04:18 -0000 @@ -263,8 +263,8 @@ break; case REFINT_MODIFIERSNAME: if ( !BER_BVISNULL( &c->value_ndn )) { - ch_free( &dd->refint_dn.bv_val ); - ch_free( &dd->refint_ndn.bv_val ); + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); dd->refint_dn = c->value_dn; dd->refint_ndn = c->value_ndn; rc = 0; --Apple-Mail-174--9407050--

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 17 Jun '10

17 Jun '10

Hi Matthew, I've tested your patch against HEAD and there seems to be a bug left open within (or even newly introduced by?) your patch: I've added Quanah into cc as his Call for 2.4.43RE testing seems to depend on this ITS. Executive summary: ;-) ====================== *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** Technical details: ;-) ====================== If I remove the following refint configuration directive from cn=config's refint-ldif file: olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar slaptest & slapd both startup fine. If the above statement is contained in the current configuration it results in an "invalid pointer" crash during slaptest and also during slapd startup (see below)... Cheers Daniel ldif_read_file: read entry file: "slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={4}refint.ldif" => str2entry: "dn: olcOverlay={4}refint objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {4}refint olcRefintAttribute: secretary olcRefintAttribute: manager olcRefintAttribute: roleOccupant olcRefintAttribute: member olcRefintAttribute: memberOf olcRefintAttribute: owner olcRefintNothing: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc= bar olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar structuralObjectClass: olcRefintConfig entryUUID: ac810092-0b82-102f-9080-ed6f5f0ebf63 creatorsName: cn=config createTimestamp: 20100613215924Z entryCSN: 20100614121813.528580Z#000000#000#000000 modifiersName: cn=ldapmanager,cn=config modifyTimestamp: 20100614121813Z " >>> dnPrettyNormal: <olcOverlay={4}refint> <<< dnPrettyNormal: <olcOverlay={4}refint>, <olcOverlay={4}refint> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=ldapmanager,cn=config> <<< dnPretty: <cn=ldapmanager,cn=config> >>> dnNormalize: <cn=ldapmanager,cn=config> <<< dnNormalize: <cn=ldapmanager,cn=config> <= str2entry(olcOverlay={4}refint) -> 0x9cd6a04 >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6(+0x6b321)[0xb735c321] /lib/i686/cmov/libc.so.6(+0x6cb78)[0xb735db78] /lib/i686/cmov/libc.so.6(cfree+0xAborted Matthew Backes schrieb: > Here's a patch that fixes 6572. > > * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead > * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) > * Should apply cleanly to RE24 and HEAD > * Older dyn-config refints (RE22, RE23) likely have the same problem > > Matthew Backes > Symas Corporation > mbackes(a)symas.com > >

1 0

(ITS#6576) Feature Request: logging actions by a particular ip/dn to a particular file/facility
by marco.pizzoli＠gmail.com 17 Jun '10

17 Jun '10

Full_Name: Marco Pizzoli Version: * OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) This is a feature request. I would like to log some particular remote IP address and/or some particular binddn activity to a special file and/or to some specific syslog facility. This would help me in case of debug of clients configuration. Thanks Marco Pizzoli

1 0

(ITS#6575) Feature Request: ldapsearch ldif export without wrap
by marco.pizzoli＠gmail.com 17 Jun '10

17 Jun '10

Full_Name: Marco Pizzoli Version: * OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) This is a feature request. I would like tools like ldapsearch have an option to produce a LDIF export without wrapping to the next row when the dn is too long. Thanks Marco Pizzoli

1 0

(ITS#6574) back-meta does not rebind as user when retrying
by masarati＠aero.polimi.it 15 Jun '10

15 Jun '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.2) Submitted by: ando While retrying, back-meta destroys the failed connection to a remote target, and re-creates it. However, it loses the credentials, while restoring the bound DN. As a consequence, the connection looks bound, but it's actually anonymous. A fix is coming. The fix either preserves the credentials, when rebind-as-user is set, or turns the connection into anonymous. The latter case is of little practical use, and should only be used in conjunction with idassert, so that in case of retry, from that point on identity is asserted. p.

1 0

Re: (ITS#6571) rebind-as-user only works on first connection attempt
by masarati＠aero.polimi.it 15 Jun '10

15 Jun '10

> Full_Name: Marcel Wysocki > Version: 2.4.22 > OS: Solaris/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.79.126.162) > > > Hello, > > i have the same problem as described here: > http://www.openldap.org/lists/openldap-software/200712/msg00283.html > > here are some logs: > > @(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $ > slapd starting > > Initial connection: > ########################## > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389) > conn=1000 op=0 BIND > dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > method=128 > conn=1000 op=0 BIND > dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > mech=SIMPLE ssf=0 > conn=1000 op=0 RESULT tag=97 err=0 text= > ########################## > > First ldapsearch: > ########################## > conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=2 SRCH attr=objectclass > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= > ########################## > > backend server has been restarted, sencond ldapsearch: > ########################## > conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=3 SRCH attr=objectclass > conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= > ########################## > > backend server has been stopped, third ldapsearch, fails as it should: > ########################## > conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=4 SRCH attr=objectclass > conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text= > ########################## > > backend server has been restarted, fourth ldapsearch, rebind fails: > ########################## > conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=5 SRCH attr=objectclass > conn=1000 op=5 ldap_back_dobind_int: > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds, > binding anonymously > conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= > ########################## > > following the configuration for back-ldap: > > database ldap > suffix "o=bazbaz" > uri ldap://10.2.163.13:389 > rootdn "cn=PEX,o=bazbaz" > rootpw secret > idle-timeout 301 > rebind-as-user yes > single-conn yes > chase-referrals no > acl-bind bindmethod=simple > binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > credentials=supersecret I don't clearly see why you consider this behavior incorrect. As soon as the client receives a err=52 (LDAP_UNAVAILABLE), the connection is compromised. Back-ldap destroys the cached connection, since it does not work. As a consequence, the related credentials are forgotten. The client should give up, as the proxy already retried and failed (if it succeeded, the whole point would be moot, as the client wouldn't even know that the connection between the proxy and the remote server was broken). p.

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 13 Jun '10

13 Jun '10

--0050450171a831aa7e0488f30c72 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 13, 2010 at 5:20 PM, Howard Chu <hyc(a)symas.com> wrote: > Mark A. Ziesemer wrote: > >> On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> >> online(a)mark.ziesemer.com <mailto:online@mark.ziesemer.com> wrote: >> >> Full_Name: Mark A. Ziesemer >> Version: 2.4.21 >> OS: Ubuntu Linux 10.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) >> >> >> Many "connection_read(): no connection!" warnings are written to >> /var/log/debug >> and /var/log/syslog by slapd. As stated at >> >> http://www.openldap.org/lists/openldap-software/200811/msg00079.html , >> this is >> apparently not a problem with slapd, but a client that is >> disconnecting without >> first unbinding. >> >> >> This also happens when the connection manager queues up a thread to >> handle >> a "socket is readable" event on a socket that's in the process of >> closing. >> Pretty much unavoidable, when a lot of threads are active. I don't see >> this as a high enough priority to warrant fixing. >> >> >> This was not happening under a high load, but with only 1-2 connections >> active. >> >> I might not have focused on it enough in the original report, but isn't >> this >> looking like it is probably an issue with the libldap client library >> (provided >> by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, >> it >> appears that no do_unbind request is received (not sent by the client) >> when >> using ldapi:/// with a bind DN. >> >> If it can't / won't be fixed, can the logging of the "connection_read(): >> no >> connection!" event in slapd at least be demoted to a lower level so that >> it >> doesn't fill the default logging output, without having to change the >> overall >> configured logging level and potentially missing other logged events that >> do >> require attention? >> > > "Fixing" libldap, if there's even a bug there, obviously won't help with > other clients using non-OpenLDAP libraries. At any rate, there's nothing > that requires an Unbind request to be sent, so there's no bug here. > As stated by one of the other OpenLDAP engineers in the above link, the recommendation was to "fix whatever client is disconnecting without unbinding". In this case, the client is the OpenLDAP libraries. Please at least re-consider for fixing, even in a "help wanted" or "pending" status, rather than just closing. Either the client library should be fixed to send an unbind before disconnecting in all circumstances (i.e. ldapi:/// as well as ldap:///), or it should be confirmed and documented that the unbind is not necessary, in which case the server should be fixed to not output the "connection_read(): no connection!" events at the default logging level. I don't see messages filling the log. I don't see any issue here at all. > I'm not the only one seeing this. My link to the OpenLDAP mailing list above, as well as Gergely's inquiry into this ITS are 2 directly related occurrences observed by others. I was only able to reproduce this by performing a Bind with invalid > credentials. In the case with correct credentials, there were no extraneous > messages. If you're seeing a lot of these cases, then you should think about > why you're getting a lot of Binds with invalid passwords. Fix the problem, > not the symptom. This ITS will be closed. While this may be true, in any production environment, you can almost be guaranteed that there will be login attempts with invalid credentials - even just due to users mistyping their password on occasion, using CAPS lock, etc. Again, the log entry should either be suppressed at the default logging level (preferred), or at least re-worded to something more meaningful, e.g. "Received invalid login attempt; disconnecting client". However, even then, this should be made to work the same regardless of protocol used for consistency. This may not be a high priority or interesting issue to fix, but please don't simply ignore what seems to be a very reasonable request. If this issue is not addressed, the effect becomes training other users and admins to ignore the logs if they regularly contain trivial updates at the default level - which I hope we can agree is not a good practice. This appears to be an issue with the libldap client library provided > by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", > but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 > sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle > pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" > sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): > > slap_listener(ldap:///) > > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Mark A. Ziesemer www.ziesemer.com --0050450171a831aa7e0488f30c72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">On Sun, Jun 13, 2010 at 5:20 PM, Howard Chu = <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&gt= ;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0= pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;= "> Mark A. Ziesemer wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"im"= > On Wed, May 12, 2010 at 10:05 AM, Howard Chu <<a href=3D"mailto:hyc@syma= s.com" target=3D"_blank">hyc(a)symas.com</a><br></div> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote:<div><div></div><div class=3D"h5"><br> <br> =A0 =A0<a href=3D"mailto:online@mark.ziesemer.com" target=3D"_blank">onlin= e(a)mark.ziesemer.com</a> <mailto:<a href=3D"mailto:online@mark.ziesemer.c= om" target=3D"_blank">online(a)mark.ziesemer.com</a>> wrote:<br> <br> =A0 =A0 =A0 =A0Full_Name: Mark A. Ziesemer<br> =A0 =A0 =A0 =A0Version: 2.4.21<br> =A0 =A0 =A0 =A0OS: Ubuntu Linux 10.04<br> =A0 =A0 =A0 =A0URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D= "_blank">ftp://ftp.openldap.org/incoming/</a><br> =A0 =A0 =A0 =A0Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:e= e3d)<br> <br> <br> =A0 =A0 =A0 =A0Many "connection_read(): no connection!" warnings= are written to<br> =A0 =A0 =A0 =A0/var/log/debug<br> =A0 =A0 =A0 =A0and /var/log/syslog by slapd. =A0As stated at<br> =A0 =A0 =A0 =A0<a href=3D"http://www.openldap.org/lists/openldap-software/= 200811/msg00079.html" target=3D"_blank">http://www.openldap.org/lists/openl= dap-software/200811/msg00079.html</a> ,<br> =A0 =A0 =A0 =A0this is<br> =A0 =A0 =A0 =A0apparently not a problem with slapd, but a client that is<b= r> =A0 =A0 =A0 =A0disconnecting without<br> =A0 =A0 =A0 =A0first unbinding.<br> <br> <br> =A0 =A0This also happens when the connection manager queues up a thread to= handle<br> =A0 =A0a "socket is readable" event on a socket that's in th= e process of closing.<br> =A0 =A0Pretty much unavoidable, when a lot of threads are active. I don&#3= 9;t see<br> =A0 =A0this as a high enough priority to warrant fixing.<br> <br> <br> This was not happening under a high load, but with only 1-2 connections act= ive.<br> <br> I might not have focused on it enough in the original report, but isn't= this<br> looking like it is probably an issue with the libldap client library (provi= ded<br> by OpenLDAP), rather than the slapd daemon? =A0Looking at the provided logs= , it<br> appears that no do_unbind request is received (not sent by the client) when= <br> using ldapi:/// with a bind DN.<br> <br> If it can't / won't be fixed, can the logging of the "connecti= on_read(): no<br> connection!" event in slapd at least be demoted to a lower level so th= at it<br> doesn't fill the default logging output, without having to change the o= verall<br> configured logging level and potentially missing other logged events that d= o<br> require attention?<br> </div></div></blockquote> <br> "Fixing" libldap, if there's even a bug there, obviously won&= #39;t help with other clients using non-OpenLDAP libraries. At any rate, th= ere's nothing that requires an Unbind request to be sent, so there'= s no bug here.<br> </blockquote><div><br>As stated by one of the other OpenLDAP engineers in t= he above link, the recommendation was to "fix whatever client is disco= nnecting without unbinding".=A0 In this case, the client is the OpenLD= AP libraries.=A0 Please at least re-consider for fixing, even in a "he= lp wanted" or "pending" status, rather than just closing.=A0= Either the client library should be fixed to send an unbind before disconn= ecting in all circumstances (i.e. ldapi:/// as well as ldap:///), or it sho= uld be confirmed and documented that the unbind is not necessary, in which = case the server should be fixed to not output the "connection_read(): = no connection!" events at the default logging level. <br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.= 8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I don't see messages filling the log. I don't see any issue here at= all.<br></blockquote><div><br>I'm not the only one seeing this.=A0 My = link to the OpenLDAP mailing list above, as well as Gergely's inquiry i= nto this ITS are 2 directly related occurrences observed by others. <br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.= 8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I was only able to reproduce this by performing a Bind with invalid credent= ials. In the case with correct credentials, there were no extraneous messag= es. If you're seeing a lot of these cases, then you should think about = why you're getting a lot of Binds with invalid passwords. Fix the probl= em, not the symptom. This ITS will be closed.</blockquote> <div class=3D"h5">=A0<br>While this may be true, in any production environm= ent, you can almost be guaranteed that there will be login attempts with in= valid credentials - even just due to users mistyping their password on occa= sion, using CAPS lock, etc.=A0 Again, the log entry should either be suppre= ssed at the default logging level (preferred), or at least re-worded to som= ething more meaningful, e.g. "Received invalid login attempt; disconne= cting client".=A0 However, even then, this should be made to work the = same regardless of protocol used for consistency.<br> <br>This may not be a high priority or interesting issue to fix, but please= don't simply ignore what seems to be a very reasonable request.=A0 If = this issue is not addressed, the effect becomes training other users and ad= mins to ignore the logs if they regularly contain trivial updates at the de= fault level - which I hope we can agree is not a good practice.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> =A0 =A0 =A0 =A0This appears to be an issue with the libldap client library= provided<br> =A0 =A0 =A0 =A0by OpenLDAP<br> =A0 =A0 =A0 =A0itself (2.4.21), and not the slapd daemon.<br> <br> =A0 =A0 =A0 =A0Issue is reproducible even by just using "ldapsearch -= H ldapi:///",<br> =A0 =A0 =A0 =A0but only if<br> =A0 =A0 =A0 =A0a bind DN is specified (-D) and external authentication is = not used.<br> <br> =A0 =A0 =A0 =A0Running slapd with logging enabled (-d 8) shows the followi= ng 3<br> =A0 =A0 =A0 =A0sequences -<br> =A0 =A0 =A0 =A0ldapsearch command followed by the slapd logs. =A0Note that= the<br> =A0 =A0 =A0 =A0"connection_read(): no connection!" is only visib= le on the middle pair.<br> <br> <br> =A0 =A0 =A0 =A0$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ""<= br> =A0 =A0 =A0 =A0SASL/EXTERNAL authentication started<br> =A0 =A0 =A0 =A0SASL username: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn= =3Dexternal,cn=3Dauth<br> =A0 =A0 =A0 =A0SASL SSF: 0<br> =A0 =A0 =A0 =A0No such object (32)<br> <br> =A0 =A0 =A0 =A0slap_listener_activate(9):<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldapi:///)<br> <br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 24 contents:<br> =A0 =A0 =A0 =A0op tag 0x60, time 1273546410<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0conn=3D1000 op=3D0 do_bind<br> =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt ({m) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt (m) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt (}}) ber:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<><br> <br> =A0 =A0 =A0 =A0<<< =A0dnPrettyNormal:<>,<><br> =A0 =A0 =A0 =A0do_bind: dn () SASL mech EXTERNAL<br> =A0 =A0 =A0 =A0=3D=3D>slap_sasl2dn: converting SASL name<br> =A0 =A0 =A0 =A0gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth to a DN<br> =A0 =A0 =A0 =A0<=3D=3Dslap_sasl2dn: Converted SASL name to<nothing&g= t;<br> =A0 =A0 =A0 =A0SASL Authorize [conn=3D1000]: =A0proxy authorization allowe= d authzDN=3D""<br> =A0 =A0 =A0 =A0send_ldap_sasl: err=3D0 len=3D-1<br> =A0 =A0 =A0 =A0do_bind: SASL/EXTERNAL bind:<br> =A0 =A0 =A0 =A0dn=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3De= xternal,cn=3Dauth" sasl_ssf=3D0<br> =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D0<br> =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14<br> =A0 =A0 =A0 =A0<=3D=3D slap_sasl_bind: rc=3D0<br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 37 contents:<br> =A0 =A0 =A0 =A0op tag 0x63, time 1273546410<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0conn=3D1000 op=3D1 do_search<br> =A0 =A0 =A0 =A0ber_scanf fmt ({miiiib) ber:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<><br> <br> =A0 =A0 =A0 =A0<<< =A0dnPrettyNormal:<>,<><br> =A0 =A0 =A0 =A0ber_scanf fmt (m) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt ({M}}) ber:<br> =A0 =A0 =A0 =A0send_ldap_result: conn=3D1000 op=3D1 p=3D3<br> =A0 =A0 =A0 =A0send_ldap_response: msgid=3D2 tag=3D101 err=3D32<br> =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14<br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 5 contents:<br> =A0 =A0 =A0 =A0op tag 0x42, time 1273546410<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0conn=3D1000 op=3D2 do_unbind<br> =A0 =A0 =A0 =A0connection_close: conn=3D1000 sd=3D14<br> <br> =A0 =A0 =A0 =A0$ ldapsearch -H ldapi:/// -D "cn=3Dadmin,dc=3Dexample,= dc=3Dcom" -b "" -W<br> =A0 =A0 =A0 =A0Enter LDAP Password:<br> =A0 =A0 =A0 =A0ldap_bind: Invalid credentials (49)<br> <br> =A0 =A0 =A0 =A0slap_listener_activate(9):<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldapi:///)<br> <br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1001<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1001<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 44 contents:<br> =A0 =A0 =A0 =A0op tag 0x60, time 1273546420<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0conn=3D1001 op=3D0 do_bind<br> =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt (m}) ber:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3D= example,dc=3Dcom><br> <br> =A0 =A0 =A0 =A0<<<<br> =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>= ,<cn=3Dadmin,dc=3Dexample,dc=3Dcom><br> =A0 =A0 =A0 =A0do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc= =3Dcom" method=3D128<br> =A0 =A0 =A0 =A0send_ldap_result: conn=3D1001 op=3D0 p=3D3<br> =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D49<br> =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14<br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1001<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1001<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next on fd 14 failed errno=3D0 (Success)<br> =A0 =A0 =A0 =A0connection_close: conn=3D1001 sd=3D14<br> =A0 =A0 =A0 =A0connection_read(14): no connection!<br> =A0 =A0 =A0 =A0connection_read(14): no connection!<br> <br> =A0 =A0 =A0 =A0$ ldapsearch -H ldap:/// -D "cn=3Dadmin,dc=3Dexample,d= c=3Dcom" -b "" -W<br> =A0 =A0 =A0 =A0Enter LDAP Password:<br> =A0 =A0 =A0 =A0ldap_bind: Invalid credentials (49)<br> <br> =A0 =A0 =A0 =A0slap_listener_activate(8):<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldap:///)<br> <br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1002<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1002<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 44 contents:<br> =A0 =A0 =A0 =A0op tag 0x60, time 1273546425<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0conn=3D1002 op=3D0 do_bind<br> =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber:<br> =A0 =A0 =A0 =A0ber_scanf fmt (m}) ber:<br> <br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3D= example,dc=3Dcom><br> <br> =A0 =A0 =A0 =A0<<<<br> =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>= ,<cn=3Dadmin,dc=3Dexample,dc=3Dcom><br> =A0 =A0 =A0 =A0do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc= =3Dcom" method=3D128<br> =A0 =A0 =A0 =A0send_ldap_result: conn=3D1002 op=3D0 p=3D3<br> =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D49<br> =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14<br> =A0 =A0 =A0 =A0connection_get(14): got connid=3D1002<br> =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1002<br> =A0 =A0 =A0 =A0ber_get_next<br> =A0 =A0 =A0 =A0ber_get_next on fd 14 failed errno=3D0 (Success)<br> =A0 =A0 =A0 =A0connection_close: conn=3D1002 sd=3D14<br> </blockquote> <br> -- <br> =A0-- Howard Chu<br> =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a><br> </div></div><br>--<br>Mark A. Ziesemer<br><a href=3D"http://www.ziesemer.co= m">www.ziesemer.com</a><br> <br> --0050450171a831aa7e0488f30c72--

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 13 Jun '10

13 Jun '10

Mark A. Ziesemer wrote: > On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > online(a)mark.ziesemer.com <mailto:online@mark.ziesemer.com> wrote: > > Full_Name: Mark A. Ziesemer > Version: 2.4.21 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) > > > Many "connection_read(): no connection!" warnings are written to > /var/log/debug > and /var/log/syslog by slapd. As stated at > http://www.openldap.org/lists/openldap-software/200811/msg00079.html , > this is > apparently not a problem with slapd, but a client that is > disconnecting without > first unbinding. > > > This also happens when the connection manager queues up a thread to handle > a "socket is readable" event on a socket that's in the process of closing. > Pretty much unavoidable, when a lot of threads are active. I don't see > this as a high enough priority to warrant fixing. > > > This was not happening under a high load, but with only 1-2 connections active. > > I might not have focused on it enough in the original report, but isn't this > looking like it is probably an issue with the libldap client library (provided > by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, it > appears that no do_unbind request is received (not sent by the client) when > using ldapi:/// with a bind DN. > > If it can't / won't be fixed, can the logging of the "connection_read(): no > connection!" event in slapd at least be demoted to a lower level so that it > doesn't fill the default logging output, without having to change the overall > configured logging level and potentially missing other logged events that do > require attention? "Fixing" libldap, if there's even a bug there, obviously won't help with other clients using non-OpenLDAP libraries. At any rate, there's nothing that requires an Unbind request to be sent, so there's no bug here. I don't see messages filling the log. I don't see any issue here at all. I was only able to reproduce this by performing a Bind with invalid credentials. In the case with correct credentials, there were no extraneous messages. If you're seeing a lot of these cases, then you should think about why you're getting a lot of Binds with invalid passwords. Fix the problem, not the symptom. This ITS will be closed. > This appears to be an issue with the libldap client library provided > by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", > but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 > sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): > > slap_listener(ldap:///) > > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by kralg＠robolution.eu 13 Jun '10

13 Jun '10

Hi! Do we have any chance that this bug will be rectified recently? I believe a communication issue like this should do taken as being important. It makes the log check a huge pain, and I don't think ,,hiding'' the log is a real solution. Thank You, Gergely Kral

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 12 Jun '10

12 Jun '10

> Here's a patch that fixes 6572. Heh, okay Quanah. This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the previous patch was = developed by me for Symas and the OpenLDAP project. I am authorized by = Symas, my employer, to release this work under the following terms. Portions Copyright 2010 Symas Corporation. Redistribution and use in source and binary forms, with or without = modification, are permitted only as authorized by the OpenLDAP Public = License. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 12 Jun '10

12 Jun '10

--Apple-Mail-322--405209956 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Here's a patch that fixes 6572. * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) * Should apply cleanly to RE24 and HEAD * Older dyn-config refints (RE22, RE23) likely have the same problem Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-322--405209956 Content-Disposition: attachment; filename=refint-patch-its-6572.txt Content-Type: text/plain; name="refint-patch-its-6572.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.46 diff -u -r1.46 refint.c --- refint.c 13 Apr 2010 20:18:25 -0000 1.46 +++ refint.c 13 Jun 2010 04:02:09 -0000 @@ -76,7 +76,6 @@ } refint_q; typedef struct refint_data_s { - const char *message; /* breadcrumbs */ struct refint_attrs_s *attrs; /* list of known attrs */ BerValue dn; /* basedn in parent, */ BerValue nothing; /* the nothing value, if needed */ @@ -210,21 +209,17 @@ rc = 0; break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing.bv_len = 0; - dd->nnothing.bv_len = 0; + ch_free( dd->nothing.bv_val ); + ch_free( dd->nnothing.bv_val ); + BER_BVZERO( &dd->nothing ); + BER_BVZERO( &dd->nnothing ); rc = 0; break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn.bv_len = 0; - dd->refint_ndn.bv_len = 0; + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); + BER_BVZERO( &dd->refint_dn ); + BER_BVZERO( &dd->refint_ndn ); rc = 0; break; default: @@ -256,22 +251,26 @@ } break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing = c->value_dn; - dd->nnothing = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free ( dd->nothing.bv_val ); + ch_free ( dd->nnothing.bv_val ); + dd->nothing = c->value_dn; + dd->nnothing = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn = c->value_dn; - dd->refint_ndn = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free( &dd->refint_dn.bv_val ); + ch_free( &dd->refint_ndn.bv_val ); + dd->refint_dn = c->value_dn; + dd->refint_ndn = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; default: abort (); @@ -299,7 +298,6 @@ slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = ch_calloc(1,sizeof(refint_data)); - id->message = "_init"; on->on_bi.bi_private = id; ldap_pvt_thread_mutex_init( &id->qmutex ); return(0); @@ -335,7 +333,6 @@ { slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = on->on_bi.bi_private; - id->message = "_open"; if ( BER_BVISNULL( &id->dn )) { if ( BER_BVISNULL( &be->be_nsuffix[0] )) @@ -354,7 +351,6 @@ ** foreach configured attribute: ** free it; ** free our basedn; -** (do not) free id->message; ** reset on_bi.bi_private; ** free our config data; ** @@ -369,7 +365,6 @@ slap_overinst *on = (slap_overinst *) be->bd_info; refint_data *id = on->on_bi.bi_private; refint_attrs *ii, *ij; - id->message = "_close"; for(ii = id->attrs; ii; ii = ij) { ij = ii->next; @@ -870,8 +865,6 @@ BackendDB *db = NULL; refint_attrs *ip; - id->message = "_refint_response"; - /* If the main op failed or is not a Delete or ModRdn, ignore it */ if (( op->o_tag != LDAP_REQ_DELETE && op->o_tag != LDAP_REQ_MODRDN ) || rs->sr_err != LDAP_SUCCESS ) --Apple-Mail-322--405209956--

1 0

(ITS#6572)
by daniel＠pluta.biz 09 Jun '10

09 Jun '10

short add-on note: any kind of modify operation on this attribute seems to crash slapd

1 0

Re: (ITS#6573) schema errors
by Kurt＠OpenLDAP.org 06 Jun '10

06 Jun '10

On Jun 6, 2010, at 8:27 PM, peychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: last > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.185.181.157) >=20 >=20 > Hi, >=20 > 1/- It seems there is one schema definition error : the "street" = attribute is > defined twice in the "domain" objectClass (cosine.schema) ... > So, the LDAP database repeat this error ; see: ldapsearch -x -b = "cn=3Dsubschema" > -s base objectclasses As far as the old RFC 1274 version of 'domain', cosine.schema is = correct. (It's not an error to list attributes multiple times in schema = descriptions. There's a number of multiple listings found in RFC = specifications of object classes.) =20 Of course, all of cosine.schema should be replaced with a new file = derived directly from RFC 4524 with non-conflicting deprecated stuff at = the end of the file or moved to cosine-old.schema file. >=20 > 2/- the attribute "internationaliSDNNumber" is defined with a "i" for = "iSDN" but > with a "I" in the "domain" objectClass definition ... (so, a compare = with no > sensitive case option must be done to find it ...) Names are case insensitive. >=20 > (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) > Regards, > Philippe EYCHART >=20

1 0

(ITS#6573) schema errors
by peychart＠mail.pf 06 Jun '10

06 Jun '10

Full_Name: Philippe EYCHART Version: last OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.185.181.157) Hi, 1/- It seems there is one schema definition error : the "street" attribute is defined twice in the "domain" objectClass (cosine.schema) ... So, the LDAP database repeat this error ; see: ldapsearch -x -b "cn=subschema" -s base objectclasses 2/- the attribute "internationaliSDNNumber" is defined with a "i" for "iSDN" but with a "I" in the "domain" objectClass definition ... (so, a compare with no sensitive case option must be done to find it ...) (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) Regards, Philippe EYCHART

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs