RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1330465 (cockpit-config-ntp) - [RFE] Cockpit should allow configuring NTP servers in chronyd
Summary: [RFE] Cockpit should allow configuring NTP servers in chronyd
Keywords:
Status: CLOSED ERRATA
Alias: cockpit-config-ntp
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cockpit
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: alpha
: 8.9
Assignee: Marius Vollmer
QA Contact: Jan Ščotka
URL:
Whiteboard:
: 1667970 1825200 1842797 (view as bug list)
Depends On: 1331655
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-26 09:59 UTC by wanghui
Modified: 2023-11-14 17:54 UTC (History)
21 users (show)

Fixed In Version: cockpit-288.1-1.el8
Doc Type: Enhancement
Doc Text:
Clone Of:
: 2181240 (view as bug list)
Environment:
Last Closed: 2023-11-14 15:47:11 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
system time field (67.84 KB, image/png)
2016-04-26 09:59 UTC, wanghui 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2023:7081 0 None None None 2023-11-14 15:47:22 UTC

Description wanghui 2016-04-26 09:59:06 UTC 
Created attachment 1150806 [details]
system time field

Description of problem:
In system time field provided by cockpit, it can set time automatically using NTP. But it can not fill the NTP server, thus the synchronization can not succeed.

Version-Release number of selected component (if applicable):
ovirt-node-ng-installer-ovirt-3.6-2016042323.iso 
cockpit-0.103-1.el7.centos.x86_64
cockpit-ovirt-0.5.1-0.0.master.el7.centos.noarch

How reproducible:
100%

Steps to Reproduce:
1. Anaconda install NGN 4.0.
2. Start cockpit service.
3. Change the system time to automatically using NTP.

Actual results:
1. After step3, the system time can not be synchronized succeed. And check the /etc/ntp.conf file, the ntp server is obtained from dhcp server as default.

Expected results:
1. Should provide a field to setup the NTP server.

Additional info:
Comment 2 Stef Walter 2016-04-26 13:42:31 UTC 
Cockpit provides NTP server configuration when systemd-timesyncd is in use. Is it possible to use this NTP service on RHEV?
Comment 3 Fabian Deutsch 2016-04-26 14:32:44 UTC 
Yes and no.
AFAIK we currently document the configuration of older ntp implementations - but going forward having the support to configure timesyncd is sufficient.
This will just be an opportunity to converge to a single solution.
Comment 4 Stef Walter 2016-04-27 09:10:29 UTC 
So I guess the question is whether we can just close this bug and just support configuring NTP servers in timesyncd.
Comment 5 Fabian Deutsch 2016-04-27 11:17:58 UTC 
Well, ain't this bug about being able to specify the NTP servers from Cockpit?
This feature is currently not present, regardless of the underlying NTP implementation.
Comment 6 Stef Walter 2016-04-27 11:49:00 UTC 
This feature has been present since cockpit version 0.83. But is not available in the version of systemd on RHEL.

$ rpm -q systemd
systemd-219-19.el7_2.4.x86_64
$ ls /usr/lib/systemd/systemd-timesyncd
ls: cannot access /usr/lib/systemd/systemd-timesyncd: No such file or directory

The RHEL spec file for systemd contains: 

$ grep timesyncd systemd.spec 
Patch0016: 0016-Revert-timedated-manage-systemd-timesyncd-directly-i.patch
--disable-timesyncd

Should we reassign this to RHEL?
Comment 7 Stef Walter 2016-04-27 11:49:16 UTC 
This feature has been present since cockpit version 0.83. But is not available in the version of systemd on RHEL.

$ rpm -q systemd
systemd-219-19.el7_2.4.x86_64
$ ls /usr/lib/systemd/systemd-timesyncd
ls: cannot access /usr/lib/systemd/systemd-timesyncd: No such file or directory

The RHEL spec file for systemd contains: 

$ grep timesyncd systemd.spec 
Patch0016: 0016-Revert-timedated-manage-systemd-timesyncd-directly-i.patch
--disable-timesyncd

Should we reassign this to systemd?
Comment 8 Fabian Deutsch 2016-04-27 13:10:03 UTC 
Good catch.

Let's ask Lukas on the plan, maybe it lands in 7.3?
Comment 9 Lukáš Nykrýn 2016-04-27 13:13:19 UTC 
Sorry no timesyncd in rhel7. I was told that we will stick to chrony, since it is more feature rich.
Comment 10 Fabian Deutsch 2016-04-27 13:14:36 UTC 
Thanks.
To me it then sounds reasonable that Cockpit should gain the functionality to set NTP servers when chrony is used.
Comment 11 Marius Vollmer 2016-04-28 08:10:45 UTC 
One idea is to add a suitable API to timedated.  Systemd would implement it for timesyncd, and timedatex would need to implement it for ntpd and/or chrony.
Comment 12 Stef Walter 2016-04-28 08:13:37 UTC 
The main obstacle is that chronyd has no programattic configuration API or file format. The format is hand editable, and it does not appear to have a configuration tool to manipulate the config file.

systemd-timesyncd uses a directory of drop in configuration files, thus removing this barrier.

Does RHEV already have a tool for manipulating chrony's configuration file? Is it general purpose? If both of the above are true, then we should work to include that tool in the chrony package.
Comment 13 Fabian Deutsch 2016-04-28 08:59:14 UTC 
We are currently using the old ntp package, and augeas for modifying the default configuration file /etc/ntpd.conf.

There is also an augeas lense for chrony.

A maybe nicer approach would be to enhance chrony to support a drop-in dir as well. And change the default configuration to recognize the drop-in dir.
Comment 14 Fabian Deutsch 2016-04-28 10:03:17 UTC 
chrony.conf actually supports "include <glob>" which would allow us to do something like "include /etc/chrony.conf.d/*.conf"

However, there are concerns that a consumer like cockpit, would not see all ntp servers if it is just updating one file.
This could be a security issue, and it does not necessarily mean that adding an ntp server has the desired effect.
Comment 15 Miroslav Lichvar 2016-04-28 10:16:40 UTC 
Yes, a user configuring NTP should see all servers that are used. For instance, if a local server was unknowingly used together with public *.pool.ntp.org server from the default configuration, it could create a false sense of security (a MITM attacker could outvote the local server by modifying replies from the public servers and control the clock).

