On Wed, 10 Jan 2007, P. Larry Nelson wrote:
> Michael Mansour wrote on 1/9/2007 5:34 PM:
> > Hi,
> >
> >> I've got one SL 4.4 system and it has tzdata-2006g-1.EL4.
> >> All my SL 3.0.4 systems have tzdata-2004e-1.EL.
> >> My one SL 3.0.5 system has tzdata-2005f-1.EL3
> >> My RHEL_3 systems have tzdata-2006m-3.el3.
> >> My RHEL_4 systems have tzdata-2006m-3.el4.
> >> And my RedHat 7.3 and 9.0 systems have no tzdata rpms. ?
Note that RHEL 2.1 is close to 7.3 .
-Connie Sieh
> >
> > Old RH releases didn't have separate RPM packages, they were contained in
> > glibc RPMs.
> >
> >> Other Than the unsupported RH 7.3 and 9.0 systems, all my systems
> >> are as up to date as I can make them, given yum cron jobs and RHN
> >> notices from RedHat.
> >
> > For 7.3 and 9.0 you should (very quickly) update to what was released from the
> > Fedora Legacy project. Any moment now they will be removing the servers
> > hosting the packages.
>
> Yes, I'm aware of their demise - I've been using them ever since we lost
> support from RedHat. And I've gotten as many updates as I've deemed
> applicable. However, I'm wary of upgrading the glibc RPMs for fear
> that will break programs our users are still running on the CDF data.
> We've still got one or two folks finishing up, so I'll migrate out of
> the RH 7.3 & 9.0 world a few boxes at a time.
>
> >> So, how does one know if times will get changed properly for the
> >> new DST changes?
> >
> > Use zdump:
> >
> > # zdump -v Australia/NSW |grep 2007
> > Australia/NSW Sat Mar 24 15:59:59 2007 UTC = Sun Mar 25 02:59:59 2007 EST
> > isdst=1 gmtoff=39600
> > Australia/NSW Sat Mar 24 16:00:00 2007 UTC = Sun Mar 25 02:00:00 2007 EST
> > isdst=0 gmtoff=36000
> > Australia/NSW Sat Oct 27 15:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EST
> > isdst=0 gmtoff=36000
> > Australia/NSW Sat Oct 27 16:00:00 2007 UTC = Sun Oct 28 03:00:00 2007 EST
> > isdst=1 gmtoff=39600
>
> No zdump on any of my systems returns any text with "2007" in it. They only
> return two "1901" and two "2038" lines.
>
> >> And what does one do for unsupported legacy systems?
> >
> > Decommission them or upgrade their OS releases. Fedora Legacy is no longer
> > active and is shutdown, but you may be able to pickup their packages before
> > they remove them from the ftp servers.
> >
> > Other than that, use zic to compile your own zone information.
> >
> >> Don't think I want to look forward to manually changing 50+ systems.
> >> Also can't say I've heard of this change in start/end time for DST.
> >> Ah well...
> >
> > If you have legacy systems in place, you should have started migration of them
> > to either decommission or upgrade about 12 months ago now. You're long overdue.
> >
> > Due to their unsupported nature, they can be easily compromised either now (if
> > you haven't been using fedora legacy RPMs) or in the not to distant future if
> > you have.
> >
> > Regards,
> >
> > Michael.
>
> Yep, the migration to all SL 4.4 (except for some key servers which will
> remain RHEL) is about to begin. I know they're long overdue - wanted to
> migrate as much as 2 years ago, but it wasn't my call. Legacy CDF code
> was still being run and it would not run on anything but RH 7.3.
> Now, of course, the code has been ported (so I'm told) so as to run on
> SL 4.4, and that's where I intend to go, hopefully before March 11 when
> the time changes! :-)
>
> Thanks for the response!
> - Larry
> --
> P. Larry Nelson (217-244-9855) | Systems/Network Administrator
> 461 Loomis Lab | High Energy Physics Group
> 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill.
> MailTo:[log in to unmask] | http://www.uiuc.edu/ph/www/lnelson
> -------------------------------------------------------------------
> "Information without accountability is just noise." - P.L. Nelson
>
|
