Re: Proposal: /etc /usr/etc /usr/local/etc
On Thu, 3 Jul 1997, Vadim Vygonets wrote:
> > [...] the FSSTND requirement that symlinks be left
> > behind in /etc in this situation? [...]
>
> 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:
"We eventually decided that /etc should be the only directory that
is actually referenced by programs (that is, everything should look
for configuration in /etc and not in /usr/etc). Any configuration
files that need to be site-wide and are not needed before /usr is
mounted (or in an emergency situation) should then be placed in
/usr/etc. Then, specific files (in /etc) on specific machines may or
may not be symbolically linked to appropriate configuration files
located in /usr/etc."
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.
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.
> > Also, Vadim Vygonets has questioned whether debian should support
> > install-time diversion of conffiles from /etc to /usr/etc (or
> > vice-versa) at all. Vadim sugggests (my paraphrase) that the
> > package maintainer'splacement of conffiles should be considered
> > final, and that relocation of conffiles between /etc and /usr/etc
> > should be considered illegal and unsupported.
>
> I just see no reason to move files that belong to /usr/etc to /etc.
> If you see any reason, please tell me (because many people base their
> answers on some thought that the reason exists, but nobody told me),
> and then, maybe we will support the relocation.
Regardless of whether the package maintainer places a package's
config files in /etc or in /usr/etc, it's possible that there
will be sysadmins somewhere who want that package's config
files in the other place to change machine-wide config to
system-wide or vice versa. I think it's an open question
right now whether debian should allow/support the per-system
flexibility for sysadmins to move those files and, if so, how.
think that there are other, more basic, issues relating to
debian install and admin in a networked environment which need
to be addressed before that open question becomes timely.
[... snip ...]
> 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.
OK, I'll try. Please understand that I'm not (yet) using debian
in a networked environment with a shared /usr filesystem. Also
please understand that I'm not an experienced and knowledgeable
sysadmin. I'll probably overlook some points and misunderstand
others due to my scanty sysadmin background.
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. This disk would step the installer
through disk partitioning and initialization, would then clone
the root partition from the central machine, and would then
interact with the installer to get the needed machine-specific
changes made to the cloned root partition (e.g., /etc/hostname,
and setting up /etc/fstab to mount the shared /usr filesystem).
The newly set-up networked debian workstation would then be
rebooted, and should come up on the network.
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). As I
envision it, there would be a package containing this support
stuff which would be installed on networked central machines.
This package would depend on the needed networking packages,
insuring that they would be installed, and would do the
central machine networking setup in its postinst script.
Once this point is reached, the question of whether and how
debian should support per-machine repositioning of config files
to switch programs between site-wide and machine-specific
configuration becomes timely.
--
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: