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.

Sometimes I’m asked if the NTP Pool really needs more servers. The answer is yes, always!

While the number of servers has grown nicely over the years, so has the number of users so we need

The only (tricky) requirement is that you have a static IP address and expect the server (and IP) to be around for a long time. ntpd doesn’t deal well with changing IP addresses (yet), so this is important.

As mentioned a few months ago, NTP operates exclusively with UTC time. If your system is (typically) one hour off after syncing with the NTP Pool then it’s because your operating system needs to be configured with the correct timezone and daylight saving time setting. If you live in a place that recently changed rules for daylight saving time you need to make sure you have the latest system updates installed.

The goal of the NTP Pool is to provide accurate time to everybody. Though internally it’s really about serving DNS requests. Quite a lot of them, and ideally fast.

Through history we’ve ended up with using the ‘pool.ntp.org’ domain for client access which for performance isn’t really optimal, but it’s what we have. Through a bit of administrative division it ends up that just to find out who to ask for the IP of ‘1.fedora.pool.ntp.org’ you have to send a whole lot of DNS requests out.

Due to the distributed nature of the pool system we don’t know exactly; but based on some sample measurements we estimate that the overall pool system on average handles somewhere between 40 and 120 thousand NTP requests per second.

If we assume it’s 50,000 a second, that makes a bit over 4300 million requests a day!

In a year that’s about 1500 trillion (american) / billion (other countries) requests a day. (1576800000000, if I’m counting the zeroes right).

In many places around the world March is the month of changing clocks as daylight saving time comes and goes.

Usually a number of users write to tell me that the NTP Pool is an hour off during this time and in the fall when clocks change the other way. Happily it isn’t so; because NTP is based on the almost stable Coordinated Universal Time (aka UTC).

If you use NTP and your clock is an hour off, you either need to update your operating system with the latest patches for the time zone information or you need to check that your time zone is configured correctly and “adjust automatically for daylight saving time” is enabled if that option is provided.

Happy New Year everyone! Please take a moment to remind your fellow sysadmins about registering their servers in the pool if they have servers meeting the requirements (~100% uptime and a static and stable IP address).

As mentioned earlier the pool system now has partial support for IPv6 servers.

It’s currently limited to just getting the servers registered though! They are not monitored and the pool DNS system does not give out AAAA records.

This morning I pushed the latest version of the NTP Pool Server code to www.pool.ntp.org. The news are:

• Runs on the code from the git repository

• Translations are back! The end-user portions of the site is now available in English, Dutch and French.

• Partial IPv6 support (thanks to Martin von Löwis). More about this in the next post.

• Apache 2 / mod_perl 2 support - this makes it much quicker to setup a development sandbox.

We hit another milestone in the last few days with 1000 active servers in Europe!

Now of course we need to get more servers added so we don’t slump below that number again - right now the number is 999. Who will take us back over 1000? :-)

Growth in North America have practically stalled on the other hand; we could use more servers there too (and as always in Asia, South America and Africa, too).

I’ve been adding support to the NTP Pool site for translations again.

Before I took over the site it was translated in a bunch of languages, but as the site got dynamic features and more pages we lost that. Now it’s back!

If you are interested in helping then send me a mail at ask@develooper.com. Experience with gettext (“.po”) files or Locale::Maketext lexicons and with version control (Subversion specifically) will be helpful, but if you are willing to learn then it isn’t required.

Early this morning (PST) we had a few hours of “sub-optimal” performance on the monitoring server. A hundred servers or so were marked “bad” and got unnecessary warning mails because of it. users of the pool should not have been impacted. Work is in progress to permanently improve on this.

