openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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 17 Jan '07

17 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs