System Administration - CLI or GUI?

This document is my opinion about performing Linux & Unix system administration using the Command Line Interface (CLI) and Graphical User Interface (GUI). This is only my opinion - your mileage, opinion, preference and experience may, and most likely will, vary. ;-)

Definitions:

For the purpose of this document, my definitions are as follows:

Command Line Interface (CLI):

A Linux/Unix shell prompt and tools/editors/programs than can be run from them and displayed in a character-based environment. I'm not including "pseudo-windows" tools that draw windows using ASCII characters. Although not a "true" GUI, they are similar in that they frequently hide the configuration files and commands used at the CLI.

Graphical User Interface (GUI):

The X-Windows environment and tools/editors/programs that can be run from them and displayed in a graphical environment. Although technically this includes a shell/terminal window, I'm not counting it. If you're going to start X-Windows and open a terminal window, you might just as well do it from the CLI to begin with. I'm only including GUI tools that configure a service (like adding a network printer) or perform some type of system administration (like adding a new user account).

Interface

Interface CLI

Ok, so the CLI doesn't win many points for style as far as most people are concerned. What it lacks in style it makes up for in speed and functionality. The only tools necessary are a shell prompt, some service specific commands and a simple text editor like vi.

Interface GUI

The "point and click" interface is generally easier for the novice administrator to become familiar with, especially since there are usually many things to learn. Once a certain level of competence is reached, the GUI tool often lacks completeness or efficiency for the administrator.

Speed

Speed CLI

In today's "point-and-click" world the command line is considered barbaric by many. But I find the command line often allows you to accomplish tasks more quickly and easily than the GUI equivalent. Ever find yourself doing something in a shell/terminal window because it's faster or easier than using the GUI tool? I can usually connect to the server, change the configuration file and restart the service before X-Windows and the GUI configuration tool are even running.

Speed GUI

GUI's by their very design, tend to be slower than the CLI, especially when the GUI must be started manually. (Think of typing "win" at the DOS prompt to load Windows 3.0.) It takes a little time and some bandwidth to draw all those windows and dialog boxes. Compound that by adding a slow network connection or dial-up link and administration becomes a "point, click and wait" operation.

Overhead

Overhead CLI

A simple shell session and text editor don't put much load on a server. While probably not important on a beefy server, what about when the server's a 486/66 with 16Mb of memory? The software required for shell access is minimal as well, sometimes a factor on a small server with limited hard disk space.

Overhead GUI

Graphical tools, by their very nature, can put an additional load on a server that may be busy enough as it is. Just the graphical interface alone without the tools can require several hundred megabytes of disk space, a potential problem on a small server.

Availability

Availability CLI

Access to the CLI is available via telnet, ssh or even a simple dial-in modem line from just about any computer. Telnet is standard for most Linux/Unix variants and almost any computer with a modem has a telnet client or modem program. If the computer in question doesn't have a modem and related software, you're probably not gonna do remote administration using it anyway. ;-)

Availability GUI

While most GUI's support some type of remote access, many require specific software to be installed/configured on both client and server end before the need to perform remote administration arises. If you haven't already installed the client software and configured the server, you're out of luck.

Reliability

Reliability CLI

I've yet to have a server crash because I was editing a configuration file with vi.

Reliability GUI

I *have* had X-Windows and/or the GUI tool crash, sometimes leaving the configuration file in an unusable state.

Configuration Files

• I believe learning the configuration file syntax is important to really understanding the service, whatever it may be. Although some people would prefer not to ever see those *ghastly* config files, there's often a wealth of information available in them. Aside from the actual syntax, there are often examples and general tips.

• By creating your own config file, you can control the way things are organized. DNS, being somewhat intimidating at first, is a perfect example of this. By organizing the records by type, it's much easier to troubleshoot or add/remove a record. You can also leave yourself notes and comment a section out instead of deleting it while troubleshooting a problem.

• Finally, there's the matter of knowing where the config file lives. By knowing the location of the config file, it's possible to keep several versions for testing/troubleshooting purposes. New configuration file not performing as expected? Move it out of the way, reinstate the previous version and things work again. (Or at least as well as they did before you started messing with it!)

• Typically the most commonly used options & settings are readily available in the form of check boxes or radio buttons. This can be useful when first configuring a service, but what if you want to do something not supported by the GUI tool? Sometimes the GUI tool hasn't caught up with the version of the service it's supposed to administer.

• GUI tools that make changes to plain-text configuration files often just tack those changes on to the end of the file, making organization of the file a lost cause. New features may be unavailable, unknown to the administrator or difficult to use. (Think of the mysterious "extra options" field that appears in many GUI tools.)

• Generally it's not feasible to have several versions of a confuration file so you can switch between them while troubleshooting. Similarly, if there is a help file it may be hopelessly out of date and if there are any hints in the configuration file, there's likely no way to view them.

Multiple Programs/Interfaces

Multiple programs/interfaces CLI

There's no getting around differences in config file syntax or avoiding learning the other commands required for the service (starting, stopping, etc.), but at least you can use the editor of your choice.

Multiple programs/interfaces GUI

Although some programs try, there isn't one single GUI program I'm aware of that's capable of configuring any & all services you might need to. This often requires learning several different tools, each with its own look & feel. Sometimes the GUI tool is written by a different group than the software. This can lead to confusing differences in terminology. (Potato or Potatoe?)

Control

Control CLI

When you edit the config file directly, you have ultimate control over everything that happens with it. I find looking at the "raw" configuration file helps when troubleshooting or sometimes sparks a new idea for tweaking the service. Occasionally it's possible to get the software to do something never intended by combining unrelated options.

Control GUI

Not that I'm a control freak or anything, but sometimes I find GUI tools do things I don't want or refusing to do things I do want. Just because I've checked option A doesn't necessarily mean I want option B enabled too, even if they're supposed to work together. What if I've found a cool configuration trick that depends on A being enabled and B being disabled?

A lesson learned:

Awhile back our HP-UX box that runs Dynix began giving us some trouble. To make a long story about hardware troubleshooting short, I'll just say that several hours and tech support phone calls later, my initial diagnosis of a failing hard drive was correct. I backed up the contents of the disk and disabled use of the server by mere mortals, both from the command line. The next morning a technician arrived with a new disk drive, installed it, and leaving the data restoration to me, went on his way.

Ok, time to reboot the server and begin restoring the data. Wait a minute - it's having trouble finding the old disk drive and doesn't "see" the new drive even though the SCSI ID are the same. No problem, I'll let the server boot and then go configure the new drive with SAM.

• A side note: SAM or the System Administration Manager is a system administration tool for HP-UX. Its interface is of text-based windowing variety - meaning that it's not a real GUI, but something that can be run from a shell prompt or the system console.

I had used SAM to add/remove drives before, so this should be no problem, right? Wrong! I had forgotten to remove the old drive from the volume group. Because the SCSI ID and device file were identical on both the old and new drives I created an "infinite" loop. SAM wouldn't recognize the new drive because it was where the old drive was supposed to be. SAM further refused to remove the old drive because it had to find the drive in order to remove it. Reinstalling the old drive was out of the question - it was in the since departed technician's vehicle.

Houston, we have a problem. Admittedly, all this wouldn't have happened had I remembered to remove the old disk from the volume group before shutting down the box and removing the drive. I had created a situation not foreseen by the programmers that wrote SAM. Ok, so what are the CLI tools and where are the config files to fix this problem? Well, I hadn't a clue because I had never taken the time to learn them - I'd always just let SAM take care of it. While on hold with HP support, it dawned on me that had this happened on one of my Linux servers, I could have already fixed the problem and been on my way because I knew the commands and where the config files were located. The points I'm trying to make with this story are:

• Programmers that design GUI system administration tools can not possibly foresee all the things that might occur and cause the program to misbehave. (The most common of these is likely human error, as it was in my case.)

• By knowing how to do it "the hard way", you can often get yourself out of an otherwise difficult situation.

Ultimately, the solution to my problem came not by using SAM, but by entering several commands at the command line. These commands were completely unknown to SAM, so even had I known how to do it without HP's assistance, I'd have had to do so from the CLI.

Using the GUI as a learning tool:

Don't get me wrong, there are times when a GUI tool can come in handy. I admit I'm guilty of configuring printers under Linux using strictly the GUI tool. The syntax of /etc/printcap was a little confusing to me and so I relied on the GUI tool. Not too long ago I built a new server for a remote location that was to be administered strictly from the command line - no X-windows, no GUI of any kind. By using the GUI tool on another server to create several sample entries in /etc/printcap, I was able to learn about the syntax and eventually add a print queue by editing the file directly.

Keeping the GUI from becoming a crutch:

Ok, so how does one use the GUI to learn without having it become a crutch? Personally speaking, if I use the GUI to start with, I make an effort to learn it "the hard way" later by reading the man pages and other documentation and looking at the config file(s). Even if I don't find it necessary to edit the config file manually, I'll at least poke around in it to become familiar with the syntax and sometimes find options that weren't available or obvious while using the GUI tool.

Conclusion:

It should be blatantly obvious to anyone who's made it this far that I prefer the CLI for a number of reasons. For those of you who have relied on the graphical user interface administration tools to get the job done, I encourage you to give the command line a try. You'll be surprised at what you can learn along the way and might even find yourself enjoying it. ;-)

Back to Eric's Linux pages