Hi Andrew, On Thu, Nov 27, 2014 at 10:00 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Thu, Nov 27, 2014 at 12:51 PM, Tom Gundersen <teg@xxxxxxx> wrote: >> On Wed, Nov 26, 2014 at 3:10 PM, Chris Adams <linux@xxxxxxxxxxx> wrote: >>> Once upon a time, Tomasz Torcz <tomek@xxxxxxxxxxxxxx> said: >>>> On Wed, Nov 26, 2014 at 08:01:37AM -0600, Chris Adams wrote: >>>> > Once upon a time, Florian Weimer <fweimer@xxxxxxxxxx> 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. > 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... > 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
