- openldap-bugs - openldap.org

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 22 Jan '07

22 Jan '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: 2.4.2alpha >> When adding a alias abject to the provider, syncprov fowllows the referral and >> is not updating the alias object to the consumer, > > Dieter, > > are you talking about aliases or referrals? > > I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While > a new 2.4 release might be desirable, I suggest you test HEAD instead. I note that this code has been present in syncprov, unchanged, for quite a long time (throughout 2.3 to current): if ( op->ors_deref & LDAP_DEREF_SEARCHING ) { send_ldap_error( op, rs, LDAP_PROTOCOL_ERROR, "illegal value for derefAliases" ); return rs->sr_err; } which would prevent syncprov from chasing aliases during a search. As such, I think you need provide a test case that illustrates the problem. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by ando＠sys-net.it 22 Jan '07

22 Jan '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.2alpha > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.177.66) > > > When adding a alias abject to the provider, syncprov fowllows the referral and > is not updating the alias object to the consumer, Dieter, are you talking about aliases or referrals? I also note that, AFAIK, 2.4.2alpha is way out of sync with HEAD. While a new 2.4 release might be desirable, I suggest you test HEAD instead. p.

1 0

(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 21 Jan '07

21 Jan '07

Full_Name: Dieter Kluenter Version: 2.4.2alpha OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.177.66) When adding a alias abject to the provider, syncprov fowllows the referral and is not updating the alias object to the consumer, -Dieter

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by ando＠sys-net.it 20 Jan '07

20 Jan '07

Apparently, according to slurpd's replog, no operational attrs are modified on modrdn. In fact, modrdn is replicated as a plain modrdn, which does not alter the write-related operational attrs (nor it is allowed to, according to LDIF, as per RFC 2849). Rep-logging an additional modify that only changes the write-related operational attrs could fix the problem, at the cost of not making it atomical. A "cleaner" solution would be to wrap a modify with a control that gets added to the modrdn operation by slurpd, which modifies modifiersName, modifyTimestamp and entryCSN using the "relax" control. Or, the (yet unpublished) "relax" control could be redefined to allow an optional control value that contains a modification required to maintain consistency of the final entry, or something like that. This definitely needs investigation, but it could be considered yet another reason for dropping slurpd. p.

1 0

(ITS#4809) Replication of operational attributes when performing modrdn operation
by Thomas.Fritz＠bam.de 19 Jan '07

19 Jan '07

Full_Name: Thomas Fritz Version: 2.3.33 OS: Debian Gnu/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.63.61.111) We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb backend. When performing the modrdn operation against the master, no update directives for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are written to the replog file. Hence, the databases of master and slave differ by the values of these attributes after replication. This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions back to (at least) 2.3.24 are affected.

1 0

