Idea for FreeBSD

[Matthew Seaman]

Jeremy Chadwick wrote:
> On Wed, Aug 06, 2008 at 07:14:51PM -0400, 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 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.

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.  

There are two connected questions here:

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

   * What functionality could or should be added to 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

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

	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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080807/d532fd22/signature.pgp