/etc, /usr/etc and bootdisks
On Fri, 4 Jul 1997, Bill Mitchell 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:
>
> "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."
Pay attention: may or may not. I prefer not. BTW, continuing the
quote:
{
This also means that /usr/etc is technically an optional directory in
the strictest sense, but we still recommend that all Linux systems
incorporate it.
}
> 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.
Although fsstnd thinks about symlinks in /etc, I think that Yann's
solution is more elegant. And for missing files -- we may decide on a
flag in /etc which will specify that the file is missing, even if it's
present in /usr/etc (like symlink to /etc/missing or something, when
/etc/missing itself doesn't exist...).
> 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.
The first part is right. /usr/etc is for site-wide config.
> 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.
Basically, it's true.
> 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.
Yes, there are many such programs here, but, as I said before, and
Yann agreed, when you install something on the fileserver it has no
right to change the root partitions on all the workstations. Because
that's what /usr is all about. If we don't make it like this (by
using either my or Yann's proposal), we may just forget about the
whole deal with /usr and just put everything in /bin and /sbin.
> 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-wideor 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.
Ok. If you want to allow them to make system-wide config
machine-local, use Yann's proposal, then (remember? first search in
/etc, then in /usr/etc).
> > 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.
Well, I am a sysadmin, and maybe I'll help you (and all of us).
> 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).
Well, that's basically what Debian provides now. IMO we need an
option to copy the root partition image (or .tar.gz, what's the
difference) from an NFS server, and then change the IP and some local
configs which must be changes. So every machine on the network will
eventually have the same programs (like, for example, /bin/ed that
many sysadmins like to put on their disks for tuning almost-dead
systems, because this editor is _far_ more powerful than ae) and
config files (like /etc/mime.types, /etc/resolve.conf and such,
including /etc/passwd, to make the root password the same as on _that_
system by default), and mount the same /usr and /whatever, and _then_
the config program will tune the local conffiles (hostname and such).
That would be cool. You would than need to only specify your network
card and IP. All the stuff above is for workstations.
> It also seems to me that another dinstall root disk needs to
> be created, for debian installation ofdebian 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, andwould 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.
Heh, you're reading my mind hours before I'm thinking ;)
> 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.
You mean things like upgrading /bin/ed and /etc/resolv.conf?
> Once this point is reached, thequestion 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.
Hmm, maybe you're right. I thought about these things before, too.
But i think first we must tune the config files thingie. Well, maybe
you're right. I basically agree to the proposal of yet another boot
disk to copy the root partition for local workstation. I think that
making the package propagating changes in root partition is timely.
Anyway, anyone wants to make the bootdisk or what? I can.
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: