Of course there are going to be time issues today.

[rex007can]

So I have Scalix 10 running on RHEL4.
I updated the OS to comply with the new time changes yesterday.
My server authenticates against Active Directory on a Windows 2000 server.

Here's my problem.

First, the Linux server didn't adjust it's time.
No biggy, I did it by hand.

Problem is, right now the mail server ADDS an hour to all email messages. If the server's clock says 7am, it timestamps all emails to 8am. So if I want emails to show proper time, I have to set the server's clock one hour back. But If I do that, the it can no longer authenticate against AD because of the time discrepancy. So I ALSO have to set my AD server one hour back, which causes other problems.

How...what?
It's pretty confusing.

[ScalixSupport]

Hi!

We've posted a document a while back on this subject. Have a look:
http://www.scalix.com/wiki/index.php?ti ... 01-DST2007

Thanks,
Subir

[rex007can]

NOT Calendar.
Emails.
The timestamp on email is set one hours ahead of system time by Scalix.

My guess would be that this will affect meeting invitations...but I haven't looked at that yet. Because there's no use looking for a fix until I have fixed the underlying problem.

And another thing I just noticed.
I Can't log onto SAC anymore.

[jch]

First, the Linux server didn't adjust it's time.
No biggy, I did it by hand.

I'm not sure why you need to do this. It could, perhaps, be because you didn't set your machine to say that the hardware clock is UTC when you installed, but even then I'm not sure. Linux doesn't adjust the clock when you switch to DST, it's just commands like "date" that change their output.

You'd also avoid this problem if you were running an NTP server and if you're authenticating against AD then I really do recommend running system-config-date and configuring up NTP. It'll save you a lot of time (no pun intended). If you get ntp synchronizing its clock properly I think you'll be in good shape for date stamps being right.

I'm also a little worried that you've only just applied the tzdata erratum for the US DST changes -- that suggests that you're running RHEL4 without about a year's worth of security updates and whatnot and that worries me.

jch

[rex007can]

First. Yes, I had the system sync with NTP, but the clock appeared wrong anyways.
The date command tells me it's an hour late but the emails get the right timestamp. If I change the time (by using system-config-date), then the date command shows me the right time, but all emails get timestamped wrong.

I use spamassassin configured the "old" way, that is with two IP addresses. If I telnet to port 25 on either addresses, I get either the scalix or sendmail SMTP server to respond. Both show the system time. If I manually send an emain with either, both will show up in a mailbox with an hour added to the timestamp.

All logs show proper timestamps. Only emails are affected.
I have 2 servers, both do the same thing.
Except the second one doesn't authenticate against AD, so it's not so critical. Which doesn't mean I dont need to get it fixed.

[rex007can]

Oh and just a side note.
I configured NTP to synch to a local time source.
It synced and the time went to the exact time.
Then I sent an email.
email was stamped one hour ahead.

Restarted Scalix
Email stamped one hour ahead.

[jch]

Hmm. Did you update /etc/localtime after you installed the tzdata update? Not sure what time zone you're in but do something like "cmp /etc/localtime /usr/share/zoneinfo/America/New_York" (the file depends on your time zone) -- if they're different then you need to copy the latter to the former. It mentioned this inthe tzdata release notes as I recall.

Everything that refers to time will need to be restarted to pick up the new /etc/localtime -- it's going to be easier to reboot to make sure everything is getting the right data.

jch

[rex007can]

Solved.
Thank-you for the info.
I had not updated /etc/localtime.
For some reason, I had assumed that a restart of the system would do that (blame it on using Windows...) And since we phically moved the servers last week, assumed it would be done.

Mistery solved. RTFM for me.

[jch]

It's a bug in the RHEL tzdata RPM really -- /etc/localtime should be updated for you. On the other hand, one could argue that it because processes running with the old /etc/localtime will get the time "wrong".

Windows doesn't keep the system clock on UTC, it just shifts the system clock an hour on the DST change days. If you have some timed job (I nearly said cron job) that goes off on during the hour the clocks change, there's no way for the system to tell it's not happened at all in spring and kicking it off twice in Autumn. Sensible operating systems maintain an internal UTC clock!

jch