Date: Tue, 12 Aug 2008 14:03:30 +0200 From: "Adrian Penisoara" <ady@freebsd.ady.ro> To: wbentley@futurecis.com Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Idea for FreeBSD Message-ID: <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> In-Reply-To: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10>