From: "Arthur Korn" <arthur@korn.ch>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org
Subject: Re: autofs init script doesn't support exclude
Date: Thu, 23 Sep 2004 12:54:27 +0200 [thread overview]
Message-ID: <20040923105426.GA3372@turing> (raw)
In-Reply-To: <Pine.LNX.4.58.0409231120110.17889@wombat.indigo.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 1961 bytes --]
Hi
Ian Kent schrieb:
> I think this will need thought wrt what distros use which directories.
> Perhaps some work on configure to make it happen right and at least a deal
> of work on the init script.
>
> My question is "can we try to do this in a reasonably distribution
> independent manner". Having each distro carry its own patches is one way
> to identify the needs.
Actually I don't like this at all. The debian patches to the
init script of autofs3 are the reason why autofs4 is not even in
unstable yet: they are copious in size and fix some delicate
(shell coding, ldap) issues, so it's not obvious wheter they
need to be applied to the new init script and how these problems
are best fixed. Partly that's an issue of badly documented
patches, but they shoudln't have accumulated like this in the
first place.
What I'd much prefer to see (and actually thought about doing
myself) is removing the whole "plug the master map together" and
direct interaction with automount processes from the init
script. Instead there should be a autofscontrol tool (similar to
the ones for apache, bind, ntpd, etc; interactive operation is
not strictly a requirement though) which can start, stop, reload
and display status information. This would have to be able to
act globally on _all_ automount instances.
The init script could then stick to assuring a sane environment
and calling this control tool in the way desired by the user.
> The reason I piped up here is that I have a crazy idea that it would be
> good to be able to use autofs in a range of distributions. Not just RedHat
> and Debian as it is now in the init script. But I'm not sure how I can do
> that yet.
Separating distribution specific stuff from generic code would
be a first step towards that goal IMHO.
ciao, 2ri
--
Secure email, spread GPG, clearsign all mail. http://www.gnupg.org
.
"Never" is almost always earlier than you think.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs
prev parent reply other threads:[~2004-09-23 10:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 22:49 autofs init script doesn't support exclude Marc MERLIN
2004-09-21 20:39 ` Arthur Korn
2004-09-22 7:37 ` Ian Kent
2004-09-22 13:28 ` Jeff Moyer
2004-09-23 3:31 ` Ian Kent
2004-09-23 10:54 ` Arthur Korn [this message]
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=20040923105426.GA3372@turing \
--to=arthur@korn.ch \
--cc=autofs@linux.kernel.org \
--cc=raven@themaw.net \
/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.