Simo Sorce wrote:
On Thu, 2013-02-14 at 09:47 -0500, Rob Crittenden wrote:
John Dennis wrote:
On 02/14/2013 09:05 AM, Simo Sorce wrote:
So as I proposed we can call ipa user-add from LDAP from a
non-transactional pre-op plugin. We just need to be careful about when
we allow that to avoid loops, but besides that problem it seem
relatively easy and does not require crazy things like playgrounds or
even full LDAP proxies.
I think I need a clarification because perhaps I didn't fully understand
your proposal.
Is the idea with a non-transactional pre-op plugin it invokes user-add
and then the pre-op returns *without* having modified ldap? In effect it
acts as a trigger?
That still implies there has to be a separate tree where the foreign
entity writes (and the pre-op plugin watches) because otherwise how
could the pre-op plugin distinguish between framework writes and foreign
writes?
The proposal is that we write a 389-ds plugin that intercepts LDAP ADD
operations. I don't think Simo proposed where in the tree this would be
written, or whether we would be able to distinguish between a normal ADD
and this special case (loop 1).
I did, please see my other emails in the thread.
For the purposes of modification you probably want it to write into the
current user container. It will need to be able to push MOD requests for
names, addresses, etc. Most LDAP apps take a single basedn against which
to do things. We can't expect to be able to provide one set for adds and
one set for mods.
We do not intercept mods, period.
The only *real* issue is creating users, because the framework adds a
lot of stuff to properly format users, but modifications from LDAP
clients is fair game.
We are in agreement here. My point is that if we try to write to a
special part of the tree then move the entry then MODS will always fail.
We cannot consider the framework as the only gatekeeper beyond object
creation, if this is not clear we need to discuss.
That was actually the point of the framework from the beginning.
And of course this leads into deletes. We want users gone when they
leave the company. Feature creep already.
Do we do anything special in the framework for user deletes now ?
I am not aware of any special ops, and I would be against making a
delete operation a special operation.
Any operation can have a pre/post operation. One RFE we have is to add
triggers so that shell scripts (or whatever) can be executed at times.
This is is the sort of thing that would be missed.
> If there is a separate tree where is the looping issue? You still
haven't explained this.
The looping is in telling whether the add is from the external HR source
or a "normal" ADD from IPA. If we get it wrong, ever, then it will ADD,
then call ipa user-add, ADD, call ipa user-add, ADD, ...
Yes, this is the only concern, I made one proposal to avoid the issue,
there are also other ways, for example the framework could use a special
control to tell our server 'I am the framework, do not loop'. We just
need to decide what's the best way to do it.
Right. I don't know enough about how much flexibility these external
systems have when creating LDAP objects so they may not be able to add
additional objectclasses. A control may be the way to go.
For example we already need to avoid any interference with replication,
but that is easy to do, as we know if an operation is coming via
replication. The other is winsync, but I would argue that winsync maybe
should actually use this plugin as it would make it more consistent with
the framework.
Yes, if we could solve this without too much performance issues that
should work.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
