At work we have a couple of RHEL2 with Oracle. Since the Daylight Saving will experience some modifications, RHEL 2 will need to undergo some hard patches. Like upgrading glibc or some other low level packages.

My question, is there any workaround without having to do a major upgrade on this server.

We want to avoid glibc upgrade specially for the long history of conflight with the Oracle database on top of it.

We would like to see if anyone in this forum knows a workaround to keep RHEL2 up to date.

FYI: this server doesn't have opening to the internet so ntp is not an option.

Take the following for what it is worth. I offer it in hopes it may help, but make your own evaluation before you do anything to your system.

My understanding is that you need to update your time zone (/usr/share/zoneinfo) files? I have dealt with the same situation on a couple of archaic systems a while back. I believe you were alluding to the fact, that for reasons that are totally mysterious to me, these are bundled with glibc. As I have done it, I can attest to the fact that it is possible to download the current files necessary to create a new batch of time zone files without doing anything else. Of course, before you delete or overwrite any existing files (basically in /usr/share/zoneinfo) you should backup the existing files in case something goes wrong. And if you succeed, you will have a whole bunch of files that your RPM db will consider to be "wrong."

I did not (shame on me!) take detailed notes on how I did this. I did, however, bookmark three sites that I used to figure out how to do this. So I offer the following links to you and I wish you good luck!

http://www.twinsun.com/tz/tz-link.htm
http://wpram.com/log/2006/03/04/comm...ylight-saving/
http://www.vanemery.com/Linux/RH-Linux-Time.html

WRT ntp, if I have understood your problem correctly, ntp wouldn't help anyway. Perhaps I am glossing too much (to heck with crossing the tees and dotting the i's), but basically ntp deals with UTC and has nothing to do with time zones.

Well I think Daylight Saving will change this year in the US, and this means that some systems are not ready for the change. For RHEL 3 and 4, there are some patches that will update to the latest policy but for RHEL 2 there is not such patch.

Here is an example that happened in 2006 when Indiana was looking into having Daylight Saving time and how it will impact their servers.

Sound this familiar? any sysadmin had gone through this?

DST time most definitely is changing in the U.S. this year. I believe there have been and will be other changes in the world also.

If RHEL 2 is still supported and you subscribe, then you need to push RH to issue a patch. If not, I would think your only alternatives would be to to either update your servers to a more recent OS, leave the time zones on your servers in error, or do some kind of an ad hoc solution like I just suggested. Am I missing something?

I just figure out that since this is not only a problem that affect me personally. There would be more sys admins facing this situation and maybe someone else would have some experience on this. I know indiana had some similar issues last year and I found some documentation herE:

http://www.indianawiki.org/wiki/Indi...s_Time_in_2006

An ingenions idea such as building a local ntp on the newer server and have the 2.x sync to it. Then again my issue will be on forecasting what can go wrong.

Feel free to correct me, but I think you are barking up the wrong tree talking about NTP. Following the Unix tradition, Linux system time is the number of seconds after the beginning of 1970, UTC. So while NTP is useful for keeping your system time accurate, it has nothing to do with time zones or Daylight Saving Time! If you try to adjust your system clock based on time zones or Daylight Saving Time, you will really screw yourself up. DST and TZs only come into play in translating between system time and human readable time.

As the article states, the preferred solution is the vendor supplied one. If you can't do that for some reason, the solution I've done on my archaic systems seems to work, but the time zone files are then out of sync with the RPM data base.

Nice replies Guuys. Expecting 1 more now. Like we have variety of Redhat Linux versions. E.g Redhat 8.0 and Redhat 9.0 as well. I didnt get any DST information for these systems. So guys if you have any , please let me know.
Do i require to install any tzdata on such systems or need to upgrade glibc version ??
Do reply.

Neither RH 8.0 or nor RH 9 are supported any longer. So I doubt that updating glibc would do any good since you couldn't get the vendor's version for it (but I could,as always, be wrong). FYI, RH 8.0 was one of the archaic systems that I referred to in post #2 which I successfully updated using tzdata. YMMV. It seemed to work fine for me (but like I said, I didn't take detailed notes and I don't remember the steps clearly). Realize using the tzdata will put all of the files in /usr/share/zoneinfo out of sync with your RPM database; i.e. running rpm -V on the appropriate package will show a lot of mismatches. As always in such case, I would recommend first backing up your existing files in /usr/share/zoneinfo.