This morning I was reading through the most recent US-CERT Security alert that describes multiple vulnerabilities found in Sun Java.

The suggested fix is to uninstall Java per Sun’s instructions and install the newest version of Java.

I found it interesting that Sun mentions uninstalling Java through Add/Remove programs may be insufficient, and the Windows Installer Cleanup Utility may need to be used to fully uninstall the program.

According to Microsoft, “You can use the utility to remove installation information for programs that were installed by using Windows Installer. Be aware that Windows Installer CleanUp Utility will not remove the actual program from your computer. However, it will remove the installation files so that you can start the installation, upgrade, or uninstall over. “

This version of Windows Installer CleanUp Utility works correctly in all 32-bit and 64-bit versions of Microsoft Windows. If you have an earlier version installed on your computer, we recommend that you download and install this latest version.

You must be logged on to Windows with a user account that is a computer administrator to run Windows Installer CleanUp Utility.

When you use Windows Installer CleanUp Utility, you can perform the following functions:

To do this, select the programs that you want in the Installed Products list in the Windows Installer CleanUp dialog box. After you make this selection, the utility removes only Windows Installer configuration information that is related to those programs.

Windows Installer CleanUp Utility does not perform the following functions:

If you use this utility to remove Windows Installer configuration information for your program and you plan to reinstall the program, you should reinstall the program in the same folder where you originally installed it. This prevents duplication of files on your hard disk or disks.

Users of our external Groupwise 6.5.6 webaccess gateway have been experiencing problems with their sessions hanging when trying to open items. Users access our internal webaccess gateways, which are the same version and configuration as the external gateway, have not been experiencing this problem. All Groupwise servers were running on NetWare 6.5.5. and were patched up to FTF GW 6.5 post SP6 English only Agents Rev 6.

It did not matter which Internet browser the external users were using, the same problem was apparent for users of Firefox 2.x, 3.x, IE6, and IE7. They’d try to open an item, and their browser would appear to hang for anywhere from a few seconds to a few minutes. Rebooting the webaccess server did not have any affect on the problem.

The following message was seen in the webaccess log file:

Error: Request aborted while waiting on locked conversation

The only Novell TID that was relevant to this problem is TID #10023251.  It describes this exact error message, but it specifically states the error only occurs when trying to view an attachment, which wasn’t the case for our users, since the error was logged when they were just navigating though the webaccess client.

The TID referenced above was not helpful, since it stated the only fix is to have the user perform the action again (ie resend the message) and there are no configurable parameters to increase this timeout.

Here’s what we did to troubleshoot this problem:

First thing I did was to verify the amount of free disk space on the sys volume of each server. The two well behaving servers had at least 750MB free, while the failing server only had 500MB free. Java sometimes behaves poorly when it lacks an abundance of free disk space, so I cleared out 500MB of old log files and restarted the server. Unfortunately, no change in performance or error rate was noted.

I loaded config.nlm on the good internal webaccess servers and the problematic external webaccess server. I then used Winmerge to compare the log resulting files to check for differences in versions of drivers, nlms, and configuration files. One of the team members noticed a difference in how webaccess was being loaded in protected mode. We tried duplicating the change on the external server, but that didn’t have any impact on the situation.

Next I checked the versions of java and tomcat on all machines:
To get the Java version number: java – version
To view the running instances of Java: java – show
To see Java instance memory utilization: java -showmemoryID where ID is the ID of the instance listed when performing java – show with no space between showmemory and the ID number.
Note: You have to switch to the NetWare console logger screen to see the output of these commands

I didn’t see anything abnormal in the problem server’s Java configuration, so next I looked at the Sys:\Apache2\logs\mod_jk.log file. Inside it I saw the following messages, repeated frequently:

jk_ajp_common.c (1318)]: Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=ajp13admin failed errno = 54

jk_uri_worker_map.c (620)]: In jk_uri_worker_map_t::map_uri_to_worker, wrong parameters

jk_ajp_common.c (1483): Timeout with waiting reply from tomcat. Tomcat is down, stopped or network problems

jk_ajp_common.c (1503): Tomcat is down or refused connection. No response has been sent to the client (yet)

These messages made me think communication was definitely failing somewhere. The server administrator in charge of the NetWare servers replaced the server’s patch cable and moved it to another port on the switch, thinking that may help communication. It didn’t.

