Idea for FreeBSD

[Adrian Penisoara]

Hi,

 I'm a bit late to jump on board, but since I'm interested in the
subject and previously given some  thinking, here are my thoughts.

 And perhaps the freebsd-rc list is better suited.

On Fri, Aug 8, 2008 at 1:20 AM,  <wbentley at futurecis.com> wrote:
> 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.

 Good point. Like it happened in the Linux world, we should also have
some commercially backed versions of [Free]BSD in order to get better
visibility and business support (which, in the end, counts a lot).
That's why I've been thinking for some time about starting up the
EnterpriseBSD project (see http://launchpad.net/enterprisebsd). I
believe PC-BSD is a good start for the desktop.

>
> 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 also agree that it would be good for the rc.d scripts to
(re)configure themselves, since they are the ones who really know
what's best for them.

 While we're at it, I wish we could leverage the posibility for the
admin to manually start the service at the CLI, no matter whether the
service has been enabled or not -- that is the "<svc>_enable" keyword
should have effect only in the bootup/automatic contexts.

>
> 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.

Let's put another name on the table: Upstart (upstart.ubuntu.com).
It's quite fast.

>
> 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.

That would very important to for service crash recovery, to keep
critical services running.

Side note:what about starting up and monitoring services in jails,
probably we'd need one such master service per jail ?

My 5cents,
Adrian.