Re: Proposal: /etc /usr/etc /usr/local/etc
Bill Mitchell writes:
> On Thu, 3 Jul 1997, Vadim Vygonets wrote:
> > AFAIU, that's not the requirement. FSSTND also allows to just put
> > config files in /usr/etc.
>
> As I read section 4.5 of the FSSTND (quoted in an earlier posting),
> it is a requirement. I'll requote below just the key passage:
[...]
> As I understand that:
>
> 1. Programs should look only in /etc for config files. They
> should not look in /usr/etc. Config files placed in /usr/etc
> may be missed unless they can be found via a symlink from
> /etc.
>
> 2. /etc is machine-local. Config files may be given site-wide
> visibility by placing them in /usr/etc (which is site-wide)
> and providing by a symlink in /etc.
>
> 3. However, on individual machines, the symlink in /etc might be
> removed and replaced once again by config files. This would
> allow administrators to override site-wide configuration where
> desired by supplying machine-specific config files on some
> (or all) of their individual machines.
It seems the same to me.
> You've been urging, I think, that all (most? many? some?) config
> files should go into /usr/etc without symlinks in /etc pointing
> to them. That would be contrary to FSSTND section quoted above,
> as I read it. It would be permissible (required?) for programs
> written with this FSSTND section in mind to fail to find the config
> file in that situation, as I read it. Given this passage in the
> linux FSSTND, I'd not be suprised to encounter programs for linux
> which acted this way.
The FSSTND is there as guide. As long as all requirements can be
solved cleanly following FSSTND, there's no reason to change it; but
if we find out that something can't be solved cleanly, then maybe it
will need to be changed...
> > Let's come to a solution. Please post what you think about the
> > networking issues, and which issues must be resolved. I agree that
> > Debian is not built for networking environments.
[...]
> It seems to me that the dinstall disk set needs to be enhanced
> to offer the option of setting up the target machine as what I've
> been calling the central machine in a debian networked environment
> (the one which provides the shared /usr filesystem mounted by
> networked debian workstations).
>
> It also seems to me that another dinstall root disk needs to
> be created, for debian installation of debian workstations
> in a networked environment with a debian central machine
> available on the network.
[...]
It might not be necessary to have 2 different disks for that; all we
need is to have the 2 options. Practical requirements will maybe force
to add 1 floppy, but it should IMO not be the starting point.
> Also, sopport scripts/programs/procedures need to be put in
> place which would get changes made in the central machine's
> root partition (package install/upgrade/removal, manual sysadmin
> changes, etc.) get propagated to the root filesystems on the
> networked debian workstations (and that changes which are
> inappropriate to propagate do not get propagated).
[...]
OK, let's try to summarize the 2 alternatives:
Everyone agrees on the fact that site-wide conffiles should be in
/usr/etc, and local ones in /etc.
Points get a + when I consider them good, a - if bad, an = if
non-significant, a ? if I don't have an idea
1) conffiles accessed exclusively through /etc, via symlinks if not
overriden.
+(a) conffiles can be overriden by another conffile in /etc;
?(b) conffiles can be made invisible by suppressing the symlink.
+(c) This is FSSTND-conformant.
=(d) This needs a mechanism for automatically updating all /etc
directories, but anyway we'll need such a mechanism to update the
whole root partition on those NFS-clients, for programs living in
/bin.
-(e) A program running as root has to be launched each time a new
program is (un)installed, to create/remove an /etc link, even if this
package lives otherwise only under /usr
-(f) Support for updating symlinks has to be built
2) conffile search-path (either by library or by filesystem):
+(a) still holds
?(b) hardly. But is this useful?
-(c) This would require a change to FSSTND
=(d) /etc will still have to be updated on new installs, and the
argument about the whole root-partition still holds.
+(e) This will save some (local) networks packets when installing a
package that only lives in /usr. This might IMHO be a plus for
security reasons.
-(f) Something has to be implemented specially for that (either the
lib, or the filesystem feature)
Given that I consider point (c) to be significant only if technical
issues require equivalent workload, both solutions seem to be quite
equivalent.
Did I forget something ?
--
Yann Dirson <dirson@univ-mlv.fr>
http://monge.univ-mlv.fr/~dirson
--
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: