On 04/11/2011 02:32 PM, Nathan Kinder wrote: > 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 > ------------------------------------------------------------------------------------------------- > >
Or you can go the other way around and eliminate the top level entry: dn: cn=www 5,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: exclude www5 from being added to webservers autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberGroupingAttr: member:dn autoMemberRegexType: exclusive autoMemberRegexAttr: fqdn autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberRegex: ^www5\.example\.com If you need to express the default entry you can say dn: cn=default,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: default catch all rule for Hosts autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberGroupingAttr: member:dn autoMemberRegexType: default autoMemberTargetGroup: cn=orpahns,cn=hostgroups,dc=example,dc=com Then you read all the entries, sort them buy "exclusive, inclusive, default" and handle accordingly. That will create a little bit more duplication of data but will be readable and manageable in a raw form. > -NGK >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> freeipa-us...@redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> >> >> _______________________________________________ >> 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 > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel