On Wed, May 18, 2016 at 05:13:11PM +0300, Alexander Bokovoy wrote: > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote: > > > On Wed, 18 May 2016, Stanislav Laznicka wrote: > > > > > > when removal succeeds but addition fails for some > > > > > > reason? The operation is not atomic anymore. > > > > > > > > > > > > > > > We offline-discussed this with Honza. There should be a new > > > > command `ipa hbacrule-replace-accesstime rule_name > > > > --orig-time=icalstr1 --new-time=icalstr2`. As it would be > > > > derived from LDAPQuery, the atomicity is kept. This may not be > > > > very nice for CLI but should work well for WebUI. Both icalstr1 > > > > and icalstr2 need to be encoded as newlines that appear so often > > > > in iCalendar strings would only make a mess here. > > > > > > > > Example of use: > > > > > > > > ipa hbacrule-replace-accesstime rule_name > > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" > > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" > > > > > > > > > > > > to add Tuesdays to the timespan defined by the rule. > > > I would really like to see a file input support here. It would be > > > simpler to operate in CLI as you would anyway create vCal files -- no > > > sane person is going to deal with these strings directly on the command > > > line. > > > > > That is correct and some basic file support is already in the patches I > > sent earlier, though replacing rules is not a part of it. However, it > > does not solve the problem as you would still need access to the files > > to work with the attributes and then change the files accordingly. > > > > However, we've had yet another brainstorm with Petr^2, Martin^2 and > > Honza. We really don't want the above so we came up with some ideas that > > I'm listing below. Note that we also do not want more than one VEVENT > > component in any of the time rules. So, the ideas: > > 1) Have the time rules as separate objects. This approach got most > > support here. Adding Simo and Jakub to CC should they have any input > > against this. > > 2) Have the time rules stored as strings in the multi-valued > > accesstime attribute at each rule. These would be referenced by their > > UID property of the VEVENT component of the iCalendar string (instead of > > that pure hell above). As each of the strings can only contain one > > VEVENT which has to define a UID, the only problem would be to keep the > > uniqueness of UIDs consistent. > > > > From my point of view, 1) seems rather better but your experience might > > be different. Don't hesitate to share your opinions, please. > I'm for time rules as separate objects too. Multi-valued accesstime > attributes would not work well because you cannot really address > attributes by UID.
>From SSSD point of view, I'm fine. We download all the HBAC related objects (all that apply to that host) anyway. Just please plan on abstracting the IPA HBAC object from its representation in libipa_hbac. -- 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
