Bug 1858344
| Summary: | Hostname not set from DHCP with ipv6 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ben Nemec <bnemec> | ||||||||
| Component: | NetworkManager | Assignee: | Thomas Haller <thaller> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 8.2 | CC: | acardace, atragler, bgalvani, lrintel, rkhan, sukulkar, thaller, till, vbenes | ||||||||
| Target Milestone: | rc | Keywords: | ZStream | ||||||||
| Target Release: | 8.3 | Flags: | pm-rhel:
mirror+
|
||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | NetworkManager-1.26.0-4.el8 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | |||||||||||
| : | 1883571 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2020-11-04 01:47:57 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1883571 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Ben Nemec
2020-07-17 15:45:15 UTC
I confirmed that this is related to the switch to the internal DHCP client. On 4.5, which still uses dhclient, this works as expected. It's only ipv6 on 4.6 that is a problem. Created attachment 1701806 [details]
Trace logs from failing deployment
Sending to NetworkManager team so they can take a look. The internal DHCPv6 client currently doesn't parse the FQDN option returned by server; this must be implemented. Would this only be for future releases then? If it's never going to be supported in 8.2 we'll need to have some discussions within our team about how to deal with that. Thanks. (In reply to Ben Nemec from comment #1) > I confirmed that this is related to the switch to the internal DHCP client. > On 4.5, which still uses dhclient, this works as expected. It's only ipv6 on > 4.6 that is a problem. When you say that it works on 4.5 with dhclient, do you mean using DHCPv4 or DHCPv6? And did you use dhclient alone or NM with the dhclient backend? From a look at the NM code, it seems to me that getting an hostname through DHCPv6 was never really functional, even when using dhcp=dhclient. (In reply to Ben Nemec from comment #5) > Would this only be for future releases then? If it's never going to be > supported in 8.2 we'll need to have some discussions within our team about > how to deal with that. Thanks. Yes, it would be for future releases. If the issue is critical to openshift, we can discuss about backporting it to 8.2 as a z-stream. (In reply to Beniamino Galvani from comment #6) > (In reply to Ben Nemec from comment #1) > > I confirmed that this is related to the switch to the internal DHCP client. > > On 4.5, which still uses dhclient, this works as expected. It's only ipv6 on > > 4.6 that is a problem. > > When you say that it works on 4.5 with dhclient, do you mean using DHCPv4 or > DHCPv6? And did you use dhclient alone or NM with the dhclient backend? > > From a look at the NM code, it seems to me that getting an hostname through > DHCPv6 was never really functional, even when using dhcp=dhclient. Both were DHCPv6. I set hostname-mode=dhcp to force them to use DHCP for hostnames, and with dhclient it worked and with internal it did not. I suppose it's also possible that the dhclient path still pulled it from DNS for some reason. > > (In reply to Ben Nemec from comment #5) > > Would this only be for future releases then? If it's never going to be > > supported in 8.2 we'll need to have some discussions within our team about > > how to deal with that. Thanks. > > Yes, it would be for future releases. If the issue is critical to openshift, > we can > discuss about backporting it to 8.2 as a z-stream. Okay, thanks. We'll have to discuss our options then. (In reply to Ben Nemec from comment #7) > (In reply to Beniamino Galvani from comment #6) > > (In reply to Ben Nemec from comment #1) > > > I confirmed that this is related to the switch to the internal DHCP client. > > > On 4.5, which still uses dhclient, this works as expected. It's only ipv6 on > > > 4.6 that is a problem. > > > > When you say that it works on 4.5 with dhclient, do you mean using DHCPv4 or > > DHCPv6? And did you use dhclient alone or NM with the dhclient backend? > > > > From a look at the NM code, it seems to me that getting an hostname through > > DHCPv6 was never really functional, even when using dhcp=dhclient. > > Both were DHCPv6. I set hostname-mode=dhcp to force them to use DHCP for > hostnames, and with dhclient it worked and with internal it did not. I > suppose it's also possible that the dhclient path still pulled it from DNS > for some reason. That shouldn't happen, and from what I see NM doesn't support getting the hostname from DHCPv6 when using dhclient. Do you happen to have NM logs, preferably at trace level? Created attachment 1702379 [details] Trace logs from dhclient deployment I've attached trace logs from a dhclient-based run. From what I can see, the difference may be that dhclient provides the necessary information for our dispatcher script to set the hostname, where the internal client does not. That would explain why it worked even though NM doesn't support setting the hostname itself. I think the relevant part of the dispatcher script is probably this: https://github.com/openshift/machine-config-operator/blob/master/templates/common/baremetal/files/NetworkManager-resolv-prepender.yaml#L22 Right, it works with dhclient because NM exports the FQDN option, while it doesn't when using the internal client. This merge request adds support to the internal client to parse the FQDN option and set it as transient hostname. This means that you won't need a dispatcher script to do it. To prevent this, set hostname-mode=none in the configuration. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/589 Created attachment 1702439 [details]
Reproducer script
Hi Ben, I'm afraid it's too late to include this in 8.2.1, if this is important we're still in time to include it in 8.2.0.4 EUS but you can you please provide an explanation of why this is needed in RHEL 8.2? Thanks, Antonio OpenShift 4.6 is based on RHEL 8.2, and in that release we had to move to the internal DHCP client. As a result, it has broken ipv6 deployments in some environments that were relying on the behavior of dhclient in regards to the hostname. If we can get this backported then we don't have to do any hacky workarounds to fix the problem. (In reply to Ben Nemec from comment #16) > OpenShift 4.6 is based on RHEL 8.2, and in that release we had to move to > the internal DHCP client. As a result, it has broken ipv6 deployments in > some environments that were relying on the behavior of dhclient in regards > to the hostname. If we can get this backported then we don't have to do any > hacky workarounds to fix the problem. The next batch update for 8.2.0 is 8.2.0.4 (EUS), you can request the zstream for that ITR if you think this is important. (In reply to Ben Nemec from comment #16) > OpenShift 4.6 is based on RHEL 8.2, and in that release we had to move to > the internal DHCP client. As a result, it has broken ipv6 deployments in > some environments that were relying on the behavior of dhclient in regards > to the hostname. If we can get this backported then we don't have to do any > hacky workarounds to fix the problem. Note that it's fine to continue using dhcp=dhclient. What changed is the default, that doesn't mean for rhel-8.2 that the other option is less maintained (or worse than it was before). In fact, dhclient DHCP plugin is infinitely configurable (because it can run any script), and as such there will be always use-cases that the internal DHCP plugin cannot satisfy. Have a file: [main] dhcp=dhclient in /{etc,usr/lib}/NeworkManager/conf.d/60-openshift-use-dhclient.conf. (In reply to Antonio Cardace from comment #17) > (In reply to Ben Nemec from comment #16) > > OpenShift 4.6 is based on RHEL 8.2, and in that release we had to move to > > the internal DHCP client. As a result, it has broken ipv6 deployments in > > some environments that were relying on the behavior of dhclient in regards > > to the hostname. If we can get this backported then we don't have to do any > > hacky workarounds to fix the problem. > > The next batch update for 8.2.0 is 8.2.0.4 (EUS), you can request the > zstream for that ITR if you think this is important. Okay, I moved it back to 8.2.0. ipv6 is an important feature for us. (In reply to Thomas Haller from comment #18) > Note that it's fine to continue using dhcp=dhclient. What changed is the > default, that doesn't mean for rhel-8.2 that the other option is less > maintained (or worse than it was before). In fact, dhclient DHCP plugin is > infinitely configurable (because it can run any script), and as such there > will be always use-cases that the internal DHCP plugin cannot satisfy. Unfortunately dhclient was completely removed from our base image for this release. That's why we had to switch to the internal client. 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 (NetworkManager 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/RHBA-2020:4499 |