-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztRXkACgkQeiVVYja6o6N4nwCeMQ5Rby7kGQADKbYj0EdEqfzi JDYAnRBS+A3rY/dg7kQVMeEB8CEHIcSr =G3lr -----END PGP SIGNATURE----- _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel