Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #184538 > unrolled thread

Network config

Back to article view | Back to linux.debian.user

Contents

  Network config ruslan axundov <raxundov@gmail.com> - 2017-08-02 16:10 +0200
    Re: Network config Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-02 16:20 +0200
      Re: Network config Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-08-02 20:20 +0200
        Re: Network config Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-02 21:00 +0200
          Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-03 03:20 +0200
            Re: Network config Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-03 15:00 +0200
              Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-03 16:00 +0200
                Re: Network config Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-08-03 20:50 +0200
                  Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-04 03:00 +0200
                    Re: Network config Joe <joe@jretrading.com> - 2017-08-04 10:10 +0200
                      Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-04 17:10 +0200
                  Re: Network config <tomas@tuxteam.de> - 2017-08-04 10:20 +0200
                    Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-04 16:20 +0200
                      Re: Network config <tomas@tuxteam.de> - 2017-08-05 10:20 +0200
                        Re: Network config Gene Heskett <gheskett@shentel.net> - 2017-08-05 16:40 +0200
                          Re: Network config <tomas@tuxteam.de> - 2017-08-05 17:00 +0200
    Re: Network config Zenaan Harkness <zenaan@freedbms.net> - 2017-08-03 03:00 +0200
      Re: Network config Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-08-03 17:30 +0200
        Re: Network config Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-08-03 21:00 +0200
          Re: Network config Henning Follmann <hfollmann@itcfollmann.com> - 2017-08-03 21:30 +0200

#184538 — Network config

[Multipart message — attachments visible in raw view] — view raw

Hi

I have a problem with debian 9 as static nameserver .
So that I used before ubuntu 16.04  and I have configure satatic ip and dns
and it worked perfectly  but today I tried to use debian 9 and  when I
enter static dns server for debian in resolve.conf  then after reboot
debian all dns ip removed from resolv.conf file. I tried multiple method to
prevent this feature but nothing happen. what I must do ?


-- 
*Axundov Ruslan*
*Tel:* (050) 229 20 24
*Email:* raxundov@gmail.com
           r.axundov@live.com

[toc] | [next] | [standalone]

#184539

On Wed, Aug 02, 2017 at 05:44:50PM +0400, ruslan axundov wrote:
> I tried to use debian 9 and  when I
> enter static dns server for debian in resolve.conf  then after reboot
> debian all dns ip removed from resolv.conf file. I tried multiple method to
> prevent this feature but nothing happen. what I must do ?

<https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> is the
best single starting point I have found so far.  It gives multiple
ways to attack the problem, and you can choose which one(s) seem best
for your situation.

Other tips I can give: 

1) Make sure the Debian "resolvconf" package is *not* installed.

2) If /etc/resolv.conf is a symlink (e.g. due to previous installation
   of the resolvconf package), remove it and recreate it as a file.

3) I have utterly no idea how Network-Manager works (never used it), so
   consider removing that too, unless you really need it.

4) systemd may have some other network configuratizing thinymajig.
   But you know better than to use *that*, right?

5) Some DHCP servers send back a list of nameserver IPs even if you don't
   ask for them.  The ISC DHCP client daemon *will* overwrite resolv.conf
   if it receives them.  So, simply configuring dhclient.conf not to
   ask for nameservers will work on some networks but not on others.

[toc] | [prev] | [next] | [standalone]

#184549

Le 02/08/2017 à 16:19, Greg Wooledge a écrit :
> 
> 1) Make sure the Debian "resolvconf" package is *not* installed.

You should reconsider this advice. resolvconf may be your best ally to 
handle such a situation.

> 3) I have utterly no idea how Network-Manager works

Me neither, but I know one thing : it overwrites /etc/resolv.conf 
*unless resolvconf is installed* and properly configured.

> 5) Some DHCP servers send back a list of nameserver IPs even if you don't
>     ask for them.  The ISC DHCP client daemon *will* overwrite resolv.conf
>     if it receives them.

*Unless resolvconf is installed* and properly configured.

[toc] | [prev] | [next] | [standalone]

#184551

On Wed, Aug 02, 2017 at 08:10:23PM +0200, Pascal Hambourg wrote:
> Le 02/08/2017 à 16:19, Greg Wooledge a écrit :
> > 
> > 1) Make sure the Debian "resolvconf" package is *not* installed.
> 
> You should reconsider this advice. resolvconf may be your best ally to
> handle such a situation.

OK, I've scanned
<https://manpages.debian.org/stretch/openresolv/resolvconf.8.en.html> and
<https://manpages.debian.org/stretch/openresolv/resolvconf.conf.5.en.html>.

Looks complicated, with lots of specialized words being thrown around
but not defined.

E.g. resolvconf(8) says "In some situations resolvconf needs to act as
a deterrent to writing to /etc/resolv.conf. Where this file cannot be
made immutable or you just need to toggle this behaviour, resolvconf
can be disabled by adding resolvconf=NO to resolvconf.conf(5)."

Looks promising, eh?  But then resolvconf.conf(5) says "Set to NO to
disable resolvconf from running any subscribers. Defaults to YES."

