Frequently Asked Questions/Trouble Shooting Guide


Symptom:

Problem:nfrwatch is unable to start httpd and is retrying about once ever second.

Possible Solutions:In this particular case nfrwatch is unable to start httpd because the correct path to httpd on this machine was not specified before running nfrwatch in install/etc/nfr.conf. You may see this behavior when nfrwatch is unable to start httpd or any other daemon for this or some other reason.


Symptom:

Problem: Your browser seems to be having some problems executing Java applets.

Possible Solutions: Unset the $CLASSPATH environment variable. Some JVM's (like Kaffe) need to set $CLASSPATH to the directory where their libraries are stored for it to function properly. So you may have left $CLASSPATH set after using a JVM and then started Netscape. Netscape will use the information in the $CLASSPATH environment variable to locate its java libraries, finding the libraies of the last used JVM instead.

Another possible solution: Certain versions of Netscape just don't execute Java code on certain X displays. We haven't been able to reliably nail down the circumstances. If you are using Netscape, you might try a different display or a different version of Netscape.


Symptoms:

Problem: You can not execute any of the NFR cgi support programs.

Possible Solution: Copy the file install/etc/httpd/cgi-bin/.htaccess to install/etc/httpd/htdocs/. You must now restart your browser for the NFR client to function properly.

Things are not working properly because for some reason you never correctly provided a login/password to the server. In the beta distributions there are two .htaccess files to be concerned with, install/etc/httpd/cgi-bin/.htaccess and install/etc/httpd/htdocs/.htaccess. The black NFR page is located in install/etc/httpd/htdocs. So it it proctected by the .htaccess file in that directory. Often someone who will remove the .htaccess file in htdocs, either because they do not know the login/password or they don't want to type it in every time they load the main NFR page. Usually they will remove only the one in htdocs and not the one in cgi-bin. So when you load the main NFR page you are not prompted for the login/password, so you never get a chance to provide it, so your browser never gets its authentication token from the server, so when you go to access something in cgi-bin (which is still protected) your browser does not have permission to get to any of those files. The programs are used to do a great many things, the two most obvious however are update the status bars and make a list of the installed packages.


Symptoms:

Problem: The NFR client applet is not communicating with the web server. If you are looking at the applet at all the browser was at one time communicating with the web server. Perhaps the web server has crashed, or there is some other type of network connectivity problem.

Possible Solutions: Check to see if the web server is up and running. If it is not, restart it. You will need to restart your browser and reload the NFR client applet.


Symptom:

Problem: The nfrd engine may not be running or not responding.

Solution: Check to make sure that the nfrd engine is up and running. If it is not running restart it. You can query the engine directly by typing 'telnet localhost `cat etc/sock_id`' from the install directory of the server machine. A healthy engine responds like this when you type 'stats intf':

stats intf
intf: ef0: ps_recv 1212
intf: ef0: ps_drop 0
intf: ef0: ps_ifDrop 0
intf: ef0: packets 621
intf: ef0: bytes 63987
intf: Arriv [10/08/97 00:16:54] secTotal 157.956 secTotal/cnt 0.254358 stdDev 0.60665
intf: totalPackets 621
1 done stats [11/21/97 16:16:48]
If the engine is not running you will not be able to connect to this port:

beta@nfr.net [~/nfr/install]$ telnet localhost `cat etc/sock_id`
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
beta@nfr.net [~/nfr/install]$

Symptom:

Problem: You are most likely looking at the wrong network interface.

Possible Solution: When the NFR engine, nfrd, starts up it reads a configuration file named install/etc/nfrd.cfg. You must specify the name of the network interface you want NFR to listen on by setting the value of the nfr_intf variable.

The value associated with name 'nfr_intf' is a space separated list of interface names. We distribute this file with four very common interface names listed. You can simply add yours to the list and restart NFR to get things working.

If you are not sure what your network interface name is, run 'ifconfig -a' and look for the network interface that has both 'UP' and 'RUNNING' in its atribute list. Usually it is the first one listed in the ifconfig output. Add the name of your interface to the list in nfrd.cfg. You'll need to restart NFR to have these changes take effect.

Possible Solution: You may also have this problem if you are running BSDI and have not properly installed the bpf patch in the BSDI kernel. If this is the case then information is not making it from the network interface to the nfrd engine. Go re-read the instructions for how to re-compile a BSDI kernel and ensure that you have performed each step correctly.

You may have installed the kernel correctly but are simply booting another kernel. To find out which kernel you are booting run 'dmesg | head' the first line or two describes which kernel is running. Make sure that the running kenel is the one that you patched.


Symptom:

Problem: Netscape idiosyncrasy. If Netscpae is pointed at a page other than the main NFR page the query's no longer function properly. You must keep the browser pointed at the black NFR page while using the NFR applet for everything to work correctly.

Solution: Point your browser at the main NFR page.


Symptom:

Problem: This can be caused by a bug in certain versions of Netscape. Open the java console. If you see the message "Finished Executing showDocument" it means the query has been successfully processed. If no window appeared, you have found the Netscape bug.

Solution: Quit and restart Netscape.


Symptom:

Problem: This behavior has been observed on some BSDI 3.0 systems that don't have the most recent patches installed.

Solution: Install these patches . . .


        K300-001
        M300-002
        M300-010 
        M300-013
        M300-015
        M300-016
        M300-021
        M300-022
        M300-023
        M300-027