paranoid mode invoked

[steven Burgess_2]

10 points for every decent reply with solution

Think of a command, the damage it could cause if it was invoked on the wrong server, the argument was wrong or you simply wanted to warn/request confirmation from the operator that they were about to do something that could possibly be destructive

ie

replace rm with rm -i in .profile

Regards

Steve

[G. Vrijhoeven · Accepted solution]

Hi Steven,

What are you planning? :)

What about a failing cd to the wrong dir and chmod -R ??? * or a chown

Or about a pvcreate -f on the wrong disk.

HTH,

Gideon

[Chris Wilshaw]

In most cases, it's going to require a wrapper script to verify the input.

newfs, either overwriting an existing filesystem, or a database raw log could have near catastrophic results

The old faves of rm -r, chown/chmod -R

dd (the potential to splatter your disks in 1 easy step) if your happen to point the "of=" option at a disk device

shutdown/halt/reboot/init 0

a "find -exec" executed from the wrong location with the rm command etc.

vipw/chsh/passwd -s (and related commands). Could lead to corruption in your password file.

I'll stop now, as I've scared myself.

[Mark Grant]

if just "> /stand/vmunix" will probably do it.

How about this "kill -9 1 1234" instead of "kill -9 11234". Just that little space is going to cause some problems. I think you can only solve that one at the kernel level.

"crontab -r" instead of "crontab -e" (they are next to each other on a us keyboard) Solved by never using either of them. Edit the crontab file and "kill -1 "

How about accidently changing "init:3:initdefault:" to ""init:6:initdefault:" in /etc/inittab. Could be very annoying.


This one could run and run but they aren't too pleasant to think about.

[Dietmar Konermann]

Setting the shell's noclobber open may be also advisable. (set -o noclobber, set -C)

I just talked to a customer who accidently pasted a 'll /etc' listing to a root shell. Guess, what happened if you look at the '>' characters involved.

Best regards...
Dietmar.

[Keith Bevan_1]

Steve,

"Have you forgotten the root passwd again !"

passwd root

Assign a new passwd & then close the connection without logging back in and checking the passwd change was as expected.

Solution:Procedural or get someone who has half a brain cell.
__________

"Oops I have no passwd file !"

cp /dev/null /etc/passwd & then logout.

Solution:make sure the file has the correct permissions otherwise fire the idiot who ran this command"
__________

"Oops there goes by system !"

rm -R /etc

Solution:alias the rm with rm -i in the profile or get those ignite recovery tapes out.

Keith

[John Carr_2]

Steven

I know someone who thought he was on his workstation and did a /etc/shutdown -hy now before leaving for the night. Unfortunalty he was logged into the main file server leaving a lot of people unable to work. Outcome he collected a P45, for those not from the uk he was dismissed from his post. Solution aways type hostname before shutdown or reboot. So simple and so effective.

[Bill Hassell]

Well, as you might expect, the solution is to never give out a root password and no duplicate UID 0 accounts. There are dozens of commands that are catastrophic as root:

dd
newfs
chmod -R
rm -rf
mv
pvcreate -f
rmboot
mediainit
adb

I would start by making root's prompt contain the name of the machine as well as the current and parent directories:

export PS1=$(hostname)--'${PWD##${PWD%/*/*}/} # '

And on incredibly important systems, always run destructive commands with another admin looking over your shoulder. Even then, run an Ignite/UX backup *before* the destructive command is issued.

[David Burgess]

This one works to change all the files in /home/dave to be owned by dave, but

*** DON'T TRY IT! ***

cd /home/dave
chown dave *
chown dave *.*
chown dave .*

It works in that it follows .. to / and recursively changes the all files on the server to be owned by dave.

Boy was I a popular guy!

next time

cd /home
chown -R dave dave

If you do it, pray you have a backup tape and claim that you are new to unix and are still learning. A long time ago now, but it still haunts me. I kept my job!

Regards,

Dave.

[Richard Darling]

I've been using Bill's idea for yeare - put
PS1=`whoami`:`hostname`\>:
as the last line in the profile.

That advice, along with alot of others, was given to me by a great CE from HP out of Boston, Bob Zanelli.
RD

[Edward McCouch]

My favorite was always:

lvextend. Oops, made that 8 Gb too big.
lvreduce. Oops that 40GB lvol is now 8Gb.

Never let anyone use lvm commands on production DB servers if they are even remotely sleepy or not operating 100%. The last thing you want to hear coming back from lunch is 'Hey, how do you recover from a bad lvreduce? Do you think anyone will notice?'

The response, incidentally, was 'let me hear you say "Do you want fries with that?" because your next career is going to hinge on how well you say that!'

[Kent Ostby]

Well, along with the usual "rm", shutdown is also a favorite of mine.

Another one that I've seen be a problem is when you have two machines in a serviceguard cluster and there is a disk on a shared bus which is used privately by one of the nodes.

The other node sees this disk as "available" and occassionally, an admin on machine B will use the "available" disk that is actually in use by machine A.

This is "bad" :-)

Oz

[Marlou Everson]

Doing an init 1 instead of init q gets people's attention. I'm not sure that there is an easy way around this one to make it safer.

Marlou

[Chris Vail]

One of the sneakiest ones I ever ran across was a self-imposed virus. (well, it was the other admin who accidently virused a productoin server).

He wrote a script that collected IO data in a continuous loop (Mistake #1: developing in the production environment). He forgot to put in a test condition to stop it at some point. He ran it in the background, decided he didn't like it, then deleted it and its data file (Mistake #2: he forgot to kill -9). He went home at the end of the day. A few hours later I got a call from the help desk saying the system was running out of disk space. I immediately blamed the Data Warehouse team (they had OLD files that they never cleaned up), and got them out of bed. The system continued to run out of space, but I couldn't find any files that were increasing in size. Every time it hit 95%, the help desk would again log a trouble ticket, and after the third time they got my boss out of bed. I would ask the DW team to delete some more files. They would, and the percentage used would then go down, but then slowly back up again.
I finally compiled & installed lsof to find out WTH had happened. His script was still running, still collecting data. But without a data file to write it to, it was filling up the filesystem without filling up the filesystem. lsof gave me the PID. When the process was thoroughly dead, the utilization dropped down to 25%.
The other admin was in the boss's office for a while the next day, with the door closed........I did not say A WORD, for there but for the Grace of $DEITY go I.
(later on, I did go, but for an entirely different reason--and there was much rejoicing)


Chris

[Michael Schulte zur Sur]

Hi,

killall is also a nice command.

greetings,

Michael