Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz
Howard Chu schrieb:
> The patch in the URL you specified appears to be empty.
Although I'm pretty sure I've successfully uploaded the patch as I
(think I) always check the URLs twice right after posting I just tried
to upload it again some minutes ago using the filename:
servers-slapd-schema_init_2.patch
The ftp-server let me successfully log in but does not allow me to
upload anything into /incoming:
"425 Can't build data connection: Connection refused."
Possibly this is also the cause the patch file currently seems to be
empty after your download?
I've tried the upload from different hosts and networks (IPv6 with IPv4
fallback) without success. Have not investigated in deep but I think it
does not seem to be a problem of my/our firewalls.
daniel@tingletangle:~$ ftp ftp.openldap.org
Connected to www.openldap.org.
220- OpenLDAP FTP Service
220 boole.openldap.org FTP server (Version 6.00LS) ready.
Name (ftp.openldap.org:daniel): anonymous
331 Guest login ok, send your email address as password.
Password:
230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved.
230- COPYING RESTRICTIONS APPLY, see:
230- ftp://ftp.openldap.org/COPYRIGHT
230- ftp://ftp.openldap.org/LICENSE
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd incoming
250 CWD command successful.
ftp> ascii
200 Type set to A.
ftp> put servers-slapd-schema_init_2.patch
local: servers-slapd-schema_init_2.patch remote:
servers-slapd-schema_init_2.patch
200 PORT command successful.
425 Can't build data connection: Connection refused.
ftp> quit
12 years, 7 months
(ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by jzeleny＠redhat.com
Full_Name: Jan Zeleny
Version: 2.4.23
OS: Linux
URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2
Submission from: (NULL) (209.132.186.34)
When running slapd listening on local socket (ldapi:///), clients connecting to
it will sometimes SIGPIPE when using TLS. This happens in about 70% times.
How to reproduce:
generate a pem certificate
slapd -h ldapi:///
ldapsearch -H ldapi:/// -ZZ -x -d -1
I'm attaching straces from both slapd and ldapsearch. What seems to be happening
is that slapd receives EAGAIN during the read from socket, marks it for another
read, but then terminates a reading thread and closes the connection, while
client still wants to write some data. When doing ldapsearch, it does this after
result was returned, that's why it can be seen probably only in debugging mode.
The issue was originally reported on 2.3.43, but I successfully reproduced it on
newer versions, including 2.4.23. The only exception was Fedora rawhide version
(currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR)
doesn't seem to support local sockets at all, so it is not possible to use ldapi
with -ZZ any more.
I'm attaching straces from both successful and unsuccessful run. For complete
information here is URL of relevant redhat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=564108
12 years, 7 months
(ITS#6609) Admin Guide Documentation typo's
by paul＠mawsonlakes.org
Full_Name: Paul Schulz
Version: CVS
OS: Linux/Ubuntu
URL:
Submission from: (NULL) (116.212.217.6)
Patch..
diff --git a/admin/access-control.sdf b/admin/access-control.sdf
index f18dba3..1ff6815 100644
--- a/admin/access-control.sdf
+++ b/admin/access-control.sdf
@@ -826,7 +826,7 @@ This ACL grants read permissions to authenticated users
while denying others
H3: Controlling rootdn access
-You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without
+You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without
specifying a {{rootpw}}. Then you have to add an actual directory entry with
the same dn, e.g.:
@@ -876,7 +876,7 @@ One can then grant access to the members of this this group
by adding appropriat
> by group.exact="cn=Administrators,dc=example,dc=com" write
> by * auth
-Like by {[dn}} clauses, one can also use {{expand}} to expand the group name
+Like by {{dn}} clauses, one can also use {{expand}} to expand the group name
based upon the regular expression matching of the target, that is, the to
{{dn.regex}}).
For instance,
diff --git a/admin/appendix-common-errors.sdf
b/admin/appendix-common-errors.sdf
index b285cd2..be901f1 100644
--- a/admin/appendix-common-errors.sdf
+++ b/admin/appendix-common-errors.sdf
@@ -11,7 +11,7 @@ H2: Common causes of LDAP errors
H3: ldap_*: Can't contact LDAP server
-The {[B:Can't contact LDAP server}} error is usually returned when the LDAP
+The {{B:Can't contact LDAP server}} error is usually returned when the LDAP
server cannot be contacted. This may occur for many reasons:
* the LDAP server is not running; this can be checked by running, for example,
12 years, 7 months
Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com
Rein Tollevik wrote:
> On 04/25/2010 12:49 AM, hyc(a)symas.com wrote:
>
>> Also in terms of logical abstraction the current behavior is wrong; the
>> frontend should of course generate the default_referral responses but
>> updateref is a per-backend item and should be generated at the backend layer.
>> Ideally this would all have been fixed to behave correctly by moving all
>> replication support into an overlay, where it properly belongs. As an interim
>> step it would be trivial to write an updateref overlay that supersedes the
>> current updateref behavior.
>
> Updateref processing should imo be kept out of any replication modules,
> it is needed in databases where syncrepl isn't configured too. I'm
> using it on my subordinate databases (with an artificial updatedn so
> that slapd accepts it..) when syncrepl is configured on the superior
> glue database without managing all of the subordinate databases. I.e,
> the infamous test058...
>
> I was having the same "chain only on some of the databases" requirement
> and is using a patch that allows it. I consider this patch more of a
> hack than a correct solution, which is why I haven't contributed it. A
> separate updateref overlay apear to me as the best solution. But for
> what it's worth, my patch is now in:
>
> ftp://ftp.openldap.org/incoming/rein-ITS6531.patch
>
> An advantage with this patch over a new overlay is that it should be
> usable without any configuration changes (provided the chain overlay
> have already been configured in the databases and found to not work as
> expected there that is ... ;-).
I didn't quite follow the intended usage for this patch. Are other overlays
expected to override the default over_mod_ref() handler?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 7 months
Re: (ITS#6607) forwarded bind failure messages cause success
by hyc＠symas.com
mbackes(a)symas.com wrote:
> 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.
>
>
This was already fixed in HEAD by back-ldap/chain.c rev 1.77 (apparently fixed
for unrelated reasons).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 7 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
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
12 years, 7 months
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com
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
12 years, 7 months
Re: (ITS#6599) slapd not responding
by binoy＠cordys.com
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
12 years, 7 months
Fwd: (ITS#6599) slapd not responding
by binoy＠cordys.com
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
12 years, 7 months
