Re: /usr vs. root was: /etc /usr/etc
On 6 Jul 1997, Manoj Srivastava wrote:
> Vadim> The division goes like this: if the program puts its config
> Vadim> files in /usr, they must go into /usr/etc; if the program puts
> Vadim> its conffiles on the root partition, they must go to /etc.
>
> So, we decide on placing files dependeing on where the
> upstream sources put their files? This does not sound like a sound
> technical policy to me. Remember, most authors do not write with
> Debian's file system discipline in mind.
And you know why? Because other Unices have similar filesystems,
i.e., noone puts site-wide conffiles in /etc. The authors kept in
mind the more technical definition of files which must go to /usr,
that is, the files that don't have to be different on the machines
across the network (like hostname), aren't essential for boot or
single-user mode maintainance.
> Vadim> You have user's .emacs for it. It must depend on the user, not
> Vadim> on the machine one is working on.
>
> No, I have 500 people on the documentation group and we all
> use machines XXA to XXZ. I don't want all 500 to continue making
> changes as the requirements of the group change. On the other hand,
> the 15,000 developers do not want auctex on the system. Not site
> wide, but a section of the site. The only solution that worked for us
> (make thet secretaries and undergrads) was rdist, not second guessing
> the local configuration.
Anyway, some of them will want to customize their .emacs (adding
keystrokes, tuning config). And what happens if one of them wants to
work on the developers' machine? This is common on our site. There
are machines that are open for everyone, and ones that are open to
some groups of users only. IMO dotfiles in users' directories are
exactly for this. Or, you can user different skel directories when
you add new users from different groups.
> >> Who decides which file is site wide? What happens if the local site
> >> disagrees?
>
> Vadim> Then, there are proposals which are designed for this
> Vadim> situation. For site-wide conffiles, many people would like to
> Vadim> make it like this: if the conffile is found in /etc, use it;
> Vadim> otherwise, look in /usr/etc. Of course, it's only for the
> Vadim> conffiles which belong to /usr, i.e., site-wide. It won't work
> Vadim> like this for files like /etc/passwd or /etc/hostname. They
> Vadim> will always be in /etc.
>
> Why complicate the simple elegance for a partial hack? Unless
> there is a clear division of the locations, this will lead to an
> unholy mess. Also, I believe this issue came up in the early stages
> of the FSSTND (when I used to be on the list), and has been discussed
> ad-infinitum, and the consensus was agains the split (correct me if I
> remember incorrectly). I have little desire to rehash the issues, but
> I will if I must, or if you present compelling technical arguments
> agains the current practice.
I think there must be a split, because of what I told tens of times
already. By the way, at large sites, as I noticed, sysadmins almost
never change config files of programs like emacs, pine and lynx.
> >> Making the boot smaller when the non-essential config files are
> >> less than 1Mb in size is not a good enough reason, seeing that it
> >> would entail breaking FSSTND compliance.
>
> Vadim> Many people pointed that we must have a clean solution, and if
> Vadim> we find a solution cleaner than one in fsstnd, we should use
> Vadim> it. I think we found one.
>
> I have yet to see a technical argument to that effect
> (imperative statements don't really count).
There was a long discussion, at it involved technical issues and
issues relevant to Unix philosophy.
> >> The proposal is flawed, because it does not solve the problem
> >> cleanly either (what if my site has a different idea about which
> >> packages have local changes than Debian does? Do I have to change
> >> conf files around?)
>
> Vadim> What do you mean? If I understood you right, you mean that
> Vadim> your site may have different ideas about which config files are
> Vadim> machine-local.
>
> Precisely.
Then, again, you may move them to /etc.
> >> Also, as a sysadmin, I really liked to have the conf files for all
> >> machines at a central location, and I used rdist. That allowed me
> >> to group machines into categories (DCE client machines, Server
> >> machines, file servers, print servers), allowed me the flexibility
> >> of distributing the same printcap file to all print clients, while
> >> having different fstab files; I could even have a cmmand execited
> >> when I updated /etc/aliases.
>
> Vadim> I already explained why this solution is better than rdist.
> Vadim> Make the root partition changing as less as possible. IMO
> Vadim> having some of the conffiles in /usr/etc is better. Of course
> Vadim> you must use rdist sometimes, but not too much.
>
> I think that an inviolate root partition is not as much of a
> requirement as ease of management. In fact, *why* should the
> root partition be constant, if I can centrally control all my
> machines? What does it buy me? If you don't have centralized control
> you hae to scramble all over the place, putting in policy hacks like
> NO-CHANGE-ROOT-PARTITION and SITE-WIDE-CONFIGURATION-IN-USR. Instead,
> please look at professional management systems (I personally prefer
> TME) which would be the way to go. I think that distributing the
> conffiles just leads to confusion, and hacking the programs to get
> the same results we get today.
>
> If you lack the big bucks for TME (as do I), you use
> rdist, with none of the (pardon me) bureaucratic policy hacks
> required.
>
> All you have offered is an opinion that some files in /usr are
> bertter. This comes at the cost of modifying programs to search n
> /etc, then in /usr, and at the cost of confusion where a particular
> programs conf files may lie (I agree this is not a major drawback,
> since there are only two (or three, with /usr/local/etc) locations
> proposed.) And using the upstream authours guidelines, when the
> programs are rarely designed with Debian's file system discipline in
> mind, seems like a poor choice for partitioning.
I respect your opinion, but don't agree with it (for reasons explained
many times over).
> manoj
> glad not to be maintaining a user system that my old boss tells me
> now has 25,000 users, 43 vendors, 6 operating systems, and an average
> of 6.458 crises per day ;-)
I maintain a system with 3 OSes (BSDI, SunOS and IRIX), 1 Solaris box,
1 Linux box (will be more soon), some NT and DOS computers (not my
fault, and I don't touch them), and I'm actually glad with it.
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: