XML is Coming to Your Administrative Toolbox

by Carla Schroder

XML might seem like something for developers to worry about, but it's also driving change in the way you'll script and manage your systems. Here's a primer on why network admins should familiarize themselves with XML's basics.

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 XML?

Continued on page 2: Why You Need To Care

Continued From Page 1

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.

XML Advantages
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 functionally:	localhost	localhost.localdomain	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="" hostname="localhost" domain_name="localdomain" </localhost>
<lan_hosts ip="" 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.

Learning XML
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.


This article was originally published on Tuesday Apr 26th 2005