openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 07 Jul '11

07 Jul '11

> > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > > specific to back-sql or to interaction with it could receive only marginal > > attention. > > > > p. > > > > I've imported my data into a server with a bdb backend, and I see the same problem. > > Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > code in tavl_find3() looks to me that it only works properly with an exact match > type of matching rule: > > Avlnode * > tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > { > int cmp = -1, dir; > Avlnode *prev = root; > > while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > prev = root; > dir = cmp > 0; > root = avl_child( root, dir ); > } > *ret = cmp; > return root ? root : prev; > } > > since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > I think I've worked out where the problem is. Firstly, there's a comment before tavl_find3() saying /* * tavl_find2 - returns Avlnode instead of data pointer. * tavl_find3 - as above, but returns Avlnode even if no match is found. * also set *ret = last comparison result, or -1 if root == NULL. */ but the "or -1 if root == NULL" is not done. Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than the search node to be returned. Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). There is another bug in send_list() in sssvlv.c, at lines 535-544: if ( i > 0 ) { tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); dir = TAVL_DIR_LEFT; } else { tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); dir = TAVL_DIR_RIGHT; } for (i=0; tmp_node != cur_node; tmp_node = tavl_next( tmp_node, dir ), i++); so->so_vlv_target = i; This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set to an offset from the end of the list, rather than the beginning. Chris

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by masarati＠aero.polimi.it 07 Jul '11

07 Jul '11

> Full_Name: Ondrej Kuznik > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (62.168.56.1) > > > When storing cn=config entries whose rdns use different attributes, they > may be > received in a different order during startup. This will mess with their > "{}" > numbering and since a change like that is not anticipated in the code, it > is > never pushed to the underlying database either. > > This leads to a state when the cn=config database and underlying on-disk > representation are out of sync, making modification (and maybe deletion) > of the > affected entries impossible. > > If needed, I can create a minimal overlay showing these symptoms. Please, do. I find this report quite unclear, as I could not understand what the actual issue is. p.

1 0

(ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 07 Jul '11

07 Jul '11

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: Submission from: (NULL) (62.168.56.1) When storing cn=config entries whose rdns use different attributes, they may be received in a different order during startup. This will mess with their "{}" numbering and since a change like that is not anticipated in the code, it is never pushed to the underlying database either. This leads to a state when the cn=config database and underlying on-disk representation are out of sync, making modification (and maybe deletion) of the affected entries impossible. If needed, I can create a minimal overlay showing these symptoms. Not sure what action is appropriate, probably letting back-ldif honor the original ordering fully, but this can break other assumptions already in the configuration code that relied on the "attribute name first, then numbers" ordering. Another thing that comes to my mind is to make the ordering sequences per attribute whatever the value of ce_type. Like this: olcAttr={0}a, olcSomething={0}something, cn=config olcAttr={1}c, olcSomething={0}something, cn=config olcAttr={2}b, olcSomething={0}something, cn=config olcOtherAttr={0}ccc, olcSomething={0}something, cn=config olcOtherAttr={1}csad, olcSomething={0}something, cn=config olcOtherAttr={2}safc, olcSomething={0}something, cn=config olcOtherAttr={3}brt, olcSomething={0}something, cn=config Again, this has other drawbacks (first restart after this is applied changes the cn=config database probably messing with replication?)

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 07 Jul '11

07 Jul '11

Am 07.07.2011 08:21, schrieb masarati(a)aero.polimi.it: > There are clearly two bugs: "count" misses the number (same for "size") > and the prefix "restrict=" is repeated. Fixed in master, please test and > report. Tested. Problem is gone with the provided patch. Thank you. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by masarati＠aero.polimi.it 06 Jul '11

06 Jul '11

There are clearly two bugs: "count" misses the number (same for "size") and the prefix "restrict=" is repeated. Fixed in master, please test and report. p. > --On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > >> Full_Name: Florian Dufner >> Version: 2.4.26 >> OS: SunOS sun 5.10 i86pc >> URL: >> Submission from: (NULL) (91.16.117.246) >> >> >> Conversion to run-time configuration (RTC) does not work with every >> configuration option of slapo-constraint. >> >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it to > see the actual value. > >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. >> >> Problem #2: (restrict parameter) >> constraint_attribute mail regex ^[[:alnum:].-]+@host$ >> restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" >> is converted to >> olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr >> ict="restrict=ldap:///ou=people,dc=host??sub?(obj >> ectClass=posixAccount)" >> >> The complete restrict parameter from the old configuration format >> (including "restrict=") is appended after a "restrict=". >> slapd will not run until this is fixed. >> > > This sounds valid. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > >

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 06 Jul '11

06 Jul '11

Am 07.07.2011 04:12, schrieb Quanah Gibson-Mount: >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it > to see the actual value. Okay, base-64 decoded it is "mail count". But as I wrote: >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. So the problem is that the number after count is not included in conversion. After adding " <number>" slapd will start. Is there a specific mechanism for the decision of what attributes get base64-encoded in conversion? In case of the count type constraint I can't see why it's needed. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by quanah＠zimbra.com 06 Jul '11

06 Jul '11

--On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > Full_Name: Florian Dufner > Version: 2.4.26 > OS: SunOS sun 5.10 i86pc > URL: > Submission from: (NULL) (91.16.117.246) > > > Conversion to run-time configuration (RTC) does not work with every > configuration option of slapo-constraint. > > Problem #1: (count constraints) > constraint_attribute mail count 1 > is converted to > olcConstraintAttribute:: bWFpbCBjb3VudCA= This is base-64 encoded, not garbage. I suggest you base-64 decode it to see the actual value. > The attribute is garbled after conversion. slapd will not run until this > is fixed. > > Problem #2: (restrict parameter) > constraint_attribute mail regex ^[[:alnum:].-]+@host$ > restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" > is converted to > olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr > ict="restrict=ldap:///ou=people,dc=host??sub?(obj > ectClass=posixAccount)" > > The complete restrict parameter from the old configuration format > (including "restrict=") is appended after a "restrict=". > slapd will not run until this is fixed. > This sounds valid. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 05 Jul '11

05 Jul '11

Full_Name: Florian Dufner Version: 2.4.26 OS: SunOS sun 5.10 i86pc URL: Submission from: (NULL) (91.16.117.246) Conversion to run-time configuration (RTC) does not work with every configuration option of slapo-constraint. Problem #1: (count constraints) constraint_attribute mail count 1 is converted to olcConstraintAttribute:: bWFpbCBjb3VudCA= The attribute is garbled after conversion. slapd will not run until this is fixed. Problem #2: (restrict parameter) constraint_attribute mail regex ^[[:alnum:].-]+@host$ restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" is converted to olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr ict="restrict=ldap:///ou=people,dc=host??sub?(obj ectClass=posixAccount)" The complete restrict parameter from the old configuration format (including "restrict=") is appended after a "restrict=". slapd will not run until this is fixed.

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 05 Jul '11

05 Jul '11

> > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > specific to back-sql or to interaction with it could receive only marginal > attention. > > p. > I've imported my data into a server with a bdb backend, and I see the same problem. Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the code in tavl_find3() looks to me that it only works properly with an exact match type of matching rule: Avlnode * tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) { int cmp = -1, dir; Avlnode *prev = root; while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { prev = root; dir = cmp > 0; root = avl_child( root, dir ); } *ret = cmp; return root ? root : prev; } since the while loop terminates when the fcmp function returns 0 (i.e. exact match). Chris

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by masarati＠aero.polimi.it 05 Jul '11

05 Jul '11

> Full_Name: Chris Card > Version: HEAD (on 30 June 2011) > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > I am running slapd built from HEAD on June 30th 2011, with back-sql Can you confirm this issue with another backend, e.g. back-bdb? Bugs specific to back-sql or to interaction with it could receive only marginal attention. p. > backend, and > pcache and sssvlv overlays. > > I am submitting a search request with vlv and sort controls. > > In the sort control I am specifying attributeType cn and orderingRule > caseIgnoreOrderingMatch. > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, > beforeCount > 0 and afterCount 4, I get 5 entries with the following cns returned: > > Dave Smith > Fiona Smith > Glynis Smith > Jane Smith > Jennifer Smith > > If I specify 'g' in greaterThanOrEqual I get: > > Glynis Smith > Jane Smith > Jennifer Smith > Jim Smith > Mark Smith > > But if I specify 'f' I get no entries returned. > >

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