r4 - 2005-02-16 - 14:32:11 - BrianUtterbackYou are here: NTP >  Support Web > StartingNTP > StartingNTPDev
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.8p11 was released on 27 February 2018. It addresses 2 low-/medium-, 1 informational-/medium-, and 2 low-severity security issues in ntpd, 1 medium-severity security issue in ntpq, and provides over 65 non-security bugfixes and other improvements over 4.2.8p10.

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.

Starting NTP Development Discussion

This is where we discuss and debate what goes in StartingNTP.


Setting the clock before starting.

It has been suggested that ntpd -gq ; ntpd is not the best way to start ntpd. Since the -g option allows a single step operation and requires that ntp halt rather than do another step if another is needed, it seems to me that quitting after setting the clock and restarting without restrictions is a good, if not the best, way to do it.


-- RichardBGilbert - 16 Sep 2004


ntp will not halt if another step is needed, unless the step is greater than SANITY (1000, by default) seconds.

The only reason to separate into the two steps you describe is if you want to use a different configuration file for startup and runtime.

Otherwise, there is no functional difference between ntpd -gq ; ntpd and ntpd -g.

(And remember about iburst and -N, at least. But those are described in the main topic.)

-- HarlanStenn - 16 Sep 2004


It seems to me that what we want is to quickly poll all the configured servers using iburst, but not necessarily set the clock when the first server gets within maxdist. This is the intention of the minclock parameter, but since we do not know how many servers will be available at startup, Dave has set the default to 1, since anything else might be dangerous.

So, the truth is that minclock really needs to be adaptive, at least during the startup phase before the first clock set. We want the effective minclock to be the minimum of minclock, or the number of reachable servers, and then make the default be 4 (or 3? Does minclock specify the minimum before or after falseticker detection?)

Another possiblity would be to have maxdist have an additional "fudge factor" during the startup phase. With this scheme, we would defer the first clock selection until minclock servers reach maxdist (minclock defaulting to 1), but accepting any server that is within maxdist+fudge. After the first clock set, fudge becomes 0.

The actual problem is that we want to quickly set the clock to the closest approximation to the real time that we can determine, with an unknown number of reachable servers. Since we cannot know how many servers will be available at startup time, we cannot use static values at compile or configuration time, although a sysadmin might be able to make some plausible guesses at configuation time.

-- BrianUtterback - 16 Feb 2005


Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | 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