What is a "subscriber"?  Definitely not defined in (8).  There's a section
called "SUBSCRIBER OPTIONS" in (5) but it still doesn't explain what they
are.

Back to (8), it says "Where this file cannot be made immutable".  Is it
*admitting* that making the file immutable is the preferred solution, and
resolvconf is just a backup plan?  That's what I'm getting out of it.

I don't see the advantage of installing a package and configuring it
in order to make it do *nothing*, when I can achieve the same thing
by making the resolv.conf file immutable.  (On Linux.)

Don't get me wrong; I'm sure there is a genuine need for resolvconf
and all this complexity on some systems.  Especially systems that are
designed to be moved around, dynamically connecting and disconnecting
various wireless networks, instantiating and decommissioning VPN sessions,
and so on.

But for a great many *other* systems, we just want to be able edit the
resolv.conf file by hand and have our changes *stay* there, untouched.
We know what we are doing, and the DHCP server is not under our direct
control, and we just need to make the DHCP client keep its hands OFF
the god damned file.

It should *not* be this hard to be allowed to edit a three line text
file that has been in common use across every Unix-like operating system
for decades.

Nevertheless, if someone can definitively state that the following
is true:

   "If you install resolvconf and then do:
      echo resolvconf=NO >> /etc/resolvconf.conf
    no Debian package will ever modify your /etc/resolv.conf again."

then I will be glad to accept it as yet another alternative solution
for some users/systems.

[toc] | [prev] | [next] | [standalone]

#184556

On Wed, Aug 02, 2017 at 02:55:50PM -0400, Greg Wooledge wrote:
> On Wed, Aug 02, 2017 at 08:10:23PM +0200, Pascal Hambourg wrote:
> > Le 02/08/2017 à 16:19, Greg Wooledge a écrit :
> > > 
> > > 1) Make sure the Debian "resolvconf" package is *not* installed.
> > 
> > You should reconsider this advice. resolvconf may be your best ally to
> > handle such a situation.
> 
> OK, I've scanned
> <https://manpages.debian.org/stretch/openresolv/resolvconf.8.en.html> and
> <https://manpages.debian.org/stretch/openresolv/resolvconf.conf.5.en.html>.
> 
> Looks complicated, with lots of specialized words being thrown around
> but not defined.
> 
> E.g. resolvconf(8) says "In some situations resolvconf needs to act as
> a deterrent to writing to /etc/resolv.conf. Where this file cannot be
> made immutable or you just need to toggle this behaviour, resolvconf
> can be disabled by adding resolvconf=NO to resolvconf.conf(5)."
> 
> Looks promising, eh?  But then resolvconf.conf(5) says "Set to NO to
> disable resolvconf from running any subscribers. Defaults to YES."
> 
> What is a "subscriber"?  Definitely not defined in (8).  There's a section
> called "SUBSCRIBER OPTIONS" in (5) but it still doesn't explain what they
> are.
> 
> Back to (8), it says "Where this file cannot be made immutable".  Is it
> *admitting*

To be precise, "implying" is perhaps accurate.


> that making the file immutable is the preferred solution, and
> resolvconf is just a backup plan?  That's what I'm getting out of it.

Perhaps in certain scenarios, yes - the world's full of wierd
networks :)

> I don't see the advantage of installing a package and configuring it
> in order to make it do *nothing*, when I can achieve the same thing
> by making the resolv.conf file immutable.  (On Linux.)
> 
> Don't get me wrong; I'm sure there is a genuine need for resolvconf
> and all this complexity on some systems.  Especially systems that are
> designed to be moved around, dynamically connecting and disconnecting
> various wireless networks, instantiating and decommissioning VPN sessions,
> and so on.
> 
> But for a great many *other* systems, we just want to be able edit the
> resolv.conf file by hand and have our changes *stay* there, untouched.
> We know what we are doing, and the DHCP server is not under our direct
> control, and we just need to make the DHCP client keep its hands OFF
> the god damned file.

If you're wanting a static resolv.conf, are you manually
running dhclient, or using /etc/network/interfaces ?

I.e. is this a one-shot scenario, or a "static" config situation?

> It should *not* be this hard to be allowed to edit a three line text
> file that has been in common use across every Unix-like operating system
> for decades.
> 
> Nevertheless, if someone can definitively state that the following
> is true:
> 
>    "If you install resolvconf and then do:
>       echo resolvconf=NO >> /etc/resolvconf.conf
>     no Debian package will ever modify your /etc/resolv.conf again."
> 
> then I will be glad to accept it as yet another alternative solution
> for some users/systems.

I'm not that knowledgeable, but dhclient is listen in the resolvconf
man page as a "^SUPPLIERS OF NAMESERVER INFORMATION"... so appears to
be intended to work together.

Have you tried also reading man dhclient.conf ?

Good luck,

[toc] | [prev] | [next] | [standalone]

#184567

On Thu, Aug 03, 2017 at 11:09:48AM +1000, Zenaan Harkness wrote:
> Perhaps in certain scenarios, yes - the world's full of wierd
> networks :)

Concrete examples?  OK.

Work system: the Information Technology Division (ITD) runs the DHCP
servers, which are basically built around the assumption that you
will be running the standard Windows 7 desktop PC.  The DHCP server
provides nameserver entries if requested, and a hostname whether you
want it or not.

Meanwhile, over in Unixland, my department has its own network
infrastructure which predates the central ITD infrastructure.  We were
the pioneers, not them.  We have our own subdomain (eeg.ccf.org), our
own authoritative DNS servers and caching resolvers.  Our DNS servers
include proper PTR records for our hosts (ITD's do not).

There is a sharing of responsibility between ITD and my department.
They control the allocation of IP addresses, but we are allowed to request
DHCP reservations.  There is a specific protocol for doing so: we put
our new computer on the network, and configure it as a DHCP client.
We get it all set up, with its DHCP-assigned address.  Then we send
an email to the ITD contact address requesting the DHCP reservation.
They put an entry in whatever software they use so the new system *keeps*
its IP address.

If someone moves the machine to a different floor (which will have a
different network address), then the fact that it's configured as a
DHCP client means it will at least *boot* and (hopefully) come up with
a new IP address.  Then they can call me, I can come down to the new
location, get the IP and MAC, update it in DNS, and send the new
DHCP reservation request to ITD.

But the problem is, various Unix DHCP client daemons do *too much*.
All I want them to do is set the IP address, netmask, and gateway.
I *don't* want them to change the system hostname, or the system
resolv.conf (in which I have hand-placed *our* DNS search domain and
*our* DNS resolvers).

On the HP-UX systems, I modified the boot scripts to accomodate all of
the funky things that happen with DHCP.  I keep master copies of the true
/etc/resolv.conf and /etc/hosts files (plus one other HP-UX-specific
network config file), which all get overwritten by the DHCP client,
and I restore them at just the right time.  I put the hostname and IP
in /etc/hosts so that dtlogin can start.  Also, starting with an update
of ITD's DHCP servers about 5 years ago, the HP-UX DHCP client started
overwriting the system hostname with the one provided by the DHCP server.
So I had to make more changes to work around that as well, restoring
the correct hostname at just the right moment.

(Thank goodness for non-parallel boot systems.)

On the Debian systems, I learned through trial and error that this
change works:

--- /etc/dhcp/dhclient.conf.20170410	2017-04-10 10:12:13.271209076 -0400
+++ /etc/dhcp/dhclient.conf	2017-04-10 10:12:26.291209232 -0400
@@ -14,8 +14,7 @@
 
 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,
+	dhcp6.sntp-servers,
 	netbios-name-servers, netbios-scope, interface-mtu,
 	rfc3442-classless-static-routes, ntp-servers;

If I simply don't ask for DNS nameserver addresses, the DHCP server
doesn't provide them, and dhclient doesn't touch resolv.conf, and everyone
is happy.  The Debian/ISC DHCP client is smart enough to ignore the
hostname coming from DHCP, so I didn't have to do anything there.

(The HP-UX DHCP client does not have this level of control, so I have
to fix things up after the fact.)


Home system: the DHCP server is a Belkin plastic router.  The router
silently forwards DNS queries to the ISP's nameserver, which is tolerable,
but a bit slow.  I would prefer to run a local dnscache resolver (from
djbdns).  The DHCP server provides a nameserver entry whether I request
it or not, and a search domain of "Belkin".

I am not using djbdns from a Debian package.  It's pure upstream.

I have configured the router to assign my IP address to my MAC address.
I just don't want it to touch my resolv.conf file.

At first I tried doing what I did at work: removing lines from the
dhclient.conf file.  But the Belkin DHCP server doesn't stop sending
the nameserver, and dhclient continues to overwrite resolv.conf.

I ended up simply doing chattr +i.


> If you're wanting a static resolv.conf, are you manually
> running dhclient, or using /etc/network/interfaces ?

I use /etc/network/interfaces with

auto eth0
iface eth0 inet dhcp

> I.e. is this a one-shot scenario, or a "static" config situation?

It's "static" in the sense that the configuration is (supposed to
be) unchanging.  But not in the sense of "iface eth0 inet static".
The IP address, netmask and gateway come from DHCP.  The hostname,
nameservers, and everything else come from their respective traditional
Unix or Debian or CentOS config files.

> Have you tried also reading man dhclient.conf ?

wooledg:~$ man dhclient.conf | grep -ic resolv

0
wooledg:~$ man dhclient.conf | grep -ic nameserver

0
wooledg:~$ man dhclient.conf | grep -ic DNS
5

All 5 hits for DNS are in a section named "DYNAMIC DNS", which describes
"very limited support for doing DNS updates when a lease is acquired".

If there is anything in the man page that describes how to make dhclient
*not touch* the resolv.conf file no matter what the DHCP server tells it,
I have not managed to find it.

