[SSSD] Design Discussion: LDAP Referral Chasing

Stephen Gallagher sgallagh at redhat.com
Thu Nov 10 16:26:51 UTC 2011


On Thu, 2011-11-10 at 17:12 +0100, Jakub Hrozek wrote:
> On Tue, Nov 08, 2011 at 11:26:28AM -0500, Stephen Gallagher wrote:
> > I've created the following wiki page with my thoughts on the design of
> > the LDAP referral chasing:
> > https://fedorahosted.org/sssd/wiki/DesignDocs/LDAPReferrals
> > 
> > Please review it and provide feedback in this email thread.
> > 
> > Pavel, please review this as well, as one section of the proposal may
> > affect your ticket #960 (though it's possible that your approach already
> > accounts for this).
> 
> In overall, looks like a good plan to me.
> 
> Quoting the page:
> 
> > 1. Disentangle sdap_id_op setup from failover configuration
> 
> Sorry, I didn't quite understand this one. The only failover calls I
> noticed in the sdap_id_op_* code were going to the next server in case
> of error on cached connection.
> 

I may have been misremembering. I didn't fact-check every one of these
ideas (I wrote this while disconnected from my computer, to avoid
distractions). It may be that there's no work required here.

> > 2. Handle async resolver needs for referrals. We need to look up referred
> > servers and take the first IP returned by DNS. 
> 
> I assume you meant to resolve the referred host names out-of-band using
> the async resolver directly. Would the approach then be able to "cache"
> referrals to avoid performing a resolution every time a referral is hit?
> 

I think maybe we should just build the lookup cache into the resolver
itself, rather than into the resolver's consumer.

> Another optimization might be to add the referred host name to the failover
> list and delete it when the referral processing (or the whole sdap request)
> is done. That way, we might also play nicer with scenarios where the
> referred server is included in the fail over list as well, although I'm
> not sure how common that would be.

I don't think we want to play with the failover list at all. That could
get us into a lot of trouble if another request came in and (for some
reason) ended up failing over until it finally got to one of the
referral servers.

The danger there would be that the referred server might not have
entries (or not located in the same search base) as the legitimate
failover servers. Then we'd be deleting cache entries.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111110/8e7848c8/attachment.sig>


More information about the sssd-devel mailing list