-----BEGIN PGP SIGNED MESSAGE-----
On 11/24/2010 11:15 AM, Dmitri Pal wrote:
> Stephen Gallagher wrote:
>> On 11/23/2010 04:32 PM, Simo Sorce wrote:
>>> On Tue, 23 Nov 2010 16:07:47 -0500
>>> Rob Crittenden <rcrit...@redhat.com> wrote:
>>>> I don't want to throw a wrench in, but what if you have multiple
>>>> replicas in various distant locations, WHICH server is the time
>>>> relative to?
>>> By server I think Steve meant the machine currently evaluation the
>>> access control decision. "Host" would have been a happier term.
>> No, I was actually talking about the FreeIPA server in this situation,
>> but Rob is right that there is no guarantee in a multi-master situation
>> that the servers themselves are in the same timezone.
>> Given this, I think the only sane thing to do here is to always use UTC
>> (and state clearly that this is what is happening)
> I was always saying that the time should be in the UTC only when it is
> evaluated on the server . I do not think that "local" is a good solution.
> But I think the whole idea with the timezones have been misinterpreted
> so let me try to explain one more time.
> He is the workflow that I have in mind:
> 1) Admin creates a rule with time definition using UI and CLI
> 2) Rule is saved in the LDAP attribute
> 3) Rule gets replicated between IPA servers
> 4) SSSD fetches the rule from an IPA server
> 5) SSSD validates the rule
> Let us say that the rule is entered, saved, transfered and interpreted
> on the client as UTC. Sounds reasonable and not that complex from the
> implementation POW. Good!
> The only issue I see is that the admin during step 1 does not think in
> terms of UTC as Ben pointed out. He thinks in user time or server time
> i.e. tries to relate the rule to some reasonable time markers (start of
> a shift, end of a working day, midnight at a special location etc.)
> So I was suggesting the following:
> 1) Allow admin to specify in what time zone he entered the time
> 2) Pass the time definition together with the time zone he selected to
> the server
> 3) Before saving the rule the server would convert the rule into UTC and
> stick the TZ info hint into the rule
> 4) When SSSD retrieves the attribute it will know that time is in UTC
> and will ignore any TZ hints stored in the rule
> 5) The TZ hint only need for UI/CLI when admin fetches the rule and
> looks at it. In this case the server will take attribute which is in
> UTC, extract a TZ hint from the rule and use that TZ to convert UTC
> value it has to the value in the specified TZ. This is what is sent to
> the client and displayed in the UI/CLI.
> So TZ is needed only for the administrative purposes and not for SSSD. I
> hope it is clear now.
> I was also suggesting to save offset together with the TZ hint but I
> guess this can be dropped.
> Can we agree to keep the TZ as hint for the management purposes in the rule?
Dmitri, this simply cannot work, because time zones are not static. You
can't tell the administrator he is defining something in the Eastern
time zone from 09:00-17:00 EST and then store that value as UTC. Because
when DST happens, suddenly this will be equivalent to 08:00-16:00 EDT.
And the meaning of the rule is lost.
So if you want to define a timezone for a rule, it MUST be stored as
local time plus timezone identifier, so that when it is evaluated it
will use the appropriate offset for that moment in history.
You can't just send a UTC value down to SSSD.
After lunch, I'm going to write up the completely new proposal that Adam
and I are suggesting to avoid the future upgrade issue for SSSD as well.
It will account for the problem you're trying to solve here.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Freeipa-devel mailing list