[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

+(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
-(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

Did I forget something ?
Yann Dirson <dirson@univ-mlv.fr>

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: