DST Change

Nope.  It sure hasn't.  Nice of them to think about us, don't you think?

They ought to hurry a bit with getting it patched at this point. If they don't issue a North American DST patch before they go home this Friday, they'll have missed it. DST in Canada and the USA starts on March 11th.

Nope.  It sure hasn't.  Nice of them to think about us, don't you think?

Nice attitude [;)]

I contacted support a while back about this. The following is me paraphrasing what they told me: They aren't releasing an update for V5 that would address the DST change. They were, at the time, working on the V6 update. V7's already compliant.

We're still on V5. So I think it's either change it by hand, or try something like this:

#!/bin/sh

wget 'elsie.nci.nih.gov/.../tzdata2007c.tar.gz'
mkdir -p /tmp/tzdata
tar xf ./tzdata2007c.tar.gz -C /tmp/tzdata
cd /tmp/tzdata
zic -d /tmp/zoneinfo northamerica
cp /tmp/zoneinfo/EST5EDT /usr/share/zoneinfo/
cp -r /tmp/zoneinfo/America/* /usr/share/zoneinfo/America/
ln -fs /etc/localtime /usr/share/zoneinfo/EST5EDT
zdump -v /usr/share/zoneinfo/EST5EDT | grep 2007
echo '------------------------'
zdump -v /usr/share/zoneinfo/America/New_York | grep 2007
echo '------------------------'
zdump -v /etc/localtime | grep 2007
cd /tmp
rm -rf zoneinfo/ tzdata/
echo "Update completed"


Which I've not done, because tho I think it'd fix the issue I don't have a dev-environment v5 system setup to test it with.

Thanks for the info shanez.

Here's another thread with more info:

Daylight Savings Time and Energy Policy Act of 2005

I would suggest replacing the timezone files manually as then when/if Astaro does update the timezone data, you won't run into conflicts as if you had installed a new timezone RPM as mentioned in the other thread.

We are getting ready to start testing our own fix as well since it appears that we can't count on Astaro to fix this issue.

Is V5 still officially supported? If so, I'm very surprised that they are not willing to fix this issue on that platform. RedHat has released timezone updates for RHEL 2.1, 3 and 4.

with v7 out v5 is going to go away....the not fixing v5's timezone issue is the first sign..time to move to v6 or another product.

Now granted I have no "right" to open a trouble ticket since I just have a lowly home license, but I submitted a trouble ticket on this last night:

Here's what I entered:

With less than a week before Daylight Savings Time is to start for the United States and Canada (Sunday, March 11 @ 2am), there have been no patches from Astaro to deal with this VERY important change.

As I use ASL as an SMTP proxy I can definitely see where time stamps will be at issue.

This change in start/end dates for Daylight Savings Time was put into law in 2005. I know that people have posted questions about it in the forums, yet there have been no patches.

Here's what I received back this AM:

V7 has the necessary packages to apply for this change. Currently there is not a patch for v6 but I believe one is being tested.

I apologize for being unable to resolve this issue with you at this time as our licensing records indicate that your license is for "Home Use only", this support service is for our commercial customers only. For Home Users we provide several online resources such as our knowledgebase www.astaro.com/kb and our UBB www.astaro.org. You're my.astaro.com license show as current. If you wish to purchase commercial licensing please contact the sales office or a representative in your area.

For evaluation assistance please contact one of our sales representatives who can assist in scheduling time with an application engineer or who can place you in contact with one of Astaro's consulting partners in your area.

Now if I was responsible for deploying a major product like a FIREWALL, I would certainly like the chance to test any patches before just putting them blindly into production, lest they turn out to either (1) not work or (2) cause instability (V7, anyone??).

I completely agree that this is long overdue, but I would like to point out that instability is unlikely.
(Assuming the only changes are the TZ files and whatever TZ data GLIBC has.)

Assuming the up2date installs, and the system is restarted, it will either work, or it won't... there will be no in-between.

Of course, if it doesn't work, and there's no rollback, life will suck this weekend. [:P]

Barry

Hello,
At this time there is a plan to have a fix implemented, unfortunately there is no specific date set for the up2date release as far as I can find out this morning.  V7 has this already built in, V6 and V5 as you are aware I am sure, are the ones affected.
A work around I can suggest is to use a public NTP server on the Astaro, such as those found here.
http://ntp.isc.org/bin/view/Servers/WebHome


...Not impressed.  Don't know what is taking so long if they are indeed actually doing anything.  Maybe we are expected to upgrade our stable  production systems to V7?  Not likely here.

I doubt NTP will help... I believe the NTP servers hand out GMT, and it is up to the local OS to figure out what the local time is.

Barry

Greg, if you KNOW you aren't entitled to support, then why be upset with their reply? They answered your question, and gracefully, I thought, mentioned what your options are if you wanted to obtain support. If you are responsible for a major firewall implementation, why wouldn't you put a support case in with that license instead? If you're evaluating Astaro wouldn't you have an evaluation license to use instead?

I don't understand what the big deal is with this anyway. If it's so important that the logs might be out by an hour, There is a simple patch that will work on all versions of Astaro, as well as your wristwatch, microwave, and car. Just login & change the time. I don't mean any disrespect, this is meant to be a light-hearted reply..  I just don't get the big hype over this issue. People keep ocmparing it to y2k, but how many problems did that actually cause?