From owner-freebsd-questions@FreeBSD.ORG Fri Mar 4 05:22:13 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FA5B16A4CE for ; Fri, 4 Mar 2005 05:22:13 +0000 (GMT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 087A943D2D for ; Fri, 4 Mar 2005 05:22:13 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j245MDb35943; Thu, 3 Mar 2005 21:22:14 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Loren M. Lang" , "Luke" Date: Thu, 3 Mar 2005 21:22:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20050303205750.GK30896@alzatex.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal cc: freebsd-questions@freebsd.org Subject: RE: Received mail timestamp is off by 7 hours X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 05:22:13 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Loren M. Lang > Sent: Thursday, March 03, 2005 12:58 PM > To: Luke > Cc: freebsd-questions@freebsd.org > Subject: Re: Received mail timestamp is off by 7 hours > > > On Wed, Mar 02, 2005 at 01:00:15PM -0800, Luke wrote: > > > > >>There's no excuse for a mailserver to not be synced to a > NTP source. > > > > > >I'd extend that to apply to any server. Practically all > the things a > > >server does are dependent in some way on the correct time. > > > > I have three excuses: > > 1) NTP is difficult to configure. I've done it, but it > wasn't trivial. > > ntpdate once at boot. > To configure NTP add the following into /etc/rc.conf xntpd_enable="YES" ntpdate_enable="YES" ntpdate_flags="XX.XX.XX.XX" NOTE: the ntpdate stuff is MANDATORY what that does is on boot, BEFORE ntpd is started, ntpdate forces the system clock to the exact time. Then ntpd starts up and merely MAINTAINS the correct time, it doesen't have to start stepping it forward or backward. create the file /etc/ntp.conf containing the single line: server XX.XX.XX.XX prefer XX.XX.XX.XX = IP address of time server. > > 2) Finding an NTP server willing to accept traffic from the > public isn't > > easy either. Every ISP worth it's salt runs NTP on ALL of their routers. It is a requirement for tracking breakin attempts, unexpected router reboots, etc. Many of them configure their routers to allow syncing from customers. Point your NTP client to your ISP's default gateway and most likely it will work. If not, e-mail the support desk of the ISP. They will supply you with an IP number of a time server they run, or the time server their upstream feed provides to them. Most major backbones run NTP servers for the use of their customers. If your ISP is too retarded to help you, e-mail their upstream feed. I can tell you if I ever got a mail from a customer of one of our customers, complaining that our customer wasn't providing time services, I would tell that ISP that they had 1 minute to turn on NTP on their router or they were going to be disconnected from the Internet. > > > 3) If your clock tends to run noticably fast or slow, constant NTP > > corrections tend to do more harm than good, at least in my > experience. It > > got to where I couldn't even run a buildworld because NTP > kept tinkering > > with the clock in the middle of the process. > >From the manpage of ntpd: "...However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway. Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities.... ... As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used..." So, even if you don't use ntpdate correctly, it still covers you ass. Ted