| 1 |
Hi, |
| 2 |
|
| 3 |
Dave Crane wrote: |
| 4 |
>>because net.lo is not usefull for a system that provides services. |
| 5 |
>>for example running a ssh server for net.lo is kinda silly :) |
| 6 |
> |
| 7 |
> |
| 8 |
> Maybe we should all remove the localhost line from /etc/hosts if it's silly. |
| 9 |
|
| 10 |
You could, but GNOME won't be happy. Silly, isn't it? ;) |
| 11 |
|
| 12 |
> Maybe /etc/fstab should be /etc/conf.d/filesystems? |
| 13 |
|
| 14 |
First off, how is this related to the rest of the discussion? |
| 15 |
There is a clear logic to find out what configuration should be set in |
| 16 |
/etc/conf.d/ and what should go to /etc in general. I'm sure you will find it |
| 17 |
out after thinking a bit over it ;) |
| 18 |
|
| 19 |
(On a side node: /etc/rc.conf still breaks that logic by setting LOGINMANAGER, |
| 20 |
although the vast majority of it has been moved to /etc/conf.d/*, which was a |
| 21 |
very good thing, IMHO) |
| 22 |
|
| 23 |
> Or maybe its should be left to the app. adding RC_NET_STRICT_CHECKING would |
| 24 |
> have other consequences. One size does not fit all here. If net.lo is the |
| 25 |
> only thing that satisfies net on a given system and the process doesnt have a |
| 26 |
> problem attaching to that (as I just verified with both sshd and apache2), |
| 27 |
> then let it be. |
| 28 |
|
| 29 |
From /etc/conf.d/rc: |
| 30 |
# no - This basically means that at least one net.* service besides net.lo |
| 31 |
# must be up. This can be used by notebook users that have a wifi and |
| 32 |
# a static nic, and only wants one up at any given time to have the |
| 33 |
# 'net' service seen as up. |
| 34 |
# lo - This is the same as the 'no' option, but net.lo is also counted. |
| 35 |
# This should be useful to people that do not care about any specific |
| 36 |
# interface being up at boot. |
| 37 |
|
| 38 |
I can't see what side effect you are referring to (assuming you set it to 'lo'). |
| 39 |
If net.lo breaks, net is not provided, and rc-scripts depending on it won't start. |
| 40 |
|
| 41 |
> Sorry to go off on this, but things have been changing in the last few months |
| 42 |
> in ways illogical to me. I've been running gentoo since pre 1.0 days and |
| 43 |
> this has greatly concerned me lately. |
| 44 |
|
| 45 |
Yes, things have been changing. This mainly causes problems for users that have |
| 46 |
installed Gentoo a long time ago, were happy with their installation and leaned |
| 47 |
back. I know it is a time-consuming task to follow the development of a |
| 48 |
distribution, but it is every administrator's first duty. I remember the nice |
| 49 |
GWN article telling how baselayout changed and what you should pay attention to |
| 50 |
when upgrading. |
| 51 |
|
| 52 |
> Every distro has it's quirks and funny ways of doing things, but the list |
| 53 |
> seems to be growing with gentoo for no good reason. |
| 54 |
|
| 55 |
I don't think so. From time to time I have the same feelings, but in almost all |
| 56 |
cases it turns out that the real issue was me beeing too lazy to read docs. |
| 57 |
|
| 58 |
Regards, |
| 59 |
|
| 60 |
-- |
| 61 |
Simon Stelling |
| 62 |
Gentoo/AMD64 Operational Co-Lead |
| 63 |
blubb@g.o |
| 64 |
-- |
| 65 |
gentoo-amd64@g.o mailing list |
Archives