<https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> (which
I also linked earlier in this thread) apparently went down a very
similar road.  The author came up with a hack that involves modifying
the dhclient backend, overwriting the shell function that does the actual
resolv.conf updates with a function that does nothing.

> the world's full of wierd
> networks :)

I don't think what I'm doing is particularly weird.  "How do I make it
stop overwriting resolv.conf" *is* a FAQ, as that URL says.  There are
many, many people in the world struggling with this every day.

[toc] | [prev] | [next] | [standalone]

#184572

On Thu, Aug 03, 2017 at 08:53:27AM -0400, Greg Wooledge wrote:
> But the problem is, various Unix DHCP client daemons do *too much*.
> All I want them to do is set the IP address, netmask, and gateway.
> I *don't* want them to change the system hostname, or the system
> resolv.conf (in which I have hand-placed *our* DNS search domain and
> *our* DNS resolvers).

Well, making /etc/resolv.conf read-only, owned by root.root, and
uninstalling resolvconf should also solve your problem.

Then programs won't write to the file.

Since you have a long term static nameserver, you're good.


Alternatively, if you might change your setup here and there for a
particular host, I find resolvconf to be the perfect middle ground -
and when it's meant to not update resolv.conf, that "NO" setting
looks like it should work a treat for you.

Or if you comission a laptop which might move daily between
locations, fully dynamic DHCP config might be best - just use network
manager and whatever it depends on, and the default "auto everything"
should work assuming DHCP is set up correctly at your site - just let
the auto-stuff do its auto stuff, and the laptop will mostly work.
Uninstall resolvconf since network manager does it all.

If you in this last (laptop) scenario need specific addition of your
static nameserver, on top of the DHCP nameservers (e.g. one
nameserver might resolve some internal names, the others might
recursively resolve internet names) then configuring resolvonf to
know about your static server and add it "on each dhcp
reconfiguration" will work when properly configured too - either
before or after the DHCP assigned servers (i.e. depending on the
precedence you need for the resolves), this could be another ideal
configuration well served by resolvconf.


That which is ideal, always depends on your requirements. I'm still
not clear on your requirements, but perhaps one of the above
scenarios will satisfy.


> On the HP-UX systems, I modified the boot scripts to accomodate all of
> the funky things that happen with DHCP.  I keep master copies of the true
> /etc/resolv.conf and /etc/hosts files (plus one other HP-UX-specific
> network config file), which all get overwritten by the DHCP client,
> and I restore them at just the right time.

That sounds ugly, and way overly hacky.

I suggest thoroughly reading the resolvconf man page to understand
its workings, and making use of that.

If you don't want to do that for any reason, that's also fine - just
remove resolvconf as suggested by someone else in this thread.


> I put the hostname and IP
> in /etc/hosts so that dtlogin can start.  Also, starting with an update
> of ITD's DHCP servers about 5 years ago, the HP-UX DHCP client started
> overwriting the system hostname with the one provided by the DHCP server.
>
> So I had to make more changes to work around that as well, restoring
> the correct hostname at just the right moment.

Surely this would be easier? :
chmod 400 /etc/hostname


I'm a sure fan of static network config (which includes hostname),
but sure sounds like you might be doing things the hard way.


> On the Debian systems, I learned through trial and error that this
> change works:
> 
> --- /etc/dhcp/dhclient.conf.20170410	2017-04-10 10:12:13.271209076 -0400
> +++ /etc/dhcp/dhclient.conf	2017-04-10 10:12:26.291209232 -0400
> @@ -14,8 +14,7 @@
>  
>  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,
> +	dhcp6.sntp-servers,
>  	netbios-name-servers, netbios-scope, interface-mtu,
>  	rfc3442-classless-static-routes, ntp-servers;
> 
> If I simply don't ask for DNS nameserver addresses, the DHCP server
> doesn't provide them, and dhclient doesn't touch resolv.conf, and everyone
> is happy.  The Debian/ISC DHCP client is smart enough to ignore the
> hostname coming from DHCP, so I didn't have to do anything there.
> 
> (The HP-UX DHCP client does not have this level of control, so I have
> to fix things up after the fact.)

Possibly just compile the ISC DHCP client for HP-UX - a binary
compiled by someone else might even be available.


> Home system: the DHCP server is a Belkin plastic router.  The router
> silently forwards DNS queries to the ISP's nameserver, which is tolerable,
> but a bit slow.  I would prefer to run a local dnscache resolver (from
> djbdns).  The DHCP server provides a nameserver entry whether I request
> it or not, and a search domain of "Belkin".
> 
> I am not using djbdns from a Debian package.  It's pure upstream.

openresolv is a new package I haven't seen before

For DNS cache, I've installed dnsmasq many times over the years -
it's small and simple.



> I have configured the router to assign my IP address to my MAC address.
> I just don't want it to touch my resolv.conf file.
> 
> At first I tried doing what I did at work: removing lines from the
> dhclient.conf file.  But the Belkin DHCP server doesn't stop sending
> the nameserver, and dhclient continues to overwrite resolv.conf.
> 
> I ended up simply doing chattr +i.

If you have a solution working for you, that's great.


> > If you're wanting a static resolv.conf, are you manually
> > running dhclient, or using /etc/network/interfaces ?
> 
> I use /etc/network/interfaces with
> 
> auto eth0
> iface eth0 inet dhcp

You may not know there's a way to do your "scripting" in the
interfaces file:

man interfaces # for help

# take 1:

auto eth0
iface eth0 inet dhcp
	post-up mv /my/resolv.conf /etc/resolv.conf
	post-up chmod 400 /etc/resolv.conf


# take 2:

auto eth0
iface eth0 inet dhcp
	dns-nameserver 192.168.1.254
	dns-nameserver 8.8.8.8
	post-up chmod 400 /etc/resolv.conf


# take 3:

auto eth0
iface eth0 inet dhcp
	post-up mv /my/resolv.conf /etc/resolv.conf
	dns-nameserver 192.168.1.254
	dns-nameserver 8.8.8.8
	post-up chmod 400 /etc/resolv.conf


Play around and see what your resultant /etc/resolv.conf ends up as
in each scenario you try.



> > I.e. is this a one-shot scenario, or a "static" config situation?
> 
> It's "static" in the sense that the configuration is (supposed to
> be) unchanging.  But not in the sense of "iface eth0 inet static".
> The IP address, netmask and gateway come from DHCP.  The hostname,
> nameservers, and everything else come from their respective traditional
> Unix or Debian or CentOS config files.

If it makes it easier for you, you could configure your home router
to match whatever your internal subnet address range/dhcp config at
work.

Anyway, you have a few options to try now.


> > Have you tried also reading man dhclient.conf ?
> 
> wooledg:~$ man dhclient.conf | grep -ic resolv
> 0
> wooledg:~$ man dhclient.conf | grep -ic nameserver
> 0
> wooledg:~$ man dhclient.conf | grep -ic DNS
> 5
> 
> All 5 hits for DNS are in a section named "DYNAMIC DNS", which describes
> "very limited support for doing DNS updates when a lease is acquired".
> 
> If there is anything in the man page that describes how to make dhclient
> *not touch* the resolv.conf file no matter what the DHCP server tells it,
> I have not managed to find it.
>
> <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> (which
> I also linked earlier in this thread) apparently went down a very
> similar road.  The author came up with a hack that involves modifying
> the dhclient backend, overwriting the shell function that does the actual
> resolv.conf updates with a function that does nothing.

Did you see these directories in your travels? :

/etc/dhcp/dhclient-enter-hooks.d
/etc/dhcp/dhclient-exit-hooks.d


> > the world's full of wierd
> > networks :)
> 
> I don't think what I'm doing is particularly weird.  "How do I make it
> stop overwriting resolv.conf" *is* a FAQ, as that URL says.  There are
> many, many people in the world struggling with this every day.

I could at least 3 solutions in this thread now:
 - read only file (looks like you found an attr for this too)
 - resolv.conf "NO" config option
 - post-up sub command in interfaces file


That should be plenty to satisfy your desire for a solution :)

Good luck,

[toc] | [prev] | [next] | [standalone]

#184595

Le 03/08/2017 à 15:52, Zenaan Harkness a écrit :
> On Thu, Aug 03, 2017 at 08:53:27AM -0400, Greg Wooledge wrote:
>> But the problem is, various Unix DHCP client daemons do *too much*.
>> All I want them to do is set the IP address, netmask, and gateway.
>> I *don't* want them to change the system hostname, or the system
>> resolv.conf (in which I have hand-placed *our* DNS search domain and
>> *our* DNS resolvers).
> 
> Well, making /etc/resolv.conf read-only, owned by root.root

... is just useless. resolv.conf is already owned by root, DCHP client 
daemons run as root and on Linux systems root (uid 0) ignores read/write 
permissions.

> uninstalling resolvconf should also solve your problem.

No, it solves nothing. Without resolvonf the DHCP client will write 
directly in resolv.conf.

> If you in this last (laptop) scenario need specific addition of your
> static nameserver, on top of the DHCP nameservers (e.g. one
> nameserver might resolve some internal names, the others might
> recursively resolve internet names)

This does not work.
The resolver stops as soon as it receives a positive (record exists) or 
negative (record does not exist) answer. If it receives a negative 
answer from the first name server, it won't query the next name server.

All name servers declared in resolv.conf must be equal and provide the 
same answers, or unexpected behaviour will happen. Multiple name servers 
is only for redundancy and load balancing, not to provide different answers.

[toc] | [prev] | [next] | [standalone]

#184613

