Idea for FreeBSD

Thu Aug 7 23:53:40 UTC 2008

I am surprised by the overwhelming response that this thread has acquired.
I have spent the majority of the day reading all the responses that
everyone has put forward. I would like to clear a few things up, comment
on others, and suggest some solutions to a lot of good points that
everyone has made so far.

First let me reiterate a few things. I started in FreeBSD and it will
always be my first love. Second, keep in mind that Solaris is a commercial
product and must be viewed as such.

Now that that is out of the way. I want to make it clear to everyone that
I was not suggesting the idea of copying or reproducing any part of how
Sun manages or implements its services; only the CONCEPT of how they do
it. It does not have to be XML, or in a database or anything else.
Actually I am thinking more along the lines of a wrapper that can
read/modify/execute from rc.d and the rc.conf. After all, we do not want
to make drastic changes. No one wants to re-write rc's or move them to
another location. Even solaris still relies on rc scripts to exist. And I
am sure I speak for all of us when I say that we all love the concept of
how rc.conf handles everything.

As some people have already pointed out multiple times so far, the idea of
an enable/disable is a great idea. Maybe we can start with that and see
how it goes and develop further based on
need/requirements/accomplishments.

I think a drop-in command like "rcadm" (someone mentioned this as an idea,
but cant remember who) would be a good start for managing the states of
services. Mike Meyer also brought up many good points that I agree with.
Please try not to get caught up in the XML stuff, that is not a
requirement or suggestion, it is just an example of how Sun did it, now
how FreeBSD has to;)

Someone recommended Puppet, but this is an entire framework that would
have to be added/implemented and configured to work with FreeBSD as well
as learning a new markup language for it. launchd has a lot of good ideas,
but I am not sure how mature it is yet; maybe it is a good place to start.

If we start with the basics and break it down and program this from a
modular standpoint it is not so bad. Begin with the basic (high-level)
approach. A shell script (service) that is aware of where rc scripts are
located and that can keep track of what the current state of the services
(PID's) are. An enable/disable command is nothing more that throwing a
start/stop command to these rc files. The rc.conf can assist with knowing
what should be enabled/disabled and what flags to throw at it. For
EXAMPLE!!!!, (you got that, example only) Solaris uses one master service
that is started first, and the whole point of that first service is to
monitor the other services and know what state they are in and starts
dependent services upon boot. Consider it the service manager almost.

I could go on plenty about different ways this concept could be
implemented but lets not go in the weeds to deep. A systematic approach to
this would be the basics. Lets start with the idea of a enable/disable and
go from there.

On a side not, I am impressed with many of the points that were made and
ideas already generated and all within less than 24 hours. I am glad I
joined this list. Thank you all.

> 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 would like to submit the idea of implementing a similar environment
> into FreeBSD. After looking through the developers links and googling I
> found no project for FreeBSD that implemented anything similar to this.
> I have included a link below to give a better understanding of SMF and
> its capabilities.
>
>    Is it possible, if it does not exist already, to look at the
> possibility of implementing the concept of SMF into FreeBSD? I would
> gladly be an active supporter in this endeavor.
>
>
> Will Bentley
> Future CIS
> 410-782-5954
> "Your resource for computer expertise!"
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>