On Mon, 09 Mar 2015, Simo Sorce wrote:
On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote:
On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
>On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
>> > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
>> > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
>> > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
>> > > ...
>> > > > One of bigger issues we had was lack of versatile ical format
>> > > > parser to handle calendar-like specification of events -- we
>> > > > need to allow importing these ones instead of inventing our
>> > > > own.
>> > >
>> > > Good point. I wonder how rigorous we want to be. iCal is a
>> > > pretty powerful
>> > > calendaring format. If we want to implement full support for it,
>> > > it would be
>> > > lot of code both on server side for setting it and on client
>> > > side for evaluating it (CCing Jakub for reference).
>> > >
>> > > AD itself has much simpler UI for setting the access time, a
>> > > table like that:
>> > >
>> > >
>> > > IIRC, they only store the bits of "can login/cannot login" for
>> > > the time slots.
>> > > That's another alternative.
>> > I don't think that's what Alexander meant, I don't think the
>> > client library should come anywhere close to the iCal format. We
>> > might want to provide a script to convert an external format, but
>> > that's about it.
>> > I thought we could simply reuse parts of the previous grammar,
>> > maybe simplified. But I agree with Nathaniel (as I stated also in
>> > the private thread) that we should use UTC where possible.
>> Yes and no. Let me go in details a bit.
>> We need iCal support to allow importing events created by external
>> tools. We don't need to use it as internal format.
>> However, there are quite a lot of details that can be lost if only
>> UTC would be in use for a date as you are ignoring a timezone
>> information completely. Timezone information needs to be kept when
>> importing and not always could be reliably represented in UTC so
>> that conversion from one timezone to another could present quite a
>> See http://www.w3.org/TR/timezone/for some of recommendations.
>I'm fine with a plan like this. I just want the admin to opt-in to
>timezones. Localtime *by default* is fraught with pitfalls. If the
>admin needs local time policy, he should specify it exactly and should
>confirm the local time on affected systems.
Yep. We need to make it easy -- probably by allowing to define timezones
as part of host object (like Martin proposed) and overridden in HBAC
service/service group. And all this have to be very visual in the UI.
Another problem is how to deal with missing timezone information at the
place where HBAC rule with time rules would need to be applied. We need
to define the way we handle all these (unavailable, non-parsable and
other kinds of errors) timezone info issues.
I would rather punt, than do some crappy thing ala Windows.
Local Only or UTC only is always wrong.
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
/ Alexander Bokovoy
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code