Take This GUI and Shove It

snydeq writes "Deep End's Paul Venezia speaks out against the overemphasis on GUIs in today's admin tools, saying that GUIs are fine and necessary in many cases, but only after a complete CLI is in place, and that they cannot interfere with the use of the CLI, only complement it. Otherwise, the GUI simply makes easy things easy and hard things much harder. He writes, 'If you have to make significant, identical changes to a bunch of Linux servers, is it easier to log into them one-by-one and run through a GUI or text-menu tool, or write a quick shell script that hits each box and either makes the changes or simply pulls down a few new config files and restarts some services? And it's not just about conservation of effort — it's also about accuracy. If you write a script, you're certain that the changes made will be identical on each box. If you're doing them all by hand, you aren't.'"

Bad GUI and no CLI: way too common

[alain94040]

Here is a Link to the print version of the article [infoworld.com] (that convenientily fits on 1 page instead of 3).

Providing a great GUI for complex routers or Linux admin is hard. Of course there has to be a CLI, that's how pros get the job done. But a great GUI is one that teaches a new user to eventually graduate to using CLI.

A bad GUI with no CLI is the worst of both worlds, the author of the article got that right. The 80/20 rule applies: 80% of the work is common to everyone, and should be offered with a GUI. And the 20% that is custom to each sysadmin, well use the CLI.
--
dead simple alternative [fairsoftware.net] to incorporating for web startups

Re:/etc/resolv.conf

[cheater512]

Usually there will be resolv.conf.head and resolv.conf.tail files somewhere which get stuck at the beginning and end of the generated resolv.conf.
That way you get a semi-dynamic and semi-static config.

Re:Config files.

[Svartalf]

Really? Ever heard of editing /etc/profile and changing the PATH statement there? No, there's no GUI tool- but under Windows it's not wholly clear like you make it out to be where it is. Yeah you can change it- but then so can I under Linux in as much of an easy way as you can under Windows- it's just different and if you're unfamiliar with one or the other, you're not going to be doing it on EITHER.

Re:Bad GUI and no CLI: way too common

[Anonymous Coward]

Exchange Server 2007 (and I assume 2010) does this for many of its GUI operations, gives you the powershell after you've run it.

Re:Bad GUI and no CLI: way too common

[Alain Williams]

AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that you could learn: look at what it did and find out about which CLI commands to run. You could also take them, build them into a script, copy elsewhere, ...

I liked SMIT.

Re:/etc/resolv.conf

[arth1]

/etc/init.d/NetworkManager stop
chkconfig NetworkManager off
chkconfig network on
vi /etc/sysconfig/network
vi /etc/sysconfig/network-scripts/eth0

At least they named it NetworkManager, so experienced admins could recognize it as a culprit. Anything named in CamelCase is almost invariably written by new school programmers who don't grok the Unix toolbox concept and write applications instead of tools, and the bloated drivel is usually best avoided.

Re:Bad GUI and no CLI: way too common

[triple.eh]

I agree with you, AIX's SMIT [wikipedia.org] was an excellent tool for learning. When I first began using AIX all of my UNIX experience was with HPUX, Solaris, Slackware and Red Hat. When I discovered SMIT it was like peering in the Ark without all the melting...

Re:Bad GUI and no CLI: way too common

[Martin Blank]

Aruba's web-based GUI does this. You stack up all of your changes per-page, and you can click on an option at the bottom that shows you the CLI changes that it will make (since it's going to run just those lines when you apply it anyway). It shows you when something is simple and can be done quickly from the CLI, and also when what takes three clicks actually takes five or six somewhat complex lines.

Re:Bad GUI and no CLI: way too common

[Anpheus]

Just about every Microsoft tool newer than 2007 does this. Virtual machine manager, SQL Server has done it for ages, I think almost all the system center tools do, etc.

It's a huge improvement.

Re:And the whole GUI overhead

[sirsnork]

it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI back.

What this means is you can run a small subset of MS services that don't need GUI interaction. With R2 that subset grew somwhat as they added the ability to install .Net too, which mean't you could run IIS in a useful manner (arguably the strongest reason to want to do this in the first place).

