Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #188193 > unrolled thread
| Started by | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| First post | 2017-10-23 04:20 +0200 |
| Last post | 2017-10-25 16:20 +0200 |
| Articles | 20 on this page of 138 — 29 participants |
Back to article view | Back to linux.debian.user
Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-23 04:20 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-23 11:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-23 11:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 01:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-24 02:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 05:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 09:20 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-24 14:20 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 14:30 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-24 19:10 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-24 18:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-25 20:50 +0200
Re: Why does resolv.conf keep changing? Roger Lynn <Roger@rilynn.me.uk> - 2017-10-25 00:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 04:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-23 13:00 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-23 18:10 +0200
Re: Why does resolv.conf keep changing? Jude DaShiell <jdashiel@panix.com> - 2017-10-23 18:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-23 23:10 +0200
Re: Why does resolv.conf keep changing? Dan Ritter <dsr@randomstring.org> - 2017-10-24 00:00 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-24 02:40 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 03:20 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 05:00 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 05:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 06:20 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? Alberto Luaces <aluaces@udc.es> - 2017-10-25 14:10 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:50 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-25 16:30 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 17:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 17:30 +0200
Re: Why does resolv.conf keep changing? rhkramer@gmail.com - 2017-10-25 19:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 19:10 +0200
Re: Why does resolv.conf keep changing? rhkramer@gmail.com - 2017-10-25 19:40 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Felix Miata <mrmazda@earthlink.net> - 2017-10-25 05:50 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:00 +0200
Re: Why does resolv.conf keep changing? tomas@tuxteam.de - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Nicolas George <george@nsup.org> - 2017-10-25 14:50 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 14:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? Dan Ritter <dsr@randomstring.org> - 2017-10-25 17:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 18:50 +0200
Re: Why does resolv.conf keep changing? Don Armstrong <don@debian.org> - 2017-10-25 21:30 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? Glenn English <ghe2001@gmail.com> - 2017-10-26 17:40 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 17:50 +0200
Re: Why does resolv.conf keep changing? The Wanderer <wanderer@fastmail.fm> - 2017-10-26 18:00 +0200
Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 18:20 +0200
Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 18:40 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:00 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:00 +0200
Re: Why does resolv.conf keep changing? Jörg-Volker Peetz <jvpeetz@web.de> - 2017-10-23 12:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 05:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 06:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 06:50 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-25 08:50 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 14:40 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:50 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:10 +0200
[SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 20:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 20:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 20:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 21:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 21:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 15:10 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 15:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 16:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Don Armstrong <don@debian.org> - 2017-10-26 21:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 21:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 16:30 +0200
The new normal of logging Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2017-10-26 21:10 +0200
Re: The new normal of logging Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 21:30 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:10 +0200
Re: The new normal of logging Ben Caradoc-Davies <ben@transient.nz> - 2017-10-27 03:30 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-27 07:00 +0200
Re: The new normal of logging Ben Caradoc-Davies <ben@transient.nz> - 2017-10-28 04:50 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-28 08:10 +0200
Re: The new normal of logging Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-10-27 04:10 +0200
Re: The new normal of logging Darac Marjal <mailinglist@darac.org.uk> - 2017-10-27 11:40 +0200
Plain text vs. binary (was Re: The new normal of logging) The Wanderer <wanderer@fastmail.fm> - 2017-10-27 14:40 +0200
Re: The new normal of logging Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 21:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-27 17:10 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 17:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-27 20:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Brian <ad44@cityscape.co.uk> - 2017-10-27 20:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-27 21:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 22:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-28 18:30 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-26 05:40 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 12:50 +0200
Re: Why does resolv.conf keep changing? Darac Marjal <mailinglist@darac.org.uk> - 2017-10-26 13:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 13:50 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-26 16:40 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 17:00 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-27 10:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 13:50 +0200
Re: Why does resolv.conf keep changing? Darac Marjal <mailinglist@darac.org.uk> - 2017-10-27 14:20 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 14:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-27 20:50 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-27 20:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-27 16:20 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-28 02:00 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 15:30 +0200
Re: Why does resolv.conf keep changing? Glenn English <ghe2001@gmail.com> - 2017-10-28 18:50 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 15:40 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-27 16:40 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-27 16:30 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-28 02:40 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-26 14:40 +0200
Re: Why does resolv.conf keep changing? Roger Lynn <Roger@rilynn.me.uk> - 2017-11-04 00:30 +0100
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-11-04 08:50 +0100
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-11-04 13:10 +0100
Re: Why does resolv.conf keep changing? Brian <ad44@cityscape.co.uk> - 2017-11-04 22:00 +0100
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-11-04 22:10 +0100
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-11-04 22:10 +0100
Re: Why does resolv.conf keep changing? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-11-04 15:40 +0100
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:20 +0200
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2017-10-26 05:40 +0200 |
| Message-ID | <uEHbr-au-3@gated-at.bofh.it> |
| In reply to | #188284 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-26 12:50 +0200 |
| Message-ID | <uENTA-4ic-5@gated-at.bofh.it> |
| In reply to | #188323 |
On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote: > > If Debian developers who are responsible for resolvconf are reading this, > > and if they actually CARE about making things work correctly and sensibly, > > then here is yet another proposal: give us a way to QUICKLY and EASILY > > and RELIABLY tell resolvconf "never do anything". > > `resolvconf` only touches /etc/resolv.conf when it is installed/initialized. > What it does to it is to replace it with a symlink. > After that, it doesn't touch it any morel instead it only modifies the file > that is the target of that symlink. > Given that multiple packages potentially touch/change resolv.conf (at least resolvconf and the various DHCP clients), would be very useful is a directive that can be put inside of resolv.conf that informs all such packages that the file is not to be modified. That would allow the admin to avoid having to hunt down all the different packages and configure them individually to leave /etc/resolv.conf alone. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Darac Marjal <mailinglist@darac.org.uk> |
|---|---|
| Date | 2017-10-26 13:30 +0200 |
| Message-ID | <uEOwh-4Mp-3@gated-at.bofh.it> |
| In reply to | #188329 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Oct 26, 2017 at 06:44:44AM -0400, Roberto C. Sánchez wrote: >On Wed, Oct 25, 2017 at 11:35:20PM -0400, Stefan Monnier wrote: >> > If Debian developers who are responsible for resolvconf are reading this, >> > and if they actually CARE about making things work correctly and sensibly, >> > then here is yet another proposal: give us a way to QUICKLY and EASILY >> > and RELIABLY tell resolvconf "never do anything". >> >> `resolvconf` only touches /etc/resolv.conf when it is installed/initialized. >> What it does to it is to replace it with a symlink. >> After that, it doesn't touch it any morel instead it only modifies the file >> that is the target of that symlink. >> >Given that multiple packages potentially touch/change resolv.conf (at >least resolvconf and the various DHCP clients), would be very useful is >a directive that can be put inside of resolv.conf that informs all such >packages that the file is not to be modified. That would allow the >admin to avoid having to hunt down all the different packages and >configure them individually to leave /etc/resolv.conf alone. Actually, there's no need to duplicate the effort. As I understand it, resolvconf is basically an optional helper program. Software that automatically modifies /etc/resolv.conf should first test for the presence of resolvconf (whether that be checking for the configuration directory of resolvconf or checking that resolvconf is running or... however resolvconf desires to be detected). If resolvconf is available, the changes are co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified directly. The problem is that I don't think that resolvconf can require packages to use it. This is similar to other higher-level APIs such as pulseaudio. If the software knows to use pulseaudio, then it can get mixed, rerouted etc by pulseaudio, but it's difficult to mandate that software stop sending audio directly to /dev/dsp (well, unless you're a distribution which applies patches to upstream software in order to harmonize the experience of its users). > >Regards, > >-Roberto > >-- >Roberto C. Sánchez > -- For more information, please reread.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-26 13:50 +0200 |
| Message-ID | <uEOPD-4Sy-5@gated-at.bofh.it> |
| In reply to | #188331 |
On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote: > > Actually, there's no need to duplicate the effort. As I understand it, > resolvconf is basically an optional helper program. Software that > automatically modifies /etc/resolv.conf should first test for the presence > of resolvconf (whether that be checking for the configuration directory of > resolvconf or checking that resolvconf is running or... however resolvconf > desires to be detected). If resolvconf is available, the changes are > co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified > directly. > In my case resolvconf is not installed/available and I want resolv.conf to be left alone. I want any other package that thinks it needs to modify resolv.conf to leave it along. I also think that would be useful in the case where resolvconf gets unexpected installed later. That is not a specific concern for me, but in a situation where multiple administrators are involved with managing a system it could happen. Based on your proposal the situation which I have would not be addressed. I am specifically saying that there should be a way to mark resolv.conf as static so that any package that touches it can check for that directive. There is no need for packages to coordinate between themselves in that case. They need only to check for the marker in resolv.conf and if it is there (indicating that it should not be modified) then they simply discontinue processing. > The problem is that I don't think that resolvconf can require packages to > use it. This is similar to other higher-level APIs such as pulseaudio. If > the software knows to use pulseaudio, then it can get mixed, rerouted etc by > pulseaudio, but it's difficult to mandate that software stop sending audio > directly to /dev/dsp (well, unless you're a distribution which applies > patches to upstream software in order to harmonize the experience of its > users). > I can see the utility of resolvconf and in packages coordinating their modifications of resolv.conf. However, I still maintain that there should be a simple way for the admin to mark resolv.conf in such a way that no package will modify it. This should be possible without resorting to hacks like making resolv.conf immutable. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-26 16:40 +0200 |
| Message-ID | <uERu9-6wp-7@gated-at.bofh.it> |
| In reply to | #188332 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-26 17:00 +0200 |
| Message-ID | <uERNv-6CV-7@gated-at.bofh.it> |
| In reply to | #188345 |
On Thu, Oct 26, 2017 at 09:31:47AM -0500, David Wright wrote: > > Judging by your address and earlier comment, you're much closer to > Debian's strategy than I am, but I thought the thrust of Debian was > to coerce/persuade packages to cooperate on /etc/resolv.conf so that > one package did not overwrite the actions of another on starting, > and could unroll their own changes when terminating. It's always > worked here with ifup and dhclient, but that's less complex than > your own situation using bind. (I use /etc/hosts for my own LAN.) > You make a good point. However, I think that requiring the user/admin to implement a hook script in order to reliably get dhclient to do the right thing is a bit much. That is why I made the suggestion about the configuration directive. > > An official hack (Debian) rather than an unofficial one (sys admin)? > The most remarkable thing in this thread is the alleged defeat of > chattr +i. (a) it's difficult to believe that some package comes > along and unsets i (immutable attribute), changes the file, and sets > i again, which is what you allege. (b) although I agreed with Gene > that a watch could be left untriggered by i being set, this would > only happen if a package tried to naively change resolv.conf; the > behaviour alleged in (a) would still trigger the watch at the time > i was temporarily unset. (c) the third alternative is failure of > i to do its job, which seems unlikely. > I had several terminal windows open and I am beginning to suspect that I was mistaken (at least initially) about having set +i. In particular, when I later tried again (possibly for the first time it now seems) I observed that new temporary files were littered in /etc after the dhclient-script attempt to overwrite the original /etc/resolv.conf failed. I am going to just call it user error on my part. > So perhaps Debian should just adopt chattr +i as the official way > of doing what Gene, Greg and you want, with a warning that you > might want to clean up any clutter (resolv.conf.foo…) periodically. > Anything that interfered with that could then be filed as a bug. > I do not find this a particularly good solution because it would likely interfere with managing a system via puppet, ansible, etc. There is definitely a use case for "this file should be changeable only by the administrator, not by any automated functionality from an installed package." > BTW did you find out why you were getting DHCP negotiations > every 3 or 4 minutes? The lease you posted was for 16005 seconds, > over 4 hours. > I don't recall this being a problem except for when I manually ran dhclient to force a new negotiation. I have not observed anything that makes me think there is an issue with premature renegotiation. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Mart van de Wege <mvdwege@gmail.com> |
|---|---|
| Date | 2017-10-27 10:10 +0200 |
| Message-ID | <uF7Sh-NC-7@gated-at.bofh.it> |
| In reply to | #188332 |
Roberto C. Sánchez <roberto@debian.org> writes: > On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote: >> >> Actually, there's no need to duplicate the effort. As I understand it, >> resolvconf is basically an optional helper program. Software that >> automatically modifies /etc/resolv.conf should first test for the presence >> of resolvconf (whether that be checking for the configuration directory of >> resolvconf or checking that resolvconf is running or... however resolvconf >> desires to be detected). If resolvconf is available, the changes are >> co-ordinated through resolvconf, otherwise, /etc/resolv.conf is modified >> directly. >> > In my case resolvconf is not installed/available and I want resolv.conf > to be left alone. I want any other package that thinks it needs to > modify resolv.conf to leave it along. But there *is* a way to do that: install resolvconf. Granted, it might be nice if resolvconf had an easier way to configure a static setup, but as it is now packages that need to access resolv.conf should do this through resolvconf if it is available, so installing and configuring it *is* the right way to handle this. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-10-27 13:50 +0200 |
| Message-ID | <uFbjb-2Zy-3@gated-at.bofh.it> |
| In reply to | #188380 |
On Friday 27 October 2017 03:46:27 Mart van de Wege wrote: > Roberto C. Sánchez <roberto@debian.org> writes: > > On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote: > >> Actually, there's no need to duplicate the effort. As I understand > >> it, resolvconf is basically an optional helper program. Software > >> that automatically modifies /etc/resolv.conf should first test for > >> the presence of resolvconf (whether that be checking for the > >> configuration directory of resolvconf or checking that resolvconf > >> is running or... however resolvconf desires to be detected). If > >> resolvconf is available, the changes are co-ordinated through > >> resolvconf, otherwise, /etc/resolv.conf is modified directly. > > > > In my case resolvconf is not installed/available and I want > > resolv.conf to be left alone. I want any other package that thinks > > it needs to modify resolv.conf to leave it along. > > But there *is* a way to do that: install resolvconf. > > Granted, it might be nice if resolvconf had an easier way to configure > a static setup, but as it is now packages that need to access > resolv.conf should do this through resolvconf if it is available, so > installing and configuring it *is* the right way to handle this. > > Mart I must argue against it, until as you say, resolvconf is given a well documented way to be told to leave a "static" system alone. Until such time, I'll make /etc/resolv.conf a real file, and mark it and /etc/network/interfaces immutable. And frankly, I'm getting tired of the arguments saying it must be installed. Not all machines are lappy's being toted to Micky D's for connectivity, where it /might/ make some modicum of sense IF it Just Worked. Here, it didn't just work on a jessie install, took me around an hour fighting with its local keyboard, to make networking work on the jessie install, and 15 minutes to make stretch work, but there I wasn't fighting with a kernel bug that kills keyboards and mice. So it didn't Just Work on a stretch install. So until such time as resolv.conf can look at /etc/network/interfaces, and finding the "static" keyword, leave that interface alone, it will be nuked on sight with a root rm... If by the debian 10 release, it must be installed, them MAKE IT WORK. My way, so far, does that. In my experience its a solution looking for a problem, and if it doesn't find one, it will make one. It's network-manager by a new name, and just as worthless. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Darac Marjal <mailinglist@darac.org.uk> |
|---|---|
| Date | 2017-10-27 14:20 +0200 |
| Message-ID | <uFbMd-3s2-5@gated-at.bofh.it> |
| In reply to | #188383 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Oct 27, 2017 at 07:49:29AM -0400, Gene Heskett wrote: >On Friday 27 October 2017 03:46:27 Mart van de Wege wrote: > >> Roberto C. Sánchez <roberto@debian.org> writes: >> > On Thu, Oct 26, 2017 at 12:24:32PM +0100, Darac Marjal wrote: >> >> Actually, there's no need to duplicate the effort. As I understand >> >> it, resolvconf is basically an optional helper program. Software >> >> that automatically modifies /etc/resolv.conf should first test for >> >> the presence of resolvconf (whether that be checking for the >> >> configuration directory of resolvconf or checking that resolvconf >> >> is running or... however resolvconf desires to be detected). If >> >> resolvconf is available, the changes are co-ordinated through >> >> resolvconf, otherwise, /etc/resolv.conf is modified directly. >> > >> > In my case resolvconf is not installed/available and I want >> > resolv.conf to be left alone. I want any other package that thinks >> > it needs to modify resolv.conf to leave it along. >> >> But there *is* a way to do that: install resolvconf. >> >> Granted, it might be nice if resolvconf had an easier way to configure >> a static setup, but as it is now packages that need to access >> resolv.conf should do this through resolvconf if it is available, so >> installing and configuring it *is* the right way to handle this. >> >> Mart > >I must argue against it, until as you say, resolvconf is given a well >documented way to be told to leave a "static" system alone. Until such >time, I'll make /etc/resolv.conf a real file, and mark it >and /etc/network/interfaces immutable. > >And frankly, I'm getting tired of the arguments saying it must be >installed. Who's saying it must be installed? Maybe I've missed something, but I think the consensus in this discussion was that if you want your resolv.conf to be unmanaged/static/administrator-controlled, then don't have resolvconf installed. If you have resolvconf installed, then what's the point of neutering it with a command? (I realise that there are some packages that come with, say, ENABLED=no in /etc/default, but that's usually there because sensible defaults are difficult, and the package needs to be configured before use. Not so with resolvconf). > Not all machines are lappy's being toted to Micky D's for >connectivity, where it /might/ make some modicum of sense IF it Just >Worked. Here, it didn't just work on a jessie install, took me around an >hour fighting with its local keyboard, to make networking work on the >jessie install, and 15 minutes to make stretch work, but there I wasn't >fighting with a kernel bug that kills keyboards and mice. So it didn't >Just Work on a stretch install. > >So until such time as resolv.conf can look at /etc/network/interfaces, >and finding the "static" keyword, leave that interface alone, it will be >nuked on sight with a root rm... > >If by the debian 10 release, it must be installed, them MAKE IT WORK. My >way, so far, does that. > >In my experience its a solution looking for a problem, and if it doesn't >find one, it will make one. It's network-manager by a new name, and >just as worthless. > >Cheers, Gene Heskett >-- >"There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." >-Ed Howdershelt (Author) >Genes Web page <http://geneslinuxbox.net:6309/gene> > -- For more information, please reread.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-27 14:40 +0200 |
| Message-ID | <uFc5z-3za-7@gated-at.bofh.it> |
| In reply to | #188384 |
On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote: > Who's saying it must be installed? A few people in this thread, though I think they're saying "should" rather than "must". > Maybe I've missed something, but I think > the consensus in this discussion was that if you want your resolv.conf to be > unmanaged/static/administrator-controlled, then don't have resolvconf > installed. If you have resolvconf installed, then what's the point of > neutering it with a command? Let's review what we've learned so far. If you want to make local modifications to /etc/resolv.conf and have them stick, here are some ways to do it: 1) chattr +i /etc/resolv.conf 2) Individually configure each daemon that might try to modify the file, to make it stop doing so. 3) Install the resolvconf package, because by doing so you also install various hacks that modify the behavior of all known Debian daemons, stopping them from writing to /etc/resolv.conf. Then tell resolvconf itself to do nothing by putting resolvconf=NO in the /etc/resolvconf.conf file.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-27 20:50 +0200 |
| Message-ID | <uFhRE-7yz-3@gated-at.bofh.it> |
| In reply to | #188386 |
On Fri 27 Oct 2017 at 08:35:05 (-0400), Greg Wooledge wrote: > On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote: > > Who's saying it must be installed? > > A few people in this thread, though I think they're saying "should" > rather than "must". > > > Maybe I've missed something, but I think > > the consensus in this discussion was that if you want your resolv.conf to be > > unmanaged/static/administrator-controlled, then don't have resolvconf > > installed. If you have resolvconf installed, then what's the point of > > neutering it with a command? Conceivably, one could switch between a *docked laptop with chattr +i of a real file* that is occasionally taken on the road with the simple actions of chattr -i and ln -s being necessary to effect the change. All the daemons could be working away as normal all the time, but just rendered impotent when docked. AFAICT this will also keep systemd happy when docked, and undocking can be done with a symlink to /run/systemd/resolve/resolv.conf (rather than /etc/resolvconf/run/resolv.conf), allowing systemd-resolved.service to perform again. > Let's review what we've learned so far. > > If you want to make local modifications to /etc/resolv.conf and have > them stick, here are some ways to do it: > > 1) chattr +i /etc/resolv.conf With the common sense assumptions that a real file has had the required data entered, that would seem to be sufficient, without having to cope with the complications following. > 2) Individually configure each daemon that might try to modify the file, > to make it stop doing so. > > 3) Install the resolvconf package, because by doing so you also install > various hacks that modify the behavior of all known Debian daemons, > stopping them from writing to /etc/resolv.conf. > > Then tell resolvconf itself to do nothing by putting resolvconf=NO > in the /etc/resolvconf.conf file. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-27 20:50 +0200 |
| Message-ID | <uFhRD-7yz-1@gated-at.bofh.it> |
| In reply to | #188386 |
On Fri 27 Oct 2017 at 11:38:56 (-0700), Kevin O'Gorman wrote: > Interesting. I took a look at mine, and found > lrwxrwxrwx 1 root root 29 Aug 8 2016 /etc/resolv.conf -> > ../run/resolvconf/resolv.conf > > so the thing is now entirely dynamic. I don't know what setting it > immutable would do or mean. If you mean /etc/resolv.conf itself, you can't. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-27 16:20 +0200 |
| Message-ID | <uFdEl-4O9-5@gated-at.bofh.it> |
| In reply to | #188384 |
On Fri, Oct 27, 2017 at 01:18:58PM +0100, Darac Marjal wrote: > > Who's saying it must be installed? Maybe I've missed something, but I think > the consensus in this discussion was that if you want your resolv.conf to be > unmanaged/static/administrator-controlled, then don't have resolvconf > installed. If you have resolvconf installed, then what's the point of > neutering it with a command? > The suggestion was made several times that if I wanted to prevent /etc/resolv.conf being changed that I needed to first install resolvconf (this system has never had resolvconf installed) and then configure resolvconf to not change /etc/resolv.conf. After much investigation and troubleshooting it turned out to be dhclient that was modifying /etc/resolv.conf. Think about that for a minute. The mere action of an interface (any interface on the system) obtaining a DHCP lease is sufficient to have dhclient think it needs to obliterate my manual networking configuration with settings from the DHCP server. It clearly assumes that it is the only thing involved in configuring networking on the system. This despite the fact that the system in question has another static interface onto my LAN and runs bind for my network (which is why I felt strongly "nameserver 127.0.0.1" is an important option that should be left alone in /etc/resolv.conf). In the end it turns out that "resolvconf not installed =/=> /etc/resolv.conf will remain unmanaged". > (I realise that there are some packages that come with, say, ENABLED=no in > /etc/default, but that's usually there because sensible defaults are > difficult, and the package needs to be configured before use. Not so with > resolvconf). > Certainly I can understand an argument for resolvconf respecting or not respecting certain conventions as defaults. However, the whole point of the thread that I started was how to figure out what was changing /etc/resolv.conf when resolvconf wasn't installed in the first place. It may have reasonable defaults but the available methods for making it do what I need it to do for my particular situation are inadequate and involve way too much work. I mean, even a simple line like this at the top would be such a help: # This was automatically generated by dhclient (Oct 25 19:03:45 EDT) # Any changes will be overwritten # To make this stop consult dhclient-script(8) In any event, when I get some time in the next days I will update some pages related to this on the Debian wiki and possibly file a few wishlist bugs. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Mart van de Wege <mvdwege@gmail.com> |
|---|---|
| Date | 2017-10-28 00:10 +0200 |
| Message-ID | <uFkZb-1np-9@gated-at.bofh.it> |
| In reply to | #188388 |
Roberto C. Sánchez <roberto@debian.org> writes: > Think about that for a minute. The mere action of an interface (any > interface on the system) obtaining a DHCP lease is sufficient to have > dhclient think it needs to obliterate my manual networking configuration > with settings from the DHCP server. Well, yes. That's what DHCP *does*. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-28 00:10 +0200 |
| Message-ID | <uFkZb-1np-11@gated-at.bofh.it> |
| In reply to | #188411 |
On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote: > Roberto C. Sánchez <roberto@debian.org> writes: > > > Think about that for a minute. The mere action of an interface (any > > interface on the system) obtaining a DHCP lease is sufficient to have > > dhclient think it needs to obliterate my manual networking configuration > > with settings from the DHCP server. > > Well, yes. That's what DHCP *does*. > The problem I have with it is that in my case there are other *static* interfaces on the system and DHCP's assumption that it is operating in a vacuum is terribly annoying. I cannot be the only person who has encountered this particular issue with these circumstances and been frustrated by how difficult it is to, 1) find out what exactly is happening, and 2) make it stop. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-28 02:00 +0200 |
| Message-ID | <uFmHD-2iI-1@gated-at.bofh.it> |
| In reply to | #188412 |
On Fri 27 Oct 2017 at 18:05:23 (-0400), Roberto C. Sánchez wrote: > On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote: > > Roberto C. Sánchez <roberto@debian.org> writes: > > > > > Think about that for a minute. The mere action of an interface (any > > > interface on the system) obtaining a DHCP lease is sufficient to have > > > dhclient think it needs to obliterate my manual networking configuration > > > with settings from the DHCP server. > > > > Well, yes. That's what DHCP *does*. > > > The problem I have with it is that in my case there are other *static* > interfaces on the system and DHCP's assumption that it is operating in a > vacuum is terribly annoying. Yes, that's why some people recommended resolvconf to moderate its (and other packages') behaviour. That's what resolvconf does. > I cannot be the only person who has > encountered this particular issue with these circumstances and been > frustrated by how difficult it is to, 1) find out what exactly is > happening, and 2) make it stop. No, nor to unintentionally cause a wild goose chase by making a reporting error. Nor to have your thread derailed by people posting their favourite purported "solutions" that have already been discredited here. OTOH I think it's understandable that the thread is prolonged by well-intentioned suggestions to adopt the "official" Debian way of handling this with resolvconf. Am I the only person surprised that there wasn't more advocacy for systemd-resolved.service as well. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Mart van de Wege <mvdwege@gmail.com> |
|---|---|
| Date | 2017-10-28 15:30 +0200 |
| Message-ID | <uFzlv-2eu-3@gated-at.bofh.it> |
| In reply to | #188413 |
David Wright <deblis@lionunicorn.co.uk> writes: > Am I the only person surprised that there wasn't more advocacy for > systemd-resolved.service as well. > So far all that's stopping me experimenting with it is that I don't understand the interaction between openvpn, systemd-networkd and systemd-resolved yet. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
[toc] | [prev] | [next] | [standalone]
| From | Glenn English <ghe2001@gmail.com> |
|---|---|
| Date | 2017-10-28 18:50 +0200 |
| Message-ID | <uFCt3-44I-3@gated-at.bofh.it> |
| In reply to | #188417 |
I've recently found myself living with a T1 and a DHCP (Comcast) -- slow and reliable all the time, and blistering fast at 3:00 AM. I think I may have dealt with the resolv.conf (R.C) problem. I set myself as the owner of R.C, removed everything but owner read permission, and set it to immutable. (Largely for show; I know all this doesn't slow down root a whole lot.) The computer's 2 Ethernet interfaces are configured in /etc/network/interfaces and Network Manager has been removed. One interface is static, the other is DHCP. There are a couple 'post-up' scripts in the DHCP config -- one replaces R.C with the one I want it to be and deletes the files whining about how Comcast couldn't scribble in R.C, the other rewrites the routing table so the mirrors go with Comcast and everything else uses the T1. If/when Comcast figures out how to get root and overcome the configs done to R.C, the scripts make things all better again. (Assuming immutable's been disabled somehow and R.C needs to be replaced.) -- Glenn English
[toc] | [prev] | [next] | [standalone]
| From | Mart van de Wege <mvdwege@gmail.com> |
|---|---|
| Date | 2017-10-28 15:40 +0200 |
| Message-ID | <uFzvb-2jp-1@gated-at.bofh.it> |
| In reply to | #188412 |
Roberto C. Sánchez <roberto@debian.org> writes: > On Fri, Oct 27, 2017 at 11:46:53PM +0200, Mart van de Wege wrote: >> Roberto C. Sánchez <roberto@debian.org> writes: >> >> > Think about that for a minute. The mere action of an interface (any >> > interface on the system) obtaining a DHCP lease is sufficient to have >> > dhclient think it needs to obliterate my manual networking configuration >> > with settings from the DHCP server. >> >> Well, yes. That's what DHCP *does*. >> > The problem I have with it is that in my case there are other *static* > interfaces on the system and DHCP's assumption that it is operating in a > vacuum is terribly annoying. You are not. Hence resolvconf. And yes, having to muck about with dhclient settings or resolvconf when you have a mixed dynamic/static setup can be aggravating. > I cannot be the only person who has encountered this particular issue > with these circumstances and been frustrated by how difficult it is > to, 1) find out what exactly is happening, Actually my first thought was 'hmm, sounds like a DHCP client is running". > and 2) make it stop. > I remember how much time it took me to get used to resolvconf + NetworkManager + dnsmasq on my laptop, to convince that combo to always use my internal DNS servers so that my Kerberos realm would keep working over VPN. Mart -- "We will need a longer wall when the revolution comes." --- AJS, quoting an uncertain source.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2017-10-27 16:40 +0200 |
| Message-ID | <uFdXI-4Vw-17@gated-at.bofh.it> |
| In reply to | #188384 |
> Who's saying it must be installed? Maybe I've missed something, but I think
> the consensus in this discussion was that if you want your resolv.conf to be
> unmanaged/static/administrator-controlled, then don't have resolvconf
> installed.
This is a ridiculous idea. This thread is about a user who doesn't have
resolvconf installed and is bothered by something changing his
resolv.conf.
So clearly, not having resolvconf installed is not a solution.
As I already explained: resolvconf does not modify resolv.conf. It only
provides a standard way for applications who want to modify resolv.conf
(and who would hence normally just go ahead and modify the file) to do
so in a way that can be controlled. Hence it gives you the tool that
you need in order to be able to (for example) keep resolv.conf under
manual control.
Stefan
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web