-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timeX.google.com provide non standard time #437
Comments
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:
Maybe not a wise idea :) What's wrong with pool.ntp.org? |
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 |
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!
|
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. |
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. |
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 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 |
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:
There are only three paths forward, given all of the cards on the table:
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:
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). |
Google's NTP servers do not provide UTC time but 'Google Time' so it is not appropriate to use them as default. As we are not a vendor, do not use a vendor pool. Instead, provide no default and require distributions to provide ntp server values.
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.
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:
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 I don't think that CoreOS registering 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:
|
Here is a plot how time1.google.com smeared the time over the leap second: And here is what time.windows.com was doing: 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. |
…uilding systemd Also, explain the situation in the docs. Relates to systemd#437
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
|
@poettering Thank you for allowing this discussion to continue |
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:
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 |
systemd should not default to using time{1,2,3,4}.google.com.
Google doesn't provide timeX.google.com as a public service(0). We don't maintain this to the same level of reliability/availability that we work hard to provide with other services (eg Google Public DNS, websearch etc). We use this for systems outside of our datacenters that need to understand our concept of time.
Google (famously(1)) runs a non standard concept of time, that works well if everything in your infrastructure knows and understands this and is designed to work with this. If you mix and match NTP servers within a machine you'll run into problems (since Google's timeservers are deliberately false ticking). If you mix and match between machines (eg some hosts use Google's time servers, and some use NIST timeservers) then your time won't match up between them. As I write this Google's clock is ≈-0.4s out from UTC.
Services such as NFS are likely to be confused as to the creation times of files and so on, logs won't be comparable between hosts etc.
People shouldn't be using these time servers for their own use. People should definitely /not/ be using these time servers by default without realising it.
Please change systemd's default time servers to some service that is designed to provide a reliable public NTP service.
(0): http://googlecloudplatform.blogspot.com/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html
(1): http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
The text was updated successfully, but these errors were encountered: