Slashdot Mirror
Top 10 System Administrator Truths
Vo0k writes "What are your top ten system administrator truths? We all know them already, but it's still fun re-telling them. Stuff like "90% of all hardware-related problems come from loose connectors", even though you already know it's true, may save you from replacing the "faulty" motherboard if you recall it at the right time."
It's interesting that everybody seems to know these things, and yet they still get us. A couple months back, I went through three power supplies before I discovered the fact that I actually had a power cable that was going bad. You don't even think of things like how power cables can go bad, but they do.
Very well; let this abomination unto the Lord begin!
... even though it's better than it used to be, registry corruption is still the number one cause of boot failures in Windows XP. And the contents ntbtlog.txt and the Recovery Console are still horribly inadequate tools for fixing it...
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
1) Never believe anything anyone tells you: always test for yourself.
2) Always ask the dumb questions: is it switched on?
3) Reboot cures most things EXCEPT rm -r * when logged in as root
After that, things could get tricky.
-You shall be very pessimistic
-Make sure you can leave exactly like it was before you touched it.
-Dont fix what aint broken.
-Start from a known state of the system (switch off - switch on).
-Even you are genius level techie, follow the manual, RTFM.
-Dont reinvent the wheel. Compare with something thats working.
-Cables are not perfect. If something doesnt connect, check lower levels first.
-If its there, ther must be a reason. Never ever delete anything. Rename instead.
-You memory is not infinite. Write what you do.
In my Tech Support experience, I have found only three basic rules.
Rule number 1. People are stupid. This one is true of all people. Tech support, highways, shopping, whatever. This rule has been extended to cover just about any stupid thing that anyone does.
"Why did that guy just..."
"Rule number 1."
"Did she think she could get away with that?"
"Rule number 1."
Rule number 2. People lie.
Me: "Has the computer been restarted since the problem started?"
Them: "Yes..."
Me: "OK. Let's try restarting the computer now and see what happens."
Them: "What do you mean by restart?"
And when you add 1 and 2 together, you get 3. Sometimes, people are so stupid, they don't know that they're lying. You know these people. They're the ones who have "Windows 2000 XP" or "2000 ME." They're the people for whom "Nothing happens when I try to check my email. Nothing! Just this error message..." Not realizing that the error message is *exactly* what I was looking for. An error message is *not* nothing. Grr.
There is a fourth rule that also shows up from time to time:
Rule number 4. No good deed goes unpunished.
In the famous words of the leader of the Uruk Hai from his battle call at Helm's Deep in The Two Towers: "Grr."
I was thinking they were talking about "truths about system administrators", not "truths about system administration".
/home
/home
/etc/passwd, /etc/shadow, and /etc/group. (By hand, NOT with passmgmt.) Slaps on setuid bit; tells a nearby secretary to handle new accounts. Usually, said secretary is still dithering over the difference between 'enter' and 'return'; and so, no new accounts are ever created.
/home; mkdir "Bob's home directory" /etc/passwd
Anyway, for the benefit of those who haven't seen this (very old and long, but somewhat entertaining) email that was doing the rounds a while ago... disclaimer: someone else wrote it, and I don't know who.
KNOW YOUR UNIX SYSTEM ADMINISTRATOR - A FIELD GUIDE
There are four major species of Unix sysad:
1) The TECHNICAL THUG. Usually a systems programmer who has been forced into system administration; writes scripts in a polyglot of the Bourne shell, sed, C, awk, perl, and APL.
2) The ADMINISTRATIVE FASCIST. Usually a retentive drone (or rarely, a harridan ex-secretary) who has been forced into system administration.
3) The MANIAC. Usually an aging cracker who discovered that neither the Mossad nor Cuba are willing to pay a living wage for computer espionage. Fell into system administration; occasionally approaches major competitors with indesp schemes.
4) The IDIOT. Usually a cretin, morpohodite, or old COBOL programmer selected to be the system administrator by a committee of cretins, morphodites, and old COBOL programmers.
HOW TO IDENTIFY YOUR SYSTEM ADMINISTRATOR:
-- SITUATION: Low disk space. --
TECHNICAL THUG: Writes a suite of scripts to monitor disk usage, maintain a database of historic disk usage, predict future disk usage via least squares regression analysis, identify users who are more than a standard deviation over the mean, and send mail to the offending parties. Places script in cron. Disk usage does not change, since disk-hogs, by nature, either ignore script-generated mail, or file it away in triplicate.
ADMINISTRATIVE FASCIST: Puts disk usage policy in motd. Uses disk quotas. Allows no exceptions, thus crippling development work. Locks accounts that go over quota.
MANIAC:
# cd
# rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`;
IDIOT:
# cd
# cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` | compress
-- SITUATION: Excessive CPU usage. --
TECHNICAL THUG: Writes a suite of scripts to monitor processes, maintain a database of CPU usage, identify processes more than a standard deviation over the norm, and renice offending processes. Places script in cron. Ends up renicing the production database into oblivion, bringing operations to a grinding halt, much to the delight of the xtrek freaks.
ADMINISTRATIVE FASCIST: Puts CPU usage policy in motd. Uses CPU quotas. Locks accounts that go over quota. Allows no exceptions, thus crippling development work, much to the delight of the xtrek freaks.
MANIAC:
# kill -9 `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
IDIOT:
# compress -f `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
-- SITUATION: New account creation. --
TECHNICAL THUG: Writes perl script that creates home directory, copies in incomprehensible default environment, and places entries in
ADMINISTRATIVE FASCIST: Puts new account policy in motd. Since people without accounts cannot read the motd, nobody ever fulfills the bureaucratic requirements; and so, no new accounts are ever created.
MANIAC: "If you're too stupid to break in and create your own account, I don't want you on the system. We've got too many goddamn sh*t-for-brains a**holes on this box anyway."
IDIOT:
# cd
# echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" >
-- SITUATION: Root disk fails. --
TECHNICAL THUG: Rep
Seriously, anthropomorphizing machines is a powerful technique. It gives you an approximate but effective mental model of a complex system. "Primitive" cultures are not dumb when they attribute personalities to objects. Our brains are wired to use personality to predict complex behaviour.
My Mother had no technical skills or knowlege - but she treated the automobile like a pet. She was alert to the tiniest change in sound or vibration of the machine, and very often alerted my Dad to problems long before he was aware of anything. One time, driving across country, my Mom said the right front wheel "didn't sound right". We were cruising along at 70, and everything seemed fine. But she insisted, so my Dad pulled over and checked all the tires. No sign of a problem. He pulled the hub cap off the right front wheel - and noticed that the cotter pin had broken! A few more miles and the wheel would have come off. My Dad panicked, since we didn't have any cotter pins in his repair kit. But my Mom dug in her purse and offered a bobby pin. My Dad didn't want to use it, because it was the wrong kind of metal and would break easily. My Mom said she had more, so he put it in. That bobby pin took us another 5000 miles.
My Dad does all his own work on his cars - at least he did until he ruined the valves on his Honda Accord a few years ago. Now he lets a mechanic do some stuff for him. I learned to be in tune with machines from my Mom, and learned to fix them from my Dad. When designing file system software back in the '70s, the rhythmic sounds of the disk access mechanism was my best feedback on its efficiency. Those were the days of 14" disk platters.
1. Adobe products and antivirus cause the most software problems, but you cannot live without either.
2. Most computer hardware problems are the result of sticky rolls, janitors cleaning, computers being accidently kicked, or power failures. In that order.
3. When calling HP or Dell about anything other than servers, you will get bad tech support.
4. Three year warranties on individual PCs do not matter. On a system with dozens of computers, they pay for themselves.
5. There will always be a lower price. Get over it.
6. Phones cannot fail. Five nines of reliability is not good enough.
7. Documented organization of the network and supplies will save you more time than the knowledge a thousand certifications brings (which isn't that much anyways).
8. Researching and backing up information before beginning a project is the sign of a professional. So is spelling.
9. Soft operating expenses are always more expensive than hard operating expenses.
10. When working on a project, document everything. It is almost never needed, but if your coworkers know you have it, they will not try to screw you.
Hoist Number One and Number Six.
Cynical but true.
Do not befriend the users. Do not tell them what is actually going wrong. Never accept blame. Do not rush to complete requests.
Here are the reasons why:
If you befriend them, they will cease to be able to do the simplest thing without your help. This is fine if they're hot, but not if they're not.
If you tell them what is actually wrong, they will get it more wrong when they report it up the line, and you will be blamed for something. Instead tell the users something hugely general that will fit into that comfortable place in their minds.
If you accept blame, users will view this as a sign of weakness, and assign blame the next time, without waiting for you to volunteer.
If you rush to complete non-critical, non-it projects, users will use this as a performace benchmark, and you'll be forced to complete all of their projects first to avoid the appearance of slacking off, in the course of this you will have to ignore critical maintenance that can get you in real trouble later.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.