From owner-freebsd-rc@FreeBSD.ORG Mon Jun 22 11:07:03 2009 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D97A1065670 for ; Mon, 22 Jun 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2A02B8FC19 for ; Mon, 22 Jun 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5MB73Pq018169 for ; Mon, 22 Jun 2009 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5MB72wg018165 for freebsd-rc@FreeBSD.org; Mon, 22 Jun 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Jun 2009 11:07:02 GMT Message-Id: <200906221107.n5MB72wg018165@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:07:03 -0000 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 owner-freebsd-rc@FreeBSD.ORG Thu Jun 25 23:17:33 2009 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94CAE106566C for ; Thu, 25 Jun 2009 23:17:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF9D8FC14 for ; Thu, 25 Jun 2009 23:17:33 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5PMoRDY045424; Thu, 25 Jun 2009 17:50:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5PMoRQ7045423; Thu, 25 Jun 2009 17:50:27 -0500 (CDT) (envelope-from brooks) Date: Thu, 25 Jun 2009 17:50:27 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20090625225027.GB45036@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <20090601212506.GA2351@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 25 Jun 2009 17:50:27 -0500 (CDT) Cc: freebsd-rc@freebsd.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:17:33 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKQ/8yXY6L6fI4GtQRAtDQAJ49tJPBLbxxTd5XLotDntMutKPJLACg5cju 3jKJ7pBpks/idt22hvIwrJ8= =cdY+ -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-rc@FreeBSD.ORG Thu Jun 25 23:48:40 2009 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF1210656DE for ; Thu, 25 Jun 2009 23:48:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAE38FC14 for ; Thu, 25 Jun 2009 23:48:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 13467 invoked by uid 399); 25 Jun 2009 23:48:39 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Jun 2009 23:48:39 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A440CD1.4080904@FreeBSD.org> Date: Thu, 25 Jun 2009 16:48:33 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Brooks Davis References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> In-Reply-To: <20090625225027.GB45036@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: multipart/mixed; boundary="------------010005000803060702020404" Cc: freebsd-rc@freebsd.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 23:48:41 -0000 This is a multi-part message in MIME format. --------------010005000803060702020404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------010005000803060702020404 Content-Type: text/plain; name="lo0-helper.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lo0-helper.diff" 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 --------------010005000803060702020404-- From owner-freebsd-rc@FreeBSD.ORG Fri Jun 26 02:36:29 2009 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07D61065670; Fri, 26 Jun 2009 02:36:29 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA9C8FC16; Fri, 26 Jun 2009 02:36:29 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5Q2ZQFA046903; Thu, 25 Jun 2009 21:35:26 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5Q2ZQV7046902; Thu, 25 Jun 2009 21:35:26 -0500 (CDT) (envelope-from brooks) Date: Thu, 25 Jun 2009 21:35:26 -0500 From: Brooks Davis To: Doug Barton Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <4A440CD1.4080904@FreeBSD.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 25 Jun 2009 21:35:26 -0500 (CDT) Cc: Brooks Davis , freebsd-rc@FreeBSD.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:36:30 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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) >=20 > 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. >=20 > 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. >=20 > 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). >=20 > > 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. >=20 > 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. >=20 > I would however add to your list the following problems that were > noted in the discussion: >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 > 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 >=20 > --=20 >=20 > This .signature sanitized for your protection >=20 > Index: network.subr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- network.subr (revision 195005) > +++ network.subr (working copy) > @@ -727,6 +727,13 @@ > ;; > *) > _tmplist=3D"${network_interfaces} ${cloned_interfaces}" > + > + # Help prevent foot-shooting > + # > + case "$_tmplist" in > + lo0*|*lo0|*' lo0 '*) ;; # This is fine, do nothing > + *) _tmplist=3D"lo0 ${_tmplist}" ;; > + esac > ;; > esac > =20 --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKRDPtXY6L6fI4GtQRAizUAKC5oMpLBErC7fG95Az+JBWIv7BFdgCgsKrk PaPwIfs+XR75LGYg6ymPKzo= =PY1y -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-rc@FreeBSD.ORG Fri Jun 26 02:46:21 2009 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FFF1065673; Fri, 26 Jun 2009 02:46:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 28B8D8FC12; Fri, 26 Jun 2009 02:46:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n5Q2iCwR048082; Thu, 25 Jun 2009 20:44:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 25 Jun 2009 20:44:46 -0600 (MDT) Message-Id: <20090625.204446.1736499898.imp@bsdimp.com> To: brooks@freebsd.org From: "M. Warner Losh" 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> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dougb@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:46:22 -0000 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 owner-freebsd-rc@FreeBSD.ORG Fri Jun 26 03:13:39 2009 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2591065670 for ; Fri, 26 Jun 2009 03:13:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFF38FC15 for ; Fri, 26 Jun 2009 03:13:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 23280 invoked by uid 399); 26 Jun 2009 03:13:37 -0000 Received: from localhost (HELO ?192.168.0.102?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Jun 2009 03:13:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A443CE0.7050000@FreeBSD.org> Date: Thu, 25 Jun 2009 20:13:36 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Brooks Davis 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> In-Reply-To: <20090626023526.GA45597@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 03:13:40 -0000 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 owner-freebsd-rc@FreeBSD.ORG Fri Jun 26 14:53:03 2009 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B6B106567B; Fri, 26 Jun 2009 14:53:03 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 106508FC22; Fri, 26 Jun 2009 14:53:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5QEpxno052781; Fri, 26 Jun 2009 09:51:59 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5QEpxO5052780; Fri, 26 Jun 2009 09:51:59 -0500 (CDT) (envelope-from brooks) Date: Fri, 26 Jun 2009 09:51:59 -0500 From: Brooks Davis To: Doug Barton Message-ID: <20090626145159.GC52107@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> <4A443CE0.7050000@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <4A443CE0.7050000@FreeBSD.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 26 Jun 2009 09:51:59 -0500 (CDT) Cc: Brooks Davis , freebsd-rc@FreeBSD.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:53:04 -0000 --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 cas= es, > >>> those uses reflect a failure to support valid use cases which is a go= od > >>> 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 > >=20 > > 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. >=20 > If we're going to move forward on feature parity for IPv4 and IPv6 > then we need to take that issue seriously. >=20 > >> 2. Auto-loading of kernel modules related to the list of interfaces to > >> configure > >=20 > > I continue to believe this "feature" is a mistake. >=20 > 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. >=20 > >> 3. The renaming cloned interfaces problem > >=20 > > 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. >=20 > 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. >=20 > >>> 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 mo= re > >>> 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? > >=20 > > I truly don't see the point in your proposed compromise.=20 >=20 > 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. >=20 > 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. >=20 > Doug >=20 --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKROCOXY6L6fI4GtQRApTnAJ9h/NIdPMQsGDvXRsFKz3SWdwr2owCgw+gn Hy1Tkc2BBOyWemxRvNJGFsI= =iehk -----END PGP SIGNATURE----- --m51xatjYGsM+13rf--