On Thu, Nov 27, 2014 at 1:53 PM, Tom Gundersen <teg@xxxxxxx> wrote: > 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. 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
