From owner-freebsd-arch Mon Mar 26 10: 7: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id A66D937B719 for ; Mon, 26 Mar 2001 10:06:55 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA06684; Mon, 26 Mar 2001 10:05:11 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06682; Mon Mar 26 10:05:10 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f2QI54p58683; Mon, 26 Mar 2001 10:05:04 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdD58667; Mon Mar 26 10:04:53 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f2QI4rR06049; Mon, 26 Mar 2001 10:04:53 -0800 (PST) Message-Id: <200103261804.f2QI4rR06049@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdar6037; Mon Mar 26 10:03:59 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Jack Rusher Cc: Andrew Reilly , Jordan Hubbard , jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML? In-reply-to: Your message of "Mon, 26 Mar 2001 08:50:01 PST." <3ABF7339.B197AF34@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Mar 2001 10:03:59 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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