Bug 1766944

Postponing to RHEL 8.3 as this is quite a big change and needs further discussion regarding which policy to adopt in case there is more than one active device each with its set of nameservers.

There also appears to be a need for the DHCP server to pass out a default gateway as well.  Our DHCP server was passing out reserved IP addresses and the DNS A and PTR records for host existed however the hostname was ignored and the host ended up with localhost.localdomain.  Once we added the option router to our dhcpd.conf the host picked up the proper hostname.

*** Bug 1766945 has been marked as a duplicate of this bug. ***

When we opened this, just over a year ago now, it was for RHEL7. 

We realise that there is unlikely to be a fix for RHEL7.  (We have developed a partial workaround, which is just about good enough for us, although not ideal.) 

But we are now planning our RHEL8 rollout.  Please could you give us an update on the progress you have made, and your estimated date for when we can expect the fix for RHEL8.  Thanks.

-- David Lee
-- Diamond Light Source, UK

I'm setting Needinfo on the developer, I have no idea why this doesn't move forward.

Hi, this is planned for RHEL 8.4.

Hi Renaud and David,

I have created a merge request that adds some properties to
NetworkManager connection profiles to control how the hostname is
assigned. The new properties are

 hostname.priority
 hostname.from-dhcp
 hostname.from-dns-lookup
 hostname.only-from-default

Setting the last property to FALSE for a specific connection, the
hostname (from DHCP or reverse DNS lookup) will be used even if the
connection doesn't have the default route. The property can be also
set globally for all connections, for example adding a configuration
file /etc/NetworkManager/conf.d/10-hostname.conf containing:

 [connection]
 hostname.only-from-default=0

If there are multiple connections active, NetworkManager first tries
the connection that was activated first. The order of evaluation can
be changed using the hostname.priority property.

What do you think? Would this solve your issue?

Great, that would work I guess.

Beniamino: Many thanks for picking this up.

I don't know the insides of NetworkManager, so cannot really comment on the detail.

Keep in mind our original bug report, which is specifically about a kickstart environment.  Does your proposed fix cover that?

Our context is a kickstart environment, where (presumably) very little user-adjustable NetworkManager configuration is available.  We had two networks which we were expecting to behave the same way: namely, for the host being installed to pick up its hostname from DHCP.  But this fails consistently on one of those networks (and works consistently on the other).  Even to understand the problem, we were forced to resort to network tracing.  What we discovered was that the host being kickstarted responded differently in a highly unexpected way to the DHCP information it received:

 *  where things worked (i.e. the host being kickstarted correctly got the hostname) the DHCP information contained a default route;
 *  where things failed (i.e. the host being kickstarted did not get its hostname) the DHCP information did not contain a default route

In both cases, the incoming DHCP information contained the hostname.  But the kickstart process fails to act on it when the DHCP information does not contain a default route.

(We did a proof-of-concept check: for the failing "no default route" network, we briefly added a "default route" at the DHCP server, and that fixed it.  But we cannot make that our solution because, for local operational reasons, although we run the two DHCP networks as similarly as possible, this difference in presence/absence of giving a default route is an essential difference.  We must run with this difference.)

Summary:

Our bug report relates to kickstart.  We found that DHCP hostname is ignored when the DHCP information legitimately has no "default route".  We believe this is a bug in the kickstart process, because the hostname is honoured when "default route" is present in the DHCP information.

 
So our requirement, as in the original bug report, is that kickstart should use the hostname regardless of the presence or absence of the "default route".  We would need any fix to be workable in a kickstart environment: either as default behaviour, or at least as a configurable option.  If the latter, then the fix should also include the relevant update to kickstart documentation.

I hope that helps.

I see this is now marked as "Fixed In Version: NetworkManager-1.30.0-0.3.el8".  Thank you.

Please could you confirm that the kickstart environment is also fixed by this.  That is, that its algorithm follows the same pattern for host-name determination regardless of the presence or absence of default-route in the earlier DHCP response.

