[gentoo-dev] rfc: only the loopback interface should provide net

[gentoo-dev] rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 1085 bytes --]

All,

I've been pondering for a while why All of OpenRC's network interfaces
provide net.

My understanding of the "net" service is that it is there to signal that
a generic network connection is active.

What I would like to do in OpenRC is change the network scripts so that
only the loopback interface provides net.

The down side of this approach will be that if a daemon uses a specific
ip address in its configuration, or if it binds to a specific address,
the user will have to set up the appropriate configuration options in
/etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has
this address, I have to put the following line in /etc/conf.d/sshd:

rc_need="net.eth0"

One advantage I see of this approach is it will provide a fix for bugs like
http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to
configure services like this to start after the interface they use
is started.

Attached to this message you will find the patch I want to apply to
OpenRC to make this change.

Any thoughts, comments, or suggestions would be helpful.

William


[-- Attachment #1.2: 0001-Only-the-loopback-interface-should-provide-net.patch --]
[-- Type: text/plain, Size: 683 bytes --]

From cf57aa084dfa3020c9f0ae1f3a07e2fbf2e588dc Mon Sep 17 00:00:00 2001
From: William Hubbs <williamh@gentoo.org>
Date: Mon, 6 Feb 2012 09:24:52 -0600
Subject: [PATCH] Only the loopback interface should provide net

---
 init.d/net.lo.in |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/init.d/net.lo.in b/init.d/net.lo.in
index bf2d848..b3d2b1a 100644
--- a/init.d/net.lo.in
+++ b/init.d/net.lo.in
@@ -20,11 +20,10 @@ depend()
 
 	need localmount
 	after bootmisc
-	provide net
 	keyword -jail -prefix -vserver
 
 	case "${IFACE}" in
-		lo|lo0);;
+		lo|lo0) provide net;;
 		*) after net.lo net.lo0 dbus;;
 	esac
 
-- 
1.7.3.4


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Zac Medico]

On 02/06/2012 01:04 PM, William Hubbs wrote:
> All,
> 
> I've been pondering for a while why All of OpenRC's network interfaces
> provide net.
> 
> My understanding of the "net" service is that it is there to signal that
> a generic network connection is active.
> 
> What I would like to do in OpenRC is change the network scripts so that
> only the loopback interface provides net.
> 
> The down side of this approach will be that if a daemon uses a specific
> ip address in its configuration, or if it binds to a specific address,
> the user will have to set up the appropriate configuration options in
> /etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has
> this address, I have to put the following line in /etc/conf.d/sshd:
> 
> rc_need="net.eth0"

That makes perfect sense. I suspect that the most common case is to have
sshd bind to all interfaces, and if that's true then special
configuration will not be needed in the most common cases.
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Alexandre Rostovtsev]

On Mon, 2012-02-06 at 15:04 -0600, William Hubbs wrote:
> All,
> 
> I've been pondering for a while why All of OpenRC's network interfaces
> provide net.
> 
> My understanding of the "net" service is that it is there to signal that
> a generic network connection is active.
> 
> What I would like to do in OpenRC is change the network scripts so that
> only the loopback interface provides net.
> 
> The down side of this approach will be that if a daemon uses a specific
> ip address in its configuration, or if it binds to a specific address,
> the user will have to set up the appropriate configuration options in
> /etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has
> this address, I have to put the following line in /etc/conf.d/sshd:
> 
> rc_need="net.eth0"
> 
> One advantage I see of this approach is it will provide a fix for bugs like
> http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to
> configure services like this to start after the interface they use
> is started.
> 
> Attached to this message you will find the patch I want to apply to
> OpenRC to make this change.
> 
> Any thoughts, comments, or suggestions would be helpful.
> 
> William

I agree with the existence of the problem, but strongly disagree with
the solution.

There are three very different reasons why an openrc service may
currently "use net" or "need net":

1. Services that connect to remote machines via any available network
interface.
2. Services that listen to connections from remote machines on any
available network interface, and run correctly even if no non-lo
interfaces are up.
3. Services that require a specific network interface, bind to a
specific address, or connect to a specific machine on the local subnet.

Category 1 includes things like ntp-client (in the typical use case).
Category 2 includes things like sshd (in the typical use case).
Category 3 includes things like netmount (in the typical use case), or
your example of sshd that's bound to a specific static IP.

The proposal to provide net only from loopback may help with startup
issues for Category 2, but would break Category 1. (Category 3 is broken
in either case unless the user adds the appropriate rc_need lines
in /etc/conf.d).

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
(b) document (via pkg_postinst messages and comments in the default
conf.d file) the requirement to manually configure rc_need for services
in Category 3; and
(c) continue to provide net in network scripts so that Category 1
continues to work.

PS. Only 4 days ago, I deliberately changed /etc/init.d/NetworkManager
in net-misc/networkmanager-0.9.2.0-r3 so that it provides net to ensure
that Category 1 services work properly. It was rather an unpleasant
surprise to now read a proposal to make the default openrc setup as
broken as old networkmanager versions used to be :/

-Alexandre

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Hi Alexander,

On Mon, Feb 06, 2012 at 06:15:13PM -0500, Alexandre Rostovtsev wrote:
> I agree with the existence of the problem, but strongly disagree with
> the solution.
 
 Actually you have sort of helped me nail down the problem more. The
 issue is that the "net" service is broken. I'll try to point out how.

> 1. Services that connect to remote machines via any available network
> interface.
> 2. Services that listen to connections from remote machines on any
> available network interface, and run correctly even if no non-lo
> interfaces are up.
> 3. Services that require a specific network interface, bind to a
> specific address, or connect to a specific machine on the local subnet.
>
> Category 1 includes things like ntp-client (in the typical use case).
> Category 2 includes things like sshd (in the typical use case).
> Category 3 includes things like netmount (in the typical use case), or
> your example of sshd that's bound to a specific static IP.
> 
> The proposal to provide net only from loopback may help with startup
> issues for Category 2, but would break Category 1. (Category 3 is broken
> in either case unless the user adds the appropriate rc_need lines
> in /etc/conf.d).

Whether or not you break category one depends on how you define a remote
machine. This is where I think the net service is broken.
 
It is possible to have a lo interface active, without having any
other network interfaces active. In the normal use case, your category
one services will start (because they see that net is provided), and
fail, because they can't make their connection over the loopback
interface.

> 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

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.

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.

William



[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Alexandre Rostovtsev]

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
> 
> 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.

Maybe a virtual service called "lo", provided by net.lo and net.lo0?

> 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.

Yes, that certainly seems reasonable.

-Alexandre

[gentoo-dev] Re: rfc: only the loopback interface should provide net

[Duncan]

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
>> 
>> 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.
> 
> Maybe a virtual service called "lo", provided by net.lo and net.lo0?
> 
>> 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.
> 
> Yes, that certainly seems reasonable.

Indeed.  I've long wondered why the loopback was thrown in there with all 
the others.  It seems to me that a lo or loopback service for it, instead 
of net, would be more natural.  Then have the individual net.* interface 
services and a common net service that by default includes all the net.* 
services EXCEPT loopback.

Then have a configuration option such that individual installations can 
define what individual interface services compose net and how many of 
them must be up for net to be defined as up.

Finally, make it possible to define additional virtual net services, 
net1, net2... each of which can be similarly locally configured as 
composed of several individual interface services, with each one allowed 
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 
depend on one or a group of individual interface services, with each 
group allowed to require one of its set, all of its set, or something in 
between.

Of course, one could add the loopback interface service to the definition 
of one of these groups if desired, but only the first one (net) would be 
defined by default, and it would by default include all interfaces /but/ 
loopback and would be provided when the first included interface came 
up.  That would allow its definition to remain "fuzzily specified" so 
things could just depend on it by default if they needed an external 
network (ntpclient), or on loopback by default if they needed only a 
local interface to come up, even if they weren't a lot of use without an 
external network (privoxy, named).

Where people want something up only if a specific net-service (or 
services, or one of several specific net-services) is up, they'll have to 
configure it specifically, just as they do now.  There's no way around 
that since there's no simple way to determine that specific net-service 
in advance, but that would fix the problems for the first two categories 
at least, since there'd be a distinction between loopback and general net 
interface services.

FWIW, my current config has net provided by loopback and several services 
depending on it, while ntpclient and ntpd depend on net.eth0.  If the 
above defaults were implemented, that would have all "just worked", since 
my setup isn't complex enough to have multiple external network interface 
services to worry about, and stuff like privoxy could be configured by 
gentoo to depend on loopback only, while ntpclient depends on net, which 
if not including loopback would allow it to "just work" as well.  I 
wouldn't have had to manually configure net.eth0, as I did due to lack of 
that distinction.

-- 
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

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

Hi again Alexander, another question for you.

On Mon, Feb 06, 2012 at 06:15:13PM -0500, Alexandre Rostovtsev wrote:
> 1. Services that connect to remote machines via any available network
> interface.
> 2. Services that listen to connections from remote machines on any
> available network interface, and run correctly even if no non-lo
> interfaces are up.
> 3. Services that require a specific network interface, bind to a
> specific address, or connect to a specific machine on the local subnet.
> 
> Category 1 includes things like ntp-client (in the typical use case).
> Category 2 includes things like sshd (in the typical use case).
> Category 3 includes things like netmount (in the typical use case), or
> your example of sshd that's bound to a specific static IP.
> 
> The proposal to provide net only from loopback may help with startup
> issues for Category 2, but would break Category 1.

How would this break category 1? I see category 1 as being
operationally similar to category 3. Here is why.

My understanding of networking is that you can't have two interfaces
with ip addresses in the same subnet on the same computer. Correct?

If that is the case, more than likely, the service you want to connect
to will be on one subnet or the other, but not both. So, again,
depending on net is eroneous because your service could start at the
wrong time, or try to connect through the wrong interface.

What do you think?

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Alexandre Rostovtsev]

On Tue, 2012-02-07 at 00:43 -0600, William Hubbs wrote:
> My understanding of networking is that you can't have two interfaces
> with ip addresses in the same subnet on the same computer. Correct?
> 
> If that is the case, more than likely, the service you want to connect
> to will be on one subnet or the other, but not both.

Forget per-interface subnets, that's category 3 material. Category 1 is
about connections that should be available from any suitably configured
interface.

If I want to connect to pool.ntp.org to sync the system clock, or to my
company's vpn gateway for telecommuting, or to tor to encrypt my
traffic, or to a dynamic dns provider to update my machine's record,
I do not care in the least which interface I use. It could be either of
my machine's ethernet ports, could be the wireless adaptor, could be the
built-in wimax card. Could even be something dynamically configured - a
mobile phone tethered over a usb cable, for example. All I care about is
that at least one of my interfaces is providing some sort of working
network connection.

And that's exactly what "provide net" should imply.

-Alexandre.

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/02/12 03:28 AM, Alexandre Rostovtsev wrote:
> 
> If I want to connect to pool.ntp.org to sync the system clock, or
> to my company's vpn gateway for telecommuting, or to tor to encrypt
> my traffic, or to a dynamic dns provider to update my machine's
> record, I do not care in the least which interface I use.


This is not actually true.  You care, in that you want to be sure that
the iface connects to the internet (or at least the network that said
target sits on).

Many systems that have multiple interfaces have only some of them that
route out to the rest of the world, and when depending on a generic
'net' that includes -all- of them, it's more likely that the, say,
static private net iface will be configured (and therefore 'net'
considered started) significantly before the one that can route to the
internet, and therefore ntp-client's attempts at connecting to
pool.ntp.org will fail.

I think that "Category 2" needs to be separated into "2a - any
network", and "2b - any public network".  For instance, the service
'net' (for 2a) and service 'inet' (for 2b).  If this were the default
case, then Cat.2 packages that by default want to connect to the
internet could 'need inet', and then the user would only have to
define which interfaces are included (or excluded) from satisfying 'inet'.

The trick that I see here is that init.d scripts have to have their
'depends' set up in such a way that the services can be separated
based on their need for public network or any network, so that the
user doesn't have to mess with those.  By default I think it makes
sense to keep both the 'net' and 'inet' pools the same (ie, all ifaces
but net.lo*), but have a simple ability to separate interfaces from
the 'public net' pool in rc.conf when they do not provide a public
network connection.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8xN5IACgkQAJxUfCtlWe3hDQD+JKD7AWVep/+v8u7WcdP2ZbxB
k9Vmo5NT39WqvWPP3TYA/ReAYy4nAyYC8nbc/dRO53LwXqEP9g8rf+0WJ/aPHXkW
=2VMQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

On Tue, Feb 07, 2012 at 09:39:14AM -0500, Ian Stakenvicius wrote:
> On 07/02/12 03:28 AM, Alexandre Rostovtsev wrote:
> > 
> > If I want to connect to pool.ntp.org to sync the system clock, or
> > to my company's vpn gateway for telecommuting, or to tor to encrypt
> > my traffic, or to a dynamic dns provider to update my machine's
> > record, I do not care in the least which interface I use.
> 
> This is not actually true.  You care, in that you want to be sure that
> the iface connects to the internet (or at least the network that said
> target sits on).
> 
> Many systems that have multiple interfaces have only some of them that
> route out to the rest of the world, and when depending on a generic
> 'net' that includes -all- of them, it's more likely that the, say,
> static private net iface will be configured (and therefore 'net'
> considered started) significantly before the one that can route to the
> internet, and therefore ntp-client's attempts at connecting to
> pool.ntp.org will fail.
> 
> I think that "Category 2" needs to be separated into "2a - any
> network", and "2b - any public network".  For instance, the service
> 'net' (for 2a) and service 'inet' (for 2b).  If this were the default
> case, then Cat.2 packages that by default want to connect to the
> internet could 'need inet', and then the user would only have to
> define which interfaces are included (or excluded) from satisfying 'inet'.

You mean cat 1 actually; cat 2 are the listeners, like sshd, which don't
care as long as some interface is active.

> The trick that I see here is that init.d scripts have to have their
> 'depends' set up in such a way that the services can be separated
> based on their need for public network or any network, so that the
> user doesn't have to mess with those.  By default I think it makes
> sense to keep both the 'net' and 'inet' pools the same (ie, all ifaces
> but net.lo*), but have a simple ability to separate interfaces from
> the 'public net' pool in rc.conf when they do not provide a public
> network connection.

If we add an internet pool, I would rather it start out with no
interfaces and have the user be required to add the interface(s) to it.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[Alec Warner]

On Tue, Feb 7, 2012 at 8:44 AM, William Hubbs <williamh@gentoo.org> wrote:
> On Tue, Feb 07, 2012 at 09:39:14AM -0500, Ian Stakenvicius wrote:
>> On 07/02/12 03:28 AM, Alexandre Rostovtsev wrote:
>> >
>> > If I want to connect to pool.ntp.org to sync the system clock, or
>> > to my company's vpn gateway for telecommuting, or to tor to encrypt
>> > my traffic, or to a dynamic dns provider to update my machine's
>> > record, I do not care in the least which interface I use.
>>
>> This is not actually true.  You care, in that you want to be sure that
>> the iface connects to the internet (or at least the network that said
>> target sits on).
>>
>> Many systems that have multiple interfaces have only some of them that
>> route out to the rest of the world, and when depending on a generic
>> 'net' that includes -all- of them, it's more likely that the, say,
>> static private net iface will be configured (and therefore 'net'
>> considered started) significantly before the one that can route to the
>> internet, and therefore ntp-client's attempts at connecting to
>> pool.ntp.org will fail.
>>
>> I think that "Category 2" needs to be separated into "2a - any
>> network", and "2b - any public network".  For instance, the service
>> 'net' (for 2a) and service 'inet' (for 2b).  If this were the default
>> case, then Cat.2 packages that by default want to connect to the
>> internet could 'need inet', and then the user would only have to
>> define which interfaces are included (or excluded) from satisfying 'inet'.
>
> You mean cat 1 actually; cat 2 are the listeners, like sshd, which don't
> care as long as some interface is active.
>
>> The trick that I see here is that init.d scripts have to have their
>> 'depends' set up in such a way that the services can be separated
>> based on their need for public network or any network, so that the
>> user doesn't have to mess with those.  By default I think it makes
>> sense to keep both the 'net' and 'inet' pools the same (ie, all ifaces
>> but net.lo*), but have a simple ability to separate interfaces from
>> the 'public net' pool in rc.conf when they do not provide a public
>> network connection.
>
> If we add an internet pool, I would rather it start out with no
> interfaces and have the user be required to add the interface(s) to it.

