How to do this will vary from distro to distro, and should be handled by your update mechanism (yum, up2date, aptitude, etc) and distro for you rather easily, but basically you need to update your zoneinfo with the new info (typically /usr/share/zoneinfo) and then make sure that /etc/localtime is pointing to the right zoneinfo.

Several ways to test, but one quick way is this…

zdump -v /etc/localtime | grep 2007

If you're good to go you should see this:

melson@mugen:~$ zdump -v /etc/localtime | grep 2007
/etc/localtime  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST isdst=0 gmtoff=-18000
melson@mugen:~$ 

If you're wrong, you should see this:

[root@scan1 root]# zdump -v /etc/localtime | grep 2007
/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

If you're like us and brilliantly go with a commercial distro where you have to pay to get to the repository in a sane fashion but then don't pay for enough licenses, you may not have the luxury of being able to update easily and instead have to do it manually. Normally an up2date will do it.

Here are some simple steps:

1. Download the most up to date tzdata rpm from redhat - our example here is: tzdata-2006m-3.el3.noarch.rpm
2. Install it - rpm -iUv tzdata-2006m-3.el3.noarch.rpm
3. Re-run redhat-config-date (RHEL3) or system-config-date.
4. Make no changes, just close (this is in the background updating the system)

If programs/applications are oddly caching the timezone data in some way they may have to be reloaded for changes to take affect; I've also heard that Tomcat (and/or Java apps) may need additional updating, though have not investigated fully. Most things should be fine - reload all services or do a reboot if you're really paranoid.

How do I set up Solaris for my time zone and daylight saving rules?

U.S. Energy Policy Act of 2005 implements change for the US. Starting in March 2007, DST in the United States will begin on the second Sunday in March and end on the first Sunday in November.

The “U.S. Energy Policy Act of 2005” which goes into effect in 2007 is addressed in the following releases:

SPARC Platform
Solaris 8 with patches 109809-02 or later and 108993-52 or later 
Solaris 9 with patches 113225-03 or later and 112874-33 or later 
Solaris 10 with patches 122032-01 or later and 119689-07 or later 

x86 Platform
Solaris 8 with patches 109810-02 or later and 108994-52 or later 
Solaris 9 with patches 116545-02 or later and 114432-23 or later 
Solaris 10 with patches 122033-01 or later and 121208-03 or later  

1) download patches from http://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage

2) follow install instruction in the patch README (please note this patch install requires 
   system reboots, to ensure that all processes to reload the new zoneinfo database), 
   command to install patch is: # patchadd /path/to/patch-id

3) check patch installed ok by issuing following command and look for the latest revision:
alumni:/export/home/hzhu% showrev -p | grep 109809
Patch: 109809-01 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWcsu
Patch: 109809-03 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWcsu
Patch: 109809-04 Obsoletes:  Requires:  Incompatibles:  Packages: SUNWcsu
alumni:/export/home/hzhu% 

4) test if you would like to be sure:
alumni:/export/home/hzhu% /usr/sbin/zdump -v $TZ |grep 2007
US/Eastern  Wed Feb 21 15:38:01 2007 UTC = Wed Feb 21 10:38:01 2007 EST isdst=0
US/Eastern  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0
US/Eastern  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1
US/Eastern  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT isdst=1
US/Eastern  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST isdst=0
alumni:/export/home/hzhu% 

It is recommended to reboot system after patch install. The zoneinfo database is loaded into the process. The information will not be reloaded until TZ environment variable is changed or process is restarted. In order to ensure that all processes which have loaded the zoneinfo database, reload the new zoneinfo database, is to restart the application/processes, The easiest solution would be to reboot the machine in order to ensure that all the applications are properly updated.

Changes in 2007

The United States has planned a change to its DST observance beginning in 2007. The Energy Policy Act of 2005 mandates that DST will start on the second Sunday in March and end on the first Sunday in November. In 2007, the start and stop dates will be March 11 and November 4, respectively. These dates are different from previous DST start and stop dates. In 2006, the dates were the first Sunday in April (April 2, 2006) and the last Sunday in October (October 29, 2006).

Some countries are still evaluating whether they will adopt the new rules for themselves. You should anticipate more changes in DST and time zone rules for countries that typically align with U.S. DST rules.

Problems Affecting Java Applications

The Java Runtime Environment (JRE) stores rules about DST observance all around the globe. Older JREs will have outdated rules that will be superseded by the Energy Policy Act of 2005. As a result, applications running on an older JRE may report incorrect time from March 11, 2007 through April 2, 2007 and from October 29, 2007 through November 4, 2007.

Solutions for Java Applications

If you are concerned about application failures that may result from these DST changes, you should update your Java Runtime Environment. To see which Java platform versions have the correct time rules to handle the DST changes that will affect U.S. time zones in 2007, see the question Which JRE version updates include which versions of the Olson data? in the Java SE platform USDST FAQ.

