Example of a careful runlevel script

Dagmar d'Surreal dagmar.wants at nospam.com
Sat Jun 21 18:40:36 PDT 2003


On Fri, 2003-06-20 at 16:10, Michael A. Peters wrote:
> On Fri, 2003-06-20 at 10:18, Dagmar d'Surreal wrote:
> 
> > 
> > Frankly, Michael, I don't care what you think because it's pretty
> > obvious you don't.
> 
> Don't let a disagreement we had on another issue turn into something.
> I do think. I think quite a bit.

1. This is the same issue it's always been.  You fail to see the problem
with attempting to spawn something from inittab without doing sanity
checks first, and then you make irrelevant and unrelated arguments while
attempting to disprove the shortcomings of the opposing viewpoint. 

2. Then think _more_.  The level of skill you've been demonstrating so
far tells me that you work in either a non-profit or college computing
department as an intern, if you do any professional system
administration at all.  I can only hope you will eventually learn that
there's a _lot_ of difference between theory of operation and what
actually comprises a working approach in an actual computing
environment--All these little things that didn't seem to be a problem
when you were managing six machines would have you working 36 hour days
when you apply the same techniques to managing 100 of them. 

> >   FS corruption can destroy files for good, an admin
> > can restabilize the filesystem, and then it would be perfectly
> > acceptible to mount /usr rw in unrlevel 3, particularly because it's a
> > little hard to identify and *replace* missing/broken files on a
> > _read-only_ filesystem.  Geez.
> 
> When an admin does that they will be doing it manually, not booting into
> runlevel 5.

You're right, the admin won't be doing it--the *machine* will be doing
it because administrators can't be there all the time.  If you insist on
throwing out "the admin will do it manually" as a solution to
everything, you will never be able to manage more than 20-25 machines by
yourself.  

Here's a nice rhetorical question for you... if two admins each have to
fix a production machine that's lost a few libraries after a powerfail
condition, and one brings his machine down and restores a backup over
the network to fix the problem, and the other one uses the package
manager on the machine to figure out which files are missing and replace
those files (which is something one can easily script... Hi there IBM!) 
which admin will be keeping their job during the next round of layoffs?

Sitting and staring at the console while a backup runs might make dim
bosses think you're doing a lot of work, but *smart* bosses will not
care how you do it or where you are when you do it so long as you get
results with alacrity and the office can get on with their "real"
work... plus, they'll expect you do be able to do multiple things at one
time.  

> When repairing a filesystem, I always boot from a floppy or CD.
> Connect to network to retrieve backup. I suspect most do the same -
> rather than booting into 5 or 3 on a filesystem that they know has a
> muffed up /usr/lib.

So what part of the fact that if runlevel 4/5 has been reached, then
fsck has declared the filesystem sane enough to mount rw has eluded you
this time?  If fsck has somehow made the wrong decision, then you need
to fix the scripts you're using to mount all your filesystems so that
the higher runlevels are never reached.  This whole mindset that you've
got which seems to indicate you think there'll always be an admin
present when a machine boots up is /broken/.  Thinking like that will
keep you from ever being able to effectively manage more than 20 or so
machines by yourself.

Anyway, I've fixed the typo in my plonk filter now, and clearly you're
more interested in worshipping at the altar of RedHat (if you had any
idea how many times I've chewed their people over some of the things
they do...) than seeing the flaws in your own techniques. so I hope you
have fun driving around putting miles on your car to fix things at the
console, and jumping like a jackrabbit at the buzz of a pager.  I'll
stick with hardening my machines to recognize problems and handle them
appropriately without me.
-- 
The email address above is just as phony as it looks, and for obvious reasons.
Instant messaging contact nfo: AIM: evilDagmar  Jabber: evilDagmar at jabber.org

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list