COMUNICATO STAMPA Roma, 20 novembre 2024. Assoprovider, l’associazione dei provider italiani piccoli e medi, esprime la propria solidarietà ed il proprio sostegno alla Commissaria dell'Autorità per le garanzie nelle comunicazioni, Elisa Giomi, commissaria Agcom, che ha denunciato attraverso il suo profilo LinkedIn, che a seguito del post su Piracy Shield – la piattaforma donata da […]

L'articolo Piracy Shield, Assoprovider esprime solidarietà alla Commissaria Agcom Elisa Giomi proviene da Assoprovider.

Un’occasione di confronto sui temi caldi delle TLC, appuntamento 21 novembre ore 15:30 Dopo il seguito delle prime due edizioni, torna la Maratona delle TCL, un’iniziativa ideata da Assoprovider che punta a mettere a confronto gli operatori delle TLC. L’evento, aperto a tutti, si terrà il 21 novembre e sarà visibile  sulle piattaforme Linkedin e […]

L'articolo Al via la Terza Maratona delle TLC (l’agenda e dove seguirla) proviene da Assoprovider.

Perito elettronico, molla tutto per aprire una sua azienda, Radio Data Net, a Vodo Cadore, in provincia di Belluno. Oggi può contare su più di 100 clienti Gli operatori di prossimità soddisfano, innanzitutto, un bisogno di mercato e diventano decisivi per la vita anche delle aziende che nascono in territori digital divisi. Lo sa bene, […]

L'articolo Radio Data Net, la storia di Gianluca, operatore di prossimità ventiseienne proviene da Assoprovider.

Roma, 22 novembre L'Associazione Assoprovider ha presentato un esposto alla Procura regionale della Corte dei Conti di Roma riguardante il sistema Piracy Shield, adottato dall'Autorità per le garanzie nelle comunicazioni (Agcom). L'esposto chiede di accertare la sussistenza di un eventuale danno erariale e la congruità dell'azione dell'Agcom nella gestione delle risorse economiche relative al Piracy […]

L'articolo Piracy Shield: Assoprovider presenta un esposto alla Corte dei Conti per possibile danno erariale proviene da Assoprovider.

Nell'ottobre del 2024, a 19 anni esatti dalla storica vittoria che liberalizzò l'uso del Wi-Fi in Italia, Assoprovider si trova nuovamente in prima linea per difendere il futuro del settore delle telecomunicazioni. Con l'approvazione del decreto Omnibus, ora legge dello Stato, affrontiamo una delle sfide più critiche della nostra storia. 2005-2024: Dal trionfo alla nuova […]

L'articolo Assoprovider, 19 anni dalla liberalizzazione del Wi-Fi, una nuova battaglia cruciale per il settore delle telecomunicazioni proviene da Assoprovider.

Il rischio di carcerazione per gli Internet Service Provider (ISP) rappresenta una minaccia senza precedenti per il settore delle telecomunicazioni in Italia Assoprovider, l'associazione rappresentativa dei piccoli e medi fornitori di servizi Internet in Italia, lancia un forte allarme riguardo agli emendamenti recentemente approvati dalle Commissioni Bilancio e Finanze del Senato nell'ambito del DL Omnibus […]

L'articolo TLC, Assoprovider: Allarme per il rischio carcere agli ISP nel DL Omnibus sulla pirateria proviene da Assoprovider.

La NIS2 è la direttiva sulla sicurezza informatica dell’Unione Europea. I Paesi membri hanno tempo fino al 17 ottobre 2024 per recepirla. Ma cosa cambia? Acronimo di Network and Information Security 2, la NIS2 è la direttiva emanata dall’Unione Europea, allo scopo di rafforzare la sicurezza informatica e la resilienza delle infrastrutture critiche in tutti […]

L'articolo NIS2, cos’è e come impatta sugli operatori di prossimità proviene da Assoprovider.

The Linux Kernel Organization is a California Public Benefit Corporation established in 2002 to distribute the Linux kernel and other Open Source software to the public without charge. We are recognized by the IRS as a 501(c)3 private operating foundation.

• IRS determination letter
• California determination letter

The Linux Kernel Organization is managed by The Linux Foundation, which provides full technical, financial and staffing support for running and maintaining the kernel.org infrastructure.

If you have questions, comments or concerns about the F.A.Q. please contact us at helpdesk@kernel.org.

Email is the only reliable way of contacting Kernel.org administrators.

We are pleased to announce the availability of a new mailing list service running under the new lists.linux.dev domain. The goal of this deployment is to offer a subscription service that:

• prioritizes mail delivery to public-inbox archives available via lore.kernel.org
• conforms to DMARC requirements to ensure subscriber delivery
• makes minimal changes to email headers and no changes to the message body content for the purposes of preserving patch attestation

If you would like to host a Linux development mailing list on this platform, please see further details on the subspace.kernel.org site.

