On 02/13/2013 05:27 PM, Simo Sorce wrote:
[...]
I am sorry, but 'cleaner' is really the last word I'd use, 'hack' is
what comes to mind here to be honest.
Then I'm missing something. Thanks for your explanations.
What about small (optional) separate daemon?
One more moving part one additional process, that does very little, it
looks to me as a big hammer to yield.
A) Variant with separate sub-tree
1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com
This has more consequences than you may think.
I do not like the separate field idea because you need to treat it in a
special way. We would probably need special ACIs to anoty allow any
other client to see this subtree otherwise they may see incomplete
objects. Yet we need to allow some user to write to it.
We need to decide case by case which plugins to enable, not all DS
plugins can use filters or exclude subtrees so we may have issues with
some plugins if we do not want them to operate on these special entries
and so on.
Is it possible to use read ACIs of the original tree?
2. watch this sub-tree with persistent search
Persistent search are scarce, and user creation is rare, it would be
over blown, plus it would be a race condition if the daemon dies for
whatever reason.
3. catch new objects and run IPA commands as necessary
With what user identity ?
Keep in mind that one of the reasons we use delegation is to make sure
that ACIs are meaningful *and* auditing reflects the actual user that
did operations.
Thanks. Now your proposal starts making sense to me.
[...]
In both cases rather than core IPA functionality this would be something
external, something the users have to explicitly install and use,
something that doesn't necessarily have to work right with user-supplied
plugins, something limited (say, to users only), and something that'd
always use existing code paths.
I'm really worried about scope creep here; after a few years of adding
features like this IPA would become unmaintainable. Better to have a
focused core and add on top.
This is why I proposed a plugin that is limited to users and calls the
framework so we can use common code.
The *simpler* way would be to simply replicate the core framework login
in the 389ds plugin or even *move* it there.
But we want to keep the logic in the framework as it is more flexible
and easier to work with and extend, so I proposed a 389ds plugin that
just *asks* the framwrok for the data. This keeps the busienss loginc in
the python framewrok, yet it allows an LDAP driver to add users properly
in IPA just using LDAP calls.
The problem is that the framework may do more than LDAP operations. It
supports user-written plugins that can literally do anything.
We'd need to limit what IPA plugins can do, or how they do it, otherwise
it's impossible to just return the result.
So I can see a DS plugin calling IPA, but IPA really has to write the
results itself.
I do not see this as a slippery slope, as it would be limited to user
creation by definition.
I'd be extremely surprised if all of these inflexible external HR
systems happened to limit themselves to user creation.
--
Petr³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
