Daylight Savings Time and Energy Policy Act of 2005

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

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!

I just ran a quick check on my Novell Security Manager (ASG) 6.303 box:

/etc/localtime  Sun Apr  1 06:59:59 2007 UTC = Sun Apr  1 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime  Sun Apr  1 07:00:00 2007 UTC = Sun Apr  1 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000

:-/

I have just manually pushed timezone-2.5-25.i586.rpm onto my production box as an interim measure. I did some experimenting with the timezone package on a number of SuSE-based machines last evening, and what I found was that, in general, if rpm didn't complain about package dependencies, the updated module was pretty much interchangeable  across the board (don't ask about SuSE Personal 9.1 - it was a nightmare).

I got mine from http://tinyurl.com/3xxfyl, but there are a number of mirrors listed on  http://tinyurl.com/ysy5bq.

As always, this is an unsupported patch, and YMMV. Anyway, I offer it for your consideration.

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.