Re: Idea for FreeBSD

[Matthew Seaman]

Jeremy Chadwick wrote:

On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] 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 and two basic
commands (svcs and svcadm) are used to manage everything.

I highly recommend you and anyone advocating the use of XML for such
things read the following whitepaper/study, in full:

http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf

Heh.  Loved all the little asides to Nancy... Amazing it hasn't been
fixed in 4 years.


There are two connected questions here:

  * What technology should be used to implement the FreeBSD rc.subr
    system?



Where the answer to the first question clearly constrains the results
of the second.  So what are the requirements for the rc system?  Off
the top of my head -- and I've probably missed some vital considerations
here -- in order of priority:

  1 reliability.  The system has to boot up.

  2 repeatability. The system has to boot up in a consistent state

  3 fault tolerance.  The system cannot fail to boot up unless the
    problems really are terminal.

  4 configurability.  The system has to boot up correctly for all
    conceivable combinations of hardware and software.

  5 portability.  Should run on anything from the smallest of
    embedded devices to the most enormous high power super computers
    to the most transient of virtualized hosts.

  6 manageability.  Must be comprehensible by ordinary mortals.

  7 efficiency.  Must bring the system up as fast as is practicable and
    without excessive use of system resources


here is rather less significant than indicated.  We already have a central
database of configuration information -- /etc/rc.conf -- and while we don't




        Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                 Kent, CT11 9PW

Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked applications. Which is fine, but as far as I can see doesn't address the question at hand. * What functionality could or should be added to the FreeBSD rc.subr system? What does XML-based technology bring to this? As the OP states the primary benefit is in manageability. I would contend that the advantage claimed have one single application to control starting and stopping services we have the next best thing: a consistent user interface for calling the individual rc-scripts. Indeed, as other posters have shown elsewhere in this thread, adding that sort of functionality is only a Small Matter of Programming using the existing tools. What's wrong wwith using XML? XML adds significantly to the complexity of an rc system -- it's suddenly necessary to have another shlib or two and several compiled applications available early in the boot process. XML itself is too general-purpose: it has too much baggage designed for its primary function of facilitating interoperation between diverse systems in different zones of control, none of which is particularly applicable to system startup. I can see the attraction of writing a nice pointy-clicky database-backed GUI management interface to encourage the uninitiated administrator, but that can only be an adjunct to the current setup, not a replacement. If you can't fix a broken system via a text only serial console accessed across whatever sort of low-bandwidth emergency connectivity you could imagine, then I suspect quite strongly it's not going to receive wholehearted community approval.

signature.asc
Description: OpenPGP digital signature