Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Sat, Nov 04, 2017 at 08:53:56PM +, Brian wrote:
> 
> I'm not going to ask what an "intersection situation" is. It sounds very
> technical. But I thought anyone who used DHCP. and cared about it, would
> realise they had ended up on the network they were connecting to. That
> would include using that network's nameservers (unless they arranged it
> otherwise).
> 
It is the intersection of groups A and B described by Tomas.

If you go back and read the original post that kicked off this thread,
the entire issue was that I thought that the absence of resolvconf was
sufficient to create an arrangement where the nameservers weren't
populated from DHCP.  In my case I am running my own bind on the machine
in question (to provide DNS for my LAN), which is also the
firewall/router for my network.  So, there is an interface with a static
address connected to the LAN and another that is configured by DHCP from
the ISP equipment.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Nov 04, 2017 at 08:53:56PM +, Brian wrote:
> On Sat 04 Nov 2017 at 08:03:02 -0400, Roberto C. Sánchez wrote:
> 
> > On Sat, Nov 04, 2017 at 08:45:59AM +0100, to...@tuxteam.de wrote:
> > > 
> > > Most of us fall into two classes:
> > > 
> > >  A. All static. Nobody changes resolv.conf. All is well. Admin writes
> > > resolv.conf (and /etc/hosts and all).  (the "classic")
> > >  B. Get IP address via DHCP (dhclient, NetworkManager, whatever else).
> > > Whatever else writes to resolv.conf. User == admin mostly doesn't
> > > even know what resolv.conf means, most of the time.

[...]

> I'm not going to ask what an "intersection situation" is. It sounds very
> technical.

Touché :-)

basically that means that you care about the content of your resolv.conf,
but let some agent (e.g. resolvconf or dhclient) update it. You then bear
the burden to understand what said agent is doing. But you learn something
(my learning started with chattr +i and log watching, some moons ago).

> But I thought anyone who used DHCP. and cared about it, would
> realise they had ended up on the network they were connecting to. That
> would include using that network's nameservers (unless they arranged it
> otherwise).

Precisely.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAln+K5wACgkQBcgs9XrR2kabmwCcCOgWMdfWM87Osa5H0qzWI1K6
zZYAn0l0IkHFS/HVegn+ZcsAXBycVpxh
=/Pk6
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Brian]

On Sat 04 Nov 2017 at 08:03:02 -0400, Roberto C. Sánchez wrote:

> On Sat, Nov 04, 2017 at 08:45:59AM +0100, to...@tuxteam.de wrote:
> > 
> > Most of us fall into two classes:
> > 
> >  A. All static. Nobody changes resolv.conf. All is well. Admin writes
> > resolv.conf (and /etc/hosts and all).  (the "classic")
> >  B. Get IP address via DHCP (dhclient, NetworkManager, whatever else).
> > Whatever else writes to resolv.conf. User == admin mostly doesn't
> > even know what resolv.conf means, most of the time.
> > 
> > Without resolvconf, you're in trouble if there are several agents
> > caring about resolv.conf, that is, you are in class B and have
> > e.g. NetworkManager and say dhclient (or some systemd outgrowth,
> > cough, cough) trying to write to that file. Or you are in an intersection
> > of A and B (who said they were disjoint? The sysadmin is but an agent
> > more). In the latter case, you're bound to learn enough about sysadmin
> > to really decide whether you *want* resolvconf or not.
> > 
> > Me? I am in A∩B. And with no resolvconf. Stefan? Most probably in
> > the same set. And with resolvconf.
> > 
> I agree.  The intersection situation (which I believe describes my) is
> why I filed #879949.  I small hint would have saved me many hours of
> frustration.  I suspect that it would do the same for others.

I'm not going to ask what an "intersection situation" is. It sounds very
technical. But I thought anyone who used DHCP. and cared about it, would
realise they had ended up on the network they were connecting to. That
would include using that network's nameservers (unless they arranged it
otherwise).

-- 
Brian.

Re: Why does resolv.conf keep changing?

[Pascal Hambourg]

Le 03/11/2017 à 23:22, Roger Lynn a écrit :


I think it would be preferable for every package which wants to write to the
resolv.conf file to be required to use the resolvconf package to do so


If it is installed. Otherwise, write directly in resolv.conf.


Uninstalling the resolvconf package would then
mean nothing could write to the resolv.conf file.


Fortunately not. That would break many existing setups.

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Sat, Nov 04, 2017 at 08:45:59AM +0100, to...@tuxteam.de wrote:
> 
> Most of us fall into two classes:
> 
>  A. All static. Nobody changes resolv.conf. All is well. Admin writes
> resolv.conf (and /etc/hosts and all).  (the "classic")
>  B. Get IP address via DHCP (dhclient, NetworkManager, whatever else).
> Whatever else writes to resolv.conf. User == admin mostly doesn't
> even know what resolv.conf means, most of the time.
> 
> Without resolvconf, you're in trouble if there are several agents
> caring about resolv.conf, that is, you are in class B and have
> e.g. NetworkManager and say dhclient (or some systemd outgrowth,
> cough, cough) trying to write to that file. Or you are in an intersection
> of A and B (who said they were disjoint? The sysadmin is but an agent
> more). In the latter case, you're bound to learn enough about sysadmin
> to really decide whether you *want* resolvconf or not.
> 
> Me? I am in A∩B. And with no resolvconf. Stefan? Most probably in
> the same set. And with resolvconf.
> 
I agree.  The intersection situation (which I believe describes my) is
why I filed #879949.  I small hint would have saved me many hours of
frustration.  I suspect that it would do the same for others.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Nov 03, 2017 at 10:22:33PM +, Roger Lynn wrote:
> On 26/10/17 13:40, Stefan Monnier wrote:
> >> Given that multiple packages potentially touch/change resolv.conf (at
> >> least resolvconf and the various DHCP clients),
> > 
> > That is not true: when resolvconf is installed, *no package* should
> > (modulo bugs) ever change /etc/resolv.conf.
> > 
> > Instead all changes go through resolvconf, which only modifies
> > /run/resolvconf/resolv.conf (and those changes usually get reflected
> > into /etc/resolv.conf by making it a symlink to that file, but that's
> > not mandatory).
> > 
> > Stefan "who thinks resolvconf should always be installed"
> 
> I think it would be preferable for every package which wants to write to the
> resolv.conf file to be required to use the resolvconf package to do so
> (which is what I, and I think some other people, thought the situation was
> until we read this thread). Uninstalling the resolvconf package would then
> mean nothing could write to the resolv.conf file.

I strongly disagree. There are people who *want* to have (for example)
dhclient keeping their resolv.conf up to date (and no intermediate
package like resolvconf meddling). One of the things I do love about
Debian is that it goes out of its way to accomodate all of 'em (as long
as there's someone willing to do the legwork, that is).

It comes at some price, though.

> I've been in the fortunate position that I've never needed to install the
> resolvconf package and nothing has ever tried to modify my resolv.conf file.
> I've obviously led a sheltered life.

Most of us fall into two classes:

 A. All static. Nobody changes resolv.conf. All is well. Admin writes
resolv.conf (and /etc/hosts and all).  (the "classic")
 B. Get IP address via DHCP (dhclient, NetworkManager, whatever else).
Whatever else writes to resolv.conf. User == admin mostly doesn't
even know what resolv.conf means, most of the time.

Without resolvconf, you're in trouble if there are several agents
caring about resolv.conf, that is, you are in class B and have
e.g. NetworkManager and say dhclient (or some systemd outgrowth,
cough, cough) trying to write to that file. Or you are in an intersection
of A and B (who said they were disjoint? The sysadmin is but an agent
more). In the latter case, you're bound to learn enough about sysadmin
to really decide whether you *want* resolvconf or not.

Me? I am in A∩B. And with no resolvconf. Stefan? Most probably in
the same set. And with resolvconf.

Distros are social projects. They have to accomodate types of humans
you never dreamt they exist. That's actually the exciting part of
it :-)

Cheers
- -- tomás


> 
> Roger
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAln9cDcACgkQBcgs9XrR2kaP6QCcDZ6J8BY8l9ZSU98sH5SG7oJq
Fn4An3dtLT0PDcUL2IiV3QdLVxLDf/fJ
=4/hS
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Roger Lynn]

On 26/10/17 13:40, Stefan Monnier wrote:
>> Given that multiple packages potentially touch/change resolv.conf (at
>> least resolvconf and the various DHCP clients),
> 
> That is not true: when resolvconf is installed, *no package* should
> (modulo bugs) ever change /etc/resolv.conf.
> 
> Instead all changes go through resolvconf, which only modifies
> /run/resolvconf/resolv.conf (and those changes usually get reflected
> into /etc/resolv.conf by making it a symlink to that file, but that's
> not mandatory).
> 
> Stefan "who thinks resolvconf should always be installed"

I think it would be preferable for every package which wants to write to the
resolv.conf file to be required to use the resolvconf package to do so
(which is what I, and I think some other people, thought the situation was
until we read this thread). Uninstalling the resolvconf package would then
mean nothing could write to the resolv.conf file.

I've been in the fortunate position that I've never needed to install the
resolvconf package and nothing has ever tried to modify my resolv.conf file.
I've obviously led a sheltered life.

Roger

Re: Why does resolv.conf keep changing?

[Glenn English]

I've recently found myself living with a T1 and a DHCP (Comcast) --
slow and reliable all the time, and blistering fast at 3:00 AM.

I think I may have dealt with the resolv.conf (R.C) problem. I set
myself as the owner of R.C, removed everything but owner read
permission, and set it to immutable. (Largely for show; I know all
this doesn't slow down root a whole lot.)

The computer's 2 Ethernet interfaces are configured in
/etc/network/interfaces and Network Manager has been removed.
One interface is static, the other is DHCP. There are a couple
'post-up'  scripts in the DHCP config -- one replaces R.C with the one
I want it to be and deletes the files whining about how Comcast
couldn't scribble in R.C, the other rewrites the routing table so the
mirrors go with Comcast and everything else uses the T1.

If/when Comcast figures out how to get root and overcome the configs
done to R.C, the scripts make things all better again. (Assuming
immutable's been disabled somehow and R.C needs to be replaced.)

--
Glenn English

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Sat, Oct 28, 2017 at 09:45:18AM +, Bonno Bloksma wrote:
> Hi Roberto,
> 
> I am glad you have things resolved and discovered some things that could be 
> improved.

Thanks.

> I do have one question about your solution.
> 
> You write:
> 
> >> This is clearly evidence that the problem is with dhclient 
> >> (isc-dhcp-client in my case).  I am taking another look at the 
> >> supersede directives in /etc/dhcp/dhclient.conf to make sure that I am 
> >> specifying them correctly. 
> 
> > OK.  I was able to dig into this I resolved the problem by telling dhclient 
> > to not request the bits of information that would trigger a change to 
> > /etc/resolv.conf.
> []
> So that was one way to resolve the problem.
> 
> But then you write:
> > Another approach which worked equally well was to specify the supersede 
> > directive with the values I preferred for domain-name, domain-search, and 
> > domain-name-servers.
> 
> And this seems weird as the very first thing you wrote a week ago was:
> >>> The second thing I tried was adding to /etc/dhcp/dhclient.conf:
> >>>
> >>> supersede domain-name example.com;
> >>> supersede domain-search example.com.;
> >>> supersede domain-name-servers 127.0.0.1;
> >>>
> >>> This similarly has no lasting effect, which is really surprising to me.
> 
> So does the supersede directive work after all, as it is supposed to do?
> 
> I have been using the prepend directive for years to make sure my own
> dns servers got listed before the ISP one. That way if my internal dns
> server would ever fail I would have a fallback to the ISP dns server.
> Maybe not perfect but it would leave me with at least some dns
> capability.
> 
> I now have a fixed ip address on the ISP connection so I can no longer
> test this, which is why I did not respond before when you stated the
> supersede directive did not work.
> 
> But could you clear up whether the supersede still works if properly
> listed in /etc/dhcp/dhclient.conf ?
> 
Yes, the supersede directive works.  I believe that the error I had in
my configuration was that the supersede lines were listed after the
request line, but they needed to occur prior to the request line.  This
seemed rather unintuitive to me.

Regards,

-Roberto

-- 
Roberto C. Sánchez

RE: [SOLVED] Re: Why does resolv.conf keep changing?

[Bonno Bloksma]

Hi Roberto,

I am glad you have things resolved and discovered some things that could be 
improved.
I do have one question about your solution.

You write:

>> This is clearly evidence that the problem is with dhclient 
>> (isc-dhcp-client in my case).  I am taking another look at the 
>> supersede directives in /etc/dhcp/dhclient.conf to make sure that I am 
>> specifying them correctly. 

> OK.  I was able to dig into this I resolved the problem by telling dhclient 
> to not request the bits of information that would trigger a change to 
> /etc/resolv.conf.
[]
So that was one way to resolve the problem.

But then you write:
> Another approach which worked equally well was to specify the supersede 
> directive with the values I preferred for domain-name, domain-search, and 
> domain-name-servers.

And this seems weird as the very first thing you wrote a week ago was:
>>> The second thing I tried was adding to /etc/dhcp/dhclient.conf:
>>>
>>> supersede domain-name example.com;
>>> supersede domain-search example.com.;
>>> supersede domain-name-servers 127.0.0.1;
>>>
>>> This similarly has no lasting effect, which is really surprising to me.

So does the supersede directive work after all, as it is supposed to do?
I have been using the prepend directive for years to make sure my own dns 
servers got listed before the ISP one. That way if my internal dns server would 
ever fail I would have a fallback to the ISP dns server. Maybe not perfect but 
it would leave me with at least some dns capability.

I now have a fixed ip address on the ISP connection so I can no longer test 
this, which is why I did not respond before when you stated the supersede 
directive did not work.
But could you clear up whether the supersede still works if properly listed in 
/etc/dhcp/dhclient.conf ?

Bonno Bloksma

Re: Why does resolv.conf keep changing?

[Mart van de Wege]

Roberto C. Sánchez  writes:

> On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote:
>> Roberto C. Sánchez  writes:
>> 
>> > Think about that for a minute.  The mere action of an interface (any
>> > interface on the system) obtaining a DHCP lease is sufficient to have
>> > dhclient think it needs to obliterate my manual networking configuration
>> > with settings from the DHCP server.
>> 
>> Well, yes. That's what DHCP *does*.
>> 
> The problem I have with it is that in my case there are other *static*
> interfaces on the system and DHCP's assumption that it is operating in a
> vacuum is terribly annoying.

You are not. Hence resolvconf. And yes, having to muck about with
dhclient settings or resolvconf when you have a mixed dynamic/static
setup can be aggravating.

> I cannot be the only person who has encountered this particular issue
> with these circumstances and been frustrated by how difficult it is
> to, 1) find out what exactly is happening,

Actually my first thought was 'hmm, sounds like a DHCP client is
running".

> and 2) make it stop.
>
I remember how much time it took me to get used to resolvconf +
NetworkManager + dnsmasq on my laptop, to convince that combo to always
use my internal DNS servers so that my Kerberos realm would keep working
over VPN.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why does resolv.conf keep changing?

[Mart van de Wege]

David Wright  writes:

