Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... > 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@i... the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@i... the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@i...) -- OptimaLogic - Finding Optimal Solutions Web/Crypto/OO/Unix/Comm/Video/DBMS sdw@l... 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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