(ITS#4808) erroneous error code testing in back-ldap
by ando＠sys-net.it 17 Jan '07

17 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando in a couple of places, LDAP_SERVER_DOWN is tested after client library error codes have already been mapped to response codes (LDAP_SERVER_DOWN => LDAP_UNAVAILABLE). As a consequence, delete and modrdn are not retried as appropriate. p.

1 0

(ITS#4807) CLOCK-Pro cache replacement
by hyc＠OpenLDAP.org 16 Jan '07

16 Jan '07

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/hyc-20070116.txt Submission from: (NULL) (76.168.84.21) Submitted by: hyc This is a rough implementation of the CLOCK-Pro cache replacement algorithm for back-bdb. It's based on the paper published here http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/abs05-3.html Currently the performance is not very good; the algorithm can invoke multiple scans of the Clock list and our lock overhead for those scans is too high. I'm not planning to do any more with this at the moment, just wanted to post it so it doesn't get lost, in case someone else is interested. I didn't want to commit it behind #ifdef's because that would get too messy. This implementation deviates from the paper in two major respects: 1) it's possible for an EntryInfo node to get its Reference bit set even when the entry is not Resident. This happens very frequently, in cache_find_ndn. As such, EntryInfo nodes without an Entry, but that have been Referenced, do not get flushed by HANDtest. 2) Nodes can get their Reference bit cleared at many points during the Clock-Pro processing, so the bit is not a good indication of whether a node is currently in use and may be safely freed. So, elaborate lock checks are used at each point where the original algorithm would simply free a node (HANDcold, HANDtest). It would be nice if our locking setup could be simplified. If someone else wants to jump in and clean it up, it may be worth committing down the road.

1 0

(ITS#4806) allow internal operations to require more specific access privileges
by ando＠sys-net.it 16 Jan '07

16 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Occasionally, internal operations, and significantly searches, are performed for some given purpose which would require different access privileges than, for example in case of searches, "search" on the filter and "read" on the data. In those cases, it may be useful to allow issuers of internal operations to change the access privilege that's requested. This feature (is implemented to address an issue with slapo-dynlist(5) which uses an internal search to collect data for compare, and thus checks "search" access on the filter of the memberURL and "read" on the datum to be compared. See <http://www.openldap.org/lists/openldap-devel/200701/msg00056.html> for discussion.

1 0

(ITS#4805) memory leak in syncrepl code
by ando＠sys-net.it 15 Jan '07

15 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando There seems to be few memory leaks in syncrepl code (detected by valgrind when running test048); one is when parsing an entry and sync "present" or "done". It's now fixed in HEAD/re23. Others are being investigated p.

1 0

Re: (ITS#4591) back-meta does not propagate response controls
by ando＠sys-net.it 15 Jan '07

15 Jan '07

ando(a)sys-net.it wrote: > In most cases, all response payload (matched, referrals) is ignored when calling > ldap_parse_result(); only in searches matched and referrals are handled. For most operations this should now be fixed, since response passes thru meta_back_op_result(), which takes care of controls. However, in case of searches, handling this issue may be problematic, as different targets may return different, possibly overlapping or incompatible controls in response, so ignoring them might be safe. A minimal, forgiving approach could be to record response controls, and, in case only one target returned any, use them; otherwise, either ignore them or complain somehow. p.

1 0

Re: Antwort: Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 12 Jan '07

12 Jan '07

Michael.Heep(a)o2.com wrote: > Today I deployed a patched 2.3.32 version on one of our replicas and > changed the config to include the aforementioned dynlist/valsort > construct. > It's been running nicely for a few hours now. Seems like the patch fixed > this issue. Thank you very much! Thanks for the feedback. The fix will appear in 2.3.33. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Antwort: Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by Michael.Heep＠o2.com 12 Jan '07

12 Jan '07

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 005BCC39C1257261_= Content-Type: text/plain; charset="US-ASCII" Today I deployed a patched 2.3.32 version on one of our replicas and changed the config to include the aforementioned dynlist/valsort construct. It's been running nicely for a few hours now. Seems like the patch fixed this issue. Thank you very much! With kind regards Michael Heep Pierangelo Masarati <ando(a)sys-net.it> 11.01.2007 23:37 An michael.heep(a)o2.com Kopie openldap-its(a)openldap.org Thema Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5). The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3). The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23). Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------ --=_alternative 005BCC39C1257261_= Content-Type: text/html; charset="US-ASCII" Today I deployed a patched 2.3.32 version on one of our replicas and changed the config to include the aforementioned dynlist/valsort construct. It's been running nicely for a few hours now. Seems like the patch fixed this issue. Thank you very much! With kind regards Michael Heep <table width=100%> <tr valign=top> <td width=40%>Pierangelo Masarati <ando(a)sys-net.it> 11.01.2007 23:37 <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>An</div> <td>michael.heep(a)o2.com <tr valign=top> <td> <div align=right>Kopie</div> <td>openldap-its(a)openldap.org <tr valign=top> <td> <div align=right>Thema</div> <td>Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive </table> <table> <tr valign=top> <td> <td></table> </table> <tt>michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset                extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. >   A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5).  The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3).  The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23).  Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office:   +39.02.23998309 Mobile:   +39.333.4963172 Email:    pierangelo.masarati(a)sys-net.it ------------------------------------------ </tt> --=_alternative 005BCC39C1257261_=--

1 0

Deny bind for subtree not working?
by Daniel Hasler 12 Jan '07

12 Jan '07

Hi I try to deni BIND for all entries in a subtree. I compiled openldap with the LDAP backend, because this is only a proxy that forwards request to another directory. Following is my configuration: >include /local/home/hasleda4/openldap/etc/openldap/schema/core.schema >include /local/home/hasleda4/openldap/etc/openldap/schema/cosine.schema >include /local/home/hasleda4/openldap/etc/openldap/schema/inetorgperson.schema > >pidfile /local/home/hasleda4/openldap/var/run/gaad-slapd.pid >argsfile /local/home/hasleda4/openldap/var/run/gaad-slapd.args > >database ldap >suffix "dc=company,dc=com" >uri "ldaps://other-dir.net:26930" > >access to dn.subtree="ou=people,ou=intranet,dc=company,dc=com" by dn.subtree="ou=applications,ou=intranet,dc=company,dc=com" read > by * none >access to dn.subtree="ou=applications,ou=intranet,dc=company,dc=com" by users read > by anonymous auth > by * none >access to * by * read As by the first ACL, anonymous users are not allowed to bind against "ou=people,ou=intranet,dc=novartis,dc=com". If I now try to bind, the ACL seems not to be evaluated (I run slapd with -d 128 to see ACL processing, and there is no output during the BIND) and the BIND operation succeeds if I give the correct password. Is this a bug? Or just how openldap behaves for bind operations? Is there another way to deny bind operations for a subtree? Thanks for any response. Cheers Dani

1 0

Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 11 Jan '07

11 Jan '07

michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > A bug (ITS#4801) was recently fixed in slapo-dynlist(5) which appeared in conjunction with slapo-valsort(5). The fix is available both in HEAD and in re23 CVS (tag OPENLDAP_REL_ENG_2_3). The relevant change is in servers/slapd/overlays/dynlist.c 1.28 -> 1.29 (HEAD) or 1.5.2.9 -> 1.5.2.10 (re23). Could you please check if it does any good to the issue you reported? Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 9:15 PM +0000 ando(a)sys-net.it wrote: > quanah(a)stanford.edu wrote: >> Okay, I can confirm it works as expected once valsort is no longer >> used.... >> > Please try servers/slapd/overlays/dynlist.c 1.28 -> 1.29 Now it works with valsort also loaded. :) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4801) segfault in dynlist
by ando＠sys-net.it 11 Jan '07

11 Jan '07

quanah(a)stanford.edu wrote: > Okay, I can confirm it works as expected once valsort is no longer used.... > Please try servers/slapd/overlays/dynlist.c 1.28 -> 1.29 p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 8:57 PM +0000 quanah(a)stanford.edu wrote: > > > --On Thursday, January 11, 2007 9:53 PM +0100 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> quanah(a)stanford.edu wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.32 >>> OS: Linux 2.6 (64-bit) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.81) >>> >> I'm not seeing anything like that, neither with HEAD nor with re23. It >> might be worth having a bit more details on your configuration, since >> that resulting from test044 (which basically complies with the info you >> provided) doesn't even hit that line of code (because rs->sr_flags == 0). >> So there must be something in between that causes the entry to be freed. >> That could be slapo-dynlist in some cases, but also slapo-translucent, >> slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you >> should share the conf, the data and the op that's causing trouble. > > The search I'm performing is: Okay, I can confirm it works as expected once valsort is no longer used.... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 9:53 PM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.32 >> OS: Linux 2.6 (64-bit) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.81) >> > I'm not seeing anything like that, neither with HEAD nor with re23. It > might be worth having a bit more details on your configuration, since > that resulting from test044 (which basically complies with the info you > provided) doesn't even hit that line of code (because rs->sr_flags == 0). > So there must be something in between that causes the entry to be freed. > That could be slapo-dynlist in some cases, but also slapo-translucent, > slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you > should share the conf, the data and the op that's causing trouble. The search I'm performing is: ldapsearch -LLL -Q -h ldap-dev1.stanford.edu -b "cn=groups,cn=applications,dc=stanford,dc=edu" the slapd.conf is as follows, and the group configurations are as previously noted. My principal has full read into the LDAP database, so the only ACL parsed is access to * for it. I am using valsort, so perhaps it is an interaction between those two? # $Id: slapd.conf.dev,v 1.7 2007/01/11 00:05:44 quanah Exp $ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/krb5-kdc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/eduperson.schema include /usr/local/etc/openldap/schema/suacct.schema include /usr/local/etc/openldap/schema/superson.schema include /usr/local/etc/openldap/schema/suapplication.schema # Allow V2 binds allow bind_v2 # Use star cert TLSCertificateFile /usr/local/etc/openldap/stardomain.crt TLSCertificateKeyFile /usr/local/etc/openldap/stardomain.key TLSCACertificateFile /usr/local/etc/openldap/comodo.pem # Define global ACLs include /usr/local/etc/openldap/slapd.acl # pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # Set the default search base for clients that don't specify a base. defaultsearchbase "dc=stanford,dc=edu" # Turn gentlehup off, it takes too long. gentlehup off # Read slapd.conf(5) for possible values loglevel 256 # Set the number of threads (8 seems to work best) threads 8 # Set the number of threads to use in tool mode tool-threads 2 # Set the timeout for idle connections #idletimeout 30 # SASL conf sasl-realm stanford.edu sasl-authz-policy both sasl-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanford.edu sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active # Load dynamic backend modules: modulepath /usr/local/lib/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload valsort.la moduleload dynlist.la ####################################################################### # stanford.edu database definitions ####################################################################### database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" # Valsort Overlay overlay valsort valsort-attr ou cn=people,dc=stanford,dc=edu weighted valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL member # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Athletics principal have limitless searches limits dn.exact="cn=athletics,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Authority audit principal have limitless searches limits dn.exact="cn=workgroup-audit,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the Registry Data Auditor principal have limitless searches limits dn.exact="cn=RegistryDataAuditor,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Let the ispace prinicpal have a search of 5000 entries limits dn.exact="cn=ispace,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=5000 size.hard=5000 # Let the GSB person principal have unlimited searches limits dn.exact="cn=gsb-person,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Save the time that the entry gets modified lastmod on include /usr/local/etc/openldap/syncrepl.conf # Set the location of where the database storage files go. directory /var/lib/ldap dbconfig set_cachesize 3 536870912 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/bdb dbconfig set_lk_max_locks 3000 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_lockers 1500 # # Automatically remove log files that are no longer needed. dbconfig set_flags DB_LOG_AUTOREMOVE # # Setting set_tas_spins reduces resource contention from multiple clients on systems with multiple CPU's. dbconfig set_tas_spins 1 # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 1024 5 # Entries to cache in memory cachesize 50000 # IDL Entries to cache in memory idlcachesize 50000 # Entries to free up when cache gets full cachefree 1000 # Change the sub_any index length from 4 to 3 so that searches like *lee* work. index_substr_any_len 3 # Indices to maintain index default eq index cn eq,sub index dc index displayName index entryUUID index givenName eq,sub index homePhone eq,sub index krb5PrincipalName index mail eq,sub index mobile eq,sub index modifyTimestamp index o index objectClass index pager eq,sub index sn eq,sub,approx index suAffiliation index suCalendarStatus index suCardNumber pres,eq index suCN eq,sub index suDialinStatus index suDisplayAffiliation index suEmailPager eq,sub index suGeneralID eq,sub index suGivenName eq,sub index suGwAffilFax1 eq,sub index suGwAffilFax2 eq,sub index suGwAffilFax3 eq,sub index suGwAffilFax4 eq,sub index suGwAffilFax5 eq,sub index suGwAffilPhone1 eq,sub index suGwAffilPhone2 eq,sub index suGwAffilPhone3 eq,sub index suGwAffilPhone4 eq,sub index suGwAffilPhone5 eq,sub index suKerberosStatus index suLelandStatus index suLocalPhone eq,sub index suMaildrop index suOtherName index suPermanentPhone eq,sub index suPrimaryOrganizationID index suPrivilegeGroup eq,sub index suProxyCardNumber pres,eq index suRegID index suRegisteredName eq,sub index suResidencePhone eq,sub index suSearchID index suSeasStatus index suSeasSunetID index suSN eq,sub,approx index suSunetID index suUniqueIdentifier index suUnivID index suVisibAffilAddress1 index suVisibAffilAddress2 index suVisibAffilAddress3 index suVisibAffilAddress4 index suVisibAffilAddress5 index suVisibAffilFax1 index suVisibAffilFax2 index suVisibAffilFax3 index suVisibAffilFax4 index suVisibAffilFax5 index suVisibAffiliation1 index suVisibAffiliation2 index suVisibAffiliation3 index suVisibAffiliation4 index suVisibAffiliation5 index suVisibAffilPhone1 index suVisibAffilPhone2 index suVisibAffilPhone3 index suVisibAffilPhone4 index suVisibAffilPhone5 index suVisibEmail index suVisibFacsimileTelephoneNumber index suVisibHomeAddress index suVisibHomePage index suVisibHomePhone index suVisibIdentity index suVisibLocalAddress index suVisibMailAddress index suVisibMailCode index suVisibMobilePhone index suVisibPagerEmail index suVisibPagerPhone index suVisibPermanentAddress index suVisibProfile index suVisibStreet index suVisibSunetID index suVisibTelephoneNumber index telephoneNumber eq,sub index uid pres,eq index uidNumber ####################################################################### # back-monitor database definitions ####################################################################### database monitor reverse-lookup on -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4801) segfault in dynlist
by ando＠sys-net.it 11 Jan '07

11 Jan '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > I'm not seeing anything like that, neither with HEAD nor with re23. It might be worth having a bit more details on your configuration, since that resulting from test044 (which basically complies with the info you provided) doesn't even hit that line of code (because rs->sr_flags == 0). So there must be something in between that causes the entry to be freed. That could be slapo-dynlist in some cases, but also slapo-translucent, slapo-collect, slapo-rwm or slapo-valsort. I guess at this point you should share the conf, the data and the op that's causing trouble. p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4801) segfault in dynlist
by quanah＠stanford.edu 11 Jan '07

11 Jan '07

--On Thursday, January 11, 2007 12:18 AM +0000 quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.32 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > I decided to start playing with the dynlist overlay, but it cores slapd: I removed all my custom patches, and validated this happens in stock 2.3.32: (gdb) bt #0 0x00002b3947cbb3e3 in __db_shalloc (p=Variable "p" is not available. ) at ../dist/../env/db_salloc.c:157 #1 0x00002b3947cd8e2d in __memp_alloc (dbmp=0x2b3946abe2a0, memreg=0x2b3946abe1c0, mfp=0x2b3a43d2beb8, len=16543, offsetp=0x0, retp=0x414fc000) at ../dist/../mp/mp_alloc.c:94 #2 0x00002b3947cda2f6 in __memp_fget (dbmfp=0x2b39479af960, pgnoaddr=0x414fc0fc, flags=0, addrp=Variable "addrp" is not available. ) at ../dist/../mp/mp_fget.c:348 #3 0x00002b3947c66e3b in __bam_search (dbc=0x2b3947aee400, root_pgno=101187584, key=0x414fc310, flags=1409, stop=1, recnop=0x0, exactp=0x414fc224) at ../dist/../btree/bt_search.c:307 #4 0x00002b3947c5bc75 in __bam_c_search (dbc=0x2b3947aee400, root_pgno=0, key=0x414fc310, flags=28, exactp=0x414fc224) at ../dist/../btree/bt_cursor.c:2547 #5 0x00002b3947c5cc86 in __bam_c_get (dbc=0x2b3947aee400, key=0x414fc310, data=0x414fc2f0, flags=28, pgnop=0x414fc2b4) at ../dist/../btree/bt_cursor.c:962 #6 0x00002b3947ca74f0 in __db_c_get (dbc_arg=0x2b3947aee740, key=0x414fc310, data=0x414fc2f0, flags=28) at ../dist/../db/db_cam.c:643 #7 0x00002b3947b1b92e in hdb_id2entry (be=Variable "be" is not available. ) at id2entry.c:125 #8 0x00002b3947b20911 in hdb_cache_find_id (op=0x4167cd30, tid=0x0, id=376099, eip=0x4167c890, islocked=1, locker=26, lock=0x4167c820) at cache.c:760 #9 0x00002b3947b14034 in hdb_search (op=0x4167cd30, rs=0x4167cf00) at search.c:695 #10 0x0000000000477c6b in overlay_op_walk (op=0x4167cd30, rs=0x4167cf00, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #11 0x0000000000477fc5 in over_op_func (op=0x4167cd30, rs=0x4167cf00, which=op_search) at backover.c:560 #12 0x00002b394802c336 in dynlist_response (op=0x2aaaab0e03c8, rs=0x417feee0) at dynlist.c:463 #13 0x0000000000477afa in over_back_response (op=0x2aaaab0e03c8, rs=0x417feee0) at backover.c:236 #14 0x0000000000434eea in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x417feee0) at result.c:717 #15 0x00002b3947b14714 in hdb_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:878 #16 0x0000000000477c6b in overlay_op_walk (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search, oi=0x2b39479ca530, on=0x0) at backover.c:508 #17 0x0000000000477fc5 in over_op_func (op=0x2aaaab0e03c8, rs=0x417feee0, which=op_search) at backover.c:560 #18 0x00000000004293d2 in fe_op_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:355 #19 0x0000000000429c12 in do_search (op=0x2aaaab0e03c8, rs=0x417feee0) at search.c:217 #20 0x00000000004278b9 in connection_operation (ctx=dwarf2_read_address: Corrupted DWARF expression. ) at connection.c:1132 #21 0x0000000000427ca6 in connection_read_thread (ctx=0x417ff030, argv=Variable "argv" is not available. ) at connection.c:1260 #22 0x00002b3945688794 in ldap_int_thread_pool_wrapper (xpool=0x2b3946ee0080) at tpool.c:478 -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4804) slapd shutdown hang
by Kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

