The Golden Rules of Sun Systems Administration

This month, Peter provides a hard-earned set of rules that can help guide systems administrators toward good systems practices. True-life examples show why these rules are so important.

When in Doubt, Reboot

As silly and hackneyed as it sounds, this is probably the most important rule. There are many circumstances when reboots are required, such as after installing kernel patches, and after making changes to /etc/system. There are other times when a reboot is debatable. In these instances, the correct decision usually is to perform the reboot. For example, I once made a simple change to a startup script and because it was so simple, I did not feel testing was necessary. A month or so later, the system crashed and failed to complete its startup. After much debugging, I found the change (that I had forgotten I had made) had an error that had caused the problem. It was then time to cancel those service calls I’d made for new hardware and systems patches.

One client was having a problem with software that had been ported from Windows to Solaris. The vendor recommended that we reinstall the operating system and all the application software, which would have been a multi-day project. Rather than reinstalling the software and operating system, we decided to take the Sun approach of debugging the problem. It turned out to be a bad Sun jumbo patch cluster, and backing down to the previous revision solved the problem and saved several days on the project.

Communicate with Users

Veteran sys admins realize that they are supposed to simplify the lives of users. Those who are going to enjoy long careers as admins take this to heart, and make decisions and recommendations based on usability, stability, and security. The antithesis of this rule is the joke I used to tell as a university sys admin: “This university job would be great if it wasn’t for the dang students messing up my systems.&