My co-worker was poking through the NetWare Console Monitor – LAN/WAN drivers – highlight NIC – press tab for stats, and noticed increasing Rx CRC errors, as well as other errors. He replaced the network card, and all of the webaccess errors went away!

So, the other day I wrote about my Java errors I experienced when trying to load VNC in Firefox on a brand new SuSE 10 SP2 server.  Today brought about a new Java error after I installed ConsoleOne 1.3.6f on the
same SLES 10 SP2 servers. I  received the following message while trying to start up ConsoleOne for the first time:

no java found

I figured it had to do with me not using the version of Java that shipped with C1.  Here’s what I did to fix the problem:

1) Browse to the /usr/ConsoleOne/bin/ConsoleOne file and right click on it.
2) Select the Permissions tab, and give Owner write access
3) Edit the /usr/ConsoleOne/bin/ConsoleOne file with gedit
4) Add the following line that points to our java installation directory:
export C1_JRE_HOME=/usr/java/jre1.6.0_07
5) Save the file and exit gedit
6) To run ConsoleOne execute: /usr/ConsoleOne/bin/ConsoleOne

Replace /usr/java/jre1.6.0_07 with the path to your Java installation. 

To the location of your version of Java, run the following from a terminal:
find / -name java

Yesterday I installed two identical SuSE Linux Enterprise (SLES) 10 SP2 servers on their own private network.  Since this private network was completeky isolated, neither server received any updates or patches.  When I tried to connect from one server to the other through VNC at http://192.168.1.2:5801, I received the following message from Firefox:

Plugin Finder Service Window reports Firefox is now checking for available plugins
Click here to download plugin

I figured Firefox was trying to download the Java browser plugin from the Internet.  I had not installed Java during the base installation, so this is what I did to fix the problem:

1)      Downloaded the most recent version of Java,  1.6.0_07 available from http://java.com/en/download/manual.jsp
2)      Copied jre-6u7-linux-i586-rpm.bin to /usr/src/packages/RPMs/i586
3)      Opened a terminal and su root
4)      cd /usr/src/packages/RPMs/i586
5)      Typed chmod a+x jre-6u7-linux-i586-rpm.bin
6)      To start install type  ./ jre-6u7-linux-i586-rpm.bin
7)      Hit the space bar several times to view license agreement
8)      Press y to accept license agreement.  Java will be installed to /usr/java/jre1.6.0_07
9)      Link Java to plugin directory.  To do this type cd /usr/lib/browser-plugins
10)    Type  ln -s /usr/java/jre1.6.0_07/plugin/i386/ns7/libjavaplugin_oji.so

Firefox was then able to see the VNC login screen at
http://192.168.1.2:5801

Sun has disclosed multiple security vulnerabilities within their Java product, which are summarized here.  The categories of vulnerabilities include:

1) Security Bypass
2) Exposure of system information
3) Exposure of sensitive information
4) DoS
5) System access

The following Sun products are affected:

Java Web Start 1.x
Java Web Start 5.x
Java Web Start 6.x
Sun Java JDK 1.5.x
Sun Java JDK 1.6.x
Sun Java JRE 1.3.x
Sun Java JRE 1.4.x
Sun Java JRE 1.5.x / 5.x
Sun Java JRE 1.6.x / 6.x
Sun Java SDK 1.3.x
Sun Java SDK 1.4.x

The recommendation is to update your software immediately to a patched version:

JDK and JRE 6 Update 7:
http://java.sun.com/javase/downloads/index.jsp

JDK and JRE 5.0 Update 16:
http://java.sun.com/javase/downloads/index_jdk5.jsp

SDK and JRE 1.4.2_18:
http://java.sun.com/j2se/1.4.2/download.html

SDK and JRE 1.3.1_23 (for customers with Solaris 8 and Vintage Support Offering support contracts):
http://java.sun.com/j2se/1.3/download.html

Java is one of those programs that seems to keep old versions of the software in Add/Remove programs even after you update to the newest version.  Right now my machine is showing Java 6 Update 3, 4, and 5 in Add/Remove programs. 

I could go in and manually uninstall each of the older versions, but Raymond pointed out JavaRa, a tool that will go in and clean up old Java installations for you, including deleting previous entries of Java from the list in Add/Remove programs.

Check out this tool, especially if you’re running an older XP machine that’s been updated numerous times over the years.