- openldap-bugs - openldap.org

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: >> Version: 2.4.26 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.26.156) >> >> >> It seems that attribute auditContext is replicated to consumers if there's an >> accesslog DB configured at the provider. IMO this does not make sense since the >> accesslog DB is not replicated and one might not want to load slapo-accesslog >> module at all in the consumer's config. >> >> In a 2-way MMR setup with accesslog DB attached to both master providers the >> auditContext contains two values for auditContext and even the same one. > > Since a syncrepl operation is a regular LDAP search, the provider sends > everything that matches the search request. Probably we should be filtering > out DSA-specific opattrs at the consumer side. > Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs on the provider side, when the Syncrepl control is present. Something else is going on here, but since you failed to provide any config info there's no way to tell where the problem is. -- -- 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#7019) attribute auditContext should not get replicated
by hyc＠symas.com 15 Aug '11

15 Aug '11

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if there's an > accesslog DB configured at the provider. IMO this does not make sense since the > accesslog DB is not replicated and one might not want to load slapo-accesslog > module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers the > auditContext contains two values for auditContext and even the same one. Since a syncrepl operation is a regular LDAP search, the provider sends everything that matches the search request. Probably we should be filtering out DSA-specific opattrs at the consumer side. -- -- 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#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 9:03 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> Delta-Syncrepl (normal and MMR modes) both use an accesslog database. >> So your contention that accesslog DBs are not replicated is somewhat >> incorrect. > > Up to now I thought that the accesslog DB itself is only accessible at the > provider and not replicated to the consumer. At least that's what's IMO > written in the OpenLDAP Admin Guide: I just wanted to be clear that accesslog can be used for replication. Thank you for providing such a nice test case example. ;) As for delta-syncrepl MMR, it exists, its in HEAD, and I have it working with RE24 just fine. It may well go into the next 2.4 release, so don't ignore it. ;) --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#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

quanah(a)zimbra.com wrote: > Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So > your contention that accesslog DBs are not replicated is somewhat incorrect. Up to now I thought that the accesslog DB itself is only accessible at the provider and not replicated to the consumer. At least that's what's IMO written in the OpenLDAP Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl "Delta-syncrepl works by maintaining a changelog of a selectable depth on the provider." Also in the Admin Guide: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl There's no accesslog database at the consumer (replica) configured. Delta-syncrepl in MMR mode is not finished yet, therefore I ignore this case for now. Because you are nitpicking in my case I set up a testbed. The accesslog DB itself is *not* replicated. Anyway the main issue here is that I regard replicating the attribute auditContext as not appropriate since you cannot access the referenced accesslog DB at the consumer. And it seems that with delta syncrepl the attribute is not replicated. But it seems to be replicated in a MMR setup with separate accesslog DBs configured at both providers. And this leads to this multiple but same(!) attribute values. We have four databases in our MMR test setup: cn=wsvdir-accesslog-de (for c=DE) cn=wsvdir-accesslog-system (for o=SYSTEM) o=SYSTEM (replicated in MMR setup) c=DE (replicated in MMR setup) In both providers I have dn: o=SYSTEM auditContext: cn=wsvdir-accesslog-system auditContext: cn=wsvdir-accesslog-system It does not happen in c=DE though. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by quanah＠zimbra.com 15 Aug '11

15 Aug '11

--On Monday, August 15, 2011 2:42 PM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.26 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.26.156) > > > It seems that attribute auditContext is replicated to consumers if > there's an accesslog DB configured at the provider. IMO this does not > make sense since the accesslog DB is not replicated and one might not > want to load slapo-accesslog module at all in the consumer's config. > > In a 2-way MMR setup with accesslog DB attached to both master providers > the auditContext contains two values for auditContext and even the same > one. Delta-Syncrepl (normal and MMR modes) both use an accesslog database. So your contention that accesslog DBs are not replicated is somewhat incorrect. --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#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

Full_Name: Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.26.156) It seems that attribute auditContext is replicated to consumers if there's an accesslog DB configured at the provider. IMO this does not make sense since the accesslog DB is not replicated and one might not want to load slapo-accesslog module at all in the consumer's config. In a 2-way MMR setup with accesslog DB attached to both master providers the auditContext contains two values for auditContext and even the same one.

1 0

(ITS#7018) unique URI's host part must be empty
by masarati＠aero.polimi.it 13 Aug '11

13 Aug '11

Full_Name: Pierangelo Masarati Version: master,re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.144.24.27) Submitted by: ando If empty "host" part is checked, misconfigurations like in <http://www.openldap.org/lists/openldap-technical/201108/msg00116.html> would be easily detected. A fix is coming. p.

1 0

