Why does resolv.conf keep changing?

[Roberto C. Sánchez]

So, I just upgraded my main router/firewall machine to Stretch.
Following the upgrade my /etc/resolv.conf settings appear to track the
DHCP options obtained by one of the two interfaces. No matter what I
try I can't get the /etc/resolv.conf settings to remain as I would like
them.

The machine has two network interfaces: one on the Internt side which
connects to my ISP-provided equipment and which obtains its address via
DHCP, another on the LAN side which is statically configured.

My /etc/network/interfaces looks like this (192.168.174.0/24 is my LAN
subnet):

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.174.1
netmask 255.255.255.0
broadcast 192.168.174.255

auto eth1
iface eth1 inet dhcp

My /etc/resolv.conf looks like this:

domain example.com
search example.com.
nameserver 127.0.0.1

The reason for "nameserver 127.0.0.1" is that I run my own instance of
bind which acts as a caching server and also serves my own internal
zones. Prior to the recent upgrade to Stretch everything worked
normally. That is, whatever I put in /etc/resolv.conf was left as I
configured it. Following my recent Stretch upgrade I found my
resolv.conf had been changed to just this (192.168.63.1/24 is the subnet
used by the ISP equipment):

nameserver 192.168.63.1

That has the effect of not allowing processes running on that machine
(the router/firewall) to properly resolve internal DNS addresses. Other
machines on my network are fine since they get their name servers set by
the internal DHCP server which is configured with the name server
address 192.168.174.1. This DHCP server is different from the embedded
DHCP server that runs on my ISP's device.

I have tried two different things. First, I added this directive to
/etc/network/interfaces under the eth0 stanza:

dns-nameservers 127.0.0.1

That did not appear to have any effect because taking eth0 and eth1 down
and then bringing them back up still results in resolv.conf pointing to
the ISP router as its name server. Additionally, after the interfaces
are up even if I manually change resolv.conf, something comes along
sometime later and undoes my changes.

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.

I did find a page on the Debian wiki [0] which recommends setting the
immutable attribute on /etc/resolv.conf. However, that feels like an
ugly hack.

Can anyone point out what it is that I am missing here?

Regards,

-Roberto

[0] https://wiki.debian.org/resolv.conf

--
Roberto C. Sánchez

[Joe]

It most certainly is, and shouldn't be necessary in your case.

> Can anyone point out what it is that I am missing here?

Not 'missing', you probably have the package resolvconf installed, and
with your network configuration, you don't need it. It's not certain,
but it seems to be the culprit in most of these cases. There is
undoubtedly a way to beat it into submission, but it's not widely
known. There was another recent thread on this matter.

If you're bringing up and taking down random interfaces, such as VPN
tunnels and wifi, then you do want to keep shifting your DNS server, so
resolvconf is appropriate on a laptop, but probably not on a fixed
workstation.

--
Joe

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote:
> On Sun, 22 Oct 2017 22:12:03 -0400
> Roberto C. Sánchez <rob...@debian.org> wrote:

[...]

> > I did find a page on the Debian wiki [0] which recommends setting the
> > immutable attribute on /etc/resolv.conf. However, that feels like an
> > ugly hack.
> >
>
> It most certainly is, and shouldn't be necessary in your case.

I've used that approach sometimes and regularly recommend it.

That said, my main intention is to *debug* the problem, i.e. to
provoke an error message in some log file or whatever, to learn which
process is (undesirably?) mutating some file. Most of the time this
leads to learning some config option to not do that mutation in the
first place (or to some understanding on why that mutation is a Good
Thing after all and to a better way of solving my real, underlying
problem).

Only in exceptional cases I had to "leave in" the immutable attribute
as a permanent "solution".

(as to the rest, yeah, resolvconf seems a worthy candidate).

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

iEYEARECAAYFAlnttXEACgkQBcgs9XrR2kbeIwCeJ1IyTwgJjRt/URyUIrhhFfyp
+KwAn3HyMZ9UO1tGAaljQeD2zxTMU3p7
=JeQl
-----END PGP SIGNATURE-----

[Jörg-Volker Peetz]

