timesyncd: default NTP pool instead of Google NTP

[jedsmith]

Google NTP is not for public consumption, according to @isomer.
Reconfigure timesyncd to default to the public NTP pool instead of
Google NTP. This is a temporary fix until systemd requests a vendor
prefix from the NTP pool:

• http://www.pool.ntp.org/en/vendors.html#open-source
• http://www.pool.ntp.org/en/vendors.html#vendor-zone

Fixes #437.

[mnordhoff]

This sounds like one of those "temporary fixes" that will turn out to be a "permanent 'fix'".

[mlindner]

+1

[frei0]

+1

i think this is a permanent fix, nowhere do I see from NTP Pool that they require non-vendor open source project maintainers to get a vendor prefix. I see the warnings on http://www.pool.ntp.org/en/vendors.html as directed towards vendors, not open source projects maintainers who will not really distribute much directly. OS vendors (Ubuntu, Debian, CentOS, etc.) can and do replace these defaults with their own configuration.

[martinpitt]

-1 on that, PR #444 is a better fix IMHO.

[xnox]

"Open source projects
Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration."

I think it makes sense to have systemd vendor, but have e.g. vendor configuration option and encouraging re-distributors to get their own vendor prefix setup.

[ghost]

What about using the ntp server provided by the datacenter (LRZ) of the Bavarian Academy of Sciences and Humanities: e.g. ntp2.lrz.de as it is described here?

[teg]

We can't do this without the explicit permission of the pool.ntp.org people (as it really seems to me at least to be against their policy). I have asked them for clarification, let's see how it goes.

Furthermore, I consider that the bike-shed must be mauve.

[jedsmith]

@teg Thanks! I asked Ask to clarify in the locked issue. We (CoreOS) also have a ticket in to create a vendor prefix with the pool. I'm sure enough people have sent him messages that we'll hear something soon, and in the meantime, I'll just leave this PR here for whatever's going to be done so it isn't forgotten.

I'm willing to update the PR if a better choice is found. There is (some?) work being done in #444 to completely gut the relevant code, which I think is a bigger change than just band-aiding the issue.

[teg]

Poor guy probably got a lot of emails about this ;-)

Personally, I agree that we should probably stop using the Google servers (but barring a formal request from them it isn't THAT big of a deal). Using some sort of pool.ntp.org servers would be ideal IMHO, but it will have to be within their (and our) terms, which might not be possible, but let's see how it all shakes out. Failing that, just dropping the default as in the other PR would not be that big of a hassle, it would just be a matter of dropping some sane defaults in your local configure and forget about it.

[poettering]

Registering a systemd vendor pool is simply wrong. We should not register a pool that noone should ever use. Downstreams should register their own pools really and not use a systemd pool.

[jedsmith]

@poettering I believe we are all aware of that being your position. We flew the request before you made your position known last night, and I still believe it's worth seeing what Ask says rather than kill forward momentum on fixing the irresponsible behavior of systemd in the face of Google's request.

There is likely nothing to be done here until @teg and Ask sync up.

[cmacq2]

Is there any particular reason why the default NTP servers should not simply be auto detected by extracting the info from the build host, in much the same way the bash completions dir is?

[dvdhrm]

Please see #437 for further discussion. Please figure out a solution everyone agrees on, in case the current solution does not suffice.