openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 26 Jun '08

26 Jun '08

On Wed, Jun 25, 2008 at 08:10:56PM +0000, Andrew Findlay wrote: > When 'sortvals members' is in effect, some attribute modify operations produce > bad results. This seems to occur when an operation adds an attribute that sorts > to the end of the list. Having thought about this some more I now think that the problem is to do with read/search rather than add. The last value in the list cannot be matched however it got there. The test data I uploaded with the ITS contains this group entry: dn: cn=tenK,ou=groups,o=test,dc=example,dc=org objectclass: groupOfNames cn: tenK member: uniqueIdentifier=a_000000,dc=example,dc=org member: uniqueIdentifier=a_000001,dc=example,dc=org member: uniqueIdentifier=a_004994,dc=example,dc=org member: uniqueIdentifier=a_004995,dc=example,dc=org member: uniqueIdentifier=a_004996,dc=example,dc=org member: uniqueIdentifier=a_004997,dc=example,dc=org member: uniqueIdentifier=a_004998,dc=example,dc=org member: uniqueIdentifier=a_004999,dc=example,dc=org member: uniqueIdentifier=a_005000,dc=example,dc=org If I do a search for any value except the last one, it succeeds: ./bound-search member=uniqueIdentifier=a_004999,dc=example,dc=org # tenK, groups, test, example.org dn: cn=tenK,ou=groups,o=test,dc=example,dc=org objectClass: groupOfNames cn: tenK member: uniqueIdentifier=a_000000,dc=example,dc=org member: uniqueIdentifier=a_000001,dc=example,dc=org member: uniqueIdentifier=a_004994,dc=example,dc=org member: uniqueIdentifier=a_004995,dc=example,dc=org member: uniqueIdentifier=a_004996,dc=example,dc=org member: uniqueIdentifier=a_004997,dc=example,dc=org member: uniqueIdentifier=a_004998,dc=example,dc=org member: uniqueIdentifier=a_004999,dc=example,dc=org member: uniqueIdentifier=a_005000,dc=example,dc=org # search result search: 2 result: 0 Success ./bound-search member=uniqueIdentifier=a_005000,dc=example,dc=org ... this does not find anything This explains why the add and modify operations failed in such an odd way. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 25 Jun '08

25 Jun '08

Hi, On Tue, Jun 24, 2008 at 3:37 PM, <unix.gurus(a)gmail.com> wrote: > On Tue, Jun 24, 2008 at 12:50 PM, <unix.gurus(a)gmail.com> wrote: >> Hi, >> >> I have uploaded a patch against HEAD that normalizes the attributes >> used under cn=monitor according to the schema: >> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch > > Unified diff of the same thing: > sean-burford-monitor-normalize-unified-080624.patch > > The search (namingContexts:distinguishedNameMatch:=CN=...) returns the > expected results, I'll check what filterentry.c:test_mra_filter() is > up to later. As far as I can tell the arguments passed to filterentry.c:test_mra_filter() for that search also look sane, so whilst it passes my tests I'm looking forward to an official opinion on this patch. > make test also completes successfully, for what it's worth. -- Thanks, Sean Burford

1 0

(ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 25 Jun '08

25 Jun '08

Full_Name: Andrew Findlay Version: 2.4.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz Submission from: (NULL) (88.97.25.132) When 'sortvals members' is in effect, some attribute modify operations produce bad results. This seems to occur when an operation adds an attribute that sorts to the end of the list. The attached tarball contains a cut-down config and dataset, along with a set of scripts and LDIF files that demonstrate the bug. To create the problem: (This does NOT need to run as root) edit vars to set appropriate PATH # First version of problem - single LDAP op removes one member and adds another: rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif ./update-dsa mess-tenk.ldif ./update-dsa unmess-tenk.ldif The first update is OK, but the second fails thus: modifying entry "cn=tenK,ou=groups,o=test,dc=example,dc=org" ldap_modify: No such attribute (16) additional info: modify/delete: member: no such value If 'sortvals member' is not set in slapd.conf.test you can just alternate those two LDIFs forever. Check data with: ./bound-search cn=tenk Now compare with the same process using change-tenk.ldif and change-tenk-back.ldif - they do the same job but with a value that sorts earlier, and they work OK. # Second version - repeat adding of single value: ./stop-slapd rm -r openldap-db mkdir openldap-db ./start-slapd ./load-dsa data.ldif ./update-dsa add-member.ldif ./update-dsa add-member.ldif ./update-dsa add-member.ldif First update OK. Second update OK but should not be. Third fails is it should. Check data with: ./bound-search cn=tenk

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 25 Jun '08

25 Jun '08

Michael Ströder wrote: > Kurt Zeilenga wrote: >> >> On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: >>> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of >>> URIs a >>> proxy is serving; can be modified run-time' SUP managedInfo ) >> >> THe fact that this element is published with a .666 OID is a bug. >> .666 are intended for experiments and should never be published. > > Sorry, could have been in my build because of -DDEVEL. Built without -DDEVEL and this schema element is still there but not 'managedInfo'. > P.S.: Frankly I see no problem with publishing a .666 OID. Personally I'd prefer to see interims schema elements in the subschema subentry over seeing no schema declaration for existing attributes. Ciao, Michael.

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by ando＠sys-net.it 25 Jun '08

25 Jun '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> I suspect something like: if back-monitor and/or back-ldap are built as >>> modules, and loaded in the wrong order (back-ldap first, back_monitor >>> then), 'olmDbURIList' is likely to be registered __before__ >>> 'managedInfo'. >> So, a manpage fix something like this? >> >> If monitor is a dynamically loaded module, it should be "moduleload"ed >> before any modules it wants to monitor. A dynamically loaded monitor >> may be unable to monitor a statically built module. > > Not necessary. The order of moduleloads is irrelevant. > > back-monitor initializes its schema as soon as the module is loaded. All of > the other backends initialize their monitor schema when a backend is first > instantiated. The problem you're talking about here doesn't exist. well, all modules do. So if a module needs to register schema dependent on another module that's not loaded yet, it should either fail or, if that piece of schema is to be considered optional, just complain it couldn't do all the job. So it seems pertinent: if you load modules in the "wrong" order, you could miss monitoring functionalities. I note that back-bdb actually tries to register the schema all times a database is instantiated, unless already done. In any case, if the back_monitor module is loaded __after__ the server is already running, existing databases will not gain monitoring capabilities; only subsequent ones will. I don't consider this necessarily a bug (it could be worked out by explicitly setting "monitoring" to "on" after loading the back_monitor module, provided some backend-specific hook is invoked). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 24 Jun '08

24 Jun '08

Kurt Zeilenga wrote: > > On Jun 23, 2008, at 4:58 PM, michael(a)stroeder.com wrote: >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of >> URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > THe fact that this element is published with a .666 OID is a bug. .666 > are intended for experiments and should never be published. Sorry, could have been in my build because of -DDEVEL. Nevertheless I'd appreciate if the schema elements of back-monitor are published in subschema subentry. Ciao, Michael. P.S.: Frankly I see no problem with publishing a .666 OID.

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by michael＠stroeder.com 24 Jun '08

24 Jun '08

Hallvard B Furuseth wrote: > michael(a)stroeder.com writes: >> The following attribute type declaration references 'managedInfo' >> which is not declared: >> >> ( 1.3.6.1.4.1.4203.666.1.55.0.1.2.1 NAME 'olmDbURIList' DESC 'List of URIs a >> proxy is serving; can be modified run-time' SUP managedInfo ) > > Please mention where the code is which you refer to. > > Anyway, this is in back-ldap/monitor.c and managedInfo *is* declared - > in back-monitor/init.c. Have you observed a failure, e.g. with > back-ldap and ./configure --disable-monitor? I'm simply looking an cn=monitor of RE24. I probably have to rephrase that: The schema elements of back-monitor seems not to be available in the subschema subentry. Ciao, Michael.

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 24 Jun '08

24 Jun '08

On Tue, Jun 24, 2008 at 12:50 PM, <unix.gurus(a)gmail.com> wrote: > Hi, > > I have uploaded a patch against HEAD that normalizes the attributes > used under cn=monitor according to the schema: > ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch Unified diff of the same thing: sean-burford-monitor-normalize-unified-080624.patch The search (namingContexts:distinguishedNameMatch:=CN=...) returns the expected results, I'll check what filterentry.c:test_mra_filter() is up to later. make test also completes successfully, for what it's worth. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 24 Jun '08

24 Jun '08

Hi, I have uploaded a patch against HEAD that normalizes the attributes used under cn=monitor according to the schema: ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-080624.patch I picked cn=monitor for the first upload since it can be modified without having to reimport databases. Once we've worked through any issues with this patch I'll seperate out the rest of the normalization patches and send those in. namingContexts was the trickiest, since RFC 4512 defines it without an equality matching rule but monitor_back_register_database() compares it with backend suffixes. It has to deal with capitalised values properly otherwise we end up with duplicate namingContexts entries, so normalization is required. The relevant part of the diff is below. I am open to suggestions about how this should be dealt with: + struct berval nContext; + + for ( j = 0; !BER_BVISNULL( &a->a_vals[ j ] ); j++ ) { + /* FIXME: namingContexts has no equality rule + * but it needs to be normalized for this + * comparison. Using si_ad_distinguishedName + * instead of si_ad_namingContexts results + * in the normalization we expect for now. + */ + if ( attr_normalize_one( slap_schema.si_ad_distinguishedName, + &a->a_vals[ j ], + &nContext, + NULL ) ) { + Debug( LDAP_DEBUG_ANY, + "monitor_subsys_database_init: " + "unable to normalize DN %d \"%s\"\n", + j, a->a_vals[ j ], 0 ); + return( -1 ); + } for ( k = 0; !BER_BVISNULL( &be->be_nsuffix[ k ] ); k++ ) { ! if ( dn_match( &nContext, &be->be_nsuffix[ k ] ) ) { rc = 0; goto done; } } + free( nContext.bv_val ); The attribute types that are modified and the attributes that are affected are listed below. cn=Monitor didn't need and schema modifications: monitorContext: removed nvals namingContexts: removed nvals rootDSE monitorContext and namingContexts monitorCounter: removed nvals cn=Max File Descriptors cn=Total,cn=Connections cn=Current,cn=Connections cn=Read under rww DN counter under sent monitorConnectionProtocol: removed nvals monitorConnectionMask: normalized monitorConnectionListener: normalized monitorConnectionPeerDomain: normalized monitorConnectionPeerAddress: normalized monitorConnectionLocalAddress: normalized monitorConnectionStartTime: normalized monitorConnectionActivityTime: normalized monitorOpInitiated: removed nvals monitorOpCompleted: removed nvals readOnly: removed nvals -- Thanks, Sean Burford

1 0

Re: (ITS#5576) Missing attribute type 'managedInfo' referenced with SUP
by hyc＠symas.com 24 Jun '08

24 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I suspect something like: if back-monitor and/or back-ldap are built as >> modules, and loaded in the wrong order (back-ldap first, back_monitor >> then), 'olmDbURIList' is likely to be registered __before__ >> 'managedInfo'. > > So, a manpage fix something like this? > > If monitor is a dynamically loaded module, it should be "moduleload"ed > before any modules it wants to monitor. A dynamically loaded monitor > may be unable to monitor a statically built module. Not necessary. The order of moduleloads is irrelevant. back-monitor initializes its schema as soon as the module is loaded. All of the other backends initialize their monitor schema when a backend is first instantiated. The problem you're talking about here doesn't exist. -- -- 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

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