> Am I the only person surprised that there wasn't more advocacy for
> systemd-resolved.service as well.
>
So far all that's stopping me experimenting with it is that I don't
understand the interaction between openvpn, systemd-networkd and
systemd-resolved yet.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why does resolv.conf keep changing?

[Michael Stone]

On Fri, Oct 27, 2017 at 07:49:29AM -0400, Gene Heskett wrote:

I must argue against it, until as you say, resolvconf is given a well
documented way to be told to leave a "static" system alone.  Until such
time, I'll make /etc/resolv.conf a real file, and mark it
and /etc/network/interfaces immutable.


It's been mentioned several times. If you don't want to do that and 
would rather set the immutable bit, great! Now move on and stop 
complaining about it.


Mike Stone

Re: Why does resolv.conf keep changing?

[David Wright]

On Fri 27 Oct 2017 at 18:05:23 (-0400), Roberto C. Sánchez wrote:
> On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote:
> > Roberto C. Sánchez  writes:
> > 
> > > Think about that for a minute.  The mere action of an interface (any
> > > interface on the system) obtaining a DHCP lease is sufficient to have
> > > dhclient think it needs to obliterate my manual networking configuration
> > > with settings from the DHCP server.
> > 
> > Well, yes. That's what DHCP *does*.
> > 
> The problem I have with it is that in my case there are other *static*
> interfaces on the system and DHCP's assumption that it is operating in a
> vacuum is terribly annoying.

Yes, that's why some people recommended resolvconf to moderate
its (and other packages') behaviour. That's what resolvconf does.

> I cannot be the only person who has
> encountered this particular issue with these circumstances and been
> frustrated by how difficult it is to, 1) find out what exactly is
> happening, and 2) make it stop.

No, nor to unintentionally cause a wild goose chase by making a
reporting error. Nor to have your thread derailed by people posting
their favourite purported "solutions" that have already been
discredited here.

OTOH I think it's understandable that the thread is prolonged by
well-intentioned suggestions to adopt the "official" Debian way
of handling this with resolvconf. Am I the only person surprised
that there wasn't more advocacy for systemd-resolved.service
as well.

Cheers,
David.

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote:
> Roberto C. Sánchez  writes:
> 
> > Think about that for a minute.  The mere action of an interface (any
> > interface on the system) obtaining a DHCP lease is sufficient to have
> > dhclient think it needs to obliterate my manual networking configuration
> > with settings from the DHCP server.
> 
> Well, yes. That's what DHCP *does*.
> 
The problem I have with it is that in my case there are other *static*
interfaces on the system and DHCP's assumption that it is operating in a
vacuum is terribly annoying.  I cannot be the only person who has
encountered this particular issue with these circumstances and been
frustrated by how difficult it is to, 1) find out what exactly is
happening, and 2) make it stop.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Mart van de Wege]

Roberto C. Sánchez  writes:

> Think about that for a minute.  The mere action of an interface (any
> interface on the system) obtaining a DHCP lease is sufficient to have
> dhclient think it needs to obliterate my manual networking configuration
> with settings from the DHCP server.

Well, yes. That's what DHCP *does*.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why does resolv.conf keep changing?

[Mart van de Wege]

Darac Marjal  writes:

>
> Who's saying it must be installed? Maybe I've missed something, but I
> think the consensus in this discussion was that if you want your
> resolv.conf to be unmanaged/static/administrator-controlled, then
> don't have resolvconf installed. If you have resolvconf installed,
> then what's the point of neutering it with a command?
>
Because in this case OP is running a DHCP client, which *will* overwrite
resolv.conf unless something stops it.

And you can then either try all kinds of workarounds, or install the
tool that's meant to manage resolv.conf in the presence of programs that
want to change it.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Fri, Oct 27, 2017 at 07:47:49PM +, Curt wrote:
> My response is two venerable hot-shots from this very forum ventured
> into that rather short wiki within the last 24 hours, made edits,
> advertised them here, but couldn't be bothered to fix the fucking thing
> and as a lesser mortal amongst you high-falutin sons of bitches I
> figured it must not be worth the effort (to fix).

Well.  The question is whether to delete that section, or to leave it
in place.  There is no urgent need to delete it, because it is not
factually *wrong*.  It's simply someone's anecdotal experience.

Likewise, there's no reason to correct the grammar.  The grammar and
the shell commands are both awkward and unpolished.  Fixing the grammar
and leaving those awful shell commands unchanged would give the mistaken
impression that those shell commands are actually good.  The way it's
written now, anyone who reads English semi-fluently can tell that it's
an anecdotal appendix, and not a preferred solution.

If you feel that it's better to delete the whole section, then that's
your call.  My preference is to leave content in place wherever possible,
unless the content is wrong, misleading, full of errors, etc.  For all
I know, "Debian 8.8.4.4" may be someone's google search terms that lead
them to this page.  Once they get to the page, then they can read about
the issues and the various ways to achieve their goal.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Curt]

On 2017-10-27, Brian  wrote:
>> >
>> 
>> Weird wiki. From "my issues" (sic) down it switches from third to
>> first-person narration by what I suspect is a Germanophone and all hell
>> breaks loose (grammatically speaking).
>
> It's a wiki. That tells you something. ("someone else apart from me
> can do it" is not your response, if you choose to give one).
>

My response is two venerable hot-shots from this very forum ventured
into that rather short wiki within the last 24 hours, made edits,
advertised them here, but couldn't be bothered to fix the fucking thing
and as a lesser mortal amongst you high-falutin sons of bitches I
figured it must not be worth the effort (to fix).

So there. Find a convenient lake, B., and go jump in.

Thank you.

Over and out.

-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

Re: Why does resolv.conf keep changing?

[David Wright]

On Fri 27 Oct 2017 at 11:38:56 (-0700), Kevin O'Gorman wrote:
> Interesting.  I took a look at mine, and found
> lrwxrwxrwx 1 root root 29 Aug  8  2016 /etc/resolv.conf ->
> ../run/resolvconf/resolv.conf
> 
> so the thing is now entirely dynamic.  I don't know what setting it
> immutable would do or mean.

If you mean /etc/resolv.conf itself, you can't.

Cheers,
David.

Re: Why does resolv.conf keep changing?

[David Wright]

On Fri 27 Oct 2017 at 08:35:05 (-0400), Greg Wooledge wrote:
> On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote:
> > Who's saying it must be installed?
> 
> A few people in this thread, though I think they're saying "should"
> rather than "must".
> 
> > Maybe I've missed something, but I think
> > the consensus in this discussion was that if you want your resolv.conf to be
> > unmanaged/static/administrator-controlled, then don't have resolvconf
> > installed. If you have resolvconf installed, then what's the point of
> > neutering it with a command?

Conceivably, one could switch between a *docked laptop with
chattr +i of a real file* that is occasionally taken on the road
with the simple actions of chattr -i and ln -s being necessary
to effect the change.
All the daemons could be working away as normal all the time,
but just rendered impotent when docked.

AFAICT this will also keep systemd happy when docked, and undocking
can be done with a symlink to /run/systemd/resolve/resolv.conf
(rather than /etc/resolvconf/run/resolv.conf), allowing
systemd-resolved.service to perform again.

> Let's review what we've learned so far.
> 
> If you want to make local modifications to /etc/resolv.conf and have
> them stick, here are some ways to do it:
> 
> 1) chattr +i /etc/resolv.conf

With the common sense assumptions that a real file has had the
required data entered, that would seem to be sufficient, without
having to cope with the complications following.

> 2) Individually configure each daemon that might try to modify the file,
>to make it stop doing so.
> 
> 3) Install the resolvconf package, because by doing so you also install
>various hacks that modify the behavior of all known Debian daemons,
>stopping them from writing to /etc/resolv.conf.
> 
>Then tell resolvconf itself to do nothing by putting resolvconf=NO
>in the /etc/resolvconf.conf file.

Cheers,
David.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Brian]

On Fri 27 Oct 2017 at 18:27:09 +, Curt wrote:

> On 2017-10-27, Greg Wooledge  wrote:
> > On Fri, Oct 27, 2017 at 11:03:38AM -0400, Roberto C. Sánchez wrote:
> >> I finally got around to updating the wiki page today.  Here is the link
> >> for those who wish to have it as a reference or perhaps would like to
> >> contribute to further improving it:
> >> 
> >> https://wiki.debian.org/resolv.conf
> >
> > I've made a few changes as well.
> >
> >
> 
> Weird wiki. From "my issues" (sic) down it switches from third to
> first-person narration by what I suspect is a Germanophone and all hell
> breaks loose (grammatically speaking).

It's a wiki. That tells you something. ("someone else apart from me
can do it" is not your response, if you choose to give one).

-- 
Brian.

Re: Why does resolv.conf keep changing?

[Kevin O'Gorman]

Interesting.  I took a look at mine, and found
lrwxrwxrwx 1 root root 29 Aug  8  2016 /etc/resolv.conf ->
../run/resolvconf/resolv.conf

so the thing is now entirely dynamic.  I don't know what setting it
immutable would do or mean.
I'm running xubuntu 16.04.3 LTS


On Fri, Oct 27, 2017 at 5:35 AM, Greg Wooledge  wrote:

> On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote:
> > Who's saying it must be installed?
>
> A few people in this thread, though I think they're saying "should"
> rather than "must".
>
> > Maybe I've missed something, but I think
> > the consensus in this discussion was that if you want your resolv.conf
> to be
> > unmanaged/static/administrator-controlled, then don't have resolvconf
> > installed. If you have resolvconf installed, then what's the point of
> > neutering it with a command?
>
> Let's review what we've learned so far.
>
> If you want to make local modifications to /etc/resolv.conf and have
> them stick, here are some ways to do it:
>
> 1) chattr +i /etc/resolv.conf
>
> 2) Individually configure each daemon that might try to modify the file,
>to make it stop doing so.
>
> 3) Install the resolvconf package, because by doing so you also install
>various hacks that modify the behavior of all known Debian daemons,
>stopping them from writing to /etc/resolv.conf.
>
>Then tell resolvconf itself to do nothing by putting resolvconf=NO
>in the /etc/resolvconf.conf file.
>
>


-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Curt]

On 2017-10-27, Greg Wooledge  wrote:
> On Fri, Oct 27, 2017 at 11:03:38AM -0400, Roberto C. Sánchez wrote:
>> I finally got around to updating the wiki page today.  Here is the link
>> for those who wish to have it as a reference or perhaps would like to
>> contribute to further improving it:
>> 
>> https://wiki.debian.org/resolv.conf
>
> I've made a few changes as well.
>
>

Weird wiki. From "my issues" (sic) down it switches from third to
first-person narration by what I suspect is a Germanophone and all hell
breaks loose (grammatically speaking). 

-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Fri, Oct 27, 2017 at 11:03:38AM -0400, Roberto C. Sánchez wrote:
> I finally got around to updating the wiki page today.  Here is the link
> for those who wish to have it as a reference or perhaps would like to
> contribute to further improving it:
> 
> https://wiki.debian.org/resolv.conf

I've made a few changes as well.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:
> 
> In any event, thanks to all who helped and who provided hints on things
> to investigate/try.  Later today I will update the poorly written wiki
> article [0] to explain that immutable is a troubleshooting approach and
> I will add documentation about how to properly configure dhclient when
> changes to /etc/resolv.conf are undesirable.
> 
I finally got around to updating the wiki page today.  Here is the link
for those who wish to have it as a reference or perhaps would like to
contribute to further improving it:

https://wiki.debian.org/resolv.conf

I also made a comment to https://bugs.debian.org/860928 regarding the
temporary files that dhclient leaves cluttering /etc if the mv to
/etc/resolv.conf fails (e.g., because it is immutable).

I also filed https://bugs.debian.org/879949 as a wishlist bug to have
dhclient-script include a header comment in /etc/resolv.conf.

Thanks again to everyone who participated in the thread.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

> Who's saying it must be installed? Maybe I've missed something, but I think
> the consensus in this discussion was that if you want your resolv.conf to be
> unmanaged/static/administrator-controlled, then don't have resolvconf
> installed.

This is a ridiculous idea.  This thread is about a user who doesn't have
resolvconf installed and is bothered by something changing his
resolv.conf.
So clearly, not having resolvconf installed is not a solution.

As I already explained: resolvconf does not modify resolv.conf.  It only
provides a standard way for applications who want to modify resolv.conf
(and who would hence normally just go ahead and modify the file) to do
so in a way that can be controlled.  Hence it gives you the tool that
you need in order to be able to (for example) keep resolv.conf under
manual control.


Stefan

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

>> Granted, it might be nice if resolvconf had an easier way to configure
>> a static setup, but as it is now packages that need to access
>> resolv.conf should do this through resolvconf if it is available, so
>> installing and configuring it *is* the right way to handle this.
> I must argue against it, until as you say, resolvconf is given a well 
> documented way to be told to leave a "static" system alone.

Why would that be a requirement?  As this thread shows, the problem of
resolv.conf being modified occurs without resolvconf: it's not caused by
resolvconf, but rather by its lack.


Stefan

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote:
> 
> Who's saying it must be installed? Maybe I've missed something, but I think
> the consensus in this discussion was that if you want your resolv.conf to be
> unmanaged/static/administrator-controlled, then don't have resolvconf
> installed. If you have resolvconf installed, then what's the point of
> neutering it with a command?
> 
The suggestion was made several times that if I wanted to prevent
/etc/resolv.conf being changed that I needed to first install resolvconf
(this system has never had resolvconf installed) and then configure
resolvconf to not change /etc/resolv.conf.

After much investigation and troubleshooting it turned out to be
dhclient that was modifying /etc/resolv.conf.

Think about that for a minute.  The mere action of an interface (any
interface on the system) obtaining a DHCP lease is sufficient to have
dhclient think it needs to obliterate my manual networking configuration
with settings from the DHCP server.  It clearly assumes that it is the
only thing involved in configuring networking on the system.  This
despite the fact that the system in question has another static
interface onto my LAN and runs bind for my network (which is why I felt
strongly "nameserver 127.0.0.1" is an important option that should be
left alone in /etc/resolv.conf).

In the end it turns out that "resolvconf not installed =/=>
/etc/resolv.conf will remain unmanaged".

> (I realise that there are some packages that come with, say, ENABLED=no in
> /etc/default, but that's usually there because sensible defaults are
> difficult, and the package needs to be configured before use. Not so with
> resolvconf).
> 
Certainly I can understand an argument for resolvconf respecting or not
respecting certain conventions as defaults.  However, the whole point of
the thread that I started was how to figure out what was changing
/etc/resolv.conf when resolvconf wasn't installed in the first place.
It may have reasonable defaults but the available methods for making it
do what I need it to do for my particular situation are inadequate and
involve way too much work.

I mean, even a simple line like this at the top would be such a help:

# This was automatically generated by dhclient (Oct 25 19:03:45 EDT)
# Any changes will be overwritten
# To make this stop consult dhclient-script(8)

In any event, when I get some time in the next days I will update some
pages related to this on the Debian wiki and possibly file a few
wishlist bugs.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote:
> Who's saying it must be installed?

A few people in this thread, though I think they're saying "should"
rather than "must".

> Maybe I've missed something, but I think
> the consensus in this discussion was that if you want your resolv.conf to be
> unmanaged/static/administrator-controlled, then don't have resolvconf
> installed. If you have resolvconf installed, then what's the point of
> neutering it with a command?

Let's review what we've learned so far.

If you want to make local modifications to /etc/resolv.conf and have
them stick, here are some ways to do it:

1) chattr +i /etc/resolv.conf

2) Individually configure each daemon that might try to modify the file,
   to make it stop doing so.

3) Install the resolvconf package, because by doing so you also install
   various hacks that modify the behavior of all known Debian daemons,
   stopping them from writing to /etc/resolv.conf.

   Then tell resolvconf itself to do nothing by putting resolvconf=NO
   in the /etc/resolvconf.conf file.

Re: Why does resolv.conf keep changing?

[Darac Marjal]

On Fri, Oct 27, 2017 at 07:49:29AM -0400, Gene Heskett wrote:

On Friday 27 October 2017 03:46:27 Mart van de Wege wrote:


Roberto C. Sánchez  writes:
> On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
>> Actually, there's no need to duplicate the effort. As I understand
>> it, resolvconf is basically an optional helper program. Software
>> that automatically modifies /etc/resolv.conf should first test for
>> the presence of resolvconf (whether that be checking for the
>> configuration directory of resolvconf or checking that resolvconf
>> is running or... however resolvconf desires to be detected). If
>> resolvconf is available, the changes are co-ordinated through
>> resolvconf, otherwise, /etc/resolv.conf is modified directly.
>
> In my case resolvconf is not installed/available and I want
> resolv.conf to be left alone.  I want any other package that thinks
> it needs to modify resolv.conf to leave it along.

But there *is* a way to do that: install resolvconf.

Granted, it might be nice if resolvconf had an easier way to configure
a static setup, but as it is now packages that need to access
resolv.conf should do this through resolvconf if it is available, so
installing and configuring it *is* the right way to handle this.

Mart


I must argue against it, until as you say, resolvconf is given a well
documented way to be told to leave a "static" system alone.  Until such
time, I'll make /etc/resolv.conf a real file, and mark it
and /etc/network/interfaces immutable.

And frankly, I'm getting tired of the arguments saying it must be
installed. 


Who's saying it must be installed? Maybe I've missed something, but I 
think the consensus in this discussion was that if you want your 
resolv.conf to be unmanaged/static/administrator-controlled, then don't 
have resolvconf installed. If you have resolvconf installed, then what's 
the point of neutering it with a command?


(I realise that there are some packages that come with, say, ENABLED=no 
in /etc/default, but that's usually there because sensible defaults are 
difficult, and the package needs to be configured before use. Not so 
with resolvconf).



Not all machines are lappy's being toted to Micky D's for
connectivity, where it /might/ make some modicum of sense IF it Just
Worked. Here, it didn't just work on a jessie install, took me around an
hour fighting with its local keyboard, to make networking work on the
jessie install, and 15 minutes to make stretch work, but there I wasn't
fighting with a kernel bug that kills keyboards and mice. So it didn't
Just Work on a stretch install.

So until such time as resolv.conf can look at /etc/network/interfaces,
and finding the "static" keyword, leave that interface alone, it will be
nuked on sight with a root rm...

If by the debian 10 release, it must be installed, them MAKE IT WORK.  My
way, so far, does that.

In my experience its a solution looking for a problem, and if it doesn't
find one, it will make one.  It's network-manager by a new name, and
just as worthless.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Friday 27 October 2017 03:46:27 Mart van de Wege wrote:

> Roberto C. Sánchez  writes:
> > On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> >> Actually, there's no need to duplicate the effort. As I understand
> >> it, resolvconf is basically an optional helper program. Software
> >> that automatically modifies /etc/resolv.conf should first test for
> >> the presence of resolvconf (whether that be checking for the
> >> configuration directory of resolvconf or checking that resolvconf
> >> is running or... however resolvconf desires to be detected). If
> >> resolvconf is available, the changes are co-ordinated through
> >> resolvconf, otherwise, /etc/resolv.conf is modified directly.
> >
> > In my case resolvconf is not installed/available and I want
> > resolv.conf to be left alone.  I want any other package that thinks
> > it needs to modify resolv.conf to leave it along.
>
> But there *is* a way to do that: install resolvconf.
>
> Granted, it might be nice if resolvconf had an easier way to configure
> a static setup, but as it is now packages that need to access
> resolv.conf should do this through resolvconf if it is available, so
> installing and configuring it *is* the right way to handle this.
>
> Mart

I must argue against it, until as you say, resolvconf is given a well 
documented way to be told to leave a "static" system alone.  Until such 
time, I'll make /etc/resolv.conf a real file, and mark it 
and /etc/network/interfaces immutable.

And frankly, I'm getting tired of the arguments saying it must be 
installed. Not all machines are lappy's being toted to Micky D's for 
connectivity, where it /might/ make some modicum of sense IF it Just 
Worked. Here, it didn't just work on a jessie install, took me around an 
hour fighting with its local keyboard, to make networking work on the 
jessie install, and 15 minutes to make stretch work, but there I wasn't 
fighting with a kernel bug that kills keyboards and mice. So it didn't 
Just Work on a stretch install.

So until such time as resolv.conf can look at /etc/network/interfaces, 
and finding the "static" keyword, leave that interface alone, it will be 
nuked on sight with a root rm...

If by the debian 10 release, it must be installed, them MAKE IT WORK.  My 
way, so far, does that.

In my experience its a solution looking for a problem, and if it doesn't 
find one, it will make one.  It's network-manager by a new name, and 
just as worthless.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Mart van de Wege]

Roberto C. Sánchez  writes:

> On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
>> 
>> Actually, there's no need to duplicate the effort. As I understand it,
>> resolvconf is basically an optional helper program. Software that
>> automatically modifies /etc/resolv.conf should first test for the presence
>> of resolvconf (whether that be checking for the configuration directory of
>> resolvconf or checking that resolvconf is running or... however resolvconf
>> desires to be detected). If resolvconf is available, the changes are
>> co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
>> directly.
>> 
> In my case resolvconf is not installed/available and I want resolv.conf
> to be left alone.  I want any other package that thinks it needs to
> modify resolv.conf to leave it along.

But there *is* a way to do that: install resolvconf.

Granted, it might be nice if resolvconf had an easier way to configure a
static setup, but as it is now packages that need to access resolv.conf
should do this through resolvconf if it is available, so installing and
configuring it *is* the right way to handle this.

Mart
-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Thursday 26 October 2017 12:13:57 Nicholas Geovanis wrote:

> An interesting, accidental FYI on the subject of the resolvconf
> package: Just now I upgraded an Ubuntu 17.04 test machine which was
> fully upgraded only ten days ago. I see in the pending upgrade details
> that resolvconf is "No longer supported by Canonical" since the
> previous upgrade.
>
Gee, I wonder why, said Gene to no one in particular ;-)

> On Thu, Oct 26, 2017 at 10:54 AM, The Wanderer  
wrote:
> > On 2017-10-26 at 11:35, Glenn English wrote:
> > > On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone 
> >
> > wrote:
> > >> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> > >>> and made immutable. Particularly is the fact that
> > >>> /etc/resolv.conf
> >
> > isn't
> >
> > >>> a link to something else but contains:
> > >>>
> > >>> nameserver 192.168.XX.1
> > >>> search  hostdns
> > >>> domain coyote.den
> > >>
> > >> Please stop posting that, it uses incorrect syntax
> > >
> > > The 'search host dns' line? How do you set that order? I couldn't
> > > find that from a bit of surfing, and I'd like to have name lookups
> > > work in that order...
> >
> > As was explained later on in this thread (and, I presume, would have
> > been explained to Gene previously in other threads), you set that
> > search order in /etc/nsswitch.conf, not in /etc/resolv.conf.
> >
> > 'man nsswitch.conf' documents the file, but all you should probably
> > need to do is look at the existing file, and tweak the 'hosts' line
> > appropriately.
> >
> >
> > If what you want is "search /etc/hosts, then search DNS, then give
> > up", the 'hosts' line you want is:
> >
> > hosts:  files dns
> >
> > There are additional options that might make sense, but that's the
> > most basic form.
> >
> >
> > My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
> > except maybe for a bit of reordering, reads:
> >
> > hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
> >
> > which, according to my understanding, simply adds a few additional
> > types of DNS lookup into the series before giving up.
> >
> > --
> >The Wanderer
> >
> > The reasonable man adapts himself to the world; the unreasonable one
> > persists in trying to adapt the world to himself. Therefore all
> > progress depends on the unreasonable man. -- George Bernard
> > Shaw


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Thursday 26 October 2017 11:35:06 Glenn English wrote:

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  
wrote:
> > On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> >> and made immutable. Particularly is the fact that /etc/resolv.conf
> >> isn't a link to something else but contains:
> >>
> >> nameserver 192.168.XX.1
> >> search  hostdns
> >> domain coyote.den
> >
> > Please stop posting that, it uses incorrect syntax
>
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...
>
That is under the keyword 'search' in the man page, where the confusion 
is about what to put there stems from the rest of that stanza. It obtuse 
and clueless except for a later statement the says search and domain are 
mutually exclusive, using the last option found.

As to what you put in the search line, I haven't a clue. I modified mine 
to:
nameserver 192.168.XX.1
search  coyote.den  nameserver

And ANAICT it made zero difference as it still Just Works(TM).

Someone else has pointed out that this is actually controlled
by nsswitch.conf, which contains:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, 
try:

# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group:  compat
shadow: compat

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

And while I'd not call that man page language swahili, it may be slightly 
better than the  man page for resolv.conf. The operative line above may 
be the "hosts:" line.  I'll leave the study of that man page for those 
search for a solution to a problem they are having. I'll note that the 
debian wheezy supplied file is quite heavily modified when compared to 
the example file in that man page. But no clue as to what problems the 
modifications are intended to fix. There may be more info in the 
ChangeLog.gz for these two files.

I know roughly where those are, but have been up to my eyeballs in a 60 
yo 1kw Gates am radio transmitter the last 2 days, and out of this loop.
The real secret here is that I am of a dying breed in the broadcast 
world, I am one of the folks who actually go on call to fix things like 
transmitters.  Most field engineers just pick up the phone and order a  
new one, for anything from 10G's for a 50 watt nighttime transmitter, to 
a couple million $ for a modern digital tv transmitter.

This one has quite extensive damage to the audio driver pcb brought on by 
it being on a phenolic substrate, and the OEM solder was the same stuff 
RCA used in their TV's circa 1953-54. Darned near pure lead with a need 
to be heated and diluted with more modern, 250F lower melting temp 
solder before it can be removed to gain access to the component lead, 
1/4" of which was bent over, locking it firmly to the board even if the 
solder was melted.

The end result of course is copper traces lifted from the board by the 
excessive heat and loaded with microscopic cracks. I replaced several 
old carbon composition resistors that were way out of tolerance, but the 
final "fix" was a piece of 22 gauge wire connecting the two ends of a 
trace carrying 500 volt on the theory that if the trace was broken 
someplace in the middle, it was now being fed on both sides of the 
break.  And it worked.  That faint thumping you can hear in the 
background, is me pecking on wood for good luck.

A new circuit board has been checked on, it would have to be made, min 
order 3 for around $11,000. So we cobble this one up yet one more time.

But I'm likely both writing swahili to most of you, and boring the whole 
list.  So I'll STFU.

> And Gene,
>
> Removing all write permissions and setting immutable has stopped
> Comcast from trashing my resolv.conf. This week.

Probably for a good long time I suspect.

> Have you looked to see whether the changes are being done by an alien
> (Comcast) or from inside the host?
>
> --
> Glenn English


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 12:31:32PM -0700, Don Armstrong wrote:
> On Thu, 26 Oct 2017, Roberto C. Sánchez wrote:
> > I do have a syslog package installed and running. It is possible I
> > misremembered what was previously logged where, but there is a clear
> > discrepancy between what goes to syslog and what systemd captures:
> 
> [...]
> 
> > In particular, systemd appears to capture this line:
> > 
> > ifup[35433]: mv: cannot move '/etc/resolv.conf.dhclient-new.35546' to
> > '/etc/resolve.conf'
> 
> That's because systemd also captures STDERR, even if that isn't directly
> logged using syslog(). It's one of the rather nice features of systemd.
> 
I've tripped over the different approach systemd takes so many times it
is nice to finally encounter something it does better.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Don Armstrong]

On Thu, 26 Oct 2017, Roberto C. Sánchez wrote:
> I do have a syslog package installed and running. It is possible I
> misremembered what was previously logged where, but there is a clear
> discrepancy between what goes to syslog and what systemd captures:

[...]

> In particular, systemd appears to capture this line:
> 
> ifup[35433]: mv: cannot move '/etc/resolv.conf.dhclient-new.35546' to
> '/etc/resolve.conf'

That's because systemd also captures STDERR, even if that isn't directly
logged using syslog(). It's one of the rather nice features of systemd.

-- 
Don Armstrong  https://www.donarmstrong.com

This isn't life in the fast lane, it's life in the oncoming traffic
 -- Terry Pratchett

Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 11:13 AM, Nicholas Geovanis 
wrote:

> An interesting, accidental FYI on the subject of the resolvconf package:
> Just now I upgraded an Ubuntu 17.04 test machine which was fully upgraded
> only ten days ago. I see in the pending upgrade details that resolvconf is
> "No longer supported by Canonical" since the previous upgrade.
>

I should have mentioned that this is the upgrade to Ubuntu 17.10 incoming.

Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

An interesting, accidental FYI on the subject of the resolvconf package:
Just now I upgraded an Ubuntu 17.04 test machine which was fully upgraded
only ten days ago. I see in the pending upgrade details that resolvconf is
"No longer supported by Canonical" since the previous upgrade.


On Thu, Oct 26, 2017 at 10:54 AM, The Wanderer  wrote:

> On 2017-10-26 at 11:35, Glenn English wrote:
>
> > On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone 
> wrote:
> >
> >> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
> >>>
> >>> and made immutable. Particularly is the fact that /etc/resolv.conf
> isn't
> >>> a link to something else but contains:
> >>>
> >>> nameserver 192.168.XX.1
> >>> search  hostdns
> >>> domain coyote.den
> >>
> >> Please stop posting that, it uses incorrect syntax
> >
> > The 'search host dns' line? How do you set that order? I couldn't find
> > that from a bit of surfing, and I'd like to have name lookups work in
> > that order...
>
> As was explained later on in this thread (and, I presume, would have
> been explained to Gene previously in other threads), you set that search
> order in /etc/nsswitch.conf, not in /etc/resolv.conf.
>
> 'man nsswitch.conf' documents the file, but all you should probably need
> to do is look at the existing file, and tweak the 'hosts' line
> appropriately.
>
>
> If what you want is "search /etc/hosts, then search DNS, then give up",
> the 'hosts' line you want is:
>
> hosts:  files dns
>
> There are additional options that might make sense, but that's the most
> basic form.
>
>
> My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
> except maybe for a bit of reordering, reads:
>
> hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
>
> which, according to my understanding, simply adds a few additional types
> of DNS lookup into the series before giving up.
>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
>

Re: Why does resolv.conf keep changing?

[The Wanderer]

