Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):
On 03/26/2015 02:40 PM, Standa Láznička wrote:
On 3/26/2015 1:24 PM, Martin Kosek wrote:
On 03/26/2015 01:08 PM, Standa Láznička wrote:
On 3/26/2015 11:13 AM, Jan Cholasta wrote:
Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
When using hbactest command you just need to supply implied time zone
as an option to the command itself. After all, you are simulating rule
execution so it does not matter where the value comes from.
Oh, good, I haven't thought of that. That certainly eases things up.
Let me make a summary then, a short one this time, of what's been
discussed .
It seems the best way to store time policies is indeed the format (time,
anchor) where anchor is either Olson database timezone or "Local Time"
for host local time. We are omitting users' local time because, after
all, we are talking HBAC Rules here (great point by Simo). If the admins
really needed that, there's a workaround Jan mentioned that should work
just fine.
What I originally meant as anchor was a value specifying the time offset
(e.g. "utc" - access time uses UTC, "rule" - access time uses time zone
specified in the HBAC rule, "host" - access time uses host's time zone),
rather than the time zone itself or "Local Time".
You're right, that's probably more descriptive than just "Local Time". Still, I
think that instead of "rule" a timezone might just as well appear on the anchor
part. I think "UTC" is also part of Olson's so it should be at the same spot as
the timezone.
Ah, right. OK then.
I am not little confused about all the places where we want to add the time
zone. I thought that it was originally meant for hosts objects, so that we can
HBAC rule is created, UI/CLI can already suggest the right time zone for the
HBAC rule. But it should have been only informative value serving mostly UX,
not something that SSSD would decide on.
HBAC rule itself is always the authoritative source. We should also avoid
having time zone in 2 places in the HBAC rule itself - if this is what you are
steering at. I thought the authoritative time zone would be only in the HBAC
time definition only, i.e. only in the anchor specifically.
I think the timezone still may be with the host object but only as the UI
helper as you suggest. Although I would maybe rather not see it with the object
at all and have the admin just set the right timezone for the HBAC rule
themselves. After all, if there's a collision of host helper timezones, I think
admin would have to do that anyway.
I don't see any point in storing time zone in the host object, if it's
not used for anything meaningful and has to be manually synchronized
with the host's actual configured time zone.
Right. But UI could then offer:
Warning, time zone is ambiguous. Please select the right time zone:
HostA time zone: Europe/Prague [ ]
HostB time zone: Europe/London [ ]
No, thanks. The whole point of "Local Time" is being able to use
whatever time zone is configured on each host instead of having to
specify one time zone for all of them, which is exactly what the above does.
I agree that there should only be one timezone record for each HBAC and I
wouldn't suggest differently. There was a confusion when Jan suggested to use
"rule" as anchor in the (time, anchor) tuple to get the rule's timezone which,
he suggested, should be stored elsewhere but in the tuple. I think there's no
harm having the timezone/"host" keyword stored with this tuple and therefore
nowhere else.
Can we show specific examples of these tuples, to make sure we are in
agreement? My take was:
(Mon-Fri 08:00-17:00, UTC+1)
(Mon-Fri 08:00-17:00, local)
UTC+1 may not be ideal as it would not work for daylight saving, a better way
would indeed be the Olson time zone ID, i.e:
(Mon-Fri 08:00-17:00, Europe/Prague)
(Mon-Fri 08:00-17:00, local)
Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we want to
use Olson's database names. If I understand it right, "UTC" is in Olson's and
stands for UTC+0 offset. If not, we can have "UTC" keyword in the anchor part
of the tuple mentioned above to signalize just that (UTC+0).
Can we please stop using the word "anchor" for time zone, rather than
source of time zone information as I originally suggested?
--
Jan Cholasta
--
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
