>> Rob, I'm afraid I believe that ldap lookup is necessary. The user inputs a >> standard string to represent the possible host group… If i simply perform a >> get_dn it will indeed provide a dn, however, it won't verify that the host >> group actually exists… (you don't want to create an assignment rule for a >> non existent target host group) >> >> >> Martin, (except for the name Clarity), I have addressed your observations in >> this latest patch. Could you please have a look and let me know if there is >> anything else I need to take care of? >> > > Good point about the LDAP lookup. > > This looks a lot better but there are still a few issues: > > If group_dn is in the object then you can use > self.obj.handle_not_found(*keys) for the NotFound.
Ok, I will give that a shot! > > Or if it can't be moved, in the calls to group_dn() you can use the ldap > handle passed into pre_callback. > > I guess you are using the includetype tuple to avoid coding long variable > names everywhere? Would a symbol be better, eg: > > INCLUDE_RE = 'automemberinclusiveregex' > EXCLUDE_RE = 'automemberexclusiveregex' That works, I'll swap em. > Is there a way to validate the regex? Now that you mention it, I believe if I import re, we should be able to validate the initial regex and raise an exception if it is bogus. > If we were to add an equivalent user group handler would it be the same code > in add_condition and remove_condition? It is sort of nice to have everything > together at the moment, I suspect it will need to be generalized at some > point. Well. For the groups, I was thinking it starts to get a little different. I would still reuse the condition, but I believe I would pivot users into groups based upon something like their manager? > Adding a clarity with no rules won't let you add rules: > > # ipa hostgroup-add --desc=hg1 hg1 > # ipa hostgroupclarity-add hg1 > # ipa hostgroupclarity-add-condition > --exclusive-hostname-regex=^web5\.example\.com hg1 > ipa: ERROR: no modifications to be performed This ^ is deliberate, you cannot add an exclusion rule if there is no existing or simultaneous inclusive rule. :) Martin asked for that, and I think its wise. > The way you explained clarity today in IRC, how it brings clarity to managing > membership with names no human can grok, I got it. Still, clarity is a bit > awkward as a name. automember might be a better choice. Fair enough ;) I tried, perhaps I can /allude/ to it in the help / docs. automember it is. One final class I have been struggling with that I want to add… The object and attribute which defines the 'default group' is the parent of the actual rules… i.e. cn=hostgroup,cn=automember,cn=etc… The ipa cli seems to only want to let me make mods that assume I am specifying a target object on the cli… "ipa hostgroupautomember-default-group=foo <rulename>" <- in this scenario, we don't actually want or need a rule name because its the container above… I have had success making the writes, but the cli syntax just doesn't lend itself to that level of abstraction… Any suggestions? _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel