Date: Tue, 12 Aug 2008 15:36:32 +0300 From: Stefan Lambrev <stefan.lambrev@moneybookers.com> To: Adrian Penisoara <ady@freebsd.ady.ro> Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD Message-ID: <48A183D0.6070901@moneybookers.com> In-Reply-To: <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <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. > 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 "freebsd-hackers-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48A183D0.6070901>