On 04/11/2011 10:58 AM, Nathan Kinder wrote:
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-us...@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.
I started writing up some notes to map out how we would represent the
configuration with this split out approach. We would have one top
level config entry per filter/scope. Child entries would be
inclusive/exclusive rule entries. We sould load all child entries as
regex rules, so we don't need pointers to each regex entry in the
top-level entry. Here is an example:
-------------------------------------------------------------------------------------------------
dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberDefinition
autoMemberScope: dc=example,dc=com
autoMemberFilter: objectclass=ipaHost
autoMemberGroupingAttr: member:dn
autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com
dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config
objectclass: autoMemberRegexRule
description: exclude www5 from being added to webservers
autoMemberRegexType: exclusive
autoMemberRegexAttr: fqdn
autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
autoMemberRegex: ^www5\.example\.com
dn: cn=www hosts,cn=Hostgroups,cn=Auto Membership
Plugin,cn=plugins,cn=config
objectclass: autoMemberRegexRule
description: include www hosts in webservers
autoMemberRegexType: inclusive
autoMemberRegexAttr: fqdn
autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
autoMemberRegex: ^www[1-9]+\.example\.com
dn: cn=web hosts,cn=Hostgroups,cn=Auto Membership
Plugin,cn=plugins,cn=config
objectclass: autoMemberRegexRule
description: include web hosts in webservers
autoMemberRegexType: inclusive
autoMemberRegexAttr: fqdn
autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com
autoMemberRegex: ^web[1-9]+\.example\.com
dn: cn=mail hosts,cn=Hostgroups,cn=Auto Membership
Plugin,cn=plugins,cn=config
objectclass: autoMemberRegexRule
description: include mail hosts in mailservers
autoMemberRegexType: inclusive
autoMemberRegexAttr: fqdn
autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com
autoMemberRegex: ^mail[1-9]+\.example\.com
-------------------------------------------------------------------------------------------------
What I don't like about this approach is that the first 3 regex rules
really belong together, as they all have to do with webservers. It
makes sense to split out the mail hosts regex since it is logically
different. If you have the case where your hosts have hostnames that
don't follow any sort of format, you may end up having many inclusive
rule entries for all of your different webservers. I see that as
being a headache in many cases. Keep in mind that the above is a very
simple example. You would likely have many more entries in an actual
deployment.
To alleviate this problem, we could make the autoMemberRegex attribute
multi-valued, but you would only have one description per regex rule
entry, not per regex. This is more flexible, as administrators could
choose when to group regexes together vs. having them separate. The
only real advantage is to add a description to a group of regex rules
though.
This is all equivalent to the following config with the method
described in the design doc (without the ability to have descriptions):
-------------------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------------------------
