On 09/03/2016 06:25 PM, Jan Pazdziora wrote:
On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:
The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?
You use host groups to serve the old rule to old clients and time-based
rule to new clients. Each client will apply the rule they see.

If you happen to serve the old rule to the new client, access will
be allowed no matter what the other, time-based rule says.

You do not use magic to interpret one rule differently, one way on
one version of client and other way on different client version.

How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
You make sure the new client does not see the old rule.

Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.
I agree that managing separate host group membership might be
and extra work. But it seems to be the only way to remove the ambiguity.

I also believe there's no way avoiding that (if we want to be somehow backward compatible).

I would just love us to come to a consensus as I am growing weary of this discussion and am willing to go with just anything as long as it's somehow OK with most people. Could we therefore decide to go with something, please?

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to