[SSSD] [PATCH] LDAP: If deref search fails, try again without deref

Jakub Hrozek jhrozek at redhat.com
Wed Mar 20 12:52:39 UTC 2013


On Wed, Dec 05, 2012 at 09:09:46AM -0500, Simo Sorce wrote:
> On Wed, 2012-12-05 at 08:50 -0500, Stephen Gallagher wrote:
> > On Wed 05 Dec 2012 04:54:52 AM EST, Jan Cholasta wrote:
> > > On 3.12.2012 21:36, Stephen Gallagher wrote:
> > >> On Mon 03 Dec 2012 11:14:28 AM EST, Jan Cholasta wrote:
> > >>> Hi,
> > >>>
> > >>> the attached patch fixes <https://fedorahosted.org/sssd/ticket/1660>.
> > >>
> > >>
> > >>
> > >> Could we do this as a check during the RootDSE lookup (similar to how we
> > >> test for the Active Directory matching rule support) instead of doing so
> > >> when we attempt a deref lookup? It would more consistently report the
> > >> issue during startup as well.
> > >
> > > Sure, but can we really trust this check? AFAICT in OpenLDAP deref is
> > > configured per naming context, which means it might not be available
> > > in RootDSE, even when it is available in our search base.
> > >
> > > Honza
> > >
> > 
> > I think you misunderstood my recommendation. I didn't mean that you 
> > should do this check against the RootDSE itself, but instead to do it 
> > during the process we use for getting the RootDSE in the first place. 
> > It's intent is to determine the capabilities of the system.
> > 
> > What I meant was to test each of the configured search bases at this 
> > point once right at the time of connection so that if there are issues 
> > we will be able to report them early on, instead of waiting for the 
> > first time a search occurs on each base.
> 
> I think Jan's approach is better Stephen,
> your suggestion trades a slightly better error reporting for a new set
> of calls right upfront.
> Most of the time these calls will be completely unnecessary but they
> will add in latency as now each time we reconnect we need to wait a few
> searches before we can start with business.
> I think this trade-off is wrong.
> We should not load the server more and we should not add yet more
> latency to our connection path, so I prefer on the fly detection like
> Jan did.
> 
> Simo.

I don't have any issues with the approach taken and interestingly
enough, the patch still applies. It also received positive testing
feedback from the reporter.

Unless there is any pushback against this patch, I would like to accept
it.



More information about the sssd-devel mailing list