On 2017-10-26 at 11:35, Glenn English wrote:

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  wrote:
>
>> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
>>>
>>> and made immutable. Particularly is the fact that /etc/resolv.conf isn't
>>> a link to something else but contains:
>>>
>>> nameserver 192.168.XX.1
>>> search  hostdns
>>> domain coyote.den
>>
>> Please stop posting that, it uses incorrect syntax
> 
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...

As was explained later on in this thread (and, I presume, would have
been explained to Gene previously in other threads), you set that search
order in /etc/nsswitch.conf, not in /etc/resolv.conf.

'man nsswitch.conf' documents the file, but all you should probably need
to do is look at the existing file, and tweak the 'hosts' line
appropriately.


If what you want is "search /etc/hosts, then search DNS, then give up",
the 'hosts' line you want is:

hosts:  files dns

There are additional options that might make sense, but that's the most
basic form.


My own nsswitch.conf hosts entry, which IIRC is fairly bog-standard
except maybe for a bit of reordering, reads:

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

which, according to my understanding, simply adds a few additional types
of DNS lookup into the series before giving up.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Thu, Oct 26, 2017 at 03:35:06PM +, Glenn English wrote:
> The 'search host dns' line? How do you set that order? I couldn't find
> that from a bit of surfing, and I'd like to have name lookups work in
> that order...

Gene's resolv.conf has this erroneous line that he has been maintaining
for decades.  It does not do what he thinks it does.

If you want to control the order of name lookup sources, that goes in
the /etc/nsswitch.conf file, as described in "man nsswitch.conf".

Re: Why does resolv.conf keep changing?

[Glenn English]

On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone  wrote:
> On Mon, Oct 23, 2017 at 08:31:05PM -0400, Gene Heskett wrote:
>>
>> and made immutable. Particularly is the fact that /etc/resolv.conf isn't
>> a link to something else but contains:
>>
>> nameserver 192.168.XX.1
>> search  hostdns
>> domain coyote.den
>
>
> Please stop posting that, it uses incorrect syntax

The 'search host dns' line? How do you set that order? I couldn't find
that from a bit of surfing, and I'd like to have name lookups work in
that order...

And Gene,

Removing all write permissions and setting immutable has stopped
Comcast from trashing my resolv.conf. This week.

Have you looked to see whether the changes are being done by an alien
(Comcast) or from inside the host?

--
Glenn English

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 09:31:47AM -0500, David Wright wrote:
> 
> Judging by your address and earlier comment, you're much closer to
> Debian's strategy than I am, but I thought the thrust of Debian was
> to coerce/persuade packages to cooperate on /etc/resolv.conf so that
> one package did not overwrite the actions of another on starting,
> and could unroll their own changes when terminating. It's always
> worked here with ifup and dhclient, but that's less complex than
> your own situation using bind. (I use /etc/hosts for my own LAN.)
> 
You make a good point.  However, I think that requiring the user/admin
to implement a hook script in order to reliably get dhclient to do the
right thing is a bit much.  That is why I made the suggestion about the
configuration directive.

> 
> An official hack (Debian) rather than an unofficial one (sys admin)?
> The most remarkable thing in this thread is the alleged defeat of
> chattr +i. (a) it's difficult to believe that some package comes
> along and unsets i (immutable attribute), changes the file, and sets
> i again, which is what you allege. (b) although I agreed with Gene
> that a watch could be left untriggered by i being set, this would
> only happen if a package tried to naively change resolv.conf; the
> behaviour alleged in (a) would still trigger the watch at the time
> i was temporarily unset. (c) the third alternative is failure of
> i to do its job, which seems unlikely.
> 
I had several terminal windows open and I am beginning to suspect that I
was mistaken (at least initially) about having set +i.  In particular,
when I later tried again (possibly for the first time it now seems) I
observed that new temporary files were littered in /etc after the
dhclient-script attempt to overwrite the original /etc/resolv.conf
failed.  I am going to just call it user error on my part.

> So perhaps Debian should just adopt chattr +i as the official way
> of doing what Gene, Greg and you want, with a warning that you
> might want to clean up any clutter (resolv.conf.foo…) periodically.
> Anything that interfered with that could then be filed as a bug.
> 
I do not find this a particularly good solution because it would likely
interfere with managing a system via puppet, ansible, etc.  There is
definitely a use case for "this file should be changeable only by the
administrator, not by any automated functionality from an installed
package."

> BTW did you find out why you were getting DHCP negotiations
> every 3 or 4 minutes? The lease you posted was for 16005 seconds,
> over 4 hours.
> 
I don't recall this being a problem except for when I manually ran
dhclient to force a new negotiation.  I have not observed anything that
makes me think there is an issue with premature renegotiation.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[David Wright]

On Thu 26 Oct 2017 at 07:46:24 (-0400), Roberto C. Sánchez wrote:
> On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> > 
> > Actually, there's no need to duplicate the effort. As I understand it,
> > resolvconf is basically an optional helper program. Software that
> > automatically modifies /etc/resolv.conf should first test for the presence
> > of resolvconf (whether that be checking for the configuration directory of
> > resolvconf or checking that resolvconf is running or... however resolvconf
> > desires to be detected). If resolvconf is available, the changes are
> > co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
> > directly.
> > 
> In my case resolvconf is not installed/available and I want resolv.conf
> to be left alone.  I want any other package that thinks it needs to
> modify resolv.conf to leave it along.  I also think that would be useful
> in the case where resolvconf gets unexpected installed later.  That is
> not a specific concern for me, but in a situation where multiple
> administrators are involved with managing a system it could happen.
> 
> Based on your proposal the situation which I have would not be
> addressed.  I am specifically saying that there should be a way to mark
> resolv.conf as static so that any package that touches it can check for
> that directive.  There is no need for packages to coordinate between
> themselves in that case.  They need only to check for the marker in
> resolv.conf and if it is there (indicating that it should not be
> modified) then they simply discontinue processing.

Judging by your address and earlier comment, you're much closer to
Debian's strategy than I am, but I thought the thrust of Debian was
to coerce/persuade packages to cooperate on /etc/resolv.conf so that
one package did not overwrite the actions of another on starting,
and could unroll their own changes when terminating. It's always
worked here with ifup and dhclient, but that's less complex than
your own situation using bind. (I use /etc/hosts for my own LAN.)

> > The problem is that I don't think that resolvconf can require packages to
> > use it. This is similar to other higher-level APIs such as pulseaudio. If
> > the software knows to use pulseaudio, then it can get mixed, rerouted etc by
> > pulseaudio, but it's difficult to mandate that software stop sending audio
> > directly to /dev/dsp (well, unless you're a distribution which applies
> > patches to upstream software in order to harmonize the experience of its
> > users).
> > 
> 
> I can see the utility of resolvconf and in packages coordinating their
> modifications of resolv.conf.  However, I still maintain that there
> should be a simple way for the admin to mark resolv.conf in such a way
> that no package will modify it.  This should be possible without
> resorting to hacks like making resolv.conf immutable.

An official hack (Debian) rather than an unofficial one (sys admin)?
The most remarkable thing in this thread is the alleged defeat of
chattr +i. (a) it's difficult to believe that some package comes
along and unsets i (immutable attribute), changes the file, and sets
i again, which is what you allege. (b) although I agreed with Gene
that a watch could be left untriggered by i being set, this would
only happen if a package tried to naively change resolv.conf; the
behaviour alleged in (a) would still trigger the watch at the time
i was temporarily unset. (c) the third alternative is failure of
i to do its job, which seems unlikely.

So perhaps Debian should just adopt chattr +i as the official way
of doing what Gene, Greg and you want, with a warning that you
might want to clean up any clutter (resolv.conf.foo…) periodically.
Anything that interfered with that could then be filed as a bug.

BTW did you find out why you were getting DHCP negotiations
every 3 or 4 minutes? The lease you posted was for 16005 seconds,
over 4 hours.

Cheers,
David.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 8:06 AM, Roberto C. Sánchez 
wrote:

>
> Is this the new normal, for things to get captured in some systemd log
> that I cannot grep out of /var/log?


Unfortunately yes.
My experience with Debian 8/9 and more recent Ubuntu is that there is now no
escaping it. One could use instead the SysV init package in Debian, it
seems to be
fully usable in 9, but my management tells me that is not an option.

Roberto C. Sánchez
>
>

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 09:35:03AM -0400, Greg Wooledge wrote:
> On Thu, Oct 26, 2017 at 09:06:09AM -0400, Roberto C. Sánchez wrote:
> > debian:/etc# systemctl status networking
> > [...]
> > Is this the new normal, for things to get captured in some systemd log
> > that I cannot grep out of /var/log?  I specifically recall in the past
> > on older pre-systemd systems that these exchanges between the DHCP
> > client and server would get logged by syslog.
> > 
> > I guess this explains why things that I recalled being logged in the
> > past suddenly disappeared from syslog.
> 
> I seem to have the information in both places.
> 
> wooledg:~$ grep dhclient /var/log/syslog
> Oct 26 08:39:56 wooledg dhclient[514]: DHCPREQUEST of 10.76.172.97 on eth0 to 
> 10.127.1.4 port 67
> Oct 26 08:39:56 wooledg dhclient[514]: DHCPACK of 10.76.172.97 from 10.127.1.4
> Oct 26 08:39:56 wooledg dhclient[514]: bound to 10.76.172.97 -- renewal in 
> 119104 seconds.
> 
> Are you sure you've got rsyslog installed and running?
> 
I do have a syslog package installed and running.  It is possible I
misremembered what was previously logged where, but there is a clear
discrepancy between what goes to syslog and what systemd captures:

debian:/etc# date
Thu Oct 26 09:39:02 EDT 2017
debian:/etc# chattr +i /etc/resolv.conf
debian:/etc# systemctl restart networking
debian:/etc# egrep 'Oct 26 09:39.*dhclient' /var/log/syslog
Oct 26 09:39:10 debian dhclient[35357]: Killed old client process
Oct 26 09:39:11 debian dhclient[35357]: Internet Systems Consortium DHCP Client 
4.3.5
Oct 26 09:39:11 debian dhclient[35357]: Copyright 2004-2016 Internet Systems 
Consortium.
Oct 26 09:39:11 debian dhclient[35357]: All rights reserved.
Oct 26 09:39:11 debian dhclient[35357]: For info, please visit 
https://www.isc.org/software/dhcp/
Oct 26 09:39:11 debian dhclient[35357]:
Oct 26 09:39:11 debian dhclient[35357]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:11 debian dhclient[35357]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:11 debian dhclient[35357]: Sending on   Socket/fallback
Oct 26 09:39:11 debian dhclient[35357]: DHCPRELEASE on eth1 to 192.168.63.1 
port 67
Oct 26 09:39:12 debian dhclient[35528]: Internet Systems Consortium DHCP Client 
4.3.5
Oct 26 09:39:12 debian dhclient[35528]: Copyright 2004-2016 Internet Systems 
Consortium.
Oct 26 09:39:12 debian dhclient[35528]: All rights reserved.
Oct 26 09:39:12 debian dhclient[35528]: For info, please visit 
https://www.isc.org/software/dhcp/
Oct 26 09:39:12 debian dhclient[35528]:
Oct 26 09:39:12 debian dhclient[35528]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian dhclient[35528]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian dhclient[35528]: Sending on   Socket/fallback
Oct 26 09:39:12 debian dhclient[35528]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 7
Oct 26 09:39:19 debian dhclient[35528]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 13
Oct 26 09:39:19 debian dhclient[35528]: DHCPREQUEST of 192.168.63.197 on eth1 
to 255.255.255.255 port 67
Oct 26 09:39:19 debian dhclient[35528]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian dhclient[35528]: DHCPACK of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian dhclient[35528]: bound to 192.168.63.197 -- renewal in 
14309 seconds.
debian:/etc# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
   Active: active (exited) since Thu 2017-10-26 09:39:19 EDT; 56s ago
 Docs: man:interfaces(5)
  Process: 35274 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo 
(code=exited, status=0/SUCCESS)
  Process: 35433 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=0/SUCCESS)
  Process: 35427 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-en
 Main PID: 35433 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 9830)
   CGroup: /system.slice/networking.service
   └─35558 /sbin/dhclient -4 -v -pf /run/dhclient.eth1.pid -lf 
/var/lib/dhcp/dhclient.eth1.leases

Oct 26 09:39:12 debian ifup[35433]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 09:39:12 debian ifup[35433]: Sending on   Socket/fallback
Oct 26 09:39:12 debian ifup[35433]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 7
Oct 26 09:39:19 debian ifup[35433]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 13
Oct 26 09:39:19 debian ifup[35433]: DHCPREQUEST of 192.168.63.197 on eth1 to 
255.255.255.255 port 67
Oct 26 09:39:19 debian ifup[35433]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 09:39:19 debian ifup[35433]: DHCPACK of 192.168.63.197 from 192.168.63.1
Oct 26 09:39:19 debian ifup[35433]: mv: cannot move 
'/etc/resolv.conf.dhclient-new.35546' to '/etc/reso
Oct 26 09:39:19 debian ifup[35433]: bound to 192.168.63.197 -- renewal in 14309 
seconds.
Oct 26 09:39:19 debian systemd[1]: 

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Thu, Oct 26, 2017 at 09:06:09AM -0400, Roberto C. Sánchez wrote:
> debian:/etc# systemctl status networking
> [...]
> Is this the new normal, for things to get captured in some systemd log
> that I cannot grep out of /var/log?  I specifically recall in the past
> on older pre-systemd systems that these exchanges between the DHCP
> client and server would get logged by syslog.
> 
> I guess this explains why things that I recalled being logged in the
> past suddenly disappeared from syslog.

I seem to have the information in both places.

wooledg:~$ grep dhclient /var/log/syslog
Oct 26 08:39:56 wooledg dhclient[514]: DHCPREQUEST of 10.76.172.97 on eth0 to 
10.127.1.4 port 67
Oct 26 08:39:56 wooledg dhclient[514]: DHCPACK of 10.76.172.97 from 10.127.1.4
Oct 26 08:39:56 wooledg dhclient[514]: bound to 10.76.172.97 -- renewal in 
119104 seconds.

Are you sure you've got rsyslog installed and running?

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:
> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
> What it does to it is to replace it with a symlink.
> After that, it doesn't touch it any morel instead it only modifies the file
> that is the target of that symlink.
> 
> So there's your answer:
> - rm /etc/resolv.conf
> - zile /etc/resolv.conf

How is this supposed to prevent dhclient (et al.) from modifying the
file, then?

A quick read of /sbin/dhclient-script shows me nothing promising.
(It's also full of bugs, which is exactly what one expects in a
shell script provided by an OS package, or to be fair, any shell
script at all.)

A quick read of

is... interesting, but low on details.  It doesn't tell me what
resolvconf actually DOES, how it prevents other things from writing
to the file.  But see below.

Hmm... how COULD it work?

Checking  
Aha!  Installing resolvconf creates a file named
/etc/dhcp/dhclient-enter-hooks.d/resolvconf in the dhclient
hooks directory.  Maybe this file overrides the make_resolv_conf
shell function that dhclient-script provides.  I would have to
download and extract the resolvconf package to find out, since I
don't have it installed anywhere.

But what's most interesting to me is this paragraph in the resolvconf
man page:

  In some situations resolvconf needs to act as a deterrent to writing
  to /etc/resolv.conf. Where this file cannot be made immutable or you
  just need to toggle this behaviour, resolvconf can be disabled by
  adding resolvconf=NO to resolvconf.conf(5).

