Date: Mon, 26 Mar 2001 10:03:59 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Jack Rusher <jar@integratus.com> Cc: 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: <200103261804.f2QI4rR06049@cwsys.cwsent.com> In-Reply-To: Your message of "Mon, 26 Mar 2001 08:50:01 PST." <3ABF7339.B197AF34@integratus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3ABF7339.B197AF34@integratus.com>, Jack Rusher writes:>
Andrew Reilly wrote:
> >
> > I really like the idea of a uniform and configurator-friendly
> > config management system. I'm not crazy about XML, but my
> > opinion on the subject hardly matters.
>
> XML certainly isn't the universal savior that it's made out to be, but
> it is a decent language for specifying other languages within
> constraints that more or less match what we are talking about. My
> feeling is that if a technology is widely adopted and good enough to get
> the job done, I'd rather use it than make up "yet another standard."
>
> > at once. None of the existing applications share config
> > formats, or rely on common mechanisms, so changing them one at a
> > time will have the positive effect of allowing for the necessary
> > user education process to be gradual. It also gives more room
>
> I agree with you completely. However, my biggest concern with such a
> project isn't that the technology will be dauntingly difficult, but
> rather that people won't want it. There is a sort of tension in this
> community between developing new technology and trying to make sure that
> we are as much like the Ghost of Unix past as possible. I am concerned
> that changing configuration file formats that have been static for
> twenty years might deeply offend some of the user (and developer) base.
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.
An example of copying, merging and editing is my "wrap" script I've
used for years to implement TCP/Wrappers on various platforms:
#!/usr/bin/awk -f
BEGIN {print"## Wrapped by OSG wrap script.\n##"}
$1 !~ /^#/ && $6 != "internal" && $6 !~ /tcpd/ && $6 ~ /sbin/ && $7 !~
/identd/ {print "## " $0;
print $1 "\t" $2 "\t" $3 "\t" $4 "\t" $5 "\t/usr/local/etc/tcpd\
t" $7 "\t" $8 " " $9}
$1 !~ /^#/ && $6 != "internal" && $6 !~ /tcpd/ && $6 !~ /sbin/ && $7
!~ /identd/ {print "## " $0;
print $1 "\t" $2 "\t" $3 "\t" $4 "\t" $5 "\t/usr/local/etc/tcpd\
t" $6 "\t" $8 " " $9}
$1 != "time" && $6 == "internal" {print "## " $0}
$1 == "time" {print $0}
$1 ~ /^#/ || $6 ~ /tcpd/ || $7 ~ /identd/ {print $0}
For example, changing inetd.conf's format would mean that I could use
this script everywhere except for FreeBSD (and RH Linux as RH uses
xinetd). (Our policy has been FreeBSD for servers and Linux or FreeBSD
for our desktops).
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.
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.
Don't read into this that I am offended that the config file format may
change. I do dislike having to vi a file on one platform only to have
to vi a similar file on another platform when all I'm trying to do is
implement a policy change across the 150+ systems. If I was running a
FreeBSD-only shop, I would not be concerned with this issue.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
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?200103261804.f2QI4rR06049>