- openldap-bugs - openldap.org

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 03 Oct '12

03 Oct '12

--On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote: > I understand that you don't want to support older OpenLDAP versions, > builds with non-default libraries, etc. But the users will rather use > the package from their distribution, instead of compiling it by > themselves. And we cannot support users' builds, because we do not have > the sources and the build environment under control. And we cannot > rebase the packages freely. Redhat needs to come up with a solution to this problem, because they are putting their users in a catch-22 situation. Either they get support from RedHat for a package that will not work, or they build their own, and can't get support from RedHat. There are reasons new *patch* level releases are made. I see zero reason why RedHat cannot update the versions of OpenLDAP they ship since the fixes are incremental. No one should be running OpenLDAP 2.4.23 as a *production server*. Keep the RPM version string the same, and note the upstream release in the RPM patchlevel, if that is necessary, but fix the actual code to be current. This is why the Debian folks *wisely* recommend that people do *not* use the distribution build for a production server. As long as RedHat keeps up this policy, the only advice ever for RedHat customers is to build their own RPMs, and get support elsewhere, since RedHat clearly can't keep working server versions together for their customers. And then that leads to the question of what exactly they are paying RedHat for support for in the first place. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 10:18 AM, Howard Chu wrote: > Thanks for your comments, Rich. > > richm(a)stanfordalumni.org wrote: >>> On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >>>> Back to this point - surely OpenLDAP libldap is not the only piece of >>>> software that expects to use OpenSSL-style cipher suite names. >>>> libldap is >>>> certainly not the best place to put this translation. >>> I'm not sure about that. We tried to go a "compatible" way with >>> OpenLDAP, >>> don't know about other projects. I will take a look. >> This is the nss_compat_ossl library approach, which attempts to make >> moznss look as much like openssl as possible to applications. I thought >> about trying to use that with openldap a few years ago when we first >> started looking at having openldap support moznss, but Howard had >> already done a great deal of work to make the tls code "pluggable" with >> tls2.c and tls_m.c, which takes the approach of using the moznss code >> directly rather than indirectly through another layer . This has been >> the preferred approach of the Red Hat and Fedora teams that were >> attempting to replace openssl with moznss. nss_compat_ossl has not been >> actively worked on for a couple of years, and would require many changes >> to support multi-init, multiple key/cert databases, and other fixes that >> have gone into tls_m.c. >> >> I suppose we could try to get some sort of openssl cipher name support >> directly in upstream moznss, but they would probably assert that it >> doesn't belong there either. >> >> Maybe we could use nss_compat_ossl to do the mapping of cipher names >> from openssl to moznss? > > That makes sense to me, although if as you say it hasn't been actively > maintained, that sounds like another problem. But certainly if other > apps are using it, then aren't they going to want new cipher suite > support too? > Yes, and imho nss_compat_ossl is the place to do this. But, would it be possible to update the cipher suite list in tls_m.c first, to bring it up to date, then work on updating the compat library?

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 03 Oct '12

03 Oct '12

Thanks for your comments, Rich. richm(a)stanfordalumni.org wrote: >> On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >>> Back to this point - surely OpenLDAP libldap is not the only piece of >>> software that expects to use OpenSSL-style cipher suite names. libldap is >>> certainly not the best place to put this translation. >> I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, >> don't know about other projects. I will take a look. > This is the nss_compat_ossl library approach, which attempts to make > moznss look as much like openssl as possible to applications. I thought > about trying to use that with openldap a few years ago when we first > started looking at having openldap support moznss, but Howard had > already done a great deal of work to make the tls code "pluggable" with > tls2.c and tls_m.c, which takes the approach of using the moznss code > directly rather than indirectly through another layer . This has been > the preferred approach of the Red Hat and Fedora teams that were > attempting to replace openssl with moznss. nss_compat_ossl has not been > actively worked on for a couple of years, and would require many changes > to support multi-init, multiple key/cert databases, and other fixes that > have gone into tls_m.c. > > I suppose we could try to get some sort of openssl cipher name support > directly in upstream moznss, but they would probably assert that it > doesn't belong there either. > > Maybe we could use nss_compat_ossl to do the mapping of cipher names > from openssl to moznss? That makes sense to me, although if as you say it hasn't been actively maintained, that sounds like another problem. But certainly if other apps are using it, then aren't they going to want new cipher suite support too? -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 02:33 AM, jvcelak(a)redhat.com wrote: > Hello, > > On Tuesday 02 of October 2012 14:01:16, hyc(a)symas.com wrote: >> Let's be very clear. I'm not rejecting patches because they come from Red >> Hat. Anyone can plainly see that we have accepted many patches from Red >> Hat. I'm rejecting patches because the relevant code sucks, and when things >> related to them break, the OpenLDAP Project takes the heat even though >> we're not responsible for the breakage. There are CVEs issued against >> OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. >> I wouldn't have a problem with these patches if they actually worked, or if >> Red Hat took the blame when they don't work, but that's not what has >> happened. Instead we get CVE-2012-2668. This was my fault - just a straight up coding error. I take the blame for this. >> We get users asking why their TLS >> connections don't work after upgrading from one RedHat release to the next. >> We get a pointless support burden because users say "we have to run the Red >> Hat packages otherwise they won't support us" but then they don't actually >> ask Red Hat for support, they ask us. I have been active in the openldap community - mailing lists, irc - in answering questions about openldap + moznss. My assumption is that any TLS/SSL problems with openldap on RHEL/Fedora/CentOS are problems with the moznss code. I realize that it is a support burden because the first instinct of a user is to blame openldap. I try to deflect as much of that as possible towards Red Hat. I try to get people who are paid RHEL users to go through support. I try to get "free" users to file bugs. > Sometimes a security bug appears. We are not flawless. I do not know how we > should take the blame. The CVE clearly stated that this is a problem only with > Mozilla NSS backend. Which is used only by Fedora, RHEL, and their derivates. > And the affected code was from RH, anyone can see it in VCS. Tell me what did > you expect us to do and we can try to do it next time. > > If our users have a problem, they should first contact our support. Or create > a bug in our issue tracker. We cannot prevent them from contacting upstream. > And you can always say them 'Sorry, we cannot help you.' if the question is > not general enough or the problem depends on our build. > I understand that you don't want to support older OpenLDAP versions, builds > with non-default libraries, etc. But the users will rather use the package > from their distribution, instead of compiling it by themselves. And we cannot > support users' builds, because we do not have the sources and the build > environment under control. And we cannot rebase the packages freely. > > On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >> Back to this point - surely OpenLDAP libldap is not the only piece of >> software that expects to use OpenSSL-style cipher suite names. libldap is >> certainly not the best place to put this translation. > I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, > don't know about other projects. I will take a look. This is the nss_compat_ossl library approach, which attempts to make moznss look as much like openssl as possible to applications. I thought about trying to use that with openldap a few years ago when we first started looking at having openldap support moznss, but Howard had already done a great deal of work to make the tls code "pluggable" with tls2.c and tls_m.c, which takes the approach of using the moznss code directly rather than indirectly through another layer . This has been the preferred approach of the Red Hat and Fedora teams that were attempting to replace openssl with moznss. nss_compat_ossl has not been actively worked on for a couple of years, and would require many changes to support multi-init, multiple key/cert databases, and other fixes that have gone into tls_m.c. I suppose we could try to get some sort of openssl cipher name support directly in upstream moznss, but they would probably assert that it doesn't belong there either. Maybe we could use nss_compat_ossl to do the mapping of cipher names from openssl to moznss? > > Jan > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 03 Oct '12

03 Oct '12

Hello, On Tuesday 02 of October 2012 14:01:16, hyc(a)symas.com wrote: > Let's be very clear. I'm not rejecting patches because they come from Red > Hat. Anyone can plainly see that we have accepted many patches from Red > Hat. I'm rejecting patches because the relevant code sucks, and when things > related to them break, the OpenLDAP Project takes the heat even though > we're not responsible for the breakage. There are CVEs issued against > OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. > I wouldn't have a problem with these patches if they actually worked, or if > Red Hat took the blame when they don't work, but that's not what has > happened. Instead we get CVE-2012-2668. We get users asking why their TLS > connections don't work after upgrading from one RedHat release to the next. > We get a pointless support burden because users say "we have to run the Red > Hat packages otherwise they won't support us" but then they don't actually > ask Red Hat for support, they ask us. Sometimes a security bug appears. We are not flawless. I do not know how we should take the blame. The CVE clearly stated that this is a problem only with Mozilla NSS backend. Which is used only by Fedora, RHEL, and their derivates. And the affected code was from RH, anyone can see it in VCS. Tell me what did you expect us to do and we can try to do it next time. If our users have a problem, they should first contact our support. Or create a bug in our issue tracker. We cannot prevent them from contacting upstream. And you can always say them 'Sorry, we cannot help you.' if the question is not general enough or the problem depends on our build. I understand that you don't want to support older OpenLDAP versions, builds with non-default libraries, etc. But the users will rather use the package from their distribution, instead of compiling it by themselves. And we cannot support users' builds, because we do not have the sources and the build environment under control. And we cannot rebase the packages freely. On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: > Back to this point - surely OpenLDAP libldap is not the only piece of > software that expects to use OpenSSL-style cipher suite names. libldap is > certainly not the best place to put this translation. I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, don't know about other projects. I will take a look. Jan

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 02 Oct '12

02 Oct '12

hyc(a)symas.com wrote: > Jan Vcelak wrote: >> Of course, cipher suite enumeration in MozNSS is possible. But >> translation from OpenSSL names without the translation table would be >> very messy. I still think this is a better solution. Back to this point - surely OpenLDAP libldap is not the only piece of software that expects to use OpenSSL-style cipher suite names. libldap is certainly not the best place to put this translation. -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 02 Oct '12

02 Oct '12

Jan Vcelak wrote: > Of course, cipher suite enumeration in MozNSS is possible. But > translation from OpenSSL names without the translation table would be > very messy. I still think this is a better solution. > >> There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for >> review >> here, plus 2 already committed for 2.4.33. We will not accept patches >> that >> require constant revisiting every time NSS updates. This is too much. >> No more. > > I'm sending one patch per change. And looking at the patches, I do not > think I'm introducing new bugs. It's mostly a fixes for issues present > in the code before I started sending my first patches. And be sure that > I'm testing the TLS heavily before submitting anything. > > I do not understand why you strictly refuse anything which comes from > Fedora or Red Hat. We decided to use MozNSS and you can disagree. We > still want to fix the problems with that backend to use it without any > pain. Sorry, I really do not feel like your feedback is constructive. Let's be very clear. I'm not rejecting patches because they come from Red Hat. Anyone can plainly see that we have accepted many patches from Red Hat. I'm rejecting patches because the relevant code sucks, and when things related to them break, the OpenLDAP Project takes the heat even though we're not responsible for the breakage. There are CVEs issued against OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. I wouldn't have a problem with these patches if they actually worked, or if Red Hat took the blame when they don't work, but that's not what has happened. Instead we get CVE-2012-2668. We get users asking why their TLS connections don't work after upgrading from one RedHat release to the next. We get a pointless support burden because users say "we have to run the Red Hat packages otherwise they won't support us" but then they don't actually ask Red Hat for support, they ask us. It may seem like this feedback is not constructive, but to me it is not productive for the Project to support a crypto library that was designed for use in a web browser and still assumes that its callers always have a human user sitting in front. Bugs like #7316 shouldn't ever have happened. None of this should come as a surprise to you since I've been stating this from the very first moment MozNSS support was ever mentioned. The NSS crypto architecture was never suited for any setting other than a single user application. It is completely inappropriate for use as a multi-user system library, or in a headless server environment. That was true 4 years ago when we first started working with it and it clearly hasn't improved by today. -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 02 Oct '12

02 Oct '12

> This is completely the wrong approach. There is no way you should be > putting > hardcoded constants in libldap that are tied to specific MozNSS > versions. The > MozNSS library needs to provide a cipher enumerator API. Let me quote OpenLDAP documentation: | When using Mozilla NSS, the OpenSSL cipher suite specifications are | used and translated into the format used internally by Mozilla NSS. And FAQ page about Mozilla NSS in OpenLDAP: | OpenLDAP can use Mozilla NSS as the TLS/SSL implementation. If you | previously used OpenLDAP with OpenSSL, and have certificate files, | cipher suites, and other TLS settings specified in your configuration | files, those settings should work exactly the same way with Mozilla | NSS - OpenLDAP with Mozilla NSS knows how to read those settings, | files, etc. and apply them in the same way. The goal is that you | will not be able to tell you are using OpenLDAP with Mozilla NSS | because it will work exactly the same as OpenLDAP with OpenSSL. Which means that if we decided at some point to make the MozNSS layer compatible with OpenSSL, we have to keep up with it now. Of course, cipher suite enumeration in MozNSS is possible. But translation from OpenSSL names without the translation table would be very messy. I still think this is a better solution. > There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for > review > here, plus 2 already committed for 2.4.33. We will not accept patches > that > require constant revisiting every time NSS updates. This is too much. > No more. I'm sending one patch per change. And looking at the patches, I do not think I'm introducing new bugs. It's mostly a fixes for issues present in the code before I started sending my first patches. And be sure that I'm testing the TLS heavily before submitting anything. I do not understand why you strictly refuse anything which comes from Fedora or Red Hat. We decided to use MozNSS and you can disagree. We still want to fix the problems with that backend to use it without any pain. Sorry, I really do not feel like your feedback is constructive. Jan

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 01 Oct '12

01 Oct '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-ciph… > Submission from: (NULL) (209.132.186.34) > > > I'm attaching patch which updates the list of supported cipher suites for > Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are > included. Recall what I said in ITS#7388 about an endless stream of patches to an unmaintainable code base... This is completely the wrong approach. There is no way you should be putting hardcoded constants in libldap that are tied to specific MozNSS versions. The MozNSS library needs to provide a cipher enumerator API. There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for review here, plus 2 already committed for 2.4.33. We will not accept patches that require constant revisiting every time NSS updates. This is too much. No more. Tell the NSS guys to fix their design, or tell Red Hat to use a crypto library that actually works for the intended purpose. MozNSS clearly doesn't. > Default ciphers are selected on the same basis as in OpenSSL. > NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well. > > > The attached 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, Jan Vcelak 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

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 01 Oct '12

01 Oct '12

