On 09/11/2012 10:51 AM, Martin Kosek wrote:
On 09/04/2012 04:40 PM, Rich Megginson wrote:
On 09/03/2012 08:42 AM, Martin Kosek wrote:
On 08/27/2012 06:29 PM, Rich Megginson wrote:
...
This is the plan I plan to take:
1) Add pres,eq indexes for all un-indexed attributes that we want to check:
sourcehost
memberservice
managedby
memberallowcmd
memberdenycmd
ipasudorunas
ipasudorunasgroup
ok
...
Implementation of the Referential Integrity in IPA works OK so far, I just hit
a strange issue when indexing memberallowcmd and memberdenycmd attributes in
IPA:
dirsrv errors log:
...
[11/Sep/2012:11:39:53 -0400] - The attribute [memberdenycmd] does not have a
valid ORDERING matching rule - error 2:s
[11/Sep/2012:11:39:58 -0400] - userRoot: Indexing attribute: memberdenycmd
[11/Sep/2012:11:39:58 -0400] - userRoot: Finished indexing.
...
This cause RI to fail to handle this attribute in IPA (which is expected based
on the error message).
I checked the attributes types, they look like that:
attributetypes: ( 2.16.840.1.113730.3.8.7.1 NAME 'memberAllowCmd' DESC 'Refere
nce to a command or group of commands that are allowed by the rule.' SUP dist
inguishedName 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.7.2 NAME 'memberDenyCmd' DESC 'Referen
ce to a command or group of commands that are denied by the rule.' SUP distin
guishedName EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch S
UBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'I
PA v2' )
"distinguishedNameMatch" ORDERING rule looks wrong, it is only a matching rule.
Anyone knows why it was defined that way? Or what should be a correct setting
for this attribute instead? caseIgnoreOrderingMatch seems as a logical choice...
Not sure. The problem is that, in LDAP, there isn't a concept of
"ordering" or "substring" matching on DN values.
http://www.ietf.org/rfc/rfc4517.txt - there is only
distinguishedNameMatch which is an EQUALITY rule. Do you really need
ordering and substring here? The problem with using some other ordering
or substring matching rule is that it will not properly normalize the DN
valued string, so you may get incorrect results.
I will have to fix the attributeTypes definition in IPA before we can enable
index& RI for them.
Thanks,
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
