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.'"
1 Do for being a user (Score:2)
Re: (Score:2)
This one made my chuckle:
7. DO tell us about security issues. Announce them publicly. Put them in an RSS feed. Tell us even if you don't have a fix yet; we need to manage risk. Your PR department doesn't understand this, and that's OK. It is your job to tell them to go away.
My CEO asks me to whip up a web page that users can use to submit who their phone provider is (we were all given options and not tied to 1 vendor. That has its pluses and minuses) and how long they have left on their contract so that he can get an assessment of where the phone situation is at for upgrading people's company phones. He wants this about 5 minutes ago.
I spent the trivial 1 minute it took to make sure my text boxes were SQL injection proof - but I haven't bothered doing
Re: (Score:3)
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.
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.
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.
Re: (Score:2)
...except this isn't about "rebuilding an engine".
It's about DRIVING. You are operating on the false assumption that this is about how users can't be admins. No. They haven't even gotten that far. They can't even use the GUI that comes with the system. Nevermind anything any more advanced than that.
The average n00b computer user CAN'T EVEN DRIVE. Nevermind fixing the engine.
Re:1 Do for being a user (Score:5, Interesting)
I wonder if there are forums on the Web where plumbers shit all over eachother.
i am impressed (Score:5, Funny)
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 (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:i am impressed (Score:5, Funny)
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.
Re: (Score:3)
Dongles and the crapware surrounding them are only there to punish the innocent.
Re: (Score:2)
#11: NO DRM, dammit!
God, I really don't know how developers get away with "activation". I have had so many fricken problems with activation over the years that I basically won't buy or install software that requires it. So first, right there, it's costing sales. Of course I can't say for sure that it costs more sales than it creates, but I can tell you anecdotally that multiple companies have lost sales to me because of their activation policies.
Second, in a strange way it's actually encouraged piracy to some degree. At m
Re:i am impressed (Score:4)
To elaborate on #11:
#11: No DRM. The BSA would turn any company inside out and have their entrails for Christmas lights if they are caught pirating even a single copy of WinRAR. Businesses who value being open are not going to be pirating anyway. So why add DRM which removes value from the product?
#12: Ability to rebuild the product if it gets corrupted. Have it as an option to have the .cab/.bz2/RPM/.deb/etc. file stored in a directory, including patches. This way, if there is concern about registry/NetInfo/ODM/whatever corruption, it shouldn't be hard to have the product reinstall itself.
#13: An uninstaller. Shit happens and crap gets in a half installed state. It would be great to be able to have a utility that completely removes any and all traces of a program, move aside/archive config files, and rename the config directories. This way, if a config document is causing problems, it is out of the path.
#14: Ability to send reports to a third location, via E-mail or whatnot. This way, either by system logs or E-mail, there is proof that a package was installed or maintained, and not just the install mechanism; but from the application itself.
#15: Ability to install as a non-administrative user if the functionality is relevant (this wouldn't be doable for system utilities, but a Web browser, yes.)
#16: Ability to have a way to completely block installs of the product.
#17: All executables are signed. Not just with the OS signing mechanism, but either with a manifest, or PGP/gpg detached signatures.
#18: A "master console" program that can check for updates, store them, check installed clients if the update is needed, push out updates (either by a program or through the OS's install mechanism), perhaps even allow for removal en masse.
I just wish more operating systems had not just an install mechanism (msiexec, rpm), but an update mechanism from repos (yum, macports). This would make life a lot easier, especially if it can be configured from custom repositories so enterprises can have their own mirrors.
How to make a good top 10 (Score:3)
10 is an even number. There's no duplicates. None of them are filler.
I don't understand how this happened.
I know how they came up with a high-quality top ten: They had 13 or so, and they cut the weakest ones.
Re:i am impressed (Score:4, Funny)
No slashdot editors were involved in the production of the list. ;)
Top 10 (Score:2)
I demand a meta top 10. The top ten list of top 10 lists.
Its an acm.org article ... (Score:4, Informative)
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?
Its an acm.org article. Not only did the author probably plan, re-read and revise the article before submitting it but a technically knowledgable editor probably read it and may have offered useful and insightful suggestions. Now there may not have been a formal peer review process but the editor may have also had one or more experts in the field read it and offer comments and suggestions.
;-)
Yes the above seems an archaic process but consider that the acm is full of old people who had experience publishing back when things were done with dead trees.
Re: (Score:2)
I had 15 items and picked the 10 best.
fucking apostrophes, how do they work? (Score:2)
nt
Re: (Score:3, Funny)
"sysadmins' lives" is correct. It is referring to the lives of sysadmins.
Unless, of course, you are referring to the sexual practices of punctuation marks. Then, I don't know.
Re:fucking apostrophes, how do they work? (Score:5, Funny)
No, I'm sorry, it is not correct. Sysadmins don't have lives.
Re: (Score:2)
When you're already in double quotes you use single quotes for any quotes they used.
"Then Jim said, 'Hi', and that made Sally smile".
The more you know!
*didlidlido duuum!*
Re:fucking apostrophes, how do they work? (Score:5, Funny)
Re: (Score:2)
Quite well, actually. And at least in the title of this article, they're even used correctly.
Re: (Score:2)
Well, there's 4 cups in a quote, and 4 quotes in a gallon. If that's too complicated, we can just get rid of the quote and count 16 (10 hexadecimal) cups in a gallon.
Summarizing (Score:2)
In essence, all 10 items on the list say "Use Linux!"
Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P
Re: (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).
Re: (Score:2)
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).
The difference with Linux is that if you don't like it, you stand a decent chance of actually being able to do something about it.
Obviously that's sub-optimal. It would be better for vendors to soundly design their software in the first place. Still, open (in the sense of "transparent") systems make it much easier to actually mitigate such nuisances.
Holy crap, a slashdot first (Score:5, Interesting)
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 (Score:5, Informative)
The article author is also behind The Practice of System and Network Administration [amazon.com], truly an excellent text into the practicalities of work in IT.
#11: Meaningful error messages (Score:5, Funny)
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 (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.
Re:#11: Meaningful error messages (Score:4, Interesting)
Re: (Score:2)
I actually ascribe to your colleague's view. You really need to do your best to anticipate and handle all REALISTICALLY POSSIBLE error scenarios. But if something unimaginable happens, you probably do NOT want to:
A) Sweep it under the rug so that the user, and you, never even know it happened
B) Try to recover, i.e. perform complex tasks, while state is corrupted in unknown ways
Really, the important idea is to make sure the user knows something REALLY bad happened, and give the user enough information to re
Re: (Score:2)
That works both ways though. I kind of agree that crashes shouldn't be pretty - you don't want to make a serious error something you can just click through. If the nightly backup job failed I don't want a benign little error message presented to the user, I want something that will get their attention. And if that means blowing the application up so that Windows lets them know then so be it.
Crashing with a stack trace because you can't open the database, instead of MessageBox.Show("Could not connect to data
Re: (Score:3)
Sometimes you don't want to be quite so obvious about the error. They're good to log though. :)
On one of my sites, it's very dependent on the database working. Sometimes the database isn't available, say someone rebooted it during the middle of the day. Shit happens. Instead of throwing a nasty "Couldn't connect to database - timeout connecting to 192.168.229.11", it just says "Sorry, we are temporarily down. Please check back in a few minutes.". Of course, the nasty erro
Channeling Philosoraptor (Score:3)
if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
Re: (Score:2)
You describe what it isn't, based on the other exceptions you were designed to handle.
Narrows down the search/troubleshooting.
Re: (Score:2)
Re: (Score:3, Informative)
Which is a perfect example of a terrible error message. And there's plenty of bad examples like that to crib from, too. (In your particular example, sure, you'll have the "at line XXX" so someone can start digging around in the code... but that's something only suitable for quick-and-dirty hack scripts.)
What you need to know is WHAT, WHERE and HOW. You know WHO (the program), and are trying to figure out WHY. I've often had to resort to strace -etrace=file to find out "What file couldn't be opened? Why
Re: (Score:2)
C --- if (err 0) printf("Unexpected Error: some_method() returned %i\n", err);
C# --- catch (Exception ex) { EventLog.WriteEntry("AppNameHere", String.Format("Unexpected Error:\n{1}", ex.ToString()) }
There are better ways, but this at least gives *something*.
Re: (Score:2)
if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
By putting error messages in a ton of places you don't expect an error to arise, just in case (i.e. places where you expect the input to have been sanitized, add error messages for unsanitized input; places where you expect parameters to be in a certain range, check for them to be out of range and indicate which was out of range).
Re: (Score:2)
if it fails in a way that you never thought possible, how would you write an error message that describes the failure?
Well, if you (or, rather, the application code) know that it fails (IOW, if it hasn't failed at a level so far down that it just dumped core/GPFed/etc. without even signalling your code) then you probably know something about the context where the error occurred (what was in progress), what code module of yours received the error, and what the exception or other indication of failure you received from outside of your code to let you know that something was wrong.
Re: (Score:2)
Seems to be far worse for Windows applications than Unix ones, and worse for commercial rather than F/OSS applications.
I've no idea why this is, but I swear to God that Windows developers have no concept of logging. It really makes me wonder how the hell they debug the application - debuggers only ever go so far.
Re: (Score:2)
Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?
Re: (Score:2)
IME you're doing well if you get that.
There's at least a few apps I would like nothing better to get to speak to the dev team leader and ask them why, on FSM's sweet earth, they decided to do that. Was some deranged PHB involved or is there some sort of requirement that nobody can be hired to develop for Windows unless they point-blank refuse to log a single damn thing?
Re: (Score:2)
Are you saying that having a file under C:\Windows\ called "mytotallycoolapplicationlog.txt" - and writing "It worked :)" everytime the process is successful and having "It failed :(" Everytime it doesn't constitute a good logging procedure?
Windows does have a system logging facility, as in it's provided by the operating system. I have no idea whether it's as functional, but otherwise it's comparable to the syslog facility provided by Unix and Unix-like systems. Maybe I'm being fanciful but this is what I imagined when I read Jimicus' post.
Re: (Score:3)
as if any programmer ever wants to do that
Got that right!
Face up to the fact that no matter how awesome your software is, it's going to fail.
As any good programmer knows, failure is not an option. If software fails it is because of misuse, foreign (read "anyone who isn't me") programming staff, or failure to RTFM. Please do not bother us with your petty problems and See Figure 1 [dourish.com]. Understand this and your life as an admin will be forever simpler.
XOX,
Your most awesome programming staff
Re: (Score:3)
Please do not bother us with your petty problems and See Figure 1 [dourish.com]...
I couldn't help but notice that the last line of the linked article was, "Love VMS or leave it, but don't complain."
I guess we all got tired of being told to see Figure 1 and just left VMS... I haven't logged into a VMS machine in over 15 years.
Re: (Score:2)
God I love slashdot sometimes
Re: (Score:2)
At last, we know why Gordon Freeman was so handy with the crowbar... AND the most solid clue yet as to why Black Mesa went blooey!
Thank you, sir! You've done us a great service!
Re: (Score:2)
Re: (Score:2)
Or even worse:
Program: *crash for no apparent reason* ... "the operation completed successfuly"...
Sysadmin: Why did you crash?
Program: I didn't crash.
Sysadmin: What went wrong?
Program: Nothing went wrong.
Sysadmin: But there's an error message right there!
Program: No there isn't.
Sysadmin: Yes there is. Look. Right there in the logs where it says Error.
Program: And what does it say after the word Error?
Sysadmin:
"Error: The operation completed succesfully" is my all time favourite error message!
Re: (Score:2)
"This should not have happened"
message recently
Re: (Score:2)
wait...what? If you don't know what it is, what SW are you installing?
Re: (Score:2)
Re: (Score:2)
You thought wrong. This was most likely scaffolding (for himself) that he put up while looking for a bug, and that a he forgot to take out afterwards. Since he didn't take it out, that probably means he never found or fixed the bug he was looking for. BTW, the effort involved in putting up one of these messages is very low, it's much much lower than building a proper logging facility from scratch.
But why would you ever have to build a proper logging facility from scratch when there are several good, open, mature implementations ready for you to use? Oh, right, it was a Symantec app on Windows he was talking about. Nevermind.
Re: (Score:3)
Meaningful error messages mean you might figure out how to solve the problem yourself, and then you wouldn't need an expensive, annually-renewed, convoluted, "platinum" support contract.
Managed to get a client away from just this sort of jackassery. It was a DOS-based medical practice app that was buggy as hell. Their solution: Package bug-fixes as "upgrades" and charge for 'em. I was disgusted.
Re: (Score:2)
Meaningful error messages mean you might figure out how to solve the problem yourself, and then you wouldn't need an expensive, annually-renewed, convoluted, "platinum" support contract.
Managed to get a client away from just this sort of jackassery. It was a DOS-based medical practice app that was buggy as hell. Their solution: Package bug-fixes as "upgrades" and charge for 'em. I was disgusted.
For commercial software that sounds like a standard industry practice.
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: (Score:3)
Wait ... why are the alligators trying to get things working?
Re: (Score:2)
Because the alligators made the mistake of eating the bottom half of the on call sysadmin before he fixed their server.
Re: (Score:3)
Any self-respecting sysadmin gets attacked by the alligator, it's alligator steak for dinner.
DON'T make the administrative interface a GUI (Score:2)
2. DON'T make the administrative interface a GUI.
Amen, the number of times I have dumped on products because of the lack of a CLI is almost rude and funnily enough it saves a lot in licensing costs so "almost" everyone is happy. Pretty pictures and buttons will get you past the management and sales but if you come near my systems with your "button pushing monkey" toys expect your time in the building to be very short indeed.
Re: (Score:3)
Ok this I don't understand. A GUI can clean things up a lot. Instead of wading through a 1000 line config file all the options are in front of you. They are better organized and can prevent things like conflicting options or flags. I've seen NFS stop working because there was a space used instead of a tab in the config. At least apache was nice enough to finally split up httpd.conf into different parts.
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.
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.
I disagree on the GUI (Score:5, Interesting)
...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: (Score:2)
The gold standard in my opinion is when the GUI utilities are essentially glorified config-file editors. Having a service that is configured with a respectable text-file (xml config files are awful), and ships with a good GUI application to guide configuration, is absolutely fantastic.
Re: (Score:2)
That's what ASDM essentially is. When you make a change, it basically just generates some commands and then sends them the box. If you tick an option, it even allows you to review those commands in advance (and manually copy-paste them in, if you prefer that instead.).
Re: (Score:2)
I have to agree. CLI scripting is wonderful and incredibly useful, but it does not render an admin GUI obsolete. It is not feasible to learn the CLI syntax for each of the hundreds of apps I deal with for clients. In most of them, creating a new user is a matter of a handful of clicks and entering the appropriate user information....not poring over poorly written txt files for an hour looking for which switch grants the user rights to edit the time entries of a different practice group.
GUI and CLI shou
Re:I disagree on the GUI (Score:5, Insightful)
Re: (Score:2)
I'm in two minds. A CLI is a fantastically powerful tool, but at the same time some quick & easy way to change small settings that doesn't require you to go back to the manual (because the last time you looked at this item was eight months ago, and you can't remember a single damn thing) is damn handy.
Re: (Score:3)
What version control tool do you use to track changes to your firewall configuration?
Ciscoworks RME?
Re: (Score:3)
At a minimum ... (Score:2)
This list is a good start. Don't consider purchasing software that doesn't meet these criteria.
Windows CAL cost (Score:5, Informative)
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: (Score:3)
Point taken. Consolidating directories of authenticated accounts in general is a good idea, especially if open standards are involved. If Active Directory (or whatever) isn't your cup of tea, setting up an OpenLDAP server or something similar should be an option.
I think the basic idea is to avoid over-replicating information and minimizing the potential for human error in the duplications.
Re: (Score:3)
Re: (Score:3)
WTF are you talking about?
With Windows, you need the CALs for the user to access any application running on the OS in the first place.
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!
GUIs (Score:2)
My Amiga was a computer that was equally comfortable with CLI and GUI interfaces, and may programs with GUIs had plenty of shell commands with the same executable. I'm not sure why the rest of the computer industry turned it into a religious war that continues to this day.
Some planning and thought are all that's required to make a balanced interface that handles both methods well.
I love bash. (Score:2)
I manage almost exclusively Linux servers and i must say the command line saves me ooodles of time. Some quirks can be alleviated by just restarting some services before they run out of memory, some needs a bit more magic but nothing takes time like having to login to many computers every day and click on the same friggin GUI stuff on multiple servers.
Bash saves me time by totally taking repetitive tasks away. Ive tried the same with some Windows machines but while powershell has potential, it does not work
Re: (Score:2)
Maybe in time Windows will climb up to the level of Linux when it comes to manageability but right now i spend most of my time doing repetitive stuff on my Windows boxes while i write scripts that handles anything on the Linux boxes.
I doubt it. Even relatively recently, I've had serious conversations with tech support at companies where they don't put someone with the IQ of a pot plant on the phone explaining that I need to automate something and you would not believe the number of times I've been told something along the lines of "Why would you want to do that? It's not that complicated - just a couple of clicks."
Getting the message across that it's a couple of clicks to you, it's a couple of clicks possibly several hundred times to
No admin clients that only work on Windows (Score:2)
And we'll call it ... (Score:2)
Copy Pasta Security®
unix? (Score:3)
This reads like a specification for building a unix system.
Those who don't understand Unix are doomed to reinvent it... or something like that.
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: (Score:3)
Do not assume that your software is running with elevated access... (root/administrator)
Correction: don't assume your software NEEDS to run with elevated privileges.
Ya know that's actually an interesting semantic difference. I think both are true. Much software is written making the blind assumption that it will be in an environment with elevated access (my comment). But with yours (which is also true) some developers just assume that their SW needs it, and they act on that assumption, and then you end up back at situation #1.
First rule (Score:3)
Make sure its clear whether you meant '10' in base 2, 8, or 16.
Old Versions (Score:3)
#10 should probably be #1. Support and documentation is everything. Because when it hits the fan, finding the original install CDs or manual is almost always a requirement. It's also why I stopped buying Nvidia cards. They got rid of almost all of their patches and drivers as well as installation CDs on their site and now force you to use their "all in one" tool. And lo and behold, you're screwed 90% of the time with an older machine if you don't have the original install CD because it simply doesn't work without the CD.
Case in point - I tried to recover an old machine's crashed system(video drivers and dirext X had eaten themselves when "upgrading" as is typical) - but the online driver was useless. The original CD was the only option, but it wasn't to be found. (as is typical, few customers keep driver CDs where they can find them). The manufacturer didn't have the original CD to download, either.(honestly, a 50mb ISO file isn't going to kill their server space) I had to buy a new card to solve what should have been a ten minute problem. Nobody was happy about it, either, as you would imagine, since the card wasn't even two years old at the time.
(note - a "roll back" option also needs to be available when "upgrading") I'd wager that 95% of the time it is simply not there.
And don't make me copy the entire 10G dist... (Score:3)
Instead, why not try using, oh, I dunno, "tar" and "make" and friends -- you know, the standard 'nix tools that every system administrator has been working with quite happily for decades and which suffice nicely to install tens of thousands of software packages ranging from the dirt-simple to the incredibly complex.
I'm looking at you, SAS.
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
GUIs are hard to document (Score:3)
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. We cannot achieve the same repeatability when the instructions are: "Checkmark the 3rd and 5th options, but not the 2nd option, then click OK." Sysadmins do not want a GUI that requires 25 clicks for each new user. We want to craft the commands to be executed in a text editor or generate them via Perl, Python, or PowerShell.
Since I've had to work with Windows servers in my new job, I thought I'd better read up on them, so I've been reading Windows Server 2008: The Definitive Guide [oreilly.com]. The sections on the underlying principles and theory of the OS are fine. But that's one third of the text, at most. Most of the text is useless blow-by-blow accounts of sequences of clicks in GUI applets. It's completely unreadable -- the descriptions are meaningless unless you're working through the instructions with an instance of Windows Server 2008 in front of you. And who's going to set up several instances, just to make sense of the description of the applet for configuring load balancing?
I can't blame the book, particularly, as it's a problem of GUIs.My workplace has lots of documents with step-by-step instructions for configuring services, which have one sentence of text, followed by a screenshot, followed by another sentence of text, and another screenshot, and so on.
On the flip side, one of the great things about text configuration files is that while they're full of obscure configuration options, they're also full of the documentation explaining the obscure configuration options. Config files are rich with documentation. GUI configuration applets frequently aren't. I'll take a documented option in a config file over an undocumented option in a GUI config applet any day.
Re: (Score:2)
You sir have no idea what it is sysadmins do. Try doing the job some time and you will see that these items make that 1 sysadmin managing 10k computers possible and saves the company millions.
Re: (Score:2)
Computer-Human Interaction for Management of Personnel?
Re: (Score:2)
I wish I got this memo when I was deciding my career path at a young age. So many small-medium sized companies out there want a Sys Admin to administrate everything from systems to facilities, including the occasional furniture move, and only pay $40k-$50. A lot of hats to wear with the expectation of being able to handle anything new, keeping everything running, and keep one's cool during crisis management. Trying to make a career out of one of those roles, like e-mail administration, only makes sense if i
Re:It's noce to know (Score:5, Interesting)
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.