>> 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
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to