Roberto C. Sánchez wrote on 10/23/17 04:12:
<snip>

> I have tried two different things. First, I added this directive to
> /etc/network/interfaces under the eth0 stanza:
>
> dns-nameservers 127.0.0.1
>
> That did not appear to have any effect because taking eth0 and eth1 down
> and then bringing them back up still results in resolv.conf pointing to
> the ISP router as its name server. Additionally, after the interfaces
> are up even if I manually change resolv.conf, something comes along
> sometime later and undoes my changes.

On testing with resolvconf the parameter in /etc/network/interfaces is
dns-nameserver 127.0.0.1

without trailing 's'.

Regards,
jvp.

[Roberto C. Sánchez]

On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote:

Ah yes, I forgot to mention that. I do not have resolvconf installed:

debian:/etc# apt-cache policy resolvconf
resolvconf:
Installed: (none)
Candidate: 1.79
Version table:
1.79 500
500 http://ftp.us.debian.org:3142/debian stretch/main amd64 Packages

> If you're bringing up and taking down random interfaces, such as VPN
> tunnels and wifi, then you do want to keep shifting your DNS server, so
> resolvconf is appropriate on a laptop, but probably not on a fixed
> workstation.
>

I agree. I make sure to only install resolvconf on my laptops since
those are the only machines I have that move from one network to
another.

Regards,

-Roberto

--
Roberto C. Sánchez

[Greg Wooledge]

On Mon, Oct 23, 2017 at 11:48:36AM -0400, Jude DaShiell wrote:
> If you've got dynamic ip addresses as many of us do, that file has to change
> to keep your internet connection up.

That's not true. The resolv.conf file does not necessarily have
to change when your IP addresses change. The primary example of a
non-changing resolv.conf would be someone running a local resolver
listening on 127.0.0.1 -- exactly like the original poster's case.

[Jude DaShiell]

If you've got dynamic ip addresses as many of us do, that file has to
change to keep your internet connection up.

On Mon, 23 Oct 2017, Joe wrote:

> Date: Mon, 23 Oct 2017 04:17:11
> From: Joe <j...@jretrading.com>
> To: debia...@lists.debian.org
> Subject: Re: Why does resolv.conf keep changing?
> Resent-Date: Mon, 23 Oct 2017 08:54:41 +0000 (UTC)
> Resent-From: debia...@lists.debian.org

[Gene Heskett]

On Monday 23 October 2017 11:48:36 Jude DaShiell wrote:

> If you've got dynamic ip addresses as many of us do, that file has to
> change to keep your internet connection up.
>

This true, but all the isp's I have dealt with over the last 23 years,
have all assigned that dynamic address BASED on the MAC of the device
doing the requesting. So while my router(s) do use dhcp to get its
internet address, I can even swap routers as long as I clone the
originals MAC address into the replacement.

So my web page, (see the sig) which is on this machine, has for the most
part just worked for much of a decade now. There hasn't been zero
downtime of course, perhaps .01% of the time.

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 <http://geneslinuxbox.net:6309/gene>

[Dan Ritter]

On Mon, Oct 23, 2017 at 05:03:30PM -0400, Gene Heskett wrote:
> On Monday 23 October 2017 11:48:36 Jude DaShiell wrote:
>
> > If you've got dynamic ip addresses as many of us do, that file has to
> > change to keep your internet connection up.
> >
> This true, but all the isp's I have dealt with over the last 23 years,
> have all assigned that dynamic address BASED on the MAC of the device
> doing the requesting. So while my router(s) do use dhcp to get its
> internet address, I can even swap routers as long as I clone the
> originals MAC address into the replacement.
>

You're conflating two different things, Gene.

DHCP assigns a dynamic IP address. That's the main job. And it
will provide a default router along with that. The original
poster wants that.

It also has lots of optional bits of data that it can provide,
but doesn't have to. Among those:

- DNS server addresses
- default domain names
- NTP servers
- TFTP servers
- NFS servers

The original poster does not want their machine to pay attention
to any of that, even if it is supplied.

The full list, I think, is a little overwhelming:

https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

-dsr-

[Roberto C. Sánchez]

On Mon, Oct 23, 2017 at 11:25:05AM +0200, to...@tuxteam.de wrote:
> On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote:
> > On Sun, 22 Oct 2017 22:12:03 -0400
> > Roberto C. Sánchez <rob...@debian.org> wrote:
>
> [...]
>
> > > I did find a page on the Debian wiki [0] which recommends setting the
> > > immutable attribute on /etc/resolv.conf. However, that feels like an
> > > ugly hack.
> > >
> >
> > It most certainly is, and shouldn't be necessary in your case.
>
> I've used that approach sometimes and regularly recommend it.
>
> That said, my main intention is to *debug* the problem, i.e. to
> provoke an error message in some log file or whatever, to learn which
> process is (undesirably?) mutating some file. Most of the time this
> leads to learning some config option to not do that mutation in the
> first place (or to some understanding on why that mutation is a Good
> Thing after all and to a better way of solving my real, underlying
> problem).
>
> Only in exceptional cases I had to "leave in" the immutable attribute
> as a permanent "solution".
>

So, I edited resolv.conf to my preference and then made it immutable
with `chattr +i /etc/resolv.conf`. Several hours later the name server
was changed back to the ISP router's address. That is very odd. Yet
even more odd is that this time the domain and search options were left
untouched. Previously, the domain and search would get wiped (because
the ISP router doesn't push those options).

The plot thickens.

[David Wright]

So if you:
$ ls -l --full-time /etc/resolv.conf
and then look at what happened at that precise time in /var/log/syslog
or wherever your logs are being written. What took place?

Cheers,
David.

[Gene Heskett]

Having looked at the dhcpd code quite some time back, "its complex" is a
gross understatement. But if the OP wants access, his router HAS to use
the address the ISP assigns. Here, my local net is entirely hard coded
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 host dns
domain coyote.den

And is made immutable.

Where XX is the block in class D that is mine.

[Roberto C. Sánchez]

On Mon, Oct 23, 2017 at 07:26:38PM -0500, David Wright wrote:
>
> So if you:
> $ ls -l --full-time /etc/resolv.conf
> and then look at what happened at that precise time in /var/log/syslog
> or wherever your logs are being written. What took place?
>

Most recently the problem happened at 22:29:16.419070807. Looking in
all of my logs (not just syslog), the only thing that happened near that
time was that a host on my LAN sent a DHCPREQUEST at 22:29:07 (which the
DHCP server answered with a DHCPACK) and then at 22:29:58 Shorewall
dropped an attempt to connect to port 2433 from a host on the Internet.

I have already changed resolv.conf back to my preferred configuration
and I will check again for correlated log entries when it is changed
again.

[Roberto C. Sánchez]

So, it happened again at 03:02:26 that resolv.conf was changed. I
looked in the logs and found nothing that appeared to be a close
correlation. There were several DHCPREQUEST/DHCPACK exchanges before
and after, but my network has a near constant stream of such exchanges
with no more than 3 or 4 minutes between exchanges. It seems unlikely
to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit.

I am fairly out of ideas at this point. Anyone?

[Greg Wooledge]

On Mon, Oct 23, 2017 at 07:33:01PM -0400, Roberto C. Sánchez wrote:
> So, I edited resolv.conf to my preference and then made it immutable
> with `chattr +i /etc/resolv.conf`. Several hours later the name server
> was changed back to the ISP router's address. That is very odd.

ls -ld /etc/resolv.conf

On Tue, Oct 24, 2017 at 03:15:30AM -0400, Roberto C. Sánchez wrote:
> > > So if you:
> > > $ ls -l --full-time /etc/resolv.conf
> > > and then look at what happened at that precise time in /var/log/syslog
> > > or wherever your logs are being written. What took place?

And what does the ls actually SHOW?

> So, it happened again at 03:02:26 that resolv.conf was changed.

ls -ld /etc/resolv.conf

If it's a SYMLINK and you made the symlink immutable, well, that would
explain a whole lot.

[Roberto C. Sánchez]

It is not a symlink:

debian:/etc# ls -l --full-time /etc/resolv.conf
-rw-r--r-- 1 root root 25 2017-10-24 07:07:54.513938427 -0400 /etc/resolv.conf
debian:/etc# file /etc/resolv.conf
/etc/resolv.conf: ASCII text

[David Wright]

Here, with resolvconf installed, resolv.conf is updated to within
one second of the DHCPREQUEST/DHCPACK exchange. I only get these
exchanges every few minutes when this laptop is misbehaving (the
wifi is flaky and the signal strength gets low). Normally it's
ten or twelve hours which I assume is when the lease expires.

> I am fairly out of ideas at this point. Anyone?

Perhaps you could watch the file with inotifywait, and capture
a ps and maybe even a lsof listing at that moment.

Cheers,
David.

[Curt]

On 2017-10-24, Roberto C Sánchez <rob...@debian.org> wrote:
>>
>> If it's a SYMLINK and you made the symlink immutable, well, that would
>> explain a whole lot.
>
> It is not a symlink:
>
> debian:/etc# ls -l --full-time /etc/resolv.conf
> -rw-r--r-- 1 root root 25 2017-10-24 07:07:54.513938427 -0400 /etc/resolv.conf
> debian:/etc# file /etc/resolv.conf
> /etc/resolv.conf: ASCII text

Of course you're certain the file indeed has the immutable attribute
(lsattr) set, in which case I wonder vaguely to myself how it could be
possible for the file to have been subsequently modified.

The plot sickens.

> Regards,
>
> -Roberto
>


--
"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.

[Roger Lynn]

On 24/10/17 08:20, Roberto C. Sánchez wrote:
> So, it happened again at 03:02:26 that resolv.conf was changed. I
> looked in the logs and found nothing that appeared to be a close
> correlation. There were several DHCPREQUEST/DHCPACK exchanges before
> and after, but my network has a near constant stream of such exchanges
> with no more than 3 or 4 minutes between exchanges. It seems unlikely
> to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit.
>
> I am fairly out of ideas at this point. Anyone?

Did you remove the resolvconf package, which is responsible for updating
resolv.conf in dynamic networking environments?

Roger

[Michael Stone]

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 host dns
>domain coyote.den

Please stop posting that, it uses incorrect syntax (as has been
explained to you before) and it would be a shame if other people copied
it as a correct example.

Mike Stone

[Roberto C. Sánchez]

https://lists.debian.org/debian-user/2017/10/msg00787.html

--
Roberto C. Sánchez

[Gene Heskett]

Mike, I think you said that before, but didn't correct it ATT, but I
wrote it while referencing the man page for resolv.conf. And I
rechecked it against the man page a few weeks ago after the last
callout.

It might not be correct, man pages have been wrong before, and will be
again.

But since its worked flawlessly for years, please explain what IS wrong
with it. Just saying its wrong doesn't cut it in the face of the fact
that I did it in self-defense against NM back when NM first came out,
what, a decade ago and was not then removeable with anything but a root
session of rm. The package managers insisted on gutting the system if
you wanted it gone back then.

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.

Fortunately, both of these so-called solutions have the good sense to NOT
spam the logs when they find they've been emasculated.

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.

[Michael Stone]

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.

>Just saying its wrong doesn't cut it in the face of the fact
>that I did it in self-defense against NM back when NM first came out,
>what, a decade ago and was not then removeable with anything but a root
>session of rm. The package managers insisted on gutting the system if
>you wanted it gone back then.

Really, rants about something that may or may not have happened 10 years
ago are just a waste of time.

If you're looking for instructions on how to use resolvconf, others have
posted it in the recent past. Since you seem to just want to complain
about it, I'm not sure what else to offer.

Mike Stone

[Stefan Monnier]

> My /etc/resolv.conf looks like this:

> domain example.com
> search example.com.
> nameserver 127.0.0.1

Here's how I'd do it:
- install resolvconf
- move the resolv.conf config you use with bind to somewhere else, like
/etc/resolv.conf.bind
- arrange for the script which starts your `bind` server to do:

resolvconf -a lo.bind </etc/resolv.conf.bind

- furthermore arrange to run

resolvconf -d lo.bind

when bind is stopped.

`resolvconf` is designed to handle situations like these where there are
DNS configs from various places which all fight for the control of
/etc/resolv.conf. The "lo.bind" is the name corresponding more or less
to the interface over which the info is served, and `resolvconf` uses
that info to enforce some priority between the different sources
of info.

With such a setup, your host should correctly use your local `bind`
server, and if you ever stop your `bind` server it should start using
your ISP's server instead. And when you restart your `bind` server, it
will switch back to using that.


Stefan

[Felix Miata]

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 host dns
>>>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".
--
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Roberto C. Sánchez]