On Thu, Aug 03, 2017 at 08:49:05PM +0200, Pascal Hambourg wrote:
> Le 03/08/2017 à 15:52, Zenaan Harkness a écrit :
> > On Thu, Aug 03, 2017 at 08:53:27AM -0400, Greg Wooledge wrote:
> > > But the problem is, various Unix DHCP client daemons do *too much*.
> > > All I want them to do is set the IP address, netmask, and gateway.
> > > I *don't* want them to change the system hostname, or the system
> > > resolv.conf (in which I have hand-placed *our* DNS search domain and
> > > *our* DNS resolvers).
> > 
> > Well, making /etc/resolv.conf read-only, owned by root.root
> 
> ... is just useless. resolv.conf is already owned by root, DCHP client daemons run as root and on Linux systems root
> (uid 0) ignores read/write permissions.
> 
> > uninstalling resolvconf should also solve your problem.
> 
> No, it solves nothing. Without resolvonf the DHCP client will write directly in resolv.conf.
> 
> > If you in this last (laptop) scenario need specific addition of your
> > static nameserver, on top of the DHCP nameservers (e.g. one
> > nameserver might resolve some internal names, the others might
> > recursively resolve internet names)
> 
> This does not work.
> The resolver stops as soon as it receives a positive (record exists) or negative (record does not exist) answer. If it
> receives a negative answer from the first name server, it won't query the next name server.
> 
> All name servers declared in resolv.conf must be equal and provide the same answers, or unexpected behaviour will
> happen. Multiple name servers is only for redundancy and load balancing, not to provide different answers.

What about putting your script lines (copying files around etc) into
your /etc/network/interfaces file?

Given the uniqueness of how you seem to want to do your networking,
perhaps that's the best option to make it less abnormal - looks like
it to me.

Good luck,

[toc] | [prev] | [next] | [standalone]

#184623

On Fri, 4 Aug 2017 10:59:13 +1000
Zenaan Harkness <zenaan@freedbms.net> wrote:


> 
> Given the uniqueness of how you seem to want to do your networking,
> perhaps that's the best option to make it less abnormal - looks like
> it to me.
> 

I don't think it's really all that unique, or unreasonable, for a
computer user to want to specify a particular DNS server. If an
operating system file needs to be made immutable in order to achieve
this, some programmer somewhere has... made a mistake, to put it kindly.

I wasted twenty minutes the other day, because a functional network
switch connected to a couple of PCs had lost its wired connection to
the rest of the network, which had been OK half an hour earlier. This
simple fault was concealed by the way my Windows laptop was behaving in
the absence of a DHCP server. Despite my efforts, it was ignoring its
previous DHCP address, and my manually entered address, and was
acquiring an APIPA address, thus guaranteeing no possible network
connection ever.

Eventually I worked out that there was a bug causing even worse
misbehaviour than usual, and forced a suitable IP address onto the
machine, when I quickly discovered a lack of connectivity... but if the
damn thing hadn't been so *helpful*, I'd have fixed it much quicker.
There appears to be no way to tell a Windows computer that you never,
ever, *ever* want to see an APIPA address anywhere.

Yes, there's the perpetual argument about how much hand-holding a
non-IT person needs, and it's a lot, and how much should be left to the
user, but whatever the decision, it should always be possible for a
user to insist 'I want it done *this* way'. If that lands him in
trouble, tough, but foot-shooting must *always* be allowed, without an
enormous struggle.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#184639

On Fri, Aug 04, 2017 at 09:01:32AM +0100, Joe wrote:
> On Fri, 4 Aug 2017 10:59:13 +1000
> Zenaan Harkness <zenaan@freedbms.net> wrote:
> > Given the uniqueness of how you seem to want to do your networking,
> > perhaps that's the best option to make it less abnormal - looks like
> > it to me.
> 
> I don't think it's really all that unique, or unreasonable, for a
> computer user to want to specify a particular DNS server. If an

That is absolutely true, and does not discount at all my implication
that "copying my own file over the top of /etc/resolv.conf after
dhclient runs and hoping there's no other race conditions that catch
me out", is perhaps a little "abnormal" in terms of a networking
setup.


> operating system file needs to be made immutable in order to achieve
> this, some programmer somewhere has... made a mistake, to put it kindly.

Or the user is not achieving their outcome due to not using the
installed software in the way it was designed.


> I wasted twenty minutes the other day, because a functional network
> switch connected to a couple of PCs had lost its wired connection to
> the rest of the network, which had been OK half an hour earlier. This
> simple fault was concealed by the way my Windows laptop was behaving in
> the absence of a DHCP server. Despite my efforts, it was ignoring its
> previous DHCP address, and my manually entered address, and was
> acquiring an APIPA address, thus guaranteeing no possible network
> connection ever.

:D - my condolences for your achievement in "using" some feature of
some version of Windows I had never even heard of before :D

> Eventually I worked out that there was a bug causing even worse
> misbehaviour than usual, and forced a suitable IP address onto the
> machine, when I quickly discovered a lack of connectivity... but if the
> damn thing hadn't been so *helpful*, I'd have fixed it much quicker.
> There appears to be no way to tell a Windows computer that you never,
> ever, *ever* want to see an APIPA address anywhere.
> 
> Yes, there's the perpetual argument about how much hand-holding a
> non-IT person needs, and it's a lot, and how much should be left to the
> user, but whatever the decision, it should always be possible for a
> user to insist 'I want it done *this* way'. If that lands him in
> trouble, tough, but foot-shooting must *always* be allowed, without an
> enormous struggle.