For version 1.4 or later, you can also use a tool to modify the time zone data within your existing JRE. Get the “TZupdater” tool from the Java SE download page.

Read more about it. U.S. Daylight Saving Time Changes in 2007

Ok, since i recently had to do this again, and completely forgot how i did it before, i decided to make this a UUG topic. And document. That, and because my planned presenter boogied.

And, running Tomcat as root is just bad, bad form.

The objectives for this exercise are

• install a server-based servlet manager (Tomcat, part of Apache's Jakarta project)

• run both non-SSL and SSL http protocols

• run as non-privileged user (meaning not as root!)

• configured for ports above 1023 (a linux requirement)

• reroute traffic so end users do not encounter these odd ports

• customize the “ROOT” application deployment page

Here is an example of what we want to achieve

• https://dspace.wesleyan.edu/ … the application runs under SSL at “ROOT”

• http://dspace.wesleyan.edu/tomcat … the standard Tomcat “hello” page

For the impatient: Java & Tomcat binaries for Linux

• JRE 1.5.0

• Jakarta/Tomcat

To run Tomcat, a servlet manager, you first need to install java. Obtain the java runtime environment from Sun. Unpack somewhere and install in /usr for example, or /usr/local. Next you need to make the package available.

root@chloe# which java
/usr/bin/java

root@chloe# ls -ld /usr/bin/java
lrwxrwxrwx  1 root root 25 Sep 11 09:46 /usr/bin/java -> /usr/jre1.5.0_06/bin/java

root@chloe# java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)

root@chloe# env | grep -i java
JAVA_HOME=/usr/j2sdk1.4.2_07

Next download Tomcat and unpack in /usr/local for example. Decide on a non-privileged user/group UID/GID which will run Tomcat. Create these entries using useradd under linux. Next lock the password for this user so no logins are permitted (under redhat linux edit the /etc/passwd file and make the first character in the password field an exclamation mark). Then create a startup script for ease of use, for example /usr/local/bin/tomcat.

#!/bin/sh

export CATALINA_HOME=/usr/local/jakarta-tomcat-5.0.27
export JAVA_HOME=/usr/jdk1.5.0_06

if [ "X$1" = "X" ]; then
        echo "Usage: tomcat start|stop"
        exit
fi

if [ $1 = "start" ]; then
        su ferrett -c "$CATALINA_HOME/bin/startup.sh"
        exit
fi

if [ $1 = "stop" ]; then
        su ferrett -c "$CATALINA_HOME/bin/shutdown.sh"
        exit
fi

I'm runnning Tomcat under UID:GID of ferrett:ferrett since i'm installing the Federated Electronic Research, Review, Extraction, and Tabulation Tool. Yes, that'll be two r's, two t's. And two e's. One f.

Next we need an IP for our Tomcat server. This is a requirement if you will be enabling SSL. On any production Linux server at Wesleyan it is typical to have two network interfaces turned on: eth1 for the private 10.3.200.xxx network and eth0 on a certain VLAN, like 6 (the “ITS DMZ”).

So, in this example … eht1, eth0, eth0:4 and our DNS alias for the application.

root@chloe# host 10.3.200.71 gwaihir.wesad.wesleyan.edu
71.200.3.10.in-addr.arpa domain name pointer chloe.wesleyan.private.

root@chloe# host chloe
chloe.wesleyan.edu has address 129.133.6.116

root@chloe# host chloe4
chloe4.wesleyan.edu has address 129.133.6.152

root@chloe# host ferrett
ferrett.wesleyan.edu is an alias for chloe4.wesleyan.edu.
chloe4.wesleyan.edu has address 129.133.6.152

Since we run Tomcat as a non-privileged user, we need to be on higher ports than 80&443. On the “ITS DMZ” the port range 7780-7800 is open by default. Thus we need to redirect traffic for 80→7780 and 443→7781 for example, without the end users having to deal with these odd ports.

IPtables allows for a variety of packet traffic manipulations. Consult this NetFilter/IPtables for details. Basically, we want to redirect (PREROUTE) any incoming traffic for 6.152:80 and 6.152:443 to their respective higher level ports. We do this by creating a NAT filter (Network Address Translation).

### edit the iptables file ###
[root@chloe ~]# vi /etc/sysconfig/iptables

### add the following 4 lines ###
*nat
-A PREROUTING -d 129.133.6.152 -p tcp --dport 80 -j DNAT --to 129.133.6.152:7780
-A PREROUTING -d 129.133.6.152 -p tcp --dport 443 -j DNAT --to 129.133.6.152:7781
COMMIT

### conditionally restart the network ###
[root@chloe ~]# /etc/init.d/iptables condrestart
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: nat filter                [  OK  ]
Unloading iptables modules:                                [  OK  ]
Applying iptables firewall rules:                          [  OK  ]

Almost there. Next, we need to instruct Tomcat to listen to these ports.

### edit the tomcat config file ###
[root@chloe]# vi /usr/local/jakarta-tomcat-5.0.27/conf/server.xml

### change this section ###

    <!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -->

    <Connector port="7780"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="7781" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true" 
    />

    <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->

    <Connector port="7781"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" debug="0" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
       keystoreFile="/usr/local/jakarta-tomcat-5.0.27/conf/ssl.new/keystore.pkcs12"
       keystoreType="PKCS12"
       keystorePass="changeit"
    />

The SSL Connector refers to a “keystore” file. The keystore file is a key database file that contains both public keys and private keys used for authentication and encryption. Here is how to create a keystore file assuming you have a valid certificate for your organization (from VeriSign for example).

/usr/bin/openssl pkcs12 -export -out keystore.pkcs12 \
         -in /somewhere/wesleyan.crt \
         -inkey /soemwhere/wesleyan.key

Make sure the server can read the keystore.pkcs12 file in terms of permissions. Do not store your *.crt and *.key underneath your server. When prompted for a password it's standard to provide 'changeit' (no quotes).

Allright. Start the Tomcat server with your script /usr/local/bin/tomcat start. Check to see if a process is listening at the expected ports.

[root@chloe]# /usr/local/bin/tomcat start

Using CATALINA_BASE:   /usr/local/jakarta-tomcat-5.0.27
Using CATALINA_HOME:   /usr/local/jakarta-tomcat-5.0.27
Using CATALINA_TMPDIR: /usr/local/jakarta-tomcat-5.0.27/temp
Using JAVA_HOME:       /usr/jdk1.5.0_06

[root@chloe]# lsof -i:7780

COMMAND  PID    USER   FD   TYPE  DEVICE SIZE NODE NAME
java    3502 ferrett    5u  IPv6 2083424       TCP *:7780 (LISTEN)

[root@chloe]# lsof -i:7781

COMMAND  PID    USER   FD   TYPE  DEVICE SIZE NODE NAME
java    3502 ferrett    7u  IPv6 2083431       TCP *:7781 (LISTEN)

[root@chloe]# tail /usr/local/jakarta-tomcat-5.0.27/logs/catalina.out

...
...
INFO: Starting Coyote HTTP/1.1 on http-7780
Feb 19, 2007 11:23:31 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-7781
Feb 19, 2007 11:23:31 PM org.apache.jk.common.ChannelSocket init
INFO: JK2: ajp13 listening on /0.0.0.0:8009
Feb 19, 2007 11:23:31 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=17/74  config=/usr/local/jakarta-tomcat-5.0.27/conf/jk2.properties
Feb 19, 2007 11:23:31 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 55 ms

Looks good. Connect to it.

• http://ferrett.wesleyan.edu/
• https://ferrett.wesleyan.edu/

If the iptables redirect is working you'll see the Tomcat welcome page. Try under SSL.

This guy in top-left corner

Unless you've done the next step, ofcourse.

By default the Tomcat informational page shows up as the ROOT web application. We're going to instruct Tomcat to move that to the URL “/tomcat” and put our own application in as the default. Well not exactly our own, let's use myServletWAR … download the servlet directly via this External Link.

Copy this file into /usr/local/jakarta-tomcat-5.0.27/webapps and make sure server can read the file permissions wise. Tomcat will automatically unpack and install the application, you should now have a /usr/local/jakarta-tomcat-5.0.27/webapps/myServletWAR directory. You could access this application via the URL

• http://ferrett.wesleyan.edu/myServletWAR/

That's no fun.

Next traverse to /usr/local/jakarta-tomcat-5.0.27/conf/Catalina/localhost. These xml files define the location of the applications. There may or may not be a root.xml file. In either case, create these two files.

was_root.xml

 <!--
 
     Context configuration file for Tomcat itself, placing it off the
     root so we can have it but use a different application as root.
 
 -->
 
 
 <Context path="/tomcat" docBase="${catalina.home}/webapps/ROOT"
         debug="0">
 
   <!--
   <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="localhost_tomcat_log." suffix=".txt"
           timestamp="true"/>
   -->
 
 </Context>

root.xml

<!--
 
     Context configuration file for myServletWAR, note the path ...
 
 -->
 
 
 <Context path="" docBase="${catalina.home}/webapps/myServletWAR"
         debug="0">
 
   <!--
   <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="localhost_dspace_log." suffix=".txt"
           timestamp="true"/>
   -->
 
 </Context>

Stop and Start Tomcat

Now load

• http://ferrett.wesleyan.edu/ … the myServletWAR application

• http://ferrett.wesleyan.edu/tomcat/ … the Tomcat welcome page

• http://ferrett.wesleyan.edu/myServletWAR/ … note that this still works too

prepared for the UUG meeting of 02/21/2007

Home