Received mail timestamp is off by 7 hours

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Loren M. Lang
> Sent: Thursday, March 03, 2005 12:58 PM
> To: Luke
> Cc: freebsd-questions at 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