If you are a developer located around Beijing, or if your connection to Beijing is faster and more reliable than to locations outside of China, then you may benefit from the new git.kernel.org mirror kindly provided by Code Aurora Forum at https://kernel.source.codeaurora.cn/. This is a full mirror that is updated just as frequently as other git.kernel.org nodes (in fact, it is managed by the same team as the rest of kernel.org infrastructure, since CAF is part of Linux Foundation IT projects).

To start using the Beijing mirror, simply clone from that location or add a separate remote to your existing checkouts, e.g.:

git remote add beijing git://kernel.source.codeaurora.cn/pub/scm/.../linux.git
git fetch beijing master

You may also use http:// and https:// protocols if that makes it easier behind corporate firewalls.

The Linux kernel community operates a Code of Conduct based on the Contributor Covenant Code of Conduct with a Linux Kernel Contributor Covenant Code of Conduct Interpretation.

setting expertise expectations, making decisions and rejecting unsuitable
contributions are not viewed as a violation of the Code of Conduct.

setting expertise expectations, making decisions and rejecting unsuitable
contributions are not viewed as a violation of the Code of Conduct.

We are trialing out a new feature that can send you a notification when the patches you send to the LKML are applied to linux-next or to the mainline git trees. If you are interested in trying it out, here are the details:

• The patches must be sent to the LKML (linux-kernel@vger.kernel.org).
• One of the cc's must be notify@kernel.org (Bcc will not work).
• Alternatively, there should be a "X-Patchwork-Bot: notify" email header.
• The patches must not have been modified by the maintainer(s).
• All patches in the series must have been applied, not just some of them.

The last two points are important, because if there are changes between the content of the patch as it was first sent to the mailing list, and how it looks like by the time it is applied to linux-next or mainline, the bot will not be able to recognize it as the same patch. Similarly, for series of multiple patches, the bot must be able to successfully match all patches in the series in order for the notification to go out.

If you are using git-format-patch, it is best to add the special header instead of using the Cc notification address, so as to avoid any unnecessary email traffic:

--add-header="X-Patchwork-Bot: notify"

You should receive one notification email per each patch series, so if you send a series of 20 patches, you will get a single email in the form of a reply to the cover letter, or to the first patch in the series. The notification will be sent directly to you, ignoring any other addresses in the Cc field.

The bot uses our LKML patchwork instance to perform matching and tracking, and the source code for the bot is also available if you would like to suggest improvements.

You may access the archives of many Linux development mailing lists on lore.kernel.org. Most of them include a full archive of messages going back several decades.

• listing of currently hosted archives

If you would like to suggest another kernel development mailing list to be included in this list, please follow the instructions on the following wiki page:

• Adding list archives to lore.kernel.org

[lore.kernel.org]
site = https://lore.kernel.org
manifest = https://lore.kernel.org/manifest.js.gz
toplevel = /path/to/your/local/folder
mymanifest = /path/to/your/local/folder/manifest.js.gz
pull_threads = 4

We'd like to announce several small changes to the way Linux tarballs are produced.

If you are in charge of CI infrastructure that needs to perform frequent full clones of kernel trees from git.kernel.org, we strongly recommend that you use the git bundles we provide instead of performing a full clone directly from git repositories.

It is better for you, because downloading the bundle from CDN is probably going to be much faster for you than cloning from our frontends due to the CDN being more local. You can even copy the bundle to a fileserver on your local infrastructure and save a lot of repeated external traffic.

It is better for us, because if you first clone from the bundle, you only need to fetch a handful of newer objects directly from git.kernel.org frontends. This not only uses an order of magnitude less bandwidth, but also results in a much smaller memory footprint on our systems -- git daemon needs a lot of RAM when serving full clones of linux repositories.

Here is a simple script that will help you automate the process of first downloading the git bundle and then fetching the newer objects:

• linux-bundle-clone

Thank you for helping us keep our systems fast and accessible to all.

The Linux Foundation IT team has been working to improve the code integrity of git repositories hosted at kernel.org by promoting the use of PGP-signed git tags and commits. Doing so allows anyone to easily verify that git repositories have not been altered or tampered with no matter from which worldwide mirror they may have been cloned. If the digital signature on your cloned repository matches the PGP key belonging to Linus Torvalds or any other maintainer, then you can be assured that what you have on your computer is the exact replica of the kernel code without any omissions or additions.

To help promote the use of PGP signatures in Linux kernel development, we now offer a detailed guide within the kernel documentation tree:

• Kernel Maintainer PGP Guide

Further, we are happy to announce a new special program sponsored by The Linux Foundation in partnership with Nitrokey -- the developer and manufacturer of smartcard-compatible digital tokens capable of storing private keys and performing PGP operations on-chip. Under this program, any developer who is listed as a maintainer in the MAINTAINERS file, or who has a kernel.org account can qualify for a free digital token to help improve the security of their PGP keys. The cost of the device, including any taxes, shipping and handling will be covered by The Linux Foundation.

