Daylight Savings Time and Energy Policy Act of 2005

Any eta when this patch will be available? It's getting close..

Looks like 7.002 has the updated timezones. Still don't know about V6, though!

Astaro is pushing it close!

Thanks for the workaround Lewis. At least we'll have some solution in case Astaro does not come through for us. But with the way updates have been going recently, I will be afraid to apply any updates to production machines without much testing!

Only a week to go before daylight savings!

We just heard back from Astaro Support. They said that QA is looking at it right now and should know more in the next day or two.

I'm simply amazed at long it has taken people to get on board with this stuff and I'm almost as guilty as everyone else, except there's not much a consultant can when he's waiting for the software from "up above" to float on down.

Last Friday, as an example, Novell *finally* released their GroupWise DST Adjustor [sic] 2007 tool. Last Friday? I can understand not releasing anything until after the last time shift, but come on! [:O]

Considering the number of log files ASL creates, can you just imagine the mess if we don't have our clocks in sync?

Cheers, and thanks for the update from Astaro!

Here is some steps you can do, without needing to apply an unsupported rpm to your install.. this just replaces the TZ data files.

https://secure-support.novell.com/KanisaPlatform/Publishing/51/3655154_f.SAL_Public.html

That's  start, however, it's the first caveat which bothers me:

• These "manual" changes WILL be lost if updates are applied to the system that do not contain the corrected timezone information. The timezone information is included in the timezone package. Applying older versions of this or related packages should be followed by re-applying these "manual" changes.

As we have really little or not control over the automatic update process, and whereas I realize that my install is wholly unsupported and could result in my system crashing, burning, or my house dropping into a fiery pit, I still think that applying the latest TZ update I could find (which fit easily) is a neater solution. I can always roll back manually later on (rpm -U --force) if necessary.

Disclaimer: I'm a Novell consultant, and certified by Novell in NetWare and Linux. I own stock in the Company. However, they're not infallable... [:$]

I opened up a support issue on this last week with Astaro.  Given their occasional habit of putting out patches that break stuff, this is really late in the game to have not yet released a patch.

I was told that it requires a whole new glibc as follows:

=== BEGIN QUOTE ===
Unfortunately this is not a simple RPM package update. The package in question is linked to by glibc, which absolutely everything else in the system is linked to/compiled against. QA is not sure how simply patching the package will affect glibc and the entire system. They may need to upgrade to a newer version of glibc, which means they need to recompile the entire OS and make sure it doesn’t break anything.
=== END QUOTE ===


What's up with that?!?!  I've patched a bunch of other old servers manually by just dropping new files into /usr/share/zoneinfo.  How come Astaro has to completely upgrade glibc?  

Furthermore, if they don't really need to upgrade the glibc, why do they have people in charge of patches that actually think glibc needs to be upgraded?  

I'm pretty happy with my v6.303 but I swear sometimes I wonder if I should have just spent the extra $$$ and went with a solution from a company that doesn't seem so darn cavalier about mission critical stuff.  Yes, I know that DST2007 is unlikely to crash my firewall if it's not patched.  But it still looks pretty poor for Astaro to have not released anything for what (I believe) is their largest installed userbase (v6.X).

While Astaro's answer may be technically accurate, many glibc packages have been DST2007-ready for some time, with the builds modified to *only* address the timezone info (see http://tinyurl.com/27avqs - related to Sarge, but common for a number of distros - and http://tinyurl.com/2jsum3 - which has some specifics related to SuSE).

It has been my experience that if rpm doesn't complain about a glibc dependency, then the timezone package should work without a problem.

A listing of files in the timezone package I installed, for example, shows three executables:

/usr/bin/tzselect
/usr/sbin/zdump
/usr/sbin/zic

and the rest of the files are simple timezone data (which I will not list here, for brevity).

