FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-06-2012, 08:36 PM
Zac Medico
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-06-2012, 10:15 PM
Alexandre Rostovtsev
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 12:41 AM
William Hubbs
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 01:33 AM
Alexandre Rostovtsev
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 02:21 AM
Duncan
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 05:43 AM
William Hubbs
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 07:28 AM
Alexandre Rostovtsev
 
Default rfc: only the loopback interface should provide net

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.
 
Old 02-07-2012, 01:39 PM
Ian Stakenvicius
 
Default rfc: only the loopback interface should provide net

-----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-----
 
Old 02-07-2012, 03:44 PM
William Hubbs
 
Default rfc: only the loopback interface should provide net

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
 
Old 02-07-2012, 03:46 PM
Duncan
 
Default rfc: only the loopback interface should provide net

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
 

Thread Tools




All times are GMT. The time now is 10:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org