Still it's a one way trip and you better be damn sure what services need to run on that box for the lifetime of that box or you're looking at a reinstall. Most windows admins will still tell you the risk isn't worth it.

Simple things like network configuration without a GUI in windows is tedious, and, at least last time i looked, you lost the ability to trunk network poers because the NIC manufactuers all assumed you had a GUI to configure your NICs

Re:Better test!

[arth1]

Yeah, cause we all have test environments.

Yes, we do. In many case it's called a chroot jail which acts as a sandbox.
In other cases, a VM that can be rolled back is the way to go.

There are two words describing those who run untested changes directly on production systems: Former employees.

Re:Bad GUI and no CLI: way too common

[turbidostato]

"What would be nice is if the GUI could automatically create a shell script doing the change"

AIX's SMIT, and it's... how old? merely 20 years now?

Re:Bad GUI and no CLI: way too common

[h4rr4r]

Cool, now move only the files that end in mp3, do not contain a number in the name and are between 10 and 60 days old. I bet the CLI starts looking might fast then.

Re:And the whole GUI overhead

[shutdown -p now]

it's called a "core" install in Server 2008 and up, and if you do that, there is no going back, you can't ever add the GUI back.

Win2008 Core still has a GUI. It's just that it's a GUI that only has a single graphical terminal window open by default, but nonetheless there's a window manager and all the other stuff. And you can open more terminals, and run GUI apps which open their own windows as well (if I remember correctly, it does have Notepad out of the box which can be used that way).

That said, resources consumed by such a thing are so tiny that they won't be noticed even on a mid-range modern desktop, much less an actual server. And it does make life somewhat easier when you actually have to work with it directly (e.g. because ssh is failing for some mysterious reason).

Re:Exchange 2007 and Powershell

[shutdown -p now]

There has been a steady transition to PowerShell for all Microsoft server products, precisely so as to enable CLI scripting with full feature coverage, similar to what has been enjoyed on Unix for a long time. It had started with Exchange 2007, but the most recent addition (to the best of my knowledge) is SharePoint 2010 [microsoft.com].

Re:Bad GUI and no CLI: way too common

[DAldredge]

Is it really too much to expect people on /. Modern to actually know what they are talking about when it comes to Windows and Microsoft?

Screen-scraping?  Really?

Re:Bad GUI and no CLI: way too common

[Anonymous Coward]

That is exactly how the mmg GUI for mkvmerge works! You can use the GUI if you only have to merge a single matroska file,
but the GUI shows the complete command line for the mkvmerge utility, so it is very easy to use it in shell scripts later.

Re:Bad GUI and no CLI: way too common

[Ephemeriis]

What would be nice is if the GUI could automatically create a shell script doing the change. That way you could (a) learn about how to do it per CLI by looking at the generated shell script, and (b) apply the generated shell script (after proper inspection, of course) to other computers.

Cisco's GUI stuff doesn't really generate any scripts, but the commands it creates are the same things you'd type into a CLI. And the resulting configuration is just as human-readable (barring any weird naming conventions) as one built using the CLI. I've actually learned an awful lot about the Cisco CLI by using their GUI.

We've just started working with Aruba hardware. Installed a mobility controller last week. They've got a GUI that does something similar. It's all a pretty web-based front-end, but it again generates CLI commands and a human-readable configuration. I'm still very new to the platform, but I'm already learning about their CLI through the GUI. And getting work done that I wouldn't be able to if I had to look up the CLI commands for everything.

Microsoft's more recent tools are also doing this. Exchange 2007 and newer, for example, are really completely driven by the PowerShell CLI. The GUI generates commands and just feeds them into PowerShell for you. So you can again issue your commands through the GUI, and learn how you could have done it in PowerShell instead.

Re:Bad GUI and no CLI: way too common

[afidel]

But a great GUI is one that teaches a new user to eventually graduate to using CLI.

I couldn't agree more which is why it's really cool that the Exchange GUI tools will show you the exact PowerShell commands they are running if you want to learn how to use the CLI (and in fact that are still things that can only be done in the CLI, though the list is greatly reduced in EX 2010 vs 2007).

Re:Bad GUI and no CLI: way too common

[afidel]

It's always worked dcpromo /unatted:unattend.txt, how do you think server core DC's get built? One of the last major obstacles in many environments to running core was the broken Broadcomm teaming tools but that issue has been resolved for a couple months.

Re:Well there's another side to that

[codepunk]

"I find it rather disturbing the UNIX ideal that sysadmins should be programmers."

Funny, nobody finds it disturbing when I interview for a job. Usually they just say holy crap
you are a experienced and accomplished programmer as well as a crack administrator, hired.

Re:ITT: "Get off my lawn"

[Shadow99_1]

'admins don't typically do stuff once' WTF world do you live in...? I administered a 500 user network a bit over a year ago and very few things were repeated. I set up servers once, and then unless I needed to change something I didn't need to reconfigure them. Now some things like new user accounts is common and repeatable... But those take 2 or 3 minutes and it's done, unless you really cycle massive amounts of employees this should never be more than a half hours work... And a GUI is easily adept at simple repeated tasks. In my 4 years I found little need for scripted anything outside an oracle database and maybe some rare cases with exchange (of all things). Everything else was usually taken care of from a centralized system once, and rarely if ever done again.

Re:Bad GUI and no CLI: way too common

[Anonymous Coward]

You forgot:

= Still alpha code.
= Cannot handle multiple group membership from a Linux file system, such as NFSv4 (http://www.pubbs.net/201004/samba/41361-samba-viewing-if-not-editing-nfsv4-acls-from-samba-shares.html).

Re:Bad GUI and no CLI: way too common

[pjt33]

My root has the ability to download and upload the config as xml. I downloaded it, noticed that it's possible to change the admin's username, and did, thinking that it's an extra step towards defence in depth. Of course, the router didn't like it - it accepted the config but now neither the old username nor the new one work. If I ever want to change the config again I'll have to reset to factory defaults first.

Re:Bad GUI and no CLI: way too common

[WongsHongKongTailor]

pf example: pass in on $ext_if inet proto tcp from any to ($ext_if) \ port $tcp_services flags S/SA keep state pass in on $ext_if inet proto tcp from any to $comp3 port 80 \ flags S/SA synproxy state iptables example: iptables -A INPUT -i $ext_if -p tcp --dport $tcp_services --syn -j ACCEPT iptables -A FORWARD -i $ext_if -p tcp -d $comp3 --dport 80 --syn -j ACCEPT Personally I find the pf format much easier to read/remember/use/debug. Read into it you will find out it is pretty neat.

A few hundred?

[phorm]

Eh? We've got several thousand users, a working master/slave replication setup, and very few issues with our LDAP. Usually if something goes awry it's indicative of another problem that also has side-effects on LDAP....

Re:Refusing to feed the beast is not mindless

[DAldredge]

http://en.wikipedia.org/wiki/Windows_PowerShell

Another concept used by PowerShell is that of a pipeline. Like Unix pipelines, PowerShell pipelines are used to compose complex commands, allowing the output of one command to be passed as input to another. A pipeline is set up by piping the output of one command (or pipeline) to another command, using the | operator. But, unlike its Unix counterpart, the PowerShell pipeline is an object pipeline; that is, the data passed between cmdlets are fully typed objects, rather than character streams. When data is piped as objects, the elements they encapsulate retain their structure and types across cmdlets, without the need for any serialization or explicit parsing  of the stream, as would be the need if only character streams were shared. An object can also encapsulate certain functions that work on the contained data. These also become available to the recipient command for use.[13][14] For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the Out-Default cmdlet, which transforms the objects into a stream of format objects and then renders those to the screen.[15][16]

Because all PowerShell objects are .NET objects, they share a .ToString() method, which retrieves the text representation of the data in an object. Windows PowerShell uses this method to convert an object to text. In addition, it also allows formatting definitions to be specified, so the text representation of objects may be customized by choosing which data elements to display, and how. However, in order to maintain backwards compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, and does not integrate with the PowerShell type system.

The PowerShell Extended Type System (ETS) is based on the .NET type system, but with extended semantics (e.g. propertySets and 3rd party extensibility) . For example, it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using XML-based configuration files.[17]