Re: /etc, /usr/etc and bootdisks
On Fri, 4 Jul 1997, Bill Mitchell wrote:
> Just responding to a few points in this...
> On Fri, 4 Jul 1997, Vadim Vygonets wrote:
> > > "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). [...]
> > > [...] 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: [... /usr/etc is, then, optional ...]
> I think you and I are still getting different readings of this.
> As I read it, it says that programs should only look for config
> files in /etc. If config files are placed in /usr/etc without
> being symlinked from /etc, then programs which only look in
> /etc for config files won't find the config files in /usr/etc.
> I think the "may or may not" part is trying to say that if
> a particular program has its config files in /usr/etc in
> the shared /usr filesystem on the server, then individual
> machines may either have symlinks to those files in /etc
> on their local root partitions, or may not have the symlinks
> (and here's what I'm reading into it) but may instead have
> local machine-specific config files installed in /etc.
Ok, you respect fsstnd, but I respect sysadmins' work more, and I
think that having Yann's solution for this is much better than
following fsstnd, because I think that:
1. The Goal of Every Unix is to keep root partition as small as one
2. Once you install a machine, you chould not touch root partition,
especially not when you install a new program far away in the
fileserver land, on a remote partition, and especially not when you
have hundreds of machines taking /usr from one fileserver. You must
install the program once, and not once + hundreds of times.
> Could one of the debian-devel FSSTND experts please clarify this?
> > 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).
> Then, it seems to me, that we'd be requiring all software which
> runs on debian systems and which uses config files to operate in
> a manner other than the linux FSSTND says it should operate.
> That's a bad thing, IMHO. We ought to follow the FSSTND.
> If there's disagreement with the FSSTND, then those who
> disagree with it should urge the FSSTND caretakers to change
We can bug them a little.
> > > 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). [...]
> > You mean things like upgrading /bin/ed and /etc/resolv.conf?
> Yeah. Basically, sysadmin is done on the server, and the
> root partition changes which need propagating out to the
> workstations get automagically propagated by scripts and
> cron jobs. There are probably some tough special cases
> lurking there somewhere -- like upgrading a package containing
> a root partition program, and where the upgraded package is
> somehow incompatable with the old programs (new config file
> format maybe). Another special case would be a standby
> file server -- it should probably not mount the shared /usr,
> but should run audits to be sure its /usr partition stays
> in sync with the shared one. Such special cases will hopefully
> shake out as we go through a couple of alpha versions of this.
IMO this one is less urgent.
Vadim Vygonets * firstname.lastname@example.org * email@example.com * 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
Trouble? e-mail to firstname.lastname@example.org .