[geeks] Thoughts on bash for root

[Greg A. Woods]

[ On Monday, April 22, 2002 at 18:36:01 (-0500), Jonathan C. Patschke wrote: ]
> Subject: Re: [geeks] Thoughts on bash for root
>
> On Mon, 22 Apr 2002, Greg A. Woods wrote:
> 
> > Oh how wrong you are!  ;-)
> 
> Okay, let's look at two systems.  One of which has /usr as a separate
> parition.  One doesn't.
> 
> Now, fill the /usr partitions on both systems.  This happens all the time
> due to patching, poor planning, upgrading applications, whatever.  It's
> not a good idea to do intentionally, and the situation is normally
> resolved quickly, but it does happen.

Sure, even I've done that once or twice -- but never while the system
was in production of course, and only because I was too insistent on
integrating applications very tightly without symlinks instead of
installing them in /opt (or whatever you might want to call it),
i.e. never when the following could happen without me noticing it
instantly:

> Now, modify some critical file in /etc on both systems.
> 
> Voila!  One system is now useless!  And, if the file contains significant
> system state (say, /etc/shadow), you lose data in the process

Well, forgetting about the many stupidities of SunOS for a minute, I
can't think of any configuration file which, if edited while the root
filesystem was full, could cause any loss of data or system state.
Certainly none can even cause a crash that would leave the system
unbootable at least to single-user mode.

As for Solaris stupidities, well those are just a stupid design flaws
that there are lots of good and proven solutions for.

And if you think you can cause irreparable damage by accident while
doing normal correct administrative procedures simply because /usr fills
when you least expect it, then I think you're not a very experienced
systems administrator.

IIRC about the only file in /etc critical enough even on Solaris to
cause your next reboot to fail if you don't notice any errors should be
/etc/inittab.  But if you've miss the error from your editor when it
fails to write out the file, and you also miss the filesystem full error
from the kernel as its spewed to your console and to every terminal
where root's logged in, and you still reboot, then too bad, so sad:  I
guess you'd better drive/fly/swim to the machine room, dig out your
spare CD ROM drive, plug it in, and find your boot CD, boot from CD, and
fix it the hard way.

(As for /etc/shadow, well there's very little that can go wrong that
can't be fixed with great ease with any text editor, or awk for that
matter -- and if pwconv were made smarter it could safely do many of
those fixes all by itself too, and thus be run on every boot.)

> One more thing:  If / and /usr are separate partitions, you can't mount
> /usr as read-only.

... and do you actually do this on Solaris machines today?  (i.e. who
cares about a feature nobody uses?)

and is that worth the danger of having a totally unbootable system if
the tiniest thing goes wrong with /usr?  this really is a case where
putting all your eggs in one basket is less risky.

(on *BSD I could mount a root filesystem, including /usr, as read-only
if I was running a NIS server on some other machine -- nothing but the
passwd databases are ever written to by any normal run-time operations,
by users or administrators.  I know *BSD firewall admins who run their
systems this way today.)

> > Do you have any idea at all why there is a /usr in the first place?
> 
> I'm sure that any answer I have you will gleefully tell me is incorrect.
> So, I'll pretend I don't know and save myself the time that would be
> invested in typing the answer.  Please note that this is also not an open
> invitation for a lecture.

suit yourself....  let's just say that those who invented the concept
out of necessity a very long time ago (in computer/internet years) were
more than happy when they were finally able to shed it once and for
all....

-- 
								Greg A. Woods

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