On Thu, 2016-09-01 at 17:48 +0200, Standa Laznicka wrote:
> If an admin wants the capabilities of time rules then they should just
> upgrade the clients. If that is a problem, it's their choice. They can
> either create a special host group for those clients that just won't 
> upgrade or just revoke access to them if it's a problem of a stubborn 
> user who does not want their system upgraded.

This is a very naive view of the problem. first of all what admins want
and what admins can have *and when* are 2 completely different things.

Admins may *prefer* to enforce time rules but it may not be a deal
breaker if some clients do not follow them. They may be ok to have a
period of time i which this is not a hard rule.

Say they are in the process of migrating 3000 clients from RHEL5.11 to
RHEL7.4, they know the roll out will take 6 months, they want a time
rule established so that in 6 months all clients will allow access only
from 8AM CET to 6PM CET, but they are ok to allow access at all times
until a client is migrated.

Of course they may simply wait and change rules after all clients are
migrated, but maybe their goal in setting rules immediately is that they
can test them to see if their users are negatively impacted immediately
so they deal with issues as they come slowly as one client after the
other is migrated instead of having it all at once on "judgment" day. 

This is just an example scenario but I find it totally reasonable.
Are there other ways to go about it ? Yes, definitely, as mentioned host
groups can be used to control which clients see what. I am just saying
this is not a black and white problem, there are various shades of gray.

> Having a single object would also be wrong - there's no way telling
> the older clients to ignore the objects you want them to ignore if you
> want them not to ignore some.

Yes there is, hostgroups again, you see, it works both ways :-)

> But all and all thank you for the explanation with the example, it
> made some of your previous points more clear.

Sure.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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