Indeed, there are many ways to sking this cat - network manager,
chattr, cp -o "with-crossed fingers" my-resolv.conf /etc/resolv.conf,
manual commands added in /e/n/i, /etc/resolvconf/resolv.conf.d/ -
even the Windows IT guys from the other department of the OP might be
able to update their DHCPd settings to deliver the desired DNS
server, when the MAC addresses get configured - do 2 things at the
same time.

Really, it would be easy to argue there are too many ways to skin
this cat.

Good luck all,

[toc] | [prev] | [next] | [standalone]

#184624

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 03, 2017 at 08:49:05PM +0200, Pascal Hambourg wrote:
> Le 03/08/2017 à 15:52, Zenaan Harkness a écrit :
> >On Thu, Aug 03, 2017 at 08:53:27AM -0400, Greg Wooledge wrote:
> >>But the problem is, various Unix DHCP client daemons do *too much*.
> >>All I want them to do is set the IP address, netmask, and gateway.
> >>I *don't* want them to change the system hostname, or the system
> >>resolv.conf (in which I have hand-placed *our* DNS search domain and
> >>*our* DNS resolvers).
> >
> >Well, making /etc/resolv.conf read-only, owned by root.root
> 
> ... is just useless. resolv.conf is already owned by root, DCHP
> client daemons run as root and on Linux systems root (uid 0) ignores
> read/write permissions.

That's what chattr +i is for. Don't forget to do chattr -i on the file
whenever *you* want to change it :-)

(For me, it's a satisfying feeling when I see the culprits whining
in the logs that they cannot write to the file, but that may be
my hidden sadistic alter ego).

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmELNwACgkQBcgs9XrR2kYNMACfSv64NQre+qFfAXONWOEdADtm
jIoAn3rP30lR8UAeYqvKSrZt55GgM4gU
=SZVO
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#184636

On Fri, Aug 04, 2017 at 10:14:20AM +0200, tomas@tuxteam.de wrote:
> On Thu, Aug 03, 2017 at 08:49:05PM +0200, Pascal Hambourg wrote:
> > Le 03/08/2017 à 15:52, Zenaan Harkness a écrit :
> > >On Thu, Aug 03, 2017 at 08:53:27AM -0400, Greg Wooledge wrote:
> > >>But the problem is, various Unix DHCP client daemons do *too much*.
> > >>All I want them to do is set the IP address, netmask, and gateway.
> > >>I *don't* want them to change the system hostname, or the system
> > >>resolv.conf (in which I have hand-placed *our* DNS search domain and
> > >>*our* DNS resolvers).
> > >
> > >Well, making /etc/resolv.conf read-only, owned by root.root
> > 
> > ... is just useless. resolv.conf is already owned by root, DCHP
> > client daemons run as root and on Linux systems root (uid 0) ignores
> > read/write permissions.
> 
> That's what chattr +i is for. Don't forget to do chattr -i on the file
> whenever *you* want to change it :-)

Another command that could be add to /e/n/i :)

[toc] | [prev] | [next] | [standalone]

#184666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Aug 05, 2017 at 12:11:28AM +1000, Zenaan Harkness wrote:
> On Fri, Aug 04, 2017 at 10:14:20AM +0200, tomas@tuxteam.de wrote:

[chattr]

> Another command that could be add to /e/n/i :)

you nasty ;-)

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmFfiQACgkQBcgs9XrR2kYTgACfXqQfkrNsHoIrcZb6jGyVywwC
UogAnRT9hQJ0ly979kDQVpaSwqqKWUK1
=XWhS
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#184678

On Saturday 05 August 2017 04:13:24 tomas@tuxteam.de wrote:

> On Sat, Aug 05, 2017 at 12:11:28AM +1000, Zenaan Harkness wrote:
> > On Fri, Aug 04, 2017 at 10:14:20AM +0200, tomas@tuxteam.de wrote:
>
> [chattr]
>
> > Another command that could be add to /e/n/i :)
>
> you nasty ;-)
>
> cheers
> -- t

Why do you say that Tomas? I've been using it precisely because the early 
versions of network mangler could not be removed without emasculating 
the whole system, AND it couldn't find a dhcpd server with both hands 
even if it was nailed to its ass. So it would tear down a working 
network config and leave you stuck.

My address xxxx = hostname based home network, several machines, Just 
Works(TM).  So I sit here and wonder why an estimated 50% of the posts 
here are network failures. But I got tired of advising how to make it 
Just Work(TM) and being called an idiot for doing so. So I sit, read, 
and chuckle.

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]

