timedatex replacing systemd-timedated for NTP packages

[Andrew Lutomirski]

On Thu, Nov 27, 2014 at 1:53 PM, Tom Gundersen <teg at jklm.no> wrote:
> Hi Andrew,
>
> On Thu, Nov 27, 2014 at 10:00 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>> On Thu, Nov 27, 2014 at 12:51 PM, Tom Gundersen <teg at jklm.no> wrote:
>>> On Wed, Nov 26, 2014 at 3:10 PM, Chris Adams <linux at cmadams.net> wrote:
>>>> Once upon a time, Tomasz Torcz <tomek at pipebreaker.pl> said:
>>>>> On Wed, Nov 26, 2014 at 08:01:37AM -0600, Chris Adams wrote:
>>>>> > Once upon a time, Florian Weimer <fweimer at redhat.com> said:
>>>>> > > Do we even use the DHCP NTP server assignment?
>>>>> >
>>>>> > I believe it is used for chrony and ntpd, don't know about sysmted's new
>>>>> > implementation.
>>>>>
>>>>>   systemd-timesyncd uses DHCP-provided NTP servers only if systemd-networkd
>>>>> is used as DHCP client.
>>>>
>>>> That should be a bug (and block it from use).  There's no excuse for
>>>> that other than "not invented here".
>>>
>>> There are technical reasons for this choice, not merely NIH.
>>
>> And those technical reasons are?
>>
>> I realize that the shell-script-fu that most DHCP clients seem to
>> require is a bit messy, but it does work, and it should be more than
>> flexible enough to plug in some systemd-timesyncd controls.
>
> The whole model is just the wrong way around for how
> networkd/timesyncd works, so this is not simply a case of  "if
> (!networkd) return -EINVAL".
>
> networkd allows consumers of network information (such as NTP servers,
> DNS resolvers, HTTP proxy brokers,...) to subscribe to this
> information (currently only via a C API [0], but could just as well
> have been dbus) and be notified of changes to it. Other DHCP clients
> will typically instead call a bunch of hooks (with env vars set) on
> every configuration change (and it is then presumably the job of the
> hook to instruct the NTP client, or whatever else, to change its
> config).
>
> So basically the systemd model is one where the consumer pulls the
> information from the producer, where the traditional DHCP model the
> producer pushes the information to the consumer. It follows from this
> that anyone can be a consumer of any sort of information (so you can
> come along and implement your alternative NTP clients hooking into
> networkd just fine), but making a drop-in replacement for a producer
> of information is not necessarily that straightforward (you basically
> have to go out of your way to make sure you mimic all the interfaces
> etc). I guess this is how our stack works most of the time anyway,
> replacing things higher in the stack is always easier than replacing
> things lower in the stack (because the kernel does not have hooks to
> call into your browser, your browser calls into the kernel...).
>
> Now that's just the design, you can of course make whatever bash
> scripts do whatever briding in either direction to make things behave
> in any way you want.

Should be straightforward to wire up timesyncd (maybe with a networkd
configured to not do anything) to any shell-based dhclient, then, if
anyone cared to do that.

>
>> As a counterexample, I run some production servers with rather
>> complicated network configurations.  NetworkManager is a nonstarter,
>> and I suspect that systemd-networkd will never work for them either.
>
> There are certainly still usecases we don't cover, but a-priori we are
> interested in making anything work, so feel free to give us ping over
> at the systemd ML if we lack some features you need.
>
>> This isn't a complaint about either package -- I don't really expect
>> them to understand my configuration.  I use a Python script that reads
>> a rather large hand-curated config file and outputs Debian
>> interfaces(5) rules with a liberal sprinking of "up" and "down"
>> directives.
>
> Yikes...

We used to do it by hand, but there were too many things to configure...

Anyway, I probably won't even try to make it work with
systemd-networkd until I'm on a distro that uses systemd in the first
place.  Ubuntu is still using upstart (grumble).

--Andy

>
>> I do use NTP, and I don't really care much which implementation I'm
>> using, but if systemd-timesyncd refuses to be reasonably configurable
>> unless systemd-networkd is installed, I won't be using *that* any time
>> soon either.
>
> You can of course still configure systemd-timesyncd to use a set of
> statically configured NTP servers, it is only the DHCP integration
> that currently requires networkd. That said, timesyncd is supposed to
> be this simple client that "just works" in the 99% of simple setups.
> If you have something fancy going on, it may very well be that you'll
> be better served by some other client (and that's just fine IMHO).
>
>> And if Fedora becomes dependent on services that aren't configurable,
>
> My understanding is that timesyncd is meant to be a good enough
> default that "just works", but not the one true NTP client. It is (or
> may at least one day be) a reasonable default, but it should clearly
> still be possible to exchange it with something else.
>
> Cheers,
>
> Tom
>
> [0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/systemd/sd-network.h>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct