Dmitri Pal wrote:
On 04/01/2011 02:06 PM, Rich Megginson wrote:
On 04/01/2011 11:26 AM, Rob Crittenden wrote:
JR Aquino wrote:
On Mar 30, 2011, at 1:16 PM, JR Aquino wrote:

The plugin architecture makes a great deal of calls to search for
memberUser and memberHost. These attributes are missing from the
index and are greatly slowing down the CLI and WebUI.

They should be added as Equality Indexes, as the searches that are
performed are meant for enumeration after the exact value is known.

<freeipa-jraquino-0022-Add-memberHost-and-memberUser-to-default-indexes.patch>_______________________________________________

Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Missed some trailing whitespace.

Corrected patch attached.

After loading this the 389-ds error logs spit out:

[01/Apr/2011:13:26:01 -0400] - The attribute [memberHost] does not
have a valid ORDERING matching rule - error 2:s
[01/Apr/2011:13:26:01 -0400] - The attribute [memberUser] does not
have a valid ORDERING matching rule - error 2:s
Looking at the schema in 60basev2.ldif - it looks as though there are
many attributes that do not have an ORDERING matching rule specified
correctly:
attributeTypes: (2.16.840.1.113730.3.8.3.5 NAME 'memberUser' DESC
'Reference to a principal that performs an action (usually user).' SUP
distinguishedName EQUALITY distinguishedNameMatch ORDERING
distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' )
attributeTypes: (2.16.840.1.113730.3.8.3.7 NAME 'memberHost' DESC
'Reference to a device where the operation takes place (usually
host).' SUP distinguishedName EQUALITY distinguishedNameMatch ORDERING
distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v2' )

1.3.6.1.4.1.1466.115.121.1.12 is DN syntax - there is no ORDERING
matching rule for DN syntax - is there some reason you want to be able
to do range searches on DN values?

I thought that ordering is used for the sorting. If you sort things by
an attribute.
I suspect that there are cases when it makes sense to sort the result
set by DN.
I think HBAC is one of those. But if ordering is not something that
should be used in this case then what shoud?

attributeTypes: (2.16.840.1.113730.3.8.3.8 NAME 'hostCategory' DESC
'Additional classification for hosts' EQUALITY caseIgnoreMatch
ORDERING caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )

This should be ORDERING caseIgnoreOrderingMatch - looks like there may
be more of these too.


This is probably an artifact of me defineing the schema 2 years ago.
Can you please file a BZ and a ticket.
IMO we should fix the schema inconsistencies ASAP.
Please review the rest of the defined attributes and make sure there are
no problems like this.


rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



The IPA schema is more sane now, this patch does the right thing.

ack, pushed to master and ipa-2-0

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to