XML is Coming to Your Administrative Toolbox

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.

By Carla Schroder | Posted Apr 26, 2005
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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.

Tradition!
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:

[!Global!]
IconName=kbackgammon
Comment=KBackgammon

[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

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter