[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why does resolv.conf keep changing?



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

> On Wed, Oct 25, 2017 at 1:06 AM, Michael Stone <mstone@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


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>


Reply to: