[SSSD] [PATCH] Add callback when the ID provider switches from offline to online
Stephen Gallagher
sgallagh at redhat.com
Wed Apr 28 14:45:28 UTC 2010
Completely rewritten design attached.
On 04/28/2010 07:57 AM, Stephen Gallagher wrote:
> On 04/28/2010 06:04 AM, Sumit Bose wrote:
>> On Tue, Apr 27, 2010 at 03:37:02PM -0400, Stephen Gallagher wrote:
>>> Allow backends to set a callback in the be_ctx that should be
>>> invoked when the ID provider goes online.
>>>
>>> This can be used to perform regular maintenance tasks that are
>>> valid only when going online.
>>>
>>> Specifically, we can use this to perform a deferred kinit on behalf
>>> of the user when we go online. We can also use this to trigger a
>>> dynamic DNS update for the IPA provider.
>>>
>>> --
>>> Stephen Gallagher
>>> RHCE 804006346421761
>>>
>>> Delivering value year after year.
>>> Red Hat ranks #1 in value among software vendors.
>>> http://www.redhat.com/promo/vendor/
>>
>>> }
>>>
>>> + /* Reconnection succeeded
>>> + * Run any post-connection routines
>>> + */
>>> + if (state->be->online_cb_list) {
>>> + DLIST_FOR_EACH(callback, state->be->online_cb_list) {
>>> + ret = callback->cb(callback->pvt);
>>> + if (ret != EOK) {
>>> + DEBUG(0, ("Post-connection callback returned [%d][%s]",
>>> + ret, strerror(ret)));
>>> + tevent_req_error(req, ret);
>>> + break;
>>> + }
>>> + }
>>> + }
>>> +
>>
>> I have several comments here:
>> - I would suggest to move this loop into a separate subroutine like
>> be_run_online_cb()
>
> Yeah, that would make sense. Then we could expose that routine.
>
>> - Maybe it would make sense to call the callbacks with a timer event to
>> make sure that they do not block the current request or other
>> callbacks
>
> I was going back and forth on this. As you said, the risk is that it
> could cause a block. So I think I'll do as you suggest and make it a
> stepped series of timer events. The catch is that return values from the
> callbacks won't affect the request they're attached to.
>
>> - Currently the callbacks are run on every reconnect which might be
>> intended, but is IMO different from running after the transition from
>> offline to online. E.g. with GSSAPI we need to reconnect if the ticket
>> becomes invalid although we haven't been offline. To catch only the
>> offline-online transition I would suggest to add a run_online_cb flag
>> which is set by be_mark_offline() and checked and unset by the
>> proposed be_run_online_cb().
>
> Good idea, I didn't think of that. I also wasn't thinking of the GSSAPI
> case. Doing it this way would also allow me to make these callbacks
> available to the proxy provider.
>
> If the callbacks should be run after
>> every successful connection it would be better to replace
>> '*online_cb*' by something like '*connect_cb*'.
>> - Is it intended that only the id provider is running the callbacks?
>>
>
> This was mostly an optimization. The ID provider must be online for any
> of the other providers to actually work (since they will all verify the
> user before proceeding). So it's not actually possible in our current
> design for anything but the ID provider to cause the transition from
> offline to online operation. (Obviously the reverse transition can occur
> in any of them)
>
>
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-callback-when-the-ID-provider-switches-from-offl.patch
Type: text/x-patch
Size: 8719 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20100428/8e8dbb1b/attachment.bin>
More information about the sssd-devel
mailing list