From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 7 23:53:39 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E185A106566C for ; Thu, 7 Aug 2008 23:53:39 +0000 (UTC) (envelope-from wbentley@futurecis.com) Received: from mail1.futurecis.com (static-72-66-21-14.washdc.fios.verizon.net [72.66.21.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9E58FC0A for ; Thu, 7 Aug 2008 23:53:39 +0000 (UTC) (envelope-from wbentley@futurecis.com) Received: (qmail 13225 invoked from network); 7 Aug 2008 23:25:40 -0000 Received: from unknown (HELO secure.futurecis.com) ([10.0.0.10]) (envelope-sender ) by mail1.futurecis.com (qmail-ldap-1.03) with SMTP for ; 7 Aug 2008 23:25:40 -0000 Received: from 130.76.96.17 (SquirrelMail authenticated user wbentley) by secure.futurecis.com with HTTP; Thu, 7 Aug 2008 19:20:27 -0400 (EDT) Message-ID: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> Date: Thu, 7 Aug 2008 19:20:27 -0400 (EDT) From: wbentley@futurecis.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 08 Aug 2008 02:04:41 +0000 Subject: Re: Idea for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 23:53:40 -0000 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. 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 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. 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. I could go on plenty about different ways this concept could be implemented but lets not go in the weeds to deep. A systematic approach to this would be the basics. Lets start with the idea of a enable/disable and go from there. On a side not, I am impressed with many of the points that were made and ideas already generated and all within less than 24 hours. I am glad I joined this list. Thank you all. > To who it may concern, > > I am A FreeBSD administrator as well as a Solaris Administrator. I use > BSD at home but Solaris at work. I love both OS's but I would like to > increase the administrative capability of FreeBSD. > > In Solaris 10 the Services Management Facility (SMF) was introduced. > Basically what it does, is take all the rc.d scripts and puts them into > a database to manage. Everything is converted to XML and two basic > commands (svcs and svcadm) are used to manage everything. > > I would like to submit the idea of implementing a similar environment > into FreeBSD. After looking through the developers links and googling I > found no project for FreeBSD that implemented anything similar to this. > I have included a link below to give a better understanding of SMF and > its capabilities. > > Is it possible, if it does not exist already, to look at the > possibility of implementing the concept of SMF into FreeBSD? I would > gladly be an active supporter in this endeavor. > > > Will Bentley > Future CIS > 410-782-5954 > "Your resource for computer expertise!" > > _______________________________________________ > 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" >