From owner-freebsd-security Fri Aug 20 8:26: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id D5FF315355 for ; Fri, 20 Aug 1999 08:25:58 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #1) id 11HqYE-0004Q8-00; Fri, 20 Aug 1999 09:25:55 -0600 Message-ID: <37BD7381.80939A1@softweyr.com> Date: Fri, 20 Aug 1999 09:25:53 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: Doug , Archie Cobbs , Lowkrantz Goran , "'freebsd-security@FreeBSD.ORG'" Subject: Re: Securelevel 3 ant setting time References: <4.2.0.58.19990819161554.04790800@localhost> <4.2.0.58.19990820035954.04757b80@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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