openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

Re: (ITS#5786) too many arguments to function slap_get_commit_csn
by hyc＠symas.com 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.88) > > > HEAD synced, invoked configure after make distclean > > cd overlays; make -w static > make[3]: Entering directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. > -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o > syncprov.o syncprov.c > syncprov.c: In function syncprov_op_response: > syncprov.c:1612: error: too many arguments to function slap_get_commit_csn > syncprov.c:1621: error: too many arguments to function slap_get_commit_csn > make[3]: *** [syncprov.o] Error 1 > make[3]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > make[2]: *** [liboverlays.a] Error 2 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' > make: *** [all-common] Error 1 Incomplete commit. Fixed now. -- -- 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#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Further info is available here: <http://www.openldap.org/faq/data/cache/1471.html> p.

1 0

(ITS#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/cf.tar.gz Submission from: (NULL) (81.72.89.40) Submitted by: ando This module registers the "Codice Fiscale" syntax, derived from directoryString, and makes it compatible with the caseExactMatch matchingRule. It also defines a "codiceFiscale" attribute and the "codiceFiscaleBase" and "codiceFiscaleObject" objectClasses. I believe this software and these schema items will probably be mainly useful to Italian users and developers of OpenLDAP software. This software has been developed by myself, based on publicly available information. It is released under the OpenLDAP license for use with OpenLDAP software. p.

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

See also <http://www.openldap.org/lists/openldap-devel/200811/msg00000.html> and specifically <http://www.openldap.org/lists/openldap-devel/200811/msg00006.html> dontUseCopy needs to be fixed, but specific "disallow" flags could be added to alter per-RFC4511 behavior. p.

1 0

(ITS#5786) too many arguments to function slap_get_commit_csn
by michael＠stroeder.com 02 Nov '08

02 Nov '08

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.100.88) HEAD synced, invoked configure after make distclean cd overlays; make -w static make[3]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o syncprov.o syncprov.c syncprov.c: In function syncprov_op_response: syncprov.c:1612: error: too many arguments to function slap_get_commit_csn syncprov.c:1621: error: too many arguments to function slap_get_commit_csn make[3]: *** [syncprov.o] Error 1 make[3]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' make[2]: *** [liboverlays.a] Error 2 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> The "dontUseCopy" control requires criticality to be TRUE. While this is the >> desirable value, > > Why is this a desirable value? The answer Kurt gave on ldap-ext mailing > list just mentioned direct mapping to X.511 dontUseCopy option. Because. If you need to avoid using copy, then you strongly need it. If it's just a wish, then don't use it, assuming the DSA you contact will do no more than what it can to provide you valid data. You would otherwise be misuing the control. >> a DUA could use the control with the criticality set to FALSE. Yes, perfectly legitimate (from a DSA's point of view, as per RFC4511) but contrary to the control's specification (and, IMHO, to common sense). > As I stated on ldap-ext mailing list in this case I'd simply accept a > best effort on the DSA side. IMHO you already get the best effort by not using the control. > So sending "dontUseCopy" control with > criticality FALSE would mean: If the DSA supports this control it should > *process* it according to what's specified in > draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. No. The spec looks broken to me, because it contradicts RFC4511 (from the DSA's point of view). The DUA must use TRUE to comply with dontUseCopy. If it doesn't, then the DSA can do its best to honor it, but nothing more. If the DSA finds out it can chain a request, but this would cost resources, it could return a referral, or simply ignore the control. All of these behaviors would comply with criticality to FALSE. > The main problem is that a DUA cannot determine in advance whether a DSA > supports a certain control for a certain backend. It turned out in > practice that looking a supportedControl in rootDSE does not have any > meaning at all. You got a clear answer: the only ultimate way to know is to try. If you use FALSE, you'll never know. > IMO yet another control does not solve this. It does: you add dontUseCopy with criticality set to TRUE; you add the whatFailed control; if dontUseCopy fails, you'd know for sure. Then you don't need to use it any more, as using it with FALSE would make no sense. >> For full conformance with RFC4511, if the control is syntactically well-formed >> and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST >> ignore it if not recognized, but CANNOT question the fact that the value of >> criticality is violating the control's specification. > > I'm not sure whether this statement can be made generally. I'd wish so > and I'd rephrase "accept it" to "process it". With "accept" I mean: "recognize it"; with "process" I'd mean "apply it to the operation". If you set criticality to FALSE and the DSA does not recognize it, the DSA will just ignore it. If the DSA recognizes it, it is at the DSA's discretion to either apply it or not, based on what the DSA considers best (including interoperability with the specific operation, with other extensions, with resource consumption and any other consideration about the opportunity to process it). I'm pretty sure you agree that elaving so much discretion to the DSA about something related to data integrity does not differ too much from not using the control at all. p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 02 Nov '08

02 Nov '08

Howard Chu a écrit : > > The startup scan is only performed inside the syncprov overlay. If > server C is only a consumer, then it does not need the syncprov overlay. > Yes, you are right for the point 1). Thank you. But I'm also bothered with the point 2) reproduced below : .... 2) If I do only one write operation on B, then I get two contextCSN values, which is normal. But il this case slapd on B scans, at each startup, all objecs written on A after the write operation on B. The log and the effect are similar to those explained above. Best Regards Ali

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 02 Nov '08

02 Nov '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I have a test directory with two mirrors A and B and a replica C connected to > A. > I usaually use server A for write operations. > > I encounter the following problems : > > > 1) If the data base is initiated in stand alone (so serverID defaults to zero) > and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on > C it scans all of the objects writtent on A afterwards, producing the followin > log for each object : The startup scan is only performed inside the syncprov overlay. If server C is only a consumer, then it does not need the syncprov overlay. -- -- 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#5709) slapd sync provider skips some objects
by hyc＠symas.com 02 Nov '08

02 Nov '08

hyc(a)symas.com wrote: > sylvain.thomas(a)gmail.com wrote: >> On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >>> Can you upload these zip attachments to our ftp server or somewhere else >>> with online >>> access please. Then we can test. >>> >> I have uploaded the two files to your ftp server (incoming folder). > > I can confirm that the problem is easily reproducable. Fixed now in HEAD. A couple of bad assumptions from 1.234-1.236... -- -- 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#5785) dontUseCopy in slapd requires criticality to be TRUE
by michael＠stroeder.com 01 Nov '08

01 Nov '08

ando(a)sys-net.it wrote: > > The "dontUseCopy" control requires criticality to be TRUE. While this is the > desirable value, Why is this a desirable value? The answer Kurt gave on ldap-ext mailing list just mentioned direct mapping to X.511 dontUseCopy option. > a DUA could use the control with the criticality set to FALSE. As I stated on ldap-ext mailing list in this case I'd simply accept a best effort on the DSA side. So sending "dontUseCopy" control with criticality FALSE would mean: If the DSA supports this control it should *process* it according to what's specified in draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. The main problem is that a DUA cannot determine in advance whether a DSA supports a certain control for a certain backend. It turned out in practice that looking a supportedControl in rootDSE does not have any meaning at all. IMO yet another control does not solve this. > For full conformance with RFC4511, if the control is syntactically well-formed > and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST > ignore it if not recognized, but CANNOT question the fact that the value of > criticality is violating the control's specification. I'm not sure whether this statement can be made generally. I'd wish so and I'd rephrase "accept it" to "process it". Ciao, Michael.

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 November 2008