All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Stef Bon <stef@bononline.nl>
Cc: autofs@linux.kernel.org
Subject: Re: ldap and reloading
Date: Mon, 08 Jun 2009 10:00:34 +0800	[thread overview]
Message-ID: <4A2C70C2.6060505@themaw.net> (raw)
In-Reply-To: <4A2B7C7B.7060909@bononline.nl>

Stef Bon wrote:
> Hello,
> 
> when using static file maps, or even executable maps, when the map 
> changes, you'll have to reload the daemon to make these changes effective.
> 
> How does this work when all the data is in ldap? Does the automounter 
> still creates a sort of snapshot of the map in memory, and to reread the 
> data provided by ldap, a reload is neccesary? ldap is well know for that 
> this is not needed. For example with postfix, it can use static maps, 
> and when something changes, it has te be restarted. But when the lookup 
> data (for local users for example) is in ldap, this is not neccesary.

That's not quite right.

If you use the "browse" option then the entire map must be read in at
start. If not then autofs remembers entries that it has seen and
attempts to check their currency at lookup.

Each lookup should check if the entry is still up to date and attempts
to work out if the map has changed (although it's not quite as simple as
that). If we think the map has changed a re-load should be triggered
internally. Following the (or any) re-load there is a cleanup which is
probably why it looks like map changes aren't seen. Any changes in
multi-mount entries cannot be seen until after they have expired away,
because of the need to maintain the context of the entry over the
duration of the mount.

Direct maps don't quite do this properly, partly because of the way they
work and partly because of an issue I haven't addressed yet.

Clearly, with program maps, we need to rely on the re-load to a large
extent but a best effort is made to work out if the entry is stale,
however, we just don't have anything really to use to establish this, so
 a re-load is needed to clean them up.

Ian

  reply	other threads:[~2009-06-08  2:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-07  8:38 ldap and reloading Stef Bon
2009-06-08  2:00 ` Ian Kent [this message]
2009-06-08  9:09   ` Stef Bon
2009-06-08  9:33     ` Ian Kent
2009-06-08 10:16       ` Ondrej Valousek
2009-06-08 13:18         ` Ian Kent
2009-06-08 15:03           ` Stef Bon
2009-06-09  3:19             ` Ian Kent

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=4A2C70C2.6060505@themaw.net \
    --to=raven@themaw.net \
    --cc=autofs@linux.kernel.org \
    --cc=stef@bononline.nl \
    /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.