Idea for FreeBSD

[Mike Meyer]

On Wed, 6 Aug 2008 22:34:51 -0400
"Michael B Allen" <ioplex at gmail.com> wrote:

> On Wed, Aug 6, 2008 at 7:14 PM,  <wbentley at futurecis.com> 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.

    <mike
-- 
Mike Meyer <mwm at mired.org>		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