I suppose the obvious question is, what's a better option? Or what are even choices for another option? Does this apply? http://www.pool.ntp.org/en/

pool.ntp.org?

@gobengo Yes, the NIST timeservers isomer is referring to in the original post are available publicly through the ntp.org pool. These are the public NTP servers most machines peg themselves to, outside of organizations that run their own pools etc etc.

time.windows.com?

From http://support.ntp.org/bin/view/Support/WindowsTimeService:

Stand-alone Windows servers and clients are automatically configured to poll time.windows.com at one-hour intervals. The time.windows.com server (actually a cluster of servers) is maintained by Microsoft. However, time.windows.com is notoriously unreliable and heavily loaded, so configuring a different time source or multiple sources is probably wise.

Maybe not a wise idea :) What's wrong with pool.ntp.org?

timesyncd just needs this, that's all:

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

This is a problem beyond systemd, too. Router manufacturers are notorious for throwing burned-in traffic at NTP systems that do not expect it; this issue is just another variant of that longstanding one.

Since this is a publicly-linked issue with some traffic now, I'll soapbox for a moment: If you run NTP for your own organization, do it correctly, please. Either use the NTP pool up to a certain size (I'd say a couple dozen systems), or configure your own edge stratum 3 servers that sync from publicly-available stratum 2, then sync your own network off those. And put your S3s in the pool.

If you are pushing configuration management to hardcode time.nist.gov, *.bldrdoc.gov, time.windows.com and friends across your hundreds of machines, you are absolutely doing it wrong.

For some reason Lennart was opposed to requesting a vendor zone last year.

http://lists.freedesktop.org/archives/systemd-devel/2014-August/022575.html

His reasoning seems rather stupid to me. In any case,

using Google's servers without their backing/consent seems bad.

@floppym The PR stops short of a vendor zone for that reason, and I agree.

You cannot use pool.ntp.org either.. "You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance." that's according to the pool's website...

@blt I don't believe the NIST servers are part of the NTP Pool.

@floppym Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.

@jleclanche As far as I know Microsoft's NTP service at time.windows.com is perfectly respectable these days. Years ago it was run by a third party vendor and it was pretty terrible.

@crrodriguez If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.

I'd suggest having no default NTP servers in the systemd code; leave it to distributors to provide their own (possibly via the NTP Pool).

@abh, would you look at that. Right you are. That's a time infrastructure misunderstanding corrected for me today. Thanks!

On Jun 30, 2015, at 8:14 PM, Ask Bjørn Hansen notifications@github.com wrote:

@blt I don't believe the NIST servers are part of the NTP Pool.

@floppym Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.

@jleclanche As far as I know Microsoft's NTP service at time.windows.com is perfectly respectable these days. Years ago it was run by a third party vendor and it was pretty terrible.

@crrodriguez If you kept reading you'd learn about getting a "vendor pool" setup specifically for your product/distribution.

I'd suggest having no default NTP servers in the systemd code; leave it to distributors to provide their own (possibly via the NTP Pool).

—
Reply to this email directly or view it on GitHub.

Has anyone applied for a vendor zone? I think systemd, although not a "distribution" could be considered a vendor or product.

Even if technically distributions need to think about this, if you have a default configuration(and you should) then it should be not unreasonable to leave it untouched, including not changing the NTP servers.

I don't see any reason not to apply for a vendor zone either way.

Lennarts reasons for not using *.systemd.pool.ntp.org ("systemd isn't a distribution") makes sense to me.

This isn't about "providing a distribution". It's about configuring a useful default for people who build/configure systemd from the git repo or source tarball. The people who run the NTP pool just want that on file.

Anyway, I agree that having no default is better than picking some random NTP servers like Google or using the public NTP pool without a vendor zone.

I think "no default" versus "stop the bleeding and get off Google per Google's request" is a theoretical discussion instead of a practical one, given that systemd has already shipped a default. Every build will break if that behavior changes. I agree that no default would be better, but I suspect that ship has sailed.

I'll leave my PR up in anticipation of being correct. I hope @abh forgives me for breaking the very FAQ I pointed folks toward in my PR given those circumstances.

if you don't take this down, google will just remove the dns, and then you lose the ability to do this in a controlled way

it does not matter if the ship has sailed; call it back. we haven't left someone behind on fare. the ship is dangerous and unreliable.

Every build will break if that behavior changes.

Not so. I would expect that most Linux distros already override it via the configure switch.

@floppym You hedged that statement yourself, making the assertion a nonstarter as a software project.

Saying you can never change something because you did something stupid in the past with makes no sense at all.

You either make timesyncd work out of the box properly, or you force people to configure it if they happen to build systemd themselves.

i use 0.arch.pool.ntp.org on Arch but dont use systemd with ntp: a simple script on crontab

http://www.pool.ntp.org/en/use.html lists 4 servers which are randomized and changed every hour. Those should be the defaults.

Arch indeed has its own timeservers {0..3}.arch.pool.ntp.org which it configures into the distribution systemd package, as does Fedora {0..3}.fedora.pool.ntp.org, as does debian {0..3}.debian.pool.ntp.org, as does ubuntu {0..3}.ubuntu.pool.ntp.org, and gentoo, and opensuse...

I think distributions are pretty good about specifying these, so maybe the defaults don't really need to be sane, just sane enough that they work.

I think maybe {0..3}.pool.ntp.org is okay for developer builds without configuration.

Its up to the distros to register an ntp pool product. systemd is not a product. Its just some toolset people can build products from. We cannot use the ntp pool hence. If the googl time servers

@poettering If systemd is not a "product" that is meant to work on its own, then there should be no need to configure any default NTP servers since nobody should ever utilize it that way.

Using Google's servers by default is still a valid problem and this issue should be reopened.

@poettering it is not appropriate for you to close the issue by google saying "stop using our resources" because you have decided it is inconvenient.

you do not have the privilege of using their servers over their protest. choices of this form do serious damage to community good will. please re-open.

Both timeX.google.com and systemd are both non-products, therefore, there's no problem here. Right?

Curious, why is a FOSS project depending on a proprietary time server(i.e Google's) as a first resort?

@poettering You're being kind of absurd and stupid here. Supplying a broken timeserver as a default is inane and silly. Please accept the pull request. #439

Looking forward to seeing the emergency update after Google pulls the DNS entry for its time servers.

@poettering Your explanation makes sense, except for the fact that you are ignoring Google's request for having their server being removed from the source code as a default. It's not a matter if their servers are bad or not, it's a gesture of goodwill towards the request from someone providing a publicly accessible resource.

@dannyperson's link above pretty much settles that ntp.org is fine with having pool.ntp.org as a default in the source code as long as vendors change it when shipping (as they do).

@abh Can you perhaps speak to this perceived corner case in the usage of the pool? This seems to be a situation not encountered before, since traditional ntpd does not ship with defaults and instead only has example configurations with ACTS drivers and such.

We're obviously at an impasse here. Allow me to summarize:

• Google firmly requests, including with emphasis, that systemd stop using time?.google.com.
• @poettering is firmly against registering as a vendor, and you agree. CoreOS has expressed willingness to take on the near-zero burden of doing so (and we've filed ntppool #4457).
• @poettering interprets the remainder of your documentation as hard forbidding systemd's usage without registering as a vendor. I haven't seen your opinion on this.

There are only three paths forward, given all of the cards on the table:

• Remove defaults and break testing/one-off builds of systemd.
• Hardcode another server instead of Google's, and hope it never breaks. The public StratumTwo list from ntp.org will be useful for this, but it's yet another server administrator to bother.
• Leave Google in as the default explicitly against their request (I consider this a nonstarter).

Can you share your perspective on whether the NTP pool can help at all here as a fourth option?

After reading that, it seems to me that this would be a viable compromise:

• Don't default to any server.
• Skip timesyncd tests with a big warning if you configured without any
• In semaphore and similar CI tests, configure with an appropriate server. E. g. semaphore runs under Ubuntu, and it would be perfectly valid to use ?.ubuntu.pool.ntp.org, and I don't think anyone would complain if it used the Debian/Arch/whatever pool.

This avoids having to take responsibility for a "systemd" pool (I agree that this makes no sense at all and we don't want that), respects Google's wishes and we don't have so many systemd CI systems out there that it's a big burden to change their config options (essentially just semaphore, I think -- distributions will already use their own configure options for their CI).

This PR takes away the default ntp servers (I agree a systemd vendor pool doesn't make sense.)

EDIT: Oh, I didn't see your comment about skipping timesyncd tests, I should add that to the PR.

Actually, what's the use case for configuring with timesyncd but not providing ntp servers (i.e. when would we skip timesyncd tests)? CI can just pass the option, and I can't think of another use case at 2:30 AM...

Sure, I'm also fine with tests just failing if you forgot to configure with an NTP server. (FTR, I'm not even aware of any timesyncd tests upstream..).

I can't find any timesyncd tests, so I'm not going to add code to skip something that doesn't exist.

@dannyperson @hishamhm I don't understand that interpretation.

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.

Isn't that specifically asking Open Source projects ("you") to get a vendor zone if they use the NTP pool in their default configuration?

So, if systemd wants to use the NTP pool in systemd's default configuration, systemd is particularly welcome to do so, but systemd must get a vendor zone.

It seems to me that "vendor zone" is just a name for a concept, and it's simply an accident of history that it isn't called "default config zone". Correct me if I'm wrong, but isn't arguing that systemd is not a vendor like arguing that you can't wear aviator sunglasses if you're not a pilot?

@kekimmo Worse, the idea is to avoid setting up a sane default because insane defaults (Google) exist and were/are preconfigured.

The two solutions here are obvious:

1. Set up a sane preconfigured option if a preconfigured option is to exist at all: Replace Google with systemd.pool.ntp.org, allowing CoreOS to register it so that it feels comfortably NIH to people who object to self-vendoring (???).
2. Remove defaults and make the build halt and catch fire if a sane NTP server isn't provided, so downstream users know they must provide for themselves. Have a flag for testing.

The first seems to require the least work; just change the default to a sane one and move on.

If @poettering doesn't want to vendor a pool, doesn't want the NTP servers to be blank by default and Google doesn't want systemd to use their test servers, the only possible solution I could see is for ntp.org to provide some sort of devtest.pool.ntp.org if they are willing to, so that systemd and other projects that feel similarly can use it as a reasonable default without annoying anyone.

I don't think that CoreOS registering systemd.pool.ntp.org is the best move. as to me it sounds like @poettering simply doesn't want any end-users to view systemd as some sort of a product providing its own services and, (at least in the minds of some users), being assigned the responsibility for those services or start treating systemd as a separate product, instead of it being an integral part of the distribution you're using.

I, personally, can sort-of see the reasoning behind this; An analogy: If you're ie a supplier of a physics library for game developers to use, you don't want gamers, (end-users), to start treating your library like a separate product that they can call, rely on etc. - this is the sort of realationship systemd seems to see itself in with Linux distributions; we are not the end product and therefore are not providing any services for end-users to rely on.

So, to make everyone happy, I think the solution is fairly simple:

1. A third-party needs to provide a "neutral" NTP server that systemd can use by default and not have it be associated with systemd as in "being provided by/a part of" systemd, (I assume that they don't want to use RedHat's servers here to not promote the idea that systemd is being "controlled" by RedHat).
2. systemd needs to adopt the neutral NTP servers ASAP.
3. Everyone needs to calm down.

Here is a plot how time1.google.com smeared the time over the leap second:
http://people.ntp.org/burnicki/leap-second-2015-06-30/time1.google.com-216.239.32.15.png

And here is what time.windows.com was doing:
http://people.ntp.org/burnicki/leap-second-2015-06-30/time.windows.com-23.99.222.162.png

So I's say neither of them is appropriate for accurate timekeeping.

I have now deleted a couple of hate-filled messages here and locked the issue. I'll unlock it again in a few days when the reddit peanut gallery lost interest.

I have now unlocked this issue again. I have also put together PR #554, which adds a configure time warning, and documentation for the issue. If people leave the default google ntp servers in, they'll now get a configure time warning.

@isomer does this make sense to you? Again, I am pretty sure we should not register systemd as a vendor pool project with ntp.org since downstreams really should register their own individual ones, and nobody should use a systemd pool at all. OTOH we also would like to ship something that allows people to test systemd without having to register/pick an ntp.org vendor pool. Hence I chose the Google NTP servers. For this usecase it doesn't matter really if they implement a non-standard clock, and it doesn't matter either if it's a service that can go away any day.

Of course, if Google explicitly doesn't want us to use the service even for this kind of testing setups, even if we acknowledge that it isn't accurate and not officially supported, we could remove the reference entirely. Can you elaborate on this?

Again, all downstream distros I am aware of have their own ntp.org vendor pools anyway, and set them at ./configure time. Only folks who build everything from source on their own, without using any kind of prepackaged distro would run with these defaults. Hence the default should really doesn't matter too much in real life.

@poettering Given that the server would near-exclusively be used for testing, is there an actual reason the default (non-vendor) ntp.org servers won't do? FWIU, they are completely fine for personal and testing use. It just seems like there would be very low usage of them, especially now that a warning is being added.

@jleclanche I believe that systemd using non-vendored ntp.org servers would unfortunately be explicitly against their policy.

You must get approval from the server operator before you hardcode any IP addresses or hostnames. 
This is easy to get if your own organization runs the NTP servers you are planning to use. In most other cases you will not get it.

Do not use the standard pool.ntp.org names as a default configuration in your system. The NTP Pool can offer services for you, but it must be setup in advance (see below).

Source: http://www.pool.ntp.org/en/vendors.html

@poettering Thank you for allowing this discussion to continue

Hmm, I fear we scared @isomer away. I will close this issue now, given that #554 has been merged now, which settles the issue from my perspective. @isomer, I'd still be interested in your feedback, and we can reopen the issue, should there be something left to fix.

@poettering

I'm not entirely satisfied with this solution. Warnings get ignored, and you're still using timeX.google.com as default.

If you're hardcoding NTP servers, it's only fair that you take responsibility for those servers.

I may be merely part of the "peanut gallery" of /r/linix but FWIW I also think doing nothing about this is foolish. Let another project generously allocate a pool as offered, and use it. One way or another, you're using someone else's NTP, but the current way is unfair, brittle, and likely unsustainable.

On 24 July 2015 11:48:28 GMT+01:00, Alfie Pates notifications@github.com wrote:

@poettering

I'm not entirely satisfied with this solution. Warnings get ignored,
and you're still using timeX.google.com as default.

If you're hardcoding NTP servers, it's only fair that you take
responsibility for those servers.

---

Reply to this email directly or view it on GitHub:
#437 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Likewise. Alternatively, ask pool.ntp.org for clarification as to whether this is a legitimate use case for the default pool. The wording isn't terribly clear - and it would be nice to clear up any ambiguity - especially if you're dead set against using a vendor pool