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
Related Topics: VirtualBuildBox
The NTP software has proven to be remarkably portable, running on a huge number of different versions of different OSes over the years.
The size of the NTP build and test farm at UDel has been shrinking over the past few years' time, and there are already a number of platforms we do not have access to for build or test access.
It would be helpful if there was an easy way for people to automatically build new releases of NTP and automatically report back the status of these builds.
Possible Implementation Design
Monitor our existing release feed, https://support.ntp.org/rss/releases.xml
, via RSS, and when a new release was available the client would fetch the tarball, build the code, and submit the
file back to the server.
Collect the returned
Prepare a webpage with updated reports on the build status of each architecture.
Questions and Discussion
- Should we only work with "registered" clients?
- It will cut down on abuse/spam.
- Decision: YES, we only interact with "registered" clients.
- We might want to dynamically limit the number of equivalent build systems.
- It would be useful if clients could indicate if they are capable of doing any debugging.
- How might we support a developer who wants to do some testing of patches that are not yet part of the released code?
I think it will be better if the client works with registered client and if a user want to register,registering process will take no time eg. taking any mail id as we do in facebook reg.
To limit the number of equivalent system we will have to compare make.log on server side and fix parameters on which two system can be considered equivalent.It can be done based on kernel used or tools used to build ntp.
Debugging will certainly the added feature of client.
We need a language in which server side and client scripting can be done. python and ruby on rails seems a good choice, perl is equally better.
- 23 Mar 2009
I just finished a prototype in Ruby. It downloads the newest development version to /tmp, compiles and send make.log to NTP_POST_URL, which is a simple PHP script just to check if the key sent is right and saves the file.
The Ruby script is in https://pastebin.com/f49bbd2cf
, and the PHP in https://pastebin.com/f718e165d
There's much more that needs to be done, but it shows basic functionality.
- 29 Mar 2009
Looks good to me Vitor, thanks! Do you have any suggestions on what else we might do to make this even more useful and helpful?
- 29 Mar 2009
Due to the extreme diversity of the platforms supported by NTP I don't think that it will be possible to provide an automated client for every case. The most conservative approach is to make it possible for a participant to manually
download the tarball (possibly via an intermediate system), manually
run the build process, and manually
upload the resulting
(again possibly via an intermediate system) using a browser.
- 01 Apr 2009
@Harlan: I was thinking about making this project as general as possible. So, with the same client, you could subscribe to download/compile n projects. This way, with more projects participating, there'll be more users volunteering. Everyone wins. But I think this is beyond the scope of one summer.
- 02 Apr 2009
@Steve: I agree, there should be means to the user do it manually. It shouldn't add much work to the project (mostly none), anyway.
- 02 Apr 2009
I just finished the first draft of the proposal, it's at https://vitorbaptista.com/GSoC2009-NTP.pdf
. I also submitted it at https://socghop.appspot.com/student_proposal/show/google/gsoc2009/vitorbaptista/t123865348080
. Any comment will be really appreciated.
- 02 Apr 2009
I think we should be able to get some sort of portable script going that will support most any *ix platform. We already require perl for ntp; we might be able to use that for this project.
- 21 Apr 2009
It might also be Really Interesting if this project could have some sort of add-on or plugin that would interface with the https://modules.sf.net
project - that way we could specify different versions of different tools, and perhaps get a "menu" or list of what versions of what tools were on any given client.
- 21 Apr 2009
Amar is implementing a buildbot instance for us that should handle these things.
Has anything happened with this project?
I should have an update on this by the middle of next week.
Brian, Amar says he is expecting to start deploying VM system images "today" (Friday) and we should be able to start doing NTP builds on these by early next week.
We're using buildbot on
now, and we need to spin up some more VM images for other OSes. Amar says we should shift to ganeti, and we may not have the hardware to justify a shift to openstack.