Take this GUI and shove it

A few weeks ago, I posted a bit of advice for VMware amid speculation that the leading virtualization company might purchase Suse Linux from Novell. (As in: Don’t do it.) Since then, I’ve taken hits in comments and in email, mostly in reponse to my criticism of the YaST tool that serves as Suse’s central management console.

Plenty of people commented that if you don’t like YaST, you don’t have to use it, which, while technically true, doesn’t accurately reflect the problems you may encounter if you use YaST alongside traditional shell management.

Also, YaST is one of the primary differences between Suse and other Linux distributions. If I’m going to toss YaST, why wouldn’t I just use CentOS or RHEL or any number of other distributions? After all, what differentiates one distro from another in the server space? Management tools, the software update tools, directory paths, and the choice of default packages. After that, it’s all just Linux.

Even though I singled out YaST, I find nearly all GUI management tools for network devices and servers more trouble than they’re worth — except on Windows, where there generally isn’t a choice. Even there I’ll head for the CLI (command-line interface) for many tasks.

This preference isn’t techno-codgerism, it’s based on the reality of day-to-day network and server administration.

Think back 15 years or so to the four main players that were producing routers and switches: Cisco, 3Com, Nortel, and Cabletron. Of those four, only Cisco consistently maintained a CLI-based management framework, while the others offered text menus to configure their gear. Some also included a crippled CLI shell, but they were all pushing their ease-of-use over Cisco’s comparatively obscure CLI. Of those four companies, only Cisco thrived while the others either failed completely or have been marginalized.

Also, in 1996, two new networking companies were founded: Extreme Networks and Juniper Networks. Both companies made the CLI the administration tool of choice, and both companies are still around and doing well.

Of course, many different factors led to that Darwinian triumph, but the fact of the matter is that most high-end network architects and admins cannot stand menuing interfaces on network gear. It makes just about everything harder by trying to make a few things easier, and for many like me, that’s a nonstarter.

Let me offer an example. I recently had a relatively complex meshed VPN network to construct using Cisco ASA security appliances. Using the CLI, I configured one ASA5520 with everything I needed: IP addresses, routes, a tunneled OSPF configuration, VPN tunnel definitions, a bevy of QoS rules, access-lists, remote and local administration rules, SNMP strings, logging, a new firmware version, the whole works.

I was then able to copy off that text-based configuration and run it through sed to do a search and replace on IP addresses and network definitions, and within a minute or two I had a complete configuration for the other ASA5520s. All I had to do to get them running was log into them, copy over the right firmware and their configuration file, and reboot them. By any definition, that’s a highly simple and effective method, and one possible due to the simplicity of the CLI and the text-based configs.

But then I came across the Cisco SA520. While the ASA5520s are full-blown ASA appliances, the SA520 is dubbed a “Small Business Pro security appliance.” It was for one site that didn’t need the horsepower of the ASA5520, and the specs of the SA520 fell into line with the planned service to that site.

The SA520 doesn’t have a CLI, or even a serial console for that matter. All it has is a Web UI.

So rather than being able to configure this device in a matter of a minute or two as I had with its bigger brothers, I had to wade through the Web UI to build essentially the same configuration as the other ASAs had, specific to the site. This process took longer than the entirety of the time I spent configuring all the other ASAs. Nominally, you’d think that having a Web UI would be easier than a CLI, but that certainly wasn’t true in this case.

To be fair, the SA520 is designed for small businesses and meant to be used by those that would have no idea what to do with a real Cisco IOS CLI. Sadly, Cisco used to make the PIX 501 that was produced for the same market, ran PIXOS and had a fully functional CLI. For the SA520, however, the Web UI is really the only method of configuration possible. The lack of a complete underlying CLI interface renders the device more difficult to use in many cases.

For another example, say that you need to do an external re-IP on a large corporate firewall that has to happen as fast as possible to minimize downtime. There are a few ways to do this. The costliest would be to purchase another firewall, configure it with all the new addresses, translations, rules, and whatnot, and then simply turn it on and turn the old one off.

If the firewall does not have a CLI, that might be the only option, because otherwise you have to feverishly click through page after page of a Web UI or a text-based menuing interface, or run through a fat GUI client to make all the necessary changes on the fly. Depending on the size of the task, this could take a very long time indeed.

Alternatively, if there’s a strong CLI, you simply open up a text editor, dump in the relevant portions of the configuration, run a search and replace for the IP addresses, make a few routing changes, and when the time comes to make the switch, you literally just paste the configuration into the firewall. All done in a matter of seconds.

These examples are based on network devices, but the same concept holds true for just about anything. 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.

As to my mention of Windows earlier, I definitely use the GUI tools extensively — while there are CLI analogues to many of the GUI interactions, that’s not universal. However, when faced with a task like having to make significant permissions changes on large filesystems, I’ll use fileacl 10 times out of 10.

The moral of this particular story is that GUI interfaces are fine and necessary in many cases. But they need to be built after a complete CLI is already in place, and they cannot interfere with the use of the CLI, only complement it. Otherwise, all you’ve done is make easy things easy and hard things much harder.

This story, “Take this GUI and shove it,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com.