[Freeipa-devel] [PATCH] 22 Add memberHost and memberUser to default indexes

[Rob Crittenden]

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 at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at 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