From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 7 05:34:22 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1FDC106564A for ; Thu, 7 Aug 2008 05:34:22 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (five.mired.org [66.92.153.75]) by mx1.freebsd.org (Postfix) with ESMTP id 694C58FC1B for ; Thu, 7 Aug 2008 05:34:22 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 98582 invoked by uid 1001); 7 Aug 2008 01:06:41 -0400 Received: from bhuda.mired.org (bhuda [192.168.195.1]) by bhuda (tmda-ofmipd) with ESMTP; Thu, 07 Aug 2008 01:06:39 -0400 Date: Thu, 7 Aug 2008 01:06:38 -0400 To: "Michael B Allen" Message-ID: <20080807010638.267d7790@bhuda.mired.org> In-Reply-To: <78c6bd860808061934l133d8ca6nabbde8cd55cb1d27@mail.gmail.com> References: <78c6bd860808061934l133d8ca6nabbde8cd55cb1d27@mail.gmail.com> Organization: Meyer Consulting X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; amd64-portbld-freebsd7.0) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Cc: hackers@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 05:34:22 -0000 On Wed, 6 Aug 2008 22:34:51 -0400 "Michael B Allen" wrote: > On Wed, Aug 6, 2008 at 7:14 PM, wrote: > > To who it may concern, > > > > I am A FreeBSD administrator as well as a Solaris Administrator. I use > > BSD at home but Solaris at work. I love both OS's but I would like to > > increase the administrative capability of FreeBSD. > > > > In Solaris 10 the Services Management Facility (SMF) was introduced. > > Basically what it does, is take all the rc.d scripts and puts them into > > a database to manage. Everything is converted to XML > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. Give the right tools, editing XML is actually reasonable. The right tools are a schema for the documents in question, a schema-aware editor, and applications software that bitches if the document doesn't match the schema. The problem is that you almost never get a schema, and having an application that cares is even rarer. Without those, you're best off using application tools to manipulate the documents, and never touching it except for emergencies. In which case: > But of course the format of data in a database is largely irrelevant. > You could implement the same thing with dbm files or a more forgiving > text format. Right. For that matter, you could leave the data in shell scripts, and build a layer of meta information and tools to manipulate these things - which is similar to what I see in Linux distros. The Solaris smf tools provide some nice facilities: one is single interface to start, stop, check and restart all the services on a system. We pretty much have that, as they all use the same basic arguments to their rc scripts. The only issue is figuring out which directory to find the rc script in. The other is a single interface to enable, disable and query the status of all the services. All we really have is the last one: you can run the script with the rcvar argument, and it'll list the appropriate variable if it's set, and the value it's set to. Maybe. Not all of them support this yet. > As for getting rid of rc.d scripts, yes they're decrepit and I would > love to see them go but they're simple and third party software may > depend on them being the norm. The only thing decrepit about the rc.d scripts is that they don't all support the latest facilities that you'd expect them to. But the way to fix that is to update the old ones, not to throw out all of them and start over. In particular, if you want to replace them with a better format, you need to start by showing that said format is better - and chanting buzzwords like "xml" isn't sufficient to do that. You could, for instance, get all of the facilities of svcs with a shell script that grokked the current rc.d formats. Searching wouldn't be quite as spiffy because we don't have the concept of an FMRI, and getting the output formatting facilities right would be a bit tricky, but the information is pretty much all there. svcadm is a bit harder, because you'd have to edit rc.conf in place, but again, most of the pieces are already in place. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org