So there you are being a happy system administrator with your handy collection of scripts and text
configuration files. You have the warm, confident glow that comes from knowing you can sit down to
any Linux or Unix machine, poke your way through plain text configuration files, and figure out how
to make things work. It may not be elegant, and you may be stuck with some weirdo, antique text
editor and man pages written by cloistered coders in Yoda-like syntax, but what counts is that
you’ll be able to get the job done.
Until the fateful day, that is, when you stumble over an XML-formatted configuration file. What
manner of beast is this?
<?xml version='1.0' encoding='UTF-8' ?> <pref name='/'> <pref name='core'> <pref name='away'> <pref name='away_when_idle' type='bool' value='1' /> <pref name='mins_before_away' type='int' value='5' /> <pref name='def_msg' type='string' value='Boring default' />
Well now, this is a different kettle of fish from your usual text configuration file. (That is a
snippet adapted from ~/.gaim/prefs.xml.) So what are you supposed to do with this? In this case
probably nothing, because you configure Gaim through a graphical menu. Though you can edit
~/.gaim/prefs.xml directly if you wish, which power users are wont to do when the graphical
menu does not do what they desire. And as the GNOME universe continues to whittle away at
user-configurable options, knowing how to tweak these files might become a necessity someday to get
any choice at all.
Come on, you say, we've been getting along fine with config files with wildly varying internal
structures for lo these many decades, and it never bothered anyone before. The traditional
comments-and-options scheme works great, especially when the comments are useful. You can enter all
kinds of options so you don't forget them, then comment and un-comment them as you need, as this
snippet from Debian's /etc/apt/sources.list shows:
# comment or un-comment the lines you need,
# then run apt-get update before installing or
# removing packages
# official OpenOffice backports for Woody
deb http://ftp.freenet.de/pub/debian-openoffice/ woody main contrib
# all kind of kewl non-official packages such as acidrip, acroread,
# acroread-debian-files, acroread-plugin, alsa-headers,
# avidemux, babytrans, babytrans-common,
# babytrans-dic-engtofre, chaplin, ...
# Architectures: all, i386
deb ftp://ftp.nerim.net/debian-marillat/ stable main
deb ftp://ftp.nerim.net/debian-marillat/ testing main
# deb ftp://ftp.nerim.net/debian-marillat/ unstable main
Some files use an .ini-type format, if you really want something that appears structured:
[game over w]
Name=Game over, you won
Name[af]=Speletjie bo, jy wen
.joerc, the configuration file for the text editor JOE, uses leading spaces
to de-activate options. To make an option active it must be flush with the
left margin. Some configuration files do not permit any
comments at all — only active options. Doubtless there are other, even more offbeat conventions.
But this is the way it's been since the beginning of time. So why do you even need to care about
Why You Need To Care
XML provides a common, cross-platform data exchange format. And because it uses plain text files the
data are recoverable with simple tools, or even plain eyeballs. XML is in wide use these days —
it's the default file format for OpenOffice, Gnumeric, Abiword, KOffice, and many other
applications. Using a structured, machine-readable format means all manner of tools can be written
to read and manipulate the data: export to different types of presentation formats, make large
changes with small effort, and export to different applications.
OS X, GNOME and KDE all make extensive use of XML. This makes for faster, easier development and
configuration of GUI interfaces. Contrast these with Webmin, which is a general-purpose Web
interface for configuring Linux servers and applications. Every module must be custom-written for
each individual application. Webmin is Perl-based, because only Perl can handle the parsing
nightmare that characterizes the Linux/Unix configuration file universe. An additional advantage of
Webmin is that you can apply manual edits and Webmin won't overwrite them. This is not true of many
GUI configuration tools, as users of Red Hat, Mandrake and SuSE know. Using well-designed XML
configuration files should make this sort of silliness a thing of the past.
Using XML opens up all sorts of possibilities: more accurate syntax checkers and markup validators,
easier parsing and analysis of logfiles, easier customization and replication, easier scripting,
easier reporting, and better cross-platform integration. In a nutshell, making the computer do more
work and the human do less is a good thing.
Sure, as hardworking system and network administrators the last thing we want to hear is "hey,
here's another new technology to learn!" But XML isn't so difficult. It's a markup language that
looks similar to HTML, with a major difference: In XML you can define your own tags. This gives you
the flexibility to design a document however you need to, and being able to write descriptive tags
makes a document more understandable. So you can almost make your files self-commenting.
For example, a common convention in a typical Linux configuration file is to use spaces and order
127.0.0.1 localhost localhost.localdomain 192.168.1.5 windbag windbag.kewldomain.net
If you forget and use a comma, or get your options in the wrong order, it won't work. With XML you
can explicitly define each element:
<?xml version="1.0"?> < hosts> < localhost ip="127.0.0.1" hostname="localhost" domain_name="localdomain" </localhost> <lan_hosts ip="192.168.1.5" hostname="windbag" domain_name="kewldomain.net" </lan_hosts>
So you don't have to worry about how to delimit spaces or what order to put options in, and
searching for specific elements is dead easy, so changes are swift and sure.
Typing rafts of tags is less than fun. Fortunately the world is overfull of XML editors to lighten
the load, and of course good old Unix standbys like Emacs, Vi, Joe, and other text editors can be
customized to apply tags with simple keystrokes.
Of course there is more to this than simply applying a few tags. You need a schema file, and
any XML pages that are displayed online need a corresponding stylesheet. w3schools has an excellent
online tutorial. So there is no need to fear
being swept away by the rising tide of XML-formatted configuration files. And anyway there is plenty
of time to get up to speed- you can't convert existing configuration files without making their
applications XML-aware, so for once we have the luxury of time.