From: Sjoerd Hardeman on
Clive McBarton schreef:
> To make my original question more precise: I want the stuff I write into
> resolv.conf to persist, but it does not have to be in that file. I'm
> happy to write things elsewhere as long as *some place* makes my changes
> persistent.
>
> Sjoerd Hardeman wrote:
>> Therefore, dns settings should be set either via dhcp, in
>> /etc/networks/interfaces or via some user-leven config framework like
>> wicd or network-manager.
>
> So maybe I should actually *install* resolvconf or reinstall
> network-manager? In that case, I need help with where the new config goes.
Well, that depends. in /etc/networks/interfaces you can set a nameserver
and search domain. When you ifup that device, the info that you've
specified in /etc/networks/interfaces then gets written to
/etc/resolv.conf. Yet, this only applies to static networks, as what
I've understood you do not have.
For dailup, stuff is configured via ppp. Either see other posts on how
to configure that or use a dialup gui like kppp which lists you all the
neat options to set dnsses yourself (which that programme then will
write to your /etc/resolv.conf.
Similarly, you can edit the dhcpd-config, or tell programmes using it
(nm, wicd, /etc/networks/interfaces with auto config devices) to put an
own nameserver in /etc/resolv.conf.
Yet, relying on the immutability of /etc/resolv/conf is like relying on
the persistence of files on /tmp: just DON'T!

Sjoerd

From: James Zuelow on
> -----Original Message-----
> From: Sjoerd Hardeman [mailto:sjoerd(a)lorentz.leidenuniv.nl]
> Sent: Saturday, 20 March, 2010 03:47
> To: debian-user(a)lists.debian.org
> Subject: Re: why does resolv.conf change?
>
> Clive McBarton schreef:
> > To make my original question more precise: I want the stuff
> I write into
> > resolv.conf to persist, but it does not have to be in that file. I'm
> > happy to write things elsewhere as long as *some place*
> makes my changes
> > persistent.
> >

> Yet, relying on the immutability of /etc/resolv/conf is like
> relying on
> the persistence of files on /tmp: just DON'T!
>

2nd note that my suggestion to make /etc/resolv.conf immutable was not to keep his changes, but to cause the application making the changes to complain in the event log. Then the OP could fix or configure the offending application.

The OP said that he did not know which application that was -- causing a failure is a simple way to identify these things. ("FOO unable to write to /etc/resolv.conf" in syslog is a good clue as to the culprit.)

Cheers,

James

--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4A09477D575C2C4B86497161427DD94C149F7885FE(a)city-exchange07
From: Clive McBarton on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Zuelow wrote:
>> Yet, relying on the immutability of /etc/resolv/conf is like
>> relying on
>> the persistence of files on /tmp: just DON'T!
>>
>
> 2nd note that my suggestion to make /etc/resolv.conf immutable was not to keep his changes, but to cause the application making the changes to complain in the event log. Then the OP could fix or configure the offending application.

He probably realized that. He is criticizing not you but me for wanting
resolv.conf to stay the same.

BTW, your suggestion did not work for me:

# chattr +i /etc/resolv.conf
chattr: Operation not supported while reading flags on /etc/resolv.conf

Anyway, having reinstalled resolvconf, I know exactly what is modifying
resolv.conf now, namely resolvconf (and possibly others, but resolvconf
overrides those). While unable to stop the modifications, I noticed that
I can put my stuff in /etc/resolvconf/resolv.conf.d/head and it will
then still be there after resolvconf runs. It does not keep the unwanted
provider nameserver out of resolv.conf, but prepends it with
sufficiently many (3 suffices?) good nameservers, so it never gets used
and everything is fine. Problem solved.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkun+N8ACgkQ+VSRxYk440+mlwCfVz6N+gLHQn/SLc1C1iJ2N7vl
ErQAn267U4tXeXgPv5Ke7l6FseQr9351
=QdJa
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BA7F8DF.9050501(a)web.de
From: Rick Thomas on

On Mar 22, 2010, at 7:10 PM, Clive McBarton wrote:

> prepends it with
> sufficiently many (3 suffices?) good nameservers, so it never gets
> used
> and everything is fine.

Nothing is 100.000% certain, of course. But as long as your 3 are
independent of each other -- i.e. not subject to a single-point-of-
failure (short of complete failure of all the root servers, thus
taking down the entire DNS [-; ) You should be OK.

Rick


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AD8BFDEF-1A7E-4DE4-B93C-AC2BD9972786(a)pobox.com
From: Clive McBarton on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rick Thomas wrote:
>
> On Mar 22, 2010, at 7:10 PM, Clive McBarton wrote:
>
>> prepends it with
>> sufficiently many (3 suffices?) good nameservers, so it never gets used
>> and everything is fine.
>
> Nothing is 100.000% certain, of course. But as long as your 3 are
> independent of each other -- i.e. not subject to a
> single-point-of-failure (short of complete failure of all the root
> servers, thus taking down the entire DNS [-; ) You should be OK.

Fine. I read somewhere that only the first 3 nameservers count, but
can't remember where.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkupAX0ACgkQ+VSRxYk440+RhQCg01eyJB3cYpdO+EK3Xa69TMGF
GssAoO1O5mj49dfzeyEvH7A+0ZmYTKK8
=ysnW
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BA9017D.6020404(a)web.de