It would be also nice to have an option to enable/disable configuration of NTP sources from DHCP (PEERNTP variable in /etc/sysconfig/network).
Comment 16 Marius Vollmer 2016-04-29 07:03:55 UTC 
(In reply to Fabian Deutsch from comment #14)

> However, there are concerns that a consumer like cockpit, would not see all
> ntp servers if it is just updating one file.
> This could be a security issue, and it does not necessarily mean that adding
> an ntp server has the desired effect.

The same is true for timesyncd, actually.
Comment 17 Stef Walter 2016-04-29 07:32:37 UTC 
I've filed a blocking bug against chronyd for this work. We could coordinate contribution of that, so it's not just throwing responsibility over the wall ... but hopefully that bug will help us decide how this should be implemented.
Comment 18 Marius Vollmer 2016-04-29 11:18:17 UTC 
(In reply to Stef Walter from comment #17)
> I've filed a blocking bug against chronyd for this work. We could coordinate
> contribution of that, so it's not just throwing responsibility over the wall
> ... but hopefully that bug will help us decide how this should be
> implemented.

I think it would be awesome to get systemd involved, too, and to expose the API via timedated.  Then clients (like Cockpit) could be completely ignorant of which implementation of the NTP protocol is used.
Comment 20 Sandro Bonazzola 2018-11-28 11:04:31 UTC 
This missed 7.3 -> 7.6; can we have a target milestone for this? 7.6.z? 7.7?
Comment 21 Marius Vollmer 2018-11-29 09:43:02 UTC 
Is anyone still interested in this?
Comment 22 Sandro Bonazzola 2019-06-14 07:26:04 UTC 
RHV is still interested.
Comment 23 Sandro Bonazzola 2019-06-14 07:26:58 UTC 
not included in 7.7, retrying with 8.1 for RHV 4.4
Comment 24 Martin Pitt 2020-03-24 14:04:59 UTC 
*** Bug 1667970 has been marked as a duplicate of this bug. ***
Comment 25 Martin Pitt 2020-06-05 14:54:26 UTC 
*** Bug 1842797 has been marked as a duplicate of this bug. ***
Comment 26 Sam Wachira 2020-06-08 10:29:21 UTC 
A customer requested for this feature in RHEL 8 since system-config-date is no longer available.
There are no other options for defining NTP servers manually via a graphical interface.
Comment 27 Marius Vollmer 2020-06-11 11:59:09 UTC 
(In reply to Sam Wachira from comment #26)
> A customer requested for this feature in RHEL 8 since system-config-date is
> no longer available.
> There are no other options for defining NTP servers manually via a graphical
> interface.

I will look at the source of system-config-date and see if we can copy what it does.
Comment 28 Marius Vollmer 2020-06-11 12:30:13 UTC 
(In reply to Marius Vollmer from comment #27)
> (In reply to Sam Wachira from comment #26)
> > A customer requested for this feature in RHEL 8 since system-config-date is
> > no longer available.
> > There are no other options for defining NTP servers manually via a graphical
> > interface.
> 
> I will look at the source of system-config-date and see if we can copy what
> it does.

system-config-date will modify /etc/ntp.conf or /etc/chrony.conf in place and synchronize the "server" lines with what the user has specified.  It ignores "pool" lines and pretty much everything else.  I think Cockpit can do the same, maybe restricted to /etc/chrony.conf.

In this mode, Cockpit probably shouldn't make a distinction between "Automatically using NTP" and "Automatically using specific NTP servers" since there is no separate set of default NTP servers.
Comment 29 Miroslav Lichvar 2020-06-11 12:45:12 UTC 
It would be good if it could display all server, peer and pool lines to avoid issues with unexpected NTP servers being used. 
There is a /usr/libexec/chrony-helper script which can list and set the static sources in chrony.conf, which might be a better example than the old system-config-date code. If your tool supported setting any option on the server/peer/pool line, that would be a nice feature.

Please note that there is a possibility that the servers in the default configuration will be moved to a separate file and it could be overridden with a different file. This probably won't happen in RHEL8, but just a thing to keep in mind if you are writing new code.
Comment 30 Lucie Vařáková 2020-07-13 08:22:11 UTC 
*** Bug 1825200 has been marked as a duplicate of this bug. ***
Comment 35 Sam Wachira 2020-11-11 16:20:20 UTC 
Any progress with this request?
Comment 36 Sam Wachira 2020-11-11 16:20:55 UTC 
Any progress with this request?
Comment 37 Martin Pitt 2021-05-03 07:48:53 UTC 
This is finally fixed in RHEL 9, where chronyd is properly integrated into the timedatectl D-Bus interface. So cockpit can talk to it.
Comment 39 Martin Pitt 2021-05-03 09:11:09 UTC 
Oops, sorry.. the "set custom NTP server" now works in RHEL 9 cockpit because systemd-timesyncd is now available -- it is not in RHEL 8. I am not sure if that is deliberate, or still needs to be re-dropped. (and thus custom servers are written into /etc/systemd/timesyncd.conf.d/50-cockpit.conf).

Also, timedatex now does not exist any more, it is using systemd's own timedated.

So indeed there is no change wrt. to timedated's D-Bus API not being able to steer chrony. Setting back to NEW.
Comment 46 Marius Vollmer 2022-12-05 12:17:55 UTC 
chrony.conf now supports the "sourcedir" directive, so let's just use that to read our own /etc/chrony-cockpit-sources/custom.sources file.  Then everything is nicely parallel to the existing code for systemd-timesynd, where we use /etc/systemd/timesyncd.conf.d/50-cockpit.conf.
Comment 47 Matej Marušák 2022-12-09 07:10:28 UTC 
https://github.com/cockpit-project/cockpit/pull/17992
Comment 48 Martin Pitt 2023-01-07 09:18:09 UTC 
It's not nicely parallel. Merely adding "sourcedir" does not really help, as cockpit would *still* have to parse the entire config and all of its source dirs to find the custom NTP servers. That's even harder than just directly looking for "server" instances. It may help if chrony would define (in its chrony.conf) a standard /etc/chrony/servers/ directory where admins, ansible, cockpit etc. could drop files, then that would be easier to parse.
Comment 50 Marius Vollmer 2023-02-10 10:06:37 UTC 
New try in https://github.com/cockpit-project/cockpit/pull/18298
Comment 62 errata-xmlrpc 2023-11-14 15:47:11 UTC 
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 (cockpit 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-2023:7081
Note You need to log in before you can comment on or make changes to this bug.