10 Dos and Don'ts To Make Sysadmins' Lives Easier 246
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.'"
Re:i am impressed (Score:4, Insightful)
Not only that, but I'd say almost all of them don't just apply to making admins of large networks' jobs easier, but to ALL software development for any computer use.
#11: NO DRM, dammit!
Re:Summarizing (Score:2, Insightful)
In essence, all 10 items on the list say "Use Linux!"
Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P
Not really. The same problems exist in Linux -- authentication, logging, putting files in random folders (/var, /etc).
click-wall. (Score:5, Insightful)
That's plain ASCII to you... (Score:5, Insightful)
> 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.
Re:#11: Meaningful error messages (Score:5, Insightful)
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.
Amendment to #2 (Score:5, Insightful)
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:DON'T make the administrative interface a GUI (Score:4, Insightful)
GUIs are (sometimes) better when you want to do something *once*.
They really suck when you have to do that same thing hundreds of times. Which sysadmins do. On a regular basis.
Re:I disagree on the GUI (Score:5, Insightful)
Re:1 Do for being a user (Score:4, Insightful)
No.. the users are the ones who can't figure out how to use the system, that's why there's an admin.. if users knew what the fuck they were doing, we wouldn't NEED sysadmins in the first place.
If the system was designed properly for the userbase, so that users could use the system, you'd still need sysadmins to administer the system, which is notionally what sysadmins are for (hence the name.)
You wouldn't need sysadmins to take breaks from administering the system to handhold users through basic usage tasks, but then, that's not really the point of a system adminstrator in the first place.
Eventlogs (Score:5, Insightful)
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:
#1 big dont (Score:5, Insightful)
Do not assume that your software is running with elevated access... (root/administrator)
Re:Windows CAL cost (Score:4, Insightful)
This is why I hate having to deal with Windows on the side. In this aside about user CALs, there's three different takes (so far) on when you need a Windows CAL and when you don't.
I got sick of researching Windows Small Business server when I read their FAQ, and the section on licensing was longer than all the other sections combined!
10 years of personal experience... (Score:4, Insightful)
1. DO have a "silent install" option.
Silent install is nice, but so is an intelligent install, or a well thought-out, correctable upgrade process.
These systems do it well:
Debian and RedHat derived; Windows, post-2003. OS install is still a bit of a bitch with Windows. The upgrade process for MediaWiki is also stupid easy and effective (basically: untar new tree and run db alter scripts).
Poorly:
FreeBSD, and, really, most BSDs, are horrible for upgrading. I suspect OS X is similarly stupid when it comes to "promptless installs". Cacti, likewise, is awful.
2. DON'T make the administrative interface a GUI.
A useful amendment to this is: don't make the administrative interface shitty. GUI is fine, as long as I can leverage it progmatically. CLI tool is great, as long as it's fucking documented and not obtuse.
Case in point (in opposition): MegaCLI, for MegaRAID cards. Absolute. Shit.
3. DO create an API so that the system can be remotely administered.
An API is great, and allows for programmers to dig in and extend the product. I'm thinking of VMWare, XenServer, and Virtualbox right now. The latest Windows versions with PowerShell and the management consoles are not a bad combination of usability/power/utility.
Most sysadmins don't have the time to dig into the API, though, so a good initial tool that isn't terribly dense or limited in functionality is a must (XenServer, please improve your shitty-useless UI on xsconsole and XenCenter; I'd like a little more access to my VM disks without digging into lv/pv commands, too).
4. DO have a configuration file that is an ASCII file, not a binary blob.
No argument here. Likewise, configuration should be human-readable and not have vague incantations.
Good: samba, and all tools which use similar configuration syntax.
Bad: sendmail is the worst offender I can think of at the moment. I'm sure all the djb* stuff, too.
5. DO include a clearly defined method to restore all user data, a single user's data, and individual items (for example, one e-mail message). The method to make backups is a prerequisite, obviously, but we care primarily about the restore procedures.
Good: any UNIX system and it's $HOME; modern Unix MTAs like Courier.
Bad: Cyrus IMAP. Pretty much any tape archive system comes close to frustrating as hell. Windows still has a long way to improve until it's capable of Unix-style $HOME utility.
6. DO instrument the system so that we can monitor more than just, "Is it up or down?"
WMI is great. SNMP on Unix/Linux hosts, not so much, due to the configuration and divergence involved. Most OEM Linux/Unix based machines or systems (XenServer) are relatively shitty in this regard, too.
7. DO tell us about security issues.
Telling us about them is great, but upgrading these things are the most important, time-sensitive upgrades we need to make, so they should also be the easiest. We should not have to break two-three different things just to get the upgrade done.
BSDs are bad about this; horrible, even. The time consumed by a simple upgrade is enormous.
Linux is mediocre, but better than most.
Windows, in this case, "just works". Except when it doesn't (though I'd argue the degree is no greater than, say, the Linux upgrade process). Your biggest cost will be when it installs something you've explicitly told it not to (*cough* new IE versions) or in bandwidth and/or uptime requirements.
8. DO use the built-in system logging mechanism (Unix syslog or Windows Event Logs).
Something which doesn't do this isn't even worth looking at. It's yet one more thing to manage and uses exponential
Addition: make your logging sensible, please. I don't want to see a full trace of everything in the logs and not be able to configura
Re:1 Do for being a user (Score:5, Insightful)
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.