Nathan Kinder wrote:
On 03/30/2011 10:19 AM, Dmitri Pal wrote:
On 03/30/2011 12:44 PM, Nathan Kinder wrote:
On 03/30/2011 06:00 AM, Dmitri Pal wrote:
Please find the design for the auto membership plugin:
I had a lengthy discussion with JR, and I have come up with an
alternate approach. I have added this approach to the design
document. I am currently leaning towards this new approach. Please
take a look at it.
I have some comments and questions:
1) Is the AND functionality for inclusion criteria required?
2) How the attributes are escaped? Do they need to? Probably there will
be cases when they should be escaped
3) Parsing pairs in the value as a bit of overhead. I wonder if
any way to avoid it?
4) I have concerns about the UI and CLI, do you see any good ways to
mange such entries?
Great. Unless I hear otherwise, I am going to move forward with this
newer approach and abandon the original approach (and clean it from the
design doc to avoid confusion).
I think this is fine though I'm concerned that some of these entries
could end up being huge.
The alternate design lumps all configuration for a particular object
type into a single entry so a default can be set, which is fine.
But what happens over time as this grows, are these huge entries going
to be unmanageable?
The cli already has a bit of iffy management of multi-valued attributes.
We'd definitely need to add a delattr option so individual elements of a
MV could be removed.
What will the behavior be if there are multiple configurations that
match? Say you have 2 objectclass=posixAccount for adding users to
groups, both with a default. Does the user get added to 2 groups?
If adding membership fails (already a member, for example) is that error
Freeipa-users mailing list