(ITS#7017) DDS overlay: TTL tolerance has inverse effect
by jvcelak＠redhat.com 11 Aug '11

11 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110811-dds-overlay-tolerance.patch Submission from: (NULL) (209.132.186.34) Hi! olcDDStolerance setting of DDS overlay has inverse effect and in fact it is shortening the real TTL of dynamic entries. I have uploaded the patch (against git master). Regards, Jan

1 0

(ITS#7016) slapd.ldif bootstrap fails on olcDatabase=frontend
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: ftp://ftp.openldap.org/incoming/ajf-20110811-slapd.ldif Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) Using a slapd.ldif (attached) closely based on the example from servers/slapd/slapd.ldif I find that the server will not bootstrap: $ slapadd -F ./config -n 0 -l slapd-try.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ slapadd -F ./config -l data.ldif -b dc=example,dc=org slapadd: bad configuration directory! The problem appears to be this entry in the LDIF: dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend olcAccess: to * by * read If 'frontend' is replaced with '{-1}frontend' in both places then the server works. At the least this needs changing in the example file slapd.ldif, in the manpage slapd-config(5), and in the admin guide. Some explanation as to why it is necessary would be welcome too! (I suspect it is because the cn=config DB has already been instantiated as DB zero, yet the frontend has to come ahead of all other DBs in some list). The error message is not very helpful, and winding up the debugging level just sent me up blind alleys so could the server please say a bit more about just what is bad about the config directory?

1 0

Re: (ITS#7015) slapd.ldif example file not installed
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Full_Name: Andrew Findlay > Version: 2.4.26 > OS: OpenSuSE 11.4 > URL: > Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) > > > slapdconf2.sdf says: > The distribution contains an example configuration file that will > be installed in the {{F: /usr/local/etc/openldap}} directory. > > There is an example file in the source: servers/slapd/slapd.ldif > but it is not installed anywhere. The corresponding slapd.conf example > does get installed, so this one should probably go alongside it. Fixed in master, please test. p.

1 0

(ITS#7015) slapd.ldif example file not installed
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) slapdconf2.sdf says: The distribution contains an example configuration file that will be installed in the {{F: /usr/local/etc/openldap}} directory. There is an example file in the source: servers/slapd/slapd.ldif but it is not installed anywhere. The corresponding slapd.conf example does get installed, so this one should probably go alongside it.

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Sounds like this may be related to ITS#6817. Please try adding a dummy > binddn > to your idassert-bind directive and re-test. First of all, I believe the real problem is that pr should not be used by the client in the first place. However, the cause of the issue might be something slightly different: back-ldap uses a pool of connections for special identities, including anonymous and rootdn; the latter is the case when identity assertion is used. So it seems plausible that although the client uses the same connection for repeated paged results requests, the proxy is using different ones. We already discussed the possibility to specially handle pr in proxies, in order to decouple its use by the client and the remote server. If slapd handles pr in the frontend, a proxy does not need to propagate pr requests to the remote server. Similarly, if a remote server *needs* pr, the client must not necessarily know about it. Something like this has already been implemented in back-meta(5), which can be instructed to silently continue unsolicited pr responses without informing the client about them (I should have ported this to back-ldap(5) as well). If this is the case (need to investigate in detail, yet), a quick fix could be to detect the presence of pr on a request, and bind the cookie to a specific connection until that cookie is gone. One thing that could be tried is to use slapo-sssvlv(5) on top of back-ldap and let it deal with the pr request. p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so > ldapsearch (and all tools) are fooled by not actually checking ld_errno > (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). Fixed in master. Also fixed timelimit (apparently, it was not honored). p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> Full_Name: Bjoern Jacke > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.159.216.39) > > > When TIMEOUT is set and happend to occur there is nothing that shows that > we > timed out. For example if you do a large/slow LDAP search using ldapsearch > and > then stop the conversation between slapd and ldapsearch by "killall -STOP > slapd" > then ldapsearch will terminate after TIMEOUT seconds and it will return > the > number of records that it got so far and exit with return code 0 and not > error > message. I'd expect that after TIMEOUT occuring that we get a warning and > a > return code != 0 libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so ldapsearch (and all tools) are fooled by not actually checking ld_errno (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). p.

1 0

Re: (ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 10 Aug '11

10 Aug '11

I'm sorry, in the meantime I found out that the binddn I used didn't have full access so the empty node couldn't get all attributes and then the broken directory got replicated back to the initial node. It was just a configuration problem on my part. Sorry again.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> I don't remember any particular reason why the argument count was omitted > here. Looking back over release 2.2 I don't see any special provision for > multiple arguments. I.e., it doesn't look like we need to accomodate > longer > argument lists here. And I don't see why we would want to NULL out any > existing settings. Sounds like we should just require argc == 2. Fixed in master, passes all tests for me. BTW, the original poster's address no longer exists, so I do not expect feedback. p.

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by hyc＠symas.com 10 Aug '11

10 Aug '11

masarati(a)aero.polimi.it wrote: >> No, thanks. The problem is that these specific statements do not >> prescribe a fixed number of arguments. Moreover, the function that uses >> the value resets the field when passed a NULL argument. If this behavior >> needs to be preserved, I have the right fix handy. Otherwise it might >> need more work. > > To be more specific: slapd's TLS configuration is registered without > enforcing a specific number of arguments. This check is delegated to the > underlying calls to ldap_pvt_tls_set_option() performed by > config_tls_option(). This poses two problems: > > - since the argument of these parameters is ARG_STRING, if no arg is > passed then ch_strdup() fails > > - fixing this (by skipping ch_strdup() if argc == 1, for example) results > in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly > legitimate value (it means: clear any existing value), but it may not be > appropriate in this context. > > Please advise whether the right fix is skip ch_strdup(), or enforcing a > requirement for argc == 2 for TLS-related fields. I don't remember any particular reason why the argument count was omitted here. Looking back over release 2.2 I don't see any special provision for multiple arguments. I.e., it doesn't look like we need to accomodate longer argument lists here. And I don't see why we would want to NULL out any existing settings. Sounds like we should just require argc == 2. -- -- 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#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> No, thanks. The problem is that these specific statements do not > prescribe a fixed number of arguments. Moreover, the function that uses > the value resets the field when passed a NULL argument. If this behavior > needs to be preserved, I have the right fix handy. Otherwise it might > need more work. To be more specific: slapd's TLS configuration is registered without enforcing a specific number of arguments. This check is delegated to the underlying calls to ldap_pvt_tls_set_option() performed by config_tls_option(). This poses two problems: - since the argument of these parameters is ARG_STRING, if no arg is passed then ch_strdup() fails - fixing this (by skipping ch_strdup() if argc == 1, for example) results in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly legitimate value (it means: clear any existing value), but it may not be appropriate in this context. Please advise whether the right fix is skip ch_strdup(), or enforcing a requirement for argc == 2 for TLS-related fields. p.

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais＠gmail.com 09 Aug '11

09 Aug '11

--00163683235cdfe3c004aa1933e0 Content-Type: text/plain; charset=ISO-8859-1 This seems to be a little old but I had attached the patch to close this issue and now I realize that I should provide it in a Uniform Resource Locator (URL) just as http://www.openldap.org/devel/contributing.html explains. So here it goes: http://xsun.eti.br/openldap/ldapsearch1_man_page.patch Sorry for this mistake. Thanks. Matheus Morais On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <matheus.morais(a)gmail.com>wrote: > Hi there, > > <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any > other program comes immediately to mind. </quote> > > Even sounds like an strange behave, as Quanah said, this information should > be included on ldapsearch man page IMHO. > > I believe that the following patch could close this BUG: > > --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31 > 01:25:23.000000000 -0300 > +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000 > -0300 > @@ -7,6 +7,8 @@ > .SH SYNOPSIS > .B ldapsearch > [\c > +.BR \-V [ V ]] > +[\c > .BR \-n ] > [\c > .BR \-c ] > @@ -107,6 +109,11 @@ > Option \fI\-L\fP controls the format of the output. > .SH OPTIONS > .TP > +.BR \-V [ V ] > +Prints the ldapsearch version and proceeds with the search. > +.B \-VV > +Prints the ldapsearch version and quit. > +.TP > .B \-n > Show what would be done, but don't actually perform the search. Useful > for > debugging in conjunction with \fB\-v\fP. > > Please review it. > > Thanks, > > Matheus Morais > --00163683235cdfe3c004aa1933e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems to be a little old but I had attached the patch to close this is= sue and now I realize that I should provide it in a Uniform Resource Locato= r (URL) just as=A0<meta http-equiv=3D"content-type" content=3D"text/html; c= harset=3Dutf-8"><a href=3D"http://www.openldap.org/devel/contributing.html"= >http://www.openldap.org/devel/contributing.html</a>=A0explains.<div> <br></div><div>So here it goes:</div><div><br></div><div><a href=3D"http://= xsun.eti.br/openldap/ldapsearch1_man_page.patch">http://xsun.eti.br/openlda= p/ldapsearch1_man_page.patch</a></div><div><br></div><div>Sorry for this mi= stake.</div> <div><br></div><div>Thanks.</div><div>Matheus Morais</div><div><br><div cla= ss=3D"gmail_quote">On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <span di= r=3D"ltr"><<a href=3D"mailto:matheus.morais@gmail.com">matheus.morais@gm= ail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Hi there,<br><br><quote> That's..= . bizarre. Even slapd doesn't behave that way. Nor any other program = comes immediately to mind. </quote><br> <br>Even sounds like an strange behave, as Quanah said, this information sh= ould be included on ldapsearch man page IMHO.<br> <br>I believe that the following patch could close this BUG:<br><br>--- ope= nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000= -0300<br>+++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:= 50.000000000 -0300<br> @@ -7,6 +7,8 @@<br>=A0.SH SYNOPSIS<br>=A0.B ldapsearch<br>=A0[\c<br>+.BR \-= V [ V ]]<br>+[\c<br>=A0.BR \-n ]<br>=A0[\c<br>=A0.BR \-c ]<br>@@ -107,6 +10= 9,11 @@<br>=A0Option \fI\-L\fP controls the format of the output.<br>=A0.SH= OPTIONS<br> =A0.TP<br>+.BR \-V [ V ]<br>+Prints the ldapsearch version and proceeds wit= h the search.<br>+.B \-VV<br>+Prints the ldapsearch version and quit.<br>+.= TP<br>=A0.B \-n<br>=A0Show what would be done, but don't actually perfo= rm the search.=A0 Useful for<br> =A0debugging in conjunction with \fB\-v\fP.<br><br>Please review it.<br><br= >Thanks,<br><font color=3D"#888888"><br>Matheus Morais<br> </font></blockquote></div><br></div> --00163683235cdfe3c004aa1933e0--

1 0

Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati＠aero.polimi.it 09 Aug '11

09 Aug '11

> Full_Name: Ashish Gawarikar > Version: 2.4.23 > OS: Redhat 5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.253.98.197) > > > In my slapd.conf file: > ... > TLSCertificateFile > TLSCertificateKeyFile > ... > > If I have the above, I get a core dump, with the error: > slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed. > > > Let me know if you need the core file. No, thanks. The problem is that these specific statements do not prescribe a fixed number of arguments. Moreover, the function that uses the value resets the field when passed a NULL argument. If this behavior needs to be preserved, I have the right fix handy. Otherwise it might need more work. p.

1 0

(ITS#7014) TLS: certificate hostnames are being checked when TLS_REQCERT is se to allow
by jvcelak＠redhat.com 09 Aug '11

09 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap/0001-TLS-do-not-check-hostname-whe… Submission from: (NULL) (209.132.186.34) Hello. If server certificate hostname does not match the server hostname, connection is closed even if client has set TLS_REQCERT to 'allow'. This is wrong - the documentation says, that bad certificates are being ignored when TLS_REQCERT is set to 'allow'. (Other certificate failures (like invalid CA) are handled as expected - at least with MozNSS.) I'm attaching patch, which fixes this behavior. The patch applies on master branch. (OpenLDAP FTP server for incoming patches reports 'No space left on device.', that's why I uploaded the patch to fedorapeople.org.) Regards, Jan

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 09 Aug '11

09 Aug '11

--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. And, at Quanah's prompting I tried it with an empty empty binddn and got similar results. Still a failure, sometimes after returning 1000 entries, sometimes after returning 2000 entries. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 09 Aug '11

09 Aug '11

--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> --On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: >> >>> --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: >>>>>> Your log shows that the subsequent search request initiates a new >>>>>> Bind to the remote server, which implies that it's not re-using the >>>>>> same connection as the first request. Since a paged results cookie >>>>>> is only valid within the context of a single connection, you get >>>>>> this error result. >>>>> >>>>> Not sure which log you are looking at. When I look at the log: >>>>> >>>>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>>>> lts.log.gz >>>>> >>>>> The only connection I see in the log is conn=1000 and it ends with: >>>>> >>>>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>>>> cookie is invalid ldap_read: want=8, got=7 >>>>> 0000: 30 05 02 01 07 42 00 0....B. >>>>> ldap_read: want=8, got=0 >>>>> >>>>> conn=1000 op=6 UNBIND >>>>> conn=1000 fd=11 closed >>>>> >>>>> These tests where made with a single ldapsearch request. The ldapsearch >>>>> tests fail when using the proxy and succeed when connecting directly to >>>>> the LDAP server with the database on it. >>>>> >>>>> A side node: the test case I submitted used ldapsearch, but the >>>>> problem was uncovered using a python application that is used for >>>>> syncing Gmail account data. >>>>> >>>>> Bill >>>> >>>> I have copied the backend server configuration to >>>> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >>>> copy of cn=config and there is a files based version the in ldap >>>> subdirectory as well. >>> >>> Where's the configuration for the slapd-ldap server? That's of the >>> most importance... >>> >>> --Quanah >> >> Of course, sorry about that. I have copied the files to the web site. > > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. I modified the configuration to include: idassert-bind bindmethod=SASL saslmech=GSSAPI mode=none binddn=cn=auth I am stilling getting the invalid-cookie error. % ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectclass=suPerson)(suVisibIdentity=world))" ou telephonenumber title ...lots of entries... # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MA0CAQAECGIdAAAAAAAA pagedresults: cookie=Yh0AAAAAAAA= # extended LDIF # # LDAPv3 # base <cn=people,dc=stanford,dc=edu> with scope subtree # filter: (&(objectclass=suPerson)(suVisibIdentity=world)) # requesting: ou telephonenumber title # with pagedResults control: size=1000 # # search result search: 3 result: 2 Protocol error text: paged results cookie is invalid # numResponses: 1002 # numEntries: 1000 Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#7013) OpenLDAP freezes and doesn't respond
by cgrosjean＠janua.fr 08 Aug '11

08 Aug '11

Full_Name: Cyril Grosjean Version: 2.4.26 OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.66.198.206) My OpenLDAP server freezes, after a few requests, and I can't understand why. I have a few LDAP clients (ldapsearch, a custom Java app. and ApacheDirectoryStudio), running from different systems, either locally on the OpenLDAP server, or on another OpenLDAP server, or on a remote workstation, and none manages to get an answer from OpenLDAP. The connection is established but each client gets stuck waiting for any result. We can reproduce the freeze, after a few requests coming from the custom Java application. The problem doesn't occur if we don't use that application. The last time, it occured only a few minutes after the OpenLDAP daemon was restarted, under very low load. I use OpenLDAP 2.4.26, over Red Hat Enterprise Linux Server release 5.4 (Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over VMWare. I also use BDB 4.8.30, and OpenLDAP's been compiled with the following options: ./configure --prefix=/opt/openldap-2.4.26 --enable-dynamic=yes --enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes --enable-accesslog=yes --enable-sssvlv=yes I noticed only 60 to 70 established connections on port 389 (according to netstat) when the freeze occurs. The OpenLDAP server is set in syncrepl mirror mode replication, and the other OpenLDAP server (only used as a hot stand-by) works fine (but doesn't receive any load). However, one can reproduce the problem with replication disabled. In the OpenLDAP accesslog, I usually see the client requests, but no lines for the responses. Also, I noticed sometimes the "deferring operation: binding" message : Jul 12 10:20:05 dev-ldap1 slapd[28525]: connection_input: conn=3377 deferring operation: binding Jul 12 10:20:07 dev-ldap1 slapd[28525]: conn=3378 fd=66 ACCEPT from IP=......:3823 (IP=0.0.0.0:389) I don't know if this message is linked or not to the main problem so I'd like to know if this message is harmless or not, and I mention it here just in case it could help. Below is a full backtrace of the slapd process when it freezes. We can reproduce the problem easily [root@rhvtq ldap-master1]# gdb GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". (gdb) bt full No stack. (gdb) attach 20884 Attaching to process 20884 Reading symbols from /opt/openldap-2.4.26/libexec/slapd...done. Reading symbols from /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2...done. Loaded symbols for /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2 Reading symbols from /opt/openldap-2.4.26/lib/liblber-2.4.so.2...done. Loaded symbols for /opt/openldap-2.4.26/lib/liblber-2.4.so.2 Reading symbols from /lib64/libuuid.so.1...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so Reading symbols from /lib64/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0x2b1c9a53dbd0 (LWP 20884)] [New Thread 0x48a36940 (LWP 21499)] [New Thread 0x40930940 (LWP 21498)] [New Thread 0x48235940 (LWP 21203)] [New Thread 0x47a34940 (LWP 21202)] [New Thread 0x47233940 (LWP 21201)] [New Thread 0x46a32940 (LWP 21200)] [New Thread 0x46231940 (LWP 21087)] [New Thread 0x45a30940 (LWP 21086)] [New Thread 0x4522f940 (LWP 21021)] [New Thread 0x44a2e940 (LWP 21020)] [New Thread 0x4422d940 (LWP 20891)] [New Thread 0x43a2c940 (LWP 20890)] [New Thread 0x4322b940 (LWP 20889)] [New Thread 0x42a2a940 (LWP 20888)] [New Thread 0x42229940 (LWP 20887)] [New Thread 0x41a28940 (LWP 20886)] [New Thread 0x41227940 (LWP 20885)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...done. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 (gdb) bt full #0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922 i = 0 rc = 0 listener_tid = (ldap_pvt_thread_t *) 0x1ef88c60 #2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983 i = 7 no_detach = 0 rc = -12 urls = 0x1ec6a460 "ldap://rhvtq:1389/" username = 0x1ec6a3b0 "" groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 7 g_argv = (char **) 0x7ffff62c9618 configfile = 0x1ec6a4d0 "/opt/openldap/etc/openldap/slapd-master1.conf" configdir = 0x0 serverName = 0x7ffff62caa62 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x55db15 "" l = 4222019 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) thread apply all bt Thread 18 (Thread 0x41227940 (LWP 20885)): #0 0x00000031a7ad4018 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000429b23 in slapd_daemon_task (ptr=0x0) at daemon.c:2528 #2 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x41a28940 (LWP 20886)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1101171008) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x41a26fe0, rs=0x41a27150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x41a26fe0, rs=0x41a27150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x41a26fe0, rs=0x41a27150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x41a26fe0, rs=0x41a27150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4aef00, rs=0x41a27c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4aef00, rs=0x41a27c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4aef00, rs=0x41a27c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4aef00, rs=0x41a27c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x41a27d70, arg_v=0x1f4aef00) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x41a27d70, argv=0x69) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x42229940 (LWP 20887)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1109563712) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x42227fe0, rs=0x42228150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x42227fe0, rs=0x42228150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x42227fe0, rs=0x42228150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x42227fe0, rs=0x42228150) at backover.c:762 ---Type <return> to continue, or q <return> to quit--- #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4b2aa0, rs=0x42228c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4b2aa0, rs=0x42228c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4b2aa0, rs=0x42228c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4b2aa0, rs=0x42228c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x42228d70, arg_v=0x1f4b2aa0) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x42228d70, argv=0x61) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x42a2a940 (LWP 20888)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1f4ae470, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x428a8460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f4b09e0, tid=0x1f4ae470, id=1968, eip=0x428a8490, flag=0, lock=0x428a8460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f4b09e0, rs=0x42a29c30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x42a29d70, arg_v=0x1f4b09e0) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x42a29d70, argv=0x55) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x4322b940 (LWP 20889)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1126349120) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x43229fe0, rs=0x4322a150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x43229fe0, rs=0x4322a150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x43229fe0, rs=0x4322a150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x43229fe0, rs=0x4322a150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f1a3d80, rs=0x4322ac30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f1a3d80, rs=0x4322ac30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f1a3d80, rs=0x4322ac30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f1a3d80, rs=0x4322ac30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4322ad70, arg_v=0x1f1a3d80) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4322ad70, argv=0x31) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x43a2c940 (LWP 20890)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1f4b3740, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x438aa460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f2ac080, tid=0x1f4b3740, id=1968, eip=0x438aa490, flag=0, lock=0x438aa460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at backover.c:750 ---Type <return> to continue, or q <return> to quit--- #11 0x00000000004318b4 in fe_op_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f2ac080, rs=0x43a2bc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x43a2bd70, arg_v=0x1f2ac080) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x43a2bd70, argv=0x57) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x4422d940 (LWP 20891)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1143134528) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x4422bfe0, rs=0x4422c150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x4422bfe0, rs=0x4422c150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x4422bfe0, rs=0x4422c150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x4422bfe0, rs=0x4422c150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f3ac600, rs=0x4422cc30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f3ac600, rs=0x4422cc30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f3ac600, rs=0x4422cc30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f3ac600, rs=0x4422cc30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4422cd70, arg_v=0x1f3ac600) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4422cd70, argv=0x62) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x44a2e940 (LWP 21020)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so ---Type <return> to continue, or q <return> to quit--- #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fc7ade0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x448ac460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f5bf860, tid=0x1fc7ade0, id=1968, eip=0x448ac490, flag=0, lock=0x448ac460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1f5bf860, rs=0x44a2dc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x44a2dd70, arg_v=0x1f5bf860) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x44a2dd70, argv=0x68) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x4522f940 (LWP 21021)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fcfb000, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x450ad460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x20012790, tid=0x1fcfb000, id=1968, eip=0x450ad490, flag=0, lock=0x450ad460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x20012790, rs=0x4522ec30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x20012790, rs=0x4522ec30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x20012790, rs=0x4522ec30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x4522ed70, arg_v=0x20012790) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x4522ed70, argv=0x5f) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 ---Type <return> to continue, or q <return> to quit--- #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x45a30940 (LWP 21086)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x2000f1d0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x458ae460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fed5290, tid=0x2000f1d0, id=1968, eip=0x458ae490, flag=0, lock=0x458ae460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1fed5290, rs=0x45a2fc30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x45a2fd70, arg_v=0x1fed5290) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x45a2fd70, argv=0x60) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x46231940 (LWP 21087)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2814ea in __lock_vec () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x00002b1c9a28212b in __lock_vec_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #6 0x000000000050f6fe in hdb_cache_entry_db_relock (bdb=0x1ed02f30, txn=0x207ff300, ei=0x1fe43b10, rw=1, tryOnly=0, lock=0x4622f180) at cache.c:198 #7 0x0000000000511817 in hdb_cache_modify (bdb=0x1ed02f30, e=0x1ee1ed68, newAttrs=0x201b6b30, txn=0x207ff300, lock=0x4622f180) at cache.c:1231 #8 0x00000000004da9ce in hdb_modify (op=0x20011d70, rs=0x46230c30) at modify.c:662 #9 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30, which=op_modify, oi=0x1ed31f10, on=0x0) at backover.c:671 #10 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30, which=op_modify) at backover.c:723 #11 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at backover.c:762 #12 0x000000000044dfd7 in fe_op_modify (op=0x20011d70, rs=0x46230c30) at modify.c:303 ---Type <return> to continue, or q <return> to quit--- #13 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30, which=op_modify, oi=0x1ed02760, on=0x0) at backover.c:671 #14 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30, which=op_modify) at backover.c:723 #15 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at backover.c:762 #16 0x000000000044d8e5 in do_modify (op=0x20011d70, rs=0x46230c30) at modify.c:177 #17 0x000000000042dbce in connection_operation (ctx=0x46230d70, arg_v=0x20011d70) at connection.c:1138 #18 0x000000000042e153 in connection_read_thread (ctx=0x46230d70, argv=0x66) at connection.c:1274 #19 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #20 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #21 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x46a32940 (LWP 21200)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1185098048) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x46a30fe0, rs=0x46a31150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x46a30fe0, rs=0x46a31150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x46a30fe0, rs=0x46a31150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x46a30fe0, rs=0x46a31150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4acf50, rs=0x46a31c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f4acf50, rs=0x46a31c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1f4acf50, rs=0x46a31c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4acf50, rs=0x46a31c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x46a31d70, arg_v=0x1f4acf50) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x46a31d70, argv=0x63) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x47233940 (LWP 21201)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so ---Type <return> to continue, or q <return> to quit--- #3 0x00002b1c9a280b49 in __lock_get_internal () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #4 0x00002b1c9a2812c2 in __lock_get_pp () from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so #5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30, txn=0x1fbf4800, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x470b1460) at cache.c:234 #6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fbf6de0, tid=0x1fbf4800, id=1968, eip=0x470b1490, flag=0, lock=0x470b1460) at cache.c:988 #7 0x00000000004e15e7 in hdb_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:737 #8 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30, which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671 #9 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30, which=op_search) at backover.c:723 #10 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at backover.c:750 #11 0x00000000004318b4 in fe_op_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:402 #12 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30, which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671 #13 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30, which=op_search) at backover.c:723 #14 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at backover.c:750 #15 0x0000000000431193 in do_search (op=0x1fbf6de0, rs=0x47232c30) at search.c:247 #16 0x000000000042dbce in connection_operation (ctx=0x47232d70, arg_v=0x1fbf6de0) at connection.c:1138 #17 0x000000000042e153 in connection_read_thread (ctx=0x47232d70, argv=0x67) at connection.c:1274 #18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x47a34940 (LWP 21202)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1201883456) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x47a32fe0, rs=0x47a33150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x47a32fe0, rs=0x47a33150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x47a32fe0, rs=0x47a33150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x47a32fe0, rs=0x47a33150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe6e000, rs=0x47a33c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fe6e000, rs=0x47a33c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fe6e000, rs=0x47a33c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe6e000, rs=0x47a33c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x47a33d70, arg_v=0x1fe6e000) at connection.c:1138 ---Type <return> to continue, or q <return> to quit--- #20 0x000000000042e153 in connection_read_thread (ctx=0x47a33d70, argv=0x6a) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x48235940 (LWP 21203)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1210276160) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x48233fe0, rs=0x48234150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x48233fe0, rs=0x48234150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x48233fe0, rs=0x48234150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x48233fe0, rs=0x48234150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe91140, rs=0x48234c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fe91140, rs=0x48234c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fe91140, rs=0x48234c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe91140, rs=0x48234c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x48234d70, arg_v=0x1fe91140) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x48234d70, argv=0x64) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x40930940 (LWP 21498)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1083377984) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x4092efe0, rs=0x4092f150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x4092efe0, rs=0x4092f150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x4092efe0, rs=0x4092f150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x4092efe0, rs=0x4092f150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1f5bf360, rs=0x4092fc30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1f5bf360, rs=0x4092fc30) at result.c:505 ---Type <return> to continue, or q <return> to quit--- #8 0x0000000000443c2f in send_ldap_response (op=0x1f5bf360, rs=0x4092fc30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f5bf360, rs=0x4092fc30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x4092fd70, arg_v=0x1f5bf360) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x4092fd70, argv=0x25) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x48a36940 (LWP 21499)): #0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized out>, owner=1218668864) at rmutex.c:129 #2 0x000000000052efb7 in accesslog_op_mod (op=0x48a34fe0, rs=0x48a35150) at accesslog.c:1889 #3 0x00000000004bbb2b in overlay_op_walk (op=0x48a34fe0, rs=0x48a35150, which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661 #4 0x00000000004bbdbd in over_op_func (op=0x48a34fe0, rs=0x48a35150, which=op_modify) at backover.c:723 #5 0x00000000004bbed3 in over_op_modify (op=0x48a34fe0, rs=0x48a35150) at backover.c:762 #6 0x000000000053c7af in ppolicy_bind_response (op=0x1fbf8d90, rs=0x48a35c30) at ppolicy.c:1173 #7 0x0000000000443a08 in slap_response_play (op=0x1fbf8d90, rs=0x48a35c30) at result.c:505 #8 0x0000000000443c2f in send_ldap_response (op=0x1fbf8d90, rs=0x48a35c30) at result.c:579 #9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fbf8d90, rs=0x48a35c30) at result.c:851 #10 0x000000000050f2f3 in hdb_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:158 #11 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671 #12 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind) at backover.c:723 #13 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at backover.c:738 #14 0x0000000000456411 in fe_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:383 #15 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671 #16 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30, which=op_bind) at backover.c:723 #17 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at backover.c:738 #18 0x0000000000455b40 in do_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:205 #19 0x000000000042dbce in connection_operation (ctx=0x48a35d70, arg_v=0x1fbf8d90) at connection.c:1138 #20 0x000000000042e153 in connection_read_thread (ctx=0x48a35d70, argv=0x30) at connection.c:1274 #21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at tpool.c:685 ---Type <return> to continue, or q <return> to quit--- #22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0 #23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2b1c9a53dbd0 (LWP 20884)): #0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922 #2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983 I've tried to upload bulky materials to the incoming directory of ftp.openldap.org but there was no space left to upload. My upload required 5950450 bytes only. So, I'm waiting for free disk space on the FTP server. BTW, here's the slapd.conf file : ########################################################################### # Section globale: les directives definies dans cette section s'appliquent # a tous les suffixes definis. # Cette section se termine juste avant la premiere directive "database" ########################################################################### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/vetoquinol.schema # Inclusion du fichier definissant les droits d'acces globaux # (cad s'appliquant a tous les suffixes (donnees, schema, cn=config, cn=monitor, etc ...)) include /etc/openldap/vtq-global-access.conf # Delai en secondes au bout duquel les connections inactives sont fermees par le serveur #idletimeout 600 # Allow LDAPv2 client connections. This is NOT the default. #allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd-master1.pid argsfile /var/run/openldap/slapd-master1.args logfile /var/log/openldap-master1-debug.log loglevel 256 #loglevel 8193 # Option utilisee en mode multi-maitre seulement # La valeur doit etre differente pour chaque instance d'annuaire serverID 1 # Load dynamic backend modules: # modulepath /usr/lib64/openldap # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. #TLSCACertificateFile /etc/openldap/OpenSSL_ca.crt #TLSCertificateFile /etc/openldap/OpenSSL_server.crt #TLSCertificateKeyFile /etc/openldap/OpenSSL_server.key #TLSCipherSuite TLSv1:SSLv3 # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # Inclusion du fichier definissant les droits d'acces pour dc=vetoquinol authz-policy to include /etc/openldap/vtq-access.conf include /etc/openldap/deleted-access.conf # Nombre maximum par defaut d'entrees renvoyees lors d'une recherche sizelimit 2000 # Module necessaire pour pouvoir demander a OpenLDAP # de trier les entrees renvoyees overlay sssvlv ####################################################################### # ldbm and/or bdb database definitions ####################################################################### ####################################################################### # Monitoring BDB database definition # ####################################################################### # Base (optionnelle) utilisee pour la supervision et l'obtention de statistiques # sur l'activite de l'annuaire database monitor rootdn cn=monitoring,cn=Monitor rootpw {SSHA}pdXDKQIKBa/oYZgDeNyum8VvJ8D0yTaZ #rootpw monitoring database hdb suffix "dc=vetoquinol" rootdn "cn=Manager,dc=vetoquinol" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw ********* # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. # Emplacement de la base pour le suffixe dc=vetoquinol directory /var/lib/ldap-master1/vtq # Indices to maintain for this database # Index generaux index objectclass,entryCSN,entryUUID,creatorsname,modifiersname eq index pwdaccountlockedtime,pwdfailuretime,pwdgraceusetime,uid,uniquemember pres index businessCategory,employeeType eq,pres index c,cn,employeeNumber,givenName,mail,sn,telephonenumber,l,departmentnumber eq,pres,sub # Index specifiques VTQ index vtq-langues,vtq-section,vtq-date-entree,vtq-date-sortie,vtq-date-mutation eq index vtq-activite eq,pres index vtq-ref-fonction eq,pres,sub # Extension pour pouvoir gerer des groupes dynamiques # Dans l'exemple ci-dessous: # - un groupe dynamique doit avoir la classe d'objet groupOfURLs # - l'attribut (du groupe dynamique) memberURL doit contenir une URL LDAP, # par exemple ldap://hostname:port/ou=people??one?(&(objectclass=vtq-personne)(c=FR)) # - l'attribut multi-valué (du groupe dynamique) uniqueMember est alors généré dynamiquement # et contient la liste des membres du groupe (donc une liste de DN) # overlay dynlist #dynlist-attrset groupOfURLs memberURL uniqueMember # Extension pour obtenir a partir d'un utilisateur # la liste des groupes auxquels il appartient #memberof-memberof-ad isMemberOf overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniqueMember memberof-refint TRUE # Definition des parametres de replication pour un annuaire maitre # L'appel au module syncprov est necessaire pour indiquer que l'annuaire est maitre # Le parametrage ci-dessous indique que la derniere ecriture sur la base est consignee # sur disque soit tous les 100 changements, soit au bout de 2 minutes overlay syncprov syncprov-checkpoint 100 2 # Definition des liens de replication # Le numero de rid doit etre different pour chaque suffixe replique # d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un meme suffixe # (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou esclave) # L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes # L'authentification aupres du maitre peut prendre jusqu'a 10 secondes # Tous les attributs et toutes les entrees sont repliques syncrepl rid=001 provider=ldap://rhvtq:2389 bindmethod=simple binddn="cn=replication user,ou=special users,dc=vetoquinol" credentials=********* searchbase="dc=vetoquinol" type=refreshAndPersist logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" retry="60 +" network-timeout=5 timeout=10 schemachecking=on attrs="*,+" filter="(objectclass=*)" # Activation du mode multi-maitre mirrormode on overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+02:00 # Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe dc=vetoquinol limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Recherche en nombre et en temps illimitee pour le compte de synchronisation vers AD sur le suffixe dc=vetoquinol limits dn.exact="cn=lsc user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le suffixe "dc=vetoquinol" # Lors de requetes ou cn=yellow pages se fait passer pour un autre utilisateur, # ce sont les limites de cet utilisateur qui s'appliquent limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # Emplacement de la strategie par defaut de gestion des mots de passe overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=vetoquinol" # L'option ci-dessous permet de renvoyer un code d'erreur explicite en cas de compte verrouille # Ne pas activer cette option donne moins d'informations en cas d'attaque #ppolicy_use_lockout # Hachage automatique des mots de passe entres en clair ppolicy_hash_cleartext # tuning base du suffixe dc=vetoquinol # Taille du cache des entrees cachesize 2000 # Taille du cache pour les recherches les plus demandees idlcachesize 6000 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb (3883008 octets au 5/07/2011) + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/vtq # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 ####################################################################### # Deleted Entries database definition # ####################################################################### database hdb suffix "o=deleted entries" rootdn "cn=Manager,o=deleted entries" rootpw ********* # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. # Emplacement de la base pour le suffixe o=deleted directory /var/lib/ldap-master1/deleted # Module necessaire pour pouvoir demander a OpenLDAP # de trier les entrees renvoyees overlay sssvlv # Index generaux index entryCSN,entryUUID,objectclass eq index employeeType eq,pres index cn,sn,employeeNumber eq,pres,sub # Definition des parametres de replication pour un annuaire maitre # L'appel au module syncprov est necessaire pour indiquer que l'annuaire est maitre # Le parametrage ci-dessous indique que la derniere ecriture sur la base est consignee # sur disque soit tous les 100 changements, soit au bout de 2 minutes overlay syncprov syncprov-checkpoint 100 2 # Definition des liens de replication # Le numero de rid doit etre different pour chaque suffixe replique # d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un meme suffixe # (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou esclave) # L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes # L'authentification aupres du maitre peut prendre jusqu'a 10 secondes # Tous les attributs et toutes les entrees sont repliques syncrepl rid=002 provider=ldap://rhvtq:2389 bindmethod=simple binddn="cn=replication user,ou=special users,dc=vetoquinol" credentials=********* searchbase="o=deleted entries" type=refreshAndPersist logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" retry="60 +" network-timeout=5 timeout=10 schemachecking=on attrs="*,+" filter="(objectclass=*)" # Activation du mode multi-maitre mirrormode on overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+02:00 # Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe o=deleted entries limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le suffixe "o=deleted entries" limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited # tuning base du suffixe o=deleted entries # Taille du cache des entrees # Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe principal (dc=vetoquinol) cachesize 200 # Taille du cache pour les recherches les plus demandees idlcachesize 600 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/deleted # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 ####################################################################### # Accesslog HDB database definition # ####################################################################### # Definition de la base (optionnelle) accesslog # Cette base permet d'optimiser la replication en ne repliquant # que la partie d'une entree qui est modifiee plutot que l'entree en entier database hdb suffix cn=accesslog directory /var/lib/ldap-master1/accesslog rootdn cn=accesslog # Definition des index pour optimiser l'acces au suffixe cn=accesslog # Seul un annuaire esclave accede a ce suffixe en principe pour savoir ce qui # a ete modifie depuis la session de replication precedente index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart #Recherche en nombre et en temps illimitee pour le compte de replication, sur le suffixe cn=accesslog limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # tuning base du suffixe cn=accesslog # Taille du cache des entrees # Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe principal (dc=vetoquinol) cachesize 200 # Taille du cache pour les recherches les plus demandees idlcachesize 600 # Taille du cache de base de donnees # voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_mai… # Idealement: taille du fichier id2entry.bdb + 10% # Syntaxe: x y z ou: # x represente la taille du cache en Go # y represente la taille du cache en octets # z represente le nombre de sous-regions de cache a creer dbconfig set_cachesize 0 4400000 1 # Taille en octets du tampon memoire pour le journal des transactions dbconfig set_lg_bsize 2097152 # Emplacement du journal des transactions dbconfig set_lg_dir /var/lib/ldap-master1/accesslog # Rotation automatique du journal des transactions dbconfig set_flags DB_LOG_AUTOREMOVE # Nombre maximum de verrous sur la base dbconfig set_lk_max_locks 10000 # Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des verrous dbconfig set_lk_max_lockers 10000 # Nombre maximum d'objets verrouilles dbconfig set_lk_max_objects 10000 The slapd.conf file is as follows

1 0

(ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by ashish＠sendmail.com 04 Aug '11

04 Aug '11

Full_Name: Ashish Gawarikar Version: 2.4.23 OS: Redhat 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.253.98.197) In my slapd.conf file: ... TLSCertificateFile TLSCertificateKeyFile ... If I have the above, I get a core dump, with the error: slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed. Let me know if you need the core file.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs