From: Sjoerd Hardeman on 20 Mar 2010 07:50 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 22 Mar 2010 12:30 > -----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 22 Mar 2010 19:20 -----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 23 Mar 2010 00:30 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 23 Mar 2010 14:10 -----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
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: NICs bringin up fails (was Realtek 8139 NICs) Next: Theoretical drive swapidge. |