I am about to admit, in public, to doing something extremely boneheaded once. Why? I just finished reading Carla Schroder‘s article at LinuxPlanet titled Linux Works Even When Your PC is Committing Suicide. This article reminded me of my past foible and I decided to share it with you to make a point.
I have been a “Unix guy” for many years now. I started with SCO Xenix back in the late 1980’s installing and supporting SMB companies that needed Point of Sale and business accounting systems. Typically this would entail running Xenix on a server and dumb terminals at each desk or Point of Sale seat. From SCO Xenix these migrated to SCO OpenServer and SCO Unixware. Sometime in the late 1990’s I built my own in-house server to run SCO Unixware at my office as a file server. This worked quite well and did not cost me too much as an SCO reseller. I was able to get Not For Resale (NFR) copies of SCO products at a steep discount.
In the early 2000’s I was running IBM OS/2 on my desktops, one multi-boot PC with IBM OS/2 + Caldera Linux + Microsoft Windows 98 to run Quickbooks and the SCO server where all my company data was stored. After installing some updates on the SCO server I decided to go into the /etc directory where all system configuration files are stored and remove some old directories that were no longer needed. I had to login as root (system administrator) to do this. While in the /etc directory I issued this command:
rm -rf olddirectory/ *
Notice there is a space between the slash “/” and the asterisk “*”. I had pressed enter and eventually realized it was taking longer than I expected to remove what I thought I was removing, should have been about 2 seconds. By the time I understood my error and canceled the command almost all of /etc was gone. For you command line novices I will explain what I did wrong in the command used. I basically told the remove command, “rm”, to delete everything recursively in both “olddirectory/” and the current working directory by adding that unintended space after the slash followed by that asterisk. Yes, that is A Very Bad Thing as the /etc directory tree is a critical system directory under Unix and GNU/Linux.
Did this kill the system? Well, yes and no. As long as I did not reboot the system I was okay. Had I made the mistake of rebooting the system I would have had more problems recovering than I cared to have. The Unix system happily churned along with an empty /etc directory and I was able to copy all the company data off the server to a PC on the LAN, including the Quickbooks file that had all the accounting data in it. Then I could decide on staying with SCO, which was starting to make noises against GNU/Linux, or move to something else. I decided to move to FreeBSD on the file server and did so.
Eventually I migrated all the company desktops to GNU/Linux (Because IBM decided to “kill” OS/2, which is still not dead yet, and I wanted to future proof my systems.), began using GNUCash in place of Quickbooks (I don’t need payroll software for my small, family business.) and kept FreeBSD on the file server. I have been and am content with this change and will stay with this setup for the foreseeable future.
I consider what would have happened should I have deleted a critical system directory tree under some other operating system. I have serious doubts the other operating system server versions would have kept running for me to copy data easily over the LAN. I have no doubt whatsoever that a GNU/Linux system would fare just as well as that venerable SCO Unixware system I killed. To me this illustrates the high robustness of all Unix-like operating systems and just another reason why I will continue to use them.
This article has been accessed this many times:
|vocational schools guide|
Edit Thu Apr 23 09:24:43 CDT 2009: Oops! Somehow the setting requiring users to be registered and logged in to comment was on in our WordPress settings. Of course no one here knows how that happened and I know I did not check that box recently. Anyway, it is back to anyone can comment now. I apologize for any inconvenience this may have caused our readers. Gene