To participate in this program, please access the special store front on the Nitrokey website:

• Nitrokey Start for Kernel Developers

All kernel releases are cryptographically signed using OpenPGP-compliant signatures. Everyone is strongly encouraged to verify the integrity of downloaded kernel releases by verifying the corresponding signatures.

$ gpg2 --locate-keys [username]@kernel.org

$ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org

$ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.xz
$ curl -OL https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.6.6.tar.sign

$ unxz linux-4.6.6.tar.xz

$ gpg2 --verify linux-4.6.6.tar.sign

$ xz -cd linux-4.6.6.tar.xz | gpg2 --verify linux-4.6.6.tar.sign -

gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT using RSA key ID 38DBBDC86092693E
gpg: Can't check signature: No public key

$ gpg2 --locate-keys torvalds@kernel.org gregkh@kernel.org
$ gpg2 --verify linux-4.6.6.tar.sign
gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT
gpg:                using RSA key 38DBBDC86092693E
gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

$ gpg2 --tofu-policy good 38DBBDC86092693E
$ gpg2 --trust-model tofu --verify linux-4.6.6.tar.sign
gpg: Signature made Wed 10 Aug 2016 06:55:15 AM EDT
gpg:                using RSA key 38DBBDC86092693E
gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [full]
gpg: gregkh@kernel.org: Verified 1 signature in the past 53 seconds.  Encrypted
     0 messages.

pub   1024D/517D0F0E 2000-10-10 [revoked: 2011-12-11]
      Key fingerprint = C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
uid                  Linux Kernel Archives Verification Key <ftpadmin@kernel.org>

pub   3072R/C4790F9D 2013-08-08
      Key fingerprint = BFA7 DD3E 0D42 1C9D B6AB  6527 0D3B 3537 C479 0F9D
uid   Linux Kernel Archives Verification Key
      (One-off resigning of old releases) <ftpadmin@kernel.org>

As you may be aware, starting with 4.12-rc1 Linus will no longer provide signed tarballs and patches for pre-release ("-rc") kernels. Reasons for this are multiple, but largely this is because people who are most interested in pre-release tags -- kernel developers -- do not rely on patches and tarballs to do their work.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git verify-tag v4.12-rc1
git archive --format=tar.gz --prefix=linux-4.12-rc1/ \
  -o linux-4.12-rc1.tar.gz v4.12-rc1

wget https://git.kernel.org/torvalds/t/linux-4.12-rc1.tar.gz

wget -O patch-4.12-rc1 https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11

wget -O patch-4.12-rc1.gz --header="accept-encoding: gzip" \
  https://git.kernel.org/torvalds/p/v4.12-rc1/v4.11

The XZ tarballs for the following kernel releases did not initially pass signature verification due to benign changes to the tarball structure done by the pixz compression tool:

• 4.11.1
• 4.10.16
• 4.9.28
• 4.4.68

These changes would have resulted in GPG returning "Bad Signature" if you tried to verify their integrity. Once we identified the problem, we generated new XZ tarballs without tar header modifications and now they should all pass PGP signature verification.

We preserved the original .xz tarballs as -badsig files in the archives in case you wanted to verify that there was nothing malicious in them, merely tar header changes. You can find them in the same v4.x directory:

• https://www.kernel.org/pub/linux/kernel/v4.x/

Our apologies for this problem and thanks to Brad Spengler and everyone else who alerted us about this issue.

We are extremely happy to announce that Packet has graciously donated the new hardware systems providing read-only public access to the kernel.org git repositories and the public website (git.kernel.org and www.kernel.org, respectively). We have avoided using cloud providers in the past due to security implications of sharing hypervisor memory with external parties, but Packet's hardware-based single-tenant approach satisfies our security requirements while taking over the burden of setting up and managing the physical hardware in multiple worldwide datacenters.

As of March 11, 2017, the four new public frontends are located in the following geographical locations:

• San Jose, California, USA
• Parsippany, New Jersey, USA
• Amsterdam, Netherlands
• Tokyo, Japan

We have changed our DNS configuration to support GeoDNS, so your requests should be routed to the frontend nearest to you.

Each Packet-hosted system is significantly more powerful than our previous generation frontends and have triple the amount of available RAM, so they should be a lot more responsive even when a lot of people are cloning linux.git simultaneously.

Our special thanks to the following organizations who have graciously donated hosting for the previous incarnation of kernel.org frontends:

• Internet Systems Consortium
• Vexxhost
• Tizen

If you notice any problems with the new systems, please email helpdesk@kernel.org.

Those of you who have been around for a while may remember a time when you used to be able to mount kernel.org directly as a partition on your system using NFS (or even SMB/CIFS). The Wayback Machine shows that this was still advertised some time in January 1998, but was removed by the time the December 1998 copy was made.