#184679

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Aug 05, 2017 at 10:37:42AM -0400, Gene Heskett wrote:
> On Saturday 05 August 2017 04:13:24 tomas@tuxteam.de wrote:
> 
> > On Sat, Aug 05, 2017 at 12:11:28AM +1000, Zenaan Harkness wrote:
> > > On Fri, Aug 04, 2017 at 10:14:20AM +0200, tomas@tuxteam.de wrote:
> >
> > [chattr]
> >
> > > Another command that could be add to /e/n/i :)
> >
> > you nasty ;-)
> >
> > cheers
> > -- t
> 
> Why do you say that Tomas?

Mind the smilie. Zenaan's post has also one.

This chattr thing is a good way to get out of trouble in a pinch
("who the %&@$!# is overvriting my /etc/ponies.d/foo file?"). It
might even help finding out the root cause (once you find it,
you'll also discover the small print in the man page, which was
stating clearly what's up.

Zenaan idea of perpetuating this (useful but ugly) hack in e/n/i
seemed... well, nasty. But funny :-)

> I've been using it precisely because the early 
> versions of network mangler could not be removed without emasculating 
> the whole system, AND it couldn't find a dhcpd server with both hands 
> even if it was nailed to its ass. So it would tear down a working 
> network config and leave you stuck.
> 
> My address xxxx = hostname based home network, several machines, Just 
> Works(TM).  So I sit here and wonder why an estimated 50% of the posts 
> here are network failures. But I got tired of advising how to make it 
> Just Work(TM) and being called an idiot for doing so. So I sit, read, 
> and chuckle.

That's OK, and works... for fixed networks. Networks I have control
over are like that. Each machine there has a static IP address. Only
laptops (which come and go, and are sometimes on other nets) get
an address via DHCP.

No idea why anyone would want to call you an idiot for that.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmF3HoACgkQBcgs9XrR2kZgowCbBGjeUBeNW0B3wbLrRQH981My
2aQAoIIHLFMR8lYcerZQBf0Vbg5K9G2D
=o3Sm
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#184555

On Wed, Aug 02, 2017 at 05:44:50PM +0400, ruslan axundov wrote:
> Hi
> 
> I have a problem with debian 9 as static nameserver .
> So that I used before ubuntu 16.04  and I have configure satatic ip and dns
> and it worked perfectly  but today I tried to use debian 9 and  when I
> enter static dns server for debian in resolve.conf  then after reboot
> debian all dns ip removed from resolv.conf file. I tried multiple method to
> prevent this feature but nothing happen. what I must do ?

I've preferred a static networking config for years, and resolvconf
works well in this situation - but once resolvconf is configured,
I've always put the dns setting in /etc/networks/interfaces - the
only time I put an entry in /etc/resolv.conf is when I'm testing
stuff or doing a quick hack.

Static network configs are quicker and give that sense of control -
if the gui is down I can still fix things, and my knowledge applies
in both gui and console scanerios.

Good luck,

[toc] | [prev] | [next] | [standalone]

#184578

[Multipart message — attachments visible in raw view] — view raw

On 08/02/2017 06:56 PM, Zenaan Harkness wrote:
>
> I've preferred a static networking config for years, and resolvconf
> works well in this situation - but once resolvconf is configured,
> I've always put the dns setting in /etc/networks/interfaces

I agree with this as well. If you want to use static configuration and want resolvconf installed, you need to use the dns-* options in /etc/network/interfaces. resolvconf will then update your /etc/resolv.conf file with those options. If you change /etc/resolv.conf manually, resolvconf will override those settings periodically. The alternative is to simply uninstall resolvconf and set your DNS settings manually.

>  - the
> only time I put an entry in /etc/resolv.conf is when I'm testing
> stuff or doing a quick hack.
>
> Static network configs are quicker and give that sense of control -
> if the gui is down I can still fix things, and my knowledge applies
> in both gui and console scanerios.

Configuration in /etc/network/interfaces only works when NetworkManager isn't installed, which it typically is in GUI environments. If you don't have it installed in your GUI environment then yes, it works in both. If NetworkManager is installed then the nmcli command should be used and you shouldn't do any configuration in /etc/network/interfaces (although loopback is typically still controlled through this file).

Thanks,
Joshua Schaeffer

[toc] | [prev] | [next] | [standalone]

#184596

Le 03/08/2017 à 17:20, Joshua Schaeffer a écrit :
> 
> Configuration in /etc/network/interfaces only works when NetworkManager isn't installed,

Wrong. The default NetworkManager behaviour is not to manage interfaces 
defined in /etc/network/interfaces.

[toc] | [prev] | [next] | [standalone]

#184600

On Thu, Aug 03, 2017 at 08:53:06PM +0200, Pascal Hambourg wrote:
> Le 03/08/2017 à 17:20, Joshua Schaeffer a écrit :
> > 
> > Configuration in /etc/network/interfaces only works when NetworkManager isn't installed,
> 
> Wrong. The default NetworkManager behaviour is not to manage interfaces
> defined in /etc/network/interfaces.
> 


Well, that is also partly wrong.
There was definitely an issue with a mix of /e/n/i and NM and systemd.
If the device couldn't be brought up during system start systemd would hang
sometimes for a very long time. This was at least true for Jessie.

-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web