Date: Fri, 20 Aug 1999 09:25:53 -0600 From: Wes Peters <wes@softweyr.com> To: Brett Glass <brett@lariat.org> Cc: Doug <Doug@gorean.org>, Archie Cobbs <archie@whistle.com>, Lowkrantz Goran <Goran.Lowkrantz@infologigruppen.se>, "'freebsd-security@FreeBSD.ORG'" <freebsd-security@FreeBSD.ORG> Subject: Re: Securelevel 3 ant setting time Message-ID: <37BD7381.80939A1@softweyr.com> References: <4.2.0.58.19990819161554.04790800@localhost> <4.2.0.58.19990820035954.04757b80@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote:
>
> At 04:14 PM 8/19/99 -0700, Doug wrote:
>
> > If you're going to do this anyway, why not just use xntpd? It's
> >more reliable, has better mechanisms to resolve the skew between your
> >various times sources, and will keep your clock within the range of
> >adjustments that are allowable in securelevel 3.
>
> I looked at the man page for xntpd once, and walked away (well,
> VIRTUALLY walked away) scratching my head. It was totally opaque.
> There was no simple information about how to synchronize with the NIST
> every so often; also, it appeared that one needed to leave a large,
> expensive daemon running all the time.
Yes, you have to leave the daemon running. At 140K text, it's not all
that large. If you want to customize it and throw out all the clock
drives you won't be using, it would probably cut the size by half.
You have to leave the daemon running becuase it is a lot smarter about
updating the clock than you are. It will update it more often when it
has to, until it gets the clock tuned to where it is mostly accurate,
then slow down it's rate of adjustment once your clock is not drifting
too far. Even on systems where the clock isn't very good, it usually
only takes a few hours for ntp to get it close, and then it only has to
tickle it once or twice an hour.
> So, I went with ntpdate, which
> was simple and easy to understand (and which got out of the way after
> it adjusted the clock). The system with the worst clock drifts no more
> than 5 minutes every 12 hours -- and that, I suspect, is mainly due to
> busy-waits with interrupts off in the ATAPI driver.
Using ntpdate, if your clock isn't very accurate, it will never become accurate,
because ntpdate doesn't adjust the clock RATE, just the current time setting.
It is solving an entirely different problem.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://softweyr.com/ wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37BD7381.80939A1>