rfc: OpenRC network provides revisited
 

All,

bugs like this one [1] are making me question the net/lo provides again,
and I want to know what everyone thinks.

First, do we need a provide for the loopback at all? I do not know of
any scenario in which a linux or *bsd system will not have an active
loopback interface. If we just make sure that the loopback interface
comes up in the boot runlevel, we should be good right?

The second question this bug brings up is whether services should "need"
or "use" net. Remember that the "need" dependency will try to run the
needed service even if it is in init.d but not in a runlevel.

What are your thoughts on this?

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=425130

rfc: OpenRC network provides revisited
 

On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote:
> The second question this bug brings up is whether services should "need"
> or "use" net. Remember that the "need" dependency will try to run the
> needed service even if it is in init.d but not in a runlevel.

Presumably that depends on the service. If a daemon can deal with
network interfaces going up and down, then "use net" of course makes
more sense.

> [1] https://bugs.gentoo.org/show_bug.cgi?id=425130

The bug report was caused by a failure of communication on our part; we
cannot expect average users to read the gentoo-dev mailing list. Maybe
there should have been a news item about the change in behavior in
openrc-0.9.9.

-Alexandre.

rfc: OpenRC network provides revisited
 

On Fri, Aug 24, 2012 at 01:50:14PM -0400, Alexandre Rostovtsev wrote:
> On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote:
> > The second question this bug brings up is whether services should "need"
> > or "use" net. Remember that the "need" dependency will try to run the
> > needed service even if it is in init.d but not in a runlevel.
>
> Presumably that depends on the service. If a daemon can deal with
> network interfaces going up and down, then "use net" of course makes
> more sense.

This user is running with pre-configured interfaces (root is nfs
mounted). The network interface configuration should not be touched by
openrc.

If you look at his logs, one issue is that the "network" service is
starting even though it isn't in a runlevel. I have made changes in git
master so this will not be installed if you do not use the "newnet" use
flag.

When network interfaces are pre-configured, our network scripts
shouldn't run at all, but they can be forced to run if other services
have "need net" in their dependencies.

So my question is, should we change our services to "use net" instead of
"need net"?

William

rfc: OpenRC network provides revisited
 

On 24/08/2012 12:58, William Hubbs wrote:
> This user is running with pre-configured interfaces (root is nfs
> mounted). The network interface configuration should not be touched by
> openrc.

That would be nice for LCX as well, just so you know.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

rfc: OpenRC network provides revisited
 

Hi William,

William Hubbs <williamh@gentoo.org> writes:

> When network interfaces are pre-configured, our network scripts
> shouldn't run at all, but they can be forced to run if other services
> have "need net" in their dependencies.
>
> So my question is, should we change our services to "use net" instead of
> "need net"?

I don't think we should make this change. People have different
setups. We cannot provide a default configuration that covers all corner
cases. Instead, we can show the user how to customize openrc and change
the default behavior. e.g. setting rc_provide="net" and
rc_depend_strict="NO", works for this case.

Our focus can be on providing more useful debug message to user, like
when net.lo fails to stop openrc outputs who pulled it in and how to
disable this behavior.

Yours,
Benda

rfc: OpenRC network provides revisited
 

Besides, IMHO, we should avoid changing OpenRC's default dependency too
often. The solution for one user can be received as a regression to
others.

People file bugs saying "it worked for OpenRC-0.9 but not 0.10". For
devs, we know we just changed default value of something perfectly
configurable. But for that user, it is quite discouraging to feel
"something in OpenRC is still unstable".

rfc: OpenRC network provides revisited
 

On Sat, Aug 25, 2012 at 07:40:43AM +0900, heroxbd@gentoo.org wrote:
> Besides, IMHO, we should avoid changing OpenRC's default dependency too
> often. The solution for one user can be received as a regression to
> others.
>
> People file bugs saying "it worked for OpenRC-0.9 but not 0.10". For
> devs, we know we just changed default value of something perfectly
> configurable. But for that user, it is quite discouraging to feel
> "something in OpenRC is still unstable".

Another thing to consider is, do the services we say "need net" really
_NEED_ net?

If a service is a listener like sshd that isn't bound to a specific
address by default and can deal with interfaces going up and down, I
would guess that it doesn't. I am thinking that we can set up the
depends for sshd as follows:

use net
after net

That would make sure a net provider runs before sshd if one is
in the runlevel, but allow sshd to start if one is not as well.

This would have to be tested on a case-by-case basis.

About changing default values, I think that if we have a good reason to
change them, we should inform users and change them.

I think the advantage here is that it makes openrc run out of the box in
more situations.

William

rfc: OpenRC network provides revisited
 

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

