On 16/11/15 13:20, Alexander Bokovoy wrote:
On Mon, 16 Nov 2015, Simo Sorce wrote:
On 16/11/15 06:02, Ludwig Krispenz wrote:
On 11/16/2015 10:32 AM, Martin Kosek wrote:
On 11/13/2015 04:40 PM, Simo Sorce wrote:
On 13/11/15 10:17, Martin Basti wrote:
And in general I am opposed to have a separate object on performance
grounds (for clients) and also on the fact that is becomes tricky to
keep objects in sync.
What exactly is the performance issue there? To download extra entry
Yes because now you have to download rules, parse them, find out what
be downloaded and pull it, or wore just download all time rules
Just for the record, you should be able to pull that in one LDAP
search, when you cast dereference on the HBAC time linking attribute
and pull the settings from time object also.
but then you will have the corresponding internal searches, and the use
of the deref control is not always efficient.
If you want to define general rules like "brno" or "rest of the world"
to reuse rules, why not use CoS and define virtual attributes in the
entry, which would be populated by CoS. The client would have to read
only one entry, the CoS allows flexibility to assign rules to entries
The nice thing about keeping it in the HBAC entry is indeed that we
*ca* use CoS ... or not. We can decided that w/o breaking the schema.
I think we will mostly *not* want to use CoS, but it remains an option.
CoS is partially undesirable because it makes any change to the time
policy an immediate change to all HBAC rules that reference them.
While if times rules are templates, then a change to a time rule can
be tested before applying it to all rules that reference it and you
also have the option to have some HBAC rules break off and go on their
It makes for a potentially more flexible and error forgiving system in
I don't see any contradiction here. You can create CoS configuration
based on the instantiated template entry. That's why I wrote in the
other answer we need to extend our current cosentry_* support a bit.
I wasn't implying any contradiction, I hadn't even read your message yet
when I replied to Ludwig, sorry :-)
Simo Sorce * Red Hat, Inc * New York
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code