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.
Hmm...
> -(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?
Vadik.
--
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: