Vous êtes sur la page 1sur 5

Chile End of DST Time Change INTRODUCTION Find below manual changes required on specific systems components in order

to maintain compatibility with recent announced time change in Chile as SOLARIS (1) Make a backup of file southamerica located at the path /usr/share/lib/zoneinfo/src #cp /usr/share/lib/zoneinfo/src/southamerica /usr/share/lib/zoneinfo/southamerica.backup Copy the attached file southamerica to the path /usr/share/lib/zoneinfo/src: Verify that the owner and group privileges are root and bin respectively #chown root:bin /usr/share/lib/zoneinfo/src/southamerica #chmod 644 /usr/share/lib/zoneinfo/src/southamerica (2) Backup following files with archiver which can maintain hardlinks.(Some may not exist depending on the Solariss version) /usr/share/lib/zoneinfo/America/Santiago /usr/share/lib/zoneinfo/Pacific/Easter /usr/share/lib/zoneinfo/Chile/Continental /usr/share/lib/zoneinfo/Chile/EasterIsland {Example using tar} #cd /usr/share/lib/zoneinfo # tar cvf zonebackup.tar \ America/Santiago \ Pacific/Easter \ Chile/Continental \ /Chile/EasterIsland (3) Verify the Actual Rules # zdump -v Chile/Continental | grep "2012" Chile/Continental Chile/Continental Chile/Continental Chile/Continental Chile/Continental Tue Feb 28 18:21:31 2012 UTC = Tue Feb 28 15:21:31 2012 CLST isdst=1 Sun Mar 11 02:59:59 2012 UTC = Sat Mar 10 23:59:59 2012 CLST isdst=1 Sun Mar 11 03:00:00 2012 UTC = Sat Mar 10 23:00:00 2012 CLT isdst=0 Sun Oct 14 03:59:59 2012 UTC = Sat Oct 13 23:59:59 2012 CLT isdst=0 Sun Oct 14 04:00:00 2012 UTC = Sun Oct 14 01:00:00 2012 CLST isdst=1

Version: 1

Oracle-Sun

Page 1

Chile End of DST Time Change # - Update zoneinfo database using zic(1M) and the file created at 1). This command will create and install the new files listed in 2). #cd /usr/share/lib/zoneinfo/src # /usr/sbin/zic southamerica (4) Make sure files are correctly updated # /usr/sbin/zdump -v America/Santiago | grep 2012 America/Santiago America/Santiago America/Santiago America/Santiago America/Santiago # Another way to verify that fix was applied: # zdump -v Chile/Continental | grep "2012" Chile/Continental Chile/Continental Chile/Continental Chile/Continental Chile/Continental # (*) show the new rules set 5) Reboot system IMPORTANT NOTE:

Tue Feb 28 18:53:47 2012 UTC = Tue Feb 28 15:53:47 2012 CLST isdst=1 Sun Apr 29 02:59:59 2012 UTC = Sat Apr 28 23:59:59 2012 CLST isdst=1 (*) Sun Apr 29 03:00:00 2012 UTC = Sat Apr 28 23:00:00 2012 CLT isdst=0 (*) Sun Sep 2 03:59:59 2012 UTC = Sat Sep 1 23:59:59 2012 CLT isdst=0 (*) Sun Sep 2 04:00:00 2012 UTC = Sun Sep 2 01:00:00 2012 CLST isdst=1 (*)

Tue Feb 28 18:53:46 2012 UTC = Tue Feb 28 15:53:46 2012 CLST isdst=1 Sun Apr 29 02:59:59 2012 UTC = Sat Apr 28 23:59:59 2012 CLST isdst=1 (*) Sun Apr 29 03:00:00 2012 UTC = Sat Apr 28 23:00:00 2012 CLT isdst=0 (*) Sun Sep 2 03:59:59 2012 UTC = Sat Sep 1 23:59:59 2012 CLT isdst=0 (*) Sun Sep 2 04:00:00 2012 UTC = Sun Sep 2 01:00:00 2012 CLST isdst=1 (*)

