Why GUIs suck, revisited

A while back, I wrote about the critical roles CLIs (command-line interfaces) play in just about every facet of the IT infrastructure. I got plenty of nods in agreement via email and in the comments, but I still receive emails claiming that I’m trying to drag computing back to the “dark ages of the C: prompt,” and there’s usually a whole lot of “you want to turn IT back into an Ivory Tower.”

I fear I’ve been misunderstood by some, no matter how well understood by others. I’m going to take a few minutes and give everyone a very concrete example. Forgive me for belaboring the obvious.

Say there are two companies, precisely the same size and in the same industry. On one side, we have an admin who’s using a Cisco ASA (though the make and model could differ), and the other is using an XYZ firewall with only a Web-based GUI interface. Yes, the ASA probably cost a bit more, but it’s based on a very mature CLI. The XYZ firewall has no CLI at all. We’ll call them CLI Inc. and GUI Industries.

Both companies are fortunate in that a new carrier has come to town and wants to light up their location with fiber. They can finally ditch those expensive T3 circuits, which will represent a massive cost savings, while increasing bandwidth more than 100 percent. Everyone is thrilled — except the firewall admin with the GUI.

You see, both companies have a significant external presence, are using most of a full class C externally, and will be renumbering to connect to the new service. This means that the translation tables on each company’s firewall must change completely. Mind you, we’re talking about more than 200 IP addresses. Oh, external DNS will have to change too. Since both companies run their own external DNS servers, they’ll have to modify those records to coincide with the cutover.

Naturally, GUI Industries is using Windows as its external DNS server. Meanwhile, CLI Inc. is using a Linux box running BIND9.

The network and DNS admins at both companies get their new subnet assignments and begin mapping the translations. Using a spreadsheet, they have one column with the service name and two columns containing the old and new IP addresses. They’re pretty much a 1-to-1 matchup, but they take the opportunity to remove some old addresses that aren’t in use any more and move a few services around. They plan carefully and make sure they’ve covered all their bases, as the cutover date is only a week away so that they can terminate their T3 contracts without getting hit with a wasted month of service.

GUI Industries starts its cutover on a Friday after hours. The new circuit tests clean and they’re ready to do the cutover. Armed with printouts of the spreadsheet, the DNS and firewall admins sit down in front of their workstations and painstakingly go through each record in DNS, and each NAT mapping in the firewall, one by one, typing in each address manually for each record, and double-checking. The night wears on as they wait for dialog boxes to appear, for POSTs to the Web-based firewall GUI to complete, for pages to redraw, and for rows to be crossed off the paper in front of them. It takes several hours at least — and unbeknownst to them, they’ve managed to fat-finger a few addresses and swap a digit here or there in the blear of a late Friday night.

Meanwhile, an admin over at CLI Inc takes the two address columns from the spreadsheet, copies them to a clipboard, and pastes them into a file on a Linux box. It’s the work of 10 seconds to parse that into a usable sed script. The DNS admin then runs sed -f ./trans.sed ./externalzone-old.fwd > ./externalzone.fwd, increments the serial number, and the DNS changes have been made with 100 percent accuracy. The named process just needs to be told to reload the zone.

The firewall admin copies the current ASA config to the internal TFTP server and runs the exact same sed script on the file, then edits it to add the relevant portions of the original configuration with “no” prepended to ensure that all the static maps are cleared. Then he renames the external ACL to something different, has the new ACL apply to the external interface, and changes the default route. He doesn’t do this in the firewall itself — instead he’s simply editing a textfile in vim. A simple textfile — it takes him maybe half an hour on a Wednesday morning.

Even these steps wouldn’t be required if the fourth octet of each address was identical in the old and new subnets. They could have done all of this with a single s/123.123.123./213.213.213./g regex replacement in vim or sed.

When it’s time to make the switch at 5 p.m. on that fateful Friday, the DNS admin copies the new zone over and reloads the zone with a single command. The DNS changes are complete in five seconds. The firewall admin simply copies and pastes his new config from that textfile directly into the ASA, then clears the translation tables. They run a few tests and head to the bar for a well-deserved scotch at around 5:20.

Meanwhile, the guys at GUI Industries complete their manual labor at around 10 p.m. and head home, happy to be done with all of that mind-numbing, repetitive pointing-and-clicking nonsense. They settle snug in their beds for all of two hours before their cell phones ring with angry reports of downed services due to their inadvertent typos. They drag themselves to their desks and fire up the VPN to fix the problems — only to discover that the VPN happened to be one of the addresses the firewall admin fat-fingered. Their cries of anguish pierce the air of their slumbering subdivisions.

Lest you think, dear reader, that this is all fabrication, that I am creating some fanciful alternate reality to prove my point, rest easy. I assure you that both of these circumstances have occurred and there are myriad tales just like them the world over. There is a time and a place for graphical interfaces, but there is no reason, and no excuse, to dispense with the command-line alternative.

Should you scoff at this lesson in IT, you do so at your own peril.

This story, “Why GUIs suck, revisited” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.