Re: new rc.network6 and rc.firewall6
On Sat, 21 Oct 2000 18:38:33 -0700 Jordan Hubbard [EMAIL PROTECTED] said: jkh Sounds good to me. My comments were, just to make it clear again, jkh just food for thought and not out-and-out objections. If even 47 more jkh files in /etc is what it takes to get IPv6 fully supported, then so be jkh it. :) There are many discussion aboud having NetBSD style rc.d. However, I think it takes for a period of time. Once, I wish to commit my changes to be in time for 4.2-RELEASE. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
There are many discussion aboud having NetBSD style rc.d. However, I think it takes for a period of time. Once, I wish to commit my changes to be in time for 4.2-RELEASE. I think people were talking only about -current here anyway. A NetBSD style rc.d is certainly not planned for -stable. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote: [redirected to just -current; I'm not sure what this has to do with -net] I agree. I've been using them for a while on my dog slow Windows CE machine. There were some minor issues when they were first committed to NetBSD on some platforms (due to a too early use of ps and some brokeness in ps on pmax, for example), but these were quickly resolved. So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. As far as I'm aware, Neil Blakey-Milner is doing just that (I'm surprised he hasn't said so himself, although I think this week/fortnight's quite hectic for him in the real world). N To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
In message [EMAIL PROTECTED] Nik Clayton writes: : On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote: : [redirected to just -current; I'm not sure what this has to do with -net] : : I agree. I've been using them for a while on my dog slow Windows CE : machine. There were some minor issues when they were first committed : to NetBSD on some platforms (due to a too early use of ps and some : brokeness in ps on pmax, for example), but these were quickly : resolved. : : So, who wants to do a proof-of-concept implementation for -current : which integrates with our existing rc.conf mechanism? In order to : obey POLA, we should at least have the separate scripts switch off the : same knobs whenever possible. : : As far as I'm aware, Neil Blakey-Milner is doing just that (I'm surprised : he hasn't said so himself, although I think this week/fortnight's quite : hectic for him in the real world). I'm looking forward to it. NetBSD does have an rc.conf already and they have recently moved to the two teir /etc/defaults/rc.conf and /etc/rc.conf after much gnashing of teeth and beating of breasts... I suspect that if we move to their rc files, a similar gnashing of teeth and beating of breasts will be played out in the mailing lists. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 15:17 -0500, Mike Meyer wrote: Gerhard Sittig writes: What's new is: - include the general config at the start (and yes, in every single script -- but this should be neglectable in terms of speed penalty and makes them work separately, too -- which is a real big gain!) This isn't really new; it's been nagging me for a while. Also, periodic.conf does this now. I'm not convined it's negligible when added up over dozens of scripts. I'm planning on taking some measurements to see how much this really costs. I believe I have a solution if it turns out to be non-negligible. The "negligible" (you finally got what I meant :) comes IMO from considering how often this would happen. I really dont mind at all if booting would take 10 more seconds or shutdown would do. An hourly cronjob eating two more seconds (under heavy load) is no problem at all. And I feel these time ranges to be estimated in a very generous way and expect them to be much lower in real life. I really would be surprised to be totally wrong in this respect. We're talking about "source"ing config and subroutine files -- the shell text is shared and the script code (file data) already in the cache, we just create a new process and allocate data (copy on write helps here) and stack. - maybe include (source) some common code like - determining pids belonging to program names - starting processes in an supervised or backgrounded or any other special way - have some printouts, error level summary, etc but I don't see FreeBSD having this level of "rc lib" as NetBSD has in rc.subr or even RedHat has in /etc/rc.d/functions(sp?). So only the sourced rc.conf (default and customized) remains. Said solutions works shell functions as well. When you're really afraid of speed you can always do what's usually done with C header files: [ -z "$SOURCED_FLAG" ] . $SOURCE_FILE When clearing the SOURCED_FLAG variable at boot's / shutdown's end you aren't very confused later and who fiddles with those variables at the command line by hand gets what he deserves. : [ ... lib function and service script skeleton snipped ... ] virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: new rc.network6 and rc.firewall6
Maybe we could have a script to do the dependency check and "compile" everything in a single big file? This script could run at boot and also after mergemaster, whatever: it just check the modification time against a cache file, where it also stores dependencies. Just my Euro 0.02 ;-) Bye, Andrea -Original Message- From: David O'Brien [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 24, 2000 10:27 PM To: Warner Losh Cc: [EMAIL PROTECTED] Subject: Re: new rc.network6 and rc.firewall6 On Tue, Oct 24, 2000 at 12:31:57PM -0600, Warner Losh wrote: The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. Redone on each boot up (and shutdown). -- You can have it soon, cheap and working. Choose *two*, not three! Andrea Campi Network Administrator World Online S.rl. V. Montecuccoli, 20 - 20132 Milano, Italy Tel. +39 02 483293.1 Fax. +39 02 483293.601 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
This was my thought also. I put the TCP/IP scripts at 99 to make sure that any slow network initialization is done. Since they all start with S - for example S99tcp - moving it to s99tcp will keep it from starting, and the Knnname in the same directory is used to stop things when moving from that run level. It's one of the things I like about the Sys V /etc/rcn.d directory structure, as you can easily fine tune it to fit your needs. Just a look at the files and you know the order. The primary reason I'm aware of is to support transitioning between run levels, where some of the stuff in the previous run level is left running. For the increasingly anal security types, run levels would let you support booting without a network, until after you had battened down the hatches. I'd never use it, in normal use, but what the heck... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 06:04 +0700, Alexey Dokuchaev wrote: On Tue, 24 Oct 2000, David O'Brien wrote: On Tue, Oct 24, 2000 at 04:23:40PM +0700, Alexey Dokuchaev wrote: Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? What about deamons that don't understand `kill -HUP'? Sendmail didn't until very reciently. ``/etc/rc.d/some-deamon restart'' does the right thing reguardless how involved that might be. Though I see your point, actually, many UNIX books, including some pretty old ones, refer to sending HUP signal as standard way of restarting/resetting daemons. Please tell the software authors about it, too. :) Although there might be some form of convention, not everyone might follow it (some might not be able even if they tried without breaking established behaviour). Wrapping those services will make starting, stopping, reloading, querying status and whatever you usually do to them easy and consistent for the user again. BTW: Do you know all the pidfile names and locations by heart? Across every version and platform you are running / taking care of? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 14:56 -0700, Jordan Hubbard wrote: [ ... NetBSD (or Linux?) like rc scripts ... ] So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. I do. As far as I understand the new scripts typically look something like this: - am I (the special service) enabled? - is my executable present? - is my config present? - optional: are my prerequisited (neighbour / underlying services) met? - start me up, obeying flags if present All of this is currently done in the monolithic block, too. I don't see the difference yet (except for splitting the logically distinct functions apart into "natural" groups). What's new is: - include the general config at the start (and yes, in every single script -- but this should be neglectable in terms of speed penalty and makes them work separately, too -- which is a real big gain!) - maybe include (source) some common code like - determining pids belonging to program names - starting processes in an supervised or backgrounded or any other special way - have some printouts, error level summary, etc but I don't see FreeBSD having this level of "rc lib" as NetBSD has in rc.subr or even RedHat has in /etc/rc.d/functions(sp?). So only the sourced rc.conf (default and customized) remains. The real new part eating most of the time to implement is the shutdown path (which I understand to be somewhat absent in FreeBSD right now, "kill -TERM everything" seems to do the job right now). It's something I'd be willing to do, I guess. I have some history with the rc.foo files. :) Tell me what I can do to help. I'm willing to contribute, too. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Gerhard Sittig writes: On Wed, Oct 25, 2000 at 06:04 +0700, Alexey Dokuchaev wrote: Though I see your point, actually, many UNIX books, including some pretty old ones, refer to sending HUP signal as standard way of restarting/resetting daemons. Please tell the software authors about it, too. :) Although there might be some form of convention, not everyone might follow it (some might not be able even if they tried without breaking established behaviour). Wrapping those services will make starting, stopping, reloading, querying status and whatever you usually do to them easy and consistent for the user again. Actually, the HUP convention has been around since at least v6. As noted, it's still not universal. The pid file convention is more recent, and less followed. Fixing that in a startup script is easy (and what I recommend for string daemons that use the HUP convention, so that it can be used for the script's stop command :-). Now, which process do I need to create a pidfile for to get my ipfw config reloaded? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote: So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? I was going to if no one else did. Who ever does it should coordinate with Luke M @ NetBSD. He is willing to make tweaks such that we could use as much of the NetBSD bits as possible. He really hopes we [BSD] can standardize on this interface. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 08:14:01PM +0200, Gerhard Sittig wrote: but I don't see FreeBSD having this level of "rc lib" as NetBSD has in rc.subr We would import the NetBSD rc.subr. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:58:08PM -0700, Jordan Hubbard wrote: With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, Nope. All the /etc/rc.d/ files are scanned by `rcorder'. `rcorder' then creates a dependacy graph from information in each /etc/rc.d/ file. A walk of the graph is done to output the list of scripts in the order they should run in. To quote what you once wrote about `pib', the NetBSD implimentation is "slicker than two eels screwing in a bucket of snot!" :-) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Grrr !@#$^ Reply-To:... On Wed, 25 Oct 2000 13:01:04 -0700, "David O'Brien" [EMAIL PROTECTED] said: Nope. All the /etc/rc.d/ files are scanned by `rcorder'. `rcorder' then creates a dependacy graph from information in each /etc/rc.d/ file. A walk of the graph is done to output the list of scripts in the order they should run in. Hmmm. We already have a program (called `tsort') which does this (i.e., a topological sort). Does `rcorder' call `tsort' or does it reinvent the wheel? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 09:42:23AM +0200, Andrea Campi wrote: Maybe we could have a script to do the dependency check and "compile" everything in a single big file? Luke already has this support in NetBSD 1.5 for those who demand it, but its a secret. ;-) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 04:04:13PM -0400, Garrett Wollman wrote: Hmmm. We already have a program (called `tsort') which does this (i.e., a topological sort). Does `rcorder' call `tsort' or does it reinvent the wheel? UTSL lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/sbin/rcorder/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Gerhard Sittig writes:
What's new is:
- include the general config at the start (and yes, in every
single script -- but this should be neglectable in terms of
speed penalty and makes them work separately, too -- which is a
real big gain!)
This isn't really new; it's been nagging me for a while. Also,
periodic.conf does this now. I'm not convined it's negligible when
added up over dozens of scripts. I'm planning on taking some
measurements to see how much this really costs. I believe I have a
solution if it turns out to be non-negligible.
- maybe include (source) some common code like
- determining pids belonging to program names
- starting processes in an supervised or backgrounded or any
other special way
- have some printouts, error level summary, etc
but I don't see FreeBSD having this level of "rc lib" as NetBSD
has in rc.subr or even RedHat has in /etc/rc.d/functions(sp?).
So only the sourced rc.conf (default and customized) remains.
Said solutions works shell functions as well.
The real new part eating most of the time to implement is the
shutdown path (which I understand to be somewhat absent in
FreeBSD right now, "kill -TERM everything" seems to do the job
right now).
Well, rc.shutdown has the appropriate loop processing in it for doing
this for the rc.d directories already. So the new part is the
per-system shutdown. That's where the shell subroutine library comes
in handy. Provide functions start/stop/reconfig that do the right
thing for the conventional single daemon subsystem like so (vertically
compressed to save space):
start() {
eval command="\$${name}_program \$${name}_flags"
command
echo $! /var/run/${name}.pid
echo -n " $name"
}
stop() {
kill -TERM /var/run/${name}.pid
echo -n " $name"
}
config() {
kill -HUP /var/run/${name}.pid
}
run()
eval check="\$${name}_enable"
case "${check}" in
[Yy][Ee][Ss]) run="yes" ;;
[Nn][Oo]) run="no" ;;
esac
case "$1" in
start) if [ "$run" = "yes" ]; then start(); fi ;;
stop) if [ "$run" = "yes" ]; then stop(); fi ;;
config) if [ "$run" = "yes" ]; then config(); fi ;;
*) echo "Usage: $0 [ start | stop | config ] $12 ;;
esac
}
Then simple daemons turn into:
#!/bin/sh
#
# PROVIDES: foobar
# REQUIRES: ...
# ...
name=foobar
. /etc/rc.setup
run
Breaking out the seperate functions allows you to change just part of
it easily. For example, if the daemon creates a pid, or the flags to
it, you'd do:
#!/bin/sh
# ...
name=smartbar
. /etc/rc.setup
start() {
$foobar_program $foobar_flags
echo -n " foobar"
}
run
Some things are hairy enough to require doing everything over, and
there is probably a better way to organize the subroutines, but that's
the general idea.
The next step is to get ports authors to start using /etc/rc.setup or
whatever it gets called :-).
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Grrr !@#%$^ Reply-To: header On Wed, 25 Oct 2000 13:13:53 -0700, "David O'Brien" [EMAIL PROTECTED] said: (i.e., a topological sort). Does `rcorder' call `tsort' or does it reinvent the wheel? UTSL You could have simply answered the question. For the benefit of everyone else: yes, it reinvents the wheel. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
I was going to if no one else did. Who ever does it should coordinate with Luke M @ NetBSD. He is willing to make tweaks such that we could use as much of the NetBSD bits as possible. He really hopes we [BSD] can standardize on this interface. Well, it sounds like David is already working with Luke on this so why don't we just tag him as "it" and get past the deadlock on this one. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
(i.e., a topological sort). Does `rcorder' call `tsort' or does it reinvent the wheel? UTSL You could have simply answered the question. For the benefit of everyone else: yes, it reinvents the wheel. I personally don't have a problem with this; tsort should be a library routine referenced by both tsort(1) and rcorder(8), of course, but the way tsort(1) works, there is really no easy way to use it to do the job in any reasonable amount of time. As far as wheel reinvention goes, we should add gcc, ld, and make to the list of programs reinventing the tsort wheel... kinda calls out for a library routine; wait, I already said that once... 8-). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Wed, Oct 25, 2000 at 06:04:43AM +0700, Alexey Dokuchaev wrote: On Tue, 24 Oct 2000, David O'Brien wrote: On Tue, Oct 24, 2000 at 04:23:40PM +0700, Alexey Dokuchaev wrote: Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? What about deamons that don't understand `kill -HUP'? Sendmail didn't until very reciently. ``/etc/rc.d/some-deamon restart'' does the right thing reguardless how involved that might be. Though I see your point, actually, many UNIX books, including some pretty old ones, refer to sending HUP signal as standard way of restarting/resetting daemons. Using the `kill -HUP` method, how do you deal with the dependency issues that people have been mentioning in this thread? -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Garrett Rooney writes: On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote: Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. and at the very least, with a number of smaller files, assuming they're named well, you can find what you're looking for faster, and not have to dig though the one monolithic script to find out how sometihng is working. Well, we *already* have over a dozen /etc/rc.* files on -current. And we *don't* have the advantage of a consistent interface to control all the functions in /etc/rc. If you break things up, then if you need to restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? "/etc/rc.d/sendmail/dhcpd restart". Etc. Of course, for consistency ports should be tweaked to use have the same provides/requires setup, and use rc.subr instead of the homegrown hacks. Which brings up the real downside of doing this - you have to parse rc.subr and rc.conf for *every* one of those scripts. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
One of the reasons for the numbers in the SysVR4 arena is to set the order of execution so programs which other depend upon are executed first. How does the NetBSD solve this problem. Very coolly. The main rc script runs a script named `rcorder' to generate the proper order. rc.shutdown also uses `rcorder' but reverses the ordering. Two examples are included below to show what `rcorder' uses to generate the list. These NetBSD rc files also provide "start", "stop", "restart", "status", etc. commands to assist the sysadmin. Again, *very* slick and still quite BSD-like. [ ... ] # PROVIDE: ypbind # REQUIRE: ypserv One thing that surfaced frequently in a discussion of a similar system was hard vs. soft requirements. Specifically, I can run sendmail without a syslogd running, so it is not a hard requirement, but I would prefer that it be there so that I can log things. There is a similar non-requirement for bind to start sendmail, if you have it configured to not probe interfaces, which is a good idea for dial-on-demand configurations, but to provide service to a remote system, it needs bind around. So along with "PROVIDE" and "REQUIRE", there's a need for "WANT"; it could be used as a tie-breaker for circular dependency lists, if such occur. Similarly, there is a need for a "config", as well as a "start", "stop", "restart", and "Status". For well written software, this would end up being a NOOP, since it would not cache config data, but would instead obtain it each time (an example of bad caching is sendmail source host name caching, when an ISP supports DNSUPDAT based on RADIUS audit events: if the machine claims to be named something different than the ISP assigned DNS name such that forward and reverse mappings don't match, the ISP will reject attempts to relay email from valid customers). Yeah, in a perfect world, everyone would have a static IP address, and sendmail would have a knob to make it do a gethostbyaddr() for each time that it wanted to say "HELO", etc., etc.. Oh... and the PROVIDE/REQUIRE/WANT lists really, really want to be "per service name" rather than per program name, so I could, for example, have a service that depends on "smtpserv", and not care if it was sendmail or qmail or whatever, only that there was a protocol aware program sitting on the SMTP port, waiting for a connection. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
I like the concept of them quite a bit. I think it definitely shows some thought on how to keep the advantages of each system. I would support a move toward a system like this. One thing that would be nice is a database somewhere of which of services from /etc/rc.d are running. I think this is what "status" is for... Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. Install a binary package that needs to be started when the system is booted and needs to be shutdown when the system is shutdown. Now consider yourself as a software vendor, such as "Oracle" or "Lucent", trying to easily distribute database software or a WinModem binary-only third-party licensed codec for FreeBSD. Despite its age, "sed" is not your friend. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, 24 Oct 2000, Terry Lambert wrote: Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. Install a binary package that needs to be started when the system is booted and needs to be shutdown when the system is shutdown. That's what /usr/local/etc/rc.d/ was for for years! Put all your application-specific scripts there, but leave base-system monotilithic startup alone :-) -- WBR, DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Well, we *already* have over a dozen /etc/rc.* files on -current. And we *don't* have the advantage of a consistent interface to control all the functions in /etc/rc. If you break things up, then if you need to restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? "/etc/rc.d/sendmail/dhcpd restart". Etc. Actually, the point is that writing TONS of scripts to get your work done (that's what Linux world does) always pissed me off. You have a shell script that is in fact a wrapper for another shell script, and like this in turn it goes on and on and on again. Icky! :-) I don't like how Linux smells. Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? I don't consider it being sagnificantly longer than writing /etc/rc.d/sendmail restart. After all, if your typing speed is good enough, it doesn't really matter whether you type in 30 or 20 chars. -- JMHO, DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Alexey Dokuchaev writes: Well, we *already* have over a dozen /etc/rc.* files on -current. And we *don't* have the advantage of a consistent interface to control all the functions in /etc/rc. If you break things up, then if you need to restart the mail server, just go "/etc/rc.d/sendmail restart". dhcpd? "/etc/rc.d/sendmail/dhcpd restart". Etc. Actually, the point is that writing TONS of scripts to get your work done (that's what Linux world does) always pissed me off. You have a shell script that is in fact a wrapper for another shell script, and like this in turn it goes on and on and on again. Icky! :-) I don't like how Linux smells. Well, I don't like Linux much either. On the other hand, I hate dealing with a lots of little things all of which are just slightly different from each other even more - and the latter is what you get from /etc/rc. Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? I don't consider it being sagnificantly longer than writing /etc/rc.d/sendmail restart. After all, if your typing speed is good enough, it doesn't really matter whether you type in 30 or 20 chars. You can still do that. However, do you know how to get everything listed in /etc/defaults/rc.conf to reread it's config file? With the approach being advocated, the answer is "yes" - even if you don't know whether or not the daemon in question *has* a config file. That's the thing I like about all those scripts (SysV, linux, whatever) - I didn't have to deal with cruft like that. Yeah, for some things, this means you wind up running a script that's a wrapper for the vendor-provided script to make it meet your standards. If you really hate that, ignore the vendors script and talk directly to the application - but they get little enough use that I'd rather use the vendor's API and let it be wasteful. After all, if they got a lot of use, having different interface wouldn't be a problem. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 08:59:36AM +, Terry Lambert wrote: Oh... and the PROVIDE/REQUIRE/WANT lists really, really want to be "per service name" rather than per program name, so I could, for example, have a service that depends on "smtpserv", and not care if it was sendmail or qmail or whatever, only that there was a protocol aware program sitting on the SMTP port, waiting for a connection. i believe, from the quick look i took at this last night, that this is the way it is done, at least for mail servers, as there seems to be provisions for both sendmail and postfix (well, i remember postfix specifically, and i assume sendmail was there). -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
The solution is very simple. Put a statically linked Perl in /sbin, and write the startup system in Perl. For user convenience, it should have a Gnome interface and a PostgreSQL backend, so we should also put X and pgsql in /sbin. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
/me hands Chris SARCASM and /SARCASM DocWilco At 13:50 24-10-2000 -0400, you wrote: The solution is very simple. Put a statically linked Perl in /sbin, and write the startup system in Perl. For user convenience, it should have a Gnome interface and a PostgreSQL backend, so we should also put X and pgsql in /sbin. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
In message [EMAIL PROTECTED] "David O'Brien" writes: : At BSDcon Luke M showed me what the NetBSD 1.5 rc files look like. : They've moved them all to /etc/rc.d/ and made them very granular (as : SVR4, but w/o leading numbers in the filenames). The NetBSD : implementation also solved all the issues people have brought up in the : past -- dependacies, etc... : : We should just move to using their rc code. I agree. I've been using them for a while on my dog slow Windows CE machine. There were some minor issues when they were first committed to NetBSD on some platforms (due to a too early use of ps and some brokeness in ps on pmax, for example), but these were quickly resolved. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
In message [EMAIL PROTECTED] Bill Vermillion writes: : One of the reasons for the numbers in the SysVR4 arena is to : set the order of execution so programs which other depend upon : are executed first. How does the NetBSD solve this problem. The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. Turns out to be fairly cheap to do. I'd check, but my netbsd box is currently off the net since I've not setit back up after BSDcon. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Mon, 23 Oct 2000, Brandon D. Valentine wrote: : Well if you're that stubborn there's no reason that the "new" layout : could not be compiled into a monolithic script. In fact perhaps you : could be the one to step forward and write the code to compile that : script. ;-) : : Indeed, given the slowdowns NetBSD enountered when switching to the new : system due to all of the shell processes being created. which slowdowns were these? Even on older pmax system the boot time wasn't increased too much, once they fixed a couple of bugs in the NetBSD/pmax port... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : By the way, the author of this stuff (Luke Mewburn) says he'll post a : summary of the design and implementation issues to this list in a few : days. I talked to Luke at BSDcon about many issues. He's very keen on increasing the cooperation between the two projects. If we find issues with /etc/rc.d(NetSBD), then I'm fairly sure that he'd be willing to work with us on them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 16:14 +0700, Alexey Dokuchaev wrote:
On Tue, 24 Oct 2000, Terry Lambert wrote:
Well, would not be this stepping aside from BSD startup
sequence, which we all know and love? Having dozens of
small files instead of pair of big ones always frustrates
me when I have to work with linux.
Install a binary package that needs to be started when the
system is booted and needs to be shutdown when the system is
shutdown.
That's what /usr/local/etc/rc.d/ was for for years! Put all
your application-specific scripts there, but leave base-system
monotilithic startup alone :-)
What if I don't employ bind but use something else (djbdns or
homebrew software) instead? Where do I put those in into the
startup sequence? When /usr/local/etc/rc.d/*.sh are run it could
be too late since on the way there a few services died due to DNS
errors.
What about other "essential" services like foreign file systems
("unnatural" things like coda?) or mail transfer agents likely to
be used / needed before other things happen but not available in
the base? What if I want to load some UPS daemon quite early?
How do I implement hardcoded ARP tables short after NIC setup and
right before services' startup? What about other hacks one had
to introduce into /etc/rc*? Think of the ipf "workaround" in PR
20202. It could have been as easy as adding one more file or
replacing the ipfw counterpart. At the moment it is about having
someone stuff the code into some other environment. Without easy
moving around in case it's wrongly placed (think of 30 lines
deleted and 30 lines added - without the chance to easily see if
they're still the same and just have moved - against one line
deleted and one line added - more obviously documenting a moved
invocation).
Plugging (dropping) in just another script and have it register
its sequence number somewhere (or replacing an existing one) is
always easier than modifying a huge pile of code.
And think about undoing those additions (insertions) upon
removal: deleting a single file is really trivial compared to
identifying and removing a chunk in a big file. And changing
your mind about what to do and how to do it for a certain service
won't interfere with all the other stuff.
I don't like thinking back of the situation, where I had to start
a (usually not running) NFS server and a NFS client for remote
installworlds. Eyeballing nested rc scripts, comparing them
against the rc.conf settings and typing all those by hand and not
missing something is really not what you want to have when you
actually have other worries to take care of. And then again -
how do I kill this damned special daemon in a clear way? Of
course every one of them has a way and if you're lucky it's only
five ways for seven services, but that's still too much of a
complexity for a simple human mind with its given restrictions.
Think of the run-parts layout in the cronjob directories and the
advantages are (should be) really obvious. The "clutter" with
the symlinks in Linux come from the notion of having runlevels,
BTW. For BSD (simple straight bootup, endless run and simple
straight shutdown, with a little change sometimes as new services
are needed or not needed any longer) there should either be no
links and a sequence description or just one pile of "numbered
links" besides the "basename'd, plain working" scripts.
BTW: When I wouldn't like those many single files I would
honestly think about combining all the source code into one or at
most two files. :) What are all those header files good for if
not for causing the preprocessor to parse them over and over for
no real gain after the first time? This analogy might
demonstrate best what modularity is able to gain, and that
devoting processing power for tedious routine jobs can free human
resources for other jobs at a more abstract level (i.e. closer to
solving "the real" problem instead of unnecessarily fiddling with
boring details and introducing dull new errors).
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 05:05:49AM +0700, Alexey Dokuchaev wrote: Still, it would be better if I could choose between "classical" and "new" startup layout, say, somewhere at the installation stage. Supporting two very different schemes is a support nightmare. And giveing good test coverage with our current resources would also be a problem. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote: Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. Maybe, but the greatly increased functionality makes it worth it. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 04:23:40PM +0700, Alexey Dokuchaev wrote: Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? What about deamons that don't understand `kill -HUP'? Sendmail didn't until very reciently. ``/etc/rc.d/some-deamon restart'' does the right thing reguardless how involved that might be. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
[redirected to just -current; I'm not sure what this has to do with -net] I agree. I've been using them for a while on my dog slow Windows CE machine. There were some minor issues when they were first committed to NetBSD on some platforms (due to a too early use of ps and some brokeness in ps on pmax, for example), but these were quickly resolved. So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. It's something I'd be willing to do, I guess. I have some history with the rc.foo files. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. I'm really curious about this, myself. One of the reasons the SYSV scripts have the numeric prefix is so that you know exactly what order things will be started in. With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, but that also gives you another location to edit when dropping in a new startup file. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:58:08PM -0700, Jordan Hubbard wrote: The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. I'm really curious about this, myself. One of the reasons the SYSV scripts have the numeric prefix is so that you know exactly what order things will be started in. With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, but that also gives you another location to edit when dropping in a new startup file. well, assuming you specify all the necessary dependencies, does it really matter what the specific order is? i mean i always thought of the numbers in SYSV script names as a hack to preserve dependencies, rather than a way to preserve a specific order. the order only needs to exist to preserve dependencies, unless i'm missing something. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:58:08PM -0700, Jordan Hubbard wrote: The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. I'm really curious about this, myself. One of the reasons the SYSV scripts have the numeric prefix is so that you know exactly what order things will be started in. With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, but that also gives you another location to edit when dropping in a new startup file. and, to reply a second time to this message, it is recomputed at each boot... the rc and rc.shutdown scripts both run rcorder to do it, with rc.shutdown reversing the order. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:58:08PM -0700, Jordan Hubbard thus spoke: The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. I'm really curious about this, myself. One of the reasons the SYSV scripts have the numeric prefix is so that you know exactly what order things will be started in. With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, but that also gives you another location to edit when dropping in a new startup file. This was my thought also. I put the TCP/IP scripts at 99 to make sure that any slow network initialization is done. Since they all start with S - for example S99tcp - moving it to s99tcp will keep it from starting, and the Knnname in the same directory is used to stop things when moving from that run level. It's one of the things I like about the Sys V /etc/rcn.d directory structure, as you can easily fine tune it to fit your needs. Just a look at the files and you know the order. Bill -- Bill Vermillion - bv @ wjv . com -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
Jordan Hubbard writes: [redirected to just -current; I'm not sure what this has to do with -net] I agree. I've been using them for a while on my dog slow Windows CE machine. There were some minor issues when they were first committed to NetBSD on some platforms (due to a too early use of ps and some brokeness in ps on pmax, for example), but these were quickly resolved. So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. I'm in the midst of trying to install NetBSD so I can look at this. If no one else steps forward to do it, I can put together a patch. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
So, who wants to do a proof-of-concept implementation for -current which integrates with our existing rc.conf mechanism? In order to obey POLA, we should at least have the separate scripts switch off the same knobs whenever possible. It's something I'd be willing to do, I guess. I have some history with the rc.foo files. :) I'm rather new to -current, but I'd be willing to be junior hacker on this project. I'm rather fond of shell script hacking and other languages come easily to me too. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, 24 Oct 2000, David O'Brien wrote: On Tue, Oct 24, 2000 at 04:23:40PM +0700, Alexey Dokuchaev wrote: Why can't I simply write kill -1 `cat /var/run/sendmail.pid`? What about deamons that don't understand `kill -HUP'? Sendmail didn't until very reciently. ``/etc/rc.d/some-deamon restart'' does the right thing reguardless how involved that might be. Though I see your point, actually, many UNIX books, including some pretty old ones, refer to sending HUP signal as standard way of restarting/resetting daemons. ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
and, to reply a second time to this message, it is recomputed at each boot... the rc and rc.shutdown scripts both run rcorder to do it, with rc.shutdown reversing the order. Ah, OK, sorry - I must have missed this the first time around. I'll have to investigate the workings of rcorder then. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
I'm in the midst of trying to install NetBSD so I can look at this. If no one else steps forward to do it, I can put together a patch. I've had several replies, so why don't we all look into this a bit and see which one of us actually manages to have enough steam to do it after the analysis period is over. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
At 2:58 PM -0700 10/24/00, Jordan Hubbard wrote: The scripts themselves have the ordering dependencies. The startup system runs them in the proper order. I don't know if this is pre-computed or redone each boot. I'm really curious about this, myself. One of the reasons the SYSV scripts have the numeric prefix is so that you know exactly what order things will be started in. With the NetBSD stuff, this is not immediately obvious though I guess one could have a top level rc file with an explicit ordering similar to our various subdir Makefiles, but that also gives you another location to edit when dropping in a new startup file. One should have some other script that you could run, which would look thru all the rc files and just list which order they will be run at startup (or at shutdown). That way you could find out the order for a given set of scripts without having to actually startup or shutdown... (I have no idea how netbsd does it, I'm just saying that I would think some other script should be provided which could list out the proper order without actually running any of the scripts...) --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 11:04:55PM -0400, Garance A Drosihn wrote: One should have some other script that you could run, which would look thru all the rc files and just list which order they will be run at startup (or at shutdown). That way you could find out the order for a given set of scripts without having to actually startup or shutdown... (I have no idea how netbsd does it, I'm just saying that I would think some other script should be provided which could list out the proper order without actually running any of the scripts...) since i've been playing with the tools a little in my copious spare time, you could determine that using the rcorder tool that they actually use to get the order in the rc script. just run 'rcorder /etc/rc.d/*' and it'll output the order they should start up in. reverse that order for shutdown. this system looks more and more swank every time i look at it. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 01:05:27AM -0700, David O'Brien wrote: On Sun, Oct 22, 2000 at 09:41:51PM -0400, Bill Vermillion wrote: One of the reasons for the numbers in the SysVR4 arena is to set the order of execution so programs which other depend upon are executed first. How does the NetBSD solve this problem. Very coolly. The main rc script runs a script named `rcorder' to generate the proper order. rc.shutdown also uses `rcorder' but reverses the ordering. Two examples are included below to show what `rcorder' uses to generate the list. These NetBSD rc files also provide "start", "stop", "restart", "status", etc. commands to assist the sysadmin. Again, *very* slick and still quite BSD-like. Sounds interesting. To add a new rc script to the system, do you have to add an entry to an "rc order list" somewhere (in addition to adding the new script)? How is that handled? The nice (or clumsy, depending on your point of view) part about the SysV way is that the order in which the rc scripts are executed is implicit in the scripts' names. Of course, they have added a symlink maze (worse, hard links on HP-UX) on top of that, making it tedious to maintain rc scripts by hand (maybe that was by design). [snip] -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, Brian O'Shea wrote: Sounds interesting. To add a new rc script to the system, do you have to add an entry to an "rc order list" somewhere (in addition to adding the new script)? How is that handled? The nice (or clumsy, depending on your point of view) part about the SysV way is that the order in which the rc scripts are executed is implicit in the scripts' names. Of course, they have added a symlink maze (worse, hard links on HP-UX) on top of that, making it tedious to maintain rc scripts by hand (maybe that was by design). Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, but I would say that adding a new script to a list of rc files would be much less hassle than adding an entry in a monolithic /etc/rc to process that new file. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: On Mon, 23 Oct 2000, Brian O'Shea wrote: Sounds interesting. To add a new rc script to the system, do you have to add an entry to an "rc order list" somewhere (in addition to adding the new script)? How is that handled? The nice (or clumsy, depending on your point of view) part about the SysV way is that the order in which the rc scripts are executed is implicit in the scripts' names. Of course, they have added a symlink maze (worse, hard links on HP-UX) on top of that, making it tedious to maintain rc scripts by hand (maybe that was by design). Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, but I would say that adding a new script to a list of rc files would be much less hassle than adding an entry in a monolithic /etc/rc to process that new file. I agree. However, I was comparing it to the SysV rc script format, not to the existing BSD rc scripts. -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/etc/rc.d/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, David O'Brien wrote: On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/etc/rc.d/ Thanks, I was gonna go find those after I finished what I was doing, but you've saved me a few keystrokes. =) I like the concept of them quite a bit. I think it definitely shows some thought on how to keep the advantages of each system. I would support a move toward a system like this. One thing that would be nice is a database somewhere of which of services from /etc/rc.d are running. This would enable one to build a nice GUI or curses based tool for showing the services running, and allowing for the stopping, starting, and restarting of those services. Basically just add a feature such that after a service is started, the pid is written to a universally standard directory for all rc controlled services. That would be sufficient. It would then be nice to write such a tool, manipulatable either via command line options or an interactive curses mode, which would manage those services. Sort of the equivalent of SysV's chkconfig command, but actually useful. =) So that one could say: rccntl amd restart or just run rccntrl and get a curses window displaying the services in /etc/rc.d currently started and possibly another window showing those not started, and the option to move a service from one list to the other, thereby starting to stopping it, as well the option to just restart it. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 02:25:40PM -0700, David O'Brien wrote: On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/etc/rc.d/ wow, that's really cool. i've always prefered BSD init versus SysV, but they seem to have gotten the best of both worlds. hope someone whith the clout to make it happen jumps on it and gets it ported over, cause that seems like something that's too useful to not use. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Sun, 22 Oct 2000, David O'Brien wrote: On Sat, Oct 21, 2000 at 11:05:37AM -0700, Jordan Hubbard wrote: I wish to update rc.network6 and introduce rc.firewall6. H. I must confess that I see /etc as getting rather cluttered these days. Is there no way to perhaps collapse some of the most related functionality into single files and start passing arguments or something? Just a comment.. At BSDcon Luke M showed me what the NetBSD 1.5 rc files look like. They've moved them all to /etc/rc.d/ and made them very granular (as SVR4, but w/o leading numbers in the filenames). The NetBSD implementation also solved all the issues people have brought up in the past -- dependacies, etc... We should just move to using their rc code. Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. -- With all due respect, DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote: Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. well, it's a single directory full of small files, as opposed to a bunch of directories, each with its own collection of files, with ugly numbers at the beginning of each one. that's better in my book. and at the very least, with a number of smaller files, assuming they're named well, you can find what you're looking for faster, and not have to dig though the one monolithic script to find out how sometihng is working. -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, Garrett Rooney wrote: On Tue, Oct 24, 2000 at 04:49:40AM +0700, Alexey Dokuchaev wrote: Well, would not be this stepping aside from BSD startup sequence, which we all know and love? Having dozens of small files instead of pair of big ones always frustrates me when I have to work with linux. well, it's a single directory full of small files, as opposed to a bunch of directories, each with its own collection of files, with ugly numbers at the beginning of each one. that's better in my book. and at the very least, with a number of smaller files, assuming they're named well, you can find what you're looking for faster, and not have to dig though the one monolithic script to find out how sometihng is working. Still, it would be better if I could choose between "classical" and "new" startup layout, say, somewhere at the installation stage. -- With best and kind regards, DAN Fe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, 24 Oct 2000, Alexey Dokuchaev wrote: Still, it would be better if I could choose between "classical" and "new" startup layout, say, somewhere at the installation stage. Well if you're that stubborn there's no reason that the "new" layout could not be compiled into a monolithic script. In fact perhaps you could be the one to step forward and write the code to compile that script. ;-) -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, Brandon D. Valentine wrote: On Tue, 24 Oct 2000, Alexey Dokuchaev wrote: Still, it would be better if I could choose between "classical" and "new" startup layout, say, somewhere at the installation stage. Well if you're that stubborn there's no reason that the "new" layout could not be compiled into a monolithic script. In fact perhaps you could be the one to step forward and write the code to compile that script. ;-) That's an idea! Gotta co recent -CURRENT right now! -- ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 05:26:07AM +0700, Alexey Dokuchaev wrote: On Mon, 23 Oct 2000, Brandon D. Valentine wrote: On Tue, 24 Oct 2000, Alexey Dokuchaev wrote: Still, it would be better if I could choose between "classical" and "new" startup layout, say, somewhere at the installation stage. Well if you're that stubborn there's no reason that the "new" layout could not be compiled into a monolithic script. In fact perhaps you could be the one to step forward and write the code to compile that script. ;-) That's an idea! Gotta co recent -CURRENT right now! might want to port the netbsd code first, since AFAIK this stuff isn't in current ;-) i imagine it won't take much though... just tweaking the scripts to make sure they all do the right thing on a FreeBSD box. and it seems like compiling a monolithic script should be simple enough... maybe i'll look at it in my copious spare time... -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, Garrett Rooney wrote: That's an idea! Gotta co recent -CURRENT right now! might want to port the netbsd code first, since AFAIK this stuff isn't in current ;-) Indeed it's not, but nice to seem him so eager. =) -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, 23 Oct 2000, Brandon D. Valentine wrote: Well if you're that stubborn there's no reason that the "new" layout could not be compiled into a monolithic script. In fact perhaps you could be the one to step forward and write the code to compile that script. ;-) Indeed, given the slowdowns NetBSD enountered when switching to the new system due to all of the shell processes being created. There isn't any reason why rc.conf shouldn't continue to be useful in either case. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 02:25:40PM -0700, David O'Brien wrote: On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/etc/rc.d/ By the way, the author of this stuff (Luke Mewburn) says he'll post a summary of the design and implementation issues to this list in a few days. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
On Sun, Oct 22, 2000 at 03:39:57PM -0700, David O'Brien thus spoke: On Sat, Oct 21, 2000 at 11:05:37AM -0700, Jordan Hubbard wrote: I wish to update rc.network6 and introduce rc.firewall6. H. I must confess that I see /etc as getting rather cluttered these days. Is there no way to perhaps collapse some of the most related functionality into single files and start passing arguments or something? Just a comment.. At BSDcon Luke M showed me what the NetBSD 1.5 rc files look like. They've moved them all to /etc/rc.d/ and made them very granular (as SVR4, but w/o leading numbers in the filenames). The NetBSD implementation also solved all the issues people have brought up in the past -- dependacies, etc... We should just move to using their rc code. One of the reasons for the numbers in the SysVR4 arena is to set the order of execution so programs which other depend upon are executed first. How does the NetBSD solve this problem. Bill -- Bill Vermillion - bv @ wjv . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
I wish to update rc.network6 and introduce rc.firewall6. H. I must confess that I see /etc as getting rather cluttered these days. Is there no way to perhaps collapse some of the most related functionality into single files and start passing arguments or something? Just a comment.. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
-On [20001021 20:10], Jordan Hubbard ([EMAIL PROTECTED]) wrote: I wish to update rc.network6 and introduce rc.firewall6. H. I must confess that I see /etc as getting rather cluttered these days. Is there no way to perhaps collapse some of the most related functionality into single files and start passing arguments or something? Just a comment.. The IPv6 systems are so much different in set-up than the IPv4 systems. Collapsing of the functions is not really doable. However, Umemoto-san and me will discuss this, since we [he mostly] have been working on this for the last few months. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl I love to doubt as well as know... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
However, Umemoto-san and me will discuss this, since we [he mostly] have been working on this for the last few months. Sounds good to me. My comments were, just to make it clear again, just food for thought and not out-and-out objections. If even 47 more files in /etc is what it takes to get IPv6 fully supported, then so be it. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
