From owner-freebsd-arch Mon Mar 26 12:19:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id B170937B71B for ; Mon, 26 Mar 2001 12:19:30 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GN5Y6MKC; Mon, 26 Mar 2001 15:19:35 -0500 Reply-To: Randell Jesup To: Cy Schubert - ITSD Open Systems Group Cc: Jack Rusher , Andrew Reilly , Jordan Hubbard , jonathan@graehl.org, freebsd-arch@FreeBSD.ORG Subject: Re: configuration files, XML? References: <200103261804.f2QI4rR06049@cwsys.cwsent.com> From: Randell Jesup Date: 26 Mar 2001 15:21:23 -0500 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Mon, 26 Mar 2001 10:03:59 -0800" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group 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: abuse: root bin: root daemon: root [ SNIP ] 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