From owner-freebsd-rc@FreeBSD.ORG Tue Aug 12 12:31:54 2008 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039E91065680 for ; Tue, 12 Aug 2008 12:31:54 +0000 (UTC) (envelope-from ady@ady.ro) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id BEEC28FC1A for ; Tue, 12 Aug 2008 12:31:53 +0000 (UTC) (envelope-from ady@ady.ro) Received: by yw-out-2324.google.com with SMTP id 9so764942ywe.13 for ; Tue, 12 Aug 2008 05:31:53 -0700 (PDT) Received: by 10.142.207.8 with SMTP id e8mr2656876wfg.110.1218542610420; Tue, 12 Aug 2008 05:03:30 -0700 (PDT) Received: by 10.142.80.3 with HTTP; Tue, 12 Aug 2008 05:03:30 -0700 (PDT) Message-ID: <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> Date: Tue, 12 Aug 2008 14:03:30 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: wbentley@futurecis.com In-Reply-To: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> X-Google-Sender-Auth: a5861f9bd2fe2885 Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Idea for FreeBSD X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 12:31:54 -0000 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, 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 "_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.