Sounds like chattr +i IS actually the preferred solution.  Installing and
configuring resolvconf is the fallback solution.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:
> 
> As an additional note, it is strange to me that none of the dhclient
> interactions are logged in syslog.  When I ran dhclient directly and
> specified the verbose option, that resulted in the exhanges being logged
> to syslog, except for the error message.  It appears that the scripts
> are not properly capturing/redirecting the standard error stream.  I
> will also investigate if a bug has been filed for that.  If one has not
> been filed I will do that as well.
> 

I sort of stumbled upon something peculiar related to this.

debian:/etc# systemctl restart networking
debian:/etc# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
   Active: active (exited) since Thu 2017-10-26 08:51:35 EDT; 5s ago
 Docs: man:interfaces(5)
  Process: 30299 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo 
(code=exited, status=0/SUCCESS)
  Process: 30455 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=0/SUCCESS)
  Process: 30451 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-en
 Main PID: 30455 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 9830)
   CGroup: /system.slice/networking.service
   └─30573 /sbin/dhclient -4 -v -pf /run/dhclient.eth1.pid -lf 
/var/lib/dhcp/dhclient.eth1.leases

Oct 26 08:51:31 debian ifup[30455]: Listening on LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 08:51:31 debian ifup[30455]: Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Oct 26 08:51:31 debian ifup[30455]: Sending on   Socket/fallback
Oct 26 08:51:31 debian ifup[30455]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 3
Oct 26 08:51:35 debian ifup[30455]: DHCPDISCOVER on eth1 to 255.255.255.255 
port 67 interval 5
Oct 26 08:51:35 debian ifup[30455]: DHCPREQUEST of 192.168.63.197 on eth1 to 
255.255.255.255 port 67
Oct 26 08:51:35 debian ifup[30455]: DHCPOFFER of 192.168.63.197 from 
192.168.63.1
Oct 26 08:51:35 debian ifup[30455]: DHCPACK of 192.168.63.197 from 192.168.63.1
Oct 26 08:51:35 debian ifup[30455]: bound to 192.168.63.197 -- renewal in 16926 
seconds.
Oct 26 08:51:35 debian systemd[1]: Started Raise network interfaces.

Is this the new normal, for things to get captured in some systemd log
that I cannot grep out of /var/log?  I specifically recall in the past
on older pre-systemd systems that these exchanges between the DHCP
client and server would get logged by syslog.

I guess this explains why things that I recalled being logged in the
past suddenly disappeared from syslog.

> Why dhclient-script(8) mentions the hook scripts for overriding the
> behavior of make_resolv_conf() but not the configuration directives that
> can be used to affect specific values is also somewhat puzzling.
> 
Based on comments by Greg and Mike, it seems like the configuration
options are not quite as useful and concrete as I thought, so perhaps it
is better to direct users to the hook script.

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

>> > If Debian developers who are responsible for resolvconf are reading this,
>> > and if they actually CARE about making things work correctly and sensibly,
>> > then here is yet another proposal: give us a way to QUICKLY and EASILY
>> > and RELIABLY tell resolvconf "never do anything".
>> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
>> What it does to it is to replace it with a symlink.
>> After that, it doesn't touch it any morel instead it only modifies the file
>> that is the target of that symlink.
> Given that multiple packages potentially touch/change resolv.conf (at
> least resolvconf and the various DHCP clients),

That is not true: when resolvconf is installed, *no package* should
(modulo bugs) ever change /etc/resolv.conf.

Instead all changes go through resolvconf, which only modifies
/run/resolvconf/resolv.conf (and those changes usually get reflected
into /etc/resolv.conf by making it a symlink to that file, but that's
not mandatory).


Stefan "who thinks resolvconf should always be installed"

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote:
> 
> Actually, there's no need to duplicate the effort. As I understand it,
> resolvconf is basically an optional helper program. Software that
> automatically modifies /etc/resolv.conf should first test for the presence
> of resolvconf (whether that be checking for the configuration directory of
> resolvconf or checking that resolvconf is running or... however resolvconf
> desires to be detected). If resolvconf is available, the changes are
> co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified
> directly.
> 
In my case resolvconf is not installed/available and I want resolv.conf
to be left alone.  I want any other package that thinks it needs to
modify resolv.conf to leave it along.  I also think that would be useful
in the case where resolvconf gets unexpected installed later.  That is
not a specific concern for me, but in a situation where multiple
administrators are involved with managing a system it could happen.

Based on your proposal the situation which I have would not be
addressed.  I am specifically saying that there should be a way to mark
resolv.conf as static so that any package that touches it can check for
that directive.  There is no need for packages to coordinate between
themselves in that case.  They need only to check for the marker in
resolv.conf and if it is there (indicating that it should not be
modified) then they simply discontinue processing.

> The problem is that I don't think that resolvconf can require packages to
> use it. This is similar to other higher-level APIs such as pulseaudio. If
> the software knows to use pulseaudio, then it can get mixed, rerouted etc by
> pulseaudio, but it's difficult to mandate that software stop sending audio
> directly to /dev/dsp (well, unless you're a distribution which applies
> patches to upstream software in order to harmonize the experience of its
> users).
> 

I can see the utility of resolvconf and in packages coordinating their
modifications of resolv.conf.  However, I still maintain that there
should be a simple way for the admin to mark resolv.conf in such a way
that no package will modify it.  This should be possible without
resorting to hacks like making resolv.conf immutable.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Darac Marjal]

On Thu, Oct 26, 2017 at 06:44:44AM -0400, Roberto C. Sánchez wrote:

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:

> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything".

`resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
What it does to it is to replace it with a symlink.
After that, it doesn't touch it any morel instead it only modifies the file
that is the target of that symlink.


Given that multiple packages potentially touch/change resolv.conf (at
least resolvconf and the various DHCP clients), would be very useful is
a directive that can be put inside of resolv.conf that informs all such
packages that the file is not to be modified.  That would allow the
admin to avoid having to hunt down all the different packages and
configure them individually to leave /etc/resolv.conf alone.


Actually, there's no need to duplicate the effort. As I understand it, 
resolvconf is basically an optional helper program. Software that 
automatically modifies /etc/resolv.conf should first test for the 
presence of resolvconf (whether that be checking for the configuration 
directory of resolvconf or checking that resolvconf is running or... 
however resolvconf desires to be detected). If resolvconf is available, 
the changes are co-ordinated through resolvconf, otherwise, 
/etc/resolv.conf is modified directly.


The problem is that I don't think that resolvconf can require packages 
to use it. This is similar to other higher-level APIs such as 
pulseaudio. If the software knows to use pulseaudio, then it can get 
mixed, rerouted etc by pulseaudio, but it's difficult to mandate that 
software stop sending audio directly to /dev/dsp (well, unless you're a 
distribution which applies patches to upstream software in order to 
harmonize the experience of its users).




Regards,

-Roberto

--
Roberto C. Sánchez



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote:
> > If Debian developers who are responsible for resolvconf are reading this,
> > and if they actually CARE about making things work correctly and sensibly,
> > then here is yet another proposal: give us a way to QUICKLY and EASILY
> > and RELIABLY tell resolvconf "never do anything".
> 
> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
> What it does to it is to replace it with a symlink.
> After that, it doesn't touch it any morel instead it only modifies the file
> that is the target of that symlink.
> 
Given that multiple packages potentially touch/change resolv.conf (at
least resolvconf and the various DHCP clients), would be very useful is
a directive that can be put inside of resolv.conf that informs all such
packages that the file is not to be modified.  That would allow the
admin to avoid having to hunt down all the different packages and
configure them individually to leave /etc/resolv.conf alone.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything".

`resolvconf` only touches /etc/resolv.conf when it is installed/initialized.
What it does to it is to replace it with a symlink.
After that, it doesn't touch it any morel instead it only modifies the file
that is the target of that symlink.

So there's your answer:
- rm /etc/resolv.conf
- zile /etc/resolv.conf

The only wrinkle left is that `resolvconf` will regularly check that
/etc/resolv.conf is still a symlink and emit a warning if it is not
(since it's usually the result of a mistake).  To silence this warning
set REPORT_ABSENT_SYMLINK=no in /etc/default/resolvconf.


Stefan

Re: Why does resolv.conf keep changing?

[Don Armstrong]

On Wed, 25 Oct 2017, Gene Heskett wrote:
> Whereas my theory has always been WRT the search line, that it should
> first search the /etc/hosts file for a name match, and failing that,
> query my router, which is running dd-wrt which means its running
> dnsmasq.

This is wrong, and has been wrong for quite some time. /etc/resolv.conf
does not control the order of querying. /etc/nsswitch.conf does.

See nsswitch.conf(5) and resolv.conf(5) for details.

-- 
Don Armstrong  https://www.donarmstrong.com

There is no mechanical problem so difficult that it cannot be solved
by brute strength and ignorance.
 -- William's Law

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Wed, Oct 25, 2017 at 02:49:43PM -0400, Roberto C. Sánchez wrote:
> On Wed, Oct 25, 2017 at 02:34:52PM -0400, Greg Wooledge wrote:
> > This only works on SOME dhcp servers, not all.
> > See 
> 
> So, if I understand your post correctly, if I request a particular
> option from the DHCP server and it provides that option, dhclient will
> respect it.  However, if I do not request a specific option and the
> server sends it anyways, dhclient will ignore the fact that I did not
> request it (based on the configuration) and use it anyways?

Exactly.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 02:34:52PM -0400, Greg Wooledge wrote:
> On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:
> > OK.  I was able to dig into this I resolved the problem by telling
> > dhclient to not request the bits of information that would trigger a
> > change to /etc/resolv.conf.
> 
> > request subnet-mask, broadcast-address, time-offset, routers,
> > #domain-name, domain-name-servers, domain-search, host-name,
> > dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, 
> > dhcp6.sntp-servers,
> > netbios-name-servers, netbios-scope, interface-mtu,
> > rfc3442-classless-static-routes, ntp-servers;
> 
> This only works on SOME dhcp servers, not all.
> See 
> 

So, if I understand your post correctly, if I request a particular
option from the DHCP server and it provides that option, dhclient will
respect it.  However, if I do not request a specific option and the
server sends it anyways, dhclient will ignore the fact that I did not
request it (based on the configuration) and use it anyways?

It makes no sense that dhclient would function that way.  I was
actually going to say, "that sounds like a bug."  However, I can't
convince myself that this isn't by design.

Oh well, a hook script it will have to be then.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[David Wright]

On Wed 25 Oct 2017 at 09:38:54 (-0400), Gene Heskett wrote:
> On Wednesday 25 October 2017 09:19:04 Roberto C. Sánchez wrote:
> 
> > On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote:
> > > Perhaps you could watch the file with inotifywait, and capture
> > > a ps and maybe even a lsof listing at that moment.
> >
> > I have both inotify-hookable and incrond watching the file and the
> > output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of
> > those for any access if resolv.conf (whether read or write) does not
> > show anything related to resolv.conf at all, except for the incron and
> > inotify-hookable processes watching the file.
> >
> > Regards,
> >
> > -Roberto
> 
> And I have a thought.  The immutable bit may be hiding the attempted 
> access from inotifywait because it may be set to only report success at 
> changing the file. I am not familiar with inotify-hookable. But 
> inotifywait has several options so I'd study the man page to see if a 
> different one may be more suitable to catch this perp.  I use it here to 
> tell kmail about incoming mail by triggering on the closing of 
> the /var/spool/mail/name file(s) after procmail has delivered it.  It 
> has worked well for that for at least a decade now.
> 
> But thats not germane to this, only that I am familiar with it to that 
> extent.

I think that is correct. I would assume that the immutable attribution
bit is seen as soon as the directory entry is consulted, whereas the
inode is the item actually being watched for change.

But if the OP is going to unset the attribution, I hope they'll post
the lsattr output first: we've had no evidence posted here that an
immutable file has been modified.

Cheers,
David.

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Michael Stone]

On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:

OK.  I was able to dig into this I resolved the problem by telling
dhclient to not request the bits of information that would trigger a
change to /etc/resolv.conf


Note that this is *not* reliable, as the server may send the information 
anyway, and the client will use whatever information it receives. 
Configuring the hook is a reliable way to prevent the client from ever 
attempting to set resolv.conf.


Mike Stone

Re: [SOLVED] Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Wed, Oct 25, 2017 at 02:26:35PM -0400, Roberto C. Sánchez wrote:
> OK.  I was able to dig into this I resolved the problem by telling
> dhclient to not request the bits of information that would trigger a
> change to /etc/resolv.conf.

> request subnet-mask, broadcast-address, time-offset, routers,
> #domain-name, domain-name-servers, domain-search, host-name,
> dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, 
> dhcp6.sntp-servers,
> netbios-name-servers, netbios-scope, interface-mtu,
> rfc3442-classless-static-routes, ntp-servers;

This only works on SOME dhcp servers, not all.
See 

[SOLVED] Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 10:00:03AM -0400, Roberto C. Sánchez wrote:
> 
> This is clearly evidence that the problem is with dhclient
> (isc-dhcp-client in my case).  I am taking another look at the supersede
> directives in /etc/dhcp/dhclient.conf to make sure that I am specifying
> them correctly.  If that fails, then I think I will need to do something
> with /sbin/dhclient-script (which is apparently what is actually
> changing the resolv.conf).  According to dhclient-script(8) I can use a
> hook to redefine the make_resolv_conf shell function to do nothing.
> 

OK.  I was able to dig into this I resolved the problem by telling
dhclient to not request the bits of information that would trigger a
change to /etc/resolv.conf.  Here the terminal output that shows the
problem and how I fixed it:

debian:/etc# chattr +i /etc/resolv.conf
debian:/etc# grep -C4 '^request' /etc/dhcp/dhclient.conf

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
debian:/etc# dhclient -v -r eth1; dhclient -v eth1
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.63.1 port 67
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
DHCPREQUEST of 192.168.63.197 on eth1 to 255.255.255.255 port 67
DHCPOFFER of 192.168.63.197 from 192.168.63.1
DHCPACK of 192.168.63.197 from 192.168.63.1
mv: cannot move '/etc/resolv.conf.dhclient-new.46741' to '/etc/resolv.conf': 
Operation not permitted
bound to 192.168.63.197 -- renewal in 13589 seconds.
debian:/etc# chattr -i /etc/resolv.conf
debian:/etc# dhclient -v -r eth1; dhclient -v eth1
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.63.1 port 67
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPREQUEST of 192.168.63.197 on eth1 to 255.255.255.255 port 67
DHCPOFFER of 192.168.63.197 from 192.168.63.1
DHCPACK of 192.168.63.197 from 192.168.63.1
bound to 192.168.63.197 -- renewal in 13628 seconds.
debian:/etc# git diff -- resolv.conf
diff --git a/resolv.conf b/resolv.conf
index 2a3d61d..7841009 100644
--- a/resolv.conf
+++ b/resolv.conf
@@ -1,3 +1 @@
-domain example.com
-search example.com.
-nameserver 127.0.0.1
+nameserver 192.168.63.1
debian:/etc# git checkout -- resolv.conf
debian:/etc# sed -i 's/^\tdomain-name/\t#domain-name/' /etc/dhcp/dhclient.conf
debian:/etc# grep -C4 '^request' /etc/dhcp/dhclient.conf

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
#domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
debian:/etc# dhclient -v -r eth1; dhclient -v eth1
Killed old client process
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPRELEASE on eth1 to 192.168.63.1 port 67
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/a0:48:1c:b8:01:d1
Sending on   LPF/eth1/a0:48:1c:b8:01:d1
Sending on   Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 

Re: Why does resolv.conf keep changing?

[rhkramer]

On Wednesday, October 25, 2017 01:06:21 PM to...@tuxteam.de wrote:
> Yeah, hey. But those were MCSEs and network pros. Or something (you aren't
> in charge of ~5K client boxes, are you?)

Nope--just have read too many instructions that didn't clearly delineate what 
was a variable / parameter vs. fixed text or similar. ;-)

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 12:55:01PM -0400, rhkra...@gmail.com wrote:
> On Wednesday, October 25, 2017 09:43:15 AM to...@tuxteam.de wrote:
> > (Don't chuckle. A company I was working at did set its internal "top
> > level domain" to "local". Much hilarity with zeroconf [1] ensued).
> 
> And I'll bet the person that did that was following the instructions he found 
> / was given to the best of his ability.  (I'll bet there were instructions 
> somewhere that said something like "set it to ... local domain".

Yeah, hey. But those were MCSEs and network pros. Or something (you aren't
in charge of ~5K client boxes, are you?)

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwxI0ACgkQBcgs9XrR2kYDxACfeB7tDtrqfarSQNkVNf7wtqyK
xc4Anisq607TFPDnHqhJ2wheX+cCdHRK
=FNWF
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[rhkramer]

On Wednesday, October 25, 2017 09:43:15 AM to...@tuxteam.de wrote:
> (Don't chuckle. A company I was working at did set its internal "top
> level domain" to "local". Much hilarity with zeroconf [1] ensued).

And I'll bet the person that did that was following the instructions he found 
/ was given to the best of his ability.  (I'll bet there were instructions 
somewhere that said something like "set it to ... local domain".

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Wednesday 25 October 2017 11:05:28 Dan Ritter wrote:

> On Wed, Oct 25, 2017 at 07:35:35AM -0400, Gene Heskett wrote:
> > On Tuesday 24 October 2017 23:46:47 Felix Miata wrote:
> > > Gene Heskett composed on 2017-10-24 22:52 (UTC-0400):
> > > >> On Mon, Oct 23, 2017 at 20:31:05 -0400, Gene Heskett wrote:
> > > >>>and made immutable. Particularly is the fact that
> > > >>> /etc/resolv.conf isn't a link to something else but contains:
> > > >>>
> > > >>>nameserver 192.168.XX.1
> > > >>>search hostdns
> > > >>>domain coyote.den
> > >
> > > ...
> >
> > Whereas my theory has always been WRT the search line, that it
> > should first search the  /etc/hosts file for a name match, and
> > failing that, query my router, which is running dd-wrt which means
> > its running dnsmasq.
>
> In order to do that, you want this:
>
> in /etc/nsswitch.conf:
> ...
> hosts:  files dns
> ...
>
> Which is the standard for Debian and basically all other Linux
> distros that I know about.
>
> That tells the DNS resolver to look at /etc/hosts first, and
> then make a DNS query if /etc/hosts does not have an answer.
>
> Note that isn't in resolv.conf, it's in nsswitch.conf.
>
> -dsr-

And mine gives more choices yet. :)
hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 04:01:50PM +0100, Joe wrote:
> On Wed, 25 Oct 2017 15:43:15 +0200
>  wrote:
> 
> 
> > 
> > (Don't chuckle. A company I was working at did set its internal "top
> > level domain" to "local". Much hilarity with zeroconf [1] ensued).
> > 
> 
> That was the standard recommendation for users of MS Small Business
> Server, who were presumed not to be running their own public DNS
> servers, to avoid name problems with externally-hosted websites etc. 

Yes, I think that's where it came from (the folks responsible for the
internal DNS servers (!) have Microsoft background). Whatever "small"
means -- this company has > 5K clients.

> It is an article of faith for MS people that no other operating system
> exists...

Many things don't exist in that bubble.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwrMMACgkQBcgs9XrR2kYZEwCeJ7T0Wxts1l9jBF6BTFEa2ff6
p5wAniW8wWnJidT6JlB40a/otDVE+crA
=hV5e
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Dan Ritter]

On Wed, Oct 25, 2017 at 07:35:35AM -0400, Gene Heskett wrote:
> On Tuesday 24 October 2017 23:46:47 Felix Miata wrote:
> 
> > Gene Heskett composed on 2017-10-24 22:52 (UTC-0400):
> > >> On Mon, Oct 23, 2017 at 20:31:05 -0400, Gene Heskett wrote:
> > >>>and made immutable. Particularly is the fact that /etc/resolv.conf
> > >>> isn't a link to something else but contains:
> > >>>
> > >>>nameserver 192.168.XX.1
> > >>>search   hostdns
> > >>>domain coyote.den
> >
> > ...
> 
> Whereas my theory has always been WRT the search line, that it should 
> first search the  /etc/hosts file for a name match, and failing that, 
> query my router, which is running dd-wrt which means its running 
> dnsmasq.


In order to do that, you want this:

in /etc/nsswitch.conf:
...
hosts:  files dns
...

Which is the standard for Debian and basically all other Linux
distros that I know about.

That tells the DNS resolver to look at /etc/hosts first, and
then make a DNS query if /etc/hosts does not have an answer.

Note that isn't in resolv.conf, it's in nsswitch.conf.

-dsr-

Re: Why does resolv.conf keep changing?

[Joe]

On Wed, 25 Oct 2017 15:43:15 +0200
 wrote:


> 
> (Don't chuckle. A company I was working at did set its internal "top
> level domain" to "local". Much hilarity with zeroconf [1] ensued).
> 

That was the standard recommendation for users of MS Small Business
Server, who were presumed not to be running their own public DNS
servers, to avoid name problems with externally-hosted websites etc. 

It is an article of faith for MS people that no other operating system
exists...

-- 
Joe 

Re: Why does resolv.conf keep changing?

[Curt]

On 2017-10-25,   wrote:
>
> On Wed, Oct 25, 2017 at 09:18:36AM -0400, Michael Stone wrote:
>
> [...]
>
>> >Might be "man resolv.conf".
>> 
>> Can't be, that man page clearly says:
>> 
>>   search Search list for host-name lookup.
>
> [...]
>
>> It certainly doesn't say anything about putting "host" or "dns" or
>> "nameserver" in that line.
>
> Unless your domain name is "host" or "dns", that is. But then you're
> asking for it, I guess :-)
>
> (Don't chuckle. A company I was working at did set its internal "top
> level domain" to "local". Much hilarity with zeroconf [1] ensued).

We did have the person here who host-named his machine localhost, which
may blunt the hilarity somewhat as it does the surprise, the former
often depending on a dose of the latter.

> Cheers
> - -- tomás
>
>


-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 09:24:49AM -0400, Stefan Monnier wrote:
> > I am not willing to accept
> 
> And what are you going to do about that?  Sue us?  Sue Debian Inc. ?
> 
Whoa.  Take it down a notch.  Considering I am a member of the project
itself it would be very counterproductive for me to to have a toxic
attitude towards it.

> > that there is no way to identify what is going on that is causing
> > resolv.conf to change.
> 
I was simply offering a rationale for why I did not find it appropriate
to implement your "solution" yet.  As an engineer, I think it important
to understand the root cause of a problem before proceeding with a
solution, else the solution may not be a good one.

Perhaps a better way for me to state it would have been, "I am not ready
to give up on investigating what is causing resolv.conf to change
unexpectedly.  I would like to understand that before trying to solve
the problem in potentially the wrong way."

> BTW, maybe one way to identify the culprit is:
> - install resolvconf [ I know it sounds bad, but bear with me ].
> - add a script in /etc/resolvconf/update.d, e.g.:
> 
> % cat >/etc/resolvconf/update.d/sm-tracker
> #!/bin/sh
> (date; ps -ef --forest) >>/var/log/sm-tracker.log
> % chmod +x /etc/resolvconf/update.d/sm-tracker
> 
> - let your system run for a while and when resolv.conf changed,
>   look at /var/log/sm-tracker.log to see what process called resolvconf
>   to update /etc/resolv.conf
> 
> You can uninstall resolvconf once you've found the culprit.  Of course,
> this will only work if the culprit has been updated to make use of
> resolvconf when installed, but that should hopefully be the case.
> 
Now, this is a good suggestion.  As it happens, I have already
identified the culprit by stumbling upon temporary files it littered in
/etc, but had I not yet done that this would be a logical next step.
Even more because the inotify suggestion did not pan out and even incron
did not show who was changing resolv.conf.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 09:24:16AM -0400, Gene Heskett wrote:
> 
> All perfectly valid points Greg. I don't know if theres a first language 
> barrier or what,

No barrier.

> but the OP has not been forthcoming with answers to the 
> lists questions. I don't see the need for secrecy when the list needs 
> valid data to make a decent guess, copied and pasted to here from the 
> terminal the OP is using to do whatever the OP is actually doing.

A result of oversight brought on by fatigue.  I have been doing much of
this troubleshooting very late at night.  It is difficult to keep
everything straight in my head, so apologize if my answers/responses to
requests for additional information from the list have been below
expectations.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 09:03:07AM -0400, Greg Wooledge wrote:
> 
> I'm STILL waiting for the OP to give the most basic, fundamental details
> like showing the output of lsattr /etc/resolv.conf to prove that his/her
> assumptions are correct.  IIRC it took two days for us to get proof that
> /etc/resolv.conf wasn't a symlink.
> 
Here you go:

debian:/etc# lsattr /etc/resolv.conf
i-e /etc/resolv.conf

> 
> P.S. All this talk about "mobile devices are the new normal, so we have
> to make everything 20 times as complicated, even for unmoving workstations
> and servers" can go screw itself.
> 
+1

> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything".  I don't care where it
> is, or what it looks like.  Just make SOME way to configure the system so
> that /etc/resolv.conf is never touched in any way by ANYTHING.  Resolvconf

DING! DING! DING! DING! DING! DING! DING!

I THINK WE HAVE A WINNER

> already intercepts all the incoming attempts to modify /etc/resolv.conf
> by dhclient et al., right?  That's its entire purpose, right?  So just

DING! DING! DING! DING! DING! DING! DING!

I THINK WE HAVE A WINNER

> give us a way to tell it to intercept those requests and do nothing.
> 
> If you don't do this, we'll just continue using chattr +i, because that
> does what we want.  (Except for this one person who still hasn't proved
> (s)he actually did it correctly.)
> 

I did the below to see if creating a new resolv.conf and then moving the
old one of the way would allow a new resolv.conf to be installed even
when the immutable flag was set.  Your further mention of dhclient
messing with resolv.conf was the critical piece that I was missing.

debian:/etc# lsattr /etc/resolv.conf
i-e /etc/resolv.conf
debian:/etc# cp /etc/resolv.conf /etc/resolv.conf.new
debian:/etc# lsattr /etc/resolv.conf.
lsattr: No such file or directory while trying to stat /etc/resolv.conf.

# (Note, I expected /etc/resolv.conf.new to be the only other file named
# similarly to /etc/resolv.conf, so I was surprised that shell
# completion failed to choose it automatically.  The next line was after
# I hit tab-tab to see what else was there.)

debian:/etc# lsattr /etc/resolv.conf.
resolv.conf.dhclient-new.18344  resolv.conf.dhclient-new.26388  
resolv.conf.dhclient-new.41226
resolv.conf.dhclient-new.21057  resolv.conf.dhclient-new.28437  resolv.conf.new
debian:/etc# lsattr /etc/resolv.conf.new
--e /etc/resolv.conf.new
debian:/etc# ls -l /etc/resolv.conf*
-rw-r--r-- 1 root root 62 Oct 24 23:14 /etc/resolv.conf
-rw-r--r-- 1 root root 25 Oct 23 11:14 /etc/resolv.conf.dhclient-new.18344
-rw-r--r-- 1 root root 25 Oct 25 03:09 /etc/resolv.conf.dhclient-new.21057
-rw-r--r-- 1 root root 25 Oct 23 14:38 /etc/resolv.conf.dhclient-new.26388
-rw-r--r-- 1 root root 25 Oct 25 06:47 /etc/resolv.conf.dhclient-new.28437
-rw-r--r-- 1 root root 25 Oct 23 18:56 /etc/resolv.conf.dhclient-new.41226
-rw-r--r-- 1 root root 62 Oct 25 09:28 /etc/resolv.conf.new
-rw-r--r-- 1 root root 66 Oct 23 19:29 /etc/resolv.conf~
debian:/etc#  rm -f /etc/resolv.conf.new
debian:/etc# cat /etc/resolv.conf.dhclient-new.18344
nameserver 192.168.63.1
debian:/etc# lsattr /etc/resolv.conf
i-e /etc/resolv.conf
debian:/etc# cat /etc/resolv.conf
domain example.com
search example.com.
nameserver 127.0.0.1

This is clearly evidence that the problem is with dhclient
(isc-dhcp-client in my case).  I am taking another look at the supersede
directives in /etc/dhcp/dhclient.conf to make sure that I am specifying
them correctly.  If that fails, then I think I will need to do something
with /sbin/dhclient-script (which is apparently what is actually
changing the resolv.conf).  According to dhclient-script(8) I can use a
hook to redefine the make_resolv_conf shell function to do nothing.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 09:18:36AM -0400, Michael Stone wrote:

[...]

> >Might be "man resolv.conf".
> 
> Can't be, that man page clearly says:
> 
>   search Search list for host-name lookup.

[...]

> It certainly doesn't say anything about putting "host" or "dns" or
> "nameserver" in that line.

Unless your domain name is "host" or "dns", that is. But then you're
asking for it, I guess :-)

(Don't chuckle. A company I was working at did set its internal "top
level domain" to "local". Much hilarity with zeroconf [1] ensued).

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlnwlPMACgkQBcgs9XrR2kZH8ACePE8XSpmgcc0zRohuHo/JBrAF
QDYAmK9KrKn0rsjYH8vM6HPznysMyek=
=3ixt
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Wednesday 25 October 2017 09:19:04 Roberto C. Sánchez wrote:

> On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote:
> > Perhaps you could watch the file with inotifywait, and capture
> > a ps and maybe even a lsof listing at that moment.
>
> I have both inotify-hookable and incrond watching the file and the
> output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of
> those for any access if resolv.conf (whether read or write) does not
> show anything related to resolv.conf at all, except for the incron and
> inotify-hookable processes watching the file.
>
> Regards,
>
> -Roberto

And I have a thought.  The immutable bit may be hiding the attempted 
access from inotifywait because it may be set to only report success at 
changing the file. I am not familiar with inotify-hookable. But 
inotifywait has several options so I'd study the man page to see if a 
different one may be more suitable to catch this perp.  I use it here to 
tell kmail about incoming mail by triggering on the closing of 
the /var/spool/mail/name file(s) after procmail has delivered it.  It 
has worked well for that for at least a decade now.

But thats not germane to this, only that I am familiar with it to that 
extent.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

> I am not willing to accept

And what are you going to do about that?  Sue us?  Sue Debian Inc. ?

> that there is no way to identify what is going on that is causing
> resolv.conf to change.

BTW, maybe one way to identify the culprit is:
- install resolvconf [ I know it sounds bad, but bear with me ].
- add a script in /etc/resolvconf/update.d, e.g.:

% cat >/etc/resolvconf/update.d/sm-tracker
#!/bin/sh
(date; ps -ef --forest) >>/var/log/sm-tracker.log
% chmod +x /etc/resolvconf/update.d/sm-tracker

- let your system run for a while and when resolv.conf changed,
  look at /var/log/sm-tracker.log to see what process called resolvconf
  to update /etc/resolv.conf

You can uninstall resolvconf once you've found the culprit.  Of course,
this will only work if the culprit has been updated to make use of
resolvconf when installed, but that should hopefully be the case.


Stefan

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Wednesday 25 October 2017 09:03:07 Greg Wooledge wrote:

> On Wed, Oct 25, 2017 at 02:42:49PM +0200, to...@tuxteam.de wrote:
> > Still the open question remains: why is it being changed although
> > the "immutable" attriibute was set?
> >
> > The OP says so, and we must believe that, [...]
>
> I'm STILL waiting for the OP to give the most basic, fundamental
> details like showing the output of lsattr /etc/resolv.conf to prove
> that his/her assumptions are correct.  IIRC it took two days for us to
> get proof that /etc/resolv.conf wasn't a symlink.
>
>
> P.S. All this talk about "mobile devices are the new normal, so we
> have to make everything 20 times as complicated, even for unmoving
> workstations and servers" can go screw itself.
>
> If Debian developers who are responsible for resolvconf are reading
> this, and if they actually CARE about making things work correctly and
> sensibly, then here is yet another proposal: give us a way to QUICKLY
> and EASILY and RELIABLY tell resolvconf "never do anything".  I don't
> care where it is, or what it looks like.  Just make SOME way to
> configure the system so that /etc/resolv.conf is never touched in any
> way by ANYTHING.  Resolvconf already intercepts all the incoming
> attempts to modify /etc/resolv.conf by dhclient et al., right?  That's
> its entire purpose, right?  So just give us a way to tell it to
> intercept those requests and do nothing.
>
> If you don't do this, we'll just continue using chattr +i, because
> that does what we want.  (Except for this one person who still hasn't
> proved (s)he actually did it correctly.)

All perfectly valid points Greg. I don't know if theres a first language 
barrier or what, but the OP has not been forthcoming with answers to the 
lists questions. I don't see the need for secrecy when the list needs 
valid data to make a decent guess, copied and pasted to here from the 
terminal the OP is using to do whatever the OP is actually doing.

To the OP, show code, or it didn't happen is one way to look at it.

None of us are clairvoyant enough to have a crystal ball.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Michael Stone]

On Wed, Oct 25, 2017 at 09:03:07AM -0400, Greg Wooledge wrote:

If Debian developers who are responsible for resolvconf are reading this,
and if they actually CARE about making things work correctly and sensibly,
then here is yet another proposal: give us a way to QUICKLY and EASILY
and RELIABLY tell resolvconf "never do anything".  I don't care where it
is, or what it looks like.  Just make SOME way to configure the system so
that /etc/resolv.conf is never touched in any way by ANYTHING.  Resolvconf
already intercepts all the incoming attempts to modify /etc/resolv.conf
by dhclient et al., right?  That's its entire purpose, right?  So just
give us a way to tell it to intercept those requests and do nothing.


You understand that in most of the cases discussed recently it isn't 
resolvconf changing resolv.conf, it's the dhcp client? One of the 
drivers for resolvconf was to have a central place to configure 
preferences so that people *wouldn't* have to deal with a number of 
other daemons modifying the resolv.conf file and overwriting each other.


Mike Stone

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 02:42:49PM +0200, to...@tuxteam.de wrote:
> 
> Yes. Still the open question remains: why is it being changed although
> the "immutable" attriibute was set?
> 
> The OP says so, and we must believe that, but I've a hard time imagining
> how that happens (whatever program is doing that, let's assume it is
> root, would have first to explicitly revert that attribute).
> 
So, I was fiddling with this again yesterday and I set/reset the
immutable attribute several times.  On the occassions when the file
changed it was when immutable was not set.  I set it again about 10
hours ago and resolv.conf has not changed since then.

I am confident that it was set the first time when I reported that the
file was changed even though I had made it immutable.  That makes me
wonder if some process had an open file descriptor on it.  However,
there was nothing in lsof.  In fact, I have not been able to see any
evidence of any actual process changing resolv.conf except for the
changed file itself.  I never see anything in any of the logs indicating
that something is changing resolv.conf or complaining that it can't.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Michael Stone]

On Wed, Oct 25, 2017 at 01:59:42PM +0200, Alberto Luaces wrote:

Michael Stone writes:


On Wed, Oct 25, 2017 at 12:16:49AM -0400, Gene Heskett wrote:

On Tuesday 24 October 2017 23:02:39 Michael Stone wrote:


On Tue, Oct 24, 2017 at 10:52:03PM -0400, Gene Heskett wrote:
>But since its worked flawlessly for years, please explain what IS
> wrong with it.

We've been over this before. Your "search host dns" line doesn't do
anything at all as written, but will screw things up if copied in a
different order by someone who doesn't know that it's simply broken.


That still doesn't specify what IS wrong. Reading the now 5+ year old man
page, the only change I might make is to change the dns string to
nameserver. IP changed host to hosts too.


What man page? Honestly, it seems like you're making things up at this point.


Might be "man resolv.conf".


Can't be, that man page clearly says:

  search Search list for host-name lookup.
 The search list is normally determined from the local domain name; 
by default,
 it  contains  only  the local domain name.  This may be changed by 
listing the
 desired domain search path following the search keyword with  
spaces  or  tabs
 separating  the names.  Resolver queries having fewer than ndots 
dots (default
 is 1) in them will be attempted using each component of  the  
search  path  in
 turn until a match is found.  For environments with multiple 
subdomains please
 read options ndots:n below to avoid man-in-the-middle attacks and  
unnecessary
 traffic for the root-dns-servers.  Note that this process may be 
slow and will
 generate a lot of network traffic if the servers for the  listed  
domains  are
 not local, and that queries will time out if no server is 
available for one of
 the domains.

It certainly doesn't say anything about putting "host" or "dns" or 
"nameserver" in that line.


Mike Stone

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

>> Also the solution I showed has the advantage that when he stops his
>> bind deamon, he still gets his host names resolved (via the
>> DHCP-provided DNS server).
> Even for shop.coyote.den?

Of course: for all host names he cares to use.

And obviously, his DHCP-provided DNS server will answer with something
like "unknown host" when queried with a host name that's only provided
by the `bind` deamon he just turned off.

But I get the impression I'm misunderstanding the question.


Stefan

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote:
> 
> Perhaps you could watch the file with inotifywait, and capture
> a ps and maybe even a lsof listing at that moment.
> 
I have both inotify-hookable and incrond watching the file and the
output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of
those for any access if resolv.conf (whether read or write) does not
show anything related to resolv.conf at all, except for the incron and
inotify-hookable processes watching the file.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 09:03:07AM -0400, Greg Wooledge wrote:

[...]

> P.S. All this talk about "mobile devices are the new normal, so we have
> to make everything 20 times as complicated, even for unmoving workstations
> and servers" can go screw itself.
> 
> If Debian developers who are responsible for resolvconf are reading this,
> and if they actually CARE about making things work correctly and sensibly,
> then here is yet another proposal: give us a way to QUICKLY and EASILY
> and RELIABLY tell resolvconf "never do anything".

I have no resolvconf. This is one reliable way to tell it to not do
anything :)

That said, dhclient does touch my resolv.conf. I don't particularly
mind (and this thread has proposals on how to change that).

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwjMAACgkQBcgs9XrR2kaXHgCePZ3gEPpmpL/2cYCy7rRdGgLn
CNgAn11yXqHscwksiZvW6Ond4r8RHFBH
=dclj
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Roberto C . Sánchez]

On Wed, Oct 25, 2017 at 12:42:24AM -0400, Stefan Monnier wrote:
> 
> I just gave you a solution to your underlying problem, which *uses* the
> infrastructure rather than fighting it.  I won't force you to use it, tho.
> 
Actually, that is not what you did.  You provided a way to mask the
problem.  If you look at the subject line of my original message it is
"Why does resolv.conf keep changing?"  The problem I am trying to solve
is to identify what on my system keeps changing resolv.conf despite the
fact that I do not have the resolvconf package installed and that I have
attempted every documented option to configure resolv.conf to my
requirements that I could find associated with the network-related
packages I have installed on my system.

I am not willing to accept that there is no way to identify what is
going on that is causing resolv.conf to change.  Once I have figured out
what is chaning resolv.conf and why, then I will be willing to consider
how best to accomplish my objective of keeping resolv.conf configured
the way that suits my needs.

That said, you keep touting that your suggestion sets the nameserver
back to the ISP nameserver when bind is stopped.  That may be an
advantage to you, but it is specifically a behavior that I do not on my
system.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Why does resolv.conf keep changing?

[Greg Wooledge]

On Wed, Oct 25, 2017 at 02:42:49PM +0200, to...@tuxteam.de wrote:
> Still the open question remains: why is it being changed although
> the "immutable" attriibute was set?
> 
> The OP says so, and we must believe that, [...]

I'm STILL waiting for the OP to give the most basic, fundamental details
like showing the output of lsattr /etc/resolv.conf to prove that his/her
assumptions are correct.  IIRC it took two days for us to get proof that
/etc/resolv.conf wasn't a symlink.


P.S. All this talk about "mobile devices are the new normal, so we have
to make everything 20 times as complicated, even for unmoving workstations
and servers" can go screw itself.

If Debian developers who are responsible for resolvconf are reading this,
and if they actually CARE about making things work correctly and sensibly,
then here is yet another proposal: give us a way to QUICKLY and EASILY
and RELIABLY tell resolvconf "never do anything".  I don't care where it
is, or what it looks like.  Just make SOME way to configure the system so
that /etc/resolv.conf is never touched in any way by ANYTHING.  Resolvconf
already intercepts all the incoming attempts to modify /etc/resolv.conf
by dhclient et al., right?  That's its entire purpose, right?  So just
give us a way to tell it to intercept those requests and do nothing.

If you don't do this, we'll just continue using chattr +i, because that
does what we want.  (Except for this one person who still hasn't proved
(s)he actually did it correctly.)

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 08:51:55AM -0400, Stefan Monnier wrote:
> > Yes. Still the open question remains: why is it being changed although
> > the "immutable" attriibute was set?
> 
> I'm not sufficiently familiar with the "immutable" attribute to answer
> that, sorry.

A file set to "immutable" (chattr +i is the command line incantation)
can't be changed (or *removed*), even by root. Only root (more precisely:
a process with the right capabilities) can set or reset this attribute).

I use that often to answer the question "who on earth is changing this
file behind my back?": set to immutable and watch someone whining in
the logs. The result is often to learn how to configure the program
doing the thing to stop doing it, or even to understand the changes
and accept them or have my say in them.

No idea why that fails for the OP.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwi3sACgkQBcgs9XrR2kYmagCfdmyYbiT6nyCNNYuDXeJlBh9X
RzoAnjWgkAMnF7APto7S/Rya6ouxhQxL
=zIlB
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Wednesday 25 October 2017 08:35:56 Stefan Monnier wrote:

> >> I just gave you a solution to your underlying problem, which *uses*
> >> the infrastructure rather than fighting it.  I won't force you to
> >> use it, tho.
> >
> > I thought the canonical method which was discussed in the
>
> Depends on "method to do what?".
>
> A static resolv.conf is basically a concept from the past when mobile
> devices were the exception and there was hence no need for resolv.conf
> to be dynamic.  Nowadays the reverse is true, so we had to change the
> design of the system such that resolv.conf is now dynamic and shared
> between competing uses.  It's easier to use this new infrastructure to
> handle the static case, as I described, than to try and provide some
> way to disable this new infrastructure.
>
> E.g. your solution removes one source of changes to resolv.conf, but
> some other may still be around or may show up in the future and you'll
> be back at square one.
>
> Also the solution I showed has the advantage that when he stops his
> bind deamon, he still gets his host names resolved (via the
> DHCP-provided DNS server).
>
Even for shop.coyote.den? I think not.  That dhcp provided nameserver has 
never in its life seen a coyote.den. It sees and searches ONLY the 
registered names. So blanket statements like that are wrong.

> Anyway, w.r.t "canonical", my solution is taken straight from the
> solution used by dnsmasq_2.76-5+deb9u1_all.deb for that same problem.
> I'd actually expect that the `bind` Debian package provides a similar
> solution ... and indeed the `bind9` package does in /etc/init.d/bind9:
>
> if [ "X$RESOLVCONF" != "Xno" ] && [ -x /sbin/resolvconf ]
> ; then echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.named fi
>
> so maybe all the OP has to do, really, is to install `resolvconf` and
> the problem will be ... resolved (save for the configuration of the
> "search" which he'll have to do by hand, e.g. with
>
> echo "search foo.bar" | resolvconf -a lo.manual
>
> in /etc/rc.local).
>
>
> Stefan


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Joe]

On Wed, 25 Oct 2017 14:16:38 +0200
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, Oct 25, 2017 at 01:06:37PM +0100, Joe wrote:
> > On Wed, 25 Oct 2017 07:35:35 -0400
> > Gene Heskett  wrote:
> > 
> >   
> > > 
> > > Whereas my theory has always been WRT the search line, that it
> > > should first search the  /etc/hosts file for a name match, and
> > > failing that, query my router, which is running dd-wrt which
> > > means its running dnsmasq.
> > >   
> > 
> > Yes, but that information (among other stuff) lives in
> > /etc/nsswitch.conf, not /etc/resolv.conf.
> > 
> > Keep up at the back: why use one configuration file when a couple of
> > dozen will easily do the job?  
> 
> To be fair, those two do quite different things. The one is the
> configuration for the (host name) resolver, whereas the other is
> a configuration for generic name services (which encompasses many
> other things, like user names, protocol names... you name it).
> So nsswitch is "outside" as seen by the resolver.

As I suggested with '(among other stuff)'.
> 
> Of course, one might envision one highly-integrated naming service
> doing "all of that", and that was probably Sun's original vision.
> But things like the DNS are complex (and important) enough that
> they develop a life of their own.

The perennial question of whether a piece of information involving A
and B should be filed under 'A' or under 'B'...

I submit that the name resolution of networked hosts has rather more in
common with other network parameters than with, for example, which
database might be expected to contain user account passwords.

-- 
Joe

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

> Yes. Still the open question remains: why is it being changed although
> the "immutable" attriibute was set?

I'm not sufficiently familiar with the "immutable" attribute to answer
that, sorry.


Stefan

Re: Why does resolv.conf keep changing?

[Nicolas George]

Le quartidi 4 brumaire, an CCXXVI, to...@tuxteam.de a écrit :
> If I give an
> FQDN (e.g. duckduckgo.com), the dots in the host name tell the resolver
> to bypass the search list.

You are wrong on this particular point. If the host name contains dots,
it changes the behaviour of the resolver by having it try the bare
domain first, but then it will try the search list too.

You can check the behaviour using, for example, the following command
line:

strace -e sendmmsg -f -s 1024 socat - tcp:doesnotexist.example:80 |&
  grep --color doesnotexist

With just "doesnotexist", I can see the requests:

doesnotexist.first.search.domain
doesnotexist.second.search.domain
doesnotexist

With doesnotexist.example (or .example.com), the requests are:

doesnotexist.example
doesnotexist.example.first.search.domain
doesnotexist.example.second.search.domain

To inhibit searching in the specified domain, the syntax requires a
final dot: "doesnotexist." or "doesnotexist.example.com.". It is a
little known fact that the dot in DNS domain names is not a separator
but a terminator, and when it is missing it means a possible ellipsis.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 08:35:56AM -0400, Stefan Monnier wrote:
> >> I just gave you a solution to your underlying problem, which *uses* the
> >> infrastructure rather than fighting it.  I won't force you to use it, tho.
> > I thought the canonical method which was discussed in the
> 
> Depends on "method to do what?".
> 
> A static resolv.conf is basically a concept from the past [...]

Yes. Still the open question remains: why is it being changed although
the "immutable" attriibute was set?

The OP says so, and we must believe that, but I've a hard time imagining
how that happens (whatever program is doing that, let's assume it is
root, would have first to explicitly revert that attribute).

Not that I'm proposing that as a permanent solution (see my other post
in this monster thread): rather as a debugging tool.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwhskACgkQBcgs9XrR2kZCZwCeLvy/qi7xKDcCBOjmKA9XtU30
g1QAnR+6o9vUW7/MQLzbwD2NruM9vV7w
=1TwY
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Stefan Monnier]

>> I just gave you a solution to your underlying problem, which *uses* the
>> infrastructure rather than fighting it.  I won't force you to use it, tho.
> I thought the canonical method which was discussed in the

Depends on "method to do what?".

A static resolv.conf is basically a concept from the past when mobile
devices were the exception and there was hence no need for resolv.conf
to be dynamic.  Nowadays the reverse is true, so we had to change the
design of the system such that resolv.conf is now dynamic and shared
between competing uses.  It's easier to use this new infrastructure to
handle the static case, as I described, than to try and provide some way
to disable this new infrastructure.

E.g. your solution removes one source of changes to resolv.conf, but some
other may still be around or may show up in the future and you'll be
back at square one.

Also the solution I showed has the advantage that when he stops his
bind deamon, he still gets his host names resolved (via the
DHCP-provided DNS server).

Anyway, w.r.t "canonical", my solution is taken straight from the
solution used by dnsmasq_2.76-5+deb9u1_all.deb for that same problem.
I'd actually expect that the `bind` Debian package provides a similar
solution ... and indeed the `bind9` package does in /etc/init.d/bind9:

if [ "X$RESOLVCONF" != "Xno" ] && [ -x /sbin/resolvconf ] ; then
echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.named
fi

so maybe all the OP has to do, really, is to install `resolvconf` and
the problem will be ... resolved (save for the configuration of the
"search" which he'll have to do by hand, e.g. with

echo "search foo.bar" | resolvconf -a lo.manual

in /etc/rc.local).


Stefan

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 02:11:21PM +0200, Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXVI, to...@tuxteam.de a écrit :
> >   If I give an
> > FQDN (e.g. duckduckgo.com), the dots in the host name tell the resolver
> > to bypass the search list.
> 
> You are wrong on this particular point. If the host name contains dots,
> it changes the behaviour of the resolver by having it try the bare
> domain first, but then it will try the search list too.

Right. Thanks for that correction.

Still: the mentioned entry should probably not be in resolv.conf, right?

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwgPMACgkQBcgs9XrR2kb8RACeM9z7A5PrtNXA+0DFyexhLm3u
C2YAnjRncPz9orQsom9AsD4O4R6YXo20
=+XfG
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 01:06:37PM +0100, Joe wrote:
> On Wed, 25 Oct 2017 07:35:35 -0400
> Gene Heskett  wrote:
> 
> 
> > 
> > Whereas my theory has always been WRT the search line, that it should 
> > first search the  /etc/hosts file for a name match, and failing that, 
> > query my router, which is running dd-wrt which means its running 
> > dnsmasq.
> > 
> 
> Yes, but that information (among other stuff) lives in
> /etc/nsswitch.conf, not /etc/resolv.conf.
> 
> Keep up at the back: why use one configuration file when a couple of
> dozen will easily do the job?

To be fair, those two do quite different things. The one is the
configuration for the (host name) resolver, whereas the other is
a configuration for generic name services (which encompasses many
other things, like user names, protocol names... you name it).
So nsswitch is "outside" as seen by the resolver.

Of course, one might envision one highly-integrated naming service
doing "all of that", and that was probably Sun's original vision.
But things like the DNS are complex (and important) enough that
they develop a life of their own.

The usual balance between integration and granularity which makes
the engineer's bread and butter, I guess.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwgKYACgkQBcgs9XrR2kYKbACeKWCV5QhtzpCArz4HLTmzN7ig
vYcAnitmadGQZqfCuwvbg14uBlcgj2hm
=jnSe
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Wednesday 25 October 2017 07:36:54 Michael Stone wrote:

> On Wed, Oct 25, 2017 at 12:16:49AM -0400, Gene Heskett wrote:
> >On Tuesday 24 October 2017 23:02:39 Michael Stone wrote:
> >> On Tue, Oct 24, 2017 at 10:52:03PM -0400, Gene Heskett wrote:
> >> >But since its worked flawlessly for years, please explain what IS
> >> > wrong with it.
> >>
> >> We've been over this before. Your "search host dns" line doesn't do
> >> anything at all as written, but will screw things up if copied in a
> >> different order by someone who doesn't know that it's simply
> >> broken.
> >
> >That still doesn't specify what IS wrong. Reading the now 5+ year old
> > man page, the only change I might make is to change the dns string
> > to nameserver. IP changed host to hosts too.
>
> What man page? Honestly, it seems like you're making things up at this
> point.
>
And  if you haven't read the man page, you are too. And I object to being 
called a liar. I may be wrong, and if I am, you'll read it here. Man 
pages as opaque as this one make that wrong possibility lots greater 
than 0. Wanna fix it? First fix the man page so there is no ambiguity.

I might note, and you should too, that all the blathering about here has 
NOT fixed the OP's problem. Something on his system is over-writing his 
resolv.conf, and maybe his /etc/network/interfaces in what, certainly 
something over a week, that something has yet to be found, and finding 
that s/b top priority.

> Mike Stone

man resolv.conf, it carrys a 2012-11-11 date on this uptodate wheezy 
system. I just put stretch on a rock64, and its man page is dated 
2017-03-13. Without doing a diff on those two files, I think they are 
identical. They aren't exactly identical on a blink compare but may as 
well be. Far more text formatting diffs than content diffs. Its still a 
poorly written man page. IMO of course.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Joe]

On Wed, 25 Oct 2017 07:35:35 -0400
Gene Heskett  wrote:


> 
> Whereas my theory has always been WRT the search line, that it should 
> first search the  /etc/hosts file for a name match, and failing that, 
> query my router, which is running dd-wrt which means its running 
> dnsmasq.
> 

Yes, but that information (among other stuff) lives in
/etc/nsswitch.conf, not /etc/resolv.conf.

Keep up at the back: why use one configuration file when a couple of
dozen will easily do the job?

-- 
Joe

Re: Why does resolv.conf keep changing?

[Alberto Luaces]

Michael Stone writes:

> On Wed, Oct 25, 2017 at 12:16:49AM -0400, Gene Heskett wrote:
>>On Tuesday 24 October 2017 23:02:39 Michael Stone wrote:
>>
>>> On Tue, Oct 24, 2017 at 10:52:03PM -0400, Gene Heskett wrote:
>>> >But since its worked flawlessly for years, please explain what IS
>>> > wrong with it.
>>>
>>> We've been over this before. Your "search host dns" line doesn't do
>>> anything at all as written, but will screw things up if copied in a
>>> different order by someone who doesn't know that it's simply broken.
>>>
>>That still doesn't specify what IS wrong. Reading the now 5+ year old man
>>page, the only change I might make is to change the dns string to
>>nameserver. IP changed host to hosts too.
>
> What man page? Honestly, it seems like you're making things up at this point.

Might be "man resolv.conf".

-- 
Alberto

Re: Why does resolv.conf keep changing?

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Oct 25, 2017 at 07:35:35AM -0400, Gene Heskett wrote:
> On Tuesday 24 October 2017 23:46:47 Felix Miata wrote:
> 
> > Gene Heskett composed on 2017-10-24 22:52 (UTC-0400):
> > >> On Mon, Oct 23, 2017 at 20:31:05 -0400, Gene Heskett wrote:
> > >>>and made immutable. Particularly is the fact that /etc/resolv.conf
> > >>> isn't a link to something else but contains:
> > >>>
> > >>>nameserver 192.168.XX.1
> > >>>search   hostdns
> > >>>domain coyote.den

This seems wrong (I know, I'm late to the party). The way I read
resolv.conf's man page (and my hazy memory), "search" lists *domains*
to be appended to the host name to be resolved if that is incomplete.

For example: my resolv.conf has a line

  search lan

(whoever put that in there, but it's irrelevant on my laptop anyway).
If I try to resolve just "foo", the resolver will first try "foo.lan"
(duh, that's most probably wrong), then just "foo". If I give an
FQDN (e.g. duckduckgo.com), the dots in the host name tell the resolver
to bypass the search list.

"host" and "dns" seem like wrong things to put in "search". The search
entry above looks to me like something which should be in /etc/nsswitch.conf,
like

  hosts:  files dns

meaning: "when looking for a host name, look first in /etc/hosts (files),
if that fails turn to the DNS (dns).

As always, I might be wrong.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnwelkACgkQBcgs9XrR2kZAugCeP6rDs/BbSlluH5TXiI4O51qR
f+0AmwZs5iEZlRs0yzj8DB/YcAjm3kSA
=Wg4b
-END PGP SIGNATURE-

Re: Why does resolv.conf keep changing?

[Michael Stone]

On Wed, Oct 25, 2017 at 12:16:49AM -0400, Gene Heskett wrote:

On Tuesday 24 October 2017 23:02:39 Michael Stone wrote:


On Tue, Oct 24, 2017 at 10:52:03PM -0400, Gene Heskett wrote:
>But since its worked flawlessly for years, please explain what IS
> wrong with it.

We've been over this before. Your "search host dns" line doesn't do
anything at all as written, but will screw things up if copied in a
different order by someone who doesn't know that it's simply broken.


That still doesn't specify what IS wrong. Reading the now 5+ year old man
page, the only change I might make is to change the dns string to
nameserver. IP changed host to hosts too.


What man page? Honestly, it seems like you're making things up at this point.

Mike Stone

Re: Why does resolv.conf keep changing?

[Gene Heskett]

On Tuesday 24 October 2017 23:46:47 Felix Miata wrote:

> Gene Heskett composed on 2017-10-24 22:52 (UTC-0400):
> >> On Mon, Oct 23, 2017 at 20:31:05 -0400, Gene Heskett wrote:
> >>>and made immutable. Particularly is the fact that /etc/resolv.conf
> >>> isn't a link to something else but contains:
> >>>
> >>>nameserver 192.168.XX.1
> >>>search hostdns
> >>>domain coyote.den
>
> ...
>
> > Now, since my home net is host file based, about 8 machines and a
> > printer these days, I make resolv.conf into a real file, and
> > once /etc/network/interfaces is similarly setup to work, both are
> > then made immutable, at which point resolvconfig and N-M can be like
> > a steer, try, but cannot tear down a working circuit, that it can
> > never bring back to life despite continueing efforts. Both N-M and
> > resolvconfig are solutions looking for a problem I don't have
> > anymore.
>
> ...
>
> > Your turn Mike, but lets see the facts as to why its wrong, not just
> > an argument for the sake of arguing.  The list doesn't need that, it
> > needs tutorials.
>
> Apparently no one else is interested in tutoring, so I'll offer this:
>
> 1-My LAN is configured essentially the same as yours, including a 2k
> hosts file.
>
> 2-My lines 1 are always the search lines, each starting with the word
> "search", followed by domain(s) to be searched, e.g. "search mylan.net
> coyote.den someother.biz"
>
> 3-My lines 2[3,4,...] are always nameserver lines, containing only the
> string "nameserver" followed by one IPV4 address.
>
> 4-I have no lines starting with string "domain", but as a result of
> this thread, that may soon change.
>
> NAICT from the man page, Mike's objection to yours is your search line
> should contain neither the string "dns" nor the string "host", and
> probably ought to contain at least the string "coyote.den" following
> the string "search".

Whereas my theory has always been WRT the search line, that it should 
first search the  /etc/hosts file for a name match, and failing that, 
query my router, which is running dd-wrt which means its running 
dnsmasq.

Now, if dnsmasq doesn't have it in its cache, then the router will query 
the dns server that it obtained from the isp via its dhcp session with 
the isp.

Frankly, "man resolv.conf" is one of the poorer man pages we have. 
Without covering the fundamentals, it wastes 8 kilobytes on options most 
folks don't know or care about.

Quite a ways down the page, I see this:

"The domain and search keywords are mutually exclusive.  If more than one 
instance of these keywords is present, the last instance wins."

Other stanza's seem to say I should replace 'hosts' with the local domain 
name, 'coyote.den' as the first argument to the search keyword. And I 
cannot tell if its doing anything different, I changed it and restarted 
my networking without disturbing the ssh sessions opened to the other 
machines, they are still up and accessable w/o logging in a new session, 
and I can still ping yahoo in 112ms.

A partial cat of /etc/network/interfaces:

auto eth0
# regular network for coyote.den
iface eth0 inet static
address 192.168.XX.3
netmask 255.255.255.0
gateway 192.168.XX.1
dns-nameserver 192.168.XX.1

That also has the immutable bit set.

The only thing I see of any concern is that since the last reboot, 
ifconfig says there has been 946 overrun errors, but total traffic has 
been nearly 200 GB in the last 27 days 9 hours of uptime. For some 
installations thats likely miniscule.

Which is 100% correct? From the ambiguity and obtuseness of that man 
page, without any hint of a 'correct' example to be found it it, 
damnedifIknow.  All I do know is that it Just Works(TM).  And still does 
after changing it just now. And except for the router, not an active 
dhcpd on the property. Any machine can access any other local machine 
via ssh, or even sshfs, and any machine can fire up a browser and go net 
crawling.

Isn't that how its supposed to work?

Thanks Felix.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Why does resolv.conf keep changing?

[Michael Stone]

On Tue, Oct 24, 2017 at 11:46:47PM -0400, Felix Miata wrote:

2-My lines 1 are always the search lines, each starting with the word "search",
followed by domain(s) to be searched, e.g. "search mylan.net coyote.den
someother.biz"

[...]

4-I have no lines starting with string "domain", but as a result of this thread,
that may soon change.


In general, you should not have a domain line; it has very little 
purpose these days, and is basically "search" that only allows one 
search domain. If you have both "domain" and "search" they turn each 
other off, so only the last one in the file does anything.


Mike Stone