Bug 2047415

This looks like an RFE for upstream chrony. If I understand correctly here's the code where DHCPv4 is implemented https://git.tuxfamily.org/chrony/chrony.git/tree/examples/chrony.nm-dispatcher.dhcp

Tagging in @mlichvar to see if they have any comment.

This needs to be supported in NetworkManager first. Last time I checked, it didn't support the NTP DHCPv6 option, so there was no way for the dispatcher script to get it.

The NetworkManager team confirmed that this is not currently supported. @dhaupt can you open a feature request against the NetworkManager team for this?

We need NM support and then a Chrony dispatcher script to take advantage of it.

This is being worked on here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1078
(This is amazing, shout-out to Lubomir and the NetworkManager team for picking this up automatically!)

I small note on the priority, this is low priority/severity, I have no customer asking for this, it was just something I was looking into when installing an openshift cluster on my own.

@mlichvar - considering the code recently added to NM in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1078 - would chrony be able to use this as part of an NM dispatcher once it's available?

I'm not sure if I'm configuring it correctly, but it doesn't seem to work for me. I configured the DHCPv6 server to provide the NTP option. It's visible in packet capture:

    NTP Server
        Option: NTP Server (56)
        Length: 20
        Value: 0001001020010db80ca200020000000000000001
        NTP Server Address
            Suboption: NTP Server Address (1)
            Length: 16
            NTP Server Address: 2001:db8:ca2:2::1

But NetworkManager (as of dc1092e22b2) doesn't seem to accept it or make a variable for it that would be visible in the dispatcher script. The only DHCP6 variables I see are:

DHCP6_DHCP6_NAME_SERVERS
DHCP6_IP6_ADDRESS

Any hints?

My bad, I wasn't actually testing the NetworkManager rpm I built. It works.

There is a DHCP6_DHCP6_NTP_SERVER variable visible in the dispatcher script. That shouldn't be difficult to support. I guess I just need to make sure that if a FQDN is provided, it doesn't contain any unexpected characters.

Please reassign this bug to the RHEL chrony component or submit a new bug.

(In reply to Miroslav Lichvar from comment #6)
> I'm not sure if I'm configuring it correctly, but it doesn't seem to work
> for me. I configured the DHCPv6 server to provide the NTP option. It's
> visible in packet capture:
> 
>     NTP Server
>         Option: NTP Server (56)
>         Length: 20
>         Value: 0001001020010db80ca200020000000000000001
>         NTP Server Address
>             Suboption: NTP Server Address (1)
>             Length: 16
>             NTP Server Address: 2001:db8:ca2:2::1

Please kill off the nm-dispatcher, if any is running, and run one in debug mode:

  /usr/libexec/nm-dispatcher --debug --persist

Here's a snippet from dhcpd6.conf I've used for testing straight from David's comment + the output of nm-dispatcher that suggests the environment variable has been set:

  option dhcp6.ntp-servers code 56 = string;
  option dhcp6.ntp-servers 00:03:00:25:06:64:68:61:75:70:74:05:63:6c:6f:75:64:03:6c:61:62:03:65:6e:67:03:62:6f:73:06:72:65:64:68:61:74:03:63:6f:6D:00;

  (nm-dispatcher:4498): nm-dispatcher-DEBUG: 15:53:19.615: req:5 'up' [enp9s0]: environment: DHCP6_DHCP6_NTP_SERVER=dhaupt.cloud.lab.eng.bos.redhat.com

I've tried your option and it seems to work too:

  option dhcp6.ntp-servers code 56 = string;
  option dhcp6.ntp-servers 00:01:00:10:20:01:0d:b8:0c:a2:00:02:00:00:00:00:00:00:00:01;

  (nm-dispatcher:4498): nm-dispatcher-DEBUG: 15:57:04.681: req:10 'up' [enp9s0]: environment: DHCP6_DHCP6_NTP_SERVER=2001:db8:ca2:2::1

Note that there might actually be multiple addresses and FQDNs joined with a comma (","). I guess it's okay if you don't take that into consideration given RFC 5908 specifically forbids that.

(In reply to Miroslav Lichvar from comment #7)
> My bad, I wasn't actually testing the NetworkManager rpm I built. It works.
> 
> There is a DHCP6_DHCP6_NTP_SERVER variable visible in the dispatcher script.
> That shouldn't be difficult to support. I guess I just need to make sure
> that if a FQDN is provided, it doesn't contain any unexpected characters.

Yes. Note that the RFC also states that internationalized domain names are
explicitly disallowed, so I guess you can go really conservative.

> Please reassign this bug to the RHEL chrony component or submit a new bug.

Done.

(In reply to Lubomir Rintel from comment #8)
> Note that there might actually be multiple addresses and FQDNs joined with a
> comma (","). I guess it's okay if you don't take that into consideration
> given RFC 5908 specifically forbids that.

It seems RFC 5908 requires one suboption in the NTP server option, but allows multiple NTP server options. Would it make sense to rename the variable to DHCP6_DHCP6_NTP_SERVERS?

I tried two FQDNs with dnsmasq, but it uses multiple suboptions in one server option.

The variable contained the two FQDNs separated by space.

(In reply to Miroslav Lichvar from comment #11)
> (In reply to Lubomir Rintel from comment #8)
> > Note that there might actually be multiple addresses and FQDNs joined with a
> > comma (","). I guess it's okay if you don't take that into consideration
> > given RFC 5908 specifically forbids that.
> 
> It seems RFC 5908 requires one suboption in the NTP server option, but
> allows multiple NTP server options. Would it make sense to rename the
> variable to DHCP6_DHCP6_NTP_SERVERS?

Yes, entirely possible at this point:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1085

> I tried two FQDNs with dnsmasq, but it uses multiple suboptions in one
> server option.
> 
> The variable contained the two FQDNs separated by space.

Ok, so not a comma. Thank you -- I stand corrected.

Upstream commit:
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=5bd13c8d593a74ad168057efe94dd2b3aeeffe14

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 (chrony 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-2022:8273