| 1 |
On Mon, 2012-02-06 at 15:04 -0600, William Hubbs wrote: |
| 2 |
> All, |
| 3 |
> |
| 4 |
> I've been pondering for a while why All of OpenRC's network interfaces |
| 5 |
> provide net. |
| 6 |
> |
| 7 |
> My understanding of the "net" service is that it is there to signal that |
| 8 |
> a generic network connection is active. |
| 9 |
> |
| 10 |
> What I would like to do in OpenRC is change the network scripts so that |
| 11 |
> only the loopback interface provides net. |
| 12 |
> |
| 13 |
> The down side of this approach will be that if a daemon uses a specific |
| 14 |
> ip address in its configuration, or if it binds to a specific address, |
| 15 |
> the user will have to set up the appropriate configuration options in |
| 16 |
> /etc/conf.d. For example, if I setup sshd to use 192.168.10.1 and eth0 has |
| 17 |
> this address, I have to put the following line in /etc/conf.d/sshd: |
| 18 |
> |
| 19 |
> rc_need="net.eth0" |
| 20 |
> |
| 21 |
> One advantage I see of this approach is it will provide a fix for bugs like |
| 22 |
> http://bugs.gentoo.org/show_bug.cgi?id=228973 by requiring users to |
| 23 |
> configure services like this to start after the interface they use |
| 24 |
> is started. |
| 25 |
> |
| 26 |
> Attached to this message you will find the patch I want to apply to |
| 27 |
> OpenRC to make this change. |
| 28 |
> |
| 29 |
> Any thoughts, comments, or suggestions would be helpful. |
| 30 |
> |
| 31 |
> William |
| 32 |
|
| 33 |
I agree with the existence of the problem, but strongly disagree with |
| 34 |
the solution. |
| 35 |
|
| 36 |
There are three very different reasons why an openrc service may |
| 37 |
currently "use net" or "need net": |
| 38 |
|
| 39 |
1. Services that connect to remote machines via any available network |
| 40 |
interface. |
| 41 |
2. Services that listen to connections from remote machines on any |
| 42 |
available network interface, and run correctly even if no non-lo |
| 43 |
interfaces are up. |
| 44 |
3. Services that require a specific network interface, bind to a |
| 45 |
specific address, or connect to a specific machine on the local subnet. |
| 46 |
|
| 47 |
Category 1 includes things like ntp-client (in the typical use case). |
| 48 |
Category 2 includes things like sshd (in the typical use case). |
| 49 |
Category 3 includes things like netmount (in the typical use case), or |
| 50 |
your example of sshd that's bound to a specific static IP. |
| 51 |
|
| 52 |
The proposal to provide net only from loopback may help with startup |
| 53 |
issues for Category 2, but would break Category 1. (Category 3 is broken |
| 54 |
in either case unless the user adds the appropriate rc_need lines |
| 55 |
in /etc/conf.d). |
| 56 |
|
| 57 |
My counterproposal is to |
| 58 |
(a) fix init scripts for Category 2 so that instead of "use net" or |
| 59 |
"need net", they only "use net.lo" or "need net.lo"; and |
| 60 |
(b) document (via pkg_postinst messages and comments in the default |
| 61 |
conf.d file) the requirement to manually configure rc_need for services |
| 62 |
in Category 3; and |
| 63 |
(c) continue to provide net in network scripts so that Category 1 |
| 64 |
continues to work. |
| 65 |
|
| 66 |
PS. Only 4 days ago, I deliberately changed /etc/init.d/NetworkManager |
| 67 |
in net-misc/networkmanager-0.9.2.0-r3 so that it provides net to ensure |
| 68 |
that Category 1 services work properly. It was rather an unpleasant |
| 69 |
surprise to now read a proposal to make the default openrc setup as |
| 70 |
broken as old networkmanager versions used to be :/ |
| 71 |
|
| 72 |
-Alexandre |
Archives