On 28/07/2014 16:34, Grand Duet wrote:
2014-07-28 1:00 GMT+03:00 Kerin Millar <kerfra...@fastmail.co.uk>:
On 27/07/2014 21:38, Grand Duet wrote:
2014-07-27 22:13 GMT+03:00 Neil Bothwick <n...@digimed.co.uk>:
On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote:
That's what replaces it when eth0 comes up.
It looks like eth0 is not being brought up fully
It sounds logical. But how can I fix it?
By identifying how far it is getting and why no further.
But it appears that eth0 is being brought up correctly
and then the config is overwritten by the lo config.
I think so.
As I have already reported in another reply to this thread,
it is my first reboot after commenting out the line
dns_domain_lo="mynetwork"
and so far it went good.
Moreover, the file /etc/resolv.conf has not been overwritten.
I still have to check if everything else works fine and
if I will get the same result on the next reboot
but I hope that the problem has been solved.
But it looks like a bug in the net csript.
Why lo configuration should overwrite eth0 configuration at all?
I would consider it be a documentation bug at the very least. Being able to
propagate different settings to resolv.conf depending on whether a given
interface is up may be of value for some esoteric use-case, although I
cannot think of one off-hand. Some other distros use the resolvconf
application to handle these nuances.
In any case, it is inexplicable that the user is invited to define
dns_domain for the lo interface. Why would one want to push settings to
resolv.conf based on the mere fact that the loopback interface has come up?
Also, it would be a great deal less confusing if the option were named
dns_search.
I think that the handbook should refrain from mentioning the option at all,
for the reasons stated in my previous email. Those who know that they need
to define a specific search domain will know why and be capable of figuring
it out.
It's too bad that the handbook is still peddling the notion that this
somehow has something to do with 'setting' the domain name. It is tosh of
the highest order.
I agree with you. But how to put it all in the right ears?
I'm not entirely sure. I'd give it another shot if I thought it was
worth the effort. My experience up until now is that requests for minor
documentation changes are dismissed on the basis that, if it does not
prevent the installation from being concluded, it's not worth bothering
with [1]. I do not rate the handbook and, at this juncture, my concern
is slight except for where it causes demonstrable confusion among the
user community. Indeed, that's why my interest was piqued by this thread.
--Kerin
[1] For example: bugs 304727 and 344753