Please restore original files when formal patches will be applied. Failing to do so could cause patchadd failure. In the case of Solaris 10, this procedure should be applied in the Global Zone, Whole root Zone and LDoms if applicable

Version: 1

Oracle-Sun

Page 2

Chile End of DST Time Change JAVA As timezone support in the JRE seems to have become a more sensitive topic in recent years. Sun released the tzupdater tool to address such issues. The TZUpdater tool is provided to allow you to update installed Java Development Kit (JDK) and Java Runtime Environment (JRE) software with more recent timezone data, to accommodate daylight saving time (DST) changes in different countries. Oracle-Sun recommends that you use the latest Sun Java SE platform JDK or JRE update release as the preferred means of delivering both timezone data updates and other product improvements, such as security fixes. However, if you are unable to use Sun's latest JDK or JRE update release, the TZUpdater tool provides a means of updating timezone data while leaving other system configuration and dependencies unchanged. IMPORTANT NOTE: The latest Chile DST change isn't included into the tool latest version yet. The tool will be released a few days after the Supreme Decree is formally published by the government.
Version: 1 Oracle-Sun Page 2

Chile End of DST Time Change Installation Download the TZUpdater tool attached file and unzip it into an appropriate directory. The TZUpdater tool modifies the JDK/JRE software instance that is used to execute the tool. A single image of the JDK/JRE software is modified per execution. You must stop any running instances of the JDK/JRE software to be operated upon before you run the TZUpdater tool on that installed JDK/JRE software image. Run the TZUpdater tool with the following command: # java -jar tzupdater.jar SUNCLUSTER For Sun Cluster, the instructions provided by Solaris engineering are sufficient to address the time change issue. All nodes in the cluster must carry the same time change.

Version: 1

Oracle-Sun

Page 3

Chile End of DST Time Change SERVERS There is no a special requirement to change the time in Serengeti systems. Domains will change automatically according to the change made in the Solaris configuration file. The only step required is to update manually the time on the System Controller for SF3800 to SF6900. Here is the procedure : Note: If the System Controller is already synchronized through an NTP server, the time will be changed automatically, after the NTP server is changed. (this can be verified by using the command showplatform) They would need to do something like this for the SC and all the domains: - Verify the current time :
tpa-sf4800a-sc0:SC> showdate

- Change the time using one of the following examples :


tpa-sf4800a-sc0:SC> setdate --t GMT


tpa-sf4800a-sc0:SC> setdate 040418152012.10 (April 04, 2012 18:15 hrs and 10 sec)

- Verify the time has been changed :


tpa-sf4800a-sc0:SC> showdate

On the Starcat, the system controller runs Solaris, and the procedure is similar to the changes made for domains. The recommendation for Starcat would be one of the following: a) Maintain the same time on SC and Domain. If changing the time on the domains using the zoneinfo workaround, make this change on the SCs as well and avoid any issues with time sync or mismatched timestamps on error logs and dump files. (b) If the SC must have different time than domains, change the domain time using "setdate" command so that the SC knows of the offset value for the domain.

This way, when the SC forces a time sync to the domain at initial power on, it factors in the offset to preserve the difference in time. The only negative impact is now a mismatch in the timestamps of error events, dump files, etc which can make data analysis and troubleshooting more difficult, but not impossible.
Oracle-Sun Page 4

Version: 1

Chile End of DST Time Change The recommendation would be to choose option one and preserve the same time on both domains and SCs, but we understand that the decision is ultimately the customers to make.

STORAGE For Storage Systems, this TimeZone change will only affect the timestamps associated with events logged into the internal log files, for those devices that actually maintain an internal log. As there are too many different types of devices that do this (arrays, NAS, switches, autoloaders, tape libraries, etc.), each one with a different administration mechanisms (front pannel, serial port connection, CLI, GUI, etc.) and there is no single procedure that can be applied in all different storage products.

Version: 1

Oracle-Sun

Page 5

Vous aimerez peut-être aussi