Re: Proposal: /etc /usr/etc /usr/local/etc
On Sun, 6 Jul 1997, Vadim Vygonets wrote:
[... severely trimmed ...]
> 1. Moving various files to /usr/etc (the Simple Solution)
> 2. Having symlinks in /etc pointing to /usr/etc (the Symlink Solution)
> 3. Making the programs in Debian first seek for conffile in /etc, then
> in /usr/etc (Yann's Solution)
> 3.a Write a function which will do it (Yann's Solution 1)
> 3.b Write a driver that will do it (Yann't Solution 2)
> 4. Using [.. the transname stuff..] to mount remote /etc (the Remote /etc
> Solution)
There should be at least two other alternatives added to this list:
0. Putting all config files in /etc (the Very Simple Solution)
5. Using the transame stuff to mount a remote root partition
(the Diskless Workstation Solution)
Solution (2) is current practice.
I would vote for (2) today because it's FSSTND-compliant, and because
it provides for both site-wide and machine-specific config files.
The package maintainer decides where the config files go, and
it's illegal to move them unless/until the dpkg-maintainers give
their OK (dpkg must deal with the relocated files properly on
package upgrades and removals).
I would vote against (0) because it doesn't address admin concerns
in networked systems (doesn't share common site-wide config files,
all config files are machine-local). It's perfectly possible to
have and administer a system where all conffiles are machine-local,
of course, but there's less chance of error and confusion if files
intended to be the same in all machines are shared from one single
copy located in one single location.
I would vote against (3[ab]) unless and until it can be shown that
they're FSSTND-compliant. Even then, I'd be leery of (3a) because
it would break many existing programs so that they would run but
would fail to find config files in /usr/etc.
>From what little I've read in debian-devel about transname, I think
(4) and/or (5) may offer the best solution. However, I can see
how they might be looked on with suspicion by some sysadmins just
because they look strange. I'd say go with (2) in the short term,
and consider moving to or, better, offering the sysadmin the option
of using (4) and/or (5) later on.
I think it would be dynamite for debian to offer sysadmins the
option of choosing (2) or (4/5), and to provide effective admin
support tools to support maintenance of the machine-specific
conffiles (including tools to convert installed confiles between
the (2) and (4/5) schemes).
Alex Yukhimets <aqy6633@is5.nyu.edu> said:
> Guys, let's keep eyes on the ball and postpone the solution of this
> problem till it would actually be a problem. Meanwhile someone
> (Vadim ?) could develop a package containing utilities which would
> simplify task of maintainence and administration of large network
> environments.
Some days ago (it seems longer than just a few days) I opined
that this topic wasn't yet timely. Despite having become involved
in this too-long discussion on this thread, I still believe that.
I think we ought to put this aside for now, and take it up
again once we have a working set of install disks for
debian-standalone, debian-fileserver, and debian-workstation.
Finally, Bruce Perens <bruce@pixar.com> said:
> I've been writing an architecture for remote and workgroup administration
> that would address most of these issues. It'll take some time to be implemented,
> but expect to see demonstrations soon. Watch debian-admintool if you are
> interested.
So, we need to wait for that in any case.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: