Forgot your password?
typodupeerror
GUI Programming Software Technology

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

Posted by timothy
from the sorry-dave-can't-let-you-do-that dept.
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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Re:i am impressed (Score:4, Insightful)

    by mcgrew (92797) * on Thursday December 23, 2010 @04:06PM (#34654332) Homepage Journal

    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)

    by Anonymous Coward on Thursday December 23, 2010 @04:19PM (#34654432)

    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)

    by nblender (741424) on Thursday December 23, 2010 @04:21PM (#34654448)
    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...
  • by sl149q (1537343) on Thursday December 23, 2010 @04:23PM (#34654468)

    > 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.

  • by Monkeedude1212 (1560403) on Thursday December 23, 2010 @04:36PM (#34654566) Journal

    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)

    by c++0xFF (1758032) on Thursday December 23, 2010 @04:42PM (#34654610)

    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.

  • by Chris Mattern (191822) on Thursday December 23, 2010 @04:50PM (#34654682)

    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.

  • by Qhartb (1311541) on Thursday December 23, 2010 @04:53PM (#34654710)
    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.
  • by DragonWriter (970822) on Thursday December 23, 2010 @05:54PM (#34655250)

    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)

    by Spad (470073) <<slashdot> <at> <spad.co.uk>> on Thursday December 23, 2010 @06:37PM (#34655608) Homepage

    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 [eventlogblog.com]
    • 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 (Score:5, Insightful)

    by MrLint (519792) on Thursday December 23, 2010 @06:40PM (#34655626) Journal

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

  • by quacking duck (607555) on Thursday December 23, 2010 @08:42PM (#34656474)

    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!

  • by CAIMLAS (41445) on Thursday December 23, 2010 @08:58PM (#34656604) Homepage

    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

  • by jombeewoof (1107009) on Thursday December 23, 2010 @09:24PM (#34656798) Homepage

    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.

I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen

Working...