Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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) - -- 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/ iEYEARECAAYFAkztJaoACgkQeiVVYja6o6MPPgCglv9EY4OaQk6PaEEXhUIIdFu4 HVQAn1gqQom24AmJ/qMUoxWN/4mr/+M4 =hSe5 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
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? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
Duration New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts? I agree that we don't want to have 24 hours in the UI. DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event. Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 11:26 AM, Dmitri Pal wrote: Duration New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts? I agree that we don't want to have 24 hours in the UI. DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event. Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. I don't want the internal representation to have arbitrary limitations set by the WebUI. It's trivial for the WebUI to be designed to convert hours to days and reverse. So we can store it in DDHHMM format and display it in the WebUI as hours if we really want to. To someone writing a rule by hand, the DDHHMM representation is going to be far more useful. - -- 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/ iEYEARECAAYFAkztQ2EACgkQeiVVYja6o6McjgCfZ7RfnLM+wU4KUqXdKac9PuWE q50An07EzeToJV6YlhStTrBg1mDIkw8s =hO6C -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-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
Re: [Freeipa-devel] Other issues with HBAC calendar
On Wed, 24 Nov 2010 11:26:05 -0500 Dmitri Pal d...@redhat.com wrote: Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. May not be the best but it is perfectly reasonable. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. I think this is not reasonable at all, it is an arbitrary limit due to the current thinking around the UI, if you change mind about the UI tomorrow, you will be left with the constraint in the grammar. This is just backwards. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
Simo Sorce wrote: On Wed, 24 Nov 2010 11:26:05 -0500 Dmitri Pal d...@redhat.com wrote: Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. May not be the best but it is perfectly reasonable. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. I think this is not reasonable at all, it is an arbitrary limit due to the current thinking around the UI, if you change mind about the UI tomorrow, you will be left with the constraint in the grammar. This is just backwards. Simo. Keeping in mind that we have just one shot at it, it is unreasonable to think that the limitations that the UI imposes will ever go away. Effectively what you and Steven say is that the grammar should dictate the UI. It is the wrong approach. As well as the vice versa. The UI should not dictate the grammar. However the grammar also should not have constructs that would never be expressed in UI because they are already identified as unusable. In other words the UI can be subset of what grammar supports but all the options that grammar supports should be potentially implementable in UI and usable. If the they never can be implemented in UI in usable way they should not be in grammar. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
On Wed, 24 Nov 2010 13:12:02 -0500 Dmitri Pal d...@redhat.com wrote: Simo Sorce wrote: On Wed, 24 Nov 2010 11:26:05 -0500 Dmitri Pal d...@redhat.com wrote: Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. May not be the best but it is perfectly reasonable. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices. I think this is not reasonable at all, it is an arbitrary limit due to the current thinking around the UI, if you change mind about the UI tomorrow, you will be left with the constraint in the grammar. This is just backwards. Simo. Keeping in mind that we have just one shot at it, it is unreasonable to think that the limitations that the UI imposes will ever go away. They changed many times since we started and will keep changing in time, I have no doubt about that. Effectively what you and Steven say is that the grammar should dictate the UI. It is the wrong approach. As well as the vice versa. The UI should not dictate the grammar. No, what we say is that the UI is the flexible actor in this dram, the grammar is not flexible. The worst case for the UI is that it may have to display an ugly rule in raw grammar. The worst case for the grammar is that you cannot express a rule, and have to change it. However the grammar also should not have constructs that would never be expressed in UI because they are already identified as unusable. The grammar needs to be flaxible in what can be represented, the UI then can choose to allow only a subset to be set. The UI drives the game, the cases where an admin will try to change something at a low level via direct ldap calls is going to be rare, and in those cases the UI can very well degrade to a less than ideal mode and show raw rules, with the option to wipe them out and let the admin replace them with UI-friendly rules. In other words the UI can be subset of what grammar supports but all the options that grammar supports should be potentially implementable in UI and usable. Everything is potentially implementable. If the they never can be implemented in UI in usable way they should not be in grammar. Given that in the worst case you show a rule by simply describing it in pseudo-natural language I think the UI has no real limits except the limits set forth by the specific implementation. That said I am starting thing that having a grammar that is powerful enough to express all possible combinations an admin can think of is not possible to get done right w/o making it extremely complicated. I need to think a bit more but I think we may want to radically simplify the grammar instead by splitting single rules (as seen in the UI) in multiple values. And use additional attributes to aid the UI, like having a displayTZ attribute that tells the UI what is the preferred timezone to look at a rule. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
I need to think a bit more but I think we may want to radically simplify the grammar instead by splitting single rules (as seen in the UI) in multiple values. And use additional attributes to aid the UI, like having a displayTZ attribute that tells the UI what is the preferred timezone to look at a rule. Simo. It seems that may be we really took a wrong approach here. Let us see what Steve and Adam would come up. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Other issues with HBAC calendar
Hi, During the conversation with Ben and Kyle today over the calendar screen two things came up: 1) Time zone 2) Duration Time zone It makes perfect sense to allow the admin to enter the rule and specify the time zone that the admin used to enter the time. Internally it will be converted to UTC but for the purpose of easier rule creation specifying time zone is helpful. Our grammar right now does not allow saving the zone since we plan to convert time to UTC, however when the value is fetched from the LDAP and presented for editing it is unclear which time zone it was entered in. Also there are two approaches to dealing with time zone information in general. Imagine you have a drop down with time zones. Imagine you entered time and then change the selected time zone in the drop down. Should the time you entered be automatically adjusted? First approach says yes but that means that we will have to implement a complex time recalculator since in corner cases the time difference between the time zones will affect the starting. The second option is to say: the time zone is just a specifier for the whole time rule indicating that the time values were entered in the given time zone. The when you change the value of the time zone you do not recalculate anything. With the right UI structure this can be made more obvious. However when the value fetched from the LDAP and displayed it might be useful to recalculate so I see two options how we can deal with the time zones. a) Do not save the time zone but recalculate the time (and date ???) when you change time zone in the drop down both in add and edit cases. When you fetch and display always use UTC but allow admin to change the timezone view at his will. b) Save time zone in the rule. As Simo pointed the time zone definition change from time to time so it makes sense to actually save offset and timezone as additional hint. This way we can easily convert the time stamp into the specified time zone and back at save and retrieval with no need to implement complex logic in the UI. IMO the second option is simpler but requires yet another change to grammar. I suggest we add offset and time zone as optional fields somewhere at the end of the rule or after start time. Duration New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
