[Freeipa-devel] [Freeipa-users] Auto membership plugin

[Nathan Kinder]

On 04/11/2011 10:25 AM, Dmitri Pal wrote:
> On 04/11/2011 11:27 AM, Nathan Kinder wrote:
>> On 04/08/2011 09:07 AM, Dmitri Pal wrote:
>>> On 04/08/2011 11:49 AM, JR Aquino wrote:
>>>> Is there any way to capture a description associated with the regex
>>>> ->   group mapping?
>>>>
>>>> I was thinking that after time, it would be important to look back
>>>> on rules and know why they were put there.
>>>>
>>>> Particularly in the case of regex, since it may not be completely
>>>> obvious by looking back at alphabet soup.
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>
>>>>
>>> The more I think about current design the more I want to normalize
>>> things.
>>> I would rather instead of:
>>>
>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
>>> objectclass: autoMemberDefinition
>>> autoMemberScope: dc=example,dc=com
>>> autoMemberFilter: objectclass=ipaHost
>>> autoMemberExclusiveRegex:
>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com
>>> autoMemberInclusiveRegex:
>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com
>>> autoMemberInclusiveRegex:
>>> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com
>>> autoMemberInclusiveRegex:
>>> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com
>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
>>> autoMemberGroupingAttr: member:dn
>>>
>>>
>>> Have something like:
>>>
>>> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
>>> objectclass: autoMemberDefinition
>>> objectclass: cnContainer
>>> autoMemberScope: dc=example,dc=com
>>> autoMemberFilter: objectclass=ipaHost
>>> autoMemberRegexRule: cn=Webserver Inclusion
>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
>>> autoMemberRegexRule: cn=Mailserver Inclusion
>>> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
>>> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto
>>> Membership Plugin,cn=plugins,cn=config
>>> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
>>> autoMemberGroupingAttr: member:dn
>>>
>>>
>>> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership
>>> Plugin,cn=plugins,cn=config
>>> objectclass: autoMemberDefinitionRegexRule
>>> cn: Webserver Inclusion Rule
>>> description: Rule contains regular expression to include webserver
>>> hosts into the webserver group.
>>> include: yes<- include or exclude
>>> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
>>> arrtibuteToMath: fgdn
>>> expressionToMatch: ^www[1-9]+\.example\.com
>>>
>>>
>>> Or something along those lines...
>> It's a nice logical layout, but it would be hard for an administrator
>> to figure out what exactly would happen if they were to add a host
>> with a specific hostname.  Since the config is spread over so many
>> entries, one would have to look at the top level config entry to find
>> each rule DN, fetch each rule DN to look at the regexes.  All of the
>> information is so spread out that you can't just look in one place to
>> see the rules that will be used.  This could make things difficult
>> from a troubleshooting perspective.
> This should not be viewed in raw. THe UI and CLi should come to the rescue.
> I am not sure that this is a right approach to mix readability and
> normalization.
> To follow this logic no-one would ever normalize data in any DB due to
> the claim that it would be hard to join tables.
The feature is implemented outside of the UI, and I would like to be 
able to troubleshoot it without the UI without a ton of hassle.  
Ultimately, it is a DS plug-in, and we should be able to troubleshoot it 
easily as a single component instead of requiring the UI to understand 
what it is doing.  We have run into this same issue with things like 
access control since ACI attributes can live anywhere in the database.  
It is for this reason that we have things like the get effective rights 
control for evaluating settings.

If one adds an inclusion rule, but doesn't realize that an exclusion 
rule is overriding it, they could easily get confused.  I understand 
that we want the UI to be able to notice this and present it to the 
user, but there is plenty of room for error in the UI as we add more and 
more logic into it.

I am not totally opposed to this approach, but I want to point out some 
of the downsides in going in this direction.  I usually like to make the 
internal representation of plug-in configuration closely mirror the 
layout of the configuration entries/attributes themselves.  In this 
case, it would be highly inefficient to do so.  Internally to the 
plug-in, we will be representing the config for a specific object type 
as a single struct with a list of all inclusive and exclusive rules.  I 
can convert multiple config entries into this same internal format, but 
it is something I generally like to avoid.

I will look into this approach further.  I have the current approach 
from the design document implemented and working at this point, so some 
surgery will be required to go back to a different configuration 
layout.  Parsing and loading the configuration when it is split across 
so many dependent entries is not going to be trivial.  I can see plenty 
of corner cases in configuration validation cropping up.  Dynamic config 
changes will also be more difficult to handle, as we will have to back 
track to find what config entries reference a modified rule.
>> The description issue is a tough one to deal with if we have the
>> config in the form that is currently described in the design doc.
>> Since we want a description per regex rule, we should need to make the
>> description be a part of the regex rule value instead of a separate
>> description attribute.  I don't necessarily like this approach, as the
>> readability of the config will not be nice.
>>
> I think this tips the scale towards the approach I proposed.
Yes, it does.
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>