1. System Administrator Peeves
Some might call them Best Practices, but I just call them good taste.
-
Be sure brain is in gear before engaging fingers.
-
Take the time to understand the problem you're facing.
-
Take the time to fix something the Right Way instead of using duct tape.
-
Use native facilities where possible.
-
Follow the general principles of the
![[WWW]](/wiki/nakedape/img/moin-www.png)
FHS, even on non-Linux systems. In that vein, there are a few sub-points:
-
Don't clutter / with mount points, symlinks or other droppings.
-
Try to keep /usr and /usr/local read-only.
-
Usually, root's home directory can be moved from / to /root on systems where that isn't the default. Do it. (NB: I know it works on AIX; not sure about Solaris, HP-UX, etc.)
-
Choose reasonable and sane names.
-
Choose hostnames with care.
-
Maintain as much consistency between hosts as possible.
-
Look for similarity and exploit it. As an example that meets both this and the previous peeve, if you have four hosts that will all be running, say, Sybase, each with a separate volume group for the database, name the volume group something like sybasevg. Having them all the same, rather than sybprodvg, sybreportvg, etc. means that you can run the same command across all of the systems (and you will likely need to), but avoid too generic names like datavg or vg00.
-
A tool like
cfengine can help.
-
Don't muck with the base OS.
-
If you must muck with the base OS, do it the Right Way--with packages. It is sometimes possible to upgrade or augment the base system with packages in ways that do not conflict with the base system (although not fool-proof--they can conflict with major updates).
-
Package 3rd party applications, especially F/OSS applications.
-
Know how you built a particular application.
-
Upgrade by downloading a new source tarball and updating the build spec.
-
Determine what version you have installed.
-
Determine whether the installation is consistent or has been tampered with (not a good substitute for host-based intrusion detection, but will reveal when other admins have been bad).
-
Install the same package on multiple systems without unnecessary fuss.
-
Let your users choose their own usernames and e-mail addresses, within limits.
-
Sometimes there are system limits to abide by, but usernames should always be lower-case and for the most part some combination of letters, digits and underscores.
-
It's good to have a recommendation, because most won't care.
-
A user will have to type is username several times a day. If he hates his username, he'll hate you and the organization with the stupid policy that forced it on him. If he likes it or doesn't care, you'll never enter his thoughts. Some users might not want their surname to be made known to people outside of the organization, because that more immediately identifies them and is easier to look up in a phone book than just a forename + initial. Sometimes the chosen algorithm yields an unacceptable name. My friend
Chris Chen was assigned the name chenc at Reed and he managed to convince the sys admin that it sounded too much like chink, which, being Chinese, he could find offensive. I got stuck with cooleyw (which I still get stuck with at some places).
-
A partially-maintained convention may be worse than no convention at all.
-
Reed was foisting these misbegotten usernames on us because they had the idea that then usernames and home directories would sort by surname. The problem was, most of the users did not have this format, so it was not only useless, it pissed people off. There were pretty much always going to be "legacy" users with the old format. The problem is that the expectation of consistency will lead to unexpected and embarassing errors.
-
Follow conventions and best-practices for writing scripts, without good reason to do otherwise.
-
Include a she-bang line on the first line. (Yes, I've seen people who didn't, until instructed otherwise.)
-
Include a few comments at the top of the file indicating it's use, who wrote it, when you wrote it, etc. Here's a template I often use:
#!/bin/bash # # foobar - Add foo to the bar. # # Written by Wil Cooley <wcooley@nakedape.cc> # Began 16 May 2006 # # $Id$
-
Damian Conway's Perl Best Practices is great for Perl; much of the advice (especially the coding conventions) applies to some degree across most scripting languages.
-
Use some sort of revision control. Ideally, your whole network will be managed with a configuration tool from a central repository, but all-too-often the costs involved with such a migration are high or planned in the future--but even using RCS is an improvement (see also my RcsIntro).
-
The original cliche is mouth instead of fingers, but for a sys admin, the word fingers is more appropriate. The things you type will have a surprisingly large influence on the quality of your life and the lives of others.
-
Often thinking through the problem you are experiencing will solve the problem more quickly and clearly than trying random stuff. Rarely is restarting a whole application, let alone a whole host, the best solution to a problem.
-
It's not always possible, particularly not the first time around or with production systems outside of maintenance windows, but it's usually for the best and will save time in the future (not to mention that it's usually more interesting).
-
For example, on UNIX systems that support SysV-style init scripts, use those instead of trying to create a /etc/rc.local, which has been deprecated for ages now. On AIX, it might be more appropriate to use the SRC (although SysV-style init scripts are still acceptable).
-
Sometimes system utilities will generate names based on templates; sometimes the names are appropriate, sometimes they're bizarre and sometimes a less generic name might be more appropriate.
-
Give near-end hosts (that is, hosts that people will be logging into intentionally) pronounceable names. Names like lnxr001, lnxr002 are fine for a compute cluster, where each host is more or less generic and only the people taking them down for maintenance will care. However, if the hosts have a wider audience (such as developers), then a name like lancer or vega will be much easier to talk about when the end-users come complaining. "
RFC 1178 - Choosing a name for your computer" is an excellent but underrated treatment.
-
When OS patches or updates get installed, they will probably overwrite your changes.
-
For example, RHEL3/CentOS3 only ships with Python 2.2 and some newer applications require Python 2.3 or 2.4. So, I've packaged 2.4 and only had to eliminate /usr/bin/python from the add-on package (it is inconvenient to have to use /usr/bin/python2.4, but it's not difficult). The 2.4 package works alongside 2.2, so nothing using 2.2 is affected. Of course, not everything works this easily; man pages or /usr/share data would cause more problems.
-
You will find it helpful to in the future to :