Please ship with sane defaults. Most users don't have crazy network
setups and the ones that do are already likely customizing and can set
up the 'pools' in a way that works for them.

-A

>
> William
>

[gentoo-dev] Re: rfc: only the loopback interface should provide net

[Duncan]

Ian Stakenvicius posted on Tue, 07 Feb 2012 09:39:14 -0500 as excerpted:

> I think that "Category 2" needs to be separated into "2a - any network",
> and "2b - any public network".  For instance, the service 'net' (for 2a)
> and service 'inet' (for 2b).  If this were the default case, then Cat.2
> packages that by default want to connect to the internet could 'need
> inet', and then the user would only have to define which interfaces are
> included (or excluded) from satisfying 'inet'.
> 
> The trick that I see here is that init.d scripts have to have their
> 'depends' set up in such a way that the services can be separated based
> on their need for public network or any network, so that the user
> doesn't have to mess with those.  By default I think it makes sense to
> keep both the 'net' and 'inet' pools the same (ie, all ifaces but
> net.lo*), but have a simple ability to separate interfaces from the
> 'public net' pool in rc.conf when they do not provide a public network
> connection.

This boils down to the suggestion I made earlier.  Using current terms:

1) Separate net.lo service for stuff that doesn't have to have an 
external connection at all.

2) A default net (or net*) service that is is composed of all non-net.lo 
services, with a default any-one-of-them policy.  Two reasons for this:

2a) It'll "just work" in the simple case.

2b) It's the easiest to automatically preconfigure without getting into 
lots of "detect all the networks and magically figure out whether they're 
lan-only or inet" hairballs.

3) Allow the user/admin to configure net1, net2... just like the default 
net/net*, specifying individual interfaces for each as well as whether 
one or all of the configured interfaces must be up for the service to be 
provided.

This way, a user/admin can provide narrower-than-all groupings as 
necessary, including net.lo if it makes sense for them, tho the defaults 
would be only one net.lo and the wildcard default-any-one-of-anything-
else.

-- 
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

Re: [gentoo-dev] Re: rfc: only the loopback interface should provide net

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/02/12 11:46 AM, Duncan wrote:
> Ian Stakenvicius posted on Tue, 07 Feb 2012 09:39:14 -0500 as
> excerpted:
> 
>> I think that "Category 2" needs to be separated into "2a - any
>> network", and "2b - any public network".  For instance, the
>> service 'net' (for 2a) and service 'inet' (for 2b).  If this were
>> the default case, then Cat.2 packages that by default want to
>> connect to the internet could 'need inet', and then the user
>> would only have to define which interfaces are included (or
>> excluded) from satisfying 'inet'.
>> 
>> The trick that I see here is that init.d scripts have to have
>> their 'depends' set up in such a way that the services can be
>> separated based on their need for public network or any network,
>> so that the user doesn't have to mess with those.  By default I
>> think it makes sense to keep both the 'net' and 'inet' pools the
>> same (ie, all ifaces but net.lo*), but have a simple ability to
>> separate interfaces from the 'public net' pool in rc.conf when
>> they do not provide a public network connection.
> 
> This boils down to the suggestion I made earlier.  Using current
> terms:
> 
> 1) Separate net.lo service for stuff that doesn't have to have an 
> external connection at all.
> 
> 2) A default net (or net*) service that is is composed of all
> non-net.lo services, with a default any-one-of-them policy.  Two
> reasons for this:
> 
> 2a) It'll "just work" in the simple case.
> 
> 2b) It's the easiest to automatically preconfigure without getting
> into lots of "detect all the networks and magically figure out
> whether they're lan-only or inet" hairballs.
> 
> 3) Allow the user/admin to configure net1, net2... just like the
> default net/net*, specifying individual interfaces for each as well
> as whether one or all of the configured interfaces must be up for
> the service to be provided.
> 
> This way, a user/admin can provide narrower-than-all groupings as 
> necessary, including net.lo if it makes sense for them, tho the
> defaults would be only one net.lo and the wildcard
> default-any-one-of-anything- else.
> 

Yes, it's very similar.  The only thing that I'm not sure of under the
above situation is how the depend in each init.d script would be
defined by default, so that IF the 'net' pool doesn't match up with
the 'inet' pool ('inet' would always be a subset of 'net'), then a
user/admin could just specify the pool(s) in rc.conf, etc and NOT have
to adjust the init scripts or assign specific ifaces/pools to each
service via rc.conf.

I do realize that there is a case that breaks pretty well every
example, but this one (a 'net' and 'inet' pool, which defaults to
being the same but can easily have an iface excluded) i think expands
to cover a larger slice of cases.

This would, of course, not keep the admin from doing #3 above, which
iirc can be done now in rc.conf

(please substitute 'inet' for 'publicnet' or whatever name makes more
send to you)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk8xW4QACgkQAJxUfCtlWe0zigD+M2epQlQPH+w1+cjgJsACF8AG
UggkmYgi5GjVxwmnxdEBAJwp0uMYnibnAEVLMibXcrvJq4ybsRBEMP5t4M9+cQm4
=aksR
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

On Tue, Feb 07, 2012 at 04:46:58PM +0000, Duncan wrote:
> 1) Separate net.lo service for stuff that doesn't have to have an 
> external connection at all.
 
 This can be easily done. I'll just make net.lo* not provide net.

> 2) A default net (or net*) service that is is composed of all non-net.lo 
> services, with a default any-one-of-them policy.
> Two reasons for this:
> 
> 2a) It'll "just work" in the simple case.
> 
> 2b) It's the easiest to automatically preconfigure without getting into 
> lots of "detect all the networks and magically figure out whether they're 
> lan-only or inet" hairballs.

As soon as you add a second interface, this default "net" service
breaks. That is why I think we should add an "internet" service that
consists of interfaces the user says provide a connection to the
internet. Then we could make our services that need real
internet connections need that service instead of net.

> 3) Allow the user/admin to configure net1, net2... just like the default 
> net/net*, specifying individual interfaces for each as well as whether 
> one or all of the configured interfaces must be up for the service to be 
> provided.

This one or all functionality you are talking about is already available
through rc_depend_strict.

Also, you can set up virtual services already (see the rc.conf section
on dependencies).

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: only the loopback interface should provide net

[Alexandre Rostovtsev]

On Tue, 2012-02-07 at 11:33 -0600, William Hubbs wrote:
> On Tue, Feb 07, 2012 at 04:46:58PM +0000, Duncan wrote:
> > 1) Separate net.lo service for stuff that doesn't have to have an 
> > external connection at all.
>  
>  This can be easily done. I'll just make net.lo* not provide net.
> 
> > 2) A default net (or net*) service that is is composed of all non-net.lo 
> > services, with a default any-one-of-them policy.
> > Two reasons for this:
> > 
> > 2a) It'll "just work" in the simple case.
> > 
> > 2b) It's the easiest to automatically preconfigure without getting into 
> > lots of "detect all the networks and magically figure out whether they're 
> > lan-only or inet" hairballs.
> 
> As soon as you add a second interface, this default "net" service
> breaks. That is why I think we should add an "internet" service that
> consists of interfaces the user says provide a connection to the
> internet. Then we could make our services that need real
> internet connections need that service instead of net.

As I discussed in #gentoo-dev, it breaks if some of your interfaces are
lan-only. That might be not uncommon in the server room, but for the
typical gentoo user with a desktop or laptop, all interfaces are
generally expected to allow internet connections, and if more than one
is up (e.g. both eth0 and wlan0), the kernel will do the intelligent
thing and choose the best one to route through.

-Alexandre.

Re: [gentoo-dev] rfc: only the loopback interface should provide net

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

All,

after discussions with several devs on irc about this issue, the
following change has been made in openrc-0.9.9 which was just released:

The loopback interface provides lo and *NOT* net.
All other network interfaces provide net.

For the categories given, this means the following:

On Mon, Feb 06, 2012 at 06:15:13PM -0500, Alexandre Rostovtsev wrote:
> 1. Services that connect to remote machines via any available network
> interface.

These should use or need net.

> 2. Services that listen to connections from remote machines on any
> available network interface, and run correctly even if no non-lo
> interfaces are up.

These should be changed to use or need lo.

> 3. Services that require a specific network interface, bind to a
> specific address, or connect to a specific machine on the local subnet.

These will have to be configured by the user with something like:

rc_use/need="!net net.iface"

Thanks,

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]