Let's face it -- while kinda neat and convenient, offering a public NFS/CIFS server was a Pretty Bad Idea, not only because both these protocols are pretty terrible over high latency connections, but also because of important security implications.

Well, 19 years later we're thinking it's time to terminate another service that has important protocol and security implications -- our FTP servers. Our decision is driven by the following considerations:

• The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons
• FTP servers have no support for caching or accelerators, which has significant performance impacts
• Most software implementations have stagnated and see infrequent updates

All kernel.org FTP services will be shut down by the end of this year. In hopes to minimise the potential disruption, we will be doing it in two stages:

1. ftp://ftp.kernel.org/ service will be terminated on March 1, 2017
2. ftp://mirrors.kernel.org/ service will be terminated on December 1, 2017

If you have any concerns, please feel free to contact ftpadmin@kernel.org (ah, the irony).

If your browser alerted you that the site certificates have changed, that would be because we replaced our StartCOM, Ltd certificates with those offered by our DNS registrar, Gandi. We are very thankful to Gandi for this opportunity.

A common question is why we aren't using the certificates offered by the Let's Encrypt project, and the answer is that there are several technical hurdles (on our end) that currently make it complicated. Once we resolve them, we will most likely switch to using certificates issued by our fellow Linux Foundation project.

If you find yourself on an unreliable Internet connection and need to perform a fresh clone of Linux.git, you may find it tricky to do so if your connection resets before you are able to complete the clone. There is currently no way to resume a git clone using git, but there is a neat trick you can use instead of cloning directly -- using git bundle files.

Here is how you would do it.

1. Start with "wget -c", which tells wget to continue interrupted downloads. If your connection resets, just rerun the same command while in the same directory, and it will pick up where it left off:

   wget -c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
   

2. Next, clone from the bundle:

   git clone clone.bundle linux
   

3. Now, point the origin to the live git repository and get the latest changes:

   cd linux
   git remote remove origin
   git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
   git pull origin master
   

Once this is done, you can delete the "clone.bundle" file, unless you think you will need to perform a fresh clone again in the future.

The "clone.bundle" files are generated weekly on Sunday, so they should contain most objects you need, even during kernel merge windows when there are lots of changes committed daily.

We are happy to announce that Fastly has offered their worldwide CDN network to provide fast download services for Linux kernel releases, which should improve download speeds for those of you located outside North America. We have modified the front page to offer CDN-powered download links, but all the existing URLs should continue to work.

If you would like to avoid using Fastly, you can simply change the URL to have "www.kernel.org" instead of "cdn.kernel.org". As always, please use PGP Signature Verification for all downloaded files regardless of where you got them.

Linus named the upcoming 4.0 release of the kernel "Hurr Durr I'ma Sheep" (see his git commit), so we are celebrating this April Fool's day with a minor prank. If you've been redirected to imasheep.hurrdurr.org, do not panic. It's all part of the joke.

We've also restored all FTP and Rsync access to the mirrors.kernel.org servers, as we seem to have resolved our SSD and dm_cache problems. If you're still using FTP, however, please consider switching to HTTP. FTP is a protocol designed for a different era -- these days everyone should be avoiding it for multiple reasons.

We've had to temporarily limit FTP access to mirrors.kernel.org due to high IO load.

We have recently upgraded our hardware in order to increase capacity -- 16TB was no longer nearly sufficient enough to host all the distro mirrors and archives. We chose larger but slower disks and offset the loss of performance by heavily utilizing SSD IO caching using dm-cache.

While it was performing very well, we have unfortunately run across an FS data corruption bug somewhere along this stack:

megaraid_sas + dm_cache + libvirt/virtio + xfs

We've temporarily removed dm-cache from the picture and switched to Varnish on top of SSD for http object caching. Unfortunately, as Varnish does not support FTP, we had to restrict FTP protocol to a limited number of concurrent sessions in order to reduce disk IO. If you are affected by this, simply switch to HTTP protocol that does not have such restrictions.

This is a temporary measure until we identify the dm-cache problem that was causing data corruption, at which point we will restore unrestricted FTP access.

Since we rely on the OpenSSL library for serving most of our websites, we, together with most of the rest of the open-source world, were vulnerable to the HeartBleed vulnerability. We have switched to the patched version of OpenSSL within hours of it becoming available, plus have performed the following steps to mitigate any sensitive information leaked via malicious SSL heartbeat requests:

• Replaced all SSL keys across all kernel.org sites.
• Expired all active sessions on Bugzilla, Patchwork, and Mediawiki sites, requiring everyone to re-login.
• Changed all passwords used for admin-level access to the above sites.

As kernel.org developers do not rely on SSL to access git repositories, there is no need to replace any SSH or PGP keys used for developer authentication.

If you have any questions or concerns, please email us at webmaster@kernel.org for more information.

If you would like to mirror all or a subset of kernel.org git repositories, please use a tool we wrote for this purpose, called grokmirror. Grokmirror is git-aware and will create a complete mirror of kernel.org repositories and keep them automatically updated with no further involvement on your part.

Grokmirror works by keeping track of repositories being updated by downloading and comparing the master manifest file. This file is only downloaded if it's newer on the server, and only the repositories that have changed will be updated via "git remote update".

You can read more about grokmirror by reading the README file.

git clone git://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git

[kernel.org]
site = git://git.kernel.org
manifest = http://git.kernel.org/manifest.js.gz
default_owner = Grokmirror User
#
# Where are we going to put the mirror on our disk?
toplevel = /var/lib/git/mirror
#
# Where do we store our own manifest? Usually in the toplevel.
mymanifest = /var/lib/git/mirror/manifest.js.gz
#
# Where do we put the logs?
log = /var/log/mirror/kernelorg.log
#
# Log level can be "info" or "debug"
loglevel = info
#
# To prevent multiple grok-pull instances from running at the same
# time, we first obtain an exclusive lock.
lock = /var/lock/mirror/kernelorg.lock
#
# Use shell-globbing to list the repositories you would like to mirror.
# If you want to mirror everything, just say "*". Separate multiple entries
# with newline plus tab. Examples:
#
# mirror everything:
#include = *
#
# mirror just the main kernel sources:
#include = /pub/scm/linux/kernel/git/torvalds/linux.git
#          /pub/scm/linux/kernel/git/stable/linux-stable.git
#          /pub/scm/linux/kernel/git/next/linux-next.git
#
# mirror just git:
#include = /pub/scm/git/*
include = *
#
# This is processed after the include. If you want to exclude some specific
# entries from an all-inclusive globbing above. E.g., to exclude all
# linux-2.4 git sources:
#exclude = */linux-2.4*
exclude =

# Run grok-pull every 5 minutes as "mirror" user
*/5 * * * * mirror /usr/bin/grok-pull -p -c /etc/grokmirror/repos.conf

Special thanks to Benoît Monin for donating a MIT-licensed CSS theme to the kernel.org project to replace the one we hastily put together. Though the Pelican authors have since obtained a free-license commitment from the copyright owners of the CSS files shipping with Pelican, we wanted to have something that looked a bit less like the default theme anyway.

If anyone else wants to participate, full sources of the kernel.org website are available from the git repository.

We've implemented two oft-requested features today:

1. The download links now default to .tar.xz versions of archives
2. There is now a JSON file with the release information located in https://www.kernel.org/releases.json. If you've been screen-scraping the front page, please use this instead.

If you have any other feature suggestions, please send them to webmaster@kernel.org.

Due to a failure in one of the rsync scripts during the maintenance window, the mirrors of /pub hierarchy on www.kernel.org got erased. We are resyncing them now from the master storage, but in the meantime you will probably get an occasional "Forbidden". The entirety of the archive should be rsync'ed in a few hours.

We apologize profusely for the problem and will fix the script to make sure this doesn't happen again.

Contents of git.kernel.org are unaffected.

You are probably wondering what happened to the site's look. Unfortunately, we've been alerted that the default theme shipped by Pelican (which we largely adapted) has an unclear license. Until this is cleared up, we've put together a quick-and-dirty cleanroom CSS reimplementation that preserves the functional aspects of the site, but sacrifices a lot of the bells and whistles.

If you are a CSS designer and would like to donate your own cleanroom style, please let us know at webmaster@kernel.org.

Our apologies, and we promise to keep a keener eye on licensing details of various templates distributed with open-source products.

Welcome to the reworked kernel.org website. We have switched to using Pelican in order to statically render our site content, which simplifies mirroring and distribution. You can view the sources used to build this website in its own git repository.

Additionally, we have switched from using gitweb-caching to using cgit for browsing git repositories. There are rewrite rules in place to forward old gitweb URLs to the pages serviced by cgit, so there shouldn't be any broken links, hopefully. If you notice that something that used to work with gitweb no longer works for you with cgit, please drop us a note at webmaster@kernel.org.

This weekend the system that monitors the NTP servers in the NTP Pool got a major overhaul!

NTP servers are now monitored from a number of monitors across the world, usually closer to the server than the single monitor was before.

One of the most frustrating things about operating an NTP server in the NTP Pool was how random network issues far away from the server would impact the score. Sometimes cause an email to be sent to the operator about potential problems.

This year the NTP Pool Project has been serving time to the world for 20 years!

Trillions and trillions of DNS requests have been served to billions of clients, with the NTP requests handled by thousands of NTP servers across the world day and night.

Development on the project ebbs and flows, but maintenance and upgrades on the production infrastructure is consistent – and constant.

Our community is active; and the NTP server operators even more so with almost 2,000 operators managing the 3,000 IPv4 NTP IPs and 1,600 IPv6 IPs active in the system.

