I also take advantage of log analysis tools like logwatch to help bring the more interesting events included in my log files to the surface for me or I build my own log analyzers in Perl and email the results to myself on a daily basis to be sure that I don't miss anything important. We're all too busy to read through our log files the way we would if we had nothing better to do, but ignoring them is never an option.
9: Issue a mkfs or format command without triple checking the target
A world in which small mistakes led to small problems and only really obvious big mistakes led to big problems would be a nice place to live, but that's not the world we inhabit. On Unix systems, putting one measly blank in the wrong place in a command (e.g., rm f * when we meant rm f*) or getting one character wrong when we issue a command to create a new file system (e.g., mkfs -t ext4 /dev/sda2 when we mean /dev/sdb2) can leave us with irate users and hours of work to put things back the way they were. These are times when we exercise the ten second rule. Stare at the command for ten seconds before pressing the return key. We know the rest of our day can depend on that brief moment of hesitation.
10: Edit a complex configuration file without making a backup copy
There's always vi's :q! but most Unix admins will make a backup copy of an important configuration file before we edit the original. Commands like cp complicated.cfg complicated.bak have been commonplace for as long as I can remember. If there's anything wrong with the modified file, we can always back up and start over again.
11: Forget that rm .* includes ..
Ever cautious of wild cards, Unix admins are very aware that the pattern .* matches .. along with .settings and .bashrc. We're likely to remove "dot files" as we like to call them with a command such as rm .[a-z0-9]* to be sure that we're avoiding .. and the disaster that would befall us if we started removing all the directories above our current location in the file system.
12: Reboot as the first option when resolving a problem
Unix sysadmins understand that Unix systems rarely need to be rebooted. I have in my decades of administering Unix systems encountered quite a few Unix systems that ran for years without a reboot. Of course, with occasional power outages and OS upgrades, this is something of a rarity. Even so, most anything can be accomplished -- including adding disks -- without a reboot and we generally know how to make that happen. When we feel compelled to reboot, it may be because we want to be sure that our systems reboot as expected to be sure that they'll reboot as expected when we're not around to watch.
13: Start file names with a hyphen
Just about every Unix sysadmin has run into a problem in which a file with a name that starts with a hyphen causes a disproportionate amount of confusion, so we don't start file names with hyphens any more than we include blanks in them. That would be just too much work! We know that we'd have to insert -- into commands (e.g., cat -- -dumfilename) just to look at these files and rm -- -dumfilename to remove them, so we avoid them altogether.
Unix systems administrators use caution in most everything we do. We're basically lazy and don't want to make work for ourselves. Besides, recovering from the same disaster more than once isn't fun. So we learn from our mistakes and are well aware of the many things that can go wrong when we're making changes on the systems we manage.
This article is published as part of the IDG Contributor Network. Want to Join?