RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com
>
> > >
> > > 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
9 years, 9 months
Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by masarati＠aero.polimi.it
> 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.
9 years, 9 months
(ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com
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?)
9 years, 9 months
Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by masarati＠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.
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
>
>
>
9 years, 9 months
Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de
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.
9 years, 9 months
Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by quanah＠zimbra.com
--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
9 years, 9 months
(ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de
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.
9 years, 9 months
RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com
> >
> > 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
9 years, 9 months
Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by masarati＠aero.polimi.it
> 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.
>
>
9 years, 9 months