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

Re: Proposal: /etc /usr/etc /usr/local/etc

On Fri, 4 Jul 1997, Yann Dirson wrote:

> Bill Mitchell writes:
>  > 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...

Well said.

>  > > 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.

I agree, we don't need an additional floppy.  All we need is to teach
the existing one to copy (or untargz, what does it matter) the root
partition from a remote NFS server.  That must not be difficult and
must not take much space on the floppy.

>  > 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.

I think this one deserves '-'.

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

Why will /etc/be updated?  Only if you copy a file into /etc, and
change it.  But then, you don't want a new version to be installed,
because otherwise, why would you copy / change it?  Pure logic :)

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

I don't like the filesystem idea.  But I do like the lib idea: it will
be only one function, remember?


Vadim Vygonets * vadik@cs.huji.ac.il * vadik@debian.org * Unix admin
The fish doesn't think, because the fish knows...  everything.
	-- Arizona Dream

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: