Date: 26 Mar 2001 15:21:23 -0500 From: Randell Jesup <rjesup@wgate.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Jack Rusher <jar@integratus.com>, Andrew Reilly <areilly@bigpond.net.au>, Jordan Hubbard <jkh@osd.bsdi.com>, jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML? Message-ID: <ybuae68mgcc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Mon, 26 Mar 2001 10:03:59 -0800" References: <200103261804.f2QI4rR06049@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> writes:
>I think it has less to do with offending people than having an O/S that
>is compatible with the other UNIX O/S's out there. For example,
>syslog.conf, services, protocols, inetd.conf, to name a few can be
>maintained and copied to FreeBSD, Linux (excepting inetd.conf),
>Solaris, Tru64-UNIX, AIX, DG-UX, and HP/UX, just to name a few. I for
>one would stop using FreeBSD if I lost the capability to leverage my
>time by copying, merging, or editing config files between the various
>platforms I support -- in other words if the 20% of the systems I
>maintain require 80% of my time to maintain them I will look for other
>solutions to reduce my workload. There are enough issues of platform
>incompatibility between the various UNIX platforms out there without
>going out of our way to create new incompatibilities.
This is a very good point.
>In regards to FreeBSD-only config files like login.conf or
>login.access, I don't care what format they are in as long as it's
>intelligent.
Which makes them a good place to start.
>Rather than stand in the way of progress, having the new config file
>format adopted by most of the major vendors would go a long way to
>mitigate many fears people have about a new super-config file format.
>Another way we can mitigate these concerns is to support two formats
>until the other popular UNIX systems (Solaris, AIX, Tru64-UNIX, HP/UX,
>DG-UX) catch up. How we go about addressing these concerns doesn't
>matter at this point. (I do have some implementation ideas but I am
>purposely not discussing them as implementation details should not be
>discussed until our policy has been decided.) What does matter is that
>we do address the compatibility issues before making any sort of
>decision.
Certainly. There are some possible tricks for dealing with
the compatibility issues, especially if we can have some sort of
programmatic conversion (especially if it can work both ways).
This is a little like how we handle /etc/passwd, but with two-way
automatic conversions.
For example, if you changed /etc/all_network_stuff.xml, the system
may go and rewrite /etc/resolv.conf; and if you modify /etc/resolv.conf,
the system might mirror the change into /etc/all_network_stuff.xml.
There may be other solutions, such as allowing a configuration
file to hold either old-style data or new-style XML; which allows the
admin to decide whether they want old or new style on a file-by-file
basis. The cost is supporting both parsers in the service using the file.
We've recently moved to XML to hold all our configuration data
which is used to set up large number of config files in the system
(network, various applications like apache, etc). Stuff like:
<SMTP>
<ConfigureFile Name="/etc/sendmail.cf">
<CopyFile Name="/etc/sendmail.cf.no-anti-spam">
<RegExp Expression="s/^DM.*/DMblah.blah.tvol.net/m"></RegExp>
</CopyFile>
<Postlude Action="chmod 644 /etc/sendmail.cf"></Postlude>
<Postlude Action="chown bin:bin /etc/sendmail.cf"></Postlude>
<Postlude action="kill -HUP `cat /var/run/sendmail.pid`"></Postlude>
</ConfigureFile>
<ConfigureFile Name="/etc/aliases">
<RegExp>
abuse: root
bin: root
daemon: root
[ SNIP ]
</RegExp>
<Postlude Action="newaliases"></Postlude>
</ConfigureFile>
<System Action="crontab -u cyrus /usr/local/cyrus/crontab"></System>
</SMTP>
This greatly simplifies setting up hundreds of machines and updating their
configurations; and makes a unified character-gui configuration interface
(that reads/modifies this config file) FAR simpler and easier to deal with.
The backend that installs these changes becomes quite simple.
Just an example.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuae68mgcc.fsf>