tzselect works (though it is not needed, as the system hasn't been moved); its dependency on glibc is no different than the build of glibc on the box right now.

zdump works, as does zic.

FWIW, glibc on this 6.303 box is glibc-2.3.3-98.38.1. Now, it is my understanding that for the DST2007-compatible timezone package(s), a minimum of glibc-2.2.4-32.2 is required, so I simply don't see where we lack a dependency.

I fail to see why glibc needs to be updated at all to update the timezones on V6. There is a timezone package installed on the system which clearly contains all the timezone data (as also noted at the URL Lewis mentioned earlier: http://tinyurl.com/2jsum3)

Looking at my /etc/localtime, it points to /usr/share/zoneinfo/US/Pacific which is part of the timezone package.

FWIW, RedHat says glibc also needs to be updated on RHEL3... 

I don't remember the details, but they're on RedHat's site.

Barry

Yes, the need to update glibc on RHEL3 is due to the fact that the shipped version of glibc is older than the minimum required by the latest TZ updates (per my earlier note). From the Red Hat kb:

A caveat of only updating tzdata is there but there is no built in mechanism to update /etc/localtime to the latest timezone unless the system is already running glibc-common version 2.3.2-95.40 or greater. If the system is not on these versions, there are additional options. Any of these can be used to update the localtime information: 

 

Update both glibc-common and tzdata at the same time in the same up2date run or with the rpm command.  This will lay down a new binary from glibc-common called tzdata-update which resides in /usr/sbin.  The tzdata package is a requirement of glibc-common, so it will be installed first and will lay down the new tzdata files...

So, it would appear that Red Hat is of the opinion that they require a newer glibc than that which I previously believed would be good for the majority of distros. That said, their note doesn't contradict mine; the reason for the glibc update is to resolve a dependency of the updated tzdata (timezone, for us) package.

FWIW, the entire note on RHEL3 may be found here: http://tinyurl.com/2t4agr.

(And I just realized that I have a WBEL3 box to update as well as - gulp! - a Red Hat 5.2 box...that last one will be fun, I'm sure.)

Yes, the need to update glibc on RHEL3 is due to the fact that the shipped version of glibc is older than the minimum required by the latest TZ updates (per my earlier note). From the Red Hat kb:

A caveat of only updating tzdata is there but there is no built in mechanism to update /etc/localtime to the latest timezone unless the system is already running glibc-common version 2.3.2-95.40 or greater. If the system is not on these versions, there are additional options. Any of these can be used to update the localtime information: 

 

Update both glibc-common and tzdata at the same time in the same up2date run or with the rpm command.  This will lay down a new binary from glibc-common called tzdata-update which resides in /usr/sbin.  The tzdata package is a requirement of glibc-common, so it will be installed first and will lay down the new tzdata files...

So, it would appear that Red Hat is of the opinion that they require a newer glibc than that which I previously believed would be good for the majority of distros. That said, their note doesn't contradict mine; the reason for the glibc update is to resolve a dependency of the updated tzdata (timezone, for us) package.

FWIW, the entire note on RHEL3 may be found here: http://tinyurl.com/2t4agr.

(And I just realized that I have a WBEL3 box to update as well as - gulp! - a Red Hat 5.2 box...that last one will be fun, I'm sure.)

FWIW:  we have a 525F here running 6.303 that didn't get patched in time.  It experienced a kernel panic somewhere around 2:00am this morning, requiring a hard reset from the back of the box and a REALLY long disk scan.

Considering how late Astaro released 6.304, it would have been a nice of them to also send out an email to customers making sure they understood the import of this one (and knew it existed)...  It seems to me that a time change shouldn't be able to take down mission critical equipment like this.

Probably a coincidence.

My 5.x home fw is running fine, aside from being off by an hour (there was no patch for 5.x released).

Barry

Could be, though it would be the first kernel panic/hard crash since we bought it a year ago.

Yep, kernel shouldn't panic because of a timezone change unless there is some kernel module doing some funny business!

You didn't happen to capture the kernel panic did you?