If the different behaviour persists by default (why would it?) please could you outline what steps a site will need to take in its kickstart set-up to get the hostname behaviour the same.  (For instance, could you let me see the proposed addition to the kickstart documentation.)

Thanks.

Hi David,

sorry but I missed your comment 14.

With the new properties, NetworkManager can be configured to honor the
hostname from DHCP from all connections (with or without the default
route). For backwards compatibility reasons, however this behaviour is
not the default.

What is needed in your case is to have the
'hostname.only-from-default' property globally set to '0' in a
[connection] section of /etc/NetworkManager/NetworkManager.conf or in
a configuration snippet inside 'conf.d/'. However, since you need the
hostname during installation, this property must be set before NM is
started in the installation boot.

I am not that familiar with kickstart, so let's ask to the installation
team.

Radek, do you think one of the following approaches is feasible in a
kickstart file?

1) if possible, let the kickstart update NM configuration before NM is
started

2) if solution 1) is not possible, then the kickstart should update
the NM configuration, make NM aware of it by reloading the service
("systemctl reload NetworkManager") and then reactivate the
connection.

Thanks

(In reply to Beniamino Galvani from comment #16)
> Hi David,
> 
> sorry but I missed your comment 14.
> 
> With the new properties, NetworkManager can be configured to honor the
> hostname from DHCP from all connections (with or without the default
> route). For backwards compatibility reasons, however this behaviour is
> not the default.
> 
> What is needed in your case is to have the
> 'hostname.only-from-default' property globally set to '0' in a
> [connection] section of /etc/NetworkManager/NetworkManager.conf or in
> a configuration snippet inside 'conf.d/'. However, since you need the
> hostname during installation, this property must be set before NM is
> started in the installation boot.
> 
> I am not that familiar with kickstart, so let's ask to the installation
> team.
> 
> Radek, do you think one of the following approaches is feasible in a
> kickstart file?
> 
> 1) if possible, let the kickstart update NM configuration before NM is
> started

This could be eventually done by installer boot option (something like inst.nm.hostname.only-from-default). As a global modification of installer environment this does not seem to belong to kickstart.
Also it would apply only to devices/connections configured by kickstart after switch root (NM activating connections in initramfs would be unaffected in this respect).

> 
> 2) if solution 1) is not possible, then the kickstart should update
> the NM configuration, make NM aware of it by reloading the service
> ("systemctl reload NetworkManager") and then reactivate the
> connection.

This seems to me like a too fragile solution having potential to break common use cases.
May be actually applied by doing this via %pre section kickstart script[1], eg with nmcli command ?

[1] https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-4-pre-installation-script

CI test added:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/689

Hi, 

I am virt QE, NetworkManager-1.30.0-0.3.el8.x86_64 introduces a difference, that is hostname is localhost.localdomain when start a VM with default network setting.

I tried to add the following setting in /etc/NetworkManager/NetworkManager.conf, but still got the hostname localhost.localdomain.
[connection]
hostname.only-from-default=0

My expectation is to get hostname from DHCP or reverse DNS lookup, like dhcp183-227.ml3.eng.bos.redhat.com. Could you please to help what else should I do?

Thanks all, NetworkManager-1.30.0-0.4.el8.x86_64 solve my problem.

Host/guest version:
NetworkManager-1.30.0-0.4.el8.x86_64

Steps:
1. Update NetworkManager-1.30.0-0.4.el8.x86_64 on the host
2. Install a VM
3. login to VM, the hostname is still localhost, update NetworkManager on the guest
4. Reboot the guest
5. login to guest, and hostname is resolved to dhcp183-70.

Actual result:
Hostname resolved to dhcp183-70 on the guest.

Expected result:
Same as above.

Referring to @xichen 15/Dec/2020:

As I read it, this doesn't look sufficient.  It doesn't seem to demonstrate solving the original bug.  What is needed is that the hostname can be determined during the kickstart process.

