Unix sysadmins generally lead very busy lives, but there's always room to be more effective and make better use of the time you have. Here are 14 things to do, not do or improve in 2014.
Be ever vigilant. The threats to our systems get worse every year and Unix systems are not as immune from attack as many of us would like to believe. Learn the basics of Unix hardening. Many have been around for decades. SansFire offers some great classes and there are numerous resources online. I'll be reviewing some hardening techniques in this year's postings. Use SELinux if your distribution supports it. It provides a strong security defense with remarkably little effort on your part.
Be on the lookout for signs of compromise on the systems you manage. Find a way to review log files that helps you notice unusual things so that problems don't sneak up on you. If you don't have funds to buy a pricey log file analyzer, prepare a script or use one of the fine free tools like logwatch -- a general-purpose log file parsing tool (a package of Perl scripts) to provide routine stats so that you have an idea what's going on even when nothing seems to be malfunctioning. In any case, don't ignore your logs! I can't tell you how many times I have helped someone track down a problem only to find that there were signs of trouble showing up in their log files for months before they noticed anything was wrong. Try to spot the unusual, to recognize what's normal and what's not.
Use iptables or some other reliable firewall on your Linux systems. Limit access to your critical servers. Pay attention to your firewall rules. Make sure only the required ports are available for access and only to the systems or subnets that require them. Block everything else.
Change your passwords and ensure your users change theirs. Stop using the same password for every system you manage. Both Linux and Solaris systems offer password complexity as well as password expiration settings that prevent your users from setting themselves up with weak passwords. Use them. Stop logging in as root. Use sudo, customize your sudoers file so that it works well for you. Take the concept of least privilege seriously.
Don't use pipes when there's a command option that does the same thing. No, the milliseconds you save on most commands won't make much difference, but your commands will look better and work better and you'll be more efficient on the command line. Read a man page now and then and try some of the options that you've never used. It took me years to realize that I didn't have to grep word myfile | wc -l, but could use grep -c word myfile instead.
If you don't prepare scripts to make your job easier, start doing so. If you do, make sure your scripts are documented and easy to find. No point writing a new script from scratch if you can reuse clever code from an existing one. Include enough comments in your scripts that several years from now, you or someone else can easily figure out what even your most complicated commands are supposed to be doing. A few comments can save you a lot of time in the long run.
Patch your systems periodically. If you can. configure your software to automatically install security patches. Attackers aware of recently discovered exploits will be trying to get to your systems before you patch away their access. So don't be slow to respond if you can help it.
An old boss of mine used to describe the process of spending so much time keeping track of what you're supposed to be doing that you get little else done as "thrashing". Simplify the process of keeping track of your tasks so that you can more easily focus on one thing at a time. You might be surprised by how much time you save.
Stop doing so much busy work. Studies (such as one published in the Harvard Business Review in September 2013 called "Make Time for the Work that Matters") have shown that knowledge workers, including people like us, spend on average 41% of our time doing things that aren't gratifying and could be delegated to someone else. Spend more of your time planning what you intend to accomplish and setting priorities.
If you have the option, delegate tasks that someone else (maybe someone less skilled) can do and focus more on those tasks that truly require your expertise.
Periodically verify your backups as well as your disaster recovery plans. Don't wait until a disaster strikes to see if you're really ready to react. If you do, you might find out that, in an emergency, you're not as ready as you expected you might be. This readiness requirement also applies to preparing for a security breach. You might have a pile of plans, but if they're not tested and you're not practiced, it could take a long time just to figure out what you're supposed to be doing, who you're supposed to notify, what you evidence need to preserve, etc.
Keep acquiring new skills. After decades of being a devoted Unix user, I'm still learning new tricks and new tools. If you're not sure what to study, browse some job announcements for positions that sound interesting to you. You're likely to find some nice lists of required skills attached. They might point you toward some areas of focus. Always be learning something new. It's not just good for your continued job prospects; it's good for you and can be quite motivating.
Be versatile. Learn more than one distribution. There are some major differences, not just in the desktop, but in how the systems boot. Make sure you can move from one Unix system to another without a major setback.
Make time for exercise -- sitting at a keyboard all day is bad for you. Add a significant commute and it's really bad for you. Get up and walk around now and then. It will actually help your brain work better and enable you to get more work done. Besides, it's beneficial to your overall health. Reading "The Healthy Programmer" (Joe Kutner, The Pragmatic Programmers) this last year helped me to realize that I've spent the last 30 years doing myself a disservice by being such a sedentary dweeb. You can feel better and work more effectively if you're not sitting still ten hours a day.
This article is published as part of the IDG Contributor Network. Want to Join?