[Freeipa-devel] Time-based account policies

[Simo Sorce]

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:
> >> > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> >> > >
> >> > > 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
> >> problem.
> >>
> >> 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.

-- 
Simo Sorce * Red Hat, Inc * New York