The main website (www.ntppool.org / www.pool.ntp.org) doesn’t set any browser cookies. Some access logs are generated strictly for diagnostics purposes. No long term storage or analytics on user behavior is attempted.

The manage website (manage.ntppool.org) sets a cookie on login to track authentication. The site also keeps a record of the account information you provide and NTP server IPs that are registered. We try hard to not keep any information that’s not essential for operating the system.

Packet is awesome.

When we started planning our recent unplanned server move, we investigated options for having not one, but two sites, for the “hub” systems for the NTP Pool. With 4000 NTP servers and hundreds of millions of clients using the system, it really should be a given!

Evaluating our options on a ridiculously short timeframe, Packet stood out as an interesting choice, though we were a little apprehensive at first if their setup would be too unusual compared to more familiar options.

After a quick chat with some of the friendly staff at Packet, we were off to the races to see if we could get everything migrated in less than a week of nights and weekends. If we could, we’d be able to move the physical servers the following Sunday without downtime to any critical services, and get us closer to having proper redundancy.

Working with the Packet system has been fascinating and extremely productive. Despite having done this sort of work for several decades, it was a surprise how mixing familiar capabilities, APIs and abstractions opened new ways for quickly building and managing powerful, reliable and scalable infrastructure.

The beta site has been updated with new features for managing the accounts. Until now each server had to be associated with just one user login. In the new system servers are associated with an account that can have multiple user logins.

If you can, please try it out and post bug reports or suggestions in the development forum or via email.

The NTP Pool consists of (as of this writing) more than 4000 NTP servers provided by the community, about 40 DNS servers and a good handful of “hub servers” running the website, databases, monitoring (for NTP, DNS, etc) and a bunch of other software to keep the system going.

This spring we learned that the facility the systems were in was being decommissioned and we needed to find other arrangements, quickly. A few weeks later we had some options lined up and a long list of work to make it a smooth migration.

As you might have seen in the news or from the US CERT, there’s an internal counter in the GPS messages that will “rollover” this week.

Poorly implemented GPS receivers might lose track of time because of this.

Many servers in the NTP Pool are using GPS signals to set the time, either directly or indirectly from another server that listens for GPS signals.

The expected impact on users of the NTP Pool is very little or none at all. The NTP Pool monitoring system will detect any systems that are wildly off and have them removed from DNS responses within typically 10-20 minutes.

Daniel Ziegenberg wrote a tutorial for Digital Ocean on configuring NTP for the NTP Pool on Ubuntu.

Oliver Nadler has another tutorial covering non-Ubuntu, too.

There’s a new forum for discussion related to the NTP Pool at community.ntppool.org. Please come join us. There are a couple interesting threads about the recent leap second and lots of empty space for your questions or suggestions. :-)

Since last Tuesday some countries have seen an excessive number of queries to the NTP Pool.

After much detective work on nanog (conclusion) and the #NTP IRC channel it was determined to be a buggy Snapchat app update.

A network switch failed causing an outage for the management system and the NTP Pool website. The DNS and NTP services should only be minorly affected, even if the outage lasts a little while.

I’ll update status website with updates.

The IETF has published a new version of NTP Best Current Practices documenting learned best practices on how to run NTP servers and clients.

If you know a little about the NTP protocol reading it will be a quick way to learn more about how it works “in the wild” (including on your own systems).

Thanks to the kind folks at statuspage.io we now have a system status page. It’s also available at an alternate domain.

Most of the data is updated manually, so it won’t be any better than the busy humans can manage, but it’ll be a better system for giving system updates than posting here (or on the dicussion mailing list).

The new login system that was tested on the beta site has been enabled on the production site.

The login system is now using Auth0 to add more login options than yet another username and password. If you have a Github, Google, Microsoft or other supported account you can use that to login.

If you are one of the many existing users, you have to create a “new account” (sign up again) with the email address you previously used to login to your account. No passwords have been transferred over.

This week we’re testing using Auth0 to login on the beta site. This will hopefully make the user account management much easier for everyone.

The beta site is a full installation of the system running with a separate database that gets new code before the regular site.

As you might have seen a few days ago several potentially critical security vulnerabilities in all versions of ntpd were announced.

Most OS’es have released back-ported fixes. Depending on your specific ntp and network configuration you might not be exposed, but the easiest way to make sure your systems aren’t vulnerable is to apply the software updates and make sure ntpd has restarted on the fixed version.

Alternatively you can read the announcement page linked above carefully and make configuration changes to mitigate the issues.

If you have built ntpd from source, the easiest fix is to update to 4.2.8. If you have trouble building that version, there’s a “4.2.8p1-beta1” version available now from support.ntp.org as well with some fixes.

If you aren’t already subscribed then you might be interested in subscribing to the NTP Pool discussion mailing list. For general discussion of NTP there’s the comp.protocols.time.ntp newsgroup.

If you are using the standard ntpd daemon to serve time to the public internet, it’s important that you make sure it is configured to not reply to “monlist” queries. Many routers and other equipment are included in this.

The configuration recommendations include the appropriate “restrict” lines to disallow any management queries to ntpd. Most Linux distributions will have an updated version by now that just disables the “monlist” queries, that will also solve the primary problem.

The NTP Support wiki has more information.

If you operate a network you can use the Open NTP Project to see if you have vulnerable devices on your network.

This week we had a period of weird behavior for the monitoring system for (mostly) German IPv6 servers.

After much back and forth on the mailing list and numerous debugging sessions we got this information from a network engineer at Hurricane Electric:

The NTP Pool “backend systems” are moving racks at Phyber. To minimize the risk of things going wrong we’re doing it the old-fashioned simple way of turning everything off, moving it and turning it on again. It will mean about an hour where servers are not monitored and we can’t add new ones or access the www.pool.ntp.org site.

In the new rack there’ll be more power available so when the move is done we’ll have more capacity.

Over the last couple of months we had a couple of the “central servers” fail. It hasn’t caused any service outage for the NTP clients, but some of you might have noticed that the manage NTP Pool site has been sluggish at times.

A few months ago I bought a few new servers and sent them down to our friends at Phyber Communications who wired them up in their hosting facility. Over the last weeks I’ve added puppet declarations to configure them and since earlier this evening they’re in production for the web sites and a few other services.

Over the last month the NTP Pool has gotten the biggest upgrade it has had in years. The changes has given us much more scalability and performance.

As you might know, the NTP Pool system is essentially a monitoring system and a smart DNS server. Server operators register their server in the system, the monitoring system checks and evaluates the submitted servers and the DNS server gives end-users a (hopefully) local selection of servers, weighted by preferences given by the server operator and other factors.

Last month there was a big change to the DNS server.

For years the geodns server has had a misconfiguration so users in Great Britain by default (accessing the non-country-code domain) would get a European server rather than a more local one.

The zone in the NTP Pool system has always been called ‘uk’, but the GeoIP library returns ‘gb’ for the relevant users. Oops! The system didn’t have a ‘gb’ zone configured, but knew it was in Europe so would fall back to that.

To safely upgrade some of the DNS configuration infrastructure updates to the DNS data will be suspended for 20-45 minutes. Some parts of the website might also return errors while everything is being updated.

For end-users of the pool there should be no interruption.

Update Maintenance was completed in 20 minutes. The changes were in part to get ready to deploy a new Go based DNS server to replace the current DNS server.

Meinberg have since long generously been supporting the NTP Pool and other open source projects. The monitoring system uses a Meinberg NTP server for “reference time” when checking the more than 3000 servers in the pool. I can’t recommend their equipment or expertise enough.

This month they are giving away in a raffle seven DCF77 computer clocks and three GPS time receivers to current and soon-to-be participants in the NTP Pool.

The form and rules are short and simple, but the deadline is July 29th, so don’t delay!

The client base for the NTP Pool continues to grow, so we also need to increase the number of servers. Being a “public utility” of sorts (you likely use it for some computer or device in your house, office or both even if you don’t know it), we need help from, well, the public. At least the particular kind of public who is running a server or two with static IP addresses and know how to configure a new daemon on it.

Today I am experimenting with hosting www.pool.ntp.org through Fastly. If you don’t know about them, they make an excellent CDN based on Varnish serving billions of requests a day.

The downside is that it is IPv4 only (currently), but then all the “static assets” (CSS files, images, etc) were already served by them, so using the site with only IPv6 was not a good experience.

Fastly is also hosting Perldoc.perl.org and have been doing so for a while.

Some months ago our friends at Phyber setup a few more servers for the NTP Pool project. Over the last months I’ve been moving services to them to make the NTP Pool infrastructure run faster and with more redundancy.

The old RRD based graphs (deprecated a few months ago) are still being used a bit, but really don’t play well with having multiple servers. Over the last week I changed the site to generate the offset and score graphs via the same D3.js based system and PhantomJS.

Today I updated the graphs from being generated by rrdtool to be generated with Javascript and SVG using the wonderful d3.js library. You can see an example of the new graphs or if you have a server in the pool you can use the new graphs.

There are a lot of things I wanted to do that using RRD made hard. Splitting the central parts of the system across more servers than the 2-3 it’s running on now. Supporting multiple monitoring nodes. More interactive graphs. Showing historical data. Etcetera.

As announced some days ago on the pool-dev mailing list, yesterday I moved the “manage your server” section to a separate site. This helps keep the main site fast and made it easier to make all connections to that site encrypted.

Today the NTP Pool site got some changes to run better and faster. In the process there was 10 minutes of downtime late Tuesday (pacific time) and through much of the day Wednesday some pages might have loaded in a language that wasn’t your usual preference.

World IPv6 Day is over, but we’ll continue to serve AAAA (IPv6) records for 2.pool.ntp.org (and 2.europe, 2.fedora, 2.debian, etc).

So far no problems have been reported, even the servers going through IPv6 tunnels seem to work fine.

We already have almost 200 IPv6 servers in the pool; though that’s less than 10% of all the pool servers and they’re mostly in a handful of countries versus the wide deployment we have for IPv4.

While the system is rebuilding some internal statistics, monitoring of some of the IPv4 servers in the pool have been suspended. They’ll be reactivated in about 6 hours. All servers with IDs below 8500 are being monitored again after a break of a couple of hours.

In addition all IPv6 servers are being monitored now and are slowly increasing their scores [for inclusion in the “2.” pool](http://news.ntppool.org/2011/06 /experimentally-enabling-ipv6.html)!

If you are following the pool mailing lists you’ll have seen that the last days have carried a flurry of activity as new code for IPv6 support (and distributed monitoring) has been tested on the “beta pool” site.

June 8th is World IPv6 Day where many sites small and big will enable the IPv6 protocol for the day to help test everyones IPv6 readiness.

Here at the NTP pool we are today enabling monitoring of IPv6 servers; and over the next 12 hours we will start in a limited fashion to serve AAAA (IPv6) DNS records to clients asking for them. Right now the pool site is enjoying a brief break while the new code and database updates are being deployed.

One of the database replicas had some corruption; so I took down the primary database briefly to run some consistency checks there, too. This is taking down the NTP Pool website and delaying some of the monitoring.

Everything will be back shortly.

Today the NTP Pool site was upgraded to run on Plack and Starman instead of Apache.

Please let me know if you encounter any trouble!

This was a bit of work to get done and with this done I’ll get back to adding new features to the system. First up: Integrating some of the contributed translations and finishing the changes to support distributed monitoring and IPv6 support that Martin von Löwis started a while back.

“pool.ntp.org” is serviced by a number of DNS servers. One of them, a.ntpns.org, is actually several servers in an anycast cloud.

Until today it was just served by two nodes, one in Los Angeles and another in Luxembourg (both provided by Solfo). Today a third node in Northern California is joining in, hosted by Sonic.net!

If you are able to provide a server (most virtual servers work, too) on a network with BGP routers to join the anycast cloud, please email ask@develooper.com.

Earlier today the website and monitoring system had several 10-15 minute outages while the databases got moved around; backups reconfigured etc.

Our friends at sonic.net have for years provided some servers that are used for backups and auxiliary functions to the main servers hosted by Phyber.

Recently Sonic.net also started hosting one of the excellent GPS Time Servers donated by Meinberg and when the system eventually starts doing distributed monitoring their servers will likely be the first “second monitoring system”.

The pool servers are having a 45 minute outage to be moved to a new datacenter.

The primary server in the pool system had a brief outage today after running out of memory. All is better now. Because of the distributed nature of the service itself, serving of time to ntp users around the world wasn’t materially affected.

Adrian von Bidder has generously hosted and maintained the mailing lists since he started the project 7 years ago and it’s time for the lists to move. In the next few days the lists will move from fortytwo.ch to lists.ntp.org.

The ’timekeepers’, ‘i18n’ and ‘dev’ lists will be moved over; but the announcements list will be discontinued since de-facto the news.ntppool.org site is where the announcements are. You can subscribe either with the Atom feed or via Feedburner’s email feature at the mailing list page.

Since Saturday morning the NTP Pool server have had trouble routing to some servers in the pool system (about 5%). This was too few to trigger the “help help, something’s wrong!” alerts; so thanks to those of you who sent in tickets!

I opened a support with our provider and hopefully the issue will be resolved shortly.

The monitoring server is on the same network as www.pool.ntp.org (in AS 7012) if you have trouble and want to check traceroutes or BGP information from your end.

If you are IPv6 connected, the www.pool.ntp.org site will now be delivered to you via IPv6.

I did tests on a hundred thousand visitors to the site and nobody who could connect with IPv4 had trouble talking to a site with both “AAAA” and “A” records. The test only included users with javascript however, so it could still miss appliances, older boxes etc. More tests are needed to make the pool.ntp.org service “ipv6 enabled”.

In our ongoing process of getting the NTP Pool IPv6 compatible we took a first (small!) step getting the website partially available via IPv6. For now it’s via an IPv6-only hostname: www6.ntppool.org.

So far the anecdotal reports are that it’s working fine for people with IPv6. The next tests will be to see how connectivity is affected for everyone else if a host has both AAAA (IPv6) and A (IPv4) records in DNS.

The pool keeps growing (although we still need more servers).

Recently we’ve added zones and servers in Costa Rica, Venezuela, Serbia, Croatia, El Salvador and New Caledonia.

But we need more servers all over the world. In smaller developing countries internet use is picking up and local servers will help. In bigger countries usage is also growing faster than the number of servers; so extra help is needed. We’re getting close to 2000 active servers - but for millions and millions of users we need more.