From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RubdX-0008JX-T3 for garchives@archives.gentoo.org; Tue, 07 Feb 2012 03:22:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 39FFBE06C3; Tue, 7 Feb 2012 03:22:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3E09BE065A for ; Tue, 7 Feb 2012 03:21:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8E3BA1B4012 for ; Tue, 7 Feb 2012 03:21:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5.5 tests=[AWL=-0.580, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tP7NS53eLCl for ; Tue, 7 Feb 2012 03:21:44 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 3D44A1B4014 for ; Tue, 7 Feb 2012 03:21:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rubce-0000qI-Oz for gentoo-dev@gentoo.org; Tue, 07 Feb 2012 04:21:36 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Feb 2012 04:21:36 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Feb 2012 04:21:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: only the loopback interface should provide net Date: Tue, 7 Feb 2012 03:21:29 +0000 (UTC) Message-ID: References: <20120206210451.GA1940@linux1> <1328570113.8348.53.camel@rook> <20120207014115.GA2683@linux1> <1328582019.8348.58.camel@rook> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 19ecd49 /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 80961858-bdd5-4b26-9592-8ee0cbe6653d X-Archives-Hash: 3754d60b5305501627f41027c7e80a8a Alexandre Rostovtsev posted on Mon, 06 Feb 2012 21:33:39 -0500 as excerpted: > On Mon, 2012-02-06 at 19:41 -0600, William Hubbs wrote: >> > My counterproposal is to (a) fix init scripts for Category 2 so that >> > instead of "use net" or "need net", they only "use net.lo" or "need >> > net.lo"; and >>=20 >> I think it would be better if I provided another service these scripts >> could use|need, because the loopback goes by at least one name other >> than "lo" that I know of, and that is "lo0", so if I don't provide a >> service, all of these scripts would have to conditionally use or need >> at least lo or lo0 depending on which platform they are running on. >=20 > Maybe a virtual service called "lo", provided by net.lo and net.lo0? >=20 >> For the normal use case, I submit that category one should not care >> about the loopback interface, since we don't make remote connections >> that way. That would mean that loopback would not provide net by >> default. >=20 > Yes, that certainly seems reasonable. Indeed. I've long wondered why the loopback was thrown in there with all= =20 the others. It seems to me that a lo or loopback service for it, instead= =20 of net, would be more natural. Then have the individual net.* interface=20 services and a common net service that by default includes all the net.*=20 services EXCEPT loopback. Then have a configuration option such that individual installations can=20 define what individual interface services compose net and how many of=20 them must be up for net to be defined as up. Finally, make it possible to define additional virtual net services,=20 net1, net2... each of which can be similarly locally configured as=20 composed of several individual interface services, with each one allowed=20 to set how many of its group of components must be up for it to be up. That would allow maximum configuration flexibility, with the ability to=20 depend on one or a group of individual interface services, with each=20 group allowed to require one of its set, all of its set, or something in=20 between. Of course, one could add the loopback interface service to the definition= =20 of one of these groups if desired, but only the first one (net) would be=20 defined by default, and it would by default include all interfaces /but/=20 loopback and would be provided when the first included interface came=20 up. That would allow its definition to remain "fuzzily specified" so=20 things could just depend on it by default if they needed an external=20 network (ntpclient), or on loopback by default if they needed only a=20 local interface to come up, even if they weren't a lot of use without an=20 external network (privoxy, named). Where people want something up only if a specific net-service (or=20 services, or one of several specific net-services) is up, they'll have to= =20 configure it specifically, just as they do now. There's no way around=20 that since there's no simple way to determine that specific net-service=20 in advance, but that would fix the problems for the first two categories=20 at least, since there'd be a distinction between loopback and general net= =20 interface services. FWIW, my current config has net provided by loopback and several services= =20 depending on it, while ntpclient and ntpd depend on net.eth0. If the=20 above defaults were implemented, that would have all "just worked", since= =20 my setup isn't complex enough to have multiple external network interface= =20 services to worry about, and stuff like privoxy could be configured by=20 gentoo to depend on loopback only, while ntpclient depends on net, which=20 if not including loopback would allow it to "just work" as well. I=20 wouldn't have had to manually configure net.eth0, as I did due to lack of= =20 that distinction. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman