r16 - 2015-08-17 - 15:57:54 - ParthKolekarYou are here: NTP >  Dev Web > GoogleSummerOfCode > GSoC2015NtpConfWebGenerator
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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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.

GSoC 2015 ntp.conf web generator - Parth

Website Design

According to the requirement, the ntp.conf parsing will need to be done in the background aync, so as not to interfere with the main server threads.

A suggested method is to make use of celery. A distributed background task queue which can be allocated a task to carry out. The celery requires a backend, and a backend of Redis is suggested to be used for this purpose, as it is an in-memory database, and all temporary parsing data is cleared out.

The post-parsed data will be dumped to a file, which is served via the server directly, without interacting with the longer and time intensive Django backend. The file instance is created when the data is sent to be parsed, but should not be viewed / shown until the status of the Uploaded object is not marked as so.

The actual parser is then free to be any set of python parsing library backend on which even cpu intensive operations can be carried out. This layout allows for the complete decouple of the parser and the front-end logic; and also allows for the seperation of the parser workers onto a different device altogether.

As for the front-end itself, the ace JS library would be extensively used to mark the errors and suggestions. The mentioned REST API allows for a completly different frontend to be made so as long as it follows the REST conventions. This allows cli via curl.

Comments on this design are appriciated.

Summary

Abstract

The ntp.conf comes pre-shipped with the package ntp, and configures the parameters for the ntp daemon, which helps it sync with the right servers in the right way. However, the ntp.conf is not always written in a way that is correct / efficient.

Hence, I propose to make a web-based ntp.conf web-portal that will parse an uploaded ntp.conf and generate a clean ntp.conf based upon a choice based system.

Proposed Implementation

I propose to make a REST api variant for the implementation of this project. The server would be receiving inputted files. The files would then be matched to a set of rules. That would result in formation of an Output File. This file would then be sent to a client parser to display, and also allow a re-check call.

A python / bash / c-program / generic executable that would run with the uploaded ntp.conf as an input and generate the output. This executable method would give immense power to the programmer and completely eliminate the need for any of the complex database dependent complexities. But that would make the back-end less flexible.

The Run-time

I wish to modularize the front-end and the back ends so that the interface between happens only via the built REST api, and for all other tasks, they might as well be hosted on opposite ends of the planet. The front-end would insert the code into the database and would long poll on it until a ready is received. Then it displays the errors and suggestions.

As for the backend, it makes a REST get and gets a ntp.conf to parse.
It reads this output and on successful parse, it would POST a url of the generated JSON in the API. The actual parsing would be done in the back-end.

Notes

  • HMS: I think we will want to have this emit rlimit memlock 0 by default.
  • HMS: The user should not have to provide a file for input. I was thinking that there might be a screen that defaults to whatever we want, and offers the user the ability to upload a file. In that case, we'd parse the file, and if the parse was successful we'd then import those "directives" and adjust the input screen selections accordingly.
  • PLK: Both of these are not too difficult to do... Default case. (When nothing found), would be to dump a blank error JSON, and a complete suggestions JSON. The tricky part still is the multi-language feature. (or atleast a api to translate).


Questions To Adderess

- will there be any refclocks attached to this machine?

- will this machine be serving time to any other machines?

Tasks

  • -Done- Start Working on the NTP Conf Web Generator Backend
  • -Done- Fix a API for Output
  • -Done- Building Front-End for the view and import of ntp.conf.
  • -Done- Build a Front-End for the view of the parsed ntp.conf
  • -X- Make a backend for the parsing of the uploaded ntp.conf

Timeline

Date Task Description % Done
04-27 Community Bonding Students get to know mentors, read documentation, get up to speed to begin working on their projects. choice-yes
05-25 Coding Begins Students begin coding for their GSoC projects choice-yes
06-26 BO Midterm Evals Mentors and students can begin submitting mid-term evaluations. choice-yes
07-03 EO Midterm Evals Mid-term evaluations deadline. choice-yes
07-06 BO Away Time Family Timeout choice-yes
07-27 EO Away Time I'm Back choice-yes
08-17 Wrap-up Suggested "Pencils Down" date. Take a week to scrub code, write tests, improve documentation, etc.  
08-21 Firm "Pencils Down" Mentors, students and organization administrators can begin submitting final evaluations to Google.  
08-28 Final Evaluation Final Evaluations Deadline  
08-28 Code Samples Students begin uploading code samples  
08-31 Final Results Final Results Announced  

Discussion and Comments

 
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r16 < r15 < r14 < r13 < r12 | 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-2019 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