r19 - 2012-10-07 - 06:41:58 - HarlanStennYou are here: NTP >  Dev Web > GoogleSummerOfCode > GSoCProjectIdeas > AutomatedBuildFramework
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.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Automated Build Framework

Related Topics: VirtualBuildBox, Vm1DeploymentPlan

Background

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

Client Code

Monitor our existing release feed, http://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 make.log file back to the server.

Server Code

Collect the returned make.log files.

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?

Comments

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.

-- RahulKumar - 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 http://pastebin.com/f49bbd2cf, and the PHP in http://pastebin.com/f718e165d

There's much more that needs to be done, but it shows basic functionality.

-- VitorBaptista - 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?

-- HarlanStenn - 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 make.log (again possibly via an intermediate system) using a browser.

-- SteveKostecke - 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.

-- VitorBaptista - 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.

-- VitorBaptista - 02 Apr 2009

I just finished the first draft of the proposal, it's at http://vitorbaptista.com/GSoC2009-NTP.pdf. I also submitted it at http://socghop.appspot.com/student_proposal/show/google/gsoc2009/vitorbaptista/t123865348080. Any comment will be really appreciated.

-- VitorBaptista - 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.

-- HarlanStenn - 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 http://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.

-- HarlanStenn - 21 Apr 2009

Amar is implementing a buildbot instance for us that should handle these things.

-- HarlanStenn - 2010-03-03

Has anything happened with this project?

-- BrianUtterback - 2012-05-13

I should have an update on this by the middle of next week.

-- HarlanStenn - 2012-05-13

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.

-- HarlanStenn - 2012-05-18

We're using buildbot on vm1 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.

-- HarlanStenn - 2012-10-07

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r19 < r18 < r17 < r16 < r15 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback