Quoting Greg A. Woods (woods@weird.com):
> [ On Friday, June 6, 2003 at 12:28:44 (-0400), Chuck Yerkes wrote: ]
> > Subject: Re: Rototil of sysinst partitioning code
> >
> > I forgot one: bad crash.  if /usr is mounted ro, we don't
> > have to worry about fsck.  If / is RW, but only 80MB, fsck
> > takes a moment.  And I don't worry about /lost+found filling
> > up with much of /usr.
> 
Generally, I ignore the GW posts...

> That's all very irrelevant.  F.U.D. in fact.  If your system suffers a
> bad crash then system related things will get messed up no matter where
> they are and they will have to be fixed before you can use the system
> properly again.
No, they won't.  If / gets whacked, and /usr is readonly, then a 60MB
fsck takes far less time than a multi gigabyte fsck.
Oh, and /usr won't corrupt on readonly file systems - there are no
outstanding buffers.

MORE, I can more easily work through a lost+found with 200 files
than one with 2000 files.
 
> > No, it doesn't.  USERS may do that, but if /, /usr, & /var
> > are separate, when /home fills up I know where to look.  When
> > /usr gets huge, I know where to look *and* it's sometimes a
> > reason for concern.
> 
> That has _NOTHING_ to do with /usr being on the root filesystem.

Need smaller words?
/ is full!  Oh no!  It's at 110% at 90MB.  What shall I do?
Oh, I'll look in the 10 directories.
Hey, there's a couple big ol coredumps in /etc/.  There, problem gone.

Compare with:  
Huh, my 8GB disk is at 45% not 44%.  I wonder what is amiss?
Oh, there at many core files in / and /etc/ and there's a /dev/rts0
file that's a dump to the mis-typed /dev/rst0.


> The inclusion of /usr on the root filesystem does not by itself leave
> any more user-writable files or directories on the root filesystem than
> would be there otherwise.
Um, Greg?  It leaves all of /usr as writable.  Oh, are you
only concerned with non-prived users?  Pull the head out of
the sand.  It's admins and processes that I find cause more
of the damage, although usually without malice aforethough.

If I have a good copy of /etc/ on my systems, along with /var/
and /home/, I can replace a machine in a few minutes.  /var/ has
info about all the packages I install.  I do NOT put config files
in /usr/local/etc, they go, usually, in /etc/PKG (eg. /etc/snmpd,
/etc/mail, /etc/ntp.conf, and so forth).

For a running server, I need /var/ to be writable and perhaps home
dirs.  That is ALL that should change day to day.  With syslog
off the machine, I can have NOTHING writable.  Given a recent
breaking that some friends are cleaning up from with trojaned
binaries, I'm MORE happy with my decision to run RO systems.

It's not a new habit:  I built SunOS 4 web servers (Cern httpd
days) for a website for a very large cracking target.  We got
probed regularly back when you logged probes and followed up.
I couldn't get / readonly then (and Solaris STILL writes to /etc/
as it boots). 
I could put most of the system onto a disk that was PINNED readonly.
The rw disk was checked hourly with tripwire.  TW's database was
PGP signed and lived on readonly media.  You can't get in, but when
you do, you can't change anything below /usr/.


That, and many other things I've gone through are the benefits of
separating file systems.  Disadvantages are that if you run out of
room in /, then you have problems.  That's either a system where
it is being used fast and loose (which is not uncommon on a build/test
system - I'll keep 4 kernels on those systems), or where you
didn't build it with knowledge of it's use.

monolithic file systems indicate a lazy admin.  "it's easier"

> > But with monolithic /, I first may not notice 12 core files in /.
> Again, that is simply not possible if you've configured the _rest_ of
> your system properly.
> 
> Please do not try so hard to mis-represent this issue!

I'm rubber blah blah your glue blah blah ...

Greg, you've been around enough.  You're not nearly as slow and
stupid as you seem to insist on acting.