NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Automated Build Framework (GSoC 2009)
The Automated Build Framework (ABF) aims to minimize the problem faced by NTP (and many other projects) in building the software in as many different operating systems and architectures as possible, by providing a way where anyone could download a daemon, which regularly monitors if a new version of the software was launched, downloads, compile and send the (compile) log back the developers.
Benefits to the NTP Community
When finished, NTP's developers could guarantee that the changes made to each new version don't breaks the compile procedures against lots of different operating systems and architectures. Something that would be very difficult (nearly impossible) to do without this system (and many volunteers).
The Automated Build Framework will use a server-client architecture.
The server consists of a webpage where the user could register and download a pre-compiled daemon for his/her operating system and architecture. It will have a way to receive compile logs, sent either manually or by the client, and an administrative interface where you could check the results sent grouped by OS and architecture.
The client will run in background in the volunteer's machine regularly checking for new NTP versions. Once found, it will be downloaded, compiled with low priority, so the user will not have a noticeable loss in performance, and the resulting log sent back to NTP's servers.
This system could be useful to other projects. So it will be done, where possible, in a software agnostic way.
- Requirements document: details, in a high abstraction level, the features to be implemented;
- Architecture document: contains the technical solution to implement the defined requirements;
- ABF server;
- ABF client for GNU/Linux and Windows.
Discussion and Comments
We want the "client" code to be as portable as possible, as one goal of this project is to make it easy to run builds on many different platforms.
- 23 Apr 2009
It would be nice if we could run "hook" or "trigger" scripts at the end of a run. For example, at
we have machines where we want to run the latest
code if it compiles. Other folks might want to also run
and report those results separately from the build reports.
- 23 Apr 2009