From dougb at FreeBSD.org Mon Jun 1 06:08:35 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 06:09:44 2009 Subject: svn commit: r193112 - head/etc/rc.d In-Reply-To: References: <200905301938.n4UJcpbF017191@svn.freebsd.org> <4A22CFA1.3050408@FreeBSD.org> Message-ID: <4A23705C.3020603@FreeBSD.org> Dmitry Morozovsky wrote: > On Sun, 31 May 2009, Doug Barton wrote: > > DB> Dmitry Morozovsky wrote: > DB> > Doug, > DB> > > DB> > On Sat, 30 May 2009, Doug Barton wrote: > DB> > > DB> > DB> Author: dougb > DB> > DB> Date: Sat May 30 19:38:51 2009 > DB> > DB> New Revision: 193112 > DB> > DB> URL: http://svn.freebsd.org/changeset/base/193112 > DB> > DB> > DB> > DB> Log: > DB> > DB> As previously advertised, remove this script prior to the 8.0 branch. > DB> > > DB> > Was there an agreement what should one do with dumping to gmirror (see > DB> > sbin/geom/class/mirror/gmirror.8) ? > DB> > DB> I'm not familiar with that issue, but it sounds like something that > DB> needs its own rc.d script. If someone who knows what is supposed to > DB> happen wants to write something up and send it to the freebsd-rc@ list > DB> I'll be glad to help review it. > > Something like (checks should be added, yeah) This is fine, but for consistency with the other stuff in rc.d the name of the script, the value of $name, and the PROVIDE should all be the same. I would name it something like gmsc and in etc/defaults/rc.conf (and probably in the script itself) add a comment indicating what it's for. Not sure what you mean by "checks should be added," I'm not familiar with gmirror at all. But it looks like you're on the right track, yes. Doug > #!/bin/sh > # > # $FreeBSD$ > # > > # BEFORE: savecore > # PROVIDE: gmirror-savecore > # KEYWORD: nojail > > . /etc/rc.subr > > name="gmirror_savecore" > start_cmd="gmsavecore_start" > stop_cmd=":" > > gmsavecore_start() > { > gmirror configure -b prefer /dev/dumpdev > } > > load_rc_config $name > run_rc_command "$1" > > possibly? > -- This .signature sanitized for your protection From marck at rinet.ru Mon Jun 1 07:28:17 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Mon Jun 1 07:28:23 2009 Subject: svn commit: r193112 - head/etc/rc.d In-Reply-To: <4A23705C.3020603@FreeBSD.org> References: <200905301938.n4UJcpbF017191@svn.freebsd.org> <4A22CFA1.3050408@FreeBSD.org> <4A23705C.3020603@FreeBSD.org> Message-ID: On Sun, 31 May 2009, Doug Barton wrote: DB> > DB> > DB> As previously advertised, remove this script prior to the 8.0 branch. DB> > DB> > DB> > DB> > Was there an agreement what should one do with dumping to gmirror (see DB> > DB> > sbin/geom/class/mirror/gmirror.8) ? DB> > DB> DB> > DB> I'm not familiar with that issue, but it sounds like something that DB> > DB> needs its own rc.d script. If someone who knows what is supposed to DB> > DB> happen wants to write something up and send it to the freebsd-rc@ list DB> > DB> I'll be glad to help review it. DB> > DB> > Something like (checks should be added, yeah) DB> DB> This is fine, but for consistency with the other stuff in rc.d the DB> name of the script, the value of $name, and the PROVIDE should all be DB> the same. I would name it something like gmsc and in DB> etc/defaults/rc.conf (and probably in the script itself) add a comment DB> indicating what it's for. DB> DB> Not sure what you mean by "checks should be added," I'm not familiar DB> with gmirror at all. But it looks like you're on the right track, yes. Well, I'm ton very familiar with rc.d scripts rules, so I suppose I missed some _rc.d_ checks, but corrected patch is attached. I'm not sure where second part of gmirror configuring process belong though... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ -------------- next part -------------- Index: defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.356 diff -u -r1.356 rc.conf --- defaults/rc.conf 22 May 2009 13:56:16 -0000 1.356 +++ defaults/rc.conf 1 Jun 2009 07:25:52 -0000 @@ -276,6 +276,7 @@ rwhod_enable="NO" # Run the rwho daemon (or NO). rwhod_flags="" # Flags for rwhod +rwhod_delay="0" # Delay in seconds before starting rwhod rarpd_enable="NO" # Run rarpd (or NO). rarpd_flags="-a" # Flags to rarpd. bootparamd_enable="NO" # Run bootparamd (or NO). @@ -546,8 +547,7 @@ dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. -crashinfo_enable="YES" # Automatically generate crash dump summary. -crashinfo_program="/usr/sbin/crashinfo" # Script to generate crash dump summary. +gmsc_enable="NO" # If gmirror is used for dumps, prepare it for savecore quota_enable="NO" # turn on quotas on startup (or NO). check_quotas="YES" # Check quotas on startup (or NO). quotaon_flags="-a" # Turn quotas on for all file systems (if enabled) Index: rc.d/Makefile =================================================================== RCS file: /home/ncvs/src/etc/rc.d/Makefile,v retrieving revision 1.97 diff -u -r1.97 Makefile --- rc.d/Makefile 30 May 2009 19:38:51 -0000 1.97 +++ rc.d/Makefile 1 Jun 2009 07:25:52 -0000 @@ -11,7 +11,7 @@ dmesg dumpon \ encswap \ fsck ftp-proxy ftpd \ - gbde geli geli2 gssd \ + gbde geli geli2 gmsc gssd \ hcsecd \ hostapd hostid hostname \ inetd initrandom \ Index: rc.d/gmsc =================================================================== RCS file: rc.d/gmsc diff -N rc.d/gmsc --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ rc.d/gmsc 1 Jun 2009 07:25:52 -0000 @@ -0,0 +1,22 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# BEFORE: savecore +# PROVIDE: gmsc +# KEYWORD: nojail + +. /etc/rc.subr + +name="gmsc" +start_cmd="gmsc_start" +stop_cmd=":" + +gmsavecore_start() +{ + gmirror configure -b prefer ${dumpdev} +} + +load_rc_config $name +run_rc_command "$1" From pjd at FreeBSD.org Mon Jun 1 08:38:53 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Mon Jun 1 08:39:06 2009 Subject: svn commit: r193112 - head/etc/rc.d In-Reply-To: References: <200905301938.n4UJcpbF017191@svn.freebsd.org> <4A22CFA1.3050408@FreeBSD.org> Message-ID: <20090601080646.GB1542@garage.freebsd.pl> On Sun, May 31, 2009 at 11:46:39PM +0400, Dmitry Morozovsky wrote: > On Sun, 31 May 2009, Doug Barton wrote: > > DB> Dmitry Morozovsky wrote: > DB> > Doug, > DB> > > DB> > On Sat, 30 May 2009, Doug Barton wrote: > DB> > > DB> > DB> Author: dougb > DB> > DB> Date: Sat May 30 19:38:51 2009 > DB> > DB> New Revision: 193112 > DB> > DB> URL: http://svn.freebsd.org/changeset/base/193112 > DB> > DB> > DB> > DB> Log: > DB> > DB> As previously advertised, remove this script prior to the 8.0 branch. > DB> > > DB> > Was there an agreement what should one do with dumping to gmirror (see > DB> > sbin/geom/class/mirror/gmirror.8) ? > DB> > DB> I'm not familiar with that issue, but it sounds like something that > DB> needs its own rc.d script. If someone who knows what is supposed to > DB> happen wants to write something up and send it to the freebsd-rc@ list > DB> I'll be glad to help review it. > > Something like (checks should be added, yeah) > > #!/bin/sh > # > # $FreeBSD$ > # > > # BEFORE: savecore > # PROVIDE: gmirror-savecore > # KEYWORD: nojail > > . /etc/rc.subr > > name="gmirror_savecore" > start_cmd="gmsavecore_start" > stop_cmd=":" > > gmsavecore_start() > { > gmirror configure -b prefer /dev/dumpdev > } > > load_rc_config $name > run_rc_command "$1" > > possibly? It's not that simple... First you have to remember previous balance algorithm and recover it once dumping crash dump is done. You also have to check if dumpdev is placed somewhere on a gmirror provider, which is not that simple, unfortunately. Imagine your dump partition is called /dev/label/dump and there is a long way to gmirror provider: label/dump -> mirror/root0s1b -> mirror/root0s1 -> mirror/root0 You can't just call 'gmirror configure -b prefer /dev/label/dump'. I'm happy to review another patch, but I don't really have any bright idea of how this should be implemented:) -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090601/053d74a3/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 1 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:09:21 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200906011106.n51B6w0e021215@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/134918 rc 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/120228 rc [zfs] [patch] Split ZFS volume startup / ease ZFS swap o conf/120194 rc [patch] UFS volumes on ZVOLs cannot be fsck'd at boot 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 57 problems total. From yvesguerin at yahoo.ca Mon Jun 1 12:14:12 2009 From: yvesguerin at yahoo.ca (=?iso-8859-1?Q?Yves_Gu=E9rin?=) Date: Mon Jun 1 12:14:19 2009 Subject: Profile rc idea Message-ID: <354710.32407.qm@web56403.mail.re3.yahoo.com> Dear Doug, I will do some doc to explain what I have done, I will try to produce a patch but my coding style may not follow the freebsd style and a review form the freebsd team will be necessary. Regards, Yves Guerin --- En date de : Sam 30.5.09, Doug Barton a ?crit : De: Doug Barton Objet: Re: Profile rc idea ?: yvesguerin@yahoo.ca Cc: freebsd-rc@freebsd.org Date: Samedi 30 Mai 2009, 0h19 Yves Gu?rin wrote: > I did something similar to your idea, I custom the boot menu (beastie.4th) to choose between home, office, dhcp and default configuration for my network interface on my laptop. > I grab the answer or the choice via the kenv system call, and on my rc directory I start my own script just before netif to configure my network depending on the answer I choose at boot time. So I think the idea can be modify for every used that you can dream of. > > I am able to send you my configuration, the boot menu and the rc file. I really like the idea of leveraging the existing boot menu for this. Can you send your patches to the list? Doug From yvesguerin at yahoo.ca Mon Jun 1 16:28:56 2009 From: yvesguerin at yahoo.ca (=?iso-8859-1?Q?Yves_Gu=E9rin?=) Date: Mon Jun 1 16:30:53 2009 Subject: Profile rc idea Message-ID: <152177.75631.qm@web56408.mail.re3.yahoo.com> Dear Sir, I made a README file but I am not very expert with patch (sorry) so to be able to send my stuff as soon as possible I just did a tarball. If you need help or you have a question just drop me an email. Regards Yves Guerin --- En date de : Sam 30.5.09, Doug Barton a ?crit : De: Doug Barton Objet: Re: Profile rc idea ?: yvesguerin@yahoo.ca Cc: freebsd-rc@freebsd.org Date: Samedi 30 Mai 2009, 0h19 Yves Gu?rin wrote: > I did something similar to your idea, I custom the boot menu (beastie.4th) to choose between home, office, dhcp and default configuration for my network interface on my laptop. > I grab the answer or the choice via the kenv system call, and on my rc directory I start my own script just before netif to configure my network depending on the answer I choose at boot time. So I think the idea can be modify for every used that you can dream of. > > I am able to send you my configuration, the boot menu and the rc file. I really like the idea of leveraging the existing boot menu for this. Can you send your patches to the list? Doug From dougb at FreeBSD.org Mon Jun 1 16:36:33 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 16:36:47 2009 Subject: Profile rc idea In-Reply-To: <152177.75631.qm@web56408.mail.re3.yahoo.com> References: <152177.75631.qm@web56408.mail.re3.yahoo.com> Message-ID: <4A24038C.9020903@FreeBSD.org> Yves Gu?rin wrote: > Dear Sir, > > I made a README file but I am not very expert with patch (sorry) so to > be able to send my stuff as soon as possible I just did a tarball. > > If you need help or you have a question just drop me an email. Thanks! Don't worry about the coding style issues, that'll all get worked out as we develop the idea. Doug From brooks at freebsd.org Mon Jun 1 21:24:59 2009 From: brooks at freebsd.org (Brooks Davis) Date: Mon Jun 1 21:25:05 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A21A4F6.5060709@dougbarton.us> References: <4A21A4F6.5060709@dougbarton.us> Message-ID: <20090601212506.GA2351@lor.one-eyed-alien.net> On Sat, May 30, 2009 at 02:28:22PM -0700, Doug Barton wrote: > Without objection I plan to commit the attached patch before the code > slush, and to MFC the change. I object. Supporting values other than AUTO adds unnecessary complexity (not a lot, but some) and IMO leads to difficulty diagnosing proper system behavior. I'd much rather just delete network_interfaces entirely. I've never seen a valid use case, just failures to understand the current system. > I've never seen the rationale for this, and I use a value other than > AUTO personally for a script I have that tests to see if the wired > interface is up and starts the wireless if not. I've also seen other > users ask about this from time to time, so I'm sure I'm not alone. Please provide this script to support your argument. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090601/3dcf25d6/attachment.pgp From dougb at dougbarton.us Mon Jun 1 22:32:02 2009 From: dougb at dougbarton.us (Doug Barton) Date: Mon Jun 1 22:32:07 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090601212506.GA2351@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> Message-ID: <4A2456DA.8040104@dougbarton.us> Brooks Davis wrote: > On Sat, May 30, 2009 at 02:28:22PM -0700, Doug Barton wrote: >> Without objection I plan to commit the attached patch before the code >> slush, and to MFC the change. > > I object. Supporting values other than AUTO adds unnecessary > complexity (not a lot, but some) and IMO leads to difficulty diagnosing > proper system behavior. Can you provide examples? I've seen this argument before, but I seriously fail to understand it. The code to generate the list for AUTO is trivial, and I've never seen a support question that was caused by setting this to a different value. > I'd much rather just delete network_interfaces entirely. > > I've never seen a valid use case, just failures to understand the > current system. One could argue that the current system needs better documentation which should cover at least half that problem. Meanwhile, I've objected to the original change several times, as have various other users. After I committed the change BMS responded to my message on the svn list to say that he is planning on using this feature for a product that is currently in development as well. >> I've never seen the rationale for this, and I use a value other than >> AUTO personally for a script I have that tests to see if the wired >> interface is up and starts the wireless if not. I've also seen other >> users ask about this from time to time, so I'm sure I'm not alone. > > Please provide this script to support your argument. I set the value of network_interfaces to "lo0 test" and then I have a /etc/start_if.test script that checks to see if my wired interface is up, initializes it if it is, and if not it checks to see which wireless card I'm using and initializes that. I've actually spent quite a lot of time trying to figure out how to accomplish something similar with the current system but AFAICS we don't have a way to do that without hooking it in at the point where the network interfaces are actually configured. At some point in the future when I get a whole bunch of free time I'd like to extend what's in the base in order to do what I'm doing now with my little script ... Doug From m.seaman at infracaninophile.co.uk Tue Jun 2 05:33:35 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Jun 2 05:33:42 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090601212506.GA2351@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> Message-ID: <4A24B99B.9050703@infracaninophile.co.uk> Brooks Davis wrote: > I've never seen a valid use case, just failures to understand the > current system. My laptop has iwi0 and bge0 interfaces. At work, both of these obtain addresses and default routes by DHCP, but from two completely different DHCP servers. When I'm plugged into the wired network I want the bge0 interface to be the default route, but iwi0 comes first in the list of interfaces produced by ifconfig, so it gets configured first and sets the route. Of course, when I'm not plugged into the wired network I want iwi0 to have the default route, so I can't just use dhclient.conf to disregard routing information on that interface. All in all, setting network_interfaces="bge0 iwi0 lo0" does exactly what I want with minimal effort. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090602/9dc11451/signature.pgp From brooks at freebsd.org Tue Jun 2 15:48:26 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 15:48:32 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A2456DA.8040104@dougbarton.us> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <4A2456DA.8040104@dougbarton.us> Message-ID: <20090602154833.GE14685@lor.one-eyed-alien.net> On Mon, Jun 01, 2009 at 03:31:54PM -0700, Doug Barton wrote: > Brooks Davis wrote: > > On Sat, May 30, 2009 at 02:28:22PM -0700, Doug Barton wrote: > >> Without objection I plan to commit the attached patch before the code > >> slush, and to MFC the change. > > > > I object. Supporting values other than AUTO adds unnecessary > > complexity (not a lot, but some) and IMO leads to difficulty diagnosing > > proper system behavior. > > Can you provide examples? I've seen this argument before, but I > seriously fail to understand it. The code to generate the list for > AUTO is trivial, and I've never seen a support question that was > caused by setting this to a different value. It's been a while since I worked on the code and I'm busy so I'll have to back off on that argument for the moment. I do remember it complicating the logic, but don't have the time right now to recall what I wanted to do. I will assert that the second argument is wrong. The deprication notice has reduced the number of errors related to network_interfaces a fair bit. The biggest problem before was that people would omit lo0, but I seem to recall there were several other misunderstanding that removed feet. > >> I've never seen the rationale for this, and I use a value other than > >> AUTO personally for a script I have that tests to see if the wired > >> interface is up and starts the wireless if not. I've also seen other > >> users ask about this from time to time, so I'm sure I'm not alone. > > > > Please provide this script to support your argument. > > I set the value of network_interfaces to "lo0 test" and then I have a > /etc/start_if.test script that checks to see if my wired interface is > up, initializes it if it is, and if not it checks to see which > wireless card I'm using and initializes that. I've actually spent > quite a lot of time trying to figure out how to accomplish something > similar with the current system but AFAICS we don't have a way to do > that without hooking it in at the point where the network interfaces > are actually configured. Wouldn't /etc/start_if. do the same thing without having to set network_interfaces? > At some point in the future when I get a whole bunch of free time I'd > like to extend what's in the base in order to do what I'm doing now > with my little script ... I'd agree we could use some better hooks for this sort of thing. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090602/0141faab/attachment.pgp From brooks at freebsd.org Tue Jun 2 15:53:55 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 2 15:54:02 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A24B99B.9050703@infracaninophile.co.uk> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <4A24B99B.9050703@infracaninophile.co.uk> Message-ID: <20090602155403.GF14685@lor.one-eyed-alien.net> On Tue, Jun 02, 2009 at 06:33:15AM +0100, Matthew Seaman wrote: > Brooks Davis wrote: > >> I've never seen a valid use case, just failures to understand the >> current system. > > My laptop has iwi0 and bge0 interfaces. At work, both of these obtain > addresses and default routes by DHCP, but from two completely different DHCP > servers. When I'm plugged into the wired network I want the bge0 interface to > be the default route, but iwi0 comes first in the list of interfaces produced > by ifconfig, so it gets configured first and sets the route. Of course, when > I'm not plugged into the wired network I want iwi0 to have the default route, > so I can't just use dhclient.conf to disregard routing information on that > interface. > > All in all, setting network_interfaces="bge0 iwi0 lo0" does exactly what I > want with minimal effort. This is an interesting use case. This is certainly the easiest way to do this in 7. FYI, it won't work by default in 8.0 because we only run dhclient from devd so there is no ordering unless you set synchronous_dhclient="YES". What I've been thinking here is that we should have a way to tell dhclient which interface(s) to prefer for a default route. I've been meaning to fix that for a while, but since I've been using a cardbus wireless device, I've not needed to scratch that itch. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090602/6b2681ba/attachment.pgp From sam at freebsd.org Tue Jun 2 16:47:11 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Jun 2 16:47:17 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090602155403.GF14685@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <4A24B99B.9050703@infracaninophile.co.uk> <20090602155403.GF14685@lor.one-eyed-alien.net> Message-ID: <4A254EFB.2020001@freebsd.org> Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:33:15AM +0100, Matthew Seaman wrote: > >> Brooks Davis wrote: >> >> >>> I've never seen a valid use case, just failures to understand the >>> current system. >>> >> My laptop has iwi0 and bge0 interfaces. At work, both of these obtain >> addresses and default routes by DHCP, but from two completely different DHCP >> servers. When I'm plugged into the wired network I want the bge0 interface to >> be the default route, but iwi0 comes first in the list of interfaces produced >> by ifconfig, so it gets configured first and sets the route. Of course, when >> I'm not plugged into the wired network I want iwi0 to have the default route, >> so I can't just use dhclient.conf to disregard routing information on that >> interface. >> >> All in all, setting network_interfaces="bge0 iwi0 lo0" does exactly what I >> want with minimal effort. >> > > This is an interesting use case. This is certainly the easiest way > to do this in 7. FYI, it won't work by default in 8.0 because we > only run dhclient from devd so there is no ordering unless you set > synchronous_dhclient="YES". What I've been thinking here is that we > should have a way to tell dhclient which interface(s) to prefer for a > default route. I've been meaning to fix that for a while, but since > I've been using a cardbus wireless device, I've not needed to scratch > that itch. > Some people prefer to use lagg's failover handling to handle the wired-wireless switchover. Sam From m.seaman at infracaninophile.co.uk Tue Jun 2 17:26:51 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Jun 2 17:26:57 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A254EFB.2020001@freebsd.org> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <4A24B99B.9050703@infracaninophile.co.uk> <20090602155403.GF14685@lor.one-eyed-alien.net> <4A254EFB.2020001@freebsd.org> Message-ID: <4A2560CB.4030307@infracaninophile.co.uk> Sam Leffler wrote: > Brooks Davis wrote: >> On Tue, Jun 02, 2009 at 06:33:15AM +0100, Matthew Seaman wrote: >> >>> Brooks Davis wrote: >>> >>> >>>> I've never seen a valid use case, just failures to understand the >>>> current system. >>>> >>> My laptop has iwi0 and bge0 interfaces. At work, both of these obtain >>> addresses and default routes by DHCP, but from two completely >>> different DHCP >>> servers. When I'm plugged into the wired network I want the bge0 >>> interface to >>> be the default route, but iwi0 comes first in the list of interfaces >>> produced >>> by ifconfig, so it gets configured first and sets the route. Of >>> course, when >>> I'm not plugged into the wired network I want iwi0 to have the >>> default route, >>> so I can't just use dhclient.conf to disregard routing information on >>> that >>> interface. >>> >>> All in all, setting network_interfaces="bge0 iwi0 lo0" does exactly >>> what I >>> want with minimal effort. >>> >> >> This is an interesting use case. This is certainly the easiest way >> to do this in 7. FYI, it won't work by default in 8.0 because we >> only run dhclient from devd so there is no ordering unless you set >> synchronous_dhclient="YES". What I've been thinking here is that we >> should have a way to tell dhclient which interface(s) to prefer for a >> default route. I've been meaning to fix that for a while, but since >> I've been using a cardbus wireless device, I've not needed to scratch >> that itch. >> > Some people prefer to use lagg's failover handling to handle the > wired-wireless switchover. How does that work if the two interfaces are in entirely different networks? Can you trigger an arbitrary action (such as modifying the routing table) when a lagg interface fails over? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090602/8a2caf0b/signature.pgp From sam at freebsd.org Tue Jun 2 17:40:02 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Jun 2 17:40:07 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A2560CB.4030307@infracaninophile.co.uk> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <4A24B99B.9050703@infracaninophile.co.uk> <20090602155403.GF14685@lor.one-eyed-alien.net> <4A254EFB.2020001@freebsd.org> <4A2560CB.4030307@infracaninophile.co.uk> Message-ID: <4A2563EF.4050502@freebsd.org> Matthew Seaman wrote: > Sam Leffler wrote: >> Brooks Davis wrote: >>> On Tue, Jun 02, 2009 at 06:33:15AM +0100, Matthew Seaman wrote: >>> >>>> Brooks Davis wrote: >>>> >>>> >>>>> I've never seen a valid use case, just failures to understand the >>>>> current system. >>>>> >>>> My laptop has iwi0 and bge0 interfaces. At work, both of these obtain >>>> addresses and default routes by DHCP, but from two completely >>>> different DHCP >>>> servers. When I'm plugged into the wired network I want the bge0 >>>> interface to >>>> be the default route, but iwi0 comes first in the list of >>>> interfaces produced >>>> by ifconfig, so it gets configured first and sets the route. Of >>>> course, when >>>> I'm not plugged into the wired network I want iwi0 to have the >>>> default route, >>>> so I can't just use dhclient.conf to disregard routing information >>>> on that >>>> interface. >>>> >>>> All in all, setting network_interfaces="bge0 iwi0 lo0" does exactly >>>> what I >>>> want with minimal effort. >>>> >>> >>> This is an interesting use case. This is certainly the easiest way >>> to do this in 7. FYI, it won't work by default in 8.0 because we >>> only run dhclient from devd so there is no ordering unless you set >>> synchronous_dhclient="YES". What I've been thinking here is that we >>> should have a way to tell dhclient which interface(s) to prefer for a >>> default route. I've been meaning to fix that for a while, but since >>> I've been using a cardbus wireless device, I've not needed to scratch >>> that itch. >>> >> Some people prefer to use lagg's failover handling to handle the >> wired-wireless switchover. > > How does that work if the two interfaces are in entirely different > networks? > Can you trigger an arbitrary action (such as modifying the routing table) > when a lagg interface fails over? Sorry, didn't read your note well enough. I don't think lagg is applicable to your setup. Sam From yvesguerin at yahoo.ca Wed Jun 3 14:21:17 2009 From: yvesguerin at yahoo.ca (=?iso-8859-1?Q?Yves_Gu=E9rin?=) Date: Wed Jun 3 14:21:27 2009 Subject: Profile rc idea Message-ID: <350474.92140.qm@web56408.mail.re3.yahoo.com> Dear Sir, I forgot to tell you that if you put a menu during the boot process, after the forth menu and if the user loads the splashscreen, your menu will never be visible to the end-user, because the splashscreen will be over the menu (on top), you have to unload the screensaver kermel module.? I experienced it, so after 10 minutes I were wondering what happen to my laptop and after hitting the "esc" key I were able to see my menu (console).? It happens on my old laptop with freebsd 6.1 so your mileage may vary. Regards, Yves Guerin --- En date de : Lun 1.6.09, Doug Barton a ?crit : De: Doug Barton Objet: Re: Profile rc idea ?: yvesguerin@yahoo.ca Cc: freebsd-rc@freebsd.org Date: Lundi 1 Juin 2009, 21h36 Yves Gu?rin wrote: > Dear Sir, > > I made a README file but I am not very expert with patch (sorry) so to > be able to send my stuff as soon as possible I just did a tarball. > > If you need help or you have a question just drop me an email. Thanks!? Don't worry about the coding style issues, that'll all get worked out as we develop the idea. Doug From dougb at FreeBSD.org Wed Jun 3 16:08:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jun 3 16:09:03 2009 Subject: Profile rc idea In-Reply-To: <350474.92140.qm@web56408.mail.re3.yahoo.com> References: <350474.92140.qm@web56408.mail.re3.yahoo.com> Message-ID: <4A269FC3.6070705@FreeBSD.org> Thanks for the info. :) Doug Yves Gu?rin wrote: > Dear Sir, > > I forgot to tell you that if you put a menu during the boot process, > after the forth menu and if the user loads the splashscreen, your menu > will never be visible to the end-user, because the splashscreen will be > over the menu (on top), you have to unload the screensaver kermel > module. I experienced it, so after 10 minutes I were wondering what > happen to my laptop and after hitting the "esc" key I were able to see > my menu (console). It happens on my old laptop with freebsd 6.1 so your > mileage may vary. > > Regards, > > Yves Guerin > > > --- En date de : *Lun 1.6.09, Doug Barton //* a ?crit : > > > De: Doug Barton > Objet: Re: Profile rc idea > ?: yvesguerin@yahoo.ca > Cc: freebsd-rc@freebsd.org > Date: Lundi 1 Juin 2009, 21h36 > > Yves Gu?rin wrote: > > Dear Sir, > > > > I made a README file but I am not very expert with patch (sorry) so to > > be able to send my stuff as soon as possible I just did a tarball. > > > > If you need help or you have a question just drop me an email. > > Thanks! Don't worry about the coding style issues, that'll all get > worked out as we develop the idea. > > Doug > > -- This .signature sanitized for your protection From jilles at stack.nl Sat Jun 6 08:40:03 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Jun 6 08:40:09 2009 Subject: conf/134333: PPP configuration problem in the rc.d scripts in combination with bash shell Message-ID: <200906060840.n568e2Jc044752@freefall.freebsd.org> The following reply was made to PR conf/134333; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, dreibh@iem.uni-due.de Cc: Subject: Re: conf/134333: PPP configuration problem in the rc.d scripts in combination with bash shell Date: Sat, 6 Jun 2009 10:30:36 +0200 The cause is probably that /etc/rc.d/ppp is using su -m, which uses the invoking user's shell from /etc/passwd. There doesn't seem a good alternative for su -m though, other than requiring the target user have /bin/sh as shell and using plain su or su -. A new option to su to execute a command using /bin/sh could be useful. -- Jilles Tjoelker From bugmaster at FreeBSD.org Mon Jun 8 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:09:28 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200906081107.n58B70fU020781@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/134918 rc 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/120228 rc [zfs] [patch] Split ZFS volume startup / ease ZFS swap o conf/120194 rc [patch] UFS volumes on ZVOLs cannot be fsck'd at boot 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 57 problems total. From bugmaster at FreeBSD.org Mon Jun 15 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:09:24 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200906151107.n5FB717N077056@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/134918 rc 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/120228 rc [zfs] [patch] Split ZFS volume startup / ease ZFS swap o conf/120194 rc [patch] UFS volumes on ZVOLs cannot be fsck'd at boot 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 57 problems total. From bugmaster at FreeBSD.org Mon Jun 22 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:09:18 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200906221107.n5MB72wg018165@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/134918 rc 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/120228 rc [zfs] [patch] Split ZFS volume startup / ease ZFS swap o conf/120194 rc [patch] UFS volumes on ZVOLs cannot be fsck'd at boot 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 57 problems total. From brooks at freebsd.org Thu Jun 25 23:17:33 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jun 25 23:17:47 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090601212506.GA2351@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> Message-ID: <20090625225027.GB45036@lor.one-eyed-alien.net> So based on the feedback I saw, there were two use cases where there wasn't another easy way to do what setting network_interface's. Yours (though I think my suggestion may well work) and Matthew Seaman's which won't actually work in 8.0 without other config changes. In both cases, those uses reflect a failure to support valid use cases which is a good reason to leave the ability to set network_interfaces in place. That being said I'd still like to see the warning restored because: - It doesn't prevent using these workarounds. - It reduces support issues due to misuse. - Most reported uses were in fact wrong. - Removing network_interfaces will help us move toward a state of more dynamic configuration to better match system realities. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090625/6bc86a50/attachment.pgp From dougb at FreeBSD.org Thu Jun 25 23:48:41 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jun 25 23:48:52 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090625225027.GB45036@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> Message-ID: <4A440CD1.4080904@FreeBSD.org> Brooks Davis wrote: > So based on the feedback I saw, there were two use cases where there > wasn't another easy way to do what setting network_interface's. Yours > (though I think my suggestion may well work) My current script is actually a little more complicated than what I described, since I have 2 different wifi cards, one of which is a pcmcia card that I use in situations where the built-in card can't pick up the signal. So my current script tests to see if the wire is up, and if so it exits. Then it tests to see if the pcmcia card is inserted, and if so it configures that, and if not it configures the built-in card. What you proposed would work in the situation where I only had one wifi card, but I haven't yet thought through how to refactor the script in order to allow rc configuration of a non-existent piece of hardware to fail gracefully. That said, your idea is a good one, and actually gives me some things to think about in terms of how to incorporate my concept into the existing rc system in a "better" way than how I'm doing it now (which admittedly is kind of a kludge, albeit a functional one). > and Matthew Seaman's which > won't actually work in 8.0 without other config changes. In both cases, > those uses reflect a failure to support valid use cases which is a good > reason to leave the ability to set network_interfaces in place. I'm glad that we agree on that bit at least, and if I haven't already made it clear if we ever get to a point where network_interfaces is not needed, I'm happy to see it go. I would however add to your list the following problems that were noted in the discussion: 1. The ipv6_network_interfaces/IPv6 autoconfig consolidation problem 2. Auto-loading of kernel modules related to the list of interfaces to configure 3. The renaming cloned interfaces problem > That being said I'd still like to see the warning restored because: > - It doesn't prevent using these workarounds. > - It reduces support issues due to misuse. > - Most reported uses were in fact wrong. > - Removing network_interfaces will help us move toward a state of more > dynamic configuration to better match system realities. My feeling remains that if it's a valid option it should not produce a warning (which becomes very very annoying over time). I would also argue that having the warning didn't buy us anything because all of the people who were defining network_interfaces kept doing it in spite of the warning (whether they actually needed to or not). I do agree with you however that there is an issue of anti-foot-shooting, and having given some thought to what you said in regards to the support issues I do have a vague recollection of the issue you described where people would leave out lo0 and then have big problems. To that end I offer the attached (admittedly untested atm because I'm in the middle of something else) patch which I believe would solve that problem. I would like to suggest a compromise to leave the warning out of 8.x until such time as that feature truly is not needed, then do a proper deprecation of it when that time comes. And remove the functionality in 9.x. The compromise being that I will agree not to MFC the removal of the warning to RELENG_[67] so that whatever benefit the warning has in terms of discouraging users will remain in place. Sound good? Doug -- This .signature sanitized for your protection -------------- next part -------------- Index: network.subr =================================================================== --- network.subr (revision 195005) +++ network.subr (working copy) @@ -727,6 +727,13 @@ ;; *) _tmplist="${network_interfaces} ${cloned_interfaces}" + + # Help prevent foot-shooting + # + case "$_tmplist" in + lo0*|*lo0|*' lo0 '*) ;; # This is fine, do nothing + *) _tmplist="lo0 ${_tmplist}" ;; + esac ;; esac From brooks at FreeBSD.org Fri Jun 26 02:36:30 2009 From: brooks at FreeBSD.org (Brooks Davis) Date: Fri Jun 26 02:36:36 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A440CD1.4080904@FreeBSD.org> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> <4A440CD1.4080904@FreeBSD.org> Message-ID: <20090626023526.GA45597@lor.one-eyed-alien.net> On Thu, Jun 25, 2009 at 04:48:33PM -0700, Doug Barton wrote: > Brooks Davis wrote: > > So based on the feedback I saw, there were two use cases where there > > wasn't another easy way to do what setting network_interface's. Yours > > (though I think my suggestion may well work) > > My current script is actually a little more complicated than what I > described, since I have 2 different wifi cards, one of which is a > pcmcia card that I use in situations where the built-in card can't > pick up the signal. So my current script tests to see if the wire is > up, and if so it exits. Then it tests to see if the pcmcia card is > inserted, and if so it configures that, and if not it configures the > built-in card. > > What you proposed would work in the situation where I only had one > wifi card, but I haven't yet thought through how to refactor the > script in order to allow rc configuration of a non-existent piece of > hardware to fail gracefully. > > That said, your idea is a good one, and actually gives me some things > to think about in terms of how to incorporate my concept into the > existing rc system in a "better" way than how I'm doing it now (which > admittedly is kind of a kludge, albeit a functional one). > > > and Matthew Seaman's which > > won't actually work in 8.0 without other config changes. In both cases, > > those uses reflect a failure to support valid use cases which is a good > > reason to leave the ability to set network_interfaces in place. > > I'm glad that we agree on that bit at least, and if I haven't already > made it clear if we ever get to a point where network_interfaces is > not needed, I'm happy to see it go. > > I would however add to your list the following problems that were > noted in the discussion: > > 1. The ipv6_network_interfaces/IPv6 autoconfig consolidation problem I don't believe the warning has an effect one way or another on this issue. For that matter, a quick grep indicates that setting network_interfaces should have no impact on IPv6 configuration. > 2. Auto-loading of kernel modules related to the list of interfaces to > configure I continue to believe this "feature" is a mistake. > 3. The renaming cloned interfaces problem I know for certain that this isn't a general problem because as I said in response to that post, it works just find for me. > > That being said I'd still like to see the warning restored because: > > - It doesn't prevent using these workarounds. > > - It reduces support issues due to misuse. > > - Most reported uses were in fact wrong. > > - Removing network_interfaces will help us move toward a state of more > > dynamic configuration to better match system realities. > > My feeling remains that if it's a valid option it should not produce a > warning (which becomes very very annoying over time). I would also > argue that having the warning didn't buy us anything because all of > the people who were defining network_interfaces kept doing it in spite > of the warning (whether they actually needed to or not). > > I do agree with you however that there is an issue of > anti-foot-shooting, and having given some thought to what you said in > regards to the support issues I do have a vague recollection of the > issue you described where people would leave out lo0 and then have big > problems. To that end I offer the attached (admittedly untested atm > because I'm in the middle of something else) patch which I believe > would solve that problem. > > I would like to suggest a compromise to leave the warning out of 8.x > until such time as that feature truly is not needed, then do a proper > deprecation of it when that time comes. And remove the functionality > in 9.x. The compromise being that I will agree not to MFC the removal > of the warning to RELENG_[67] so that whatever benefit the warning has > in terms of discouraging users will remain in place. > > Sound good? I truly don't see the point in your proposed compromise. It fails to educate users either of a coming change or of their failure to understand the variable they are setting (usually wrongly.) The few people with legitimate uses case easily ignore the error or can simply delete it from their local copies of the script since they are presumably using mergemaster or freebsd-update, both of which will let them preserve the change. -- Brooks > Doug > > -- > > This .signature sanitized for your protection > > Index: network.subr > =================================================================== > --- network.subr (revision 195005) > +++ network.subr (working copy) > @@ -727,6 +727,13 @@ > ;; > *) > _tmplist="${network_interfaces} ${cloned_interfaces}" > + > + # Help prevent foot-shooting > + # > + case "$_tmplist" in > + lo0*|*lo0|*' lo0 '*) ;; # This is fine, do nothing > + *) _tmplist="lo0 ${_tmplist}" ;; > + esac > ;; > esac > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090626/202f1f40/attachment.pgp From imp at bsdimp.com Fri Jun 26 02:46:22 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jun 26 02:46:27 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090626023526.GA45597@lor.one-eyed-alien.net> References: <20090625225027.GB45036@lor.one-eyed-alien.net> <4A440CD1.4080904@FreeBSD.org> <20090626023526.GA45597@lor.one-eyed-alien.net> Message-ID: <20090625.204446.1736499898.imp@bsdimp.com> In message: <20090626023526.GA45597@lor.one-eyed-alien.net> Brooks Davis writes: : > 2. Auto-loading of kernel modules related to the list of interfaces to : > configure : : I continue to believe this "feature" is a mistake. We've been slowly breaking this feature over the years. It used to be that all I needed to do was "dhclient rl0" to load if_rl.ko and run dhclient on it and only if I didn't have a rl in my box would it complain. For a while, other kinds of interfaces were busted due to some dubious simplifications that were made in ifconfig. It was added, btw, to have parity with mount, since you could say "mount -t msdos " and have it work, even if you forgot to kldload msdos.ko... It is more DWIMy than most Unix things, but there's so many things that Unix has done since the halcyon days of its youth that it is hard to hold this little bit of dwimness against ifconfig :) Warner From dougb at FreeBSD.org Fri Jun 26 03:13:40 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 26 03:13:49 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <20090626023526.GA45597@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> <4A440CD1.4080904@FreeBSD.org> <20090626023526.GA45597@lor.one-eyed-alien.net> Message-ID: <4A443CE0.7050000@FreeBSD.org> Brooks Davis wrote: > On Thu, Jun 25, 2009 at 04:48:33PM -0700, Doug Barton wrote: >> Brooks Davis wrote: >>> So based on the feedback I saw, there were two use cases where there >>> wasn't another easy way to do what setting network_interface's. Yours >>> (though I think my suggestion may well work) >> My current script is actually a little more complicated than what I >> described, since I have 2 different wifi cards, one of which is a >> pcmcia card that I use in situations where the built-in card can't >> pick up the signal. So my current script tests to see if the wire is >> up, and if so it exits. Then it tests to see if the pcmcia card is >> inserted, and if so it configures that, and if not it configures the >> built-in card. >> >> What you proposed would work in the situation where I only had one >> wifi card, but I haven't yet thought through how to refactor the >> script in order to allow rc configuration of a non-existent piece of >> hardware to fail gracefully. >> >> That said, your idea is a good one, and actually gives me some things >> to think about in terms of how to incorporate my concept into the >> existing rc system in a "better" way than how I'm doing it now (which >> admittedly is kind of a kludge, albeit a functional one). >> >>> and Matthew Seaman's which >>> won't actually work in 8.0 without other config changes. In both cases, >>> those uses reflect a failure to support valid use cases which is a good >>> reason to leave the ability to set network_interfaces in place. >> I'm glad that we agree on that bit at least, and if I haven't already >> made it clear if we ever get to a point where network_interfaces is >> not needed, I'm happy to see it go. >> >> I would however add to your list the following problems that were >> noted in the discussion: >> >> 1. The ipv6_network_interfaces/IPv6 autoconfig consolidation problem > > I don't believe the warning has an effect one way or another on this > issue. For that matter, a quick grep indicates that setting > network_interfaces should have no impact on IPv6 configuration. If we're going to move forward on feature parity for IPv4 and IPv6 then we need to take that issue seriously. >> 2. Auto-loading of kernel modules related to the list of interfaces to >> configure > > I continue to believe this "feature" is a mistake. I find it quite handy personally. Unless I'm missing something the alternative would be to require people to kldload a module before doing 'ifconfig up' which seems kind of silly, and I think would be a regression our users would object to. >> 3. The renaming cloned interfaces problem > > I know for certain that this isn't a general problem because as I said > in response to that post, it works just find for me. It was general enough for one user to complain about it, and state that the only alternative for him was to use the network_interfaces option. If the bug can be confirmed and subsequently fixed, fine. >>> That being said I'd still like to see the warning restored because: >>> - It doesn't prevent using these workarounds. >>> - It reduces support issues due to misuse. >>> - Most reported uses were in fact wrong. >>> - Removing network_interfaces will help us move toward a state of more >>> dynamic configuration to better match system realities. >> My feeling remains that if it's a valid option it should not produce a >> warning (which becomes very very annoying over time). I would also >> argue that having the warning didn't buy us anything because all of >> the people who were defining network_interfaces kept doing it in spite >> of the warning (whether they actually needed to or not). >> >> I do agree with you however that there is an issue of >> anti-foot-shooting, and having given some thought to what you said in >> regards to the support issues I do have a vague recollection of the >> issue you described where people would leave out lo0 and then have big >> problems. To that end I offer the attached (admittedly untested atm >> because I'm in the middle of something else) patch which I believe >> would solve that problem. >> >> I would like to suggest a compromise to leave the warning out of 8.x >> until such time as that feature truly is not needed, then do a proper >> deprecation of it when that time comes. And remove the functionality >> in 9.x. The compromise being that I will agree not to MFC the removal >> of the warning to RELENG_[67] so that whatever benefit the warning has >> in terms of discouraging users will remain in place. >> >> Sound good? > > I truly don't see the point in your proposed compromise. I don't see any point in a warning message for the deprecation of an option that is still needed by our users until such time as it is no longer actually needed. I obviously don't share your enthusiasm for removing it, and I haven't seen anyone else chime in with a good reason to remove it either. The one concern you've raised about this option which does seem legitimate is the issue of users forgetting to include lo0 in their list, which I've addressed. Doug From brooks at FreeBSD.org Fri Jun 26 14:53:04 2009 From: brooks at FreeBSD.org (Brooks Davis) Date: Fri Jun 26 14:53:11 2009 Subject: Removal of deprecation for network_interfaces != AUTO In-Reply-To: <4A443CE0.7050000@FreeBSD.org> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> <4A440CD1.4080904@FreeBSD.org> <20090626023526.GA45597@lor.one-eyed-alien.net> <4A443CE0.7050000@FreeBSD.org> Message-ID: <20090626145159.GC52107@lor.one-eyed-alien.net> I give. I think this change was wrong both technically and procedurally, but it's wasted enough of my time and energy that that I don't want to pursue it further. -- Brooks On Thu, Jun 25, 2009 at 08:13:36PM -0700, Doug Barton wrote: > Brooks Davis wrote: > > On Thu, Jun 25, 2009 at 04:48:33PM -0700, Doug Barton wrote: > >> Brooks Davis wrote: > >>> So based on the feedback I saw, there were two use cases where there > >>> wasn't another easy way to do what setting network_interface's. Yours > >>> (though I think my suggestion may well work) > >> My current script is actually a little more complicated than what I > >> described, since I have 2 different wifi cards, one of which is a > >> pcmcia card that I use in situations where the built-in card can't > >> pick up the signal. So my current script tests to see if the wire is > >> up, and if so it exits. Then it tests to see if the pcmcia card is > >> inserted, and if so it configures that, and if not it configures the > >> built-in card. > >> > >> What you proposed would work in the situation where I only had one > >> wifi card, but I haven't yet thought through how to refactor the > >> script in order to allow rc configuration of a non-existent piece of > >> hardware to fail gracefully. > >> > >> That said, your idea is a good one, and actually gives me some things > >> to think about in terms of how to incorporate my concept into the > >> existing rc system in a "better" way than how I'm doing it now (which > >> admittedly is kind of a kludge, albeit a functional one). > >> > >>> and Matthew Seaman's which > >>> won't actually work in 8.0 without other config changes. In both cases, > >>> those uses reflect a failure to support valid use cases which is a good > >>> reason to leave the ability to set network_interfaces in place. > >> I'm glad that we agree on that bit at least, and if I haven't already > >> made it clear if we ever get to a point where network_interfaces is > >> not needed, I'm happy to see it go. > >> > >> I would however add to your list the following problems that were > >> noted in the discussion: > >> > >> 1. The ipv6_network_interfaces/IPv6 autoconfig consolidation problem > > > > I don't believe the warning has an effect one way or another on this > > issue. For that matter, a quick grep indicates that setting > > network_interfaces should have no impact on IPv6 configuration. > > If we're going to move forward on feature parity for IPv4 and IPv6 > then we need to take that issue seriously. > > >> 2. Auto-loading of kernel modules related to the list of interfaces to > >> configure > > > > I continue to believe this "feature" is a mistake. > > I find it quite handy personally. Unless I'm missing something the > alternative would be to require people to kldload a module before > doing 'ifconfig up' which seems kind of silly, and I think would be a > regression our users would object to. > > >> 3. The renaming cloned interfaces problem > > > > I know for certain that this isn't a general problem because as I said > > in response to that post, it works just find for me. > > It was general enough for one user to complain about it, and state > that the only alternative for him was to use the network_interfaces > option. If the bug can be confirmed and subsequently fixed, fine. > > >>> That being said I'd still like to see the warning restored because: > >>> - It doesn't prevent using these workarounds. > >>> - It reduces support issues due to misuse. > >>> - Most reported uses were in fact wrong. > >>> - Removing network_interfaces will help us move toward a state of more > >>> dynamic configuration to better match system realities. > >> My feeling remains that if it's a valid option it should not produce a > >> warning (which becomes very very annoying over time). I would also > >> argue that having the warning didn't buy us anything because all of > >> the people who were defining network_interfaces kept doing it in spite > >> of the warning (whether they actually needed to or not). > >> > >> I do agree with you however that there is an issue of > >> anti-foot-shooting, and having given some thought to what you said in > >> regards to the support issues I do have a vague recollection of the > >> issue you described where people would leave out lo0 and then have big > >> problems. To that end I offer the attached (admittedly untested atm > >> because I'm in the middle of something else) patch which I believe > >> would solve that problem. > >> > >> I would like to suggest a compromise to leave the warning out of 8.x > >> until such time as that feature truly is not needed, then do a proper > >> deprecation of it when that time comes. And remove the functionality > >> in 9.x. The compromise being that I will agree not to MFC the removal > >> of the warning to RELENG_[67] so that whatever benefit the warning has > >> in terms of discouraging users will remain in place. > >> > >> Sound good? > > > > I truly don't see the point in your proposed compromise. > > I don't see any point in a warning message for the deprecation of an > option that is still needed by our users until such time as it is no > longer actually needed. I obviously don't share your enthusiasm for > removing it, and I haven't seen anyone else chime in with a good > reason to remove it either. > > The one concern you've raised about this option which does seem > legitimate is the issue of users forgetting to include lo0 in their > list, which I've addressed. > > Doug > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090626/cca5ee66/attachment.pgp From hrs at FreeBSD.org Sun Jun 28 10:44:09 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sun Jun 28 10:44:17 2009 Subject: RFC: integrate network_ipv6 to netif and tidy up several rc.d scripts Message-ID: <20090628.194342.254155418.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/20090628/27b16637/attachment.pgp From bugmaster at FreeBSD.org Mon Jun 29 11:07:07 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:09:19 2009 Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org Message-ID: <200906291107.n5TB76Td046472@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/134918 rc 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/120228 rc [zfs] [patch] Split ZFS volume startup / ease ZFS swap o conf/120194 rc [patch] UFS volumes on ZVOLs cannot be fsck'd at boot 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 57 problems total.