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

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

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 * 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: