Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted more than 3 years ago | from the sorry-dave-can't-let-you-do-that dept.

GUI 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.'"

Sorry! There are no comments related to the filter you selected.

Fuck you, you fucking command line Nazis! (0, Troll)

Anonymous Coward | more than 3 years ago | (#34654262)

Command line was used by Nazis to kill Jews, and is unconstitutional.

I, for one, welcome our new command line overlords.

In Soviet Russia, line commands you!

Obligatory [xkcd.com] xkcd [xkcd.com]

.

Re:Fuck you, you fucking command line Nazis! (1, Troll)

The Clockwork Troll (655321) | more than 3 years ago | (#34654414)

I think you misunderstood the term "Jew bashing".

Re:Fuck you, you fucking command line Nazis! (0)

Anonymous Coward | more than 3 years ago | (#34654626)

Mel, is that you?

CHIMIT (0)

Anonymous Coward | more than 3 years ago | (#34654278)

Computer-Human Interaction for Management of Information Technology's

I hate every term in that series.

Re:CHIMIT (1)

Nogami_Saeko (466595) | more than 3 years ago | (#34654366)

I was sort of hoping it was going to spell CHIMP. Unfortunately it didn't. Pity.

Re:CHIMIT (1)

Yvan256 (722131) | more than 3 years ago | (#34654636)

Computer-Human Interaction for Management of Personnel?

Re:CHIMIT (1)

mrawhimskell (1794156) | more than 3 years ago | (#34655124)

CHIMP - Computer Human Interaction for Management Professionals . There you have it!

1 Do for being a user (2)

TheL0ser (1955440) | more than 3 years ago | (#34654290)

1. DO switch every don't to a do and do to a don't on that list. You are now a user.

Re:1 Do for being a user (0)

Anonymous Coward | more than 3 years ago | (#34654330)

You are the problem, not the solution. It *is not* your system. It exists solely for the use of "users".

And, dude, put down the Cheeto's and Dew, don't you think 210 is a bit heavy considering you're only 5'6"?

Re:1 Do for being a user (2)

epyT-R (613989) | more than 3 years ago | (#34654724)

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 (0)

houstonbofh (602064) | more than 3 years ago | (#34655048)

Really? Can you rebuild an engine? Than give me your car.

User should not have to be mechanics. But mechanics should not need an extra elbow in the forearm just to change a spark plug.

Re:1 Do for being a user (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34654434)

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 any real data validation on each of them.

I've got a Try Catch around the data insert - if a user doesn't enter things in right it'll tell them to contact me... We'll see how well that goes.

I think I've made the trade-off of time/security plenty of times at this job. It's never really my decision though. I go for the Security through obscurity method here... If I'm the only one who knows how insecure this website is, no one in the company would try and break it, or so I hope.

i am impressed (5, Funny)

digitalsushi (137809) | more than 3 years ago | (#34654296)

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 (3, Insightful)

mcgrew (92797) | more than 3 years ago | (#34654332)

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 (5, Funny)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#34654794)

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.

Re:i am impressed (1)

Anonymous Coward | more than 3 years ago | (#34654426)

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?

This is your one Christmas present from Slashdot. It's the one story this year where the editors did their job.

Which, of course, means it will be duplicated three or four times in the next week.

Re:i am impressed (0)

Anonymous Coward | more than 3 years ago | (#34654496)

Ah, the gift that keeps on giving.

How to make a good top 10 (2)

tepples (727027) | more than 3 years ago | (#34654456)

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 (3, Funny)

kimvette (919543) | more than 3 years ago | (#34654516)

No slashdot editors were involved in the production of the list. ;)

Top 10 (1)

sakdoctor (1087155) | more than 3 years ago | (#34654520)

I demand a meta top 10. The top ten list of top 10 lists.

fucking apostrophes, how do they work? (1)

jollyreaper (513215) | more than 3 years ago | (#34654326)

nt

Re:fucking apostrophes, how do they work? (3, Funny)

Anonymous Coward | more than 3 years ago | (#34654364)

"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? (5, Funny)

daremonai (859175) | more than 3 years ago | (#34654986)

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

Re:fucking apostrophes, how do they work? (0)

Anonymous Coward | more than 3 years ago | (#34654368)

fucking apostrophe's, how do they work?

Re:fucking apostrophes, how do they work? (1)

pantheonwhaley (1933610) | more than 3 years ago | (#34654382)

I don't know, how do fucking apostrophes work [grammarbook.com] ? I'm a descriptivist. I don't judge either way. I like your way better but that doesn't make you right any more than me liking communism makes Marx right.

Re:fucking apostrophes, how do they work? (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34654506)

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? (5, Funny)

blind monkey 3 (773904) | more than 3 years ago | (#34654556)

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

Re:fucking apostrophes, how do they work? (1)

Millennium (2451) | more than 3 years ago | (#34654646)

Quite well, actually. And at least in the title of this article, they're even used correctly.

Re:fucking apostrophes, how do they work? (1)

enjerth (892959) | more than 3 years ago | (#34654806)

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.

The mere existence of an API? (1)

a Flatbed Darkly (1964478) | more than 3 years ago | (#34654340)

I agree with most of these; however, I'd revise #3 to refer to "a substantial API" and not the minimal, in terms of usefulness execrable, deposits of code provided by some software.

Re:The mere existence of an API? (0)

Anonymous Coward | more than 3 years ago | (#34654574)

I'll take simple and well documented, substantial is just a nice bonus, but good documentation is a must.

DO NOT (1)

Anonymous Coward | more than 3 years ago | (#34654356)

DO NOT be a sysadmin

Summarizing (1)

billcopc (196330) | more than 3 years ago | (#34654358)

In essence, all 10 items on the list say "Use Linux!"

Yeah, ok, thank you Captain Obvious, I mean CHIMIT :P

Re:Summarizing (2, Insightful)

Anonymous Coward | more than 3 years ago | (#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).

Holy crap, a slashdot first (4, Interesting)

subreality (157447) | more than 3 years ago | (#34654360)

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 (5, Informative)

XanC (644172) | more than 3 years ago | (#34654378)

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.

Ten??? I read that as Two! (0)

Anonymous Coward | more than 3 years ago | (#34654396)

(blush)

#11: Meaningful error messages (5, Funny)

eln (21727) | more than 3 years ago | (#34654400)

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 (0)

Anonymous Coward | more than 3 years ago | (#34654460)

I'm imagining the sound of a Half-Life crowbar beating on headcrab zombies right now.

Re:#11: Meaningful error messages (1)

Psyko (69453) | more than 3 years ago | (#34654538)

too true.

Years back I remember a symantec app on windows that would pop up a dialogue box when it was trying to shut down that just said:

Should not see this.

with a big red X on the left and a cancel button on it. I had a screenshot of it somewhere, it was my favorite error message to date. I was always thinking ok... you took the time to have it pop a box with that message in it, but couldn't actually put any useful info in it?

Re:#11: Meaningful error messages (1)

mehrotra.akash (1539473) | more than 3 years ago | (#34654588)

i had ubuntu give me a
"This should not have happened"
message recently

Re:#11: Meaningful error messages (1)

martin-boundary (547041) | more than 3 years ago | (#34654654)

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.

Re:#11: Meaningful error messages (5, Insightful)

Monkeedude1212 (1560403) | more than 3 years ago | (#34654566)

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 (3, Interesting)

Jaime2 (824950) | more than 3 years ago | (#34655100)

Of course, good error handling is best. But, no error handling is usually better than cargo-cult error handling that displays a pretty message, but doesn't record the error detail anywhere. Very few things bother me more in a code review than somebody who put in the extra effort to ensure that an error message can never be found, I would have rather they simply skipped it.

Channeling Philosoraptor (2)

Xaositecte (897197) | more than 3 years ago | (#34654570)

if it fails in a way that you never thought possible, how would you write an error message that describes the failure?

Re:Channeling Philosoraptor (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34654594)

You describe what it isn't, based on the other exceptions you were designed to handle.

Narrows down the search/troubleshooting.

Re:Channeling Philosoraptor (1)

bwindle2 (519558) | more than 3 years ago | (#34654664)

by catching return codes to functions, and displaying their results back to the user. If a function tries to open a file, and it fails, the OS will tell the program the reason and describe the failure; all you have to do it pass it along to the user. such as: open FILE, "filename.txt" or die $!;

Re:Channeling Philosoraptor (3, Informative)

greed (112493) | more than 3 years ago | (#34654764)

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 couldn't it be opened?"

So, sticking with perl:

open FILE,"filename.txt" or die "Cannot open \"filename.txt\" for reading--$!\n";

Your example will give only the errno, which is what I'm calling HOW [it went wrong]. WHAT went wrong is the "open for reading". WHERE it went wrong is "filename.txt".

I generally wrap such calls with a library; that way, I don't have the error handling littering up every call-site. But if you're using an exception-oriented language, we need the SAME INFORMATION once it turns into an error message!

Oh yeah: For error recovery code, files can't be opened for more reasons than just, "It's not there." You can try all you want, but if (say) the filesystem has gone read-only due to a disk controller failure resulting in journal abort, you might want to do something different. That one's strictly hypothetical, haven't had it happen in over a week--ever since I replaced that faulty cable....

Re:Channeling Philosoraptor (1)

janeuner (815461) | more than 3 years ago | (#34654848)

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:Channeling Philosoraptor (1)

fishexe (168879) | more than 3 years ago | (#34655068)

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:#11: Meaningful error messages (1)

jimicus (737525) | more than 3 years ago | (#34654590)

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:#11: Meaningful error messages (1)

Monkeedude1212 (1560403) | more than 3 years ago | (#34654614)

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:#11: Meaningful error messages (1)

jimicus (737525) | more than 3 years ago | (#34655004)

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:#11: Meaningful error messages (2)

frank_adrian314159 (469671) | more than 3 years ago | (#34654634)

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:#11: Meaningful error messages (0)

Anonymous Coward | more than 3 years ago | (#34654644)

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.

Re:#11: Meaningful error messages (2)

UncleTogie (1004853) | more than 3 years ago | (#34655090)

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:#11: Meaningful error messages (1)

blind monkey 3 (773904) | more than 3 years ago | (#34654740)

*picks up a crowbar and goes off to find the programmer*
KY gel in the other hand? Easier access to logs.

Re:#11: Meaningful error messages (1)

mewsenews (251487) | more than 3 years ago | (#34654816)

God I love slashdot sometimes

Re:#11: Meaningful error messages (1)

GMFTatsujin (239569) | more than 3 years ago | (#34654984)

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!

click-wall. (5, Insightful)

nblender (741424) | more than 3 years ago | (#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...

Re:click-wall. (1)

crunchygranola (1954152) | more than 3 years ago | (#34654894)

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

Reminds me of the time I was going to spend a month vacation at a beach cottage. No broadband, no cable TV, no WiFi AP, but it did have a telephone. So I decided to sign up for a month with an ISP who had a POP that was a local call from the cottage. There was only one that I could find - EarthLink. Now obviously I couldn't sign up on-line for their service FROM THE COTTAGE since I would need an Internet connection for this. Additionally I did not suppose there was any reason that I would need to use the very computer I was going to have at the beach simply for the sign-up.

EarthLink thought differently. When I signed up it automatically downloaded software to the machine I was using (belonging to a relative I was staying with) that erased all of its Internet settings, making EarthLink the ISP on that machine, and replacing all of my relative's info (username, etc.) with the data I had entered on sign-up, all without warning me or giving me any options. I couldn't restore the settings myself since I didn't know them. Though not a disaster it was a real nuisance to undo all the "help" it deemed fit to give me.

On #10 (0)

Anonymous Coward | more than 3 years ago | (#34654462)

Some of work in the field and we should be able to read the documentation via telnet or lynx. It's not always convienient to grab a laptop, sometimes there's no wireless availiable and either all the switch ports are used or getting internet access is a kafkaesque nightmare. Yes I have a smartphone -- it's not an efficient way to browse documentation!

That's plain ASCII to you... (5, Insightful)

sl149q (1537343) | more than 3 years ago | (#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.

Re:That's plain ASCII to you... (1)

HomelessInLaJolla (1026842) | more than 3 years ago | (#34654608)

Absolutely. The art of the ASCII file, the plain text editor, and the comma separated data file is more important than all of the internet.

1. Silent install? Well, great idea, but ideally you have one program file and maybe a few config files. This whole concept of installation is a product of lazy programmers and/or poorly written operating systems. There isn't anything to be done about it in modern computing... just sayin'.

2. No GUI. Totally. Similar to the concept of dependencies--you should know what you are doing before you consider yourself an admin. Same applies for computer security. If you cannot secure your local priveleges then no amount or combination of network firewalls or safety nets is going to save you from incompetence.

3. Somewhat disagree. API for remote admin? If it were written properly it would just run and remote admin would consist of editing the text config files.

5. Ideally all of the data is stored in the text files. That's easy enough. If you're worried about information security then pass the text files through your own custom made algorithm which you've hand-craftedly carefully buried within the asm of the executable.

6. Ha. I consider that like ftp. Log in and poke around. Is it up or down? That's all there is. If portions of your program become inaccessible when other portions are still running then you wrote it wrong or the underlying operating system sucks.

7, 8, 9... totally.

10. Documentation should be in ASCII text readable by any text editor/pager. _IF_ you create fancier docs from the original that is fine... ASCII plain text human readable should be first and foremost.

Re:That's plain ASCII to you... (2)

c++0xFF (1758032) | more than 3 years ago | (#34654622)

Wait ... why are the alligators trying to get things working?

Re:That's plain ASCII to you... (1)

Nadaka (224565) | more than 3 years ago | (#34654898)

Because the alligators made the mistake of eating the bottom half of the on call sysadmin before he fixed their server.

Re:That's plain ASCII to you... (2)

jimicus (737525) | more than 3 years ago | (#34655042)

Any self-respecting sysadmin gets attacked by the alligator, it's alligator steak for dinner.

DON'T make the administrative interface a GUI (2)

Chucky_M (1708842) | more than 3 years ago | (#34654470)

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:DON'T make the administrative interface a GUI (2)

ArchieBunker (132337) | more than 3 years ago | (#34654546)

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 (3, Insightful)

Chris Mattern (191822) | more than 3 years ago | (#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.

Re:DON'T make the administrative interface a GUI (0)

Anonymous Coward | more than 3 years ago | (#34654600)

Double Amen. I'm the local Linux admin. I feel so so sorry for my colleague the Windows admin every time he has to setup something in IIS. Our conversation usually ends with "Hmm, I don't know dude, in Apache I'd just use sed to update XXX across all our sites..." And his mouse goes click click click.

Amendment to #2 (4, Insightful)

c++0xFF (1758032) | more than 3 years ago | (#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.

I'm sorry, why should we care? (-1)

Anonymous Coward | more than 3 years ago | (#34654472)

What makes you think we care about making your jobs easier? Why do admins always get the idea that they're the important part of the process? You're server janitors. You're the IT equivalent of the dude who unclogs the toilet. You think I'm going to eat more fiber for him next?

Re:I'm sorry, why should we care? (1)

Coren22 (1625475) | more than 3 years ago | (#34654568)

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:I'm sorry, why should we care? (-1)

Anonymous Coward | more than 3 years ago | (#34654632)

Actually I know exactly what you all do. You whine and pule and cry like you have a hard job, and you bitch and moan and get basic concepts incorrect and regurgitate things we programmers invented that you ill understand.

Go unclog the toilet.

I disagree on the GUI (5, Interesting)

Zarhan (415465) | more than 3 years ago | (#34654530)

...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 (0, Funny)

Anonymous Coward | more than 3 years ago | (#34654606)

What version control tool do you use to track changes to your firewall configuration?

Didn't think so.

Re:I disagree on the GUI (2)

Zarhan (415465) | more than 3 years ago | (#34654648)

What version control tool do you use to track changes to your firewall configuration?

    Ciscoworks RME?

Re:I disagree on the GUI (2)

Simulant (528590) | more than 3 years ago | (#34654716)

How about RANCID? http://www.shrubbery.net/rancid/ [shrubbery.net] It doesn't give a shit how you edit your firewall config. Version control does not preclude using a GUI. While a CLI should always be there, I have no problem adding a GUI to just about anything.

Re:I disagree on the GUI (1)

Whatsisname (891214) | more than 3 years ago | (#34654616)

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:I disagree on the GUI (1)

Zarhan (415465) | more than 3 years ago | (#34654670)

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:I disagree on the GUI (1)

PrimalChrome (186162) | more than 3 years ago | (#34654704)

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 should both be well designed and complimentary in nature. They are excellent tools and suit their own set of admin needs.

Re:I disagree on the GUI (1)

greed (112493) | more than 3 years ago | (#34654826)

You can easily build a GUI on a good script-able CLI. You can even build Web interfaces to them... though the "good"ness of that idea depends on the security around your web server.

You can rarely build a CLI on a GUI, no matter how good. You would have had to build all the CLI hooks into the GUI code anyway, at which point you might as well have done it the other way up in the first place.

It makes much more sense to start with a strong CLI and build the GUI on top; most UNIX admin GUIs are exactly that. Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).

The other thing, of course, is admins deal with broken stuff. The more stuff you need, the harder it will be to deal with when things are broken.

Re:I disagree on the GUI (1)

Anonymous Coward | more than 3 years ago | (#34654944)

Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).

Everyone who uses the Very Wrong Editor (emacs) is using a TUI built on top of a line editor (TECO).

Re:I disagree on the GUI (5, Insightful)

Qhartb (1311541) | more than 3 years ago | (#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.

Re:I disagree on the GUI (1)

lbates_35476 (901961) | more than 3 years ago | (#34654776)

Only if you are setting up one firewall or editing one rule. Try that on 50 firewalls for 50 remote offices and you will notice that this doesn't work well any longer. You will want a script that you can apply to all 50 quickly and with confidence that all of them are EXACTLY alike.

Re:I disagree on the GUI (1)

jimicus (737525) | more than 3 years ago | (#34654946)

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:I disagree on the GUI (0)

Anonymous Coward | more than 3 years ago | (#34654974)

Guess you have no experience outside small doze admin tasks? Command lines are best for the simplest of reasons: automation.

Anyone can click an option for "admin", try and do that for hundreds or even thousands of machines, though.

Re:I disagree on the GUI (1)

MichaelKristopeit328 (1963774) | more than 3 years ago | (#34655000)

it's quite obvious that an optimal solution is the combination of an optimal command line solution and an optimal smart thin client GUI solution.

All very good suggestions (1)

trollertron3000 (1940942) | more than 3 years ago | (#34654554)

All very good suggestions. But as a programmer it's my job to ignore these. Thank you come again. I joke, I try my best to make my tools admin friendly. Because that admin might be me.

At a minimum ... (1)

LoudMusic (199347) | more than 3 years ago | (#34654576)

This list is a good start. Don't consider purchasing software that doesn't meet these criteria.

Windows CAL cost (5, Informative)

tepples (727027) | more than 3 years ago | (#34654580)

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:Windows CAL cost (2)

GMFTatsujin (239569) | more than 3 years ago | (#34655012)

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:Windows CAL cost (2)

Jaime2 (824950) | more than 3 years ago | (#34655054)

Incorrect. Client Access Licenses are for those who use File and Print services. Authentication services only require a license for the server itself.

Re:Windows CAL cost (2)

jimicus (737525) | more than 3 years ago | (#34655112)

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 (0)

Anonymous Coward | more than 3 years ago | (#34655120)

But NTLM is a specific authentication implementation developers shouldn't have to bother with. A good application uses an abstraction layer like SASL, so I can choose the scheme myself. And one update to e.g. the LDAP module should be sufficient to fix all SASL-enabled applications using LDAP.

GUIs (1)

Waccoon (1186667) | more than 3 years ago | (#34654746)

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. (2)

miffo.swe (547642) | more than 3 years ago | (#34654770)

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 in reality unless you are a 100% Microsoft shop, and you happen to run the limited set of applications that has full support for powershell.

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.

No admin clients that only work on Windows (1)

Air-conditioned cowh (552882) | more than 3 years ago | (#34654992)

Unless you want me to drop the product and choose something else less irritating. Hello VMWare? Xen?

More options (1)

SnarfQuest (469614) | more than 3 years ago | (#34655038)

- If you don't provide documentation, requiring the sysadmin to dig through the source code for configuration information, please add some useful comments and meaningful function names.
- Make the option parsing code clear enough so we can at lease see what words are used for the options. Cute parsing code may save a millionth of a second each time the program is run, but is useless if we can't figure out how to configure it.
- If you have a configuration file, tell us where it is and what it is named, at a very minimum. Scanning a binary file for strings to locate the configuration file is a major pain.
- Don't develop yet another build system. Especially if it only works on one specific version of a specific operating system on specific hardware.
- Don't make every error message exactly the same. Trying to figure out which one of the fifty "oops" messages was triggered is painful.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?