All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Peter Staubach <staubach@redhat.com>
Cc: autofs mailing list <autofs@linux.kernel.org>
Subject: Re: [autofs4 patch] Clean up the ldap code
Date: Fri, 01 Dec 2006 09:53:03 +0800	[thread overview]
Message-ID: <1164937983.3404.2.camel@localhost> (raw)
In-Reply-To: <456F3220.9050504@redhat.com>

On Thu, 2006-11-30 at 14:33 -0500, Peter Staubach wrote:
> Jeff Moyer wrote:
> > ==> On Thu, 30 Nov 2006 14:03:40 -0500, Peter Staubach <staubach@redhat.com> said:
> >
> > Peter> Jeff Moyer wrote:
> > Peter> > Hi, Ian, list,
> > Peter> >
> > Peter> > Here's a patch that significantly cleans up the lookup_ldap module.
> > Peter> > In the beginning of time (for this module), there was only one
> > Peter> > supported LDAP schema.  And for a time, it was good.  After a while,
> > Peter> > however, standards emerged -- standards which conflicted with our
> > Peter> > original LDAP schema vision.  With each new standard, our LDAP module
> > Peter> > gained ugly if clauses and added return values.  The parsing of such
> > Peter> > things made the module less and less pleasing to the eye.  And, users
> > Peter> > began to complain of many queries to their poor little LDAP servers.
> > Peter> >
> > Peter> > In a heroic effort to bring peace back to the world of autofs and
> > Peter> > LDAP, I present this patch.  Among its merits, I submit the following:
> > Peter> >
> > Peter> > o It will perform less binds to the LDAP server
> > Peter> > o It will remember which LDAP schema worked, and continue to query
> > Peter> >   only that schema (instead of trying all three every time)
> > Peter> >
> >
> > Peter> It is good to remember the working schema, but what happens if that
> > Peter> schema stops working?  It seems like it would be good to forget and
> > Peter> then try all three again until another working schema is discovered.
> >
> > I'm not sure that a sane administrator would switch schemas in
> > production; that seems like a fairly unlikely situation.  Also, how
> > would you differentiate between a failed lookup for a key that doesn't
> > exist and a failed lookup due to a schema change?  I think that we
> > have to enforce at least some sane constraints, here.
> >
> >   
> 
> I guess that I was naively hoping that there was some way to
> differentiate between these two failed lookups.
> 
> If not, then I agree completely.  I think that assuming a sane
> administrator may be a bit of a dangerous assumption, but what
> the heck, gotta start someplace, I guess.  :-)

A sane administrator, now there's a thought!

Ian

  reply	other threads:[~2006-12-01  1:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30 17:45 [autofs4 patch] Clean up the ldap code Jeff Moyer
2006-11-30 19:03 ` Peter Staubach
2006-11-30 19:13   ` Jeff Moyer
2006-11-30 19:33     ` Peter Staubach
2006-12-01  1:53       ` Ian Kent [this message]
2006-11-30 19:47 ` Jeff Bastian
2006-11-30 20:09   ` Jeff Moyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1164937983.3404.2.camel@localhost \
    --to=raven@themaw.net \
    --cc=autofs@linux.kernel.org \
    --cc=staubach@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.