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.
