openldap-bugs September 2010

openldap-bugs@openldap.org

26 participants
109 discussions

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> Please try this (nearly blind) patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > and report through the ITS. Thanks, p. I note that I have messed things up a bit in cleanup; however, this should not affect the testing of the functionality, except if you delete the overlay from the configuration using back-config. If the patch works fine, I'll fix that part. p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> 2010/9/14 <masarati(a)aero.polimi.it>: >>> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.23 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.145.72.122) >>>> >>>> >>>> Hi, >>>> >>>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>>> http://www.ltb-project.org). Overlays are not compiled as modules. >>>> >>>> Overlay sssvlv is compiled, but not activated in configuration >>>> >>>> But: >>>> * SSS and VLV controls are displayed in RootDSE >>>> * SSS control is taken into account if present in an LDAP search >>>> operation >>>> >>>> For example, a search with SSS control on cn (which has no ordering >>>> rule) >>>> gives: >>>> result: 18 Inappropriate matching >>>> text: serverSort control: No ordering rule >>>> >>>> >>>> The error would be normal if overlay has been activated, but I think >>>> control >>>> should be ignored if overlay is not active. >>> >>> I hit this exact same issue just last week - it seems that when the >>> overlay is compiled in, the SSS control is displayed in the rootDSE. >>> >>> In my case, this caused a client to attempt to use the control, then >>> fail with a similar message as above. Without the overlay compiled in, >>> the client just doesn't use the control, and the client's operation >>> suceeded. >>> >>> My point is that I agree this probably shouldn't be activated by >>> default, or at the very least a clear warning added in the >>> documentation= > . >> >> This behavior is common to all overlays that register a general feature, >> like controls, extended ops or even just a bit of custom schema: the >> registration is done when the module is loaded (or at startup, if the >> module is statically built into slapd). =A0As a consequence, the feature >> = > is >> advertised because slapd knows about it, but since it is not explicitly >> configured, does not know how to handle it. >> >> In the end, slapd's behavior is correct: it recognizes the feature, it >> recognizes requests for the feature, but does not know how to handle >> them= > , >> thus returns an appropriate error. =A0This looks pretty consistent with >> RFC4511 and specifications of each feature, although I understand it >> coul= > d >> be disappointing. >> >> Perhaps we could modify this behavior so that the module initialization >> does nothing or so, and only the first instantiation of the feature >> cause= > s >> the real initialization. =A0This was discussed in the past, and I recall >> = > it >> created trouble when part of the initialization was needed earlier (e.g. >> registering schema items that need to be used later in the configuration >> or so; a clear case was back-monitor, which registers schema items that >> are needed by other backends when registering custom monitoring; if >> back-monitor startup didn't occur early enough, one had to instantiate >> it >> before any database that wanted to register custom monitoring). >> >> In conclusion: the current behavior is consistent; on a case by case >> basis, feature instantiation could perhaps be deferred as much as >> possible, unless this conflicts with other features. >> > > I understand your point of view. Indeed, recompiling OpenLDAP without > sssvlv overlay works. > > The fact is that for people compiling OpenLDAP with --enable-overlays, > we have a 'regression' with overlay sssvlv, because LDAP clients are > now using the control and get errors. > > Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client > is using the SSS control in a non-critical mode, OpenLDAP should > return search results (unsorted) even if the control fails (because of > missing ordering rule for requested attribute). If the control is > critical, then the error must be returned. Please try this (nearly blind) patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> and report through the ITS. Thanks, p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 14 Sep '10

14 Sep '10

