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.