On Tue, 10 Mar 2015, Simo Sorce wrote:
On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote:
On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
> On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Simo Sorce wrote:
...
>>> For some tasks 'local' is the only thing that makes sense (your
>>> morning alarm clock), for other things 'UTC' is the only thing
>>> that make sense (coordinated changes across multiple distributed
>>> data centers).
>>>
>>> Implementing just one or the other is not useful.
>> Correct. At this point I think we are more or less in agreement that
>> we need to store time rules in UTC plus timezone correction
>> information specific to the execution context (HBAC rule, host,
>> etc). Handling 'UTC' rule is equivalent to selecting specific
>> timezone (GMT+0, for example) so this is a case of more general (UTC
>> time, timezone definiton) pairs.
>>
>> This timezone definition may have aliases forcing HBAC intepretation
>> to use local machine defaults if needed but the general scheme stays
>> the same.
>
> Agreed.
Alexander, can you please elaborate a bit more on the idea of storing the time
rules in UTC + timezone correction? I thought SSSD would take take the time
zone information from the local system.
The purpose is that admin can create rule like "Joe can interactively log in
from 8:00 to 17:00 on all machines across the globe". You cannot store the time
zone with such rule as the rule spans across several many different time zones.
Right?
Yes this is a rule expressed in "Local Time" which is a time-zone-less
rule.
Yep, and timezone info for this rule is "Local Time" which is a timezone
that doesn't exist in Olson database and would be interpreted by SSSD
as "default server timezone".
--
/ Alexander Bokovoy
--
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