2010/9/14 <masarati(a)aero.polimi.it>: >> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.23 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.145.72.122) >>> >>> >>> Hi, >>> >>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>> http://www.ltb-project.org). Overlays are not compiled as modules. >>> >>> Overlay sssvlv is compiled, but not activated in configuration >>> >>> But: >>> * SSS and VLV controls are displayed in RootDSE >>> * SSS control is taken into account if present in an LDAP search >>> operation >>> >>> For example, a search with SSS control on cn (which has no ordering >>> rule) >>> gives: >>> result: 18 Inappropriate matching >>> text: serverSort control: No ordering rule >>> >>> >>> The error would be normal if overlay has been activated, but I think >>> control >>> should be ignored if overlay is not active. >> >> I hit this exact same issue just last week - it seems that when the >> overlay is compiled in, the SSS control is displayed in the rootDSE. >> >> In my case, this caused a client to attempt to use the control, then >> fail with a similar message as above. Without the overlay compiled in, >> the client just doesn't use the control, and the client's operation >> suceeded. >> >> My point is that I agree this probably shouldn't be activated by >> default, or at the very least a clear warning added in the documentation= . > > This behavior is common to all overlays that register a general feature, > like controls, extended ops or even just a bit of custom schema: the > registration is done when the module is loaded (or at startup, if the > module is statically built into slapd). =A0As a consequence, the feature = is > advertised because slapd knows about it, but since it is not explicitly > configured, does not know how to handle it. > > In the end, slapd's behavior is correct: it recognizes the feature, it > recognizes requests for the feature, but does not know how to handle them= , > thus returns an appropriate error. =A0This looks pretty consistent with > RFC4511 and specifications of each feature, although I understand it coul= d > be disappointing. > > Perhaps we could modify this behavior so that the module initialization > does nothing or so, and only the first instantiation of the feature cause= s > the real initialization. =A0This was discussed in the past, and I recall = it > created trouble when part of the initialization was needed earlier (e.g. > registering schema items that need to be used later in the configuration > or so; a clear case was back-monitor, which registers schema items that > are needed by other backends when registering custom monitoring; if > back-monitor startup didn't occur early enough, one had to instantiate it > before any database that wanted to register custom monitoring). > > In conclusion: the current behavior is consistent; on a case by case > basis, feature instantiation could perhaps be deferred as much as > possible, unless this conflicts with other features. > I understand your point of view. Indeed, recompiling OpenLDAP without sssvlv overlay works. The fact is that for people compiling OpenLDAP with --enable-overlays, we have a 'regression' with overlay sssvlv, because LDAP clients are now using the control and get errors. Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client is using the SSS control in a non-critical mode, OpenLDAP should return search results (unsorted) even if the control fails (because of missing ordering rule for requested attribute). If the control is critical, then the error must be returned. What is your opinion? Cl=E9ment.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.23 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> >> Hi, >> >> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >> http://www.ltb-project.org). Overlays are not compiled as modules. >> >> Overlay sssvlv is compiled, but not activated in configuration >> >> But: >> * SSS and VLV controls are displayed in RootDSE >> * SSS control is taken into account if present in an LDAP search >> operation >> >> For example, a search with SSS control on cn (which has no ordering >> rule) >> gives: >> result: 18 Inappropriate matching >> text: serverSort control: No ordering rule >> >> >> The error would be normal if overlay has been activated, but I think >> control >> should be ignored if overlay is not active. > > I hit this exact same issue just last week - it seems that when the > overlay is compiled in, the SSS control is displayed in the rootDSE. > > In my case, this caused a client to attempt to use the control, then > fail with a similar message as above. Without the overlay compiled in, > the client just doesn't use the control, and the client's operation > suceeded. > > My point is that I agree this probably shouldn't be activated by > default, or at the very least a clear warning added in the documentation. This behavior is common to all overlays that register a general feature, like controls, extended ops or even just a bit of custom schema: the registration is done when the module is loaded (or at startup, if the module is statically built into slapd). As a consequence, the feature is advertised because slapd knows about it, but since it is not explicitly configured, does not know how to handle it. In the end, slapd's behavior is correct: it recognizes the feature, it recognizes requests for the feature, but does not know how to handle them, thus returns an appropriate error. This looks pretty consistent with RFC4511 and specifications of each feature, although I understand it could be disappointing. Perhaps we could modify this behavior so that the module initialization does nothing or so, and only the first instantiation of the feature causes the real initialization. This was discussed in the past, and I recall it created trouble when part of the initialization was needed earlier (e.g. registering schema items that need to be used later in the configuration or so; a clear case was back-monitor, which registers schema items that are needed by other backends when registering custom monitoring; if back-monitor startup didn't occur early enough, one had to instantiate it before any database that wanted to register custom monitoring). In conclusion: the current behavior is consistent; on a case by case basis, feature instantiation could perhaps be deferred as much as possible, unless this conflicts with other features. p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by jonathan.clarke＠normation.com 14 Sep '10

14 Sep '10

On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.23 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > Hi, > > I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from > http://www.ltb-project.org). Overlays are not compiled as modules. > > Overlay sssvlv is compiled, but not activated in configuration > > But: > * SSS and VLV controls are displayed in RootDSE > * SSS control is taken into account if present in an LDAP search operation > > For example, a search with SSS control on cn (which has no ordering rule) > gives: > result: 18 Inappropriate matching > text: serverSort control: No ordering rule > > > The error would be normal if overlay has been activated, but I think control > should be ignored if overlay is not active. I hit this exact same issue just last week - it seems that when the overlay is compiled in, the SSS control is displayed in the rootDSE. In my case, this caused a client to attempt to use the control, then fail with a similar message as above. Without the overlay compiled in, the client just doesn't use the control, and the client's operation suceeded. My point is that I agree this probably shouldn't be activated by default, or at the very least a clear warning added in the documentation. Jonathan -- ========================================== Jonathan CLARKE ------------------------------------------ Normation 44 rue Cauchy, 94110 Arcueil, France ------------------------------------------ Telephone: +33 (0)1 83 62 26 96 ------------------------------------------ Web: http://www.normation.com/ ==========================================

1 0

(ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 14 Sep '10

14 Sep '10

Full_Name: Clement OUDOT Version: 2.4.23 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hi, I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from http://www.ltb-project.org). Overlays are not compiled as modules. Overlay sssvlv is compiled, but not activated in configuration But: * SSS and VLV controls are displayed in RootDSE * SSS control is taken into account if present in an LDAP search operation For example, a search with SSS control on cn (which has no ordering rule) gives: result: 18 Inappropriate matching text: serverSort control: No ordering rule The error would be normal if overlay has been activated, but I think control should be ignored if overlay is not active.

1 0

(ITS#6489) replication problem - new valuable information, nearly solved
by frank.offermanns＠caseris.de 14 Sep '10

14 Sep '10

Hello, after digging very deep to find out, what the problem could be, I found interesting facts: 1) With our new client-DLL the master/slave replication problem seems to be solved. (our old DLL wrote each attribute separately, our new writes all in a row), but 2) So I switched back to Master/Master in hope that this works also, but I found out the following. - my client-DLL first create a new user entry and then it does a add with all attributes. - at the second master server I activated replication log and saw the following short message (the important part is surounded with ________): "do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20100914081312.596142Z#000000#00 1#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000 syncprov_matchops: skipping original sid 001 slap_graduate_commit_csn: removing 09377b10 20100914081312.596142Z#000000#001#00 0000 syncrepl_entry: rid=001 be_add cn=10008,o=BAD_CLIENT3,ou=users,o=caesar (0) slap_queue_csn: queing 09369668 20100914081312.596142Z#000000#001#000000 syncprov_matchops: skipping original sid 001 slap_graduate_commit_csn: removing 09377b10 20100914081312.596142Z#000000#001#00 0000 do_syncrep2: rid=001 cookie= syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) __________________________________________________________________ dn_callback : new entry is older than ours cn=10008,o=BAD_CLIENT3,ou=users,o=cae sar ours 20100914081312.596142Z#000000#001#000000, new 20100914081312.100780Z#00 0000#001#000000 ___________________________________________________________________ syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=10008,o=BAD_CLIENT3,ou=users,o=caesar syncrepl_entry: rid=001 entry unchanged, ignored (cn=10008,o=BAD_CLIENT3,ou=user s,o=caesar)" Is it a bug, or a result of a bad time synchronization (I only have windows standard time synchronization) But if it would be a time synchronization problem, in recent posts I asked when the time synchronization is important. I got the answer (if understood correctly) that the time synchronization only matters if concurrent write operations are made. So it should'nt be an issue here, since I made my write operations only at one master. Best regards, Frank

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by hyc＠symas.com 12 Sep '10

12 Sep '10

Bill MacAllister wrote: > Howard, > > The patched packages where installed last night on the production OpenLDAP > master with two of the replicas in the failing state. Once the patched > slapd was started the two problem replicas quickly caught up and everything > looks good now. Thanks for the confirmation. I'll commit a final fix to HEAD shortly. > > Thanks again for your help. > > Bill > -- -- 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#6639) syncrepl failing using SASL/GSSAPI
by whm＠stanford.edu 11 Sep '10

11 Sep '10

--On Thursday, September 09, 2010 10:43:06 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: >> >> The problem with the database was only coincidental. Restoring the database >> got the failing replica past the problem replication event. >> >> In the replica pool of 6 servers we have seen the problem on there of the >> servers. In thinking about this more it is unlikely that it is a slave >> problem since the slaves have been in use for about 6 weeks and we did >> not see the problem. Only when we changed the master to 2.4.23 did we >> see the problem. I have captured a master debug log of the problem >> event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. >> >> Bill >> > Please try with this patch: > > Index: sasl.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v > retrieving revision 1.79 > diff -u -r1.79 sasl.c > --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 > +++ sasl.c 10 Sep 2010 05:42:22 -0000 > @@ -733,8 +733,9 @@ > return ret; > } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { > /* partial write? pretend nothing got written */ > - len2 = 0; > p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; > + sock_errset(EAGAIN); > + len2 = -1; > } > > /* return number of bytes encoded, not written, to ensure Howard, The patched packages where installed last night on the production OpenLDAP master with two of the replicas in the failing state. Once the patched slapd was started the two problem replicas quickly caught up and everything looks good now. Thanks again for your help. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 10 Sep '10

10 Sep '10

> I've checked a simple configuration (global instance of chain overlay; > request for non existing entry, resulting in slapd returning the default > referral), and nothing strange appeared (the offending instruction is > executed). The issue might be specific to your configuration. You'll > probably need to post more details. I've checked a "real" case: DNSSRV-located DSAs, one responding and one not. Things seem to work as expected, no cores and valgrind shows no issue. In any case, I have committed a few modifications to HEAD code (plugs a potential leak). Please test and either provide more details about the core or more details about the configuration. p.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2010