On 02/14/2013 12:16 AM, Nathan Kinder wrote:
On 02/13/2013 08:30 PM, John Dennis wrote:
On 02/13/2013 10:40 PM, Nathan Kinder wrote:
With the DS plug-in approach that calls into the IPA framework with a
'mock add' to form the resulting entry at the pre-op stage, we could
take care of the initial ADD operation of the user entry. We would
still need to have a way to trigger the additional write operations that
the IPA framework performs. The proposed DS plug-in could do an
internal search operation after the add, then it could perform the
additional write operations that are needed. This logic would need to
be in the DS plug-in, or we would need another way to get the details
from the IPA framework via JSON. The approach begins to get a bit
messy.
Messy is one word for it :-) Herein lies the problem. user-add is
actually a simple case where in this particular version of our code we
know the LDAP operations that occur and in what order. But there is
nothing in our coding guidelines that guarantees this, it just happens
to be true today. Pre and post callbacks are free to do as they
please. The logic in our ldap module can change (in fact it's
undergoing a rewrite as we speak). We've committed to supporting an
extension mechanism (plugins) that ties into the framework operations
and who knows what might occur in that code. At the moment it's not
used, but hopefully it will be.
Then comes the question, where do we draw the line? Do we say only
user-add with no additional options is supported because we know what
occurs during it's processing and hence we feel safe emulating
user-add outside the framework?
We all know this is a slippery slope, as soon as you support user-add
this way we'll be getting requests to support other commands or other
options. And after we make framework changes (which we do frequently)
are we going to test these out-of-band operations continue to emulate
the ever changing framework?
It's a slippery slope that can expose us to problems we don't need.
Jenny, do you want to test an entirely different mechanism or do you
want to limit it to our defined API?
We have a defined API, I really think that's the only thing we should
support. Backdoor shortcuts that sidestep our framework should be off
the table IMHO, it's just inviting too many problems.
This is why I think that the most sane approach is to put something in
front of 'ipa user-add'. This is not without it's own set of
difficulties, but if we need a basic LDAP interface that can be used to
create IPA users, it should end up calling into the same code that 'ipa
user-add' uses. This would ensure that any extensions (plugins) for the
framework are called.
I actually see this as very similar to the LDAP migration case. For
migration, we basically take entries in LDIF format, extract the
relevant data, then feed it into 'ipa user-add', right? That's more or
less what we need to do here for HR systems that provision users, but
the user addition needs to be pushed to IPA via an LDAP client instead
of IPA pulling from an LDAP server.
Yes, this is exactly what I'm saying and we concur.
--
John Dennis <jden...@redhat.com>
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