On Tue, Oct 24, 2017 at 11:44:59PM -0400, Stefan Monnier wrote:
>
> With such a setup, your host should correctly use your local `bind`
> server, and if you ever stop your `bind` server it should start using
> your ISP's server instead. And when you restart your `bind` server, it
> will switch back to using that.
>

That is not at all what I am trying to accomplish. I simply want
resolv.conf to be left alone. As I do not have resolvconf even
installed, I don't think I am asking too much.

[Gene Heskett]

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.

My local network now pings at the same elapsed times as before. Shrug.

> >Just saying its wrong doesn't cut it in the face of the fact
> >that I did it in self-defense against NM back when NM first came out,
> >what, a decade ago and was not then removeable with anything but a
> > root session of rm. The package managers insisted on gutting the
> > system if you wanted it gone back then.
>
> Really, rants about something that may or may not have happened 10
> years ago are just a waste of time.
>

Is it? When I see victims of this stuff posting weekly on every machine
list I'm on and you folks can't solve their problems, what exactly am I
supposed to think? If it waddles and quacks like a duck, it probably is
a duck.

> If you're looking for instructions on how to use resolvconf, others
> have posted it in the recent past. Since you seem to just want to
> complain about it, I'm not sure what else to offer.

What you are missing is that there is more than one way to skin a cat,
and I prefer the simplest, and fastest way. Eg, hard code it, make it
immutable, and get on with the real work. I just scanned my network, and
only one machine, an r-pi-3b actually has a resolvconf man page, its
running jessie. A recent stretch install on a rock64 probably needs the
man pages installed. However, the executable has not been found by
locate. I'm outta here for some zz's.

> Mike Stone

[Stefan Monnier]

>> With such a setup, your host should correctly use your local `bind`
>> server, and if you ever stop your `bind` server it should start using
>> your ISP's server instead. And when you restart your `bind` server, it
>> will switch back to using that.
> That is not at all what I am trying to accomplish. I simply want
> resolv.conf to be left alone. As I do not have resolvconf even
> installed, I don't think I am asking too much.

Don't worry, you can ask whatever you want and I won't judge if it's too
much or too little: It's not like I (nor anyone else for that matter)
have to provide you with what you want, anyway.

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.


Stefan

[Curt]

I thought the canonical method which was discussed in the
long thread here recently was to use hooks:

Create a file 'disable_make_resolv_conf'

/etc/dhcp/dhclient-enter-hooks.d/disable_make_resolv_conf

with the following

#!/bin/sh
make_resolv_conf(){
exit 0
}

which does precisely nothing. Make it executable.

[Gene Heskett]

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.

[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

[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

[to...@tuxteam.de]

-----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 host dns
> > >>>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-----

[Joe]

On Wed, 25 Oct 2017 07:35:35 -0400
Gene Heskett <ghes...@shentel.net> 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

[Alberto Luaces]

Might be "man resolv.conf".

--
Alberto

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----

[to...@tuxteam.de]

-----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-----

[Gene Heskett]

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.

[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

[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

[to...@tuxteam.de]

-----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-----

[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

[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

[Joe]

On Wed, 25 Oct 2017 14:16:38 +0200
<to...@tuxteam.de> 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 <ghes...@shentel.net> 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

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----

[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.

[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.)

[to...@tuxteam.de]

-----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-----

[Gene Heskett]

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.

[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

[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.

[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

[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.

[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

[Michael Stone]

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

[Gene Heskett]

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.

[to...@tuxteam.de]

-----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-----

[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.

[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.

[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.

[Curt]

On 2017-10-25, <to...@tuxteam.de> <to...@tuxteam.de> 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.

[Joe]

On Wed, 25 Oct 2017 15:43:15 +0200
<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).
>

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

[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 host dns
> > >>>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-

[to...@tuxteam.de]

-----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
> <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).
> >
>
> 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-----

[Gene Heskett]

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

[rhkr...@gmail.com]

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".

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----

[rhkr...@gmail.com]

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. ;-)

[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 interval 6
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 16005 seconds.
debian:/etc# git diff -- resolv.conf
(no output here shows that resolv.conf was not changed)

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.

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.

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.

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.

Regards,

-Roberto

[0] https://wiki.debian.org/resolv.conf

--
Roberto C. Sánchez

[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 <https://lists.debian.org/debian-user/2017/08/msg00087.html>

[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

[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.

[Roberto C. Sánchez]

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.

[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 <https://lists.debian.org/debian-user/2017/08/msg00087.html>
>
> 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.

[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

[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

[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.

[Darac Marjal]

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.

[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.

[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"

[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

[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
<https://manpages.debian.org/stretch/openresolv/resolvconf.8.en.html>
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 <https://packages.debian.org/stretch/all/resolvconf/filelist> ....
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.

[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?

[Roberto C. Sánchez]

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]: Started Raise network interfaces.

In particular, systemd appears to capture this line:

ifup[35433]: mv: cannot move '/etc/resolv.conf.dhclient-new.35546' to
'/etc/resolve.conf'

That line is not anywhere in syslog. As you pointed out in another
post, dhclient-script is riddled with bugs. The blind use of 'mv -f' to
replace resolv.conf appears to be one of those bugs. There is no
provision for that command to fail, nor is there any effort to capture
and report antying that may appear on the standard error stream. Though
it does check the exit status of any hook scripts that it executes.

Even simply logging the fact that it is replacing resolv.conf would be a
nice thing and would have saved me hours of troubleshooting.

I also looked back through my logs and found lots of dhclient entries
from the last day or so and many leading up to about a month ago, but
there is a gap there as well. That was part of made the initial
troubleshootin difficult. Somehow resolv.conf would change and I could
not correlate the change to anything that was being logged.

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 8:06 AM, Roberto C. Sánchez <rob...@debian.org> 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

[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.

[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.

[Glenn English]

On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone <mst...@debian.org> 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 host dns
>> 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

[Greg Wooledge]

On Thu, Oct 26, 2017 at 03:35:06PM +0000, 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".

[The Wanderer]

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

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone <mst...@debian.org> 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 host dns
>>> 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

[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.

[Nicholas Geovanis]

On Thu, Oct 26, 2017 at 11:13 AM, Nicholas Geovanis <nickge...@gmail.com> 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.

[Jonathan de Boyne Pollard]

Roberto C. Sánchez:

> Is this the new normal, for things to get captured in some systemd log

> [...]?
>
* https://unix.stackexchange.com/a/294206/5132 Yes.

[Roberto C. Sánchez]

That is very informative. In particular:

| If it can connect (as a client) to an AF_LOCAL datagram socket at
| /run/systemd/journal/syslog it writes journal data there, if forwarding
| to syslog is configured.

I need to make sure that I have that forwarding propery configured on my
systems.

Then also:

| systemd itself arranges for the standard outputs and errors of (some)
| services to be attached to the /run/systemd/journal/stdout socket. So
| dæmons that log to standard error in the normal fashion have their
| output sent to the journal.

That does seem quite useful and from what I have experienced the last
few days nicely handles the case where something that should log to
syslog calls a command and then ignores its stdout/stderr. The systemd
journal was seeing that stderr text where syslog was not.

[Nicholas Geovanis]

Thanks for that. And quoting that article....

" And there's also systemd, that is slowly phagocytosing the UNIX part of Linux...."

:-D

[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.

[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

[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 ;-)

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 <http://geneslinuxbox.net:6309/gene>

[Gene Heskett]

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

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone <mst...@debian.org>
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 host dns
> >> 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

[Gene Heskett]

I'm old enough to have taken phonics in grade school, but that obviously
invented word could probably be replaced by a 4 letter adjective...