1 |
Alexandre Rostovtsev posted on Mon, 06 Feb 2012 21:33:39 -0500 as |
2 |
excerpted: |
3 |
|
4 |
> On Mon, 2012-02-06 at 19:41 -0600, William Hubbs wrote: |
5 |
>> > My counterproposal is to (a) fix init scripts for Category 2 so that |
6 |
>> > instead of "use net" or "need net", they only "use net.lo" or "need |
7 |
>> > net.lo"; and |
8 |
>> |
9 |
>> I think it would be better if I provided another service these scripts |
10 |
>> could use|need, because the loopback goes by at least one name other |
11 |
>> than "lo" that I know of, and that is "lo0", so if I don't provide a |
12 |
>> service, all of these scripts would have to conditionally use or need |
13 |
>> at least lo or lo0 depending on which platform they are running on. |
14 |
> |
15 |
> Maybe a virtual service called "lo", provided by net.lo and net.lo0? |
16 |
> |
17 |
>> For the normal use case, I submit that category one should not care |
18 |
>> about the loopback interface, since we don't make remote connections |
19 |
>> that way. That would mean that loopback would not provide net by |
20 |
>> default. |
21 |
> |
22 |
> Yes, that certainly seems reasonable. |
23 |
|
24 |
Indeed. I've long wondered why the loopback was thrown in there with all |
25 |
the others. It seems to me that a lo or loopback service for it, instead |
26 |
of net, would be more natural. Then have the individual net.* interface |
27 |
services and a common net service that by default includes all the net.* |
28 |
services EXCEPT loopback. |
29 |
|
30 |
Then have a configuration option such that individual installations can |
31 |
define what individual interface services compose net and how many of |
32 |
them must be up for net to be defined as up. |
33 |
|
34 |
Finally, make it possible to define additional virtual net services, |
35 |
net1, net2... each of which can be similarly locally configured as |
36 |
composed of several individual interface services, with each one allowed |
37 |
to set how many of its group of components must be up for it to be up. |
38 |
|
39 |
That would allow maximum configuration flexibility, with the ability to |
40 |
depend on one or a group of individual interface services, with each |
41 |
group allowed to require one of its set, all of its set, or something in |
42 |
between. |
43 |
|
44 |
Of course, one could add the loopback interface service to the definition |
45 |
of one of these groups if desired, but only the first one (net) would be |
46 |
defined by default, and it would by default include all interfaces /but/ |
47 |
loopback and would be provided when the first included interface came |
48 |
up. That would allow its definition to remain "fuzzily specified" so |
49 |
things could just depend on it by default if they needed an external |
50 |
network (ntpclient), or on loopback by default if they needed only a |
51 |
local interface to come up, even if they weren't a lot of use without an |
52 |
external network (privoxy, named). |
53 |
|
54 |
Where people want something up only if a specific net-service (or |
55 |
services, or one of several specific net-services) is up, they'll have to |
56 |
configure it specifically, just as they do now. There's no way around |
57 |
that since there's no simple way to determine that specific net-service |
58 |
in advance, but that would fix the problems for the first two categories |
59 |
at least, since there'd be a distinction between loopback and general net |
60 |
interface services. |
61 |
|
62 |
FWIW, my current config has net provided by loopback and several services |
63 |
depending on it, while ntpclient and ntpd depend on net.eth0. If the |
64 |
above defaults were implemented, that would have all "just worked", since |
65 |
my setup isn't complex enough to have multiple external network interface |
66 |
services to worry about, and stuff like privoxy could be configured by |
67 |
gentoo to depend on loopback only, while ntpclient depends on net, which |
68 |
if not including loopback would allow it to "just work" as well. I |
69 |
wouldn't have had to manually configure net.eth0, as I did due to lack of |
70 |
that distinction. |
71 |
|
72 |
-- |
73 |
Duncan - List replies preferred. No HTML msgs. |
74 |
"Every nonfree program has a lord, a master -- |
75 |
and if you use the program, he is your master." Richard Stallman |