arun s wrote: > Hi, > Yes, I am able to reproduce the issue with 2.4.32 > > Making sense of the logs for the exact reproduction is hard since it needs a > lot of operations in a short time. But this will probably help: > > 1. At the start of the test, the group temp_group existed. > > 2. I created a user temp_user and added temp_user to temp_group. > > 3. During replication, the group was replicated first and I got an error 32 > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object > (This does not exist in the readslave yet). > > 4. The temp_user object was replicated next, and as you see, querying it does > show a memberOf attribute, proving that this field was replicated. (Note that > I have run OpenLDAP with debug as -1 and verified that the replicated data has > the memberOf field in it. I can provide this too if needed.) I see. The current code drops the memberOf attribute if it was not explicitly requested in the search. However, by default the consumer requests "+" which means "all operational attributes" and so slapd considers memberOf to have been requested. We need to reconsider this aspect of the design. > > 5. The more serious problem occurs when the sequence is reversed and the group > has been deleted as a last operation - The user is replicated first, but since > the group is deleted, it is never replicated and a stale memberOf entry stays > with the user. -- -- 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#7400) Memberof and Syncrepl incompatibility
by arunkumar_1123＠yahoo.com 01 Oct '12

01 Oct '12

---872237384-2137566121-1349092304=:39209 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0AYes, I am able to reproduce the issue with 2.4.32=0A=0A=0AMaking sens= e of the logs for the exact reproduction is hard since it needs a lot of op= erations in a short time. But this will probably help:=0A=0A1. At the start= of the test, the group temp_group existed.=0A=0A2. I created a user temp_u= ser and added temp_user to temp_group.=0A=0A3. During replication, the grou= p was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried= to modify the memberOf of the temp_user object (This does not exist in the= readslave yet).=0A=0A4. The temp_user object was replicated next, and as y= ou see, querying it does show a memberOf attribute, proving that this field= was replicated. (Note that I have run OpenLDAP with debug as -1 and verifi= ed that the replicated data has the memberOf field in it. I can provide thi= s too if needed.)=0A=0A5. The more serious problem occurs when the sequence= is reversed and the group has been deleted as a last operation - The user = is replicated first, but since the group is deleted, it is never replicated= and a stale memberOf entry stays with the user.=0A=0A=0ALOGS:=0A=0A5069157= c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,ou=3Dgroup,dc=3D= example,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A5069157c syn= crepl_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c sync= repl_entry: rid=3D179 inserted UUID 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A= 5069157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry:= rid=3D179 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A5069157c slap= _queue_csn: queing 0x4270c730 20121001040100.779862Z#000000#000#000000=0A50= 69157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.779862Z#= 000000#000#000000=0A5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"= uid=3Dtemp_user,dc=3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou= =3Dgroup,dc=3Dexample,dc=3Dcom" failed err=3D32=0A5069157c syncrepl_entry: = rid=3D179 be_modify ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom (0)=0A= 5069157c syncrepl_message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexam= ple,dc=3Dcom, UUID: 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069157c syncrep= l_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c syncrepl= _entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069= 157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry: rid= =3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0A5069157c syncrepl_entry: rid= =3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)=0A=0AThe object tem= p_user:=0A=0Adn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0AmemberOf: ou=3Dtem= p_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A=0A=0AWhat is interesting is tha= t in this case, the memberOf field being replicated actually protects the s= lave from incorrect data as the temp_user entry was not present at the time= the group got replicated (The user entry was the second entry in the repli= cation order). On the other hand, a reversed path during replication causes= the mentioned bug.=0A=0AThanks=0A=0A=0A=0A________________________________= =0A From: Howard Chu <hyc(a)symas.com>=0ATo: arunkumar_1123(a)yahoo.com =0ACc: = openldap-its(a)openldap.org =0ASent: Sunday, 30 September 2012 8:51 PM=0ASubj= ect: Re: (ITS#7400) Memberof and Syncrepl incompatibility=0A =0Aarunkumar_1= 123(a)yahoo.com wrote:=0A> Full_Name: Arunkumar shanmugam=0A> Version: 2.4.29= =0A> OS: rhel5=0A> URL: ftp://ftp.openldap.org/incoming/=0A> Submission fro= m: (NULL) (203.83.248.32)=0A>=0A>=0A> Hi,=0A>=0A> I'm currently using Openl= dap 2.4.29 to model an Authorization platform. I=0A> noticed some inconsist= ent behavior with syncrepl and memberof overlays.=0A=0ADoes this issue occu= r with the current release, 2.4.32?=0A>=0A> The issue happens as follows:= =0A>=0A> If I Create groups with a large number of members and delete them = in quick=0A> succession on the writemaster, the data replicated to the read= slave is=0A> incorrect, in particular, the memberof fields of the User obje= cts.=0A>=0A> This seems to happen because the memberof field is getting rep= licated to the=0A> slave nodes, although the documentation states that it s= houldn't.=0A=0AIndeed. Do you have debug logs showing the replication traff= ic, and showing =0Athat the memberof attribute got replicated?=0A=0A> While= =0A> replicating, the User object is replicated inclusive of the memberof f= ields, but=0A> by the time the syncrepl search comes to the group object, i= t has already been=0A> deleted, and hence not replicated. This leaves a dan= gling memberof field in the=0A> read slave instance.=0A>=0A> I was wonderin= g if anyone has faced this issues (I did not see any ITS related=0A> to thi= s), and has a workaround.=0A>=0A> Thanks,=0A> Arunkumar=0A>=0A>=0A=0A=0A-- = =0A=A0 -- Howard Chu=0A=A0 CTO, Symas Corp.=A0 =A0 =A0 =A0 =A0 http://www= .symas.com=0A=A0 Director, Highland Sun=A0 =A0 http://highlandsun.com/hyc/= =0A=A0 Chief Architect, OpenLDAP=A0 http://www.openldap.org/project/ ---872237384-2137566121-1349092304=:39209 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div style=3D"colo= r: rgb(69, 69, 69); font-size: 13px; font-family: arial, helvetica, sans-se= rif; background-color: transparent; font-style: normal; ">=09Yes, I am able to reproduce the issue with = 2.4.32 </div><div style=3D"color: rgb(69, 69, 69); font-size: 13p= x; font-family: arial, helvetica, sans-serif; background-color: transparent= ; font-style: normal; "> Making = sense of the logs for the exact reproduction is hard since it needs a lot o= f operations in a short time. But this will probably help: 1. At the = start of the test, the group temp_group existed. 2. I created a user t= emp_user and added temp_user to temp_group. 3. During replication, the group= was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried = to modify the memberOf of the temp_user object (This does not exist in the = readslave yet). <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">4. The temp_user object was replicated next, and as yo= u see, querying it does show a memberOf attribute, proving that this field = was replicated. (Note that I have run OpenLDAP with debug as -1 and verifie= d that the replicated data has the memberOf field in it. I can provide this = too if needed.) <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5. The more serious problem occurs when the sequence i= s reversed and the group has been deleted as a last operation - The user is= replicated first, but since the group is deleted, it is never replicated a= nd a stale memberOf entry stays with the user. LOG= S: 5069157c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,o= u=3Dgroup,dc=3Dexample,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4= 5069157c syncrepl_= entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5069157c syncrepl_entry: rid=3D179 inserted UUID 31090a= b1-f8a7-4363-83c2-c0ac0d3918d4 5069157c syncrepl_entry: rid=3D179 be_search (0) 5069157c syncrepl_entry: rid=3D17= 9 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom 5069157c slap_queue_csn: queing 0x4270c730 = 20121001040100.779862Z#000000#000#000000 5069157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.77986= 2Z#000000#000#000000 5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"uid=3Dtemp_user,dc= =3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou=3Dgroup,dc=3Dexampl= e,dc=3Dcom" failed err=3D32 5069157c syncrepl_entry: rid=3D179 be_modify ou=3Dtemp_group,ou=3D= group,dc=3Dexample,dc=3Dcom (0) 5069157c syncrepl= _message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom, UUI= D: 748bd1a9-6be3-450b-809c-5ea692aa073c <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5069157c syncrepl_entry: rid=3D179 LDAP_RES_SEARCH_ENT= RY(LDAP_SYNC_ADD) 5= 069157c syncrepl_entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea= 692aa073c 5069157c syncrepl_entry: = rid=3D179 be_search (0) 5069157c syncrepl_entry: rid=3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dc= om 5069157c syncrep= l_entry: rid=3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)<= br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-ser= if; font-size: 13px; "> Th= e object temp_user: dn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom memberOf: ou=3Dtemp_group,ou=3Dgro= up,dc=3Dexample,dc=3Dcom What is interesting is that in this case, t= he memberOf field being replicated actually protects the slave from incorre= ct data as the temp_user entry was not present at the time the group got re= plicated (The user entry was the second entry in the replication order). On= the other hand, a reversed path during replication causes the mentioned bu= g. Thanks</div><div> </div> <div style=3D"font-famil= y: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div st= yle=3D"font-family: 'times new roman', 'new york', times, serif; font-size:= 12pt; "> <div dir=3D"ltr"> <hr size=3D"1"= > From: Howard Chu <hyc(a)symas.com&= gt; To: arunkumar_1123= @yahoo.com Cc: openlda= p-its(a)openldap.org Sent:<= /b> Sunday, 30 September 2012 8:51 PM Subject: Re: (ITS#7400) Memberof and Syncrepl incompatibili= ty </div> <a ymailto=3D"mailto:arunkumar_1123@yahoo.com" hr= ef=3D"mailto:arunkumar_1123@yahoo.com">arunkumar_1123(a)yahoo.com</a> wrote:<= br>> Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: = rhel5 > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_= blank">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL)= (203.83.248.32) > > > Hi, > > I'm currently = using Openldap 2.4.29 to model an Authorization platform. I > noticed= some inconsistent behavior with syncrepl and memberof overlays. Does thi= s issue occur with the current release, 2.4.32? > > The issue h= appens as follows: > > If I Create groups with a large number o= f members and delete them in quick > succession on the writemaster, t= he data replicated to the readslave is > incorrect, in particular, th= e memberof fields of the User objects. > > This seems to happen= because the memberof field is getting replicated to the > slave node= s, although the documentation states that it shouldn't. Indeed. Do y= ou have debug logs showing the replication traffic, and showing that th= e memberof attribute got replicated? > While > replicating,= the User object is replicated inclusive of the memberof fields, but &gt= ; by the time the syncrepl search comes to the group object, it has already= been > deleted, and hence not replicated. This leaves a dangling memberof field in the > read slave instance. > &gt= ; I was wondering if anyone has faced this issues (I did not see any ITS re= lated > to this), and has a workaround. > > Thanks, &g= t; Arunkumar > > --   -- Howard Chu &nb= sp; CTO, Symas Corp.          <a href=3D"http://= www.symas.com/" target=3D"_blank">http://www.symas.com</a>   Direc= tor, Highland Sun    <a href=3D"http://highlandsun.com/hyc/" tar= get=3D"_blank">http://highlandsun.com/hyc/</a>   Chief Architect, = OpenLDAP  <a href=3D"http://www.openldap.org/project/" target=3D"_blan= k">http://www.openldap.org/project/</a> </div> </div> </div></= body></html> ---872237384-2137566121-1349092304=:39209--

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu 01 Oct '12

01 Oct '12

Thanks, my 2 mirror (Master-Master) server say : ebuild U ] net-nds/openldap-2.4.30::gentoo [2.4.23-r1::MC-link-NOC] upgrading to 2.4.30 doesn't cause problems , its correct ? Can i upgrade quietly or i have to do some pre-operations ? Thanks Il giorno 28/set/2012, alle ore 18:57, Quanah Gibson-Mount ha scritto: > --On Friday, September 28, 2012 10:04 AM +0000 a.stefanello(a)mclink.eu wrote: > >> Full_Name: Andrea Stefanello >> Version: 2.4.23-r1 > > Use a current openldap build. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 30 Sep '12

30 Sep '12

arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.32) > > > Hi, > > I'm currently using Openldap 2.4.29 to model an Authorization platform. I > noticed some inconsistent behavior with syncrepl and memberof overlays. Does this issue occur with the current release, 2.4.32? > > The issue happens as follows: > > If I Create groups with a large number of members and delete them in quick > succession on the writemaster, the data replicated to the readslave is > incorrect, in particular, the memberof fields of the User objects. > > This seems to happen because the memberof field is getting replicated to the > slave nodes, although the documentation states that it shouldn't. Indeed. Do you have debug logs showing the replication traffic, and showing that the memberof attribute got replicated? > While > replicating, the User object is replicated inclusive of the memberof fields, but > by the time the syncrepl search comes to the group object, it has already been > deleted, and hence not replicated. This leaves a dangling memberof field in the > read slave instance. > > I was wondering if anyone has faced this issues (I did not see any ITS related > to this), and has a workaround. > > Thanks, > Arunkumar > > -- -- 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#7408 published: SECURITY: OpenLDAP multimaster out of sync
by openldap-its＠OpenLDAP.org 30 Sep '12

30 Sep '12

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

1 0

Re: (ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

I've just noticed, that there are subclasses that match the filter criteria. I.e. (attr1>=100) filter part matched attr1 attribute, but (attr1<=200) matched some attr2 (attr2=42) attribute in the same object, and attr2 is a subclass of attr1. This is probably not a bug, better I'll ask the mail-list.

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by quanah＠zimbra.com 28 Sep '12

28 Sep '12

--On Friday, September 28, 2012 10:04 AM +0000 a.stefanello(a)mclink.eu wrote: > Full_Name: Andrea Stefanello > Version: 2.4.23-r1 Use a current openldap build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

Full_Name: Roman Rybalko Version: git a1c2dc6 OS: Linux Debian x64 URL: ftp://ftp.openldap.org/incoming/romanr-120928.tgz Submission from: (NULL) (82.146.61.98) olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'logOrderingInteger' DESC 'Integer with ordering' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'logTimeInteger' DESC 'Integer time representation' SUP logOrderingInteger ) olcDbIndex: logTimeInteger Search filter (&(logTimeInteger>=1348137600)(logTimeInteger<=1348137620)) provides entries with logTimeInteger>1348137620. Should be only entries with logTimeInteger>=1348137600 and logTimeInteger<=1348137620. See data on ftp.

1 0

(ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu 28 Sep '12

28 Sep '12

Full_Name: Andrea Stefanello Version: 2.4.23-r1 OS: Gentoo Base System release 1.12.14 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.21.176.129) Hi, i have this problem , searching a just created entries using base DN OU doesn't works, searching with his real base DN works. This happened with all new entries. This is an example : SEARCH USING BASE ou=mail : #ldapsearch -b ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS doesn't find nothing . SEARCH USING BASE cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN : #ldapsearch -b cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS find the entry. The scope used is "sub". After a couple of hour(i think 2 hours) the entry can be found even with the first query, using the "contenitor" ou just like somethings appenned inside the DB. There is a way to find out why we have this behaviour ? Can it be a index problem ? (mailAddress index is ok otherwise the second query shall not work, right?) Can i force something on ldap to resync something inside to find the entry just after is creation ? Thanks for your answer.

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 27 Sep '12

27 Sep '12

Thanks, Quanah. We will try this version and see how it performs. Venkatesh -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, September 25, 2012 1:12 PM To: BAGLODI, VENKATESH; openldap-its(a)openldap.org Subject: RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues --On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote: > Thank you so much for the quick reply. We are a bit hesitant to try > 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as > it is mentioned on your Web site > (http://www.openldap.org/software/release/readme.html)? I've been using BDB 4.7.25 (+all patches) for several years, and it has been quite stable. No deadlocks. This version is used on all Zimbra deployments across the world, with plenty of customers having millions of entry DBs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com 27 Sep '12

27 Sep '12

I'll have to see if I can track down stderr when this happens. Here is the configuration on that host: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/custom.schema include /etc/openldap/schema/ldapux.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/puppet.schema TLSVerifyClient never TLSCertificateFile /etc/openldap/slapd.pem TLSCertificateKeyFile /etc/openldap/slapd.pem TLSCACertificateFile /etc/openldap/ca.pem pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel sync reverse-lookup on # old ACLs include /etc/openldap/legacy.acl # new ACLs include /etc/openldap/new.acl # Allow anonymous access to userPassword for directory binds access to dn.onelevel="ou=users,dc=example2,dc=net" attrs="userPassword" by anonymous auth by self read by * none # Secure unix passwords access to dn.onelevel="ou=users,ou=posix,dc=example2,dc=net" attrs="userPassword" by self read by * none # Secure unix passwords # legacy access to dn.onelevel="ou=people,dc=example,dc=com" attrs="userPassword" by self read by * none access to dn.onelevel="ou=people,dc=example2,dc=net" attrs="userPassword" by self read by * none # posix info is public access to dn.subtree="ou=posix,dc=example2,dc=net" by * read # posix info is public # legacy access to dn.subtree="ou=people,dc=example,dc=com" by * read access to dn.subtree="ou=people,dc=example2,dc=net" by * read access to dn.subtree="ou=group,dc=example2,dc=net" by * read # access to the base dn access to dn.base="dc=example2,dc=net" by * read # access to the base dn # legacy access to dn.base="dc=example,dc=com" by * none # basic access # legacy access to dn.subtree="dc=example,dc=com" by * none # basic access access to * by users read by * none database hdb suffix "dc=example2,dc=net" rootdn "cn=manager,dc=example2,dc=net" rootpw password index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryUUID,modifyTimestamp eq index location eq index service subinitial index uniqueMember eq directory /var/lib/ldap sizelimit unlimited cachesize 1000000 idlcachesize 3000000 overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net syncrepl rid=1 provider=ldap://syncrepl.example2.net:389 type=refreshAndPersist searchbase="dc=example2,dc=net" bindmethod=simple binddn=user=sync-user,ou=users,dc=example2,dc=net starttls=critical credentials=password retry="10 100 300 +" database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=example,dc=com" "dc=example2,dc=net" overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by hyc＠symas.com 27 Sep '12

27 Sep '12

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.32 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.148.0.72) > > > We are seeing this a few times a week in our environment. Can you provide a sample config to reproduce the issue? What is the exact error message on stderr that accompanies this assert? > #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 > #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 > #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, > oldctrls=0x11251620) at ppolicy.c:870 > #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) > at ppolicy.c:895 > #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at > result.c:541 > #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at > result.c:733 > #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) > at result.c:860 > #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 > #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 > #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) > at op.c:210 > #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at > op.c:243 > #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 > #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at > bind.c:383 > #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 > #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, > arg_v=0x11144d40) at connection.c:1150 > #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at > connection.c:1286 > #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at > tpool.c:688 > #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 > #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 > #24 0x0000000000000000 in ?? () > > -- -- 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#7399) ¡¾Syncrepl¡¿when consumer doing the syncrepl with the provider, reboot the consumer, the cusummer does not continue the task any more
by hyc＠symas.com 27 Sep '12

27 Sep '12

xinrong.li(a)163.com wrote: > Full_Name: mark > Version: 2.4.20 > OS: sles11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (113.116.144.106) > > The current version is 2.4.32. Bugs in old versions will not be investigated. If you can still encounter this issue in the current release, we can work from there. For now this ITS will be closed. > I meet some problem when doing as following: > --> consumer and provider OK. mean that if you add/delete some records to > provider, consumer will sync with the provder > > --> let consumer ldap service stop > --> provider add 100 records > --> consumer start and it will begin to sync the 100 records from provider > --> consumer restart when have sync 60 records from provider > --> consumer wounld not Syncrepl the rest 40 records from provider > > --> then, you add or delete some records, consumer will sync with provider OK > except the 40 records > > May anyone give me some help? thanks! > > my slapd.conf content is thus: > > provider: > database bdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > comsumer: > database hdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > > syncrepl rid=123 > provider=ldap://provider.example.com:389 > type=refreshOnly > interval=01:00:00:00 > searchbase="dc=example,dc=com" > filter="(objectClass=organizationalPerson)" > scope=sub > attrs="cn,sn,ou,telephoneNumber,title,l" > schemachecking=off > bindmethod=simple > binddn="cn=syncuser,dc=example,dc=com" > credentials=secret > > > > -- -- 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#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 27 Sep '12

27 Sep '12

It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema. Comments?

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 27 Sep '12

27 Sep '12

marco(a)schirrmeister.net wrote: > On Sep 18, 2012, at 1:59 PM, hyc(a)symas.com wrote: > >> Marco Schirrmeister wrote: >>> I pulled latest RE24 on Sep 15th and now I get this. >>> >>> ... >>> indexing id=00010d0e >>> indexing id=00010d0f >>> 5056de89 => mdb_tool_entry_reindex: txn_commit failed: Unknown error 18446744073709520830 (-30786) >> >> That was fixed yesterday in commit 8bb10add2465eee34e79abeaa62011e3e234effb. >> Please pull RE24 again today and try again, it should all be working fine. > > Just tested with latest RE24 > > indexing id=00010d0e > indexing id=00010d0f > 50587b72 => mdb_tool_entry_reindex: txn_commit failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786) Thanks for your help, this is now fixed in master. -- -- 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#7405) Improve refint documentation
by hyc＠symas.com 27 Sep '12

27 Sep '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > As per debian bug#688857: > > Modifications made by refint are not replicated. They neither update the > modification timestamp nor the CSN used for replication. This is serious > data loss, because the replicas gets out of sync pretty quickly. There > seems to be no way to recover from this discrepancy without doing a > complete replication. > > While this seems to be known, it is not documented at all in the > man-pages related to the refint and memberof overlays. Also it violates > the principle of least surprise, because the changes are not limited to > operational attributes. slapo-refint(5) manpage updated in master. slapo-memberof(5) was updated in 2.4.26 (ITS#6915) so at least that part of the bug report is invalid. -- -- 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#7405) Improve refint documentation
by quanah＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) As per debian bug#688857: Modifications made by refint are not replicated. They neither update the modification timestamp nor the CSN used for replication. This is serious data loss, because the replicas gets out of sync pretty quickly. There seems to be no way to recover from this discrepancy without doing a complete replication. While this seems to be known, it is not documented at all in the man-pages related to the refint and memberof overlays. Also it violates the principle of least surprise, because the changes are not limited to operational attributes.

1 0

Re: (ITS#7404) back-ldap connection cache error
by hyc＠symas.com 26 Sep '12

26 Sep '12

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.19.96.255) > Submitted by: hyc > > > back-ldap resets the local DN of a connection after a Bind request, even if the > Bind failed. Subsequent operations for that DN will reuse this connection, even > though it hasn't bound successfully. This is clearly wrong. Hm, false alarm. back-ldap is correct here. Something else is lying about its identity... -- -- 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#7404) back-ldap connection cache error
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc back-ldap resets the local DN of a connection after a Bind request, even if the Bind failed. Subsequent operations for that DN will reuse this connection, even though it hasn't bound successfully. This is clearly wrong.

1 0

