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

Jakub Hrozek jhrozek at redhat.com
Thu Mar 21 17:35:26 UTC 2013


On Wed, Mar 20, 2013 at 01:52:39PM +0100, Jakub Hrozek wrote:
> 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.

Ack and pushed to master.



More information about the sssd-devel mailing list