Hallo,
my company ships a VPN appliance based on Debian Linux. For that we applied for an own vendor zone, with no response. I wrote an email to vendors@ntppool.org, but still no response. That all was in January.
Is the project still alive? We’re willing to pay the suggested fee.
Regards,
Bernhard
Project is alive, admin is just busy now. @ask
Well, that was in January… How long does it usually take to get such a vendor zone?
@bernhard.walle In recent months, ages, unfortunately :-(.
@ask No offense intended here, but I’ve seen a few of these threads pop up, and leaving vendors who are trying to follow the proper process waiting months with no response isn’t reasonable.
I get that you’re busy, but if we don’t want people abusing the pool zones or setting things up in a way that we can’t mitigate problems, you really need to prioritise dealing with the vendor zone requests quickly, or delegate that task to someone else. The reality is that if you don’t, vendors will move ahead with their product rollout anyway, and there’s a good chance they’ll do so using the main pool zones, which nobody wants.
Given Google is providing their time service available for commercial use, I guess we can reconsider if it is time to retire vendor zones. Existing vendor zones can continue to work while no new ones are allowed. Volunteers are not joining the pool to help some big companies externalize their business cost…
I fully agree. When you sell hundreds of thousands if not millions of appliances, you can, better, should, be able to support the cost of running them.
The problem as @erayd stated, is some will use the pool anyway because it’s cheaper, easier, safer. How do we handle them if they do not suffer any kind of coercion?
There is a suggested monetary donation on the vendor page information depending on the number of expected devices to help subsidize the usage. That helps to offset the costs of the pool (Web & DNS) hardware and in turn provide the free service for the non-commercial users…
No need to get out the torches & pitchforks just yet…
Just sayin…
We’re not selling hundred thousands of appliances but a few hundreds. We can’t provide an own NTP infrastructure around the world. If it’s only Germany we can use the NTP server of PTB which is also free for commercial use as far as I understood.
I personally don’t want to use Google because (a) it’s Google and (b) the leap second issue which is incompatible with the rest of the world.
And, we’re willing to pay the suggested donation
Regards,
Bernhard
I posted for a vendor zone back in Sept 2018, I think, certainly sometime around then. I chased it up a couple of times then, more recently late last year and each time nothing at all. Not an electronic sausage.
Should we abandon vendor zones and just use pool.ntp.org? (At present we’re using rhel.pool.ntp.org which isn’t right for Oracle Linux.). I have no idea what the suggested donation might be, no one got back to me with any suggestions at all, but I can’t imagine it would be much of an obstacle.
I should add that a vendor zone for Oracle Linux (OL) isn’t for Oracle, it’s for users of OL where ever they are to identify themselves as using OL in much the same way that the rhel, fedora and centos vendor zones are used.
Testing the vendor zone of Ubuntu (ubuntu.pool.ntp.org) and have some funny results.
remote refid st t when poll reach delay offset jitter
==============================================================================
0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.002
+103.122.190.194 103.226.213.30 2 u 129 128 177 8.457 2.580 32.839
+218.161.118.185 216.239.35.4 2 u 64 128 377 13.177 2.779 1.079
+183.177.72.201 119.160.254.155 2 u 27 128 377 8.091 0.343 9.550
+118.163.74.161 10.0.0.16 2 u 31 128 377 24.812 2.455 37.127
+162.159.200.1 10.23.8.29 3 u 27 128 367 34.591 1.575 55.770
+60.248.114.17 33.219.230.8 2 u 103 64 376 12.084 2.365 30.690
+91.189.91.157 132.163.96.1 2 u 84 128 373 207.565 2.082 53.002
+213.199.225.30 212.160.106.226 2 u 29 128 377 317.597 2.008 1.866
#91.189.94.4 17.253.34.125 2 u 80 128 377 267.524 3.114 21.156
#91.189.89.198 17.253.108.125 2 u 31 128 377 264.014 1.038 22.457
+85.199.214.100 .GPS. 1 u 14 64 337 265.758 1.787 22.075
*133.243.238.163 .NICT. 1 u 20 128 377 40.648 0.736 60.733
+91.189.89.199 145.238.203.14 2 u 73 128 377 266.722 1.744 24.498
The 91.189.* servers are from the ntp.ubuntu.com backup pool. But the ntppool gave me the NICT server of Japan Standard Time and some other servers in Europe besides the ordinary servers in Taiwan. Is this intended?
Yes. Currently, you dont get geolocated NTP Servers on Vendor Zones or the general pool.ntp.org, but instead random Servers from the pool with the Speed Setting of 1GB/s
Well, hope this could be changed, at least on a vendor-specific basis. The vendors should know where would their products be polling the pool, and specify what servers fit their need best.
It’s generally not a good idea to use google since their ntp servers are largely blocked in China.
Well, it is the vendor’s decision to run business in a restricted environment like China. And they can still choose Cloudflare as their time source.
Not really in this case, it’s an issue mostly regarding where their customers choose to run the hardware, the vendor has little control over that.
Since this was before cloudflare offered a ntp service they ended up just using the default pools(eg 0.pool.ntp.org) since they never got a vendor zone.
That’s right. If you buy a Pixel phone from Google and bring it unopened into China, even the OOBE will be a problem. And this is not the fault of Google anyway. If the vendor does not intend to do business in China, then the vendor is not responsible for any issues originated from the firewall of China. Consumers should work around this themselves. (In Pixel phone case, prepare circumvention methods like VPN)
Personally I can accept this. Not hardcoding any specific IP is the least requirement.
This vendor sells hardware worldwide from China, so working worldwide out of the box was a requirement. Regardless having regional issues like blocked NTP servers in China is a major support headache even in cases where the vendor is not at fault.
In practice this isn’t really feasible as many of their customers would not be technical enough to work around NTP issues themselves, this vendor wasn’t even able to figure out that China was blocking google’s NTP servers without assistance(I worked for a partner company at the time and basically had to redesign most of their firmware myself).
That’s fine. Since the vendor is doing business around the world, may I assume it is a large corporation? Then building their own time service will always be an option. You know D-Link once abused NTP Pool and was being blamed, after that they build their own NTP server to support their own products. Check ntp1.dlink.com for details.
I’m not sure I would characterize them as large, they sell worldwide but mostly just via direct shipping of hardware to their customers, they have little if any local presence outside of China, I’d say they are a mid sized company, however they outsourced significant portions of their business, they had roughly a dozen software developers on staff when I was working with them.
They would definitely not be competent enough to run a reliable time service themselves, their software development background is weak in general, they are really more of a hardware design company.