XML <-> non-XML filter project

Tue Mar 30 17:04:59 BST 1999

I like this idea and a few weeks ago was evangelizing a similar idea:
<diatribe id="OOXMLSysAdmin">
<note>Bear with me, there is a good XML tie in at the end...</note>
<problem>
I was considering what was wrong with the way that OS and application configuration is handled
typically.
Of course NT can be a nightmare because of registry problems and centrality.  Unix/Linux is
somewhat easier to manage but still needs changes distributed throughout a filesystem tree,
often with minor variations between Unix vendors, Linux, BSD, etc.
</problem>

Furthermore, there are a few obvious goals that come to mind in designing a perfect system
administration environment:

<goal>
Applications and OS modules should be 'object oriented' in the sense that as much as possible
all programs, data, files, temp space, logging, and especially configuration are stored in an
area partitioned from everything else in a predictable way.  This could mean that you have one
directory that contains everything and is referenced one way or another from all of the
appropriate subsystems.

</goal><goal>

Configuration should be straightfoward, portable (between OS's, hardware, etc.) and easily
editable in most circumstances.

</goal><goal>

Upgrading the OS to a new version, distribution, etc. should be trivial and not require
reinstalling all applications.  Conversely, it should be trivial to copy an application to
another system with the same OS.  This includes easy backups and restores.
</goal>

I can see two major ways to solve these problems:
<solution>
Modification to standard subsystems and/or OS initialization sequences to expect modular
installations of applications.  For instance, Oracle requires userid's in /etc/passwd, OS
parameter changes, daemon startup in /etc/rc.d/init.d, environment variables for all or most
users, etc. etc.  Normally you change all kinds of things, add it to your path, add the
libraries to your path, include directories, Java library to your CLASSPATH, etc.

All of this (everything except possibly allocation of data space, although that's feasible
also in simple or default cases) should go into /opt/oracle (for instance) in ways that are
automatically picked up by boot up and/or user login actions.  For instance, I typically
modify /etc/profile once to add /opt/*/bin to PATH and /opt/*/bin/lib/*.jar to CLASSPATH,
etc.  It would be fairly easy to add users virtually to /etc/passwd with PAM modifications.
System parameters could be computed by the max of all mentions in /opt/*/config/osparam.
Environments could have all /opt/*/config/profile contents 'sourced'.  Etc.

</solution><solution>

In fact, the base OS installation (say a Linux distribution) should be read-only and all
changes made in an logical 'overlay' tree.
</solution>

Because all of this requires cooperation with people defining the 'correct' way to do things
and those putting together distributions or OS versions, I came up with another way that is
almost equivalent:

<solution>
For many things, especially standard OS parameters, configuration can be indicated in a nearly
generic way by creating logical XML files in, say, /config.  These files could easily handle
most common configuration and be operated on by installers with a standard feature set but
which are built specifically for the operating system they run on.

As an example, /config/network.xml could contain system name, domain name, network IP
addresses, masks, routes, etc.  Services to start at boot and/or login could be listed and
controlled.  Users to add to the box could be configured.  Filesystems to export, etc.  These
files could be used on any OS and a local installer would know how to install the equivalent
configuration into native config files, along with restarting daemons or reloading
configuration.

This would completely eliminate, for many users and purposes, any problems with fluctuations
with how a particular Unix stores system name (which varies) or network configuration (which
varies), etc.  I have worked with something like 10-15 different Unix OS which all vary more
from a system administration standpoint than anything.  Oddly enough, this would work just as
well for Win98 or WinNT since the installer could update the registry appropriately.
</solution>

Is there some reason we haven't done this already?
</diatribe>

sdw

James Tauber wrote:

> Earlier this month, I posted the following to XSL-LIST. With apologies to
> those who received it there, I'm posting it (modified) here to see if anyone
> is interested in some co-operative effort in this area.
>
> What I would like to see is people taking existing non-XML formats and
> developing:
>
>      a) a URI for the non-XML format (for notations and for the namespace of
> the XML format)
>      b) a DTD representing the existing non-XML format
>      c) an output filter to convert documents conforming to the DTD into the
> non-XML format
>      d) (possibly) an input filter to convert the non-XML format into XML
>
> There are individual cases of this sort of thing[1] but I would like to see
> some sort of co-operative effort to produce a large number of these things.
> I'm not envisaging complex filters, just a simple XML representation of the
> non-XML format so that purely XML tools like editors, query engines, XSL
> engines can operate on non-XML formats. There are plently of applications
> including generation of these files on the basis of other XML documents (I
> need this for Makefiles on my websites) and literate programming.
>
> I would personally find great value in this being done for Makefiles,
> procmail files, simple shell scripts and PalmPilot databases. Others of
> value I can think of include Windows INI files, Unix mailboxes, your
> favourite programming language...
>
> If there is enough interest I am more than willing to coordinate these
> efforts. Just let me know.
>
> James
>
> [1] http://www.xmlsoftware.com/convert/
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

--
OptimaLogic - Finding Optimal Solutions     Web/Crypto/OO/Unix/Comm/Video/DBMS
sdw at lig.net   Stephen D. Williams  Senior Consultant/Architect   http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 5Jan1999

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)