On 24/08/12 03:58 PM, William Hubbs wrote:
> On Fri, Aug 24, 2012 at 01:50:14PM -0400, Alexandre Rostovtsev
> wrote:
>> On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote:
>>> The second question this bug brings up is whether services
>>> should "need" or "use" net. Remember that the "need" dependency
>>> will try to run the needed service even if it is in init.d but
>>> not in a runlevel.
>>
>> Presumably that depends on the service. If a daemon can deal
>> with network interfaces going up and down, then "use net" of
>> course makes more sense.
>
> This user is running with pre-configured interfaces (root is nfs
> mounted). The network interface configuration should not be touched
> by openrc.
>
> If you look at his logs, one issue is that the "network" service
> is starting even though it isn't in a runlevel. I have made changes
> in git master so this will not be installed if you do not use the
> "newnet" use flag.
>
> When network interfaces are pre-configured, our network scripts
> shouldn't run at all, but they can be forced to run if other
> services have "need net" in their dependencies.
>
> So my question is, should we change our services to "use net"
> instead of "need net"?
>

No, we shouldn't. "need net" is important and "use net" doesn't
suffice in many cases.

However, for a NFS-root system there's a way to either #1 make the
"net" service do nothing (or alternatively overwrite the previously
configured net with the exact same info -- but iirc the do-nothing
option works), and alternatively #2 make it so that "net" is provided
right away.

One thing, though, that i'm not certain of is How the different
runlevels interact -- ie if "net" is started (considered up) at
"boot", it should be (and i assume is, but could be wrong) "up" during
"default" or whatever other runlevel there is, right? I know it was
with baselayout-1 (which i'm actually still running on my NFS-root
cluster).



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

iF4EAREIAAYFAlA4J6kACgkQ2ugaI38ACPAoigEAgi/Idi+tk/lmg597aVqJ+dKD
978sMNwUFnLD5GjTjM4A/1+xa5KmmF9b7SgOw0LFIdcBGByHCq8i3nd3HpgnGYhX
=FvL9
-----END PGP SIGNATURE-----

rfc: OpenRC network provides revisited
 

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

On 24/08/12 07:48 PM, William Hubbs wrote:
> On Sat, Aug 25, 2012 at 07:40:43AM +0900, heroxbd@gentoo.org
> wrote:
>> Besides, IMHO, we should avoid changing OpenRC's default
>> dependency too often. The solution for one user can be received
>> as a regression to others.
>>
>> People file bugs saying "it worked for OpenRC-0.9 but not 0.10".
>> For devs, we know we just changed default value of something
>> perfectly configurable. But for that user, it is quite
>> discouraging to feel "something in OpenRC is still unstable".
>
> Another thing to consider is, do the services we say "need net"
> really _NEED_ net?
>
> If a service is a listener like sshd that isn't bound to a
> specific address by default and can deal with interfaces going up
> and down, I would guess that it doesn't. I am thinking that we can
> set up the depends for sshd as follows:
>
> use net after net
>
> That would make sure a net provider runs before sshd if one is in
> the runlevel, but allow sshd to start if one is not as well.
>
> This would have to be tested on a case-by-case basis.
>
> About changing default values, I think that if we have a good
> reason to change them, we should inform users and change them.
>
> I think the advantage here is that it makes openrc run out of the
> box in more situations.
>
> William
>

I think this may again come down to the meaning of "net" -- in the
case where rc_depend_strict="no" then "net" just means that the
network interface infrastructure is up and running (ie net.lo); this
should be true and imo is required for something like ssh. When "net"
goes beyond that and includes other interfaces (ie,
rc_depend_strict="yes") then the 'need net' might be a bit strict; on
the other hand if a user has things set up that way then it may very
well be for a reason (for instance, I tend to prefer that sshd is
started after my hotplugged iface is up and likewise goes down when
that iface disappears. I don't see that happening with a "use net"
case when compared against a "need net".

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

iF4EAREIAAYFAlA4KMcACgkQ2ugaI38ACPCdxQD8DWD+LOJq1V 5722MUkC2tvp0i
skFHngOAJNGFyW4q3gMBAJnXZ2TQE77MUjcbbWGbfXr71EBLVB coy9vzcxHOK/Oj
=yO7o
-----END PGP SIGNATURE-----

rfc: OpenRC network provides revisited
 

On Fri, Aug 24, 2012 at 09:22:15PM -0400, Ian Stakenvicius wrote:
> I think this may again come down to the meaning of "net" -- in the
> case where rc_depend_strict="no" then "net" just means that the
> network interface infrastructure is up and running (ie net.lo); this
> should be true and imo is required for something like ssh. When "net"
> goes beyond that and includes other interfaces (ie,
> rc_depend_strict="yes") then the 'need net' might be a bit strict; on
> the other hand if a user has things set up that way then it may very
> well be for a reason (for instance, I tend to prefer that sshd is
> started after my hotplugged iface is up and likewise goes down when
> that iface disappears. I don't see that happening with a "use net"
> case when compared against a "need net".

We decided in a previous thread on this list that net.lo should not
provide net, and that is how it is set up in ~arch openrc. The part I
forgot to change is the network script.

We decided that the only things that provide net should be the
interfaces that support remote connections (e.g. anything besides the
loopback).

Also, consider a system where root is nfs mounted or a linux container.
If you are running services that "need net" and you have turned off all
of the "net" providers by adding something like rc_provide="!net" to
their conf.d files, the services that need net will fail hard even
though they shouldn't.

To handle your sshd case, you could always put

rc_need="net"

or, even better,

rc_need="net.iface"

in your /etc/conf.d/sshd file.

Thoughts?

William