GO-Joe

GO-Joe provides several diagnostic tools and outputs to help diagnose problems that may arise due to misconfiguration and other difficulties. These should be checked whenever problems are encountered.

JavaOS Console Output

On devices that provide it, the JavaOS console output can be highly informative if the applet terminates prematurely. When viewing this output, look for all exceptions that may be listed. Exceptions may occur that cause further exceptions as the program continues to execute, and it is usually the original exception that indicates the true cause of the problem. In addition, the GO-Joe applet will print messages to the status bar, but not all Java environments will show this status (or they may overwrite it with their own status messages). These messages are also sent to the JavaOS console, so they may be visible in the console log when they are not visible on the status line.

Applet diagfile Parameter

Recall that the applet supports a diagfile parameter that redirects the messages normally printed into the console log into a file on the local disk (or into a port on a remote machine). Note that depending on the configuration of the Java Security Manager, the applet may or may not be permitted to connect to the remote host.

The /tmp/Xerr:n File

The GlobalHost ddx loadable module redirects the standard error output for the session to a file called /tmp/Xerr:n, where n represents the display number of the session. This file s contains diagnostic messages from the GlobalInit program, from the ddx loadable module itself, and from the X clients that run throughout the session.

Common Problems

The GO-Joe product has been designed to be easy to configure and use, yet is somewhat complex in operation. Some of the more common problems encountered are described here.

Device Driver Permissions

The GlobalHost loadable module device driver in /devices/pseudo/goglobal@0:goglobal0 must be world readable and world writable. Early versions of the GO-Joe package would not always preserve these permissions. This problem has been corrected, but this remains a possible failure point for the session initialization. This problem can be diagnosed by checking the /tmp/Xerr:n file for permission denied messages related to the /dev/fbs/goglobal0 device.

The /etc/inetd.conf Entry

The inetd.conf entry has proved to be one of the more trouble-prone parts of the GO-Joe installation. This should be corrected with the use of the shim script in /usr/openwin/server/etc/shim. Diagnose this problem by double-checking the /etc/inetd.conf entry: verify that an entry does exist, and that the path to the shim script is valid with no misspellings. Check also that the shim script contains the correct path to the go-login program.

HTML References

If the GO-Joe applet fails to load entirely, suspect the HTML file you are loading and verify that the APPLET tag is correctly formed. Check the codebase path and the path and file name to the applet file itself. Finally, investigate the log files for your HTTP server (usually called access_log and error_log) to see if the applet is being successfully transmitted to the Java environment. It may sometimes also help to exit your browser or Java environment and restart it to clear any cached files that may be interfering with the applet's execution.

Java Security Manager Exceptions

All Java environments implement a security manager that determines what operations may be dangerous for an applet to perform, and can allow or disallow these actions as it sees fit. The biggest restriction that most security managers implement with respect to GO-Joe, is that an applet is allowed to connect only to the host which served that applet. This means that, for example, if you have such a security manager, your GO-Joe applet will only be able to connect to go-login running on the server that the applet was loaded from. In addition, the diagfile functionality of GO-Joe is similarly restricted.

The exact exception that this generates is dependent on the Java environment in question, but it may appear similar to this message (from a Netscape browser):

security.AppletSecurityExceptionsecurity: Couldn't connect to 'x_host' with origin 'web_server_host'.

If your browser supports it (such as some versions of HotJava), you may be able to relax the behavior of the security manager to allow these connections.