ON POSSIBLE CHANGES TO IP OR HOSTNAME
According to the logs there is no renewal request. The machine is still
sitting there with the same IP, but that information is purged from bind
and the dhcpd.leases file indicates the lease is no longer active.
ANALYSIS OF THE PROBLEM
I think the basic problem is that there are 2 points for network
configuration during the boot process. The "early" point occurs at initial
PXE boot when the client asks for an IP and all the associated PXE boot
information, which is provided by dhcpd and tftpd and their config files.
The "regular" point occurs after the pivot from the initrd so supplied onto
the full system. The regular point is where ifup and
/etc/network/interfaces (and NetworkManager and other technologies) come
into play. dhclient is ordinarily triggered at the regular point, but
since I haven't set the interface to auto there is no "regular"
configuration, no dhclient, and no renewal of the lease. Further, some of
the info from dhcp, like the domain name, doesn't make it from the early
setup to the regular system.
EXPERIMENT: ENABLE AUTO
I disabled "auto eno1" in /etc/network/interfaces because having the
interface configured twice led to trouble in the past--but tried turning it
back on.
This did get dhclient to run. But .... the client machine sent 2 requests
for an IP to dhcpd (one "early" and the other "regular", I assume). As
before, the early request got the IP I was using before, and dhcpd
successfully asked bind to add info to DDNS.
The "regular" request got a different IP back from dhcpd. When dhcpd
attempted to update DDNS various preconditions failed, so the DDNS info was
unchanged, and remained set for the first IP.
dhcpd.leases has entries for both IP's and ip addr on the client machine
shows the card associated with both IPs. dhclient is also running on the
client machine.
When time for the lease of the first IP expires, dhcpd marks the lease as
free and deletes the entries from DDNS. Sometime later, when dhclient
renews the 2nd IP, that info is successfully written to DDNS.
Aside from this being ugly, it means there are times when the client
machine can't be found in DNS, and its apparent IP changes. There is also
the theoretical possibility that DHCP would hand out the "early" IP to
another machine (although maybe broadcasts would catch the problem before
it happened). Since the original client still thinks it owns that IP,
there would be 2 machines that respond to the same IP.
I don't know if changing the interface IP is ever OK for a machine that is
nfsroot.
POSSIBLE WORK-AROUNDS
1) configure a lease time longer than the machine is likely to be up for
the nfsroot machine. Disable auto in interfaces.
2) leave current configuration (with auto) and hope the theoretical
problems remain theoretical and the periods when DNS lookups for the
machine are brief
3) configure the machine with a fixed IP in dhcp, which the docs recommend
for nfsroot clients anyway. Possibly this would eliminate the current
handout of 2 different IPs for the same MAC.
4) hardcode fixed info into DNS so there's no dynamic updating at all.
The clients will not necessarily be booting the same software all the time,
and I might want the different systems to have different names. That might
not be such a good fit for 3 or 4.
Ross
On Sun, Jul 19, 2020 at 8:54 AM Nicholas Geovanis <nickgeova...@gmail.com>
wrote:
> On a first guess, maybe at the renewal your IP address and/or hostname are
> changing unexpectedly. Check for duplicate sources for address resolution,
> say duplicate entries in /etc/hosts. Check the resolution order in
> resolv.conf to make sure it's what you expect. Make sure that dhcpd.conf
> measures up to them. Also check if your IP interface names are changing
> unexpectedly.
>
> On Sun, Jul 19, 2020, 12:36 AM Ross Boylan <rossboy...@stanfordalumni.org>
> wrote:
>
>> Running isc-dhcp-server, bind9, and tftpd-hpa I netboot a diskless
>> system, and entries for it go into DNS. But 30 minutes later they are
>> withdrawn, presumably by dhcpd.
>> I've enabled a lot of logging, but am having trouble getting a fix on
>> what the problem is. Any suggestions? 30 minutes is my dhcp lease time; I
>> assume that's the trigger for the deletion.
>>
>> I don't see any DHCP requests from the netboot system after the initial
>> one. I don't think I've messed with the standard configuration there, and
>> so I don't know why it wouldn't request a renewal. I can still ping or ssh
>> into the system using the IP. The /var/lib/dhcp/dhclient.eno1.leases file
>> is over a year old.
>>
>> Netbooting means the netboot system is assigned an IP before it's live,
>> and it would probably be dangerous if it attempted to reconfigure the
>> interface when it normally happens in the boot sequence. So maybe
>> dhclient doesn't run (though it's certainly mentioned in the logs) -> never
>> requests lease renewal -> dhcpd decides the system has gone away?
>>
>> Possibly relevant peculiarities:
>> Only clients with key can update DNS.
>> dhcpd.conf includes
>> ddns-update-style standard;
>> ignore client-updates; # since clients don't have they key their
>> updates would fail
>> and the host section for the netbooted host includes
>> ddns-hostname "family2";
>> The netbooted machine is getting an IP handed out from dhcpd from a range
>> declaration.
>> bind is using views, with only the inside view getting updates.
>>
>> Server and client both running Debian stable/buster.
>>
>> Thanks.
>>
>> Ross
>>
>> Further details follow.
>>
>> Logs from the update channel of bind:
>> 18-Jul-2020 17:44:10.007 update: info: client @0x7f941c0f58c0
>> 127.0.0.1#51353/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': adding an RR at 'family2.betterworld.us' A
>> 192.168.1.151
>> 18-Jul-2020 17:44:10.007 update: info: client @0x7f941c0f58c0
>> 127.0.0.1#51353/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': adding an RR at 'family2.betterworld.us' DHCID
>> AAABx0AZqf15+Bp6fgMzfCJt/GsFFTG5pBI4GUqlLfBeIaE=
>> 18-Jul-2020 17:44:10.007 update: debug 3: client @0x7f941c0f58c0
>> 127.0.0.1#51353/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': checking for NSEC3PARAM changes
>> 18-Jul-2020 17:44:10.036 update: info: client @0x7f93fc0089d0
>> 127.0.0.1#60313/key rndc-key: view inside: updating zone
>> '1.168.192.in-addr.arpa/IN': deleting rrset at '151.1.168.192.in-addr.arpa'
>> PTR
>> 18-Jul-2020 17:44:10.036 update: info: client @0x7f93fc0089d0
>> 127.0.0.1#60313/key rndc-key: view inside: updating zone
>> '1.168.192.in-addr.arpa/IN': adding an RR at '151.1.168.192.in-addr.arpa'
>> PTR family2.betterworld.us.
>> 18-Jul-2020 17:44:10.036 update: debug 3: client @0x7f93fc0089d0
>> 127.0.0.1#60313/key rndc-key: view inside: updating zone
>> '1.168.192.in-addr.arpa/IN': checking for NSEC3PARAM changes
>> 18-Jul-2020 18:14:09.211 update: info: client @0x7f941f25b9c0
>> 127.0.0.1#42741/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': deleting an RR at family2.betterworld.us A
>> 18-Jul-2020 18:14:09.211 update: debug 3: client @0x7f941f25b9c0
>> 127.0.0.1#42741/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': checking for NSEC3PARAM changes
>> 18-Jul-2020 18:14:09.232 update: info: client @0x7f941c11e280
>> 127.0.0.1#40175/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': deleting an RR at family2.betterworld.us DHCID
>> 18-Jul-2020 18:14:09.232 update: debug 3: client @0x7f941c11e280
>> 127.0.0.1#40175/key rndc-key: view inside: updating zone '
>> betterworld.us/IN': checking for NSEC3PARAM changes
>> 18-Jul-2020 18:14:09.254 update: info: client @0x7f9418012c80
>> 127.0.0.1#48249/key rndc-key: view inside: updating zone
>> '1.168.192.in-addr.arpa/IN': deleting rrset at '151.1.168.192.in-addr.arpa'
>> PTR
>> 18-Jul-2020 18:14:09.255 update: debug 3: client @0x7f9418012c80
>> 127.0.0.1#48249/key rndc-key: view inside: updating zone
>> '1.168.192.in-addr.arpa/IN': checking for NSEC3PARAM changes
>>
>> From the netboot client system, /etc/network/interface includes
>> iface eno1 inet dhcp
>> for the relevant interface, but no auto or allow-hotplug for it.
>> The startup logs show the first entry ~30 seconds after the 17:44:10
>> above. Here are just the lines I thought relevant:
>> Jul 18 17:44:31 family2 systemd[1]: Starting Raise network interfaces...
>> Jul 18 17:44:31 family2 systemd-udevd[315]: Using default interface
>> naming scheme 'v240'.
>> Jul 18 17:44:31 family2 systemd-udevd[315]: link_config: autonegotiation
>> is unset or enabled, the speed and duplex are not writable.
>> Jul 18 17:44:31 family2 kernel: [ 0.231325] audit: initializing
>> netlink subsys (disabled)
>> Jul 18 17:44:31 family2 kernel: [ 0.231387] audit: type=2000
>> audit(1595119456.036:1): state=initialized audit_enabled=0 res=1
>> Jul 18 17:44:31 family2 kernel: [ 0.278885] NET: Registered protocol
>> family 2
>> Jul 18 17:44:31 family2 kernel: [ 0.279045] tcp_listen_portaddr_hash
>> hash table entries: 4096 (order: 4, 65536 bytes)
>> Jul 18 17:44:31 family2 kernel: [ 0.279135] TCP established hash table
>> entries: 65536 (order: 7, 524288 bytes)
>> Jul 18 17:44:31 family2 kernel: [ 0.279291] TCP bind hash table
>> entries: 65536 (order: 8, 1048576 bytes)
>> Jul 18 17:44:31 family2 kernel: [ 0.279441] TCP: Hash tables
>> configured (established 65536 bind 65536)
>> Jul 18 17:44:31 family2 kernel: [ 0.279522] UDP hash table entries:
>> 4096 (order: 5, 131072 bytes)
>> Jul 18 17:44:31 family2 kernel: [ 0.279595] UDP-Lite hash table
>> entries: 4096 (order: 5, 131072 bytes)
>> Jul 18 17:44:31 family2 kernel: [ 0.279694] NET: Registered protocol
>> family 1
>> Jul 18 17:44:31 family2 kernel: [ 0.279751] NET: Registered protocol
>> family 44
>> Jul 18 17:44:31 family2 kernel: [ 1.078485] e1000e: Intel(R) PRO/1000
>> Network Driver - 3.2.6-k
>> Jul 18 17:44:31 family2 kernel: [ 1.078548] e1000e: Copyright(c) 1999
>> - 2015 Intel Corporation.
>> Jul 18 17:44:31 family2 kernel: [ 1.078796] e1000e 0000:00:19.0:
>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>> Jul 18 17:44:31 family2 kernel: [ 1.209069] e1000e 0000:00:19.0
>> 0000:00:19.0 (uninitialized): registered PHC clock
>> Jul 18 17:44:31 family2 kernel: [ 1.338809] e1000e 0000:00:19.0 eth0:
>> (PCI Express:2.5GT/s:Width x1) 4c:72:b9:42:ba:c3
>> Jul 18 17:44:31 family2 kernel: [ 1.338814] e1000e 0000:00:19.0 eth0:
>> Intel(R) PRO/1000 Network Connection
>> Jul 18 17:44:31 family2 kernel: [ 1.338854] e1000e 0000:00:19.0 eth0:
>> MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
>> Jul 18 17:44:31 family2 kernel: [ 1.339678] e1000e 0000:00:19.0 eno1:
>> renamed from eth0
>> Jul 18 17:44:32 family2 NetworkManager[347]: <info> [1595119472.6658]
>> monitoring ifupdown state file '/run/network/ifstate'.
>> Jul 18 17:44:32 family2 systemd[1]: Started Network Manager.
>> Jul 18 17:44:32 family2 systemd[1]: Starting Hostname Service...
>> Jul 18 17:44:32 family2 systemd[1]: Starting Network Manager Wait
>> Online...
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.0010]
>> hostname: hostname: using hostnamed
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.0010]
>> hostname: hostname changed from (none) to "family2"
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.0017]
>> dns-mgr[0x55859729f130]: init: dns=default, rc-manager=resolvconf
>> Jul 18 17:44:33 family2 dbus-daemon[346]: [system] Activating via
>> systemd: service name='org.freedesktop.nm_dispatcher'
>> unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.8'
>> (uid=0 pid=347 comm="/usr/sbin/NetworkManager --no-daemon ")
>> Jul 18 17:44:33 family2 systemd[1]: Starting Network Manager Script
>> Dispatcher Service...
>> Jul 18 17:44:33 family2 dbus-daemon[346]: [system] Successfully activated
>> service 'org.freedesktop.nm_dispatcher'
>> Jul 18 17:44:33 family2 systemd[1]: Started Network Manager Script
>> Dispatcher Service.
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2851]
>> ifupdown: interface-parser: parsing file /etc/network/interfaces
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2852]
>> ifupdown: interface-parser: source line includes interfaces file(s)
>> /etc/network/interfaces.d
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2941]
>> ifupdown: interface-parser: finished parsing file
>> /etc/network/interfaces
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2943]
>> ifupdown: guessed connection type (eno1) = 802-3-ethernet
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2944]
>> ifupdown: update_connection_setting_from_if_block: name:eno1,
>> type:802-3-ethernet, id:Ifupdown (eno1), uuid:
>> 1c8633f8-7f9d-dc05-cc57-22a3458c15a9
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2946]
>> ifupdown: management mode: unmanaged
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2946]
>> settings: Loaded settings plugin: SettingsPluginIfupdown
>> ("/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-settings-plugin-ifupdown.so")
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2946]
>> settings: Loaded settings plugin: NMSKeyfilePlugin (internal)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2962]
>> manager: rfkill: WiFi enabled by radio killswitch; enabled by state file
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2964]
>> manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2966]
>> manager: Networking is enabled by state file
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.2972]
>> dhcp-init: Using DHCP client 'dhclient'
>> Jul 18 17:44:33 family2 nm-dispatcher: req:1 'hostname': new request (1
>> scripts)
>> Jul 18 17:44:33 family2 nm-dispatcher: req:1 'hostname': start running
>> ordered scripts...
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.3483]
>> Loaded device plugin: NMTeamFactory
>> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-device-plugin-team.so)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.3916]
>> Loaded device plugin: NMWwanFactory
>> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-device-plugin-wwan.so)
>> Jul 18 17:44:33 family2 systemd[1]: Started Modem Manager.
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.4399]
>> Loaded device plugin: NMAtmManager
>> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-device-plugin-adsl.so)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.4722]
>> Loaded device plugin: NMBluezManager
>> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-device-plugin-bluetooth.so)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5023]
>> Loaded device plugin: NMWifiFactory
>> (/usr/lib/x86_64-linux-gnu/NetworkManager/1.14.6/libnm-device-plugin-wifi.so)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5033]
>> device (lo): carrier: link connected
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5039]
>> manager: (lo): new Generic device
>> (/org/freedesktop/NetworkManager/Devices/1)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5046]
>> device (eno1): carrier: link connected
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5051]
>> manager: (eno1): new Ethernet device
>> (/org/freedesktop/NetworkManager/Devices/2)
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5169]
>> modem-manager: ModemManager available
>> Jul 18 17:44:33 family2 NetworkManager[347]: <info> [1595119473.5173]
>> manager: startup complete
>> Jul 18 17:44:33 family2 systemd[1]: Started Network Manager Wait Online.
>> Jul 18 17:44:33 family2 systemd[1]: Reached target Network is Online.
>>
>
