Adrian Penisoara wrote:
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, <[EMAIL PROTECTED]> 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.
There is commercial support for FreeBSD out there.
Actually the problem is that misinformed people are still spreading the
lie that there is not...
Also the example with Linux is very bad, where you have a "stable"
version only in enterprise RH or SuSe
and the vanilla kernel is only for development and beta testing .. I do
not want to see this happens to FreeBSD
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.
Like keywords - forcestart forcerestart forcestop ?!?!
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.
Some of us use FreeBSD because we think this is the proper way things to
be done, if we want another linux distro we may switch to *buntu ..
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.
Looks like we are reinventing inetd ?
Side note:what about starting up and monitoring services in jails,
probably we'd need one such master service per jail ?
Like inetd running in jail ?
My 5cents,
Overpriced ;) and good luck with enterprisebsd
Adrian.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
