From alex at trull.org Sun Oct 4 14:35:59 2009 From: alex at trull.org (Alex Trull) Date: Sun Oct 4 14:36:58 2009 Subject: (Ab)using rcng's features to keep rc.d-style services running should they fail. Message-ID: <20091004141118.GG95662@syndicate.internationalconspiracy.org> Hi all, I realised that because portupgrade/portmaster don't always cleanly restart processes that have died due to being upgraded (mysqld, often!) that this was something I wanted to fix. However, I'd seen the daemontools and wasn't a fan - too much to configure with weird directories and so forth and while monit is very powerful it also takes too much effort to do what could be so much simpler. So why not just (ab)use the rcng system with a script ? the functionality is all there already to do almost everything needed. To check whether something is running and (if not!) start it. So this is my dirty hack so far - runs out of cron with "2>/dev/null" every few minutes and mails me about attempted startups as they happen : #!/bin/sh # start things that should be running find /usr/local/etc/rc.d/ /etc/rc.d/ -type f | egrep -v '(newsyslog|devd|sendmail)' | awk '{print $0" status| grep \"is not running\" && "$0" start"}' | sh Performance is not stunning, thankfuly my cpus are quite idle. real 0m1.198s user 0m0.610s sys 0m0.877s (devd, newsyslog and sendmail are left out because their scripts don't behave quite right.) Initialy I used it purely for the /usr/local/etc/rc.d but I had a base ntpd die on me one evening so decided to throw in /etc/rc.d/ too. This script has also caught a few other failures in port-installed daemons in addition to the ever-common mysqld-upgraded one. Of course it is relatively inefficient executing all those scripts on a regular basis - but it works - has anyone thought of cleaner/more efficient ways of doing this and getting more out of the rcng framework ? Or simpler for that matter. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091004/a6d7598f/attachment.pgp From dougb at FreeBSD.org Sun Oct 4 19:30:58 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 4 19:31:23 2009 Subject: (Ab)using rcng's features to keep rc.d-style services running should they fail. In-Reply-To: <20091004141118.GG95662@syndicate.internationalconspiracy.org> References: <20091004141118.GG95662@syndicate.internationalconspiracy.org> Message-ID: <4AC8F7EF.9010303@FreeBSD.org> Alex Trull wrote: > Hi all, > > I realised that because portupgrade/portmaster don't always > cleanly restart processes that have died due to being > upgraded (mysqld, often!) that this was something I wanted > to fix. I can't speak to portupgrade, however for portmaster there is no such facility whatsoever. The admin is expected to disable things prior to an upgrade and re-enable them when the upgrade is done. I don't feel that this is an overwhelming burden. :) That said I have it in mind to add a facility to handle this feature. Stay tuned for more news about this. > So why not just (ab)use the rcng system with a script ? First, it's rc.d now if you please. Second, I don't think that there is anything wrong with your concept that would classify it as abuse, although I'm not sure I would have implemented it in quite the same way. > the > functionality is all there already to do almost everything > needed. To check whether something is running and (if not!) > start it. > > So this is my dirty hack so far - runs out of cron with > "2>/dev/null" every few minutes and mails me about attempted > startups as they happen : > > #!/bin/sh > # start things that should be running > find /usr/local/etc/rc.d/ /etc/rc.d/ -type f | egrep -v '(newsyslog|devd|sendmail)' | awk '{print $0" status| grep \"is not running\" && "$0" start"}' | sh There are a couple of "problems" with this, although please understand I'm not criticizing, I'm just offering what I hope are constructive suggestions. First, (and I consider this to be a bug) there are several scripts in /etc/rc.d that are not actually 'startup' scripts in the true sense. Therefore I would not attempt to run them all. Personally if I were going to do what you're doing I would make an explicit list of scripts I wanted to test for. If you are going to continue to use awk you might want to learn how to avoid piping it to grep, that's an extra subshell that you don't really need. Finally I would do something like this (untested): for service in ntpd mysqld foo bar; do if [ -x /usr/local/etc/rc.d/$service ]; then service=/usr/local/etc/rc.d/$service elif [ -x /etc/rc.d/$service ]; then service=/etc/rc.d/$service else echo "Cannot find $service in /etc/rc.d or /usr/local/etc/rc.d" exit 1 fi $service start | grep -v 'already running' done > (devd, newsyslog and sendmail are left out because their > scripts don't behave quite right.) I don't see anything wrong with devd's output from the status command, sendmail's is a little hard to parse because it's doing a lot of things in one script. newsyslog is spitting out 'not running' which arguably it should not do since that script is not for starting a persistent service, it's just a 'run at boot' thing. In any case, if you find what you think are bugs in rc.d related stuff feel free to report them to freebsd-rc@freebsd.org. hth, Doug -- This .signature sanitized for your protection From hrs at FreeBSD.org Mon Oct 5 03:54:21 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 03:54:34 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20090920.224018.16368211.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> Message-ID: <20091005.123427.227628092.hrs@allbsd.org> Hi, I would like your comments about merging the network_ipv6 -> netif integration to stable/8. The issue of this rc.d script change is it involves user-visible changes in rc.conf(5) variables as described in UPDATING. I still want to do so before 8.0-R because the ND6 change in -CURRENT needs updating IPv6-related rc.d scripts first. While the ND6 change is not harmful from viewpoint of compatibility because basically it just converts a global knob to a per-interface flag, handling it in the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and rc.d/netif. The necessary changes have already been committed into -CURRENT. It displays a warning to inform the users what is old in the rc.conf if the user uses rc.d variables that have been changed, and at the same time it keeps backward compatibility so that the old variables also work. So, I think the impact is small enough, and this sort of visible changes should be included in the .0 release rather than in the middle of future 8.x releases. The patch for stable/8 can be found at: http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff This includes both of the ND6 kernel change and the rc.d script change. If there is an objection from someone here I will put off the merge until after 8.0-R. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091005/a6a15177/attachment.pgp From jhay at meraka.org.za Mon Oct 5 05:58:09 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Oct 5 05:58:15 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <20091005055806.GB58246@zibbi.meraka.csir.co.za> On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. The issue of this rc.d script change is it > involves user-visible changes in rc.conf(5) variables as described in > UPDATING. > > I still want to do so before 8.0-R because the ND6 change in -CURRENT > needs updating IPv6-related rc.d scripts first. While the ND6 change > is not harmful from viewpoint of compatibility because basically it > just converts a global knob to a per-interface flag, handling it in > the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > rc.d/netif. > > The necessary changes have already been committed into -CURRENT. It > displays a warning to inform the users what is old in the rc.conf if > the user uses rc.d variables that have been changed, and at the same > time it keeps backward compatibility so that the old variables also > work. So, I think the impact is small enough, and this sort of > visible changes should be included in the .0 release rather than in > the middle of future 8.x releases. > > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > > This includes both of the ND6 kernel change and the rc.d script > change. If there is an objection from someone here I will put off > the merge until after 8.0-R. Is there a good reason why we still ship with ipv6 off by default? Most others seem to ship with ipv6 on. At least Windows, most linux flavours and Mac OS X which make out the rest of the machines on our network here at Meraka Institute. One thing that I have against the way the stuff in -current is done at the moment, is that it seems to be a lot more work to just get ipv6 to work. Either I did things wrong or we are taking a step backward. Make no mistake, I like the idea of being able to control it per interface, but it seems that you have to enable it per interface with a long string for each... I would rather that it is enabled everywhere by default and then you disbale it where you do not want it. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From hrs at FreeBSD.org Mon Oct 5 09:24:33 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 09:24:40 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> Message-ID: <20091005.182342.167950100.hrs@allbsd.org> John Hay wrote in <20091005055806.GB58246@zibbi.meraka.csir.co.za>: jh> Is there a good reason why we still ship with ipv6 off by default? Most jh> others seem to ship with ipv6 on. At least Windows, most linux flavours jh> and Mac OS X which make out the rest of the machines on our network here jh> at Meraka Institute. What do you mean by "off by default"? I think IPv6 is not disabled by default with the patch. Re-enabling of "automatic assignment of a link-local address by default" has been a big step for IPv6 ready out of the box. jh> One thing that I have against the way the stuff in -current is done at jh> the moment, is that it seems to be a lot more work to just get ipv6 to jh> work. Either I did things wrong or we are taking a step backward. Make jh> no mistake, I like the idea of being able to control it per interface, jh> but it seems that you have to enable it per interface with a long string jh> for each... I would rather that it is enabled everywhere by default and jh> then you disbale it where you do not want it. The initial patch had several regressions to mistakenly disable the functionality, but the current one should work by just adding an $ifconfig_IF_ipv6 line to rc.conf. The intention of my patch is to set $ipv6_enable=YES automatically (in more modular manner) when an IPv6 configuration is specified for an interface. Even with no per-interface configuration, when $ipv6_prefer=YES, IPv6 communication by using link-local addresses works. I believe it does not make it so complex compared with the old $ipv6_enable=YES model. I feel there is some difference between my understanding of "enable by default" and yours. Do you elaborate the word "enable" a bit more, please? -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091005/7186ff99/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Mon Oct 5 09:47:26 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 5 09:47:52 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> Message-ID: <20091005091708.J26486@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, John Hay wrote: Hi, > On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: >> Hi, >> >> I would like your comments about merging the network_ipv6 -> netif >> integration to stable/8. The issue of this rc.d script change is it >> involves user-visible changes in rc.conf(5) variables as described in >> UPDATING. >> >> I still want to do so before 8.0-R because the ND6 change in -CURRENT >> needs updating IPv6-related rc.d scripts first. While the ND6 change >> is not harmful from viewpoint of compatibility because basically it >> just converts a global knob to a per-interface flag, handling it in >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and >> rc.d/netif. >> >> The necessary changes have already been committed into -CURRENT. It >> displays a warning to inform the users what is old in the rc.conf if >> the user uses rc.d variables that have been changed, and at the same >> time it keeps backward compatibility so that the old variables also >> work. So, I think the impact is small enough, and this sort of >> visible changes should be included in the .0 release rather than in >> the middle of future 8.x releases. >> >> The patch for stable/8 can be found at: >> >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> >> This includes both of the ND6 kernel change and the rc.d script >> change. If there is an objection from someone here I will put off >> the merge until after 8.0-R. > > Is there a good reason why we still ship with ipv6 off by default? Most > others seem to ship with ipv6 on. At least Windows, most linux flavours > and Mac OS X which make out the rest of the machines on our network here > at Meraka Institute. > > One thing that I have against the way the stuff in -current is done at > the moment, is that it seems to be a lot more work to just get ipv6 to > work. Either I did things wrong or we are taking a step backward. Make > no mistake, I like the idea of being able to control it per interface, > but it seems that you have to enable it per interface with a long string > for each... I would rather that it is enabled everywhere by default and > then you disbale it where you do not want it. link-local had been enabled by default in the past and I am not sure if we had a SA or EN for that or that it was just preemptively disabled. The problem is that if it is enabled by default you are exposing yourself to others on the same network. That is of course especially bad if you are in untrusted environments like conferences, ... or on a public LAN. If we'd support IPv4 link-local addresses by default we would have to apply the same logic there. I am not sure about OSX but at least Windows has a firewall set to deny any unrelated incoming things by default these days. Just because others haven't yet (really) thought about the problems doesn't mean they aren't there. If you want to use IPv4 you either add an address or start DHCP or .. and you have to configure that. If you want IPv6, you configure that as well. You shall not have anything enbaled by default that people can use to attack you and you don't know about because you didn't configure. While (we) IPv6 people know that it would be there a lot of people are still totally unaware of IPv6 and they would be surprised. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From bugmaster at FreeBSD.org Mon Oct 5 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:09:23 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200910051106.n95B6xmI088783@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/138208 rc [rc] [patch] Making rc.firewall (workstation) IPv6 awa o conf/137629 rc [rc] background_dhclient rc.conf option causing double o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132766 rc wait_for_pids() in /etc/rc.subr is dull. o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/130414 rc [patch] rc services started with onestart are not stop o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 60 problems total. From wxs at FreeBSD.org Mon Oct 5 14:16:41 2009 From: wxs at FreeBSD.org (Wesley Shields) Date: Mon Oct 5 14:16:47 2009 Subject: (Ab)using rcng's features to keep rc.d-style services running should they fail. In-Reply-To: <4AC8F7EF.9010303@FreeBSD.org> References: <20091004141118.GG95662@syndicate.internationalconspiracy.org> <4AC8F7EF.9010303@FreeBSD.org> Message-ID: <20091005135842.GA8629@atarininja.org> On Sun, Oct 04, 2009 at 12:30:55PM -0700, Doug Barton wrote: > Alex Trull wrote: > > Hi all, > > > > I realised that because portupgrade/portmaster don't always > > cleanly restart processes that have died due to being > > upgraded (mysqld, often!) that this was something I wanted > > to fix. > > I can't speak to portupgrade, however for portmaster there is no such > facility whatsoever. The admin is expected to disable things prior to > an upgrade and re-enable them when the upgrade is done. I don't feel > that this is an overwhelming burden. :) There is the @stopdaemon directive in plists (which gets translated into @unexec to forcestop the script). Some ports use it and some do not. Personally I think ports doing this automatically are quite annoying, and would love to rip them all out from the ports. Something like portmaster growing support for it would be welcome provided it does not happen by default. I've always found it funny that there is no @startdaemon directive (rightfully so, as we want people to explicitly turn things on) but it's acceptable if things get turned off via @stopdaemon without explicit permission. If a particular upgrade requires that the thing be not running we should check for that and abort, not go shutting things down. -- WXS From des at des.no Mon Oct 5 18:25:24 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 18:25:30 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.182342.167950100.hrs@allbsd.org> (Hiroki Sato's message of "Mon, 05 Oct 2009 18:23:42 +0900 (JST)") References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> Message-ID: <86my45vhlj.fsf@ds4.des.no> Hiroki Sato writes: > John Hay writes: > > Is there a good reason why we still ship with ipv6 off by default? > What do you mean by "off by default"? I think IPv6 is not disabled by > default with the patch. % ident /usr/src/etc/defaults/rc.conf /usr/src/etc/defaults/rc.conf: $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf ipv6_network_interfaces="none" # List of IPv6 network interfaces #ipv6_network_interfaces="ed0 ep0" # Examples for router % grep ipv6_prefer /usr/src/etc/defaults/rc.conf ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used Does mean that IPv6 is disabled by default? Who knows? There is no coherent explanation *anywhere* of what these variables mean, and rc.conf(5) does not mention them at all. In fact, the first hit for "ipv6" in rc.conf(5) is this: ipv6_enable (bool) Enable support for IPv6 networking. Note that this requires that the kernel has been compiled with options INET6. DES -- Dag-Erling Sm?rgrav - des@des.no From oberman at es.net Mon Oct 5 18:54:13 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 5 18:54:25 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: Your message of "Mon, 05 Oct 2009 20:08:40 +0200." <86my45vhlj.fsf@ds4.des.no> Message-ID: <20091005185408.728471CC0E@ptavv.es.net> > From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= > Date: Mon, 05 Oct 2009 20:08:40 +0200 > Sender: owner-freebsd-current@freebsd.org > > Hiroki Sato writes: > > John Hay writes: > > > Is there a good reason why we still ship with ipv6 off by default? > > What do you mean by "off by default"? I think IPv6 is not disabled by > > default with the patch. > > % ident /usr/src/etc/defaults/rc.conf > /usr/src/etc/defaults/rc.conf: > $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ > % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf > ipv6_network_interfaces="none" # List of IPv6 network interfaces > #ipv6_network_interfaces="ed0 ep0" # Examples for router > % grep ipv6_prefer /usr/src/etc/defaults/rc.conf > ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used > > Does mean that IPv6 is disabled by default? Who knows? There is no > coherent explanation *anywhere* of what these variables mean, and > rc.conf(5) does not mention them at all. In fact, the first hit for > "ipv6" in rc.conf(5) is this: > > ipv6_enable > (bool) Enable support for IPv6 networking. Note that this > requires that the kernel has been compiled with options > INET6. Am I missing something here? From the same /etc/defaults/rc.conf: ### IPv6 options: ### ipv6_enable="NO" # Set to YES to set up for IPv6. That looks about a "disabled out of the box" as it gets. As far as I can see (which may not be far), ipv6_network_interfaces is only relevant to IPv6 routing. I believe that ipv6_prefer controls the default behavior when DNS returns both IPv4 and IPv6 addresses for a host. If it is set to "NO", IPv4 will be tried first (preferred). If set to "YES", the IPv6 address will be preferred. I strongly recommend keeping ipv6_prefer set to "NO". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From des at des.no Mon Oct 5 19:12:35 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 19:12:47 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005185408.728471CC0E@ptavv.es.net> (Kevin Oberman's message of "Mon, 05 Oct 2009 11:54:08 -0700") References: <20091005185408.728471CC0E@ptavv.es.net> Message-ID: <86ab05ven2.fsf@ds4.des.no> "Kevin Oberman" writes: > Am I missing something here? From the same /etc/defaults/rc.conf: > ### IPv6 options: ### > ipv6_enable="NO" # Set to YES to set up for IPv6. > > That looks about a "disabled out of the box" as it gets. AFAIK, ipv6_enable has no effect. DES -- Dag-Erling Sm?rgrav - des@des.no From dimitry at andric.com Mon Oct 5 19:39:40 2009 From: dimitry at andric.com (Dimitry Andric) Date: Mon Oct 5 19:39:52 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <4ACA4B81.3090105@andric.com> On 2009-10-05 05:34, Hiroki Sato wrote: > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff Hmm, build bombs out at sbin/ifconfig: ===> sbin/ifconfig (depend) make: don't know how to make af_nd6.c. Stop *** Error code 2 This is because the patch doesn't seem to contain sbin/ifconfig/af_nd6.c. Can I just use the version from head? From hrs at FreeBSD.org Mon Oct 5 20:03:52 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 20:03:59 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <86my45vhlj.fsf@ds4.des.no> References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> Message-ID: <20091006.045043.187164797.hrs@allbsd.org> Dag-Erling Sm?rgrav wrote in <86my45vhlj.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > John Hay writes: de> > > Is there a good reason why we still ship with ipv6 off by default? de> > What do you mean by "off by default"? I think IPv6 is not disabled by de> > default with the patch. de> de> % ident /usr/src/etc/defaults/rc.conf de> /usr/src/etc/defaults/rc.conf: de> $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ de> % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf de> ipv6_network_interfaces="none" # List of IPv6 network interfaces de> #ipv6_network_interfaces="ed0 ep0" # Examples for router de> % grep ipv6_prefer /usr/src/etc/defaults/rc.conf de> ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used de> de> Does mean that IPv6 is disabled by default? Who knows? There is no de> coherent explanation *anywhere* of what these variables mean, and de> rc.conf(5) does not mention them at all. In fact, the first hit for de> "ipv6" in rc.conf(5) is this: de> de> ipv6_enable de> (bool) Enable support for IPv6 networking. Note that this de> requires that the kernel has been compiled with options de> INET6. No, the rc.conf(5) has been updated in r197526: ipv6_enable (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is added to all of ifconfig__ipv6 and the ipv6_prefer is defined as ``YES''. This variable is deprecated. Use ipv6_prefer and ifconfig__ipv6. and UPDATING also explains the relationship between the $ipv6_enable and the other variables. IMHO "Enabling (or disabling) IPv6" is not a correct expression for $ipv6_enable and $ipv6_prefer. If you use a kernel with "options INET6" (GENERIC has it) IPv6 is enabled, and $ipv6_enable=NO in the old releases does not disable the functionality. It just controlled whether $ipv6_* in rc.conf are ignored or not. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091005/24619684/attachment.pgp From hrs at FreeBSD.org Mon Oct 5 20:36:59 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 20:37:07 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA4B81.3090105@andric.com> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> Message-ID: <20091006.053611.25963972.hrs@allbsd.org> Dimitry Andric wrote in <4ACA4B81.3090105@andric.com>: di> On 2009-10-05 05:34, Hiroki Sato wrote: di> > The patch for stable/8 can be found at: di> > di> > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff di> di> Hmm, build bombs out at sbin/ifconfig: di> di> ===> sbin/ifconfig (depend) di> make: don't know how to make af_nd6.c. Stop di> *** Error code 2 di> di> This is because the patch doesn't seem to contain di> sbin/ifconfig/af_nd6.c. Can I just use the version from head? Yes, you can use the file in HEAD. I do not know why but "svn diff" seems not to generate a diff delta for a newly-added file by "svn merge"... The missing delta can also be found at: http://people.freebsd.org/~hrs/af_nd6.c.diff -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091005/a76b54d0/attachment.pgp From des at des.no Mon Oct 5 21:06:03 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 21:06:10 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091006.045043.187164797.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 04:50:43 +0900 (JST)") References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> Message-ID: <8663atv9dz.fsf@ds4.des.no> Hiroki Sato writes: > No, the rc.conf(5) has been updated in r197526: > > ipv6_enable > (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is > added to all of ifconfig__ipv6 and the ipv6_prefer > is defined as ``YES''. > > This variable is deprecated. Use ipv6_prefer and > ifconfig__ipv6. Still not very helpful. If I install FreeBSD from a release CD and use the GENERIC kernel and do *not* want to use IPv6, what do I do? Please don't answer "compile a custom kernel". DES -- Dag-Erling Sm?rgrav - des@des.no From hrs at FreeBSD.org Mon Oct 5 22:09:37 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 22:09:49 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <8663atv9dz.fsf@ds4.des.no> References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> Message-ID: <20091006.070714.233607520.hrs@allbsd.org> Dag-Erling Sm?rgrav wrote in <8663atv9dz.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > No, the rc.conf(5) has been updated in r197526: de> > de> > ipv6_enable de> > (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is de> > added to all of ifconfig__ipv6 and the ipv6_prefer de> > is defined as ``YES''. de> > de> > This variable is deprecated. Use ipv6_prefer and de> > ifconfig__ipv6. de> de> Still not very helpful. de> de> If I install FreeBSD from a release CD and use the GENERIC kernel and do de> *not* want to use IPv6, what do I do? de> de> Please don't answer "compile a custom kernel". It depends on the definition of "use", but the answer is "do not put any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 will be "disabled" (including communication using link-local addresses) on all of interfaces except lo0. It is the default behavior now. I do not think this means "IPv6 is disabled by default". By adding an IPv6 address by using ifconfig(8) after boot you can still use IPv6 on that interface. This is almost the same as IPv4 does. When I do not want to use IPv4, I do not put any IPv4 addresses to $ifconfig_IF. Strictly speaking the address ::1/128 on lo0 cannot be removed because it is assigned by the kernel itself unlike IPv4's 127.0.0.1, so you can use the loopback address without knowing it. If you do not want to use it, you can disable IPv6 on lo0 manually by "ifconfig lo0 inet6 ifdisabled". Anyway, the existence of this loopback address has not been changed for a long time. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091005/ed798d49/attachment.pgp From dougb at FreeBSD.org Mon Oct 5 22:23:22 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 5 22:23:30 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <4ACA71D4.6010502@FreeBSD.org> Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As stated previously my objections are as follows (in decreasing order of general importance): 1. It is a fairly significant change happening too late in the release cycle. IMO that is reason enough to not allow the change. 2. Although 8.0 seems to be getting more beta/rc testing than previous .0 releases, the overall number of users testing it is still a small percentage of the userbase. 3. A dramatically smaller percentage of those users who are actually doing the testing is also using IPv6. 4. There are still rough edges to the changes. 5. I personally disagree with some of the choices you've made and would like to see more discussion about them. (More about 4 and 5 below.) The rough edges I've noticed have to do with the various problems people have reported to the lists, including what seems to be a lack of testing without IPv6 in the kernel, continuing evolution of how to deal with the afnet tests, and personally I've noticed the following on my console, although I haven't had time to research yet whether it's definitely coming from your changes: in6_ifattach_linklocal: failed to add a link-local addr to wpi0 In terms of design decisions you've made, I am still confused about why you insist on deprecating ipv6_enable. Recent discussion on the lists indicates to me that I'm not alone in thinking that this is a valuable mechanism and that there is not only no reason to deprecate it, to do so is not desirable. I'd also like to explore further the idea that I suggested in a previous thread that it should not be necessary to specify ifconfig_IF_ipv6 at all. The vast majority of users will be using RA for the next couple of years at least, so in my mind it makes sense to default to using ipv6_network_interfaces=$network_interfaces and RA by default. If the user has a need to configure something explicitly then you've provided the mechanism for them to do that, but they shouldn't be forced to use it. This is another reason that I think ipv6_enable should be the "master" knob. I like the idea of the ipv6_prefer knob, but I do not like the idea of overloading it with the function of ipv6_enable too. I can certainly understand why you are eager to get these changes into 8.0, however if we do a proper job of maintaining backwards compatibility (which I think we should do anyway) I don't see any reason that they cannot be merged after 8.0, and more importantly after they have had a proper opportunity to shake out in HEAD. Doug -- This .signature sanitized for your protection From qing.li at bluecoat.com Mon Oct 5 23:18:42 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Oct 5 23:18:48 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA71D4.6010502@FreeBSD.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org><20091005.123427.227628092.hrs@allbsd.org> <4ACA71D4.6010502@FreeBSD.org> Message-ID: I agree with Doug and I'd prefer getting more runtime cycles out of these changes before MFC into stable/8. On a semi-related topic, I like the features developed in r197138. The changes are significant enough that having a MFC of 3 days is way too short. This changelist should also be postponed to post REL_8. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Doug Barton > Sent: Monday, October 05, 2009 3:23 PM > To: Hiroki Sato > Cc: freebsd-current@freebsd.org; freebsd-rc@freebsd.org > Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration > > Hiroki Sato wrote: > > Hi, > > > > I would like your comments about merging the network_ipv6 -> netif > > integration to stable/8. > > I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As > stated previously my objections are as follows (in decreasing order of > general importance): > > 1. It is a fairly significant change happening too late in the release > cycle. IMO that is reason enough to not allow the change. > 2. Although 8.0 seems to be getting more beta/rc testing than previous > .0 releases, the overall number of users testing it is still a small > percentage of the userbase. > 3. A dramatically smaller percentage of those users who are actually > doing the testing is also using IPv6. > 4. There are still rough edges to the changes. > 5. I personally disagree with some of the choices you've made and > would like to see more discussion about them. (More about 4 and 5 > below.) > > The rough edges I've noticed have to do with the various problems > people have reported to the lists, including what seems to be a lack > of testing without IPv6 in the kernel, continuing evolution of how to > deal with the afnet tests, and personally I've noticed the following > on my console, although I haven't had time to research yet whether > it's definitely coming from your changes: > > in6_ifattach_linklocal: failed to add a link-local addr to wpi0 > > In terms of design decisions you've made, I am still confused about > why you insist on deprecating ipv6_enable. Recent discussion on the > lists indicates to me that I'm not alone in thinking that this is a > valuable mechanism and that there is not only no reason to deprecate > it, to do so is not desirable. > > I'd also like to explore further the idea that I suggested in a > previous thread that it should not be necessary to specify > ifconfig_IF_ipv6 at all. The vast majority of users will be using RA > for the next couple of years at least, so in my mind it makes sense to > default to using ipv6_network_interfaces=$network_interfaces and RA by > default. If the user has a need to configure something explicitly then > you've provided the mechanism for them to do that, but they shouldn't > be forced to use it. This is another reason that I think ipv6_enable > should be the "master" knob. I like the idea of the ipv6_prefer knob, > but I do not like the idea of overloading it with the function of > ipv6_enable too. > > I can certainly understand why you are eager to get these changes into > 8.0, however if we do a proper job of maintaining backwards > compatibility (which I think we should do anyway) I don't see any > reason that they cannot be merged after 8.0, and more importantly > after they have had a proper opportunity to shake out in HEAD. > > > Doug > > -- > > This .signature sanitized for your protection > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From des at des.no Tue Oct 6 08:26:13 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 6 08:26:20 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091006.070714.233607520.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 07:07:14 +0900 (JST)") References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> <20091006.070714.233607520.hrs@allbsd.org> Message-ID: <864oqd9bdn.fsf@ds4.des.no> Hiroki Sato writes: > Dag-Erling Sm?rgrav writes: > > If I install FreeBSD from a release CD and use the GENERIC kernel > > and do *not* want to use IPv6, what do I do? > It depends on the definition of "use", but the answer is "do not put > any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 > will be "disabled" (including communication using link-local > addresses) on all of interfaces except lo0. It is the default > behavior now. > > I do not think this means "IPv6 is disabled by default". Close enough from my POV... thanks. Network configuration is complicated enough that I think we should have a separate man page for it; rc.conf is pretty much useless unless you already know what you're looking for. DES -- Dag-Erling Sm?rgrav - des@des.no From dimitry at andric.com Tue Oct 6 12:37:21 2009 From: dimitry at andric.com (Dimitry Andric) Date: Tue Oct 6 12:37:30 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA4B81.3090105@andric.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> Message-ID: <4ACB3A08.9030109@andric.com> On 2009-10-05 21:39, Dimitry Andric wrote: >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > Hmm, build bombs out at sbin/ifconfig: ... > This is because the patch doesn't seem to contain > sbin/ifconfig/af_nd6.c. Can I just use the version from head? FYI, the patch also misses etc/rc.d/{faith,stf}. Without these, mergemaster fails; again, taking them from head fixes it. From dhorn2000 at gmail.com Tue Oct 6 16:50:10 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Oct 6 16:50:16 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACB3A08.9030109@andric.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> Message-ID: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> On Tue, Oct 6, 2009 at 8:37 AM, Dimitry Andric wrote: > On 2009-10-05 21:39, Dimitry Andric wrote: >>> ? http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> Hmm, build bombs out at sbin/ifconfig: > ... >> This is because the patch doesn't seem to contain >> sbin/ifconfig/af_nd6.c. ?Can I just use the version from head? > > FYI, the patch also misses etc/rc.d/{faith,stf}. ?Without these, > mergemaster fails; again, taking them from head fixes it. Hiroki -- I also attempted to use your patch against 8/Stable svn, and wanted to give some feedback. svn add before doing the svn diff will ensure that files you want to add to a patch get noticed. svn diff will only look at files under version control. 1) Patchset is missing examples and defaults for new rc.conf variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been updated in -current, although perhaps once everything settles, it would help to expand the examples in comments) 2) I really like the changes to ifconfig and kernel for exposing per-interface flags for "accept_rtadv" and other ndp flags to ifconfig (and inherently rc.conf). I previously had to do some hackery to disable "accept_rtadv" at boot time for just one interface within rc.conf. 3) I would prefer that ipv6_enable remain a global flag in rc.conf, and NOT be obsoleted. I would also prefer that ipv6_network_interfaces="auto" as in the past by default. Again, I like the logic changes and the flexibility it provides, it is just the default/obsolete that I am interested in changing. 4) Personal opinion time: change the "accept_rtadv" token to "autoconf" in ifconfig and rc.conf, as this it is a better self-description. Just one persons opinion. 5) I noticed in the comments that you are considering allowing autoconf+router in a future advanced configuration. I completely agree with adding this functionality to -current (for ipv6 router cpe needs), we just need a new knob when this gets added. I had code around somewhere at one point. I'll see if I can find it still. There is a PR (conf/121812) on this as well. Given the timing, +1 for letting this bake in -current until after 8.0 release. If you want any early feedback for a future MFC of this code, feel free to email me and I will gladly test the patch. Thanks for the changes. ---Dave H From delphij at delphij.net Tue Oct 6 22:44:52 2009 From: delphij at delphij.net (Xin LI) Date: Tue Oct 6 22:45:04 2009 Subject: (Ab)using rcng's features to keep rc.d-style services running should they fail. In-Reply-To: <20091005135842.GA8629@atarininja.org> References: <20091004141118.GG95662@syndicate.internationalconspiracy.org> <4AC8F7EF.9010303@FreeBSD.org> <20091005135842.GA8629@atarininja.org> Message-ID: <4ACBC857.2030207@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wesley Shields wrote: > On Sun, Oct 04, 2009 at 12:30:55PM -0700, Doug Barton wrote: >> Alex Trull wrote: >>> Hi all, >>> >>> I realised that because portupgrade/portmaster don't always >>> cleanly restart processes that have died due to being >>> upgraded (mysqld, often!) that this was something I wanted >>> to fix. >> I can't speak to portupgrade, however for portmaster there is no such >> facility whatsoever. The admin is expected to disable things prior to >> an upgrade and re-enable them when the upgrade is done. I don't feel >> that this is an overwhelming burden. :) > > There is the @stopdaemon directive in plists (which gets translated into > @unexec to forcestop the script). Some ports use it and some do not. > Personally I think ports doing this automatically are quite annoying, > and would love to rip them all out from the ports. Something like > portmaster growing support for it would be welcome provided it does not > happen by default. +1 I think this feature should be user-controllable (or, the 'make install' should be 'restart'ing the rc.d script at very least). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrLyFcACgkQi+vbBBjt66DZ5QCfU3LSI+RiZwJv3huFx4wd3QNe UUsAn37vdhs30y+2eE/HLaw424CS7dMh =1FW0 -----END PGP SIGNATURE----- From doconnor at gsoft.com.au Wed Oct 7 03:33:05 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Oct 7 03:33:11 2009 Subject: (Ab)using rcng's features to keep rc.d-style services running should they fail. In-Reply-To: <4ACBC857.2030207@delphij.net> References: <20091004141118.GG95662@syndicate.internationalconspiracy.org> <20091005135842.GA8629@atarininja.org> <4ACBC857.2030207@delphij.net> Message-ID: <200910071322.48738.doconnor@gsoft.com.au> On Wed, 7 Oct 2009, Xin LI wrote: > Wesley Shields wrote: > > On Sun, Oct 04, 2009 at 12:30:55PM -0700, Doug Barton wrote: > >> Alex Trull wrote: > >>> Hi all, > >>> > >>> I realised that because portupgrade/portmaster don't always > >>> cleanly restart processes that have died due to being > >>> upgraded (mysqld, often!) that this was something I wanted > >>> to fix. > >> > >> I can't speak to portupgrade, however for portmaster there is no > >> such facility whatsoever. The admin is expected to disable things > >> prior to an upgrade and re-enable them when the upgrade is done. I > >> don't feel that this is an overwhelming burden. :) > > > > There is the @stopdaemon directive in plists (which gets translated > > into @unexec to forcestop the script). Some ports use it and some > > do not. Personally I think ports doing this automatically are quite > > annoying, and would love to rip them all out from the ports. > > Something like portmaster growing support for it would be welcome > > provided it does not happen by default. > > +1 > > I think this feature should be user-controllable (or, the 'make > install' should be 'restart'ing the rc.d script at very least). It won't actually start anything you haven't enabled in rc.conf though since all ports install rc.d scripts which require FOO_enable to be YES. That said a knob like RESTART_SERVICES or similar would be nice. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091007/84111f61/attachment.pgp From jhay at meraka.org.za Wed Oct 7 19:12:08 2009 From: jhay at meraka.org.za (John Hay) Date: Wed Oct 7 19:12:20 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005091708.J26486@maildrop.int.zabbadoz.net> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005091708.J26486@maildrop.int.zabbadoz.net> Message-ID: <20091007191203.GA24065@zibbi.meraka.csir.co.za> Hi, Sorry I was away from keyboard for a few days. On Mon, Oct 05, 2009 at 09:25:18AM +0000, Bjoern A. Zeeb wrote: > On Mon, 5 Oct 2009, John Hay wrote: > > Hi, > > >On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > >>Hi, > >> > >> I would like your comments about merging the network_ipv6 -> netif > >> integration to stable/8. The issue of this rc.d script change is it > >> involves user-visible changes in rc.conf(5) variables as described in > >> UPDATING. > >> > >> I still want to do so before 8.0-R because the ND6 change in -CURRENT > >> needs updating IPv6-related rc.d scripts first. While the ND6 change > >> is not harmful from viewpoint of compatibility because basically it > >> just converts a global knob to a per-interface flag, handling it in > >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > >> rc.d/netif. > >> > >> The necessary changes have already been committed into -CURRENT. It > >> displays a warning to inform the users what is old in the rc.conf if > >> the user uses rc.d variables that have been changed, and at the same > >> time it keeps backward compatibility so that the old variables also > >> work. So, I think the impact is small enough, and this sort of > >> visible changes should be included in the .0 release rather than in > >> the middle of future 8.x releases. > >> > >> The patch for stable/8 can be found at: > >> > >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > >> > >> This includes both of the ND6 kernel change and the rc.d script > >> change. If there is an objection from someone here I will put off > >> the merge until after 8.0-R. > > > >Is there a good reason why we still ship with ipv6 off by default? Most > >others seem to ship with ipv6 on. At least Windows, most linux flavours > >and Mac OS X which make out the rest of the machines on our network here > >at Meraka Institute. > > > >One thing that I have against the way the stuff in -current is done at > >the moment, is that it seems to be a lot more work to just get ipv6 to > >work. Either I did things wrong or we are taking a step backward. Make > >no mistake, I like the idea of being able to control it per interface, > >but it seems that you have to enable it per interface with a long string > >for each... I would rather that it is enabled everywhere by default and > >then you disbale it where you do not want it. > > > link-local had been enabled by default in the past and I am not sure > if we had a SA or EN for that or that it was just preemptively > disabled. > > The problem is that if it is enabled by default you are exposing > yourself to others on the same network. That is of course especially > bad if you are in untrusted environments like conferences, ... or on a > public LAN. For a while I hoped that we could return to the good old days, but I guess it is fear and terror nowadays. :-/ > If we'd support IPv4 link-local addresses by default we would have to > apply the same logic there. > > I am not sure about OSX but at least Windows has a firewall set to > deny any unrelated incoming things by default these days. Well depending on how narrow you look at it, we are not that far away from that. We have all network services off by default and if you install via sysinstall, you get a chance to enable the ones you want. :-) > > Just because others haven't yet (really) thought about the problems > doesn't mean they aren't there. > > If you want to use IPv4 you either add an address or start DHCP or .. > and you have to configure that. If you want IPv6, you configure that > as well. You shall not have anything enbaled by default that people > can use to attack you and you don't know about because you didn't > configure. > > While (we) IPv6 people know that it would be there a lot of people are > still totally unaware of IPv6 and they would be surprised. Ok I can understand why not have it totally enabled by default, but why not keep ipv6_enabled and let the user only have to add ipv6_enabled="YES" to his rc.conf and have the "normal" case of a client ipv6 box just work? Either on all interfaces or limited to maybe network_interfaces. After all, one of the aims of IPv6 was to make configuration easier for the "normal" client case. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From dimitry at andric.com Fri Oct 9 10:21:23 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Oct 9 10:21:35 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> Message-ID: <4ACF0EA0.9070401@andric.com> On 2009-10-06 18:21, David Horn wrote: > 1) Patchset is missing examples and defaults for new rc.conf > variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been > updated in -current, although perhaps once everything settles, it > would help to expand the examples in comments) Not only that, it would prevent the following needless warnings, which are printed at every boot: [...] /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. [...] /etc/rc: WARNING: $ipv6_router_enable is obsolete. Use $route6d_enable instead. /etc/rc: WARNING: $ipv6_router is obsolete. Use $route6d_program instead. /etc/rc: WARNING: $router_enable is obsolete. Use $routed_enable instead. /etc/rc: WARNING: $router is obsolete. Use $routed_program instead. /etc/rc: WARNING: $router_flags is obsolete. Use $routed_flags instead. Although the warning about ipv6_enable could be considered right, there's no need to print it twice, and I never touched any of the other ipv6_* or router_* variables. Those are from /etc/defaults/rc.conf. > 2) I really like the changes to ifconfig and kernel for exposing > per-interface flags for "accept_rtadv" and other ndp flags to ifconfig > (and inherently rc.conf). I previously had to do some hackery to > disable "accept_rtadv" at boot time for just one interface within > rc.conf. I'm not entirely sure if this is a sensible default. I would guess that for most users (80%? 90%?) the choice is only to have IPv6 "globally" disabled or enabled, and only a small percentage of users will need per-interface enabling/disabling of IPv4. Since it's now 2009 and everybody should start using IPv6 ASAP, it might make sense to have IPv6 globally enabled by default, with additional options for users like David to selectively disable it for individual interfaces. > 3) I would prefer that ipv6_enable remain a global flag in rc.conf, > and NOT be obsoleted. I would also prefer that > ipv6_network_interfaces="auto" as in the past by default. Again, I > like the logic changes and the flexibility it provides, it is just the > default/obsolete that I am interested in changing. Seconded. Even Windows defaults to enabling IPv6 globally for all interfaces these days. :) > 4) Personal opinion time: change the "accept_rtadv" token to > "autoconf" in ifconfig and rc.conf, as this it is a better > self-description. Just one persons opinion. Since the old "global" sysctl was also called accept_rtadv, I understand the same name was chosen for the per-interface option. People might confuse "autoconf" with "zeroconf" or other automatic configuration systems. Since the option means to accept router advertisements, accept_rtadv seems not a very bad name to me... :) > Given the timing, +1 for letting this bake in -current until after 8.0 > release. Yes. A few weeks at least. From dougb at FreeBSD.org Sun Oct 11 20:54:37 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 11 20:54:43 2009 Subject: A more thorough "Starting foo:" solution Message-ID: <4AD2460A.3000902@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 After giving this a more thorough look I realized that there were quite a few places where $rc_quiet was being used directly in an rc.d script (16 scripts total). I've already committed this to HEAD in order to try and make the MFC deadline to potentially get it into 8.0, but I do want to give y'all a chance to review this change as well. If anyone objects to this change being MFC'ed to 8.0-RELEASE, or has other comments or suggestions please speak up ASAP. Doug PS, please pardon the line wrap below ... - -------- Original Message -------- Subject: svn commit: r197947 - in head/etc: . rc.d Date: Sat, 10 Oct 2009 22:17:03 +0000 (UTC) Author: dougb Date: Sat Oct 10 22:17:03 2009 New Revision: 197947 URL: http://svn.freebsd.org/changeset/base/197947 Log: In regards to the "Starting foo:" type messages at boot time, create and employ a more generic solution, and use it in the individual rc.d scripts that also have an $rc_quiet test: 1. Add check_startmsgs() to rc.subr. 2. In the rc.d scripts that use rc_quiet (and rc.subr) substitute variations of [ -z "$rc_quiet" ] with check_startmsgs 3. In savecore add a trailing '.' to the end of the message to make it more consistent with other scripts. 4. In newsyslog remove a : before the terminal '.' since we do not expect there to be anything printed out in between to make it more consistent. 5. In the following scripts change "quotes" to 'quotes' where no variables exist in the message: savecore pf newsyslog 6. In the following scripts substitute if/then/fi for the simpler (and more consistent) check_startmsgs &&: faith stf 7. In the following scripts separate the "Starting foo:" from the terminal '.' to make them more consistent: moused hostname pf 8. In nfsclient move the message to its own line to avoid a style bug 9. In pf rc_quiet does not apply to the _stop method, so remove the test there. 10. In motd add 'quotes' around the terminal '.' for consistency Modified: head/etc/rc.d/bgfsck head/etc/rc.d/cleartmp head/etc/rc.d/faith head/etc/rc.d/fsck head/etc/rc.d/hostid head/etc/rc.d/hostname head/etc/rc.d/ldconfig head/etc/rc.d/motd head/etc/rc.d/mountcritlocal head/etc/rc.d/moused head/etc/rc.d/netif head/etc/rc.d/newsyslog head/etc/rc.d/nfsclient head/etc/rc.d/pf head/etc/rc.d/savecore head/etc/rc.d/stf head/etc/rc.subr Modified: head/etc/rc.d/bgfsck ============================================================================== - --- head/etc/rc.d/bgfsck Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/bgfsck Sat Oct 10 22:17:03 2009 (r197947) @@ -31,7 +31,7 @@ bgfsck_start () bgfsck_msg="${bgfsck_msg} in ${background_fsck_delay} seconds" fi if [ -z "${rc_force}" ]; then - - [ -z "${rc_quiet}" ] && echo "${bgfsck_msg}." + check_startmsgs && echo "${bgfsck_msg}." fi (sleep ${background_fsck_delay}; nice -4 fsck -B -p) 2>&1 | \ Modified: head/etc/rc.d/cleartmp ============================================================================== - --- head/etc/rc.d/cleartmp Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/cleartmp Sat Oct 10 22:17:03 2009 (r197947) @@ -25,7 +25,7 @@ cleartmp_start() ${tmp}/.ICE-unix ${tmp}/.font-unix" if checkyesno ${rcvar1}; then - - [ -z "${rc_quiet}" ] && echo "Clearing ${tmp}." + check_startmsgs && echo "Clearing ${tmp}." # This is not needed for mfs, but doesn't hurt anything. # Things to note: @@ -44,7 +44,7 @@ cleartmp_start() elif checkyesno clear_tmp_X; then # Remove X lock files, since they will prevent you from # restarting X. Remove other X related directories. - - [ -z "${rc_quiet}" ] && echo "Clearing ${tmp} (X related)." + check_startmsgs && echo "Clearing ${tmp} (X related)." rm -rf ${tmp}/.X[0-9]-lock ${x11_socket_dirs} fi if checkyesno clear_tmp_X; then Modified: head/etc/rc.d/faith ============================================================================== - --- head/etc/rc.d/faith Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/faith Sat Oct 10 22:17:03 2009 (r197947) @@ -39,9 +39,7 @@ faith_up() route change -inet6 ${prefix} -prefixlen ${prefixlen} \ -ifp faith0 done - - if [ -z "${rc_quiet}" ]; then - - ifconfig faith0 - - fi + check_startmsgs && ifconfig faith0 ;; esac } Modified: head/etc/rc.d/fsck ============================================================================== - --- head/etc/rc.d/fsck Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/fsck Sat Oct 10 22:17:03 2009 (r197947) @@ -23,7 +23,7 @@ fsck_start() # During fsck ignore SIGQUIT trap : 3 - - [ -z "${rc_quiet}" ] && echo "Starting file system checks:" + check_startmsgs && echo "Starting file system checks:" if checkyesno background_fsck; then fsck -F -p else Modified: head/etc/rc.d/hostid ============================================================================== - --- head/etc/rc.d/hostid Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/hostid Sat Oct 10 22:17:03 2009 (r197947) @@ -49,9 +49,9 @@ hostid_set() # Set both kern.hostuuid and kern.hostid. # - - [ -z "${rc_quiet}" ] && echo "Setting hostuuid: ${uuid}." + check_startmsgs && echo "Setting hostuuid: ${uuid}." ${SYSCTL_W} kern.hostuuid="${uuid}" >/dev/null - - [ -z "${rc_quiet}" ] && echo "Setting hostid: ${id}." + check_startmsgs && echo "Setting hostid: ${id}." ${SYSCTL_W} kern.hostid=${id} >/dev/null } Modified: head/etc/rc.d/hostname ============================================================================== - --- head/etc/rc.d/hostname Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/hostname Sat Oct 10 22:17:03 2009 (r197947) @@ -72,8 +72,9 @@ hostname_start() # All right, it is safe to invoke hostname(1) now. # - - [ -z "${rc_quiet}" ] && echo "Setting hostname: ${hostname}." + check_startmsgs && echo -n "Setting hostname: ${hostname}" /bin/hostname "${hostname}" + check_startmsgs && echo '.' } load_rc_config $name Modified: head/etc/rc.d/ldconfig ============================================================================== - --- head/etc/rc.d/ldconfig Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/ldconfig Sat Oct 10 22:17:03 2009 (r197947) @@ -36,7 +36,7 @@ ldconfig_start() _LDC="${_LDC} ${i}" fi done - - [ -z "${rc_quiet}" ] && echo 'ELF ldconfig path:' ${_LDC} + check_startmsgs && echo 'ELF ldconfig path:' ${_LDC} ${ldconfig} -elf ${_ins} ${_LDC} case `sysctl -n hw.machine_arch` in @@ -55,7 +55,7 @@ ldconfig_start() _LDC="${_LDC} ${i}" fi done - - [ -z "${rc_quiet}" ] && + check_startmsgs && echo '32-bit compatibility ldconfig path:' ${_LDC} ${ldconfig} -32 -m ${_ins} ${_LDC} ;; @@ -72,8 +72,7 @@ ldconfig_start() _LDC="${_LDC} ${i}" fi done - - [ -z "${rc_quiet}" ] && - - echo 'a.out ldconfig path:' ${_LDC} + check_startmsgs && echo 'a.out ldconfig path:' ${_LDC} ${ldconfig} -aout ${_ins} ${_LDC} ;; esac Modified: head/etc/rc.d/motd ============================================================================== - --- head/etc/rc.d/motd Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/motd Sat Oct 10 22:17:03 2009 (r197947) @@ -22,7 +22,7 @@ motd_start() # Must be done *before* interactive logins are possible # to prevent possible race conditions. # - - [ -z "${rc_quiet}" ] && echo -n 'Updating motd:' + check_startmsgs && echo -n 'Updating motd:' if [ ! -f /etc/motd ]; then install -c -o root -g wheel -m ${PERMS} /dev/null /etc/motd fi @@ -42,7 +42,7 @@ motd_start() } rm -f $T - - [ -z "${rc_quiet}" ] && echo . + check_startmsgs && echo '.' } load_rc_config $name Modified: head/etc/rc.d/mountcritlocal ============================================================================== - --- head/etc/rc.d/mountcritlocal Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/mountcritlocal Sat Oct 10 22:17:03 2009 (r197947) @@ -28,7 +28,7 @@ mountcritlocal_start() esac # Mount everything except nfs filesystems. - - [ -z "${rc_quiet}" ] && echo -n 'Mounting local file systems:' + check_startmsgs && echo -n 'Mounting local file systems:' mount_excludes='no' for i in ${netfs_types}; do fstype=${i%:*} @@ -37,7 +37,7 @@ mountcritlocal_start() mount_excludes=${mount_excludes%,} mount -a -t ${mount_excludes} err=$? - - [ -z "${rc_quiet}" ] && echo '.' + check_startmsgs && echo '.' case ${err} in 0) Modified: head/etc/rc.d/moused ============================================================================== - --- head/etc/rc.d/moused Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/moused Sat Oct 10 22:17:03 2009 (r197947) @@ -51,8 +51,9 @@ moused_start() mytype="$moused_type" fi - - [ -z "${rc_quiet}" ] && echo -n "Starting ${ms} moused." + check_startmsgs && echo -n "Starting ${ms} moused" /usr/sbin/moused ${myflags} -p ${myport} -t ${mytype} ${pidarg} + check_startmsgs && echo '.' mousechar_arg= case ${mousechar_start} in Modified: head/etc/rc.d/netif ============================================================================== - --- head/etc/rc.d/netif Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/netif Sat Oct 10 22:17:03 2009 (r197947) @@ -143,7 +143,7 @@ network_common() ;; esac echo "${_str} Network:${_ok}." - - if [ -z "${rc_quiet}" ]; then + if check_startmsgs; then for ifn in ${_ok}; do /sbin/ifconfig ${ifn} done Modified: head/etc/rc.d/newsyslog ============================================================================== - --- head/etc/rc.d/newsyslog Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/newsyslog Sat Oct 10 22:17:03 2009 (r197947) @@ -17,9 +17,9 @@ stop_cmd=":" newsyslog_start() { - - [ -z "${rc_quiet}" ] && echo -n "Creating and/or trimming log files:" + check_startmsgs && echo -n 'Creating and/or trimming log files' ${command} ${rc_flags} - - [ -z "${rc_quiet}" ] && echo "." + check_startmsgs && echo '.' } load_rc_config $name Modified: head/etc/rc.d/nfsclient ============================================================================== - --- head/etc/rc.d/nfsclient Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/nfsclient Sat Oct 10 22:17:03 2009 (r197947) @@ -22,7 +22,8 @@ nfsclient_start() # if [ -n "${nfs_access_cache}" ]; then - - [ -z "${rc_quiet}" ] && echo "NFS access cache time=${nfs_access_cache}" + check_startmsgs && + echo "NFS access cache time=${nfs_access_cache}" if ! sysctl vfs.nfs.access_cache_timeout=${nfs_access_cache} >/dev/null; then warn "failed to set access cache timeout" fi Modified: head/etc/rc.d/pf ============================================================================== - --- head/etc/rc.d/pf Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/pf Sat Oct 10 22:17:03 2009 (r197947) @@ -25,19 +25,21 @@ required_modules="pf" pf_start() { - - [ -z "${rc_quiet}" ] && echo "Enabling pf." + check_startmsgs && echo -n 'Enabling pf' $pf_program -F all > /dev/null 2>&1 $pf_program -f "$pf_rules" $pf_flags if ! $pf_program -s info | grep -q "Enabled" ; then $pf_program -e fi + check_startmsgs && echo '.' } pf_stop() { if $pf_program -s info | grep -q "Enabled" ; then - - [ -z "${rc_quiet}" ] && echo "Disabling pf." + echo -n 'Disabling pf' $pf_program -d + echo '.' fi } Modified: head/etc/rc.d/savecore ============================================================================== - --- head/etc/rc.d/savecore Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/savecore Sat Oct 10 22:17:03 2009 (r197947) @@ -69,7 +69,7 @@ savecore_start() ${crashinfo_program} -d ${dumpdir} fi else - - [ -z "${rc_quiet}" ] && echo "No core dumps found" + check_startmsgs && echo 'No core dumps found.' fi } Modified: head/etc/rc.d/stf ============================================================================== - --- head/etc/rc.d/stf Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.d/stf Sat Oct 10 22:17:03 2009 (r197947) @@ -53,9 +53,8 @@ stf_up() ifconfig stf0 create >/dev/null 2>&1 ifconfig stf0 inet6 2002:${ipv4_in_hexformat}:${stf_interface_ipv6_slaid:-0}:${stf_interface_ipv6_ifid} \ prefixlen ${stf_prefixlen} - - if [ -z "${rc_quiet}" ]; then - - /sbin/ifconfig stf0 - - fi + check_startmsgs && /sbin/ifconfig stf0 + # disallow packets to malicious 6to4 prefix route add -inet6 2002:e000:: -prefixlen 20 ::1 -reject route add -inet6 2002:7f00:: -prefixlen 24 ::1 -reject Modified: head/etc/rc.subr ============================================================================== - --- head/etc/rc.subr Sat Oct 10 21:56:39 2009 (r197946) +++ head/etc/rc.subr Sat Oct 10 22:17:03 2009 (r197947) @@ -398,6 +398,20 @@ wait_for_pids() } # +# check_startmsgs +# If rc_quiet is set (usually as a result of using faststart at +# boot time) check if rc_startmsgs is enabled. +# +check_startmsgs() +{ + if [ -n "$rc_quiet" ]; then + checkyesno rc_startmsgs + else + return 0 + fi +} + +# # run_rc_command argument # Search for argument in the list of supported commands, which is: # "start stop restart rcvar status poll ${extra_commands}" @@ -708,13 +722,7 @@ run_rc_command() # setup the full command to run # - - _show_startmsgs=1 - - if [ -n "${rc_quiet}" ]; then - - if ! checkyesno rc_startmsgs; then - - unset _show_startmsgs - - fi - - fi - - [ -n "$_show_startmsgs" ] && echo "Starting ${name}." + check_startmsgs && echo "Starting ${name}." if [ -n "$_chroot" ]; then _doit="\ ${_nice:+nice -n $_nice }\ - -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEAREDAAYFAkrSRgoACgkQyIakK9Wy8PuW5QCfcsYuCcsgQP6FYvNCXkGjg5Wg fnMAoL4JRVKCsrHX3zWqdyvYeQi9IT5d =pTmG -----END PGP SIGNATURE----- From bugmaster at FreeBSD.org Mon Oct 12 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:09:13 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200910121107.n9CB70US036528@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/138208 rc [rc] [patch] Making rc.firewall (workstation) IPv6 awa o conf/137629 rc [rc] background_dhclient rc.conf option causing double o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132766 rc wait_for_pids() in /etc/rc.subr is dull. o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/130414 rc [patch] rc services started with onestart are not stop o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 60 problems total. From dougb at FreeBSD.org Mon Oct 12 22:01:09 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 22:01:15 2009 Subject: svn commit: r197790 - head/etc In-Reply-To: <200910052011.n95KBXdS024044@svn.freebsd.org> References: <200910052011.n95KBXdS024044@svn.freebsd.org> Message-ID: <4AD3A722.9060401@FreeBSD.org> I think this is the wrong solution to the problem. In at least two cases (routed and route6d) where $command is not defined in the rc.d scripts this change is resulting in $command not being defined at all. If you look at the definition of the + parameter substitution this makes sense: ${parameter:+word} Use Alternate Value. If parameter is unset or null, null is substituted; otherwise, the expansion of word is substituted. I think that what you really wanted to do was: Index: rc.subr =================================================================== --- rc.subr (revision 198000) +++ rc.subr (working copy) @@ -616,7 +616,7 @@ esac eval _override_command=\$${name}_program - command=${command:+${_override_command:-$command}} + command=${_override_command:-$command} _keywords="start stop restart rcvar $extra_commands" rc_pid= That actually makes more sense anyway, at least to me since it allows the user to override the definition of command in rc.conf, which seems consistent with how we override other things. Mark, can you revert the band-aids that I supplied previously and try this instead? Anyone else have a comment on this idea? Doug Hiroki Sato wrote: > Author: hrs > Date: Mon Oct 5 20:11:33 2009 > New Revision: 197790 > URL: http://svn.freebsd.org/changeset/base/197790 > > Log: > Fix a case when both ${name}_program and ${command} are defined. > > Spotted by: Michio "Karl" Jinbo > > Modified: > head/etc/rc.subr > > Modified: head/etc/rc.subr > ============================================================================== > --- head/etc/rc.subr Mon Oct 5 19:56:56 2009 (r197789) > +++ head/etc/rc.subr Mon Oct 5 20:11:33 2009 (r197790) > @@ -602,7 +602,7 @@ run_rc_command() > esac > > eval _override_command=\$${name}_program > - command=${command:-${_override_command}} > + command=${command:+${_override_command:-$command}} > > _keywords="start stop restart rcvar $extra_commands" > rc_pid= > -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at FreeBSD.org Wed Oct 14 03:55:50 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Oct 14 03:55:57 2009 Subject: A more thorough "Starting foo:" solution In-Reply-To: <4AD2460A.3000902@FreeBSD.org> References: <4AD2460A.3000902@FreeBSD.org> Message-ID: <4AD54BBD.4020704@FreeBSD.org> Doug Barton wrote: > After giving this a more thorough look I realized that there were > quite a few places where $rc_quiet was being used directly in an rc.d > script (16 scripts total). > > I've already committed this to HEAD in order to try and make the MFC > deadline to potentially get it into 8.0, but I do want to give y'all a > chance to review this change as well. > > If anyone objects to this change being MFC'ed to 8.0-RELEASE, or has > other comments or suggestions please speak up ASAP. I haven't heard any comments about this, so I've requested permission to MFC it to RELENG_8. If you have any concerns speak up now. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dimitry at andric.com Wed Oct 14 09:45:41 2009 From: dimitry at andric.com (Dimitry Andric) Date: Wed Oct 14 09:45:47 2009 Subject: A more thorough "Starting foo:" solution In-Reply-To: <4AD2460A.3000902@FreeBSD.org> References: <4AD2460A.3000902@FreeBSD.org> Message-ID: <4AD59DCC.9000008@andric.com> On 2009-10-11 22:54, Doug Barton wrote: > After giving this a more thorough look I realized that there were > quite a few places where $rc_quiet was being used directly in an rc.d > script (16 scripts total). > > I've already committed this to HEAD in order to try and make the MFC > deadline to potentially get it into 8.0, but I do want to give y'all a > chance to review this change as well. > > If anyone objects to this change being MFC'ed to 8.0-RELEASE, or has > other comments or suggestions please speak up ASAP. I see no problems with MFC'ing, this is a nice way of cleaning up. That said, there are still quite a number of scripts in rc.d that don't check rc_quiet at all, and just echo whatever they like. Therefore, couldn't all those "check_startmsgs && echo foo" constructs, plus the other echo's be replaced with, say, a spam() function from /etc/rc.subr? This function can then check in one central location for rc_startmsgs and decide whether to spam the console or not. One could even start implementing some verbosity level using this... :) From dougb at FreeBSD.org Wed Oct 14 18:02:25 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Oct 14 18:02:36 2009 Subject: A more thorough "Starting foo:" solution In-Reply-To: <4AD59DCC.9000008@andric.com> References: <4AD2460A.3000902@FreeBSD.org> <4AD59DCC.9000008@andric.com> Message-ID: <4AD6122F.3090407@FreeBSD.org> Dimitry Andric wrote: > On 2009-10-11 22:54, Doug Barton wrote: >> After giving this a more thorough look I realized that there were >> quite a few places where $rc_quiet was being used directly in an rc.d >> script (16 scripts total). >> >> I've already committed this to HEAD in order to try and make the MFC >> deadline to potentially get it into 8.0, but I do want to give y'all a >> chance to review this change as well. >> >> If anyone objects to this change being MFC'ed to 8.0-RELEASE, or has >> other comments or suggestions please speak up ASAP. > > I see no problems with MFC'ing, this is a nice way of cleaning up. Thanks. > That said, there are still quite a number of scripts in rc.d that don't > check rc_quiet at all, and just echo whatever they like. > > Therefore, couldn't all those "check_startmsgs && echo foo" constructs, > plus the other echo's be replaced with, say, a spam() function from > /etc/rc.subr? This function can then check in one central location for > rc_startmsgs and decide whether to spam the console or not. > > One could even start implementing some verbosity level using this... :) My intention was to give users the option to get back to where things were before they were fiddled with in time for the release. I actually gave some thought along similar lines when I was working on this patch since there are some things that I restored that I personally don't care about seeing. I look forward to reviewing your patches. :) Doug From hrs at FreeBSD.org Thu Oct 15 07:20:23 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Thu Oct 15 07:20:56 2009 Subject: svn commit: r197790 - head/etc In-Reply-To: <4AD3A722.9060401@FreeBSD.org> References: <200910052011.n95KBXdS024044@svn.freebsd.org> <4AD3A722.9060401@FreeBSD.org> Message-ID: <20091015.161939.200967153.hrs@allbsd.org> Hi Doug, Doug Barton wrote in <4AD3A722.9060401@FreeBSD.org>: do> I think this is the wrong solution to the problem. In at least two do> cases (routed and route6d) where $command is not defined in the rc.d do> scripts this change is resulting in $command not being defined at all. do> do> If you look at the definition of the + parameter substitution this do> makes sense: do> do> ${parameter:+word} do> Use Alternate Value. If parameter is unset or null, null do> is substituted; otherwise, the expansion of word is do> substituted. do> do> I think that what you really wanted to do was: I am sorry for the delay. Your patch is reasonable to me. This problem was there for a while, so it should be fixed asap. I noticed there was something wrong about ${name}_program but it seems I mistakenly changed it (sorry...). Then I received a report "it does not work" so I just reverted it. IMO defining $command in rc.d scripts is not a good practice. "Always use ${name}_program and let load_rc_config() set the $command" would be consistent and useful to avoid this sort of problems. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091015/400bee54/attachment.pgp From dougb at FreeBSD.org Fri Oct 16 00:06:21 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Oct 16 00:06:28 2009 Subject: svn commit: r197790 - head/etc In-Reply-To: <20091015.161939.200967153.hrs@allbsd.org> References: <200910052011.n95KBXdS024044@svn.freebsd.org> <4AD3A722.9060401@FreeBSD.org> <20091015.161939.200967153.hrs@allbsd.org> Message-ID: <4AD7B8FA.7020703@FreeBSD.org> Hiroki Sato wrote: > Hi Doug, > > Doug Barton wrote > in <4AD3A722.9060401@FreeBSD.org>: > > do> I think this is the wrong solution to the problem. In at least two > do> cases (routed and route6d) where $command is not defined in the rc.d > do> scripts this change is resulting in $command not being defined at all. > do> > do> If you look at the definition of the + parameter substitution this > do> makes sense: > do> > do> ${parameter:+word} > do> Use Alternate Value. If parameter is unset or null, null > do> is substituted; otherwise, the expansion of word is > do> substituted. > do> > do> I think that what you really wanted to do was: > > I am sorry for the delay. Your patch is reasonable to me. This > problem was there for a while, so it should be fixed asap. Ok, I've committed the fix, thanks for getting back to me. > I noticed there was something wrong about ${name}_program but it > seems I mistakenly changed it (sorry...). Then I received a report > "it does not work" so I just reverted it. Understood. I am sure you realize that it's always Ok to ask for help here on -rc. The rc.d system is not life-threateningly complex but it does have a lot of "behind the scenes" interactions that are not always obvious. I certainly don't hesitate to ask for review on changes myself and I encourage others to do so (as you have done in the past). FWIW, what I do object to about your changes in r197144 and r197790 are that in the first case you neglected to mention that you were changing that part of the code, and in the second you neglected to mention that you were changing it back to what it was before you changed it. That made debugging this problem more difficult for me than (I think) it should have been. You also did not mention that you were removing $command in your changes to route[6]d, which made debugging Mark's original complaint harder, but only for about 30 seconds or so. :) The two most important things about VCS logs are WHAT you did (should be brief, but thorough) and WHY you did it. My logs are often obnoxiously long, but you can generally find at least that information in them. Please think about what people who read the logs years from now will need to know. Of course, I realize that this is difficult to do, especially when you are just wrapping up a project and all of the information is fresh in your head and seems painfully obvious. > IMO defining $command in rc.d scripts is not a good practice. > "Always use ${name}_program and let load_rc_config() set the > $command" would be consistent and useful to avoid this sort of > problems. In the past since there was not a reliable mechanism to allow ${name}_program to override $command, and because rc.subr needs to have $command defined to work properly (see the description in the run_rc_command comments in rc.subr) it was necessary to set command in each script. When yar introduced the current version of the override code almost 4 years ago he also went through and set command explicitly in all the scripts that didn't have it, so the situation that was created here never came up until now. (FYI, the previous code that he replaced had the same effect as what I just changed it to but was slightly more complex.) I'm sort of ambivalent about whether we need to continue encouraging people to use command in the script or not. As long as what's in the script matches what's in /etc/defaults/rc.conf we're not hurting anything, although we are duplicating effort. My preference at this point is to let the change that I just made settle for a while, mostly to see if it has any negative interactions with scripts from ports, then MFC it after 8.0-RELEASE along with the changes you've made to the IPv6 stuff. After that we can start talking about ripping command= out of the individual rc.d scripts if people think that's a good idea. Doug PS, Mark you're a slacker for not getting back to me. :) -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From freebsd at levsha.org.ua Sat Oct 17 17:51:31 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Sat Oct 17 17:51:37 2009 Subject: Circular dependency in rc.d after r197527 Message-ID: <20091017171853.GA29771@expo.ukrweb.net> Hi! After r197527 circular dependency found in rc.d scripts: stf and faith conatins # REQUIRE: netif routing and after r197527 routing contains # REQUIRE: faith netif ppp stf I think tath deleting "routing" from REQUIRE list on stf and faith required. -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua From dougb at FreeBSD.org Sat Oct 17 20:19:14 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Oct 17 20:19:21 2009 Subject: Circular dependency in rc.d after r197527 In-Reply-To: <20091017171853.GA29771@expo.ukrweb.net> References: <20091017171853.GA29771@expo.ukrweb.net> Message-ID: <4ADA2080.6060502@FreeBSD.org> Mykola Dzham wrote: > Hi! > After r197527 circular dependency found in rc.d scripts: stf and faith > conatins > # REQUIRE: netif routing > and after r197527 routing contains > # REQUIRE: faith netif ppp stf > > I think tath deleting "routing" from REQUIRE list on stf and faith > required. Agreed. hrs, any objections? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From hrs at FreeBSD.org Sat Oct 17 20:52:12 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sat Oct 17 20:52:19 2009 Subject: Circular dependency in rc.d after r197527 In-Reply-To: <4ADA2080.6060502@FreeBSD.org> References: <20091017171853.GA29771@expo.ukrweb.net> <4ADA2080.6060502@FreeBSD.org> Message-ID: <20091018.054929.261416476.hrs@allbsd.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091017/174475ef/attachment.pgp From dougb at FreeBSD.org Sat Oct 17 21:10:17 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Oct 17 21:10:23 2009 Subject: Circular dependency in rc.d after r197527 In-Reply-To: <20091018.054929.261416476.hrs@allbsd.org> References: <20091017171853.GA29771@expo.ukrweb.net> <4ADA2080.6060502@FreeBSD.org> <20091018.054929.261416476.hrs@allbsd.org> Message-ID: <4ADA32B5.5030304@FreeBSD.org> Hiroki Sato wrote: > Thank you for pointing out it. No objection from me. The attached > patch should fix it. Ok, done. Thanks for the quick reply. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From bugmaster at FreeBSD.org Mon Oct 19 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:09:25 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200910191107.n9JB70fL063552@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/138208 rc [rc] [patch] Making rc.firewall (workstation) IPv6 awa o conf/137629 rc [rc] background_dhclient rc.conf option causing double o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132766 rc wait_for_pids() in /etc/rc.subr is dull. o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/130414 rc [patch] rc services started with onestart are not stop o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 60 problems total. From bugmaster at FreeBSD.org Mon Oct 26 11:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:09:44 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200910261107.n9QB76uC043869@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/138208 rc [rc] [patch] Making rc.firewall (workstation) IPv6 awa o conf/137629 rc [rc] background_dhclient rc.conf option causing double o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132766 rc wait_for_pids() in /etc/rc.subr is dull. o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/130414 rc [patch] rc services started with onestart are not stop o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 60 problems total. From hrs at FreeBSD.org Tue Oct 27 06:48:58 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Tue Oct 27 06:49:31 2009 Subject: svn commit: r197790 - head/etc In-Reply-To: <4AD7B8FA.7020703@FreeBSD.org> References: <4AD3A722.9060401@FreeBSD.org> <20091015.161939.200967153.hrs@allbsd.org> <4AD7B8FA.7020703@FreeBSD.org> Message-ID: <20091027.154257.185630115.hrs@allbsd.org> Hi Doug, sorry again for the delayed response. I have been distracted by a busy few weeks due to my day job... Doug Barton wrote in <4AD7B8FA.7020703@FreeBSD.org>: do> > I noticed there was something wrong about ${name}_program but it do> > seems I mistakenly changed it (sorry...). Then I received a report do> > "it does not work" so I just reverted it. do> do> Understood. I am sure you realize that it's always Ok to ask for help do> here on -rc. The rc.d system is not life-threateningly complex but it do> does have a lot of "behind the scenes" interactions that are not do> always obvious. I certainly don't hesitate to ask for review on do> changes myself and I encourage others to do so (as you have done in do> the past). do> do> FWIW, what I do object to about your changes in r197144 and r197790 do> are that in the first case you neglected to mention that you were do> changing that part of the code, and in the second you neglected to do> mention that you were changing it back to what it was before you do> changed it. That made debugging this problem more difficult for me do> than (I think) it should have been. You also did not mention that you do> were removing $command in your changes to route[6]d, which made do> debugging Mark's original complaint harder, but only for about 30 do> seconds or so. :) Yes, indeed. I should have been more careful and will keep it in mind. Sorry about that. do> I'm sort of ambivalent about whether we need to continue encouraging do> people to use command in the script or not. As long as what's in the do> script matches what's in /etc/defaults/rc.conf we're not hurting do> anything, although we are duplicating effort. do> do> My preference at this point is to let the change that I just made do> settle for a while, mostly to see if it has any negative interactions do> with scripts from ports, then MFC it after 8.0-RELEASE along with the do> changes you've made to the IPv6 stuff. After that we can start talking do> about ripping command= out of the individual rc.d scripts if people do> think that's a good idea. Sounds reasonable to me. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20091027/598e66fa/attachment.pgp From dougb at FreeBSD.org Tue Oct 27 22:34:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Oct 27 22:35:04 2009 Subject: svn commit: r197790 - head/etc In-Reply-To: <20091027.154257.185630115.hrs@allbsd.org> References: <4AD3A722.9060401@FreeBSD.org> <20091015.161939.200967153.hrs@allbsd.org> <4AD7B8FA.7020703@FreeBSD.org> <20091027.154257.185630115.hrs@allbsd.org> Message-ID: <4AE77593.4030904@FreeBSD.org> Hiroki Sato wrote: > Hi Doug, sorry again for the delayed response. I have been distracted > by a busy few weeks due to my day job... No problem, I know the feeling. :) > Doug Barton wrote > in <4AD7B8FA.7020703@FreeBSD.org>: > > do> > I noticed there was something wrong about ${name}_program but it > do> > seems I mistakenly changed it (sorry...). Then I received a report > do> > "it does not work" so I just reverted it. > do> > do> Understood. I am sure you realize that it's always Ok to ask for help > do> here on -rc. The rc.d system is not life-threateningly complex but it > do> does have a lot of "behind the scenes" interactions that are not > do> always obvious. I certainly don't hesitate to ask for review on > do> changes myself and I encourage others to do so (as you have done in > do> the past). > do> > do> FWIW, what I do object to about your changes in r197144 and r197790 > do> are that in the first case you neglected to mention that you were > do> changing that part of the code, and in the second you neglected to > do> mention that you were changing it back to what it was before you > do> changed it. That made debugging this problem more difficult for me > do> than (I think) it should have been. You also did not mention that you > do> were removing $command in your changes to route[6]d, which made > do> debugging Mark's original complaint harder, but only for about 30 > do> seconds or so. :) > > Yes, indeed. I should have been more careful and will keep it in > mind. Sorry about that. These things happen, I'm not really that concerned about it. The whole "keep in mind how people will read this commit message years from now" thing is something that I have to constantly remind myself of as well. > do> I'm sort of ambivalent about whether we need to continue encouraging > do> people to use command in the script or not. As long as what's in the > do> script matches what's in /etc/defaults/rc.conf we're not hurting > do> anything, although we are duplicating effort. > do> > do> My preference at this point is to let the change that I just made > do> settle for a while, mostly to see if it has any negative interactions > do> with scripts from ports, then MFC it after 8.0-RELEASE along with the > do> changes you've made to the IPv6 stuff. After that we can start talking > do> about ripping command= out of the individual rc.d scripts if people > do> think that's a good idea. > > Sounds reasonable to me. Given that no one has reported any problems with this, and that it restores the code to what was happening prior to yar's command= fixes I decided to ask for MFC permission but given the impending RC2 the request is on hold. My feelings won't be hurt if it doesn't get approved for 8.0-release though, so I'm happy either way. FYI, I'm currently in the process of cleaning things up locally so that I'll have time to give more review to your changes over the last couple months. I'm seeing some weirdness with my wireless interface that I think we can probably nail down without too much effort. At this point I'm not actually sure that it is related to your changes in any case. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/