| 1 |
> Or maybe its should be left to the app. adding RC_NET_STRICT_CHECKING would |
| 2 |
> have other consequences. One size does not fit all here. If net.lo is the |
| 3 |
> only thing that satisfies net on a given system and the process doesnt have a |
| 4 |
> problem attaching to that (as I just verified with both sshd and apache2), |
| 5 |
> then let it be. |
| 6 |
|
| 7 |
A distribution is made for groups of users, not you specifically. |
| 8 |
Personally, I prefer having it the way it is so that if I boot my laptop |
| 9 |
and it cannot connect to a network it doesn't spend ages starting various |
| 10 |
network services like sshd, apache2, openvpn, etc. |
| 11 |
|
| 12 |
If a particular application has a problem with net.lo, you could force a |
| 13 |
dependency on a particular net service instead of just net by modifying |
| 14 |
the init files, or using multiple run levels. Personally, I do not know of |
| 15 |
any network service that has a problem in having just net.lo available. |
| 16 |
|
| 17 |
I use the RC_NET_STRICT_CHECKING to prevent a bunch of services from |
| 18 |
starting up on my laptop if it cannot find a wifi or ethernet connection. |
| 19 |
|
| 20 |
> What if you have apache setup SPECIFICALLY to attach to 127.0.0.1 so as to not |
| 21 |
> be publicly accessible? I've done this numerous times in the past for |
| 22 |
> various reasons. |
| 23 |
> |
| 24 |
> If it fails at init, it would be logical to check the logfile for the app and |
| 25 |
> you'd quickly know what was wrong instead of having to mail a list. |
| 26 |
|
| 27 |
How is that logical ? |
| 28 |
|
| 29 |
First you have to check if the service attempted to start. |
| 30 |
Then, upon proper interpretation of failures, you should check the |
| 31 |
relevant log file. |
| 32 |
|
| 33 |
Regarding network interfaces, apache will fail if it cannot bind to |
| 34 |
a specific IP if and only if it is the only ip it is set to bind to. |
| 35 |
|
| 36 |
The init scripts will not start a service if the dependencies are not |
| 37 |
satisfied in the first place. |
| 38 |
|
| 39 |
Also it usually is better to mail a list more specific to your needs as |
| 40 |
this is not an amd64 issue, after checking the documentation. |
| 41 |
|
| 42 |
> Sorry to go off on this, but things have been changing in the last few months |
| 43 |
> in ways illogical to me. I've been running gentoo since pre 1.0 days and |
| 44 |
> this has greatly concerned me lately. |
| 45 |
> |
| 46 |
> Every distro has it's quirks and funny ways of doing things, but the list |
| 47 |
> seems to be growing with gentoo for no good reason. |
| 48 |
|
| 49 |
Distributions always evolve. No one is pointing a gun to your head to use |
| 50 |
Gentoo. |
| 51 |
-- |
| 52 |
gentoo-amd64@g.o mailing list |
Archives