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

Re: Proposal: /etc /usr/etc /usr/local/etc

On Wed, 2 Jul 1997, Bill Mitchell wrote:

> On Wed, 2 Jul 1997, Vadim Vygonets wrote:
> > On Tue, 1 Jul 1997, Yann Dirson wrote:
> > 
> > > Then I guess that having some sort of "search path" for config files,
> > > that is looking first if /etc contains a conffile, and only if not,
> > > taking the one installed in /usr/etc. This could even be made to use
> > > conffiles for groups (sub-sites) of computers, by using
> > > /etc:/nfs/mygroup/etc:/usr/etc as a search path.
> > 
> > Cool.  I agree it's cool.  It will take more work than my simple
> > standard solution, but it's nice.
> This sounds to me like it'd take a lot of per-package hacking.

Yes it is.

> Also, it sounds like what's being argued here hinges on whether or
> not debian should abandon Linux FSSTND compliance on this point.
> >From FSSTND-1.2:
> 4.5  /usr/etc : Site-wide system configuration [snip]

What it basically says is: you may put conffiles in /usr/etc, if you

> So, the package maintainer makes the determination of whether
> his package is to be machine-local or site-wide configurable
> by whether he places the config files in /etc or in /usr/etc.
> If he places config files in /usr/etc, he places symlinks
> to them in /etc.  The programs in his package should look in
> /etc for configuration files.

This means that the admins should manually tune all the machines.

> ( begin digression
> It occurs to me at this point towonder if debian is ready for
> prime time in networked systems of many machines each having
> a machine-local root partition with /proc, /sbin, /bin, /boot,
> /tmp, /var, /etc, ...; and a mount point for a common /usr.


> By what standard debian installation mechanism do the root
> partitions on all those machines lacking a local /usr directory
> tree get set up?  (Perhaps they're expected to have a standard
> base-system-install /usr tree, with the common /usr directory
> nfs-overmounted on that /usr leaf?)

Wasting disk space?  Thanks.  The whole point in /usr is to save disk
space (which we don't with debian's overfilled /etc), and to install /
upgrade any program only once, _once_, *once*, !!!ONCE!!!  I'm
shouting because it seems you don't get my point.  I don't wanna run
between machines when I change my proxy and want to change lynx.conf
to know it.  Or putting symlinks on each and every machine...

> (Perhaps they're expected
> to have "rm -rf /usr/*" done manually sometime after the
> debian install?)

Ridiculous, too.  Because it means that there's no Linux machine to be
installed first time with disk about 32M (I don't count swap).

> (Is there not a less labor-intensive means
> than a manual debian install to get the root partition onto
> these machines?  If not, should there not be some such means?)

What I want is: decide whether your package is in / or in /usr, and
then, put _all_ of it on _one_ of the above.

> What is the mechanism by which installation/upgrade/removal
> of packages which affects the root partition gets propagated
> to all these separate machines?  (Surely not per-machine 
> manual twiddling)

None, I'm afraid.

> Anyhow, assuming these machines have gotten debian installed
> somehow, and that one common machine is providing a common
> /usr filesystem which the other machines have mounted,
> and the package admin issues have been dealt with, ....
> end digression)

Then what?  Then everything's alright, isn't it?

> A sysadmin might convert packages configured machine-local into
> site-wide by moving the config files from /etc on the machine
> which provides the common /usr directory tree into /usr/etc
> on that machine.  He must also emplace symlinks into /etc
> on each separate machine.  This could no doubt be mechanized.

Why should you do it at all?  Why in this world would you want to have
a local config file, when other machines (and other Unices) have
site-wide config file?

> He could also convert packages configured site-wide into
> machine-local configuration by doing the reverse.  Either
> course would leave him with a configuration which would
> probably require his manual attention when upgrading these
> packages.  Perhaps debian ought to provide some standard
> procedures/mechanisms to assist sysadmins in this.  OTOH,
> perhaps debian ought to consider this sort of tweaking as
> illegal and unsupported.

All other Unices concider it illegal.  I heard no complaints.

> I just recently resubscribed to debian-devel, and I'm still
> coming back up to speed on the state of things.  It seems
> to me, in my ignorance, that more basic issues relating
> to debian installation and administration in networked
> systems need to be nailed down here before discussion of
> these details.  (or do I misunderstand???)

I think so too.  Debian IMO must go to the direction of large
networking systems.


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: