System Administration - CLI or GUI?
Last modified May 25, 2000
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. ;-)
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 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 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"
- 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
- 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 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 CLI
- I've yet to have a server crash because I was editing a configuration file
- Reliability GUI
- I *have* had X-Windows and/or the GUI tool crash, sometimes leaving
the configuration file in an unusable state.
Configuration Files CLI
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.
Configuration Files GUI
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 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 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
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
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
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.
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
This page created October 09, 1999 by Eric Sisler
This page last modified May 25, 2000 by:
Eric Sisler (firstname.lastname@example.org)