Today I have shutdown'ed a production machine by mistake because I thought I was on my local machine. I know, novice mistake :-(
As a solution for it not to happen again, I was thinking to remove the execution permission for the shutdown command as that machine should be always on.
Is that a good idea? Can you see any unwanted side effect by doing that?
Cheers, Dan
Completely another aproach how to be warned that you work on productional machine is to mark the terminal. For example the
user@machine:~#
text could be red at production machines, green at development, etc. Here is nice tutorial how to do this: Color Bash PromptThe best advice I can give you is don't login as root unless you need root access, and make sure you have a different root/sudo password on each machine.
Making shutdown inaccessible is one option but it's not a good one. Either alias
shutdown
toshutdown -a
andtouch /etc/shutdown.allow
orchmod a-x /sbin/shutdown
Also, where does it end? Are you going to also disallow halt, reboot and init?
Some points to consider:
I don't think messing with the permissions on
shutdown
are the way to handle the situation. Basically you just learned a lesson. Chin up.I've done the same kinds of things -- getting long chains of ssh sessions, then messing with the routes on one of the machines I was ssh'd through, cutting myself off. I've botched a rsync request, leading to a systematic destruction of a system on the other side of the world. I've run
rm -rf / path
on a production server. (That time I got to learn how the restores worked.)So, much older and hopefully a little bit wiser, I now have strict rules I impose on myself.
The nature of my job requires me to spend a lot of time at a lot of varied root prompts, but thanks to my errors in the past I maintain a far better situational awareness than I did when I started.
If you're using Ubuntu then try Molly-guard. As discussed in this similar question.
Depends, really. You could try just wrapping the command but it means that if you do updates or upgrades that affect that executable, you might forget about it and have it screw up an update. Playing with system shutdown commands can be a PITA, especially if you have new hires or a replacement that ends up not knowing you were playing with system binaries.
Personally I'd look at wrapping the command in a script that identifies the system by name and makes you confirm that's what you really want to do before running the actual binary, or that you have to type in a certain sequence of letters to confirm shutdown before it runs the binary. That should give some pause.
You might consider setting the command prompt to include the machine name, at least on servers. It just might help to prevent other commands being run on the wrong machine in the future. It's more effective if the machine names are coloured to make them stand out and you could even colour code to identify server roles.
One way is not to use
su
and/or login directly toroot
. Better to log into directly into the account AND have different password forroot
on local machine and ssh key.Of course it is in addition to watching for red '#' prompt.
Yes, removing the execute bit on the shutdown command is the simplest and safest way of preventing accidental shutdowns, especially if you have a desktop environment like KDE on the machine and you want to prevent accidental shutdowns when logging out.
As for new people being confused, I think the first thing they'll do would be
ls -l /sbin/shutdown
to find out why it doesn't work (especially if they have the good habit of tab-completing executable names). Obviously though you should tell them about any changes you've made.For extra safety you could add a line to
/etc/rc.local
to remove the execute bit from the shutdown command so you don't forget to reset it after a reboot.you can just remove /sbin/ from root's path. that way you need to type the full path to execute it, and it usually fixes accidents.