January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

System Administration


Download PDF version of this article
This and other acmqueue articles have been translated into Portuguese
ACM Q em Língua Portuguesa

ITEM not available


Originally published in Queue vol. 8, no. 12
see this item in the ACM Digital Library



Adam Oliner, Archana Ganapathi, Wei Xu - Advances and Challenges in Log Analysis
Logs contain a wealth of information for help in managing systems.

Mark Burgess - Testable System Administration
Models of indeterminism are changing IT management.

Christina Lear - System Administration Soft Skills
How can system administrators reduce stress and conflict in the workplace?

Eben M. Haber, Eser Kandogan, Paul Maglio - Collaboration in System Administration
For sysadmins, solving problems usually involves collaborating with others. How can we make it more effective?


(newest first)

Displaying 10 most recent comments. Read the full list here

Jim | Wed, 20 Jun 2012 05:57:54 UTC

DO have text configuration files and DO provide an editing tool if your test config file is fragile. e.g. visudo

Matthew Berg | Fri, 02 Mar 2012 14:10:41 UTC

A thousand times no to #8. Use a logging FRAMEWORK instead. In other words, log4j (or similar) and *NOT* syslog.

Peter Jeremy | Thu, 03 Mar 2011 20:27:04 UTC

A couple more don'ts: If your software interacts with hardware, it should accept that hardware occasionally fails and will need to be replaced. If I'm using your LVM to provide disk mirroring, I don't want the disk replacement procedure to begin "unmirror the logical volume and destroy the virtual device containing the failed disk" (eg Solaris Volume Manager) - this doesn't scale with virtual devices made up of multiple physical devices.

Also, your software shouldn't assume that there is only one instance of itself running on a host and rely on magic, undocumented sockets, ports or whatever, even for short periods of time. Oracle rdbms fails this test - starting multiple rdbms instances simultaneously leads to deadlocks.

Finally, do have your own configuration file, don't configure yourself based on the configuration for some other function, no matter how similar. You can have it default to that if you like but make it overrideable. Solaris IPMP fails this.

Rigs | Tue, 01 Feb 2011 15:23:03 UTC

Regarding point 6 I remember customizing a very lightweight proactive monitoring tool (before Quest Software convert it to commercial) mixing perl, python, awk and shell scripts called Big Brother (now BB4).

It was really helpful.

Paul Anderson | Thu, 27 Jan 2011 08:07:11 UTC

Interesting to see what's changed (and what hasn't) since 1992 :-) http://homepages.inf.ed.ac.uk/dcspaul/publications/Workshop_Report.pdf

Mark | Tue, 04 Jan 2011 14:03:09 UTC

Can't entirely agree with point 2 - I'd say have both a GUI and a CLI. Scriptability is good, but so is discoverability, particularly for small environments. The more hoops need to be jumped through to learn a product, the less likely it is a reseller will embrace it.

Robert Wipfel | Tue, 28 Dec 2010 15:39:36 UTC

Many of these recommendations appeared in Eric Raymond's "Art of Unix programming", about Unix (versus Windows) philosophy in general:


I would add two more; (1) for remotable APIs intended to support mass operation: do allow SSH and log everything (2) for scribbling on the disk; see Linux Standard Base (LSB).

Dan Cross | Mon, 27 Dec 2010 09:09:54 UTC

I'll go one further on configuration and automation:

DO (if it doesn't compromise security) use a pre-existing, text-based scripting language like Tcl or Python for configuration data. Using a full language (again, if it doesn't compromise security) opens up new worlds of possibility for a product.

DO provide bindings for a scripting language like Tcl or Python if you provide an API. This avoids the proliferation of badly constructed third party scripting language bindings that inevitably pop up. If you provide a remotely accessible API for administration, similarly wrap the protocol in some sort of module loadable in a scripting language; preferably, use the same language you use for configuration.

Christian Drexler | Fri, 24 Dec 2010 19:32:50 UTC

I have another one: respect and use the packaging mechanism of the platforms you are supporting! Don't give me a tarball containing a badly written script that copies stuff to random places but build a nice deb/rpm/SysV-pkg that installs without being --forced.

mathew | Fri, 24 Dec 2010 16:52:09 UTC

For server software on POSIX systems, include a standard /etc/init.d script to start and stop the software.

I'm looking at you, IBM.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.