Dmitri Pal wrote:
On 02/21/2011 08:52 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Mon, 21 Feb 2011 11:56:39 +0100
Jakub Hrozek<jhro...@redhat.com> wrote:
On Sat, Feb 19, 2011 at 11:47:45PM -0500, Rob Crittenden wrote:
I had to add a couple of short sleep calls to make things work a
little better. The memberof plugin runs as a postop and we have no
way of knowing when it has done its work. If we don't pause we may
show some stale data that memberof hasn't updated yet. .3 seconds is
an arbitrary choice.
I don't know the DS plugin architecture good enough but there's no
callback or anything we can hook to? If the machine swaps or
something, we might get incorrect data with the sleep anyway..
Unfortunately the way plugins are done, post-ops are pretty much
impossible to catch from the outside.
And I really don't like this either.
I would definitely prefer for the reply to the modifying client to wait
until the memberof plugin is done, even if this means the operations
will be slow.
But I don't know if this can be done easily with the current DS
architecture ...
The problem is that we cannot even enter a read loop to wait smaller
amounts of time until we get back the right answer because a competing
client may change the membership while we are waiting and causing us to
loop forever ...
Simo.
This is the same conclusion I came too and decided that a brief sleep
is the lesser of evils.
Can this be fixed by the memberOf plugin?
If the memberOf plugin is modified to also change/set the attribute
there should not be a race condition.
What is the recommendation from Rich and Nathan?
I am fine with the temp fix but should we have a ticket to fix it in a
better way in 2.1?
This is a race condition only in that we're racing against the memberOf
plugin.
Take the case of a group the a member user:
If you remove the member attribute from the group then immediately do an
ldap search for ("member=cn=group,...") you may very well get the user
if the memberOf operation isn't completed yet.
In this case it makes the user look like an indirect member of the group
(because they are no long in the group's member attribute).
I talked to Nathan about this on Friday. memberOf runs as a postop so
only runs once the modification results have been sent. So from the IPA
perspective the work is complete and we move along. We don't get any
sort of ID that we can query on to see if memberOf is done, and at the
point of our operation we have no idea what scope of work memberOf has
to do, it could be extensive (think about a group of 1000 users and you
delete the group, it has to remove memberOf from all those 1000 users).
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
