Symptom:
Section: [httpd] Start Command: [/usr/httpd -d /usr/home/eric/e/nfrbase/nfr/install//etc/httpd] Execute as: [NFR USER] Nice Value: [0] Respawn: [Yes] PIDfile: [/usr/home/eric/e/nfrbase/nfr/install//etc/httpd/apache.pid] Termination: [kill -15 pid]
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:
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:
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:
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:
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:
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:
Solution: Point your browser at the main NFR page.
Symptom:
Solution: Quit and restart Netscape.
Symptom:
Solution: Install these patches . . .
K300-001 M300-002 M300-010 M300-013 M300-015 M300-016 M300-021 M300-022 M300-023 M300-027