10 Dos and Don'ts To Make Sysadmins' Lives Easier

CowboyRobot writes "Tom Limoncelli has a piece in 'Queue' summarizing the Computer-Human Interaction for Management of Information Technology's list of how to make software that is easy to install, maintain, and upgrade. FTA: '#2. DON'T make the administrative interface a GUI. System administrators need a command-line tool for constructing repeatable processes. Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line.'"

Comments

i am impressed

[digitalsushi]

10 is an even number. There's no duplicates. None of them are filler.

I don't understand how this happened.

Did someone plan this before they wrote it? What gives?

Re:i am impressed

[fuzzyfuzzyfungus]

There is a special place in hell for vendors who sell bulk licenses(50+ seats) for software whose DRM prevents automated installation, and requires that the IT office's picker of the short straw go around and type in a gigantic license key on all machines.

If a hole has to be punched in the firewall for the online activation/authentication step; because they were just too damn special to use SSL on a standard port like everybody else, that special place in hell is filled with screwworms.

If there is a hardware dongle component(that looks exactly like a USB flash drive, and thus wanders accidentally if not carefully hidden) and requires a new purchase order and a nasty pile of cash to replace, that special place in hell automatically inserts bullet ants into the scrotum of anybody placed there.

Holy crap, a slashdot first

[subreality]

It's a top-10 list that actually has insightful information on how to do software right, instead of being a random collection of ten things to make a fluff article. Bonus points for being things that I actually agree with.

The Practice of System and Network Administration

[XanC]

The article author is also behind The Practice of System and Network Administration, truly an excellent text into the practicalities of work in IT.

#11: Meaningful error messages

[eln]

If you want to make a sysadmin's life easier (as if any programmer ever wants to do that), you can start by making your error and status messages 1.) plentiful and 2.) easy to understand. Also, provide several logging levels so we can drill down as needed, and make sure the logging levels are meaningful. Too many programmers put just two log levels: one which shows nothing useful, and another that spews out indecipherable hex dumps of every call it makes.

Face up to the fact that no matter how awesome your software is, it's going to fail. Not only that, but it's going to fail in ways you never thought possible at the worst possible times. Make sure we have enough information to figure out what happened. Otherwise, stuff like this happens:

Program: *crash for no apparent reason*
Sysadmin: Why did you crash?
Program: Because something went wrong.
Sysadmin: What went wrong?
Program: Something.
Sysadmin: I need more detail. Increasing log level.
Program: Something bad went wrong.
Sysadmin: I need more than that. Increasing log level again.
Program: Fuck you. Here's a 16GB hex dump of system memory. Figure it out yourself jackass.
Sysadmin: *picks up a crowbar and goes off to find the programmer*

Re:#11: Meaningful error messages

[Monkeedude1212]

That reminds me of a Web Developer I once knew.

He said he didn't bother putting try/catches around certain standard things (Like Database connection opening, closing, transactions, etc) - because if anything ever went wrong it was easier for the user to take a screenshot of the Stack Trace if and when it went wrong from the Webapp. Said it took too much time to build in proper exception handling and error messages.

He said that the user experience basically means nothing if your application doesn't work, so when something doesn't work, don't bother making it pretty.

He no longer works here, though I can't imagine why.

click-wall.

[nblender]

Don't make me use a real browser to click all the way through your site, make me agree to a stupid set of conditions for using the software, and then provide my browser with a cookie that it can subsequently use to download your software; when my browser is on one continent and the machine that wants the software is on another continent; you ass-fucks...

That's plain ASCII to you...

[sl149q]

> DO have a configuration file that is an ASCII file, not a binary blob.

And by ASCII we mean something that can be edited by any editor.

XML is the equivalent of a binary blob when you are up to your ass in alligators trying to get things working again with minimal tools available.

I disagree on the GUI

[Zarhan]

...if the GUI is well done and complements command line.. Some tasks actually ARE much better performed with Point&Click.

One example of a "good" GUI that I use a lot is the ASDM for Cisco ASA firewalls. Most of the simpler admin tasks are in fact *faster* via ASDM. If you have your network objects all properly set up and you need to add a firewall rule, it's far simpler to select it from a list (actually, in this case it's a combobox - just type first few letters to filter your choices and then click) than typing that stuff in manually. Packet tracer to check the rules is much nicer to use via the GUI. Setting up VPN profiles is simpler via ASDM. Handling network object groupings is simpler via ASDM.

Editing access-lists, doing routing configuration and most of the more "rudimentary" tasks are still something I do via command line, though.

Re:I disagree on the GUI

[Qhartb]

I think it's more a matter of not making a GUI instead of a command line interface. Making both is, of course, perfectly fine, so long as the CLI is fully-featured and reasonably usable.

Re:fucking apostrophes, how do they work?

[blind monkey 3]

I thought they just followed Jesus around.......

Windows CAL cost

[tepples]

From the article:

8. [...] Similarly, use the operating system's built-in authentication system and standard I/O systems.

This can be a bad thing if your application runs on a platform whose built-in authentication is a nickel-and-dime revenue stream for the platform's publisher. Microsoft Windows Server is like this: each user account on the built-in authentication system requires a Client Access License.

Amendment to #2

[c 0xFF]

Feel free to make a GUI for the administrative interface, but not at the expense of an underlying CLI.

There are two ways to do this: have your GUI call the CLI when necessary, or use a common API behind both. Other methods will lead to bitrot in one of the interfaces, most likely the CLI.

GUIs are fine and even enjoyable to a certain extent, but the author is right that the CLI takes priority.

Re:fucking apostrophes, how do they work?

[daremonai]

"sysadmins' lives" is correct. It is referring to the lives of sysadmins.

No, I'm sorry, it is not correct. Sysadmins don't have lives.

Eventlogs

[Spad]

In reference to point 8, this is something I wrote I while ago after dealing with several Windows apps that either horribly abused the Eventlog or refused to use it entirely:

• DO create your own event message DLL(s) where appropriate to avoid your events looking like this
• DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.
• DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0×8003387 means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.
• DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.
• DO make your logging level easily configurable by the user and DO set a sensible default.
• DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.

#1 big dont

[MrLint]

Do not assume that your software is running with elevated access... (root/administrator)

Re:It's noce to know

[swordgeek]

A GUI is NOT fine for administering a broken system over a slow link to the other side of the world.

I used to remotely administer a set of servers in the middle east. The bandwidth was tiny, and the latency was insane. I would type a command out, then take a sip of coffee while waiting to see it displayed before hitting "enter." I had to use a GUI for one application, and it took over 40 minutes to fire up and display on my machine.

Mandatory (and well-designed) GUIs should be for using an application, not administering or installing it.

Re:1 Do for being a user

[skarphace]

I wonder if there are forums on the Web where plumbers shit all over eachother.

Re:1 Do for being a user

[jombeewoof]

I disagree,

take any person of reasonable intelligence and place them in an unfamiliar settting. They become retarded.
The fact that they have been in front of that unfamiliar device for 20 years means they just don't care.

Give me a user who cares to familiarize them-self with the system and 6 months, I'll give you a half decent sysadmin. At least better than half of the paper certified MCSE's I've had the pleasure to work with.