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.

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.

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.

#1 big dont

[MrLint]

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