Installing a New Java Version

Basic Steps

1. down load the files from the java download site. Keep them all in /tmp. You will use gtar -C <path> or execute *.bin to put the files to the directory.
2. check space availablity for each target directory by running checkQuota
3. IF you get an executable (*.bin) then create the jdk-* subdirectory under each OS directory, e.g. linux, solaris, etc.
4. IF you get a zipped tarball make sure gtar -C is used to unpack and install the directories.
5. change the patch variable in the installJava script to the latest patch number
6. cd to the place where you downloaded all the files, e.g. /tmp
7. Make sure to change the patch number before running the script.
8. Edit the install script and check that the new version names will unpack properly. Run the installJava* script.
9. run the release script to deploy the new versions to the read-only disk.
10. restart the test server and check that everything still works
11. restart all the other servers. Use the server monitoring page to do this. If that doesn't work, logon to the machine and run the stop/start scripts.
12. update the web page (see url address below)
13. announce to mailing lists (see list names below)

Download sites:

Main site http://www.oracle.com/technetwork/index.html

The download url for Java version 6 (may change but currently)  is

http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u26-download-400750.html

download url for Java version 7

http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

Download to /tmp, the set of files that match the pattern:

Make sure there is sufficient space in the target directories by running

/afs/.slac.stanford.edu/package/java/common/install/checkQuota

if not, clean up by deleting old releases in:

• /afs/.slac.stanford.edu/package/java/i386_linux2
• /afs/.slac.stanford.edu/package/java/amd64_linux
• /afs/.slac.stanford.edu/package/java/sun4x_55

Old releases should not have links to them and their release number should be several levels lower than a current release.

If you still need more space put in an  afs request

Use the mkdir command to create the new directory; for example for patch 26:

        cd /afs/.slac.stanford.edu/package/java/i386_linux2

        mkdir jdk1.6.0_26

Target Directories - Readonly and Shadow Version

visible path = /afs/slac/package/java/directory_name

shadow path = /afs/.slac/package/java/directory_name (note the dot in the path;  the ls command will not show this dir)

*If a download release contains two files one ends up in the target directory under bin

Install the new versions

Change the patch number by editing the script installJava located in

/afs/.slac.stanford.edu/package/java/common/install/installJava

cd to the place where you downloaded all the files and execute installJava from there.

Deploy the new versions

The script /afs/slac.stanford.edu/package/java/build/release is a bourne shell script that assembles the names of the volumes in the java directory that will be updated and then makes calls to the vos_release command which in turn calls vos commands to update a release.  The same script is in the shadow directory but it refers to the visible path when building the package list.

The tomcat script (usually in the ~glast/tomcat/scripts directory) is where the "current" version of java is specified. Tony or Max updates this script.

Once you deploy the new version you must restart the servers so they can pick up the changes. The best way is to restart the test server and see if everything is ok there. If nothing breaks then restart the other servers. The Fermi experiment has an application called Server Monitoring which gives a list of all servers and a way to start or stop the server. Use the show details link to see what version of java is on the server.

For other experiments that do not have this application, you must log on to each server and restart it manually.

Updating the Web Page

Update the web page in the shadow directory (the visible directory is read-only).The path is /afs/.slac.stanford.edu/package/java/common/doc. Use the path plus index.html in the browser location window to view your changes. Once the code is released the web page will also be updated with the copy in the shadow directory.

If you need to make changes to the web page only then rerun the release script using common as the argument:

     /afs/slac.stanford.edu/package/java/build/release common

The common directory, containing the web page index.html will be updated. View the changes on line using the url

http://www.slac.stanford.edu/comp/java/index.html

Announce via Mailing Lists

Policy File

For new java versions you may also need to install a new policy file. These files

should go into a jce directory.

@sys Links, Links and PACKAGE.LINKS

The package.links file contain the list of values for @sys. Links go to a wrapper in common directory, which
magically re-direct to the appropriate binary. So, if you've created a softlink, say i386_rhel60 -> i386_linux2, then you might need to update the PACKAGE.LINKS file so that @sys will know about i386_rhel60. Every few hours a cronjob runs to pick up any new @sys names.

1. cd /afs.slac.stanford.edu/package/java (the shadow directory)
2. edit PACKAGE.LINKS (add the softlink to the @sys list, e.g. i386_rhel60)
3. cd /afs/.slac.stanford.edu/package/build
4. invoke /usr/local/bin/vos_release pkg.java