(ITS#7403) back-ldap idassert always overrides
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc If an idassert-bind directive has been configured, idassert processing is always performed, even if a direct bind has occurred. In effect, back-ldap always behaves as if flags=override was set in the idassert configuration. This is not the documented or intended behavior. A fix is coming shortly.

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by quanah＠zimbra.com 25 Sep '12

25 Sep '12

--On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote: > Thank you so much for the quick reply. We are a bit hesitant to try > 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as > it is mentioned on your Web site > (http://www.openldap.org/software/release/readme.html)? I've been using BDB 4.7.25 (+all patches) for several years, and it has been quite stable. No deadlocks. This version is used on all Zimbra deployments across the world, with plenty of customers having millions of entry DBs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 25 Sep '12

25 Sep '12

Thank you so much for the quick reply. We are a bit hesitant to try 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as it is mentioned on your Web site (http://www.openldap.org/software/release/readme.html)? Sincerely, Venkatesh -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, September 25, 2012 11:19 AM To: BAGLODI, VENKATESH Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.160.226.53) > > > We have been facing occasional deadlock issues when using OpenLDAP in > multi-master mode (4 servers). It looks like deadlocks are occuring on > objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend > (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We > tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks > like the server is out of disk space. Some of the traces are provided below: Your traces look much the same as ITS#7378. However, as noted in followup#4 to that report, there's no code path in back-bdb/hdb that can legitimately cause this situation. Can you switch to BDB 4.7.25 and still reproduce the problem? -- -- 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#7402)
by agarcia＠tempel.es 25 Sep '12

25 Sep '12

This is a multi-part message in MIME format. --------------080808010700020804030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And sldapd change the shema from: attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE ) to : # RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) Thanks a lot for your quick reply, c=Net is not really Country (just a TLD) but I used it in previous slapd version a worked well! Thanks --------------080808010700020804030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> And sldapd change the shema from: <blockquote>attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )         DESC 'RFC2256: ISO-3166 country 2-letter code'         SUP name SINGLE-VALUE ) </blockquote> to : <blockquote># RFC 4519 definition ('countryName' in X.500 and RFC2256) attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )         DESC 'RFC4519: two-letter ISO-3166 country code'         SUP name         SYNTAX 1.3.6.1.4.1.1466.115.121.1.11         SINGLE-VALUE ) </blockquote> Thanks a lot for your quick reply, c=Net is not really Country (just a TLD) but I used it in previous slapd version a worked well! Thanks </body> </html> --------------080808010700020804030601--

1 0

Re: (ITS#7402) Invalid DN 21
by Pierangelo Masarati 25 Sep '12

25 Sep '12

> I've configured my DB suffix at /etc/openldap/slapd.conf > >> suffix "o=Iddover, c=Net" > > But slapd doesn't like the dn, if I've used "cn=Iddover, cn=Net" slapd start > normally. "Net" is invalid per "c" syntax. The ITS is intended for software bugs; please direct usage error questions to openldap-technical. This ITS will be closed. p.

1 0

Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by hyc＠symas.com 25 Sep '12

25 Sep '12

vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.160.226.53) > > > We have been facing occasional deadlock issues when using OpenLDAP in > multi-master mode (4 servers). It looks like deadlocks are occuring on > objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend > (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We > tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks > like the server is out of disk space. Some of the traces are provided below: Your traces look much the same as ITS#7378. However, as noted in followup#4 to that report, there's no code path in back-bdb/hdb that can legitimately cause this situation. Can you switch to BDB 4.7.25 and still reproduce the problem? -- -- 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#7401
by vb4607＠att.com 25 Sep '12

25 Sep '12

--_004_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_ Content-Type: multipart/alternative; boundary="_000_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_" --_000_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, see attached for section of LDAP log file. LDAP instance became unres= ponsive (hanging) at 00:41:09 until it was restarted at 01:24:33. --_000_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Also, see attached for= section of LDAP log file. LDAP instance became unresponsive (hanging) at 0= 0:41:09  until it was restarted at 01:24:33.<o:p></o:p> </div> </body> </html> --_000_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_-- --_004_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_ Content-Type: text/plain; name="logtrace.txt" Content-Description: logtrace.txt Content-Disposition: attachment; filename="logtrace.txt"; size=17169; creation-date="Tue, 25 Sep 2012 15:08:27 GMT"; modification-date="Tue, 25 Sep 2012 15:08:42 GMT" Content-Transfer-Encoding: base64 U2VwIDI1IDAwOjQwOjE3IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg0OTkg TU9EIGRuPSJlcD10My1tMmViLXExMDBjc2k4bTgudmNpLmF0dC5jb218MzY0NjgsdmVyPTY0LjAu Nyxjbj1PUkFDTEVGVVNJT05BZGFwdGVyLG91PW0yZSxvdT1jc2ksb3U9YXR0LG91PWNvbSxvdT1T DQplcnZpY2VzLG91PVBFUkYsb3U9RW52aXJvbm1lbnRzLG89c2NsZCxkYz1hdHQsZGM9Y29tIg0K U2VwIDI1IDAwOjQwOjE3IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg0OTkg TU9EIGF0dHI9c2NTdGF0dXNDaGVja1RpbWUgc2NFeHBpcmF0aW9uVGltZQ0KU2VwIDI1IDAwOjQw OjE3IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg0OTkgUkVTVUxUIHRhZz0x MDMgZXJyPTAgdGV4dD0NClNlcCAyNSAwMDo0MDoxOCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMTk3NyBvcD0xMDkgTU9EIGRuPSJlcD1kMWEtbTJlLXExMTJtMmUxLmVkYy5jaW5ndWxhci5u ZXR8NDAzMzksdmVyPTYyLjAuNDUsY249SW5xdWlyZUNvbWJpbmVkQmlsbGluZ0VsaWdpYmlsaXR5 LG91PW0yZSxvdT1jc2ksbw0KdT1hdHQsb3U9Y29tLG91PVNlcnZpY2VzLG91PVRFU1Qsb3U9RW52 aXJvbm1lbnRzLG89c2NsZCxkYz1hdHQsZGM9Y29tIg0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQg c2xhcGRbMjc0NDhdOiBjb25uPTMxOTc3IG9wPTEwOSBNT0QgYXR0cj1zY1N0YXR1c0NoZWNrVGlt ZSBzY0V4cGlyYXRpb25UaW1lDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06 IGNvbm49MzE5Nzcgb3A9MTA5IFJFU1VMVCB0YWc9MTAzIGVycj0wIHRleHQ9DQpTZXAgMjUgMDA6 NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1NDQgb3A9MjMgU1JDSCBiYXNlPSJj bj1BdXRob3JpemVMT0FVcGRhdGUsb3U9bTJlLG91PWNzaSxvdT1hdHQsb3U9Y29tLG91PVNlcnZp Y2VzLG91PVBFUkYsb3U9RW52aXJvbm1lbnRzLG89c2NsZCxkYz1hdHQsZGM9Y28NCm0iIHNjb3Bl PTIgZGVyZWY9MyBmaWx0ZXI9IigmKG9iamVjdENsYXNzPXNjU2VydmljZUVuZFBvaW50KShzY01h am9yVmVyc2lvbj02NCkoc2NNaW5vclZlcnNpb249MCkoc2NQYXRjaFZlcnNpb249MTcpKHNjSG9z dEFkZHJlc3M9dDEtbTJlYi1xMTAwY3NpN203LnZjaS5hdHQuY29tKShzY0xpc3Rlbg0KUG9ydD0z NDU1MCkoIShzY0RlbGV0ZWRUaW1lPSopKSkiDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFw ZFsyNzQ0OF06IGNvbm49MzI1NDQgb3A9MjMgU1JDSCBhdHRyPSogY3JlYXRlVGltZXN0YW1wIG1v ZGlmeVRpbWVzdGFtcA0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiA8PSBi ZGJfZXF1YWxpdHlfY2FuZGlkYXRlczogKHNjTWFqb3JWZXJzaW9uKSBub3QgaW5kZXhlZA0KU2Vw IDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiA8PSBiZGJfZXF1YWxpdHlfY2FuZGlk YXRlczogKHNjTWlub3JWZXJzaW9uKSBub3QgaW5kZXhlZA0KU2VwIDI1IDAwOjQwOjE4IGxsdGQw MDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNTQ0IG9wPTIzIFNFQVJDSCBSRVNVTFQgdGFnPTEwMSBl cnI9MCBuZW50cmllcz0xIHRleHQ9DQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0 OF06IGNvbm49MzIyNTYgb3A9NjEgTU9EIGRuPSJlcD10My1tMmViLXExMDBjc2k4bTcudmNpLmF0 dC5jb218NTMyODIsdmVyPTY0LjAuMTYsY249SW5xdWlyZURTTFNlcnZpY2VEZXRhaWwsb3U9bTJl LG91PWNzaSxvdT1hdHQsb3U9Y29tLG8NCnU9U2VydmljZXMsb3U9UEVSRixvdT1FbnZpcm9ubWVu dHMsbz1zY2xkLGRjPWF0dCxkYz1jb20iDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsy NzQ0OF06IGNvbm49MzIyNTYgb3A9NjEgTU9EIGF0dHI9c2NTdGF0dXNDaGVja1RpbWUgc2NFeHBp cmF0aW9uVGltZQ0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMy MjU2IG9wPTYxIFJFU1VMVCB0YWc9MTAzIGVycj0wIHRleHQ9DQpTZXAgMjUgMDA6NDA6MTggbGx0 ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzIzNDMgb3A9MzE1IFNSQ0ggYmFzZT0iY249SW5xdWly ZVN1YnNjcmliZXJQcm9maWxlLG91PW0yZSxvdT1jc2ksb3U9YXR0LG91PWNvbSxvdT1TZXJ2aWNl cyxvdT1URVNULG91PUVudmlyb25tZW50cyxvPXNjbGQsZGM9YXQNCnQsZGM9Y29tIiBzY29wZT0y IGRlcmVmPTMgZmlsdGVyPSIoJihvYmplY3RDbGFzcz1zY1NlcnZpY2VFbmRQb2ludCkoc2NNYWpv clZlcnNpb249NjQpKHNjTWlub3JWZXJzaW9uPj0wKSh8KHNjUm91dGVPZmZlcj1xMjdhKSkoIShz Y0RlbGV0ZWRUaW1lPSopKSkiDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06 IGNvbm49MzIzNDMgb3A9MzE1IFNSQ0ggYXR0cj0qIGNyZWF0ZVRpbWVzdGFtcCBtb2RpZnlUaW1l c3RhbXANClNlcCAyNSAwMDo0MDoxOCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogPD0gYmRiX2VxdWFs aXR5X2NhbmRpZGF0ZXM6IChzY01ham9yVmVyc2lvbikgbm90IGluZGV4ZWQNClNlcCAyNSAwMDo0 MDoxOCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogPD0gYmRiX2luZXF1YWxpdHlfY2FuZGlkYXRlczog KHNjTWlub3JWZXJzaW9uKSBub3QgaW5kZXhlZA0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xh cGRbMjc0NDhdOiBjb25uPTMyMzQzIG9wPTMxNSBTRUFSQ0ggUkVTVUxUIHRhZz0xMDEgZXJyPTAg bmVudHJpZXM9MCB0ZXh0PQ0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBj b25uPTMxOTc3IG9wPTExMCBNT0QgZG49ImVwPXQxLW0yZWItcTEwMGNzaTdtNy52Y2kuYXR0LmNv bXwzNDU1MCx2ZXI9NjQuMC4xNyxjbj1BdXRob3JpemVMT0FVcGRhdGUsb3U9bTJlLG91PWNzaSxv dT1hdHQsb3U9Y29tLG91PVNlDQpydmljZXMsb3U9UEVSRixvdT1FbnZpcm9ubWVudHMsbz1zY2xk LGRjPWF0dCxkYz1jb20iDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNv bm49MzE5Nzcgb3A9MTEwIE1PRCBhdHRyPXNjU3RhdHVzQ2hlY2tUaW1lIHNjRXhwaXJhdGlvblRp bWUNClNlcCAyNSAwMDo0MDoxOCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMTk3NyBvcD0x MTAgUkVTVUxUIHRhZz0xMDMgZXJyPTAgdGV4dD0NClNlcCAyNSAwMDo0MDoxOCBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjQ1OSBvcD0zMjIgU1JDSCBiYXNlPSJjbj1JbnF1aXJlU3Vic2Ny aWJlclRlcm1zQW5kQ29uZGl0aW9ucyxvdT1tMmUsb3U9Y3NpLG91PWF0dCxvdT1jb20sb3U9U2Vy dmljZXMsb3U9UEVSRixvdT1FbnZpcm9ubWVudHMsbw0KPXNjbGQsZGM9YXR0LGRjPWNvbSIgc2Nv cGU9MiBkZXJlZj0zIGZpbHRlcj0iKCYob2JqZWN0Q2xhc3M9c2NTZXJ2aWNlRW5kUG9pbnQpKHNj TWFqb3JWZXJzaW9uPTY0KShzY01pbm9yVmVyc2lvbj0wKShzY1BhdGNoVmVyc2lvbj0yMCkoc2NI b3N0QWRkcmVzcz10My1tMmViLXExMDBjc2k4bTcudmNpDQouYXR0LmNvbSkoc2NMaXN0ZW5Qb3J0 PTUzMjgyKSghKHNjRGVsZXRlZFRpbWU9KikpKSINClNlcCAyNSAwMDo0MDoxOCBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjQ1OSBvcD0zMjIgU1JDSCBhdHRyPSogY3JlYXRlVGltZXN0YW1w IG1vZGlmeVRpbWVzdGFtcA0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiA8 PSBiZGJfZXF1YWxpdHlfY2FuZGlkYXRlczogKHNjTWFqb3JWZXJzaW9uKSBub3QgaW5kZXhlZA0K U2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiA8PSBiZGJfZXF1YWxpdHlfY2Fu ZGlkYXRlczogKHNjTWlub3JWZXJzaW9uKSBub3QgaW5kZXhlZA0KU2VwIDI1IDAwOjQwOjE4IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDU5IG9wPTMyMiBTRUFSQ0ggUkVTVUxUIHRhZz0x MDEgZXJyPTAgbmVudHJpZXM9MSB0ZXh0PQ0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRb Mjc0NDhdOiBjb25uPTMyNDU5IG9wPTMyMyBNT0QgZG49ImVwPXQzLW0yZWItcTEwMGNzaThtNy52 Y2kuYXR0LmNvbXw1MzI4Mix2ZXI9NjQuMC4yMCxjbj1JbnF1aXJlU3Vic2NyaWJlclRlcm1zQW5k Q29uZGl0aW9ucyxvdT1tMmUsb3U9Y3NpLG91DQo9YXR0LG91PWNvbSxvdT1TZXJ2aWNlcyxvdT1Q RVJGLG91PUVudmlyb25tZW50cyxvPXNjbGQsZGM9YXR0LGRjPWNvbSINClNlcCAyNSAwMDo0MDox OCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ1OSBvcD0zMjMgTU9EIGF0dHI9c2NTdGF0 dXNDaGVja1RpbWUgc2NFeHBpcmF0aW9uVGltZQ0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xh cGRbMjc0NDhdOiBjb25uPTMyNDU5IG9wPTMyMyBSRVNVTFQgdGFnPTEwMyBlcnI9MCB0ZXh0PQ0K U2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDAg U1JDSCBiYXNlPSJjbj1BZGRXaXJlbGluZU5vdGUsb3U9bTJlLG91PWNzaSxvdT1hdHQsb3U9Y29t LG91PVNlcnZpY2VzLG91PVRFU1Qsb3U9RW52aXJvbm1lbnRzLG89c2NsZCxkYz1hdHQsZGM9Y29t DQoiIHNjb3BlPTIgZGVyZWY9MyBmaWx0ZXI9IigmKG9iamVjdENsYXNzPXNjU2VydmljZUVuZFBv aW50KShzY01ham9yVmVyc2lvbj02Mikoc2NNaW5vclZlcnNpb249MCkoc2NQYXRjaFZlcnNpb249 NDMpKHNjSG9zdEFkZHJlc3M9ZDFhLW0yZS1xMTEybTJlMS5lZGMuY2luZ3VsYXIubmV0KShzY0xp c3QNCmVuUG9ydD00MDMzOSkoIShzY0RlbGV0ZWRUaW1lPSopKSkiDQpTZXAgMjUgMDA6NDA6MTgg bGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49NjczMiBvcD0yODUwMCBTUkNIIGF0dHI9KiBjcmVh dGVUaW1lc3RhbXAgbW9kaWZ5VGltZXN0YW1wDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFw ZFsyNzQ0OF06IDw9IGJkYl9lcXVhbGl0eV9jYW5kaWRhdGVzOiAoc2NNYWpvclZlcnNpb24pIG5v dCBpbmRleGVkDQpTZXAgMjUgMDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IDw9IGJkYl9l cXVhbGl0eV9jYW5kaWRhdGVzOiAoc2NNaW5vclZlcnNpb24pIG5vdCBpbmRleGVkDQpTZXAgMjUg MDA6NDA6MTggbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49NjczMiBvcD0yODUwMCBTRUFSQ0gg UkVTVUxUIHRhZz0xMDEgZXJyPTAgbmVudHJpZXM9MSB0ZXh0PQ0KU2VwIDI1IDAwOjQwOjE4IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDEgTU9EIGRuPSJlcD1kMWEtbTJl LXExMTJtMmUxLmVkYy5jaW5ndWxhci5uZXR8NDAzMzksdmVyPTYyLjAuNDMsY249QWRkV2lyZWxp bmVOb3RlLG91PW0yZSxvdT1jc2ksb3U9YXR0LG91PWNvbSxvdT1TDQplcnZpY2VzLG91PVRFU1Qs b3U9RW52aXJvbm1lbnRzLG89c2NsZCxkYz1hdHQsZGM9Y29tIg0KU2VwIDI1IDAwOjQwOjE4IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDEgTU9EIGF0dHI9c2NTdGF0dXND aGVja1RpbWUgc2NFeHBpcmF0aW9uVGltZQ0KU2VwIDI1IDAwOjQwOjE4IGxsdGQwMDQgc2xhcGRb Mjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDEgUkVTVUxUIHRhZz0xMDMgZXJyPTAgdGV4dD0NClNl cCAyNSAwMDo0MDoxOSBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj02NzMyIG9wPTI4NTAyIFNS Q0ggYmFzZT0iY2k9dDNwdGUybTMuaHlkYy5zYmMuY29tfDE1NjE5LHZlcj02Mi4wLjQsY249SW5x dWlyZVVuaWZpZWRDdXN0b21lclNlcnZpY2VQcm9maWxlLG91PW0yZSxvdT1jc2ksb3U9YXR0LA0K b3U9Y29tLG91PUNvbnRhaW5lcnMsb3U9UEVSRixvdT1FbnZpcm9ubWVudHMsbz1zY2xkLGRjPWF0 dCxkYz1jb20iIHNjb3BlPTIgZGVyZWY9MyBmaWx0ZXI9IigmKG9iamVjdENsYXNzPXNjQ29udGFp bmVySW5zdGFuY2UpKCEoc2NEZWxldGVkVGltZT0qKSkpIg0KU2VwIDI1IDAwOjQwOjE5IGxsdGQw MDQgc2xhcGRbMjc0NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDIgU1JDSCBhdHRyPSogY3JlYXRlVGlt ZXN0YW1wIG1vZGlmeVRpbWVzdGFtcA0KU2VwIDI1IDAwOjQwOjE5IGxsdGQwMDQgc2xhcGRbMjc0 NDhdOiBjb25uPTY3MzIgb3A9Mjg1MDIgU0VBUkNIIFJFU1VMVCB0YWc9MTAxIGVycj0wIG5lbnRy aWVzPTEgdGV4dD0NClNlcCAyNSAwMDo0MDoxOSBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj02 NzMyIG9wPTI4NTAzIE1PRCBkbj0iY2k9dDNwdGUybTMuaHlkYy5zYmMuY29tfDE1NjE5LHZlcj02 Mi4wLjQsY249SW5xdWlyZVVuaWZpZWRDdXN0b21lclNlcnZpY2VQcm9maWxlLG91PW0yZSxvdT1j c2ksb3U9YXR0LG91PQ0KY29tLG91PUNvbnRhaW5lcnMsb3U9UEVSRixvdT1FbnZpcm9ubWVudHMs bz1zY2xkLGRjPWF0dCxkYz1jb20iDQpTZXAgMjUgMDA6NDA6MTkgbGx0ZDAwNCBzbGFwZFsyNzQ0 OF06IGNvbm49NjczMiBvcD0yODUwMyBNT0QgYXR0cj1zY0V4cGlyYXRpb25UaW1lDQpTZXAgMjUg MDA6NDA6MTkgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49NjczMiBvcD0yODUwMyBSRVNVTFQg dGFnPTEwMyBlcnI9MCB0ZXh0PQ0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhd OiBjb25uPTMyNDYyIG9wPTIgVU5CSU5EDQpTZXAgMjUgMDA6NDA6MjQgbGx0ZDAwNCBzbGFwZFsy NzQ0OF06IGNvbm49MzI0NjIgZmQ9MzA3IGNsb3NlZA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQg c2xhcGRbMjc0NDhdOiBjb25uPTMyNDYzIG9wPTIgVU5CSU5EDQpTZXAgMjUgMDA6NDA6MjQgbGx0 ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI0NjMgZmQ9MzI1IGNsb3NlZA0KU2VwIDI1IDAwOjQw OjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDY0IG9wPTIgVU5CSU5EDQpTZXAgMjUg MDA6NDA6MjQgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI0NjQgZmQ9MzI2IGNsb3NlZA0K U2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uZWN0aW9uX3JlYWQoMzA3 KTogbm8gY29ubmVjdGlvbiENClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTog Y29ubj0zMjQ2NiBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0 NDhdOiBjb25uPTMyNDY2IGZkPTMyOCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjQ2NSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQw MDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDY1IGZkPTMyNyBjbG9zZWQNClNlcCAyNSAwMDo0MDoy NCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ2NyBvcD0yIFVOQklORA0KU2VwIDI1IDAw OjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDY3IGZkPTMyOSBjbG9zZWQNClNl cCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ2OCBvcD0yIFVOQklO RA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDY4IGZkPTMz MCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3 NSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25u PTMyNDc1IGZkPTMzOCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4 XTogY29ubj0zMjQ3NCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRb Mjc0NDhdOiBjb25uPTMyNDc0IGZkPTMzNyBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0 IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3MyBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDczIGZkPTMzNiBjbG9zZWQNClNlcCAyNSAwMDo0 MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3MiBvcD0yIFVOQklORA0KU2VwIDI1 IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDcyIGZkPTMzNSBjbG9zZWQN ClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3MSBvcD0yIFVO QklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDcxIGZk PTMzNCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0z MjQ3MCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBj b25uPTMyNDcwIGZkPTMzMiBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjQ2OSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xh cGRbMjc0NDhdOiBjb25uPTMyNDY5IGZkPTMzMSBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRk MDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3NyBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0 IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDc3IGZkPTM0MCBjbG9zZWQNClNlcCAyNSAw MDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3NiBvcD0yIFVOQklORA0KU2Vw IDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDc2IGZkPTMzOSBjbG9z ZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3OCBvcD0y IFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDc4 IGZkPTM0MSBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMjQ4MyBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhd OiBjb25uPTMyNDgzIGZkPTM1MSBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBk WzI3NDQ4XTogY29ubj0zMjQ4MiBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQg c2xhcGRbMjc0NDhdOiBjb25uPTMyNDgyIGZkPTM1MCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBs bHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ4MSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQw OjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDgxIGZkPTM0OSBjbG9zZWQNClNlcCAy NSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ4MCBvcD0yIFVOQklORA0K U2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDgwIGZkPTM0OCBj bG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ3OSBv cD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMy NDc5IGZkPTM0NyBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTog Y29ubj0zMjQ4NCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0 NDhdOiBjb25uPTMyNDg0IGZkPTM1MiBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjQ4NiBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQw MDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDg2IGZkPTM1NCBjbG9zZWQNClNlcCAyNSAwMDo0MDoy NCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ4NSBvcD0yIFVOQklORA0KU2VwIDI1IDAw OjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDg1IGZkPTM1MyBjbG9zZWQNClNl cCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ4OCBvcD0yIFVOQklO RA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDg4IGZkPTM1 NiBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ4 NyBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25u PTMyNDg3IGZkPTM1NSBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4 XTogY29ubj0zMjQ4OSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRb Mjc0NDhdOiBjb25uPTMyNDg5IGZkPTM1NyBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0 IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5MCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDkwIGZkPTM1OCBjbG9zZWQNClNlcCAyNSAwMDo0 MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5MSBvcD0yIFVOQklORA0KU2VwIDI1 IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDkxIGZkPTM1OSBjbG9zZWQN ClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5MiBvcD0yIFVO QklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDkyIGZk PTM2MCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0z MjQ5NCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBj b25uPTMyNDk0IGZkPTM2MiBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjQ5MyBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xh cGRbMjc0NDhdOiBjb25uPTMyNDkzIGZkPTM2MSBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRk MDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5NSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0 IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDk1IGZkPTM2MyBjbG9zZWQNClNlcCAyNSAw MDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5NyBvcD0yIFVOQklORA0KU2Vw IDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDk3IGZkPTM2NSBjbG9z ZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5NiBvcD0y IFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDk2 IGZkPTM2NCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMjQ5OCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhd OiBjb25uPTMyNDk4IGZkPTM2NiBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBk WzI3NDQ4XTogY29ubj0zMjUwMCBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQg c2xhcGRbMjc0NDhdOiBjb25uPTMyNTAwIGZkPTM2OCBjbG9zZWQNClNlcCAyNSAwMDo0MDoyNCBs bHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjQ5OSBvcD0yIFVOQklORA0KU2VwIDI1IDAwOjQw OjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNDk5IGZkPTM2NyBjbG9zZWQNClNlcCAy NSAwMDo0MDoyNCBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUwMSBvcD0yIFVOQklORA0K U2VwIDI1IDAwOjQwOjI0IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyNTAxIGZkPTM2OSBj bG9zZWQNClNlcCAyNSAwMDo0MTowNSBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjYwOCBm ZD0xODAgY2xvc2VkICh3cml0ZXRpbWVvdXQpDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFw ZFsyNzQ0OF06IGNvbm49MzI1MDQgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0 IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUwNCBmZD01NDIgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDYg bGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MDUgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0 MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUwNSBmZD01NDMgY2xvc2VkDQpTZXAg MjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MDcgb3A9MiBVTkJJTkQN ClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUwNyBmZD01NDcg Y2xvc2VkDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MDgg b3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0z MjUwOCBmZD01NDggY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06 IGNvbm49MzI1MDkgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjUwOSBmZD01NDkgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBz bGFwZFsyNzQ0OF06IGNvbm49MzI5NzIgZmQ9MTgwIEFDQ0VQVCBmcm9tIElQPTEzNS4yMDEuNzMu MTY3OjQ2ODEwIChJUD0xMzUuMjAxLjczLjE2NzoxMDgwNikNClNlcCAyNSAwMDo0MTowNiBsbHRk MDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjk3MiBvcD0wIEJJTkQgZG49ImNuPW1vbml0b3Isbz1z Y2xkLGRjPWF0dCxkYz1jb20iIG1ldGhvZD0xMjgNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjk3MiBvcD0wIEJJTkQgZG49ImNuPW1vbml0b3Isbz1zY2xkLGRj PWF0dCxkYz1jb20iIG1lY2g9U0lNUExFIHNzZj0wDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBz bGFwZFsyNzQ0OF06IGNvbm49MzI5NzIgb3A9MCBSRVNVTFQgdGFnPTk3IGVycj0wIHRleHQ9DQpT ZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI5NzIgb3A9MSBTUkNI IGJhc2U9Im89c2NsZCxkYz1hdHQsZGM9Y29tIiBzY29wZT0wIGRlcmVmPTAgZmlsdGVyPSIob2Jq ZWN0Q2xhc3M9KikiDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49 MzI5NzIgb3A9MSBTUkNIIGF0dHI9ZG4NClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjk3MiBvcD0xIFNFQVJDSCBSRVNVTFQgdGFnPTEwMSBlcnI9MCBuZW50cmll cz0xIHRleHQ9DQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI5 NzIgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMjk3MiBmZD0xODAgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0 OF06IGRvX3N5bmNyZXAyOiByaWQ9MDAzICgtMSkgQ2FuJ3QgY29udGFjdCBMREFQIHNlcnZlcg0K U2VwIDI1IDAwOjQxOjA2IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBkb19zeW5jcmVwbDogcmlkPTAw MyByYyAtMSByZXRyeWluZw0KU2VwIDI1IDAwOjQxOjA2IGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBk b19zeW5jcmVwMjogcmlkPTAwMiAoLTEpIENhbid0IGNvbnRhY3QgTERBUCBzZXJ2ZXINClNlcCAy NSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogZG9fc3luY3JlcGw6IHJpZD0wMDIgcmMg LTEgcmV0cnlpbmcNClNlcCAyNSAwMDo0MTowNiBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogZG9fc3lu Y3JlcDI6IHJpZD0wMDQgKC0xKSBDYW4ndCBjb250YWN0IExEQVAgc2VydmVyDQpTZXAgMjUgMDA6 NDE6MDYgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGRvX3N5bmNyZXBsOiByaWQ9MDA0IHJjIC0xIHJl dHJ5aW5nDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MTIg b3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0z MjUxMiBmZD00MzggY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06 IGNvbm49MzI1MTQgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjUxNCBmZD00NDAgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBz bGFwZFsyNzQ0OF06IGNvbm49MzI1MTMgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRk MDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUxMyBmZD00MzkgY2xvc2VkDQpTZXAgMjUgMDA6NDE6 MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MTggb3A9MiBVTkJJTkQNClNlcCAyNSAw MDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUxOCBmZD00NDQgY2xvc2VkDQpT ZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MTcgb3A9MiBVTkJJ TkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUxNyBmZD00 NDMgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1 MTYgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMjUxNiBmZD00NDIgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0 OF06IGNvbm49MzI1MTUgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBk WzI3NDQ4XTogY29ubj0zMjUxNSBmZD00NDEgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAw NCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MTkgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBs bHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUxOSBmZD00NDUgY2xvc2VkDQpTZXAgMjUgMDA6 NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MjAgb3A9MiBVTkJJTkQNClNlcCAy NSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyMCBmZD00NDYgY2xvc2Vk DQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MjEgb3A9MiBV TkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyMSBm ZD00NDcgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49 MzI1MjIgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTog Y29ubj0zMjUyMiBmZD00NDggY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsy NzQ0OF06IGNvbm49MzI1MjQgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNs YXBkWzI3NDQ4XTogY29ubj0zMjUyNCBmZD00NTAgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0 ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MjMgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTow NyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyMyBmZD00NDkgY2xvc2VkDQpTZXAgMjUg MDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MjUgb3A9MiBVTkJJTkQNClNl cCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyNSBmZD00NTEgY2xv c2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MjYgb3A9 MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUy NiBmZD00NTIgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNv bm49MzI1Mjcgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4 XTogY29ubj0zMjUyNyBmZD00NTMgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFw ZFsyNzQ0OF06IGNvbm49MzI1Mjggb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0 IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyOCBmZD00NTQgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcg bGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1Mjkgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0 MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUyOSBmZD00NTUgY2xvc2VkDQpTZXAg MjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MzAgb3A9MiBVTkJJTkQN ClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUzMCBmZD00NTYg Y2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MzEg b3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0z MjUzMSBmZD00NTcgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06 IGNvbm49MzI1MzIgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3 NDQ4XTogY29ubj0zMjUzMiBmZD00NTggY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBz bGFwZFsyNzQ0OF06IGNvbm49MzI1MzQgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRk MDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUzNCBmZD00NjAgY2xvc2VkDQpTZXAgMjUgMDA6NDE6 MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MzMgb3A9MiBVTkJJTkQNClNlcCAyNSAw MDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUzMyBmZD00NTkgY2xvc2VkDQpT ZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1MzUgb3A9MiBVTkJJ TkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29ubj0zMjUzNSBmZD00 NjQgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDcgbGx0ZDAwNCBzbGFwZFsyNzQ0OF06IGNvbm49MzI1 MzYgb3A9MiBVTkJJTkQNClNlcCAyNSAwMDo0MTowNyBsbHRkMDA0IHNsYXBkWzI3NDQ4XTogY29u bj0zMjUzNiBmZD00NjUgY2xvc2VkDQpTZXAgMjUgMDA6NDE6MDkgbGx0ZDAwNCBzbGFwZFsyNzQ0 OF06IGNvbm49MzIzNzUgb3A9MyBVTkJJTkQNClNlcCAyNSAwMDo0MTowOSBsbHRkMDA0IHNsYXBk WzI3NDQ4XTogY29ubj0zMjM3NSBmZD01NyBjbG9zZWQNClNlcCAyNSAwMDo0MTowOSBsbHRkMDA0 IHNsYXBkWzI3NDQ4XTogY29ubj0zMjM3NCBvcD01IFVOQklORA0KU2VwIDI1IDAwOjQxOjA5IGxs dGQwMDQgc2xhcGRbMjc0NDhdOiBjb25uPTMyMzc0IGZkPTUxIGNsb3NlZA0KU2VwIDI1IDAxOjI0 OjMzIGxsdGQwMDQgc2xhcGRbMjc0NDhdOiBkYWVtb246IHNodXRkb3duIHJlcXVlc3RlZCBhbmQg aW5pdGlhdGVkLg0K --_004_0F8C8B668A69F44A8B738E6522AF86186EAAB7GAALPA1MSGUSR9PIT_--

1 0

(ITS#7402) Invalid DN 21
by agarcia＠tempel.es 25 Sep '12

25 Sep '12

Full_Name: Aitor Garcia Version: openldap-servers-2.4.23-26.el6_3.2.x86_64 OS: CentOS release 6.3 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.33.152.6) I've configured my DB suffix at /etc/openldap/slapd.conf > suffix "o=Iddover, c=Net" But slapd doesn't like the dn, if I've used "cn=Iddover, cn=Net" slapd start normally. Sep 25 16:03:41 r300te1 slapd[15756]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 8 2012 16:29:21) $#012#011mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd Sep 25 16:03:41 r300te1 slapd[15756]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) Sep 25 16:03:41 r300te1 slapd[15756]: line 24 (allow bind_v2) Sep 25 16:03:41 r300te1 slapd[15756]: line 30 (pidfile#011#011/var/run/openldap/slapd.pid) Sep 25 16:03:41 r300te1 slapd[15756]: line 31 (argsfile#011/var/run/openldap/slapd.args) Sep 25 16:03:41 r300te1 slapd[15756]: line 93 (access to * by * read) Sep 25 16:03:41 r300te1 slapd[15756]: line 107 (database bdb) Sep 25 16:03:41 r300te1 slapd[15756]: bdb_db_init: Initializing BDB database Sep 25 16:03:41 r300te1 slapd[15756]: line 109 (suffix "o=Iddover, c=Net") Sep 25 16:03:41 r300te1 slapd[15756]: >>> dnPrettyNormal: <o=Iddover, c=Net> Sep 25 16:03:41 r300te1 slapd[15756]: /etc/openldap/slapd.conf: line 109: <suffix> invalid DN 21 (Invalid syntax) Sep 25 16:03:41 r300te1 slapd[15756]: slapd destroy: freeing system resources. Sep 25 16:03:41 r300te1 slapd[15756]: slapd stopped. Sep 25 16:03:41 r300te1 slapd[15756]: connections_destroy: nothing to destroy.

1 0

(ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 25 Sep '12

25 Sep '12

Full_Name: Venkatesh Baglodi Version: 2.4.32 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.160.226.53) We have been facing occasional deadlock issues when using OpenLDAP in multi-master mode (4 servers). It looks like deadlocks are occuring on objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks like the server is out of disk space. Some of the traces are provided below: db_stat -CA =========== Default locking region information: 254 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 2400 Initial number of locks allocated 0 Initial number of lockers allocated 2400 Initial number of lock objects allocated 0 Maximum number of locks possible 0 Maximum number of lockers possible 0 Maximum number of lock objects possible 2400 Current number of locks allocated 188 Current number of lockers allocated 2400 Current number of lock objects allocated 480 Number of lock object partitions 4099 Size of object hash table 91 Number of current locks 7765 Maximum number of locks at any one time 88 Maximum number of locks in any one bucket 248550 Maximum number of locks stolen by for an empty partition 665 Maximum number of locks stolen for any one partition 79 Number of current lockers 185 Maximum number of lockers at any one time 33 Number of current lock objects 1779 Maximum number of lock objects at any one time 4 Maximum number of lock objects in any one bucket 15 Maximum number of objects stolen by for an empty partition 2 Maximum number of objects stolen for any one partition 1175M Total number of locks requested (1175730771) 1174M Total number of locks released (1174938911) 0 Total number of locks upgraded 163 Total number of locks downgraded 1058324 Lock requests not available due to conflicts, for which we waited 459038 Lock requests not available due to conflicts, for which we did not wait 84153 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 3MB 336KB Region size 5804758 The number of partition locks that required waiting (0%) 50948 The maximum number of times any partition lock was waited for (0%) 701 The number of object queue operations that required waiting (0%) 1703227 The number of locker allocations that required waiting (0%) 243743 The number of region locks that required waiting (0%) 5 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /opt/app/aft/scldldap/var/data/o=scld,dc=att,dc=com/__db.001 Region name 0x2b9be30d3000 Region address 0x2b9be30d30a0 Region allocation head 0x2b9be32d35b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 30466493 allocations, 0 failures, 30465357 frees, 10 longest Allocations by power-of-two sizes: 1KB 30466479 2KB 3 4KB 4 8KB 3 16KB 0 32KB 0 64KB 1 128KB 1 256KB 0 512KB 1 1024KB 1 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [243743/281M 0% 27451/47948529212608] <wakeups 0/15779> 257 locker table size 4099 object table size 2099280 obj_off 2567960 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 81b47648 dd=43 locks held 0 write locks 0 pid/thread 27448/1165564224 flags 0 priority 100 81b47648 READ 1 WAIT objectClass.bdb page 3 81b3bf98 dd=67 locks held 0 write locks 0 pid/thread 27448/1106815296 flags 0 priority 100 81b3bf98 READ 1 WAIT objectClass.bdb page 3 81b84f43 dd=10 locks held 0 write locks 0 pid/thread 27448/1425738048 flags 0 priority 100 81b84f43 READ 1 WAIT objectClass.bdb page 3 81b3c4be dd=57 locks held 0 write locks 0 pid/thread 27448/1140386112 flags 0 priority 100 81b3c4be READ 1 WAIT objectClass.bdb page 3 81b84f46 dd= 9 locks held 0 write locks 0 pid/thread 27448/1434130752 flags 0 priority 100 81b84f46 READ 1 WAIT objectClass.bdb page 3 81b84f49 dd= 8 locks held 0 write locks 0 pid/thread 27448/1442523456 flags 0 priority 100 81b84f49 READ 1 WAIT objectClass.bdb page 3 81b71512 dd=38 locks held 0 write locks 0 pid/thread 27448/1190742336 flags 0 priority 100 81b71512 READ 1 WAIT objectClass.bdb page 3 81b71515 dd=37 locks held 0 write locks 0 pid/thread 27448/1199135040 flags 0 priority 100 81b71515 READ 1 WAIT objectClass.bdb page 3 81b71518 dd=36 locks held 0 write locks 0 pid/thread 27448/1207527744 flags 0 priority 100 81b71518 READ 1 WAIT objectClass.bdb page 3 81b84f52 dd= 7 locks held 0 write locks 0 pid/thread 27448/1450916160 flags 0 priority 100 81b84f52 READ 1 WAIT objectClass.bdb page 3 81b84f55 dd= 6 locks held 0 write locks 0 pid/thread 27448/1459308864 flags 0 priority 100 81b84f55 READ 1 WAIT objectClass.bdb page 3 81b7151d dd=35 locks held 0 write locks 0 pid/thread 27448/1215920448 flags 0 priority 100 81b7151d READ 1 WAIT objectClass.bdb page 3 81b84f58 dd= 5 locks held 0 write locks 0 pid/thread 27448/1467701568 flags 0 priority 100 81b84f58 READ 1 WAIT objectClass.bdb page 3 81b71520 dd=34 locks held 0 write locks 0 pid/thread 27448/1224313152 flags 0 priority 100 81b71520 READ 1 WAIT objectClass.bdb page 3 81b71521 dd=33 locks held 1 write locks 1 pid/thread 27448/1232705856 flags 0 priority 100 81b71521 WRITE 1 HELD objectClass.bdb page 3 81b84f5b dd= 4 locks held 0 write locks 0 pid/thread 27448/1476094272 flags 0 priority 100 81b84f5b READ 1 WAIT objectClass.bdb page 3 81b3c4d5 dd=56 locks held 0 write locks 0 pid/thread 27448/1148778816 flags 0 priority 100 81b3c4d5 READ 1 WAIT objectClass.bdb page 3 81b71524 dd=32 locks held 0 write locks 0 pid/thread 27448/1241098560 flags 0 priority 100 81b71524 READ 1 WAIT objectClass.bdb page 3 81b84f5e dd= 3 locks held 0 write locks 0 pid/thread 27448/1484486976 flags 0 priority 100 81b84f5e READ 1 WAIT objectClass.bdb page 3 81b84f5f dd= 2 locks held 0 write locks 0 pid/thread 27448/1492879680 flags 0 priority 100 81b84f5f READ 1 WAIT objectClass.bdb page 3 81b71529 dd=31 locks held 0 write locks 0 pid/thread 27448/1249491264 flags 0 priority 100 81b71529 READ 1 WAIT objectClass.bdb page 3 81b7152a dd=30 locks held 0 write locks 0 pid/thread 27448/1257883968 flags 0 priority 100 81b7152a READ 1 WAIT objectClass.bdb page 3 81b7152d dd=29 locks held 0 write locks 0 pid/thread 27448/1266276672 flags 0 priority 100 81b7152d READ 1 WAIT objectClass.bdb page 3 81b71530 dd=28 locks held 0 write locks 0 pid/thread 27448/1274669376 flags 0 priority 100 81b71530 READ 1 WAIT objectClass.bdb page 3 81b71533 dd=27 locks held 0 write locks 0 pid/thread 27448/1283062080 flags 0 priority 100 81b71533 READ 1 WAIT objectClass.bdb page 3 81b71536 dd=26 locks held 0 write locks 0 pid/thread 27448/1291454784 flags 0 priority 100 81b71536 READ 1 WAIT objectClass.bdb page 3 81b3c0e5 dd=66 locks held 0 write locks 0 pid/thread 27448/1115208000 flags 0 priority 100 81b3c0e5 READ 1 WAIT objectClass.bdb page 3 81b71539 dd=25 locks held 0 write locks 0 pid/thread 27448/1299847488 flags 0 priority 100 81b7153c dd=24 locks held 0 write locks 0 pid/thread 27448/1308240192 flags 0 priority 100 81b7153c READ 1 WAIT objectClass.bdb page 3 81b7153f dd=23 locks held 0 write locks 0 pid/thread 27448/1316632896 flags 0 priority 100 81b7153f READ 1 WAIT objectClass.bdb page 3 81b55581 dd=42 locks held 0 write locks 0 pid/thread 27448/1173956928 flags 0 priority 100 81b55581 READ 1 WAIT objectClass.bdb page 3 81b71542 dd=22 locks held 0 write locks 0 pid/thread 27448/1325025600 flags 0 priority 100 81b71542 READ 1 WAIT objectClass.bdb page 3 81b71545 dd=21 locks held 0 write locks 0 pid/thread 27448/1333418304 flags 0 priority 100 81b71545 READ 1 WAIT objectClass.bdb page 3 81b71548 dd=20 locks held 0 write locks 0 pid/thread 27448/1341811008 flags 0 priority 100 81b71548 READ 1 WAIT objectClass.bdb page 3 81b3ca00 dd=55 locks held 0 write locks 0 pid/thread 27448/1157171520 flags 0 priority 100 81b3ca00 READ 1 WAIT objectClass.bdb page 3 81b7154b dd=19 locks held 0 write locks 0 pid/thread 27448/1350203712 flags 0 priority 100 81b7154b READ 1 WAIT objectClass.bdb page 3 81b7154e dd=18 locks held 0 write locks 0 pid/thread 27448/1358596416 flags 0 priority 100 81b7154e READ 1 WAIT objectClass.bdb page 3 81b71551 dd=17 locks held 0 write locks 0 pid/thread 27448/1366989120 flags 0 priority 100 81b71551 READ 1 WAIT objectClass.bdb page 3 81b71554 dd=16 locks held 0 write locks 0 pid/thread 27448/1375381824 flags 0 priority 100 81b71554 READ 1 WAIT objectClass.bdb page 3 81b71559 dd=15 locks held 0 write locks 0 pid/thread 27448/1383774528 flags 0 priority 100 81b71559 READ 1 WAIT objectClass.bdb page 3 81c57cb3 dd= 0 locks held 2 write locks 0 pid/thread 27448/1232705856 flags 0 priority 100 81c57cb3 READ 1 HELD 0x27a480 len: 9 data: 718c00000000000000 81c57cb3 READ 1 HELD 0x283700 len: 9 data: 90bd05000000000000 81b7155a dd=14 locks held 0 write locks 0 pid/thread 27448/1392167232 flags 0 priority 100 81b7155a READ 1 WAIT objectClass.bdb page 3 81c57cb4 dd= 0 locks held 16 write locks 8 pid/thread 27448/1232705856 flags 0 priority 100 81c57cb4 READ 1 WAIT objectClass.bdb page 3 81c57cb4 WRITE 2 HELD objectClass.bdb page 129 81c57cb4 READ 2 HELD objectClass.bdb page 129 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 1453 81c57cb4 READ 2 HELD scRouteOffer.bdb page 1453 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 2462 81c57cb4 READ 2 HELD scRouteOffer.bdb page 2462 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 2242 81c57cb4 READ 2 HELD scRouteOffer.bdb page 2242 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 14 81c57cb4 READ 2 HELD scRouteOffer.bdb page 14 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 12 81c57cb4 READ 2 HELD scRouteOffer.bdb page 12 81c57cb4 WRITE 2 HELD dn2id.bdb page 8834 81c57cb4 WRITE 2 HELD dn2id.bdb page 2281 81c57cb4 READ 1 HELD dn2id.bdb page 2281 81c57cb4 READ 2 HELD dn2id.bdb page 8834 81b7155d dd=13 locks held 0 write locks 0 pid/thread 27448/1400559936 flags 0 priority 100 81b7155d READ 1 WAIT objectClass.bdb page 3 81b71560 dd=12 locks held 0 write locks 0 pid/thread 27448/1408952640 flags 0 priority 100 81b71560 READ 1 WAIT objectClass.bdb page 3 81b71563 dd=11 locks held 0 write locks 0 pid/thread 27448/1417345344 flags 0 priority 100 81b71563 READ 1 WAIT objectClass.bdb page 3 81b557ba dd=41 locks held 0 write locks 0 pid/thread 27448/1182349632 flags 0 priority 100 81b557ba READ 1 WAIT objectClass.bdb page 3 81b3cd43 dd=54 locks held 0 write locks 0 pid/thread 27448/1086777664 flags 0 priority 100 81b3cd43 READ 1 WAIT objectClass.bdb page 3 81b3bf42 dd=73 locks held 0 write locks 0 pid/thread 27448/47802396722192 flags 0 priority 100 81b3bf43 dd=72 locks held 0 write locks 0 pid/thread 27448/47802396722192 flags 0 priority 100 81b3bf44 dd=71 locks held 0 write locks 0 pid/thread 27448/1123600704 flags 0 priority 100 81b3bf44 READ 1 WAIT objectClass.bdb page 3 81c564f7 dd= 1 locks held 2 write locks 0 pid/thread 27448/1299847488 flags 0 priority 100 81c564f7 READ 1 HELD 0x2c5710 len: 9 data: b3c005000000000000 81c564f7 READ 1 HELD 0x28fb78 len: 9 data: 92ce05000000000000 81c564f8 dd= 1 locks held 4 write locks 2 pid/thread 27448/1299847488 flags 0 priority 100 81c564f8 READ 1 WAIT objectClass.bdb page 3 81c564f8 WRITE 2 HELD dn2id.bdb page 7794 81c564f8 READ 1 HELD dn2id.bdb page 7794 81c564f8 WRITE 2 HELD dn2id.bdb page 9612 81c564f8 READ 1 HELD dn2id.bdb page 9612 81b3bf69 dd=68 locks held 0 write locks 0 pid/thread 27448/1131993408 flags 0 priority 100 81b3bf69 READ 1 WAIT objectClass.bdb page 3 e3 dd=76 locks held 1 write locks 0 pid/thread 27448/47802396722192 flags 10 priority 100 e3 READ 1 HELD id2entry.bdb handle 0 e4 dd=75 locks held 1 write locks 0 pid/thread 27448/47802396722192 flags 10 priority 100 e4 READ 1 HELD dn2id.bdb handle 0 e5 dd=74 locks held 0 write locks 0 pid/thread 27448/47802396722192 flags 0 priority 100 e6 dd=70 locks held 1 write locks 0 pid/thread 27448/1123600704 flags 10 priority 100 e6 READ 1 HELD entryUUID.bdb handle 0 e7 dd=69 locks held 1 write locks 0 pid/thread 27448/1123600704 flags 10 priority 100 e7 READ 1 HELD entryCSN.bdb handle 0 e8 dd=65 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 e8 READ 1 HELD scRouteOffer.bdb handle 0 e9 dd=64 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 e9 READ 1 HELD objectClass.bdb handle 0 ea dd=63 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 ea READ 1 HELD scHostAddress.bdb handle 0 eb dd=62 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 eb READ 1 HELD scListenPort.bdb handle 0 ec dd=61 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 ec READ 1 HELD scLRMDN.bdb handle 0 ed dd=60 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 ed READ 1 HELD scPID.bdb handle 0 ee dd=59 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 ee READ 1 HELD scContainerInstanceName.bdb handle 0 ef dd=58 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 ef READ 1 HELD scPatchVersion.bdb handle 0 f0 dd=53 locks held 1 write locks 0 pid/thread 27448/1086777664 flags 10 priority 100 f0 READ 1 HELD scContainerInstanceDN.bdb handle 0 f1 dd=52 locks held 0 write locks 0 pid/thread 27448/1115208000 flags 0 priority 100 f2 dd=51 locks held 0 write locks 0 pid/thread 27448/1157171520 flags 0 priority 100 f3 dd=50 locks held 0 write locks 0 pid/thread 27448/1224313152 flags 0 priority 100 f4 dd=49 locks held 0 write locks 0 pid/thread 27448/1182349632 flags 0 priority 100 f5 dd=48 locks held 0 write locks 0 pid/thread 27448/1131993408 flags 0 priority 100 f6 dd=47 locks held 0 write locks 0 pid/thread 27448/1131993408 flags 0 priority 100 f7 dd=46 locks held 1 write locks 0 pid/thread 27448/1157171520 flags 10 priority 100 f7 READ 1 HELD scManagedResourceName.bdb handle 0 f8 dd=45 locks held 1 write locks 0 pid/thread 27448/1123600704 flags 10 priority 100 f8 READ 1 HELD scServiceDefinitionName.bdb handle 0 f9 dd=44 locks held 1 write locks 0 pid/thread 27448/1148778816 flags 10 priority 100 f9 READ 1 HELD scContainerDefinitionName.bdb handle 0 fa dd=40 locks held 1 write locks 0 pid/thread 27448/1131993408 flags 10 priority 100 fa READ 1 HELD scServiceVersionDefinitionName.bdb handle 0 fb dd=39 locks held 1 write locks 0 pid/thread 27448/1157171520 flags 10 priority 100 fb READ 1 HELD scContainerVersionDefinitionName.bdb handle 0 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- ee READ 1 HELD scContainerInstanceName.bdb handle 0 81c564f7 READ 1 HELD 0x28fb78 len: 9 data: 92ce05000000000000 ea READ 1 HELD scHostAddress.bdb handle 0 81c57cb3 READ 1 HELD 0x27a480 len: 9 data: 718c00000000000000 81c564f8 READ 1 HELD dn2id.bdb page 9612 81c564f8 WRITE 2 HELD dn2id.bdb page 9612 e7 READ 1 HELD entryCSN.bdb handle 0 81c57cb4 READ 2 HELD objectClass.bdb page 129 81c57cb4 WRITE 2 HELD objectClass.bdb page 129 f9 READ 1 HELD scContainerDefinitionName.bdb handle 0 ed READ 1 HELD scPID.bdb handle 0 e9 READ 1 HELD objectClass.bdb handle 0 81b71521 WRITE 1 HELD objectClass.bdb page 3 81c564f8 READ 1 WAIT objectClass.bdb page 3 81b3c4d5 READ 1 WAIT objectClass.bdb page 3 81b84f49 READ 1 WAIT objectClass.bdb page 3 81b7154b READ 1 WAIT objectClass.bdb page 3 81b71560 READ 1 WAIT objectClass.bdb page 3 81b7155d READ 1 WAIT objectClass.bdb page 3 81b3c4be READ 1 WAIT objectClass.bdb page 3 81b557ba READ 1 WAIT objectClass.bdb page 3 81b84f46 READ 1 WAIT objectClass.bdb page 3 81b7153f READ 1 WAIT objectClass.bdb page 3 81b71518 READ 1 WAIT objectClass.bdb page 3 81b71536 READ 1 WAIT objectClass.bdb page 3 81b71542 READ 1 WAIT objectClass.bdb page 3 81b71533 READ 1 WAIT objectClass.bdb page 3 81b71548 READ 1 WAIT objectClass.bdb page 3 81b3cd43 READ 1 WAIT objectClass.bdb page 3 81b7152d READ 1 WAIT objectClass.bdb page 3 81b71559 READ 1 WAIT objectClass.bdb page 3 81b84f52 READ 1 WAIT objectClass.bdb page 3 81b3c0e5 READ 1 WAIT objectClass.bdb page 3 81b71545 READ 1 WAIT objectClass.bdb page 3 81b3bf69 READ 1 WAIT objectClass.bdb page 3 81b84f43 READ 1 WAIT objectClass.bdb page 3 81b47648 READ 1 WAIT objectClass.bdb page 3 81b71520 READ 1 WAIT objectClass.bdb page 3 81b3bf98 READ 1 WAIT objectClass.bdb page 3 81b3ca00 READ 1 WAIT objectClass.bdb page 3 81b84f5e READ 1 WAIT objectClass.bdb page 3 81b7154e READ 1 WAIT objectClass.bdb page 3 81b84f5f READ 1 WAIT objectClass.bdb page 3 81b7151d READ 1 WAIT objectClass.bdb page 3 81b71530 READ 1 WAIT objectClass.bdb page 3 81b7152a READ 1 WAIT objectClass.bdb page 3 81b84f55 READ 1 WAIT objectClass.bdb page 3 81b7155a READ 1 WAIT objectClass.bdb page 3 81b71551 READ 1 WAIT objectClass.bdb page 3 81b7153c READ 1 WAIT objectClass.bdb page 3 81b71554 READ 1 WAIT objectClass.bdb page 3 81b55581 READ 1 WAIT objectClass.bdb page 3 81b71563 READ 1 WAIT objectClass.bdb page 3 81b84f58 READ 1 WAIT objectClass.bdb page 3 81b71515 READ 1 WAIT objectClass.bdb page 3 81b3bf44 READ 1 WAIT objectClass.bdb page 3 81b71529 READ 1 WAIT objectClass.bdb page 3 81b84f5b READ 1 WAIT objectClass.bdb page 3 81b71524 READ 1 WAIT objectClass.bdb page 3 81b71512 READ 1 WAIT objectClass.bdb page 3 81c57cb4 READ 1 WAIT objectClass.bdb page 3 e6 READ 1 HELD entryUUID.bdb handle 0 81c57cb4 READ 1 HELD dn2id.bdb page 2281 81c57cb4 WRITE 2 HELD dn2id.bdb page 2281 f7 READ 1 HELD scManagedResourceName.bdb handle 0 81c57cb3 READ 1 HELD 0x283700 len: 9 data: 90bd05000000000000 ec READ 1 HELD scLRMDN.bdb handle 0 fa READ 1 HELD scServiceVersionDefinitionName.bdb handle 0 81c57cb4 READ 2 HELD scRouteOffer.bdb page 2462 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 2462 81c564f8 READ 1 HELD dn2id.bdb page 7794 81c564f8 WRITE 2 HELD dn2id.bdb page 7794 81c57cb4 READ 2 HELD scRouteOffer.bdb page 2242 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 2242 f8 READ 1 HELD scServiceDefinitionName.bdb handle 0 fb READ 1 HELD scContainerVersionDefinitionName.bdb handle 0 81c57cb4 READ 2 HELD dn2id.bdb page 8834 81c57cb4 WRITE 2 HELD dn2id.bdb page 8834 81c57cb4 READ 2 HELD scRouteOffer.bdb page 1453 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 1453 81c564f7 READ 1 HELD 0x2c5710 len: 9 data: b3c005000000000000 e4 READ 1 HELD dn2id.bdb handle 0 e3 READ 1 HELD id2entry.bdb handle 0 ef READ 1 HELD scPatchVersion.bdb handle 0 eb READ 1 HELD scListenPort.bdb handle 0 e8 READ 1 HELD scRouteOffer.bdb handle 0 81c57cb4 READ 2 HELD scRouteOffer.bdb page 12 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 12 81c57cb4 READ 2 HELD scRouteOffer.bdb page 14 81c57cb4 WRITE 2 HELD scRouteOffer.bdb page 14 f0 READ 1 HELD scContainerInstanceDN.bdb handle 0 db_stat -t ========== 23078/6225330 File/offset for last checkpoint LSN Tue Sep 25 00:41:24 2012 Checkpoint timestamp 0x81c57cb4 Last transaction ID allocated 144 Maximum number of active transactions configured 0 Initial number of transactions configured 54 Active transactions 146 Maximum active transactions 29M Number of transactions begun (29719732) 170765 Number of transactions aborted 29M Number of transactions committed (29548913) 0 Snapshot transactions 0 Maximum snapshot transactions 0 Number of transactions restored 3MB 336KB Region size 243743 The number of region locks that required waiting (0%) Active transactions: 81b3bf42: running; xa_status xa idle; pid/thread 27448/47802396722192; begin LSN: file/offset 0/0; priority: 0 81b3bf43: running; xa_status xa idle; pid/thread 27448/47802396722192; begin LSN: file/offset 0/0; priority: 0 81b3bf44: running; xa_status xa idle; pid/thread 27448/1123600704; begin LSN: file/offset 0/0; priority: 0 81b3bf69: running; xa_status xa idle; pid/thread 27448/1131993408; begin LSN: file/offset 0/0; priority: 0 81b3bf98: running; xa_status xa idle; pid/thread 27448/1106815296; begin LSN: file/offset 0/0; priority: 0 81b3c0e5: running; xa_status xa idle; pid/thread 27448/1115208000; begin LSN: file/offset 0/0; priority: 0 81b3c4be: running; xa_status xa idle; pid/thread 27448/1140386112; begin LSN: file/offset 0/0; priority: 0 81b3c4d5: running; xa_status xa idle; pid/thread 27448/1148778816; begin LSN: file/offset 0/0; priority: 0 81b3ca00: running; xa_status xa idle; pid/thread 27448/1157171520; begin LSN: file/offset 0/0; priority: 0 81b3cd43: running; xa_status xa idle; pid/thread 27448/1086777664; begin LSN: file/offset 0/0; priority: 0 81b47648: running; xa_status xa idle; pid/thread 27448/1165564224; begin LSN: file/offset 0/0; priority: 0 81b55581: running; xa_status xa idle; pid/thread 27448/1173956928; begin LSN: file/offset 0/0; priority: 0 81b557ba: running; xa_status xa idle; pid/thread 27448/1182349632; begin LSN: file/offset 0/0; priority: 0 81b71512: running; xa_status xa idle; pid/thread 27448/1190742336; begin LSN: file/offset 0/0; priority: 0 81b71515: running; xa_status xa idle; pid/thread 27448/1199135040; begin LSN: file/offset 0/0; priority: 0 81b71518: running; xa_status xa idle; pid/thread 27448/1207527744; begin LSN: file/offset 0/0; priority: 0 81b7151d: running; xa_status xa idle; pid/thread 27448/1215920448; begin LSN: file/offset 0/0; priority: 0 81b71520: running; xa_status xa idle; pid/thread 27448/1224313152; begin LSN: file/offset 0/0; priority: 0 81b71521: running; xa_status xa idle; pid/thread 27448/1232705856; begin LSN: file/offset 23077/7253030; priority: 0 81b71524: running; xa_status xa idle; pid/thread 27448/1241098560; begin LSN: file/offset 0/0; priority: 0 81b71529: running; xa_status xa idle; pid/thread 27448/1249491264; begin LSN: file/offset 0/0; priority: 0 81b7152a: running; xa_status xa idle; pid/thread 27448/1257883968; begin LSN: file/offset 0/0; priority: 0 81b7152d: running; xa_status xa idle; pid/thread 27448/1266276672; begin LSN: file/offset 0/0; priority: 0 81b71530: running; xa_status xa idle; pid/thread 27448/1274669376; begin LSN: file/offset 0/0; priority: 0 81b71533: running; xa_status xa idle; pid/thread 27448/1283062080; begin LSN: file/offset 0/0; priority: 0 81b71536: running; xa_status xa idle; pid/thread 27448/1291454784; begin LSN: file/offset 0/0; priority: 0 81b71539: running; xa_status xa idle; pid/thread 27448/1299847488; begin LSN: file/offset 0/0; priority: 0 81b7153c: running; xa_status xa idle; pid/thread 27448/1308240192; begin LSN: file/offset 0/0; priority: 0 81b7153f: running; xa_status xa idle; pid/thread 27448/1316632896; begin LSN: file/offset 0/0; priority: 0 81b71542: running; xa_status xa idle; pid/thread 27448/1325025600; begin LSN: file/offset 0/0; priority: 0 81b71545: running; xa_status xa idle; pid/thread 27448/1333418304; begin LSN: file/offset 0/0; priority: 0 81b71548: running; xa_status xa idle; pid/thread 27448/1341811008; begin LSN: file/offset 0/0; priority: 0 81b7154b: running; xa_status xa idle; pid/thread 27448/1350203712; begin LSN: file/offset 0/0; priority: 0 81b7154e: running; xa_status xa idle; pid/thread 27448/1358596416; begin LSN: file/offset 0/0; priority: 0 81b71551: running; xa_status xa idle; pid/thread 27448/1366989120; begin LSN: file/offset 0/0; priority: 0 81b71554: running; xa_status xa idle; pid/thread 27448/1375381824; begin LSN: file/offset 0/0; priority: 0 81b71559: running; xa_status xa idle; pid/thread 27448/1383774528; begin LSN: file/offset 0/0; priority: 0 81b7155a: running; xa_status xa idle; pid/thread 27448/1392167232; begin LSN: file/offset 0/0; priority: 0 81b7155d: running; xa_status xa idle; pid/thread 27448/1400559936; begin LSN: file/offset 0/0; priority: 0 81b71560: running; xa_status xa idle; pid/thread 27448/1408952640; begin LSN: file/offset 0/0; priority: 0 81b71563: running; xa_status xa idle; pid/thread 27448/1417345344; begin LSN: file/offset 0/0; priority: 0 81b84f43: running; xa_status xa idle; pid/thread 27448/1425738048; begin LSN: file/offset 0/0; priority: 0 81b84f46: running; xa_status xa idle; pid/thread 27448/1434130752; begin LSN: file/offset 0/0; priority: 0 81b84f49: running; xa_status xa idle; pid/thread 27448/1442523456; begin LSN: file/offset 0/0; priority: 0 81b84f52: running; xa_status xa idle; pid/thread 27448/1450916160; begin LSN: file/offset 0/0; priority: 0 81b84f55: running; xa_status xa idle; pid/thread 27448/1459308864; begin LSN: file/offset 0/0; priority: 0 81b84f58: running; xa_status xa idle; pid/thread 27448/1467701568; begin LSN: file/offset 0/0; priority: 0 81b84f5b: running; xa_status xa idle; pid/thread 27448/1476094272; begin LSN: file/offset 0/0; priority: 0 81b84f5e: running; xa_status xa idle; pid/thread 27448/1484486976; begin LSN: file/offset 0/0; priority: 0 81b84f5f: running; xa_status xa idle; pid/thread 27448/1492879680; begin LSN: file/offset 0/0; priority: 0 81c564f7: running; xa_status xa idle; pid/thread 27448/1299847488; begin LSN: file/offset 23077/7253106; priority: 0 81c564f8: running; xa_status xa idle; pid/thread 27448/1299847488; begin LSN: file/offset 0/0; parent: 81c564f7; priority: 0 81c57cb3: running; xa_status xa idle; pid/thread 27448/1232705856; begin LSN: file/offset 23078/6289581; priority: 0 81c57cb4: running; xa_status xa idle; pid/thread 27448/1232705856; begin LSN: file/offset 0/0; parent: 81c57cb3; priority: 0 pstack trace: ============= Thread 50 (Thread 0x41789940 (LWP 27463)): #0 0x00000038c7ad4358 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000043a8c4 in ?? () #2 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #3 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 49 (Thread 0x41f8a940 (LWP 27464)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 48 (Thread 0x4278b940 (LWP 27465)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 47 (Thread 0x42f8c940 (LWP 27466)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 46 (Thread 0x4378d940 (LWP 27467)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 45 (Thread 0x43f8e940 (LWP 27512)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x4478f940 (LWP 27513)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x44f90940 (LWP 27599)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x40c6e940 (LWP 27656)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x45791940 (LWP 3074)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x45f92940 (LWP 5033)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x46793940 (LWP 5416)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x46f94940 (LWP 10803)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x47795940 (LWP 10804)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x47f96940 (LWP 10805)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x48797940 (LWP 10806)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x48f98940 (LWP 10807)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 33 (Thread 0x49799940 (LWP 10808)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de015813 in hdb_idl_delete_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a4c6 in hdb_key_change () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de009401 in indexer () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de009882 in index_at_values () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de009a13 in hdb_index_values () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de009e98 in hdb_index_entry () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79ddffcd89 in hdb_delete () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf243 in ?? () #24 0x00000000004c0d78 in ?? () #25 0x00000000004b9c17 in ?? () #26 0x00000000004ba51e in ?? () #27 0x00000000004f4739 in ?? () #28 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #29 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x49f9a940 (LWP 10814)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x4a79b940 (LWP 10818)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 30 (Thread 0x4af9c940 (LWP 10821)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x4b79d940 (LWP 10822)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 28 (Thread 0x4bf9e940 (LWP 10824)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x4c79f940 (LWP 10825)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 26 (Thread 0x4cfa0940 (LWP 10826)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 25 (Thread 0x4d7a1940 (LWP 10827)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de015813 in hdb_idl_delete_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a4c6 in hdb_key_change () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de009401 in indexer () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de009882 in index_at_values () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de009a13 in hdb_index_values () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de009e98 in hdb_index_entry () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79ddffcd89 in hdb_delete () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf243 in ?? () #24 0x000000000046139d in fe_op_delete () #25 0x0000000000461046 in do_delete () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 ... ... Thread 2 (Thread 0x58fb8940 (LWP 26982)): #0 0x00000038c820aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b79dc19aab9 in __db_pthread_mutex_condwait () from /opt/app/aft/scldldap/lib/libdb-5.3.so #2 0x00002b79dc19a810 in __db_hybrid_mutex_suspend () from /opt/app/aft/scldldap/lib/libdb-5.3.so #3 0x00002b79dc199ee1 in __db_tas_mutex_lock_int () from /opt/app/aft/scldldap/lib/libdb-5.3.so #4 0x00002b79dc199b36 in __db_tas_mutex_lock () from /opt/app/aft/scldldap/lib/libdb-5.3.so #5 0x00002b79dc2909f2 in __lock_get_internal () from /opt/app/aft/scldldap/lib/libdb-5.3.so #6 0x00002b79dc28e167 in __lock_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #7 0x00002b79dc2d3345 in __db_lget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #8 0x00002b79dc1c6727 in __bam_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #9 0x00002b79dc1ac1b0 in __bamc_search () from /opt/app/aft/scldldap/lib/libdb-5.3.so #10 0x00002b79dc1a6de1 in __bamc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #11 0x00002b79dc2b57dd in __dbc_iget () from /opt/app/aft/scldldap/lib/libdb-5.3.so #12 0x00002b79dc2b51dd in __dbc_get () from /opt/app/aft/scldldap/lib/libdb-5.3.so #13 0x00002b79dc2cd579 in __dbc_get_pp () from /opt/app/aft/scldldap/lib/libdb-5.3.so #14 0x00002b79de0141f6 in hdb_idl_fetch_key () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #15 0x00002b79de00a1bd in hdb_key_read () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #16 0x00002b79de00ca5d in equality_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #17 0x00002b79de00b14c in hdb_filter_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #18 0x00002b79de0039a9 in search_aliases () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #19 0x00002b79de006eed in search_candidates () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #20 0x00002b79de005093 in hdb_search () from /opt/app/aft/scldldap/libexec/back_hdb-2.4.so.2 #21 0x00000000004ceebe in overlay_op_walk () #22 0x00000000004cf0c1 in ?? () #23 0x00000000004cf18f in ?? () #24 0x0000000000442670 in fe_op_search () #25 0x0000000000441f4f in do_search () #26 0x000000000043e98c in ?? () #27 0x000000000043ef11 in ?? () #28 0x00000000004f4739 in ?? () #29 0x00000038c820673d in start_thread () from /lib64/libpthread.so.0 #30 0x00000038c7ad3f6d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2b79dce04410 (LWP 27448)): #0 0x00000038c8207b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x00000000004f5c0b in ldap_pvt_thread_join () #2 0x000000000043ba60 in slapd_daemon () #3 0x0000000000419bd3 in main () Thanks, Venkatesh

1 0

(ITS#7400) Memberof and Syncrepl incompatibility
by arunkumar_1123＠yahoo.com 25 Sep '12

25 Sep '12

Full_Name: Arunkumar shanmugam Version: 2.4.29 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.83.248.32) Hi, I'm currently using Openldap 2.4.29 to model an Authorization platform. I noticed some inconsistent behavior with syncrepl and memberof overlays. The issue happens as follows: If I Create groups with a large number of members and delete them in quick succession on the writemaster, the data replicated to the readslave is incorrect, in particular, the memberof fields of the User objects. This seems to happen because the memberof field is getting replicated to the slave nodes, although the documentation states that it shouldn't. While replicating, the User object is replicated inclusive of the memberof fields, but by the time the syncrepl search comes to the group object, it has already been deleted, and hence not replicated. This leaves a dangling memberof field in the read slave instance. I was wondering if anyone has faced this issues (I did not see any ITS related to this), and has a workaround. Thanks, Arunkumar

1 0

(ITS#7399) ��Syncrepl��when consumer doing the syncrepl with the provider, reboot the consumer, the cusummer does not continue the task any more
by xinrong.li＠163.com 23 Sep '12

23 Sep '12

Full_Name: mark Version: 2.4.20 OS: sles11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (113.116.144.106) I meet some problem when doing as following: --> consumer and provider OK. mean that if you add/delete some records to provider, consumer will sync with the provder --> let consumer ldap service stop --> provider add 100 records --> consumer start and it will begin to sync the 100 records from provider --> consumer restart when have sync 60 records from provider --> consumer wounld not Syncrepl the rest 40 records from provider --> then, you add or delete some records, consumer will sync with provider OK except the 40 records May anyone give me some help? thanks! my slapd.conf content is thus: provider: database bdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 comsumer: database hdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq syncrepl rid=123 provider=ldap://provider.example.com:389 type=refreshOnly interval=01:00:00:00 searchbase="dc=example,dc=com" filter="(objectClass=organizationalPerson)" scope=sub attrs="cn,sn,ou,telephoneNumber,title,l" schemachecking=off bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=secret

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by kurt＠OpenLDAP.org 22 Sep '12

22 Sep '12

On Sep 22, 2012, at 8:24 AM, michael(a)stroeder.com wrote: > Hallvard Breien Furuseth wrote: >> I wrote: >>> In OpenSSL, SSL_get_peer_certificate(). >> >> ..after getting the SSL* arg with >> ldap_get_option LDAP_OPT_X_TLS_SSL_CTX. >> Which the manpage recommends not doing. At least >> don't meddle with the SSL* more than you have to. That statement, IIRC, was made mostly because unless you control your build of libldap (or control which libldap you use), you don't know what TLS implementation lies underneath. > Hmm, but then the client has to deal with whether libldap is linked to > OpenSSL, libnss or GnuTLS... Yes. but often that's only one. Anyways, I see little reason to add cert extraction code in libldap. Most folks who need this need this for more than one protocols, and it's easier/better for them to use a common facilities for doing this across all these protocols. But, hey, if someone wants to write such code for all the supported TLS layers, have at it. But like most things for non-OpenSSL, your mileage will vary. > > Ciao, Michael. > >

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by michael＠stroeder.com 22 Sep '12

22 Sep '12

Hallvard Breien Furuseth wrote: > I wrote: >> In OpenSSL, SSL_get_peer_certificate(). > > ..after getting the SSL* arg with > ldap_get_option LDAP_OPT_X_TLS_SSL_CTX. > Which the manpage recommends not doing. At least > don't meddle with the SSL* more than you have to. Hmm, but then the client has to deal with whether libldap is linked to OpenSSL, libnss or GnuTLS... Unfortunately in the current project where I'm using web2ldap the python-ldap libs are linked against the OpenLDAP libs shipped with Debian => GnuTLS. Ciao, Michael.

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by masarati＠aero.polimi.it 22 Sep '12

22 Sep '12

> I wrote: >> In OpenSSL, SSL_get_peer_certificate(). > > ..after getting the SSL* arg with > ldap_get_option LDAP_OPT_X_TLS_SSL_CTX. > Which the manpage recommends not doing. At least > don't meddle with the SSL* more than you have to. I presume Michael's case is one of the few in which the client would pay enough attention to details when using such an option. Whether a case like this deserves an OpenLDAP API is questionable, since it is not an LDAP-specific issue, but rather a general SSL wrapping issue. OTOH, as long as clever client design often needs it, I would not object to adding such feature. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by h.b.furuseth＠usit.uio.no 22 Sep '12

22 Sep '12

I wrote: > In OpenSSL, SSL_get_peer_certificate(). ..after getting the SSL* arg with ldap_get_option LDAP_OPT_X_TLS_SSL_CTX. Which the manpage recommends not doing. At least don't meddle with the SSL* more than you have to. Hallvard

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by h.b.furuseth＠usit.uio.no 22 Sep '12

22 Sep '12

michael(a)stroeder.com wrote: >Kurt Zeilenga wrote: >> Why not just get it from TLS? That does require an #ifdef <which TLS implementation> mess in the client. libldap already has that. > What exactly do you mean? In OpenSSL, SSL_get_peer_certificate(). I note that it might also or instead make sense to ask for the cert chain - OpenSSL SSL_get_peer_cert_chain(). Which quickly dives into how many other TLS session attributes it would make sense to kindly provide an LDAP API interface to... Hallvard

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by michael＠stroeder.com 22 Sep '12

22 Sep '12

This is a cryptographically signed message in MIME format. --------------ms000108080605020401040901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt Zeilenga wrote: > Why not just get it from TLS?=20 What exactly do you mean? Ciao, Michael. --------------ms000108080605020401040901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTIyMTE0NDE1WjAjBgkq hkiG9w0BCQQxFgQURaD6VwBCA23yunm+7WIzNVeHwy4wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAVLqeOPOWTaONCtPgeSsDnNeEDd3Wm+5GnNHIeQoyKHVQOrRFiSJrdeaAAv1xqOZK/1F4 4npTnQiIEPtSAU6iMJcutUc2MSlpuGRen3tIsYKi+Ku+KYRLUjaQoN/nqaej0HuLhOUfQwmw vftzkmCz465NABCJXdY4mUttnITa3dE2aVZ7lTgaXqNnjxk1IF709FTnA4+dQUxB94QfjDLU GIphLSYjU/KMJr/hcfWouBPX08MLEOllmx19gs8ynLwLK4sFuJyL9J0+Om/VfRNWTikgngUf VbQE9ovQDNDWO4qU+VEA9uJJ/v9iKNPuh00YBNAgRnBNnraWlkpmER83+gAAAAAAAA== --------------ms000108080605020401040901--

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by Kurt＠OpenLDAP.org 21 Sep '12

21 Sep '12

Why not just get it from TLS? -- Kurt

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by michael＠stroeder.com 21 Sep '12

21 Sep '12

On Fri, 21 Sep 2012 10:43:42 -0700 Howard Chu <hyc(a)symas.com> wrote > michael(a)stroeder.com wrote: > > Feature request: > > When using LDAPS or StartTLS it would be sometimes handy to retrieve the > > LDAP server certificate over the LDAP client API. > > > > Opinions? > > And then what? I think it'd be straightforward for us to return a copy of it > in DER binary format. What do clients need to do with it? In my case (web2ldap): Simply display it to the user. If it's not too much work this would be a handy feature. Ciao, Michael.

1 0

Re: (ITS#7398) Retrieve LDAP server cert
by hyc＠symas.com 21 Sep '12

21 Sep '12

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) > > > Feature request: > When using LDAPS or StartTLS it would be sometimes handy to retrieve the LDAP > server certificate over the LDAP client API. > > Opinions? And then what? I think it'd be straightforward for us to return a copy of it in DER binary format. What do clients need to do with it? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7393) slapd crash when changing an attribute name to an existing name
by hyc＠symas.com 21 Sep '12

21 Sep '12

ddick(a)cpan.org wrote: > Full_Name: David Dick > Version: 2.4.26 > OS: Fedora 16 > URL: > Submission from: (NULL) (124.148.129.18) > > > When changing the NAME of an attribute to the name of an existing attribute, the > slapd process crashes. Unable to reproduce this in current OpenLDAP. (2.4.32 is latest.) You need to upgrade, closing this ITS. > The following set of statements in ldif format will crash the server; > The cn={12} was chosen as the next available schema index and may need to be > adjusted appropriately. > > dn: cn={12}crashme,cn=schema,cn=config > changetype: add > objectClass: olcSchemaConfig > cn: {12}crashme > olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'SmtpHost' EQUALITY > caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > dn: cn={12}crashme,cn=schema,cn=config > changetype: modify > replace: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'MailHost' EQUALITY > caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > -- -- 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#7398) Retrieve LDAP server cert
by michael＠stroeder.com 21 Sep '12

21 Sep '12

Full_Name: Michael Ströder Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) Feature request: When using LDAPS or StartTLS it would be sometimes handy to retrieve the LDAP server certificate over the LDAP client API. Opinions?

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs