[geeks] Thoughts on bash for root

[Jonathan C. Patschke]

On Mon, 22 Apr 2002, Greg A. Woods wrote:

> 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.

Truncate /etc/path_to_inst.  Foom.  It won't boot.  This is why the file
says it shouldn't be edited, even if there are very good reasons to do so.

> Certainly none can even cause a crash that would leave the system
> unbootable at least to single-user mode.

A SunOS system without a valid /etc/path_to_inst file will not boot
single-user.  I think the kernel will panic long before then.  The system
will probably even get nervous if you attempt to load or unload a kernel
module before rebooting, on a system without /etc/path_to_inst.

> And if you think you can cause irreparable damage by accident while

Technically speaking, there is no such thing as irreparable damage, as the
number of states in which a digital computer can be is a finite (albeit
large) number.

> 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.

You'll not cause any damamge at all by filling /usr, so long as /usr is
not on the / slice.  This is my entire point.

> 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.

I can think of at -least- two more.  And losing /etc/shadow will make
booting single-user very interesting, unless that has recently been fixed.

> But if you've miss the error from your editor when it fails to write
> out the file

There is at least one vi workalike which will truncate the saved file
before attempting to see if the filesystem will hold the replacement file.  
I think it's elvis, but I'm not sure.  Whichever it was, it was removed
from the system I was adminning after some idiot caused the exact problem
I'm mentioning.  Said idiot quit the editor, thinking that his changes
were not saved and that nothing was modified.

This was the same idiot who used pico to edit DNS zones, and then wondered
why named refused to load them.  I don't know what he had (still has,
probably) against standard vi, but I've never seen him use it.

> 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.

Or, you could partition /usr separately, and give more space for / than
you'll ever need (I usually give it 64 megabytes, 128 if I'm feeling
particularly generous/paranoid).  That:

  1) Avoides this entire problem and the associated downtime.
  2) Has no negative impact on system administration, except for the loss
     of one partition table entry and N megabytes for the root slice.
  3) Is fully supported by every OS worth running (even IRIX, after
     appropriate frobbing).
  4) Doesn't cause cancer in laboratory animals.

> (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

Truncate it to zero bytes, but leave /etc/passwd intact.  Everyone's
account is suddenly locked, and some of the password-manipulation tools
will dump core.

> > 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?)

On production machines where no new software gets installed, except on a
stringent upgrade schedule, yes.  There's no need for /usr to be mounted
read-write.

On development/experimental machines that get upgrades much more
frequently, no.

Strictly speaking, -today- I do neither, as I left my position at that
company, and have only SGI servers and one Sun workstation here.  But, as
of two months ago, that was my policy, and it treated my customers quite
well.

> and is that worth the danger of having a totally unbootable system if
> the tiniest thing goes wrong with /usr?

What?

If /usr is dead, the system will refuse to boot regardless of which slice
/usr lives in.  Putting it in a separate slice and mounting that slice
read-only will -prevent- damage to that filesystem in the event that the
filesystem is ever unmounted abruptly.  This is the entire point of
mounting it read-only.

I have never had a system go unbootable with / and /usr in separate
slices.

> this really is a case where putting all your eggs in one basket is
> less risky.

Yet you're -advocating- dumping both slices into one basket, instead of
letting them remain separate as good practice dictates.

--Jonathan