Let's backtrack:

  *  If DHCP offers default route, then the kickstart process requests the hostname and this is available throughout the kickstart process.
  *  BUT... and here's the bug... if DHCP does not offer default route, then the kickstart process does not request the hostname and is unable to know the hostname.

IN THIS CONTRAST LIES THE BUG.

The required fix is that the kickstart process requests the hostname in BOTH the above instances.

Xichen's comment was about updating NetworkManager AFTER the installation had already been done

But the bug report is about ensuring (presumably) that the NM downloaded in those earliest stages of kickstart requests the hostname.

A suitable demonstration would be:

  * reproduce the above problem (including the bug-difference between default-route and non-default-route environments; Xichen's comment seems to show that
  * adjust the kickstart download to include the new NM, and now demonstrate that both environments (default-route and non-default-route:  Xichen's comment doesn't include this

Thanks for your work on this.  I hope this helps.

-- David Lee

Hi David,




I noticed the compose RHEL-8.4.0-20201215.d.2 is out, so test again. The result is hostname is resolved after reboot of the installation, but in post-installation the hostname is still be localhost.localdomain.

Version:
NetworkManager-1.30.0-0.4.el8.x86_64


Steps and details:
1. Add below configurations in /etc/NetworkManager/NetworkManager.conf

[connection]
hostname.priority=1
hostname.from-dhcp=1
hostname.from-dns-lookup=1
hostname.only-from-default=0

2. In my kickstart cfg, network setting is network --bootproto=dhcp, and in my case it has default route.
3. In my post-installation script, I try to fetch hostname, and find out it is localhost.localdomain. In my previous test log, for example with NetworkManager-1.30.0-0.2.el8.x86_64, it can fetch hostname like dhcp180-243.ml3.eng.bos.redhat.com. I am not sure this difference is bug or not.
4. I logged in to the guest, hostname dhcp182-88 is resolved.

(In reply to David Lee from comment #34)
> Referring to @xichen 15/Dec/2020:
> 
> As I read it, this doesn't look sufficient.  It doesn't seem to demonstrate
> solving the original bug.  What is needed is that the hostname can be
> determined during the kickstart process.
> 
> Let's backtrack:
> 
>   *  If DHCP offers default route, then the kickstart process requests the
> hostname and this is available throughout the kickstart process.
>   *  BUT... and here's the bug... if DHCP does not offer default route, then
> the kickstart process does not request the hostname and is unable to know
> the hostname.
> 
> IN THIS CONTRAST LIES THE BUG.
> 
> The required fix is that the kickstart process requests the hostname in BOTH
> the above instances.
> 
> Xichen's comment was about updating NetworkManager AFTER the installation
> had already been done
> 
> But the bug report is about ensuring (presumably) that the NM downloaded in
> those earliest stages of kickstart requests the hostname.
> 
> A suitable demonstration would be:
> 
>   * reproduce the above problem (including the bug-difference between
> default-route and non-default-route environments; Xichen's comment seems to
> show that
>   * adjust the kickstart download to include the new NM, and now demonstrate
> that both environments (default-route and non-default-route:  Xichen's
> comment doesn't include this
> 
> Thanks for your work on this.  I hope this helps.
> 
> -- David Lee


Hi David,

I guess you are needing info from me, my email is zixchen. I noticed the compose RHEL-8.4.0-20201215.d.2 is out now, so test it again. The result is hostname is resolved after reboot of the installation, but in post-installation the hostname is still be localhost.localdomain.

Version:
NetworkManager-1.30.0-0.4.el8.x86_64


Steps and details:
1. Add below configurations in /etc/NetworkManager/NetworkManager.conf

[connection]
hostname.priority=1
hostname.from-dhcp=1
hostname.from-dns-lookup=1
hostname.only-from-default=0

2. In my kickstart cfg, network setting is network --bootproto=dhcp, and in my case it has default route.
3. In my post-installation script, I try to fetch hostname, and find out it is localhost.localdomain. In my previous test log, for example with NetworkManager-1.30.0-0.2.el8.x86_64, it can fetch hostname like dhcp180-243.ml3.eng.bos.redhat.com. I am not sure this difference is bug or not.
4. I logged in to the guest, hostname dhcp182-88 is resolved.

(In reply to David Lee from comment #34)
>   *  If DHCP offers default route, then the kickstart process requests the
> hostname and this is available throughout the kickstart process.
>   *  BUT... and here's the bug... if DHCP does not offer default route, then
> the kickstart process does not request the hostname and is unable to know
> the hostname.
> 
> IN THIS CONTRAST LIES THE BUG.

Hi, you are right, the current fix isn't enough yet to cover the
original bug. As mentioned previously, we believe that allowing NM to
obtain by default the hostname (via DHCP or DNS lookup) from any
interface without default route would be a big change in behavior with
a potential to break existing users.

The idea is to make this configurable in NM and then have a way to
enable the new behavior during installation. The work done so far is
about the NM part.

In comments 16 and 20 there are some proposals on how to enable
the new behavior. I didn't manage to investigate them, but I plan to do
that once the NM part is working properly.

Beiamino:  Many thanks for your reply.

//we believe that allowing NM to obtain by default the hostname (via DHCP or DNS lookup) from any interface without default route would be a big change in behavior with a potential to break existing users.//

Well, yes, I suppose it might be termed a change to behaviour.  But it is not a change to documented behaviour,  (Is it?)   It is a a bug fix, surely.  There is already a problem in that the discrepancy of behaviour (bug) between "default route" and "non default route" affecting hostname is not documented.  So, yes, technically a change to behaviour.  But, no, not a change to documented behaviour.


//Potential to break existing users.//  Well if existing users of a product (any product) are relying on a bug, then, yes, a bugfix will break it.  But that's in the nature of bugs and their later fixes!  (As programmers, we very rarely say "we won't fix the bug for the future because it might impact a few users who have specifically relied on the bug (and an undocumented bug at that) in the past.")

If the bug is to be preserved, then at the very least, documentation should be written.  If the existing difference is to be maintained, then documentation should state both (a) that there is a difference (b) why this difference is continuing to be positively maintained.

And the very act of attempting such documentation ("hostname is treated differently depending on presence/absence of 'default route' because...") might prompt a rethink!

My own vote would be that, having introduced this new configurability (thank you!), you then make the default hostname behaviour the same irrespective of presence/absence of 'default route', and that the documentation can say with great simplicity "this is how to get/stop hostname behaviour" without having to mention 'default route' at all.  Clean and simple.

Thanks for explaining that this is a two step process (a) adding capability to NM (b) providing hooks into kickstart to drive that capability.  That's useful to know!  I look forward to progress.

-- David Lee

After some discussion, we decided to do:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/92c494f2904c981842192d3eea7b74501c1fda0a

to change the default value of `hostname.only-from-default` to false. In this way NM will get the hostname via DHCP/DNS even without a default route.

Beiamino:

Many thanks for your thought and work on this.  If I understand your description correctly, this sounds good and promising.  Thank you.

-- David Lee

Hi,

here:

 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0474] device[fd260e66f3d91440] (eth0): hostname-from-dns: ipv4 resolver state wait-address, old address (null), new address 10.73.115.36
 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0474] device[fd260e66f3d91440] (eth0): hostname-from-dns: starting lookup for address 10.73.115.36
 Jan 26 09:56:01 NetworkManager[830]: <trace> [1611672961.0476] dns-mgr: current configuration: [{'nameservers': <['10.73.2.107', '10.73.2.108', '10.66.127.10']>, ...

NM tries a reverse DNS lookup of address 10.73.115.36 using
nameservers 10.73.2.107, 10.73.2.108, 10.66.127.10, but there is no
result.

Everything looks correct in this log, except for the lookup result. I
don't know if this is a NM problem or an infrastructure one. Since you
said that other machines are getting the hostname, perhaps you can
grab the trace logs from a working machine, so that we can compare it
with the failing one. Thank you.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: NetworkManager and libnma security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1574