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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-10-25 08:50 +0200 |
| Message-ID | <uEnFL-4Wd-5@gated-at.bofh.it> |
| In reply to | #188263 |
On 2017-10-25, Stefan Monnier <monnier@iro.umontreal.ca> 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.
>
> 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.
>
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.
--
"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.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2017-10-25 14:40 +0200 |
| Message-ID | <uEt8u-8kq-5@gated-at.bofh.it> |
| In reply to | #188265 |
>> 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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-10-25 14:50 +0200 |
| Message-ID | <uEtia-8nJ-5@gated-at.bofh.it> |
| In reply to | #188276 |
-----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-----
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2017-10-25 15:00 +0200 |
| Message-ID | <uEtrP-8qX-3@gated-at.bofh.it> |
| In reply to | #188278 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-10-25 15:10 +0200 |
| Message-ID | <uEtBw-hW-21@gated-at.bofh.it> |
| In reply to | #188279 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 25, 2017 at 08:51:55AM -0400, Stefan Monnier wrote: > > 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. 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-----
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-25 15:10 +0200 |
| Message-ID | <uEtBx-hW-35@gated-at.bofh.it> |
| In reply to | #188278 |
On Wed, Oct 25, 2017 at 02:42:49PM +0200, tomas@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.)
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-10-25 15:10 +0200 |
| Message-ID | <uEtBx-hW-37@gated-at.bofh.it> |
| In reply to | #188284 |
-----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-----
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-10-25 15:30 +0200 |
| Message-ID | <uEtUS-ot-3@gated-at.bofh.it> |
| In reply to | #188284 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-10-25 15:30 +0200 |
| Message-ID | <uEtUS-ot-9@gated-at.bofh.it> |
| In reply to | #188284 |
On Wednesday 25 October 2017 09:03:07 Greg Wooledge wrote: > On Wed, Oct 25, 2017 at 02:42:49PM +0200, tomas@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.) 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. 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 | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 16:10 +0200 |
| Message-ID | <uEuxz-QM-9@gated-at.bofh.it> |
| In reply to | #188290 |
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. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 16:10 +0200 |
| Message-ID | <uEuxz-QM-11@gated-at.bofh.it> |
| In reply to | #188284 |
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. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 20:30 +0200 |
| Subject | [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEyBb-3eu-1@gated-at.bofh.it> |
| In reply to | #188296 |
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
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-10-25 20:40 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEyKS-3hK-3@gated-at.bofh.it> |
| In reply to | #188309 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-25 20:40 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEyKS-3hK-13@gated-at.bofh.it> |
| In reply to | #188309 |
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>
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-25 21:00 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEz4e-3pb-5@gated-at.bofh.it> |
| In reply to | #188311 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 21:00 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEz4e-3pb-7@gated-at.bofh.it> |
| In reply to | #188311 |
On Wed, Oct 25, 2017 at 02:34:52PM -0400, Greg Wooledge wrote: > 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> > 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. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-26 15:10 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEQ54-5ND-15@gated-at.bofh.it> |
| In reply to | #188309 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-26 15:40 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEQy6-5Wv-3@gated-at.bofh.it> |
| In reply to | #188339 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-26 16:00 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEQRr-64w-11@gated-at.bofh.it> |
| In reply to | #188341 |
On Thu, Oct 26, 2017 at 09:35:03AM -0400, Greg Wooledge wrote:
> 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?
>
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.
Regards,
-Roberto
--
Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Don Armstrong <don@debian.org> |
|---|---|
| Date | 2017-10-26 21:40 +0200 |
| Subject | Re: [SOLVED] Re: Why does resolv.conf keep changing? |
| Message-ID | <uEWat-15p-1@gated-at.bofh.it> |
| In reply to | #188343 |
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
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web