When you shouldn't be root...

From the very first day of training to be a Unix system administrator, I was warned about the dangers of working as root on a Unix system.  There are some things that only root can do:  change system configuration files, add users, update the system.  But with great power, comes great responsibility.  The responsibility to know when you are too tired, too angry, or too distracted to safely use that power.  

I was working on our web server, a virtual machine where we control everything.  My website wasn't live yet.  There had been some challenges with getting all the modules installed into Apache and getting my site to see them.  When I still couldn't enable clean URLs for my content management system (CMS) but my sister's website could, then I decided to clear out the website root directory and database and start over.

My sister had gotten her website up the night before, and spent all day Saturday documenting her website, what the settings were for each area and copies of all her writing.  She's a very good technical writer and believes in backups and redundancy. And it was a good thing as the evening turned out.

I was working as root, necessary in this case, and knew I wanted to remove all files and directories under the document root directory.  I double-checked to make sure i was in the document root, and ran rm -rf ./*. This means to "remove everything inside this directory and don't ask me about it first."  I made sure to use ./* so I wouldn't delete anything else I didn't want to.  But after I hit Enter, something started bothering me. Just to be sure I was where I wanted to be, I ran pwd (present working directory) to verify which directory I was working in.  Oops!  I was in the document root directory of my sister's website.  

I let out an expletive, and then all was quiet in the house.  A discreet minute or so later—my sister really knows me—she came in and asked what happened.  I didn't spare myself or sugar coat it.  "I just blew away your entire website.  I was trying to blow mine away."  She said OK and went back to her computer.  I set her up with a clean install and let her know it was ready for her to set up.

An hour and a half later, her website was back on line.  Her documentation and backups had done what they were supposed to do—enabled her to recover from a catastrophic event.  Even one created by her sister.  And, bless her heart, my sister never got upset at me for my blunder.

I went on and "blew" my own site away and actually got a base install up within a few minutes.  After one more critical chore, I logged out as root, and as myself, and put myself to bed.  I was on a new distribution of Linux, and had been working while I was tired. Big mistake. It would be time enough to work on my site tomorrow.  

There are times when we all have to switch to the root user to do our jobs.  That will never likely change.  And there will be times when we have to do this when we're not at our best.  When that happens, think twice or three times before executing any command.  Some Linux distributions even come with rm (remove) aliased to rm -i, which means that every time you try to delete something, it asks you to confirm.

What was the critical chore that kept me on as root when I already knew I wasn't at my best?  Writing a backup script that would backup every website on the server!  When you're setting up a website, or have an active website, things change daily.  Weekly backups aren't enough.  So I wrote my backup script, debugging as I went, using echo statements to mimic the actual commands, triple checking that everything was as I thought it should be, and finally testing it.  Then I setup the cron job to run it every night and logged out.