4:01 p.m.
Hi,
Since http://lists.freedesktop.org/archives/systemd-devel/2015-March/029482.html
systemd-timesyncd can be enabled in more places. (That change isn't in F22 now
but could be backported easily). Looking at the state
of things here, there was a previous discussion on the desktop list:
https://lists.fedoraproject.org/pipermail/desktop/2014-September/010751.html
From an Atomic Host perspective,
systemd-timesyncd now looks
fairly equivalent to chrony, and is 140k
that's already shipped. (Though if systemd didn't do internal static
linking that'd likely be noticeably smaller...anyways, the packaging of
systemd is a separate discussion).
Anaconda looks like it only supports chrony. Although,
it seems weird that Anaconda itself is doing the bridging of DHCP
NTP servers to chrony config - seems like something to fix in
NetworkManager itself so that it knows how to copy configuration
acquired at install time to the target.
And even then, it seems like we could get away with not setting
the NTP servers persistently from the DHCP lease acquired at
install time, and instead just rely on NM/systemd-networkd to
set them when the system boots again, right?
This however would require NetworkManager -> timesyncd
integration. Filed that as
https://bugzilla.gnome.org/show_bug.cgi?id=746911
It appears to me that at least Fedora Server has ntp installed
but not running, which (looks) is due to freeipa-client having
a Requires: on ntp. Which came from
https://fedorahosted.org/freeipa/ticket/2974
Besides gnome-control-center then, I guess the switch of
systemd-timedated to only supporting systemd-timesyncd
impacts FreeIPA too.
But it wouldn't seem that hard for gnome-control-center and
freeipa-client to grow minimal awareness of how to use
systemd-timesyncd's dbus api to set the server.
Currently I'm leaning towards enabling systemd-timesyncd by default
for Atomic Host at least, but sending this mail to get a discussion
across the products.
6:09 p.m.
gnome-control-center just talks to timedated, it doesn't care about what's
behind.
----- Original Message -----
Hi,
Since
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029482.html
systemd-timesyncd can be enabled in more places. (That change isn't in F22
now
but could be backported easily). Looking at the state
of things here, there was a previous discussion on the desktop list:
https://lists.fedoraproject.org/pipermail/desktop/2014-September/010751.html
From an Atomic Host perspective,
systemd-timesyncd now looks fairly equivalent to chrony, and is 140k
that's already shipped. (Though if systemd didn't do internal static
linking that'd likely be noticeably smaller...anyways, the packaging of
systemd is a separate discussion).
Anaconda looks like it only supports chrony. Although,
it seems weird that Anaconda itself is doing the bridging of DHCP
NTP servers to chrony config - seems like something to fix in
NetworkManager itself so that it knows how to copy configuration
acquired at install time to the target.
And even then, it seems like we could get away with not setting
the NTP servers persistently from the DHCP lease acquired at
install time, and instead just rely on NM/systemd-networkd to
set them when the system boots again, right?
This however would require NetworkManager -> timesyncd
integration. Filed that as
https://bugzilla.gnome.org/show_bug.cgi?id=746911
It appears to me that at least Fedora Server has ntp installed
but not running, which (looks) is due to freeipa-client having
a Requires: on ntp. Which came from
https://fedorahosted.org/freeipa/ticket/2974
Besides gnome-control-center then, I guess the switch of
systemd-timedated to only supporting systemd-timesyncd
impacts FreeIPA too.
But it wouldn't seem that hard for gnome-control-center and
freeipa-client to grow minimal awareness of how to use
systemd-timesyncd's dbus api to set the server.
Currently I'm leaning towards enabling systemd-timesyncd by default
for Atomic Host at least, but sending this mail to get a discussion
across the products.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
7:48 a.m.
Hello,
Besides gnome-control-center then, I guess the switch of
systemd-timedated to only supporting systemd-timesyncd
impacts FreeIPA too.
Are you aware of https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html
?
Mirek
8:19 a.m.
----- Original Message -----
Hello,
> Besides gnome-control-center then, I guess the switch of
> systemd-timedated to only supporting systemd-timesyncd
> impacts FreeIPA too.
Are you aware of
https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ?
Yes, and I don't want to make changes to gnome-control-center that would only
be applicable to Fedora. The point of use timedatectl is that we don't have
to do a version for each distribution. Change timedated to do "the right thing"
instead.
8:25 a.m.
> Hello,
> > Besides gnome-control-center then, I guess the switch of
> > systemd-timedated to only supporting systemd-timesyncd
> > impacts FreeIPA too.
>
> Are you aware of
> https://lists.fedoraproject.org/pipermail/devel/2014-November/204658.html ?
Yes, and I don't want to make changes to gnome-control-center that would only
be applicable to Fedora. The point of use timedatectl is that we don't have
to do a version for each distribution. Change timedated to do "the right
thing"
instead.
AFAICT gnome-control-center is “fine” with timedatex used (well, working in Fedora; I’m
not trying to solve upstream here). It just seemed to me that Colin’s original analysis
(focusing on Atomic, not g-c-c) was not taking timedatex int account, and thus perhaps
misleading (at the very least in the FreeIPA part, and thus perhaps for the other aspects
of Atomic as well.)
Mirek
10:45 a.m.
On Fri, 27.03.15 17:01, Colin Walters (walters(a)verbum.org) wrote:
This however would require NetworkManager -> timesyncd
integration. Filed that as
https://bugzilla.gnome.org/show_bug.cgi?id=746911
So, what's missing here is actually a way for NM to tell timesyncd NTP
server information... timesyncd gets the data automatically from
networkd, but that's a private iface between the two. For us, from the
systemd side it really should be timesyncd that pulls the data from
networkd, i.e. that the upper layer pulls from the lower layer rather
than the lower layer pushing into the upper layer. NM never was never
so strict there with the layering...
Now, we intend to support NM (or in fact any other external config
source) pushing data into timesyncd, but this will probably not happen
before kdbus. The reason for this is that timesyncd runs in early boot
already, where classic dbus is not available. Adding a bus interface for
pushing NTP server info into timesyncd would hence either mean moving
timesyncd into late boot or dealing with the complexities of having to
reconnect when dbus appears. With kdbus this all goes away, as dbus
is then available from earliest boot to latest shutdown.
Lennart
--
Lennart Poettering, Red Hat
3309
days inactive
3316
days old
5 comments
4 participants
participants (4)
-
Bastien Nocera -
Colin Walters -
Lennart Poettering -
Miloslav Trmač