At 10:13 AM 1/11/2007, kurt(a)OpenLDAP.org wrote: >Full_Name: Kurt Zeilenga >Version: HEAD >OS: FreeBSD 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (71.80.218.136) > > >In current HEAD (as well as for the last couple of days), slapd(8) has been >consistently (every time) been hanging on shutdown. For instance, when running >test000, gdb shows: >> thread apply all bt >Thread 2 (process 71085, thread 2): >#0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 >#1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 >#3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 >#4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 >#5 0x0 in ?? () > >Thread 1 (process 71085, thread 1): >#0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 >#1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 >#2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 >#3 0x0 in ?? () > >The last few log messages are: >daemon: shutdown requested and initiated. >slapd shutdown: waiting for 0 threads to terminate >slapd shutdown: initiated >====> bdb_cache_release_all >slapd destroy: freeing system resources. > >I suspect a recent (in the last week or so) is the cause... I complete rebuild seems have cured this problem. Kurt

1 0

(ITS#4804) slapd shutdown hang
by kurt＠OpenLDAP.org 11 Jan '07

11 Jan '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.80.218.136) In current HEAD (as well as for the last couple of days), slapd(8) has been consistently (every time) been hanging on shutdown. For instance, when running test000, gdb shows: > thread apply all bt Thread 2 (process 71085, thread 2): #0 0x28fc0197 in _thread_kern_sched () from /usr/lib/libc_r.so.4 #1 0x28fc09e5 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc296d in pthread_cond_timedwait () from /usr/lib/libc_r.so.4 #3 0x28fa959b in _thread_gc () from /usr/lib/libc_r.so.4 #4 0x28f824d8 in _thread_start () from /usr/lib/libc_r.so.4 #5 0x0 in ?? () Thread 1 (process 71085, thread 1): #0 0x28fc1914 in __sys_poll () from /usr/lib/libc_r.so.4 #1 0x28fc0df9 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.4 #2 0x28fc07ae in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 #3 0x0 in ?? () The last few log messages are: daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate slapd shutdown: initiated ====> bdb_cache_release_all slapd destroy: freeing system resources. I suspect a recent (in the last week or so) is the cause...

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 11 Jan '07

11 Jan '07

Hello! I have added the following to NOTICE file inside the provided .zip file: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Radovan Skolnik radovan(a)skolnik.info. These modifications are not subject to any license of TEMPEST, a.s. I, Radovan Skolnik, 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. I hope that is OK. Best regards Radovan Skolnik On Tuesday 09 January 2007 04:14, Kurt D. Zeilenga wrote: > At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: > >Full_Name: Radovan Skolnik > >Version: JLDAP CVS version > >OS: Windows/Java > >URL: http://www.skolnik.info/LDAPPagedResults.zip > >Submission from: (NULL) (82.119.120.128) > > > > > >Hello, > > > >I hope this is the right place to make this submission ;-) Recently I > > found that JLDAP does not support simple paging mechanism via control as > > stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an > > attempt to implement it and it seems to me it works as it's supposed to. > > I would like to contribute it to the project for the benefit of others. > > The files can be found at > >http://www.skolnik.info/LDAPPagedResults.zip If there is something more > > needed from me please let me know. > > Your submission lacks both a notice of origin and a > rights statement, as required of contributions. See > <http://www.openldap.org/devel/contributing.html#notice>. > Though submissions such as this should be in the form > of patch file (with notices placed above the patch in the > file), a zip file is acceptable. In this case, just place > the required notice and statement in a file called NOTICE. > > Please revise. -- Kurt

1 0

(ITS#4803) slapacl(8) man page still mentions the "defaultaccess" directive
by ando＠sys-net.it 11 Jan '07

11 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando AFAICT it was removed since 2.1... p.

1 0

(ITS#4802) refint mutex bug
by h.b.furuseth＠usit.uio.no 11 Jan '07

11 Jan '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) overlays/refint.c:refint_close() does refint_data *id = on->on_bi.bi_private; memset( id, 0, sizeof(*id)); which overwrites id->qmutex. Then refint_db_destroy() does ldap_pvt_thread_mutex_destroy( &id->qmutex ); which can fail. I don't know what the required lifetime for that mutex is - if refint_close() must preserve it, or if it can destroy it and set on->on_bi.bi_private = NULL (so refint_db_destroy will do nothing), or something else.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs