Sysadmin Stories: Moral of these stories

by Stephen on October 19, 2009 · 0 comments

in Sysadmin Stories


From: (John Jarocki)
Organization: Advanced Micro Devices, Inc.; Austin, Texas

– Never hand out directions on “how to” do some sysadmin task
until the directions have been tested thoroughly.
– Corollary: Just because it works one one flavor
on *nix says nothing about the others. ‘-}
– Corollary: This goes for changes to rc.local (and
other such “vital” scripties.


From: (Eric Wedaa)
Organization: Advanced Micro Devices, Inc.

-NEVER use ‘rm ‘, use rm -i ‘ instead.
-Do backups more often than you go to church.
-Read the backup media at least as often as you go to church.
-Set up your prompt to do a `pwd` everytime you cd.
-Always do a `cd .` before doing anything.
-DOCUMENT all your changes to the system (We use a text file
called /Changes)
-Don’t nuke stuff you are not sure about.
-Do major changes to the system on Saturday morning so you will
have all weekend to fix it.
-Have a shadow watching you when you do anything major.
-Don’t do systems work on a Friday afternoon. (or any other time
when you are tired and not paying attention.)


From: rca@Ingres.COM (Bob Arnold)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501

1) The “man” pages don’t tell you everything you need to know.
2) Don’t do backups to floppies.
3) Test your backups to make sure they are readable.
4) Handle the format program (and anything else that writes directly
to disk devices) like nitroglycerine.
5) Strenuously avoid systems with inadequate backup and restore
programs wherever possible (thank goodness for “restore” with
an “e”!).
6) If you’ve never done sysadmin work before, take a formal
training class.
7) You get what you pay for.
8) There’s no substutite for experience.
9) It’s a lot less painful to learn from someone else’s experience
than your own (that’s what this thread is about, I guess ๐Ÿ™‚ )


From: jimh@pacdata.uucp (Jim Harkins)
Organization: Pacific Data Products

If you appoint someone to admin your machine you better be willing
to train them. If they’ve never had a hard disk crash on them you might want
to ensure they understand hardware does stuff like that.


Organization: Department of Computer Science, University of York, England

Beware anything recursive when logged in as root!


From: (Mike Matthews)
Organization: /etc/organization

*NEVER* move something important. Copy, VERIFY, and THEN delete.


From: (Squish)
Organization: Human Interface Technology Lab (on vacation)

When you are doing some BIG type the command and reread what you’ve typed
about 100 times to make sure its sunk in (:


From: Nick Sayer

If / is full, du /dev.


Organization: Wesleyan College

Never ever assume that some prepackaged script that you are running does
anything right.

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: