Re: Idea for FreeBSD
On Aug 12, 2008, at 5:14 AM, Jonathan McKeown wrote: On Tuesday 12 August 2008 14:03:30 Adrian Penisoara wrote: 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. Isn't this what onestart does? Jonathan I may be a bit late into the conversation, but for what it's worth upstart does have some positive features in the 0.5.0 version (the one that just rolled off the SVN train recently). Their use of simple and complex job start criteria and the ability to link in process monitoring functionality via DBUS clients is interesting... albeit not necessary except in high availability environments. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Wed, Aug 13, 2008 at 1:40 AM, Vincent Hoffman <[EMAIL PROTECTED]> wrote:
> Jonathan McKeown wrote:
>> On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote:
>>> On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara"
>>> Ok, given that you 1) want to have both " this service if it's
>>> part of our normal runtime" and " this service even if it's not
>>> part of our normal runtime" as script commands, and that 2)
>>> without a prefix gets the "if it's part of our normal runtime"
>>> meaning, as we want the user to have to explicitly say "Yes, I know
>>> this looks odd, but I know what I'm doing so do it anyway" to get the
>>> "even if it's not part of our normal runtime" behavior, then what
>>> would you have us use instead of "force"?
>>>
>> People keep talking about forcestart.
>>
>> Unless I'm misunderstanding things horribly, forcestart does exactly that
>> - forces the service to start regardless of any error that may occur.
>>
>> The better option for starting something as a one-off (not enabled in
>> rc.conf) is mnemonically named onestart - which only ignores the rcvar but
>> still fails on any other error.
>>
>> And yes, I like having onestart/onestop distinguished from start/stop.
>>
> I believe it "forces" a start even though its not actually enabled (in
> rc.conf) rather than regardless of errors.
> If you really want a command line of onestart/onestop install the
> sysutils/bsdadminscripts port which has a script called rconestart and
> rconestop which do exactly that ;)
>From /etc/rc.subr:
# run_rc_command argument
# Search for argument in the list of supported commands, which is:
# "start stop restart rcvar status poll ${extra_commands}"
# If there's a match, run ${argument}_cmd or the default method
# (see below).
#
# If argument has a given prefix, then change the operation as follows:
# Prefix Operation
# -- -
# fastSkip the pid check, and set rc_fast=yes
# force Set ${rcvar} to YES, and set rc_force=yes
# one Set ${rcvar} to YES
Further in the file:
case "$rc_arg" in
fast*) # "fast" prefix; don't check pid
rc_arg=${rc_arg#fast}
rc_fast=yes
;;
force*) # "force prefix; always run
rc_force=yes
_rc_prefix=force
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n "${rcvar}" ]; then
eval ${rcvar}=YES
fi
;;
one*) # "one" prefix; set ${rcvar}=yes
_rc_prefix=one
rc_arg=${rc_arg#${_rc_prefix}}
if [ -n "${rcvar}" ]; then
eval ${rcvar}=YES
fi
;;
esac
Which, if I follow things, means:
** "/etc/rc.d/$script faststart" won't check for existing PID files
or already running apps, and just run $script, but still checks if
$script_enable=yes is in /etc/rc.conf.
** "/etc/rc.d/$script onestart" sets $script_enable=yes internally,
regardless of what is in rc.conf, and runs $script. All other checks
are done as per normal.
** "/etc/rc.d/$script forcestart" runs $script, regardless of what's
in rc.conf, the status of the PID file, or the existence of an already
running daemon.
What most people in this thread are looking for is onestart.
--
Freddie Cash
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Quoting "Kurt J. Lidl" <[EMAIL PROTECTED]> (from Thu, 7 Aug 2008 16:20:42 -0400): On Thu, Aug 07, 2008 at 07:02:30PM +1000, Peter Jeremy wrote: On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: > In Solaris 10 the Services Management Facility (SMF) was introduced. The main purpose of SMF appears to be to drum up business for Sun's training courses by radically changing Sol10 Administration for little benefit. The main purpose of SMF was to make it possible to programmatically control the system and deal with the myriad of different types of faults from the gazillion different things that people want to run on machines. It's complex because it has to deal with the real world. There's also some sort of functionality included, which is comparable with daemontools (depending if you enable this in the xml description or not). You could say this is included in your "deal with ... faults" above, but for people not aware of this it may be nice to know. Bye, Alexander. -- Life may have no meaning, or, even worse, it may have a meaning of which you disapprove. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
Jonathan McKeown wrote: On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote: On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: Umm, I have used Gentoo and I do not remember having to use "forcestart" at the command line... Ok, given that you 1) want to have both " this service if it's part of our normal runtime" and " this service even if it's not part of our normal runtime" as script commands, and that 2) without a prefix gets the "if it's part of our normal runtime" meaning, as we want the user to have to explicitly say "Yes, I know this looks odd, but I know what I'm doing so do it anyway" to get the "even if it's not part of our normal runtime" behavior, then what would you have us use instead of "force"? People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. I believe it "forces" a start even though its not actually enabled (in rc.conf) rather than regardless of errors. If you really want a command line of onestart/onestop install the sysutils/bsdadminscripts port which has a script called rconestart and rconestop which do exactly that ;) Vince Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Tuesday 12 August 2008 17:51:32 Mike Meyer wrote: > On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: > > > > Umm, I have used Gentoo and I do not remember having to use > > "forcestart" at the command line... > > Ok, given that you 1) want to have both " this service if it's > part of our normal runtime" and " this service even if it's not > part of our normal runtime" as script commands, and that 2) > without a prefix gets the "if it's part of our normal runtime" > meaning, as we want the user to have to explicitly say "Yes, I know > this looks odd, but I know what I'm doing so do it anyway" to get the > "even if it's not part of our normal runtime" behavior, then what > would you have us use instead of "force"? People keep talking about forcestart. Unless I'm misunderstanding things horribly, forcestart does exactly that - forces the service to start regardless of any error that may occur. The better option for starting something as a one-off (not enabled in rc.conf) is mnemonically named onestart - which only ignores the rcvar but still fails on any other error. And yes, I like having onestart/onestop distinguished from start/stop. Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
Stefan Lambrev wrote: Mike Meyer wrote: On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: 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. Like keywords - forcestart forcerestart forcestop ?!?! Yes, I am always reminded of that :). Well, to tell you the truth, I do not know of any other OS which requires prefixing with "force" the start/stop actions in order to act on the service at the command line, and personally I wish it weren't the case. Well I bet you can find this in most linux distros that copy FreeBSD. What about gentoo? Umm, I have used Gentoo and I do not remember having to use "forcestart" at the command line... Ok, given that you 1) want to have both " this service if it's part of our normal runtime" and " this service even if it's not part of our normal runtime" as script commands, and that 2) without a prefix gets the "if it's part of our normal runtime" meaning, as we want the user to have to explicitly say "Yes, I know this looks odd, but I know what I'm doing so do it anyway" to get the "even if it's not part of our normal runtime" behavior, then what would you have us use instead of "force"? Personally, I think "start -f" or "start --force" might have been better, but it's to late to fix such a minor thing. I think the idea (behind not using force) is to implement something like in RH where there is a number of folders (for every run level) populated with links to the real rc scripts which are in /etc/init.d/ and when you type /etc/init.d/script start it will be started but the boot up rc.scripts will never do start on /etc/init.d/ itself only on the folder with links. It's not much better (or worse?) then the current system in freebsd, so I do not see why we should bother. http://en.wikipedia.org/wiki/Init I hate sysV style init myself, half of why I moved to *BSD Vince ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: > 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. > >>> Like keywords - forcestart forcerestart forcestop ?!?! > >> Yes, I am always reminded of that :). > >> Well, to tell you the truth, I do not know of any other OS which > >> requires prefixing with "force" the start/stop actions in order to act > >> on the service at the command line, and personally I wish it weren't > >> the case. > > Well I bet you can find this in most linux distros that copy FreeBSD. What > > about gentoo? > Umm, I have used Gentoo and I do not remember having to use > "forcestart" at the command line... Ok, given that you 1) want to have both " this service if it's part of our normal runtime" and " this service even if it's not part of our normal runtime" as script commands, and that 2) without a prefix gets the "if it's part of our normal runtime" meaning, as we want the user to have to explicitly say "Yes, I know this looks odd, but I know what I'm doing so do it anyway" to get the "even if it's not part of our normal runtime" behavior, then what would you have us use instead of "force"? Personally, I think "start -f" or "start --force" might have been better, but it's to late to fix such a minor thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
Mike Meyer wrote: On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: 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. Like keywords - forcestart forcerestart forcestop ?!?! Yes, I am always reminded of that :). Well, to tell you the truth, I do not know of any other OS which requires prefixing with "force" the start/stop actions in order to act on the service at the command line, and personally I wish it weren't the case. Well I bet you can find this in most linux distros that copy FreeBSD. What about gentoo? Umm, I have used Gentoo and I do not remember having to use "forcestart" at the command line... Ok, given that you 1) want to have both " this service if it's part of our normal runtime" and " this service even if it's not part of our normal runtime" as script commands, and that 2) without a prefix gets the "if it's part of our normal runtime" meaning, as we want the user to have to explicitly say "Yes, I know this looks odd, but I know what I'm doing so do it anyway" to get the "even if it's not part of our normal runtime" behavior, then what would you have us use instead of "force"? Personally, I think "start -f" or "start --force" might have been better, but it's to late to fix such a minor thing. I think the idea (behind not using force) is to implement something like in RH where there is a number of folders (for every run level) populated with links to the real rc scripts which are in /etc/init.d/ and when you type /etc/init.d/script start it will be started but the boot up rc.scripts will never do start on /etc/init.d/ itself only on the folder with links. It's not much better (or worse?) then the current system in freebsd, so I do not see why we should bother. -- 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]"
FreeBSD in Business (was Re: Idea for FreeBSD)
Hi, On Tue, Aug 12, 2008 at 4:52 PM, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >> I'm not sure where is that remark headed to. And I don't think >> (re)packaging a business-centric version would harm -- please correct >> me if I'm wrong. >> > > The problem with "enterprise" is that they ship their own kernel which is > heavily modified. Not one, but rather multiple kernels (which includes the generic one). Which otherwise are possible to build with the vanilla distro, but it might take a lot of tweaking time to get there and you got no QA for that either. > If you want enterprise go for OSX :) I think it's the best enterprise BSDish > system ;) Why not help the people already using FreeBSD at their workplace get better arguments to keep and grow the FreeBSD base ? ;) > Also there are more packages for FreeBSD available then for RH, and I can > assure you that > all programs that you actually use (like ssh, apache, perl and etc) you have > to manually compile to fit your needs. I tend to disagree in this particular context -- business usage relies on stability which implies a small set of very well tested packages, not necessarily the latest version. >> >> 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. >>> >>> Like keywords - forcestart forcerestart forcestop ?!?! >>> >> >> Yes, I am always reminded of that :). >> Well, to tell you the truth, I do not know of any other OS which >> requires prefixing with "force" the start/stop actions in order to act >> on the service at the command line, and personally I wish it weren't >> the case. >> > > Well I bet you can find this in most linux distros that copy FreeBSD. What > about gentoo? Umm, I have used Gentoo and I do not remember having to use "forcestart" at the command line... > Anyway I think that the beauty of the current rc/ng system in freebsd is > that it's very easy to understand and use it. > Not like those nasty XML config files that makes you blind. > There are small fixes that can be applied to make the system even better, > but rewriting it just for the sport looks like wasting too much power :) > But after all FreeBSD innovate do not imitate ;) > > Anyway it's may be just me, but I do not think that the rc system in freebsd > is the showstopper, that needs funding or more ppl looking at it. Right. And I'm going to stop here -- if you want to continue we can go off-the-list. > And btw burdening the rc subsystem to monitor your daemons is overkill too. > It will never work as good as real monitoring software, > and will only bloat things. There are tons of utilities that can do this. Umm, one should not need huge monitoring software packages to accomplish such (simple?) tasks. The inittab/ttys systems comes to my mind when I say this... ;). Over & out, Adrian. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Adrian Penisoara wrote: Hi, On Tue, Aug 12, 2008 at 2:36 PM, Stefan Lambrev <[EMAIL PROTECTED]> wrote: 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... OK, I will reword that a bit: I believe having also a "business" face for the business market will help a lot in increasing visibility. 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 I'm not sure where is that remark headed to. And I don't think (re)packaging a business-centric version would harm -- please correct me if I'm wrong. The problem with "enterprise" is that they ship their own kernel which is heavily modified. If you want enterprise go for OSX :) I think it's the best enterprise BSDish system ;) Also there are more packages for FreeBSD available then for RH, and I can assure you that all programs that you actually use (like ssh, apache, perl and etc) you have to manually compile to fit your needs. 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. Like keywords - forcestart forcerestart forcestop ?!?! Yes, I am always reminded of that :). Well, to tell you the truth, I do not know of any other OS which requires prefixing with "force" the start/stop actions in order to act on the service at the command line, and personally I wish it weren't the case. Well I bet you can find this in most linux distros that copy FreeBSD. What about gentoo? Anyway I think that the beauty of the current rc/ng system in freebsd is that it's very easy to understand and use it. Not like those nasty XML config files that makes you blind. There are small fixes that can be applied to make the system even better, but rewriting it just for the sport looks like wasting too much power :) But after all FreeBSD innovate do not imitate ;) Anyway it's may be just me, but I do not think that the rc system in freebsd is the showstopper, that needs funding or more ppl looking at it. And btw burdening the rc subsystem to monitor your daemons is overkill too. It will never work as good as real monitoring software, and will only bloat things. There are tons of utilities that can do this. -cut- -- 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]"
Re: Idea for FreeBSD
Hi, On Tue, Aug 12, 2008 at 2:36 PM, Stefan Lambrev <[EMAIL PROTECTED]> wrote: >>> >>> 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... OK, I will reword that a bit: I believe having also a "business" face for the business market will help a lot in increasing visibility. > > 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 I'm not sure where is that remark headed to. And I don't think (re)packaging a business-centric version would harm -- please correct me if I'm wrong. >> 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. >> > > Like keywords - forcestart forcerestart forcestop ?!?! Yes, I am always reminded of that :). Well, to tell you the truth, I do not know of any other OS which requires prefixing with "force" the start/stop actions in order to act on the service at the command line, and personally I wish it weren't the case. >>> 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 .. Oh, we are debating here, not imposing personal preferences :). Good ideas can come up from any direction, it's up to us whether we want to learn from them. >>> 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 ? Inetd is only for multiplexing seldomly used network services bound to specific ports -- not too many real-life services fall under this exact specification. >> >> 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 Well, that was usually conceived as a contribution, not a price. Ideas are free anyway ;). Thanks. Adrian. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Tuesday 12 August 2008 14:03:30 Adrian Penisoara wrote: > 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. Isn't this what onestart does? Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
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 "_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. __
Re: Idea for FreeBSD
Adrian Penisoara wrote: 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. /etc/rc.d/$service forcestart seems to be what you want. I do like the idea of being able to enable/disable services from the rc scripts as /etc/rc.d/$service rcvar | sed 's/NO/YES/' >> /etc/rc.conf and/or editing rc.conf can feel a little clunky at times. Vince 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
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. > > 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Idea for FreeBSD
> On Behalf Of Wilkinson, Alex > Sent: Thursday, August 07, 2008 6:34 AM > To: freebsd-hackers@freebsd.org > Subject: Re: Idea for FreeBSD > > > 0n Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: > > >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. > > I believe there was a port of MacOS-X 'launchd' to FreeBSD: > > [http://wiki.freebsd.org/launchd] > > I think launchd may use XML. Tyler has made no changes to the above mentioned wiki page since 2005-11-01. We can only assume that the project is dead. Rudi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Fri, Aug 08, 2008 at 09:57:07AM +0100, Vincent Hoffman wrote: > > On Thu, Aug 07, 2008 at 11:25:39AM -0400, Mike Meyer wrote: > >> On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote: > >>> [1]: > >>> $cat /usr/local/bin/service > >> Basically what I had in mind, but it can be made more portable across > >> FreeBSD configurations. > > [...] > >> And here's where you go wrong. What you want now is: > > Yes. This is more correct: > > > Just to save reimplementing the wheel, have a look also at the > sysutils/bsdadminscripts port. it has rcstart (and various hardlinks,) > which are intended for pretty much what youre intending I think. Too late, I think. This wheel was reimplemented, and quite some time ago ;-) Anyway, thanks for the pointer. I'll check on the weekends if pkg_libchk from bsdadminscripts is a suitable replacement for sysutils/libchk. -- Adios ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Fri, Aug 08, 2008 at 12:19:54PM +0200, Dag-Erling Smørgrav wrote: > Alex Kozlov <[EMAIL PROTECTED]> writes: > > Matthew Seaman <[EMAIL PROTECTED]> writes: > > > [...] XML itself is too general-purpose: it has too much baggage > > > designed for its primary function of facilitating interoperation > > > between diverse systems in different zones of control, none of which > > > is particularly applicable to system startup. > > While in general I agree with You, I must note that We already have > > xml parser (expat 1.95) for geom. See /lib/libbsdxml.so* > Non sequitur. The fact that we have an XML parser in base does not make > XML more (or less) suitable for the task. I never said anything like this. Only that argument about 'to have another shlib or two... available early in the boot process' is invalid. -- Adios ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Alex Kozlov <[EMAIL PROTECTED]> writes: > Matthew Seaman <[EMAIL PROTECTED]> writes: > > [...] XML itself is too general-purpose: it has too much baggage > > designed for its primary function of facilitating interoperation > > between diverse systems in different zones of control, none of which > > is particularly applicable to system startup. > While in general I agree with You, I must note that We already have > xml parser (expat 1.95) for geom. See /lib/libbsdxml.so* Non sequitur. The fact that we have an XML parser in base does not make XML more (or less) suitable for the task. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Alex Kozlov wrote:
On Thu, Aug 07, 2008 at 11:25:39AM -0400, Mike Meyer wrote:
On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
[1]:
$cat /usr/local/bin/service
Basically what I had in mind, but it can be made more portable across
FreeBSD configurations.
[...]
And here's where you go wrong. What you want now is:
Yes. This is more correct:
Just to save reimplementing the wheel, have a look also at the
sysutils/bsdadminscripts port. it has rcstart (and various hardlinks,)
which are intended for pretty much what youre intending I think.
Vince
#!/bin/sh
name=$1
cmd=$2
if [ -z "${name}" -o -z "${cmd}" ]; then
echo ${0##*/} service_name command
exit 3
fi
. /etc/rc.subr
load_rc_config ${name}
for dir in /etc/rc.d ${local_startup}; do
if [ -r "${dir}/${name}" ]; then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]; then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
echo "service '${name}' not found"
exit 2
--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 11:25:39AM -0400, Mike Meyer wrote:
> On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
> > [1]:
> > $cat /usr/local/bin/service
>
> Basically what I had in mind, but it can be made more portable across
> FreeBSD configurations.
>
[...]
>
> And here's where you go wrong. What you want now is:
Yes. This is more correct:
#!/bin/sh
name=$1
cmd=$2
if [ -z "${name}" -o -z "${cmd}" ]; then
echo ${0##*/} service_name command
exit 3
fi
. /etc/rc.subr
load_rc_config ${name}
for dir in /etc/rc.d ${local_startup}; do
if [ -r "${dir}/${name}" ]; then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]; then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
echo "service '${name}' not found"
exit 2
--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
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 "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 07:02:30PM +1000, Peter Jeremy wrote: > On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: > > In Solaris 10 the Services Management Facility (SMF) was introduced. > > The main purpose of SMF appears to be to drum up business for Sun's > training courses by radically changing Sol10 Administration for little > benefit. The main purpose of SMF was to make it possible to programmatically control the system and deal with the myriad of different types of faults from the gazillion different things that people want to run on machines. It's complex because it has to deal with the real world. > >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. Actually, the inputs to the database are in XML, and this is distilled down to a binary representation in a sqlite database that actually drives the system. While the "svccfg" and "svcadm" interfaces do give you a single manner of dealing with the database (svccfg) and then the state of a given service (svcadm). The other thing that the SMF system captures entirely is the dependencies between the different daemons and services. I'm not sure that the rcorder stuff in FreeBSD is quite as complete. It could be, I just don't know. Also, there is versioning for the changes of the sqlite database in Solaris, so you can punt back to a earlier configuration without much hassle. > With FreeBSD, I can configure virtually all the system via a single > text file - which is easily found and kepy under configuration control. > With Sol10, there are random bits of configuration spread all over the > system and there is no obvious way to control configuration. Well, realistically, the sum of the files in /etc/rc.d and /usr/local/etc/rc.d are also needed, and you need a snapshot of all of those at a given instant in time to provably know how the system is going to configure when booted. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, Aug 06, 2008 at 11:16:36PM -0700, Tim Kientzle wrote: > >The Solaris smf tools provide some nice facilities: one is single > >interface to start, stop, check and restart all the services on a > >system. We pretty much have that ... > >The other is a single interface to enable, disable and query the > >status of all the services. All we really have is the last one... > > Sounds like the only missing pieces, then, are standard > ways to enable, disable, and configure services. How about: > > sudo /etc/rc.d/ssh enable > sudo /etc/rc.d/ssh disable > sudo /etc/rc.d/ssh configure > > That shouldn't be much of a stretch to implement, either. > The first two just append entries to /etc/rc.conf. The > third opens an editor with a list of variables supported > by this service and then appends the result to rc.conf. Pretty much the same came to my mind some weeks ago. I'd propose a "rcadm" command like Solaris' svcadm, so you do not need to care about if the rc script is in /etc/rc.d or in /usr/local/etc/rc.d. And it would be safer to check if the service is already listed in rc.conf, so it doesn't get appended every time you enable a service. pgp4PjNWFD9J7.pgp Description: PGP signature
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 11:29:49AM +0100, Matthew Seaman wrote: > Jeremy Chadwick wrote: > > On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: > >> 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 highly recommend you and anyone advocating the use of XML for such > > things read the following whitepaper/study, in full: > > > > http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf > > > > Heh. Loved all the little asides to Nancy... Amazing it hasn't been > fixed in 4 years. > > Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked > applications. Which is fine, but as far as I can see doesn't address the > question at hand. > > There are two connected questions here: > >* What technology should be used to implement the FreeBSD rc.subr > system? > >* What functionality could or should be added to the FreeBSD rc.subr > system? > > Where the answer to the first question clearly constrains the results > of the second. So what are the requirements for the rc system? Off > the top of my head -- and I've probably missed some vital considerations > here -- in order of priority: > >1 reliability. The system has to boot up. > >2 repeatability. The system has to boot up in a consistent state > >3 fault tolerance. The system cannot fail to boot up unless the > problems really are terminal. > >4 configurability. The system has to boot up correctly for all > conceivable combinations of hardware and software. > >5 portability. Should run on anything from the smallest of > embedded devices to the most enormous high power super computers > to the most transient of virtualized hosts. > >6 manageability. Must be comprehensible by ordinary mortals. > >7 efficiency. Must bring the system up as fast as is practicable and > without excessive use of system resources > > What does XML-based technology bring to this? As the OP states the primary > benefit is in manageability. I would contend that the advantage claimed > here is rather less significant than indicated. We already have a central > database of configuration information -- /etc/rc.conf -- and while we don't > have one single application to control starting and stopping services we > have the next best thing: a consistent user interface for calling the > individual rc-scripts. Indeed, as other posters have shown elsewhere in > this thread, adding that sort of functionality is only a Small Matter of > Programming using the existing tools. > > What's wrong wwith using XML? XML adds significantly to the complexity of > an rc system -- it's suddenly necessary to have another shlib or two and > several compiled applications available early in the boot process. XML > itself is too general-purpose: it has too much baggage designed for its > primary function of facilitating interoperation between diverse systems in > different zones of control, none of which is particularly applicable to > system startup. While in general I agree with You, I must note that We already have xml parser (expat 1.95) for geom. See /lib/libbsdxml.so* -- Adios ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, 06 Aug 2008 23:16:36 -0700 Tim Kientzle <[EMAIL PROTECTED]> wrote: > > The Solaris smf tools provide some nice facilities: one is single > > interface to start, stop, check and restart all the services on a > > system. We pretty much have that ... > > > > The other is a single interface to enable, disable and query the > > status of all the services. All we really have is the last one... > > Sounds like the only missing pieces, then, are standard > ways to enable, disable, and configure services. How about: > >sudo /etc/rc.d/ssh enable >sudo /etc/rc.d/ssh disable >sudo /etc/rc.d/ssh configure > > That shouldn't be much of a stretch to implement, either. > The first two just append entries to /etc/rc.conf. The > third opens an editor with a list of variables supported > by this service and then appends the result to rc.conf. Well, that might work, but could lead to unintended consequences if you start missing settings from two different configure runs by continually appending without deleting the old settings. load_rc_config already sources /etc/rc.conf.d/"$_name". Working with that file instead of /etc/rc.conf would seem to be a cleaner solution. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
> [1]:
> $cat /usr/local/bin/service
Basically what I had in mind, but it can be made more portable across
FreeBSD configurations.
> #!/bin/sh
>
> name=$1
> cmd=$2
>
> . /etc/rc.subr
> if [ -z "${name}" -o -z "${cmd}" ]
> then
> echo ${0##*/} service_name command
> exit 3
> fi
>
>
> if [ -r "/etc/rc.d/${name}" ]
> then
> run_rc_script "/etc/rc.d/${name}" ${cmd}
> exit 0
> fi
And here's where you go wrong. What you want now is:
for dir in $local_startup; do
if [ -r "${dir}/${name}" ]
then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]
then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
>
> echo "service '${name}' not found"
> exit 2
Thanks,
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, 7 Aug 2008, Dag-Erling Smørgrav wrote: > Peter Jeremy <[EMAIL PROTECTED]> writes: > > So you take each line from inetd.conf (literally) and wrap it in > > several KB of XML. This definitely adds to bloat and doesn't even > > obey the spirit of XML (since the content of each inetd.conf entry > > remains opaque). > > s/inetd/rc/g > > I completely agree with you - but I also agree with whoever it was that > suggested adding enable / disable commands to rc.subr. inetd.conf too(!); see inetconv(1M) Whilst solaris has some nice bits and pieces, the tendency to take configuration (static and dynamic) and shove it into an opaque database I personally find problematic: compare the ISC and solaris dhcp servers, for instance. enable/disable sound interesting, however. jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...You're visualising the _duck_ taped over my _mouth_..?___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Peter Jeremy <[EMAIL PROTECTED]> writes: > So you take each line from inetd.conf (literally) and wrap it in > several KB of XML. This definitely adds to bloat and doesn't even > obey the spirit of XML (since the content of each inetd.conf entry > remains opaque). s/inetd/rc/g I completely agree with you - but I also agree with whoever it was that suggested adding enable / disable commands to rc.subr. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: > In Solaris 10 the Services Management Facility (SMF) was introduced. The main purpose of SMF appears to be to drum up business for Sun's training courses by radically changing Sol10 Administration for little benefit. >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. So you take each line from inetd.conf (literally) and wrap it in several KB of XML. This definitely adds to bloat and doesn't even obey the spirit of XML (since the content of each inetd.conf entry remains opaque). I haven't looked at what happens to /etc/inittab or the rc.d scripts but I expect that it's similar. It's not clear what benefit this brings. The svcs and svcadm commands are among the most arcane I have bumped into during my >20 years of administering Unix. I agree that some of the process management facilities of SMF are better than exists for most FreeBSD daemons but don't believe that all the other baggage is worth the improvement. With FreeBSD, I can configure virtually all the system via a single text file - which is easily found and kepy under configuration control. With Sol10, there are random bits of configuration spread all over the system and there is no obvious way to control configuration. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpXrc0UnsFtr.pgp Description: PGP signature
Re: Idea for FreeBSD
"Michael B Allen" <[EMAIL PROTECTED]> writes: > I did not mean to say that the scripts themselves were decrepit. I > mean the whole Unix runlevel rc.d apparatus in general is decrepit. FreeBSD doesn't have runlevels. Solaris does. You don't like runlevels, but you want FreeBSD to be more like Solaris. Make up your mind... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Jeremy Chadwick wrote: On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: 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 highly recommend you and anyone advocating the use of XML for such things read the following whitepaper/study, in full: http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf Heh. Loved all the little asides to Nancy... Amazing it hasn't been fixed in 4 years. Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked applications. Which is fine, but as far as I can see doesn't address the question at hand. There are two connected questions here: * What technology should be used to implement the FreeBSD rc.subr system? * What functionality could or should be added to the FreeBSD rc.subr system? Where the answer to the first question clearly constrains the results of the second. So what are the requirements for the rc system? Off the top of my head -- and I've probably missed some vital considerations here -- in order of priority: 1 reliability. The system has to boot up. 2 repeatability. The system has to boot up in a consistent state 3 fault tolerance. The system cannot fail to boot up unless the problems really are terminal. 4 configurability. The system has to boot up correctly for all conceivable combinations of hardware and software. 5 portability. Should run on anything from the smallest of embedded devices to the most enormous high power super computers to the most transient of virtualized hosts. 6 manageability. Must be comprehensible by ordinary mortals. 7 efficiency. Must bring the system up as fast as is practicable and without excessive use of system resources What does XML-based technology bring to this? As the OP states the primary benefit is in manageability. I would contend that the advantage claimed here is rather less significant than indicated. We already have a central database of configuration information -- /etc/rc.conf -- and while we don't have one single application to control starting and stopping services we have the next best thing: a consistent user interface for calling the individual rc-scripts. Indeed, as other posters have shown elsewhere in this thread, adding that sort of functionality is only a Small Matter of Programming using the existing tools. What's wrong wwith using XML? XML adds significantly to the complexity of an rc system -- it's suddenly necessary to have another shlib or two and several compiled applications available early in the boot process. XML itself is too general-purpose: it has too much baggage designed for its primary function of facilitating interoperation between diverse systems in different zones of control, none of which is particularly applicable to system startup. I can see the attraction of writing a nice pointy-clicky database-backed GUI management interface to encourage the uninitiated administrator, but that can only be an adjunct to the current setup, not a replacement. If you can't fix a broken system via a text only serial console accessed across whatever sort of low-bandwidth emergency connectivity you could imagine, then I suspect quite strongly it's not going to receive wholehearted community approval. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Idea for FreeBSD
Am 07.08.2008 um 08:31 schrieb Michael B Allen: mean the whole Unix runlevel rc.d apparatus in general is decrepit. Hi, Jordan! 8-) There should be a library to install, start, stop, restart, uninstall, disable, enable, change order of services and also change the runlevel. And then there should be a very small utility that calls the library to invoke the desired operations from the commandline and from init. As I'm having my daily struggles with launchd on Mac OS Servers (subsystems like lpd being turned of by mechanisms unknown to me, orphaned processes being unceremoniously eaten by launchd without any good reasons) the dream of having one tool instead of init, cron, inetd and the rest of that gang has turned into more work. As I'm also have an allergy against AIX since I came into contact with SMIT for the first time: Be careful what you're asking for, you might really get it. If the library and corresponding utility are implemented correctly, the format of the file containing service state should be moot since no one will ever look at it Besides in emergencies. That's also the time where the tools you would urgently need to repair something aren't working because the system isn't completely up and running. Believe me: Editing XML using ed isn't that exciting. (which is to say dbm or some other binary-blob format should be used since it makes programming the said library much cleaner). Who cares for the programmer? 8-) But I just made that up. Of course such things are never as simple as they sound the first time around. It's worse. Things that are looking great on paper often turn out to be a nightmare when you have to deal with it. And things like "I still intend on writing a plist format (the non-XML one) parser to incorporate into the code base [...]" on http://wiki.freebsd.org/launchd are scaring me even more (the only thing that makes .plists in binary format bearable is the fact that they can be transformed into XML and dealt with reasonable tools). Achim
Re: Idea for FreeBSD
I wonder opinions on more general question: Does somebody believe in necessity of separate infrastructure for daemons(services)? As for me i very dislike unclean of "what where located". Some configuration lie in /etc, some in /usr/local/etc, some in /usr/local/program_name. In addition there is own inclusions in program conf's of some vital data/parameters located somewhere, not to mention program binary, libraries and startup scripts. What the shortest dump command that allow after fresh installation restore full functionality? So, i believe that clean rule of daemons(services) arrangement in system more important than startup design. May be rule that "all daemons should nest in /svc" can help. For example, /svc -mostly read /svc/daemon_name - daemon dir /svc/daemon_name/bin/ - program itself /svc/daemon_name/*.conf - configuration /svc/daemon_name/data/ - data itself (mostly read, rarely write) + symlinks to real data /svc/daemon_name/var2/*.conf - another configuration named var2 (for another instance) /svc/daemon_name/var2/data/ - data itself (mostly read, rarely write) + symlinks to real data another configuration named var2 /svc/daemon_name/cs/ - control scripts (startup/shutdown etc) So, by design there is ability: list all daemon (readdir /svc) start / stop daemons: svc daemon_name start = (do a "/svc/daemon_name/cs/start") use alternative configuration: svc daemon_name var2 start = (do a "/svc/daemon_name/cs/start -c var2") dump all functionallity dump /svc Thursday, August 07, 2008, 3:14:51 AM, you wrote: wfc> To who it may concern, wfc>I am A FreeBSD administrator as well as a Solaris Administrator. I use wfc> BSD at home but Solaris at work. I love both OS's but I would like to wfc> increase the administrative capability of FreeBSD. wfc>In Solaris 10 the Services Management Facility (SMF) was introduced. wfc> Basically what it does, is take all the rc.d scripts and puts them into wfc> a database to manage. Everything is converted to XML and two basic wfc> commands (svcs and svcadm) are used to manage everything. wfc>I would like to submit the idea of implementing a similar environment wfc> into FreeBSD. After looking through the developers links and googling I wfc> found no project for FreeBSD that implemented anything similar to this. wfc> I have included a link below to give a better understanding of SMF and wfc> its capabilities. wfc>Is it possible, if it does not exist already, to look at the wfc> possibility of implementing the concept of SMF into FreeBSD? I would wfc> gladly be an active supporter in this endeavor. wfc> Will Bentley wfc> Future CIS wfc> 410-782-5954 wfc> "Your resource for computer expertise!" wfc> ___ wfc> freebsd-hackers@freebsd.org mailing list wfc> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers wfc> To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best regards, Anthonymailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: > 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 highly recommend you and anyone advocating the use of XML for such things read the following whitepaper/study, in full: http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 01:06:38AM -0400, Mike Meyer wrote:
>On Wed, 6 Aug 2008 22:34:51 "Michael B Allen" <[EMAIL PROTECTED]> wrote:
> > But of course the format of data in a database is largely irrelevant.
> > You could implement the same thing with dbm files or a more forgiving
> > text format.
>
> Right. For that matter, you could leave the data in shell scripts, and
> build a layer of meta information and tools to manipulate these things
> - which is similar to what I see in Linux distros.
>
> The Solaris smf tools provide some nice facilities: one is single
> interface to start, stop, check and restart all the services on a
> system. We pretty much have that, as they all use the same basic
> arguments to their rc scripts. The only issue is figuring out which
> directory to find the rc script in.
I use for this simple script [1] plus some programmable completion.
>
> The other is a single interface to enable, disable and query the
> status of all the services. All we really have is the last one: you
> can run the script with the rcvar argument, and it'll list the
> appropriate variable if it's set, and the value it's set
> to. Maybe. Not all of them support this yet.
> > As for getting rid of rc.d scripts, yes they're decrepit and I would
> > love to see them go but they're simple and third party software may
> > depend on them being the norm.
Can You please be more elaborate? Yes, rc.d scripts have some problems,
but I don't think We need to get rid of them.
[1]:
$cat /usr/local/bin/service
#!/bin/sh
name=$1
cmd=$2
. /etc/rc.subr
if [ -z "${name}" -o -z "${cmd}" ]
then
echo ${0##*/} service_name command
exit 3
fi
if [ -r "/etc/rc.d/${name}" ]
then
run_rc_script "/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}.sh" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}.sh" ${cmd}
exit 0
fi
echo "service '${name}' not found"
exit 2
--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
The Solaris smf tools provide some nice facilities: one is single interface to start, stop, check and restart all the services on a system. We pretty much have that ... The other is a single interface to enable, disable and query the status of all the services. All we really have is the last one... Sounds like the only missing pieces, then, are standard ways to enable, disable, and configure services. How about: sudo /etc/rc.d/ssh enable sudo /etc/rc.d/ssh disable sudo /etc/rc.d/ssh configure That shouldn't be much of a stretch to implement, either. The first two just append entries to /etc/rc.conf. The third opens an editor with a list of variables supported by this service and then appends the result to rc.conf. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 7, 2008 at 1:06 AM, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Wed, 6 Aug 2008 22:34:51 -0400 > "Michael B Allen" <[EMAIL PROTECTED]> wrote: >> As for getting rid of rc.d scripts, yes they're decrepit and I would >> love to see them go but they're simple and third party software may >> depend on them being the norm. > > The only thing decrepit about the rc.d scripts is that they don't all > support the latest facilities that you'd expect them to. But the way > to fix that is to update the old ones, not to throw out all of them > and start over. In particular, if you want to replace them with a > better format, you need to start by showing that said format is better > - and chanting buzzwords like "xml" isn't sufficient to do that. I did not mean to say that the scripts themselves were decrepit. I mean the whole Unix runlevel rc.d apparatus in general is decrepit. There should be a library to install, start, stop, restart, uninstall, disable, enable, change order of services and also change the runlevel. And then there should be a very small utility that calls the library to invoke the desired operations from the commandline and from init. If the library and corresponding utility are implemented correctly, the format of the file containing service state should be moot since no one will ever look at it (which is to say dbm or some other binary-blob format should be used since it makes programming the said library much cleaner). And for backwards compatibility you leave the rc.d tree so that a third party can drop in a script and it will continue to work but anyone using the said utility would completely bypass all the rc.d business. But I just made that up. Of course such things are never as simple as they sound the first time around. Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, 6 Aug 2008 22:34:51 -0400 "Michael B Allen" <[EMAIL PROTECTED]> wrote: > On Wed, Aug 6, 2008 at 7:14 PM, <[EMAIL PROTECTED]> wrote: > > 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 > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. Give the right tools, editing XML is actually reasonable. The right tools are a schema for the documents in question, a schema-aware editor, and applications software that bitches if the document doesn't match the schema. The problem is that you almost never get a schema, and having an application that cares is even rarer. Without those, you're best off using application tools to manipulate the documents, and never touching it except for emergencies. In which case: > But of course the format of data in a database is largely irrelevant. > You could implement the same thing with dbm files or a more forgiving > text format. Right. For that matter, you could leave the data in shell scripts, and build a layer of meta information and tools to manipulate these things - which is similar to what I see in Linux distros. The Solaris smf tools provide some nice facilities: one is single interface to start, stop, check and restart all the services on a system. We pretty much have that, as they all use the same basic arguments to their rc scripts. The only issue is figuring out which directory to find the rc script in. The other is a single interface to enable, disable and query the status of all the services. All we really have is the last one: you can run the script with the rcvar argument, and it'll list the appropriate variable if it's set, and the value it's set to. Maybe. Not all of them support this yet. > As for getting rid of rc.d scripts, yes they're decrepit and I would > love to see them go but they're simple and third party software may > depend on them being the norm. The only thing decrepit about the rc.d scripts is that they don't all support the latest facilities that you'd expect them to. But the way to fix that is to update the old ones, not to throw out all of them and start over. In particular, if you want to replace them with a better format, you need to start by showing that said format is better - and chanting buzzwords like "xml" isn't sufficient to do that. You could, for instance, get all of the facilities of svcs with a shell script that grokked the current rc.d formats. Searching wouldn't be quite as spiffy because we don't have the concept of an FMRI, and getting the output formatting facilities right would be a bit tricky, but the information is pretty much all there. svcadm is a bit harder, because you'd have to edit rc.conf in place, but again, most of the pieces are already in place. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
0n Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: >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. I believe there was a port of MacOS-X 'launchd' to FreeBSD: [http://wiki.freebsd.org/launchd] I think launchd may use XML. -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
> On Wed, Aug 6, 2008 at 7:14 PM, <[EMAIL PROTECTED]> wrote: >> 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 > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. > > But of course the format of data in a database is largely > irrelevant. > You could implement the same thing with dbm files or a more > forgiving > text format. > > As for getting rid of rc.d scripts, yes they're decrepit and I would > love to see them go but they're simple and third party software may > depend on them being the norm. > > Just my 2c, > Mike > > PS: I'm not a FreeBSD "hacker" or even an admin. > ___ I believe the puppet project has a lot of potential, or if not the project then at least the ideas behind it, in regard to automating administrative tasks. I particularly like the way it allows the automation of the same tasks across different operating systems. http://reductivelabs.com/trac/puppet/ Cheers, Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, Aug 6, 2008 at 7:14 PM, <[EMAIL PROTECTED]> wrote: > 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 XML is good at document processing and for portable self-describing databases. Otherwise, I would think significantly less of any OS (or application) that used XML for configuration data. At least nothing that anyone would *every* be forced to edit manually. But of course the format of data in a database is largely irrelevant. You could implement the same thing with dbm files or a more forgiving text format. As for getting rid of rc.d scripts, yes they're decrepit and I would love to see them go but they're simple and third party software may depend on them being the norm. Just my 2c, Mike PS: I'm not a FreeBSD "hacker" or even an admin. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Idea for FreeBSD
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 "[EMAIL PROTECTED]"
