Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):
On 3/23/2015 10:10 AM, Jan Cholasta wrote:
Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):
...

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).

Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays)
should be stored with user objects (but not in group objects, as users
can be members of multiple groups, which could cause conflicts). When
a user goes on a bussiness trip etc., an administrator/manager would
need to change their location accordingly to reflect that.

For hosts, timezone information is already available on the host
(/etc/localtime). I'm not sure if there is a 1-1 mapping between
timezone and holidays, but if there is not, we probably need to store
location with host objects as well. If we do that, maybe we can make
SSSD update local timezone on the host using the information stored
with the host object to allow roaming (think user laptops).

I'm not sure about storing the holiday information with any objects.
Holidays are a good example for exceptions in time rules but I'm not
sure that this information should be really stored with each user/host.
There might be cases where you want the holidays to apply and then
sometimes you may not want them to apply. Storing time exceptions with
the specific HBAC rules would solve that, I think.

I'm not saying we should store them directly with any object, but rather store a reference to an object defining them, so that you don't have to define them over and over again when you need to use them in multiple places.

It might be a good idea to store optional owner information with
hosts, so that when the owner moves to a different location, the host
is assumed to be at that location as well (again think user laptops).

Given the above, HBAC rules could contain (time, anchor), where anchor
is "UTC", "user local time" or "host local time".
Truth is, it was not really clear to me from the last week's discussion
whose "Local Time" to use - do we use host's or do we use user's?  It
would make sense to me to use the user's local time. But then you would
need to really store at least the timezone information with each user
object. And that information should probably change with user moving
between different timezones. That's quite a pickle I am in right here.

IMO whether to use user or host local time depends on organization local policy, hence my suggestion to support both.

Yes, timezone would need to be stored with the user, and someone or something (not the user, so they can't cheat) would need to change it when the user moves.


What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.
...


Honza


--
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

Reply via email to