Subject: Re: Rototil of sysinst partitioning code
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 06/05/2003 15:10:43
[ On Thursday, June 5, 2003 at 14:33:12 (-0400), William Allen Simpson wrote: ]
> Subject: Re: Rototil of sysinst partitioning code
>
> Perhaps it's just my faulty memory of what's gone before,

/usr as it is today is totally an artifact of how big and how many disks
were available on the original PDP-11s unix was first created on.  /usr
was initially for user home directories, but the base OS grew too big to
fit on the root disk and since so many of the initial users were writing
software for the system they just ended up sharing their "user-level"
stuff in /usr/bin and the rest is history.  /usr still grew too big of
course, but until bigger disks were available the solution was to simply
remove shared programs that were not used since obviously they were not
needed as part of the generic system.  I think all this may even be
documented in a paper or two somewhere, or maybe some of it is on a tape
of an interview with DMR et al that I have somewhere around here....

> but I've 
> always thought of / as a carefully maintained area where variable 
> per system security conscious material is kept, and the structure 
> and files (especially /root and /etc) needed protection from wild 
> (or accidental) expansion from rogue activity.

That's also exactly what /usr is -- at least on a modern *BSD system and
at leas so long as /usr contains only what hier(7) says it should
contain, and so long as it does not contain the actual /usr/obj, but
rather a symlink as suggested.

Personally I would put /usr/pkgsrc and /usr/pkg up with /usr/src so as
to strongly hint that they should all be on some separate filesystem(s),
but either way it's not nearly so bad as having /home -> /usr/home as
I've seen on many poorly maintained systems.

> While /usr is the static, rarely changing, sharable, read-only, 
> union-mountable (maybe even on a CDROM) area that expands as new 
> user programs (and packages) are added by root (and never by users). 

And your point is?  Of course it needs some extra room!

> Thus, I agree that / and /usr could be combined on a single user 
> workstation, where the same person maintains everything.  The only 
> person you hurt will be yourself.  Although the hurt could be drastic.

How is this different from what is on the root filesystem, pray tell?

There is literally no difference to how much damage a person can do to
their own system by installing and maintaining it, regardless of how its
directories and filesystems are laid out.  Everything you're thinking of
as unique to /usr is a figment of your imagination.

(assuming that person isn't macho enough to set LOCALBASE=/usr and then
blindly go about installing packages from source.... :-)

> But, on a file server (where many persons might be accessing the 
> machine) or development machine (where the programs frequently change, 
> the build scripts can accidently blow away whole directories, etc), 
> I'd really prefer to have /usr separate.

Ah, I see your point now:  you don't trust your fellow sys-admins.

Well then put /usr/pkg on a separate filesystem and be happy with /usr
on the root filesystem!

You only need /usr on a separate filesystem if you really REALLY need to
mount it read-only, but there we go again thinking that there's
something special about /usr that doesn't equally apply to /etc and the
rest of what's on the root filesystem.  If you don't trust your fellow
admins to work in /usr then you cannot trust them in / either.

> Do we want to change /usr/pkg to /opt?

I sort of did this on my development system!  ;-)

But I only did it so that /usr/pkg and /usr/local could both point to
the same shared separate filesystem because that's where I had more disk
to spare:

$ ls -l /usr/pkg /usr/local 
lrwxr-xr-x  1 root  wheel  12 Mar 16  2000 /usr/local -> ../opt/local
lrwxr-xr-x  1 root  wheel  10 Dec 22  1998 /usr/pkg -> ../opt/pkg


:-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>