>> 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
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…
Freeipa-devel mailing list