We were [upgrading the servers](http://log.perl.org/2007/12/upgrades- mostly.html) that the pool web site is running on yesterday and had an outage for a few hours. It should all be back to normal now.

The upgrade was (mostly) about getting all our servers up from RHEL 3 to version 5 (before we had mostly RHEL3 boxes and a few with 4 and 5 …). Now when they are all the same it’s easier for us to manage the configuration across all the boxes and soon we’ll have some more high availability things setup for the pool system. Long term the goal is to get more of the infrastructure completely distributed, but the website (for showing stats etc) will likely still be in just one place.

A relatively frequent question I get is “when will the pool support IP v6”.

It’s on the “road map”, but not too high up on the list. Months ago I wrote up the current plans on the NTP Pool wiki (now a dead site…).

With assistance from Guillaume Filion the fifth pool.ntp.org name server is now running the new DNS software, too. It’s located in Germany. We have a few more servers offered by volunteers ready to be setup and we’ll work on that over the next week or so and then we’ll experiment with how best to use them to get the best possible performance for the pool users.

The difference is that now pool operators shouldn’t see “spikes” in traffic, unless a big ISP caches the DNS entry and gives it out to many many many clients. If that happens we’ll experiment with adjusting the TTL of the served records (The “TTL” is the time-to-live, the time the data should be cached by the end-user nameserver).

We deployed the new DNS system to 4 out of the 5 pool.ntp.org nameservers. We have several new systems that volunteers have offered ready to be setup, but no time to configure and test them yet. Hopefully it will be done within a week or so…

We’ve noticed an issue with the new system that it seems too eager to send traffic to the high bandwidth systems rather than the low-bandwidth ones. I am looking into it, although not with too much urgency as none of the high-bandwidth server operators have gotten more traffic than they can handle.

On hearing how many people had sent in applications for the equipment giveaway our friends at Meinberg offered us some more equipment!

For diversity from the GPS units the extra 3 systems will be DCF77 cards (PCI or PCI-Express).

Since DCF77 only works in Europe we’re planning to give them out there and then pick hosts in the rest of the world for the GPS units.

Also - in particular one of the locations having offered to host the LANTIME server is ideal as a future home for the pool system in general, so the LANTIME (also donated by Meinberg) that I’m currently using will also be sent out (location to be determined).

I’ve setup a weblog for posting news about the NTP Pool project. This will be much nicer and hopefully make it easier to get slightly more frequent updates. The old process had me updating the list of news by editing HTML on the site (or rather, edit in my development copy, commit to subversion and then run the deployment to the site).

I’ve “imported” all the old news into the weblog and soon I will update the main site so it pulls the recent news automatically.

Three awesome news items today:

1: We're announcing the great Meinberg GPS time equipment giveaway. Over the next months we're (thanks to Meinberg) giving away thousands of dollars worth of high quality time-keeping devices.

2: We got a brand new design and layout on the pool site! Many more updates are coming.

3: The pool is the default ntp service in several of the big Linux distributions (Fedora, Debian, RHEL, CentOS and many more). For this reason we really really need more servers to help with the traffic. Hopefully the equipment giveaway will help on this. Please mention it in your weblog or wherever else appropriate.

On a related sidenote we've started alpha-testing a new system for distributing traffic to the servers more evenly and with much less "spikes" in the traffic.

We are getting close to one thousand active servers in the pool system! The pool system has gotten a major software upgrade, most notably safely letting the server operators do more without having to involve me. Please email ask@develooper.com if you see anything odd.

Coming up on the todo list is revamping the monitoring system. With the help of a donated time server generously donated by Meinberg I am working on a better and distributed monitoring system.

The NTP Pool project now has a wikipedia entry.

The system has been changed a little so we now have separate counts for "all servers" (almost 700 servers!) and servers in the global pool (+600 servers!). The global is by far the busiest, as most users don't pick a country or continent zone.

I've also done some more measuring and estimating of the client population and my best guess is that somewhere between 2 and 6 million client systems are using the pool.

The new information for vendors page is up! Please let me know if your operating system/appliance/software vendor is using the NTP Pool but isn’t using a vendor zone.

Welcome Slashdot readers. The Slashdot story was that we had reached 500 active servers, but since the story was posted another 50 or so servers joined us! This is great, thank you everyone. The only way we can keep the load on each server reasonable is by adding more servers quickly. If you can, please join. More than 500 servers in the pool might sound like a lot, but our best guestimates puts the number of clients at either hundreds of thousands or millions of computers.

You can now add your NTP servers (and only your own, please) via the new web interface. Please email me if it doesn't work as expected.

You can now browse the available zones. Also, I split up the front page into a few smaller pages. I've fallen a little behind on adding servers. I'll catch up soon and get the self-service web interface done.

I've added a page for server admins to login and see their servers as they are listed in the pool system. I'm using Bitcard for the authentication, so don't be alarmed when you get redirected over there. In the not too far future I'll add functionality so new servers can be registered via the manage page too.

If you see this message you are fetching this page from the new server. I added a page to keep track of the dns servers.

No news for almost a year… It’s time to say good bye. I’ll hand over the project to Ask Bjørn Hansen effective tomorrow morning.

Details are, of course, in the list archives.

Server count hits 220.

Please do not use OpenNTP as a server for the pool.ntp.org project [2004-12-15: Versions later than 3.6.1 do now properly report the stratum, though].

The monitoring system has been changed: it now uses simple ntp queries instead of ’ntpd’ monitoring servers.

{0,1,2}.pool.ntp.org subzones have been reintroduced.

time.fortytwo.ch will be retired in the long run.

Read more in the [full announcement](https://marc.info/?l=timekeepers- announce&m=119487987909709&w=2).

Current server count: 115.

The ntp packages in Debian GNU/Linux now use pool.ntp.org by default, and include an invitation to join the pool.

A sidenote: some people have experienced problems when trying to reach me per mail. This is nothing personal, but as I’ve been flooded by spam, I now block some countries and some internet providers almost entirely.

There is a Spanish translation - thanks to Xisco Lladó.

Also, I have installed an automatic rating mechanism, so that bad timeservers are automatically removed from the pool.ntp.org nameserver (an associated mailing list has also been created).

Richard S. Shuford (Sun) sent me a note about how to configure nscd properly to work around the fact that it doesn’t do proper round robin of DNS entries. I don’t recommend the use of maxpoll 12 in ntp.conf anymore. As always: more information on the mailing list.

The project now consists of 87 servers - thanks to all who participate. Also, nameservers in the US and in New Zealand will be added shortly. The mailing list has seen some discussions about monitoring server quality - I’ll have to look at this problem more detail. Read the long version of these news in the mailing list archives.

It’s done! The project is now at pool.ntp.org. Also, country level subdomain are being created - the biggest (us) already has 18 servers, with ch (11) and nl (8) being the next biggest. Due to a problem with TCP nameserver requests, no more than 15 servers are visible at any moment in the zone. Debian developer Bdale Garbee considers using pool.ntp.org in the default configuration of the Debian ntp package. Read the longer version of these news in the mailing list archives.

L’associazione dei provider di servizi internet contesta la sanzione amministrativa comminata da AGCOM, nel caso del Piracy Shield e sceglie di impugnare la decisione davanti al Tribunale Amministrativo Assoprovider, l’associazione che tutela i diritti dei provider indipendenti di servizi Internet, si rivolge al Tar contro la multa che AGCOM le ha comminato nello scorso aprile […]

L'articolo Assoprovider ricorre al TAR contro la multa di AGCOM proviene da Assoprovider.

Buonasera a tutti, pubblichiamo le frequenze radio scelte per possibili comunicazioni tra gli utenti in caso di problemi alla rete, il consiglio e’ quello di riportarli su carta.

FREQUENZA PRINCIPALE PMR – CB e HF Rete Radio Prepper del Progetto

CANALE 2 PMR —- 446,01875 Mhz (nessun tono)

CANALE 2 CB

7.190 Mhz HF LSB ( solo per radioamatori )

RIPORTIAMO INOLTRE E FREQUENZE UFFICIALI PER EMERGENZE NAZIONALI E INTERNAZIONALI AD OGGI 9 GENNAIO 2020

Rete HF in Italia

Rete d’emergenza in fonia tra Sala operativa del Dipartimento e Di.Co.Mac.:

3.643,5 — 7.045 – 6.990 Mhz

6990 MHz (psk31)

Rete delle Prefetture:

Fonia: 7.045-3.643 Mhz

PSK31: 6.990-3.580 Mhz

Reti VHF-UHF:

Vengono utilizzati i Link nazionali Analogico e Digitale del CISAR

ponti ripetitori dislocati sul territorio dell’ERA ed ARI

ponti ripetitori mobili a copertura delle aree colpite dall’emergenza

Banda radioamatoriale internazionale

3760-7110-14300-18160-21360

Americhe
3750-3985
Asia
3600-7060-7240-7275