WebSite
Troubleshooting Tips

WebSite Resources
June 12, 1996


The WebSite troubleshooting tips page is divided into two main sections: a section of specific problems and solutions, and a section of guidelines for diagnosing and solving problems on your own.

The problems and solutions have been collected from O'Reilly Technical Support and reflect questions users have had with previous versions of WebSite.

The guidelines section describes the troubleshooting tools that come with WebSite (such as the various logs and tracing options), and suggests typical places to look for the causes of problems.

This page also includes information regarding other resources for getting help with WebSite.

Many of the problems you may encounter while installing and starting your server are networking related. The specific problems can be myriad, from a mistyped IP address to a wrongly configured TCP/IP setup. These problems are beyond the scope of this book and should be addressed to your network administrator or your Internet service provider. If you suspect the problem is with your TCP/IP configuration, see the documentation for your operating and network systems.

Problems and Solutions

The following specific problems and questions have been encountered by WebSite users. The answers are from O'Reilly's Technical Support staff.

Problem
My server starts and immediately exits. What now?

Solution
Look in the file server.log, normally in the logs subdirectory under WebSite, to see any internal errors logged by the server. The messages there can provide a clue. You must have TCP/IP installed and active on your system. If you are using a dial-up connection only, it must be dialed-in and active before the server will start.

Problem
I don't yet have an internet host name for my computer, but I want to test it on the same computer as the server. What do I use for a URL?

Solution
The URL http://localhost/ will contact your local server and return your home page.

Problem
I let WebSite Setup install my server as an application. How can I change it to run as a service?

Solution
Open the server's property sheet and select one of the service options as the run mode. Stop the server. If you are on NT, you must start it using the NT services control panel. You cannot hand-start WebSite if it is set to run as an NT service. On Windows 95, you can re-start the server using the Start menu now; the next time you reboot your system, WebSite will start immediately and run without anyone logged in.

Problem
I'm on an intranet with no Internet names. What do I use for my host name in the Identities section of Server Admin?

Solution
Use the IP address (for example, 143.95.101.75). Do not use the NetBIOS or Windows Network computer name. Windows domains and names are not the same as internet/TCP-IP domains and names. If you use an IP address, people can use it in their URLs to get to your server, for example, http://143.95.101.75/.

Problem
No one else can see my server. Where do I look?

Solution
First, check to see that your server is running. Then try to access it locally using the above URL. If both of these work then the server is OK and the problem is networking related. Go to another computer on your network and ping your server computer. If you don't know what ping is, consult the Windows NT or Windows 95 TCP/IP networking documentation or contact your local network administrator.

Problem
The file server.log is huge! What can I do?

Solution
Check the Logging tab in the WebSite property sheet and disable all tracing options. Tracing is useful for diagnosing problems with CGI programs and the server itself. Normally you should run the server with all tracing disabled. Once you have disabled tracing, stop the server, delete the server.log file and restart the server.

Problem
My Netscape users have problems loading inline images. Sometimes they get broken icons. Is WebSite buggy?

Solution
Of course not! If you have "hold connections open for re-use" enabled in Server Admin (General Page), try turning it off. As of April, 1996, some browsers have quirks in their support of keep-alive, which cause this behavior if the option is enabled.

Problem
Users get broken images if they don't put a trailing slash on some URLs. What's wrong?

Solution
Check the Identity tab on the WebSite property sheet and see that the host name is correct. You would have caught this if you had run through the self-test and demonstration after you installed WebSite.

Problem
When using the NT command scheduler (AT or WinAT), logcycle.exe doesn't cycle the server logs.

Solution
Logcycle.exe is a desktop application. To successfully schedule log cycling, it must be able to communicate with AT and WebSite.

To ensure proper communication, set up the following services:

  1. Scheduler service (must be running for AT to work): allow service to interact with desktop (control panel, services, scheduler, startup button)

  2. WebSite as a service: allow service to interact with desktop (control panel, services, webserver, startup button)

  3. WebSite as a desktop application: no special requirements

  4. AT: command line needs to have the argument /interactive

  5. WinAT (GUI AT interface from resource kit): interact with desktop checked

    Note that any time you run WinAT and edit an entry, verify that /interactive is turned on. A bug in WinAT causes /interactive to be turned off when entries are edited.

Problem
When running WebSite as a service (under NT), the icon doesn't show.

Solution
To run as a service, WebSite must be run under a system account. Do not run WebSite as a service under a nonprivileged user account. Windows NT 3.51 security will not give an unprivileged process access to the desktop. The simplest solution is to run WebSite under the system account as it was installed.

Problem
How can I add more than five IP addresses to a Windows NT system? The Advanced Networking option of the Control Panel limits me to five IP addresses.

Solution
Having more than five IP addresses per Network Interface Card (NIC) is not supported by Microsoft. However, it is possible to add more IP addresses through the Registry.

Mistakes with the Registry Editor (regedit) can be fatal to your system!

To add more IP addresses, follow these steps:

  1. With the Registry editor, look under HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services and locate the entry, or entries, for your Ethernet card. If you have more than one entry, you must determine which is the primary one. For example, a 3Com Etherlink III card probably has two keys, Elnk3 and Elnk31. Open each key and look in the Linkage sub-key to see which one points to the other. For the 3Com card, the Linkage sub-key Elnk3 points to Elnk31 as the primary key.

  2. Open the primary key for your Ethernet card and locate the Tcpip key under the Parameters key. The hierarchical path should look something like this:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Elnk31\
    Parameters\Tcpip
    

  3. Under the Tcpip key, locate the named value IPAddress. This value is of type REG_MULTI_SZ (multi-string). Each of the component strings represents one of the IP addresses on which the NIC will answer. If you have entered five IP addresses using the Control Panel, those five IP addresses are listed.

  4. Double-click the IPAddress value, and the multi-string editor dialog appears showing all the IP addresses you have already assigned.

  5. Add additional IP addresses by appending them to the list, each one on a separate line. We recommend that you have no more than 16 IP addresses total. If you add too many, TCP will not start.

    Don't forget to add an appropriate subnet mask for each entry.

  6. Reboot the system. If TCP doesn't start, remove some of the addresses and try again.

    You are now ready to set up multiple virtual servers (one for each IP address), using the Identity wizard on the Identity page of Server Admin.

Problem
I have a server that uses only CGI programs (no static documents), and I would like to allow users to self-register. How can I get the username and password information from the authentication dialog?

Solution
First rename your CGI program so the name starts with a $. This naming convention causes the server to pass the username and password through the CGI interface. The CGI-BAS that ships with WebSite (V1.7) includes the CGI_AuthPass and CGI_AuthUser variables.

To get the browser to display the username and password dialog (if the request doesn't contain a username), have your CGI program respond something like this:

Send "HTTP/1.0 401 Not Authorized" 
Send "WWW-Authenticate: Basic Realm=""My Cool App""")
Send ("")

This response causes the browser to display the username/password dialog. The user fills it in, presses OK, and the browser repeats the previous request with the username and password included. Your CGI application will get both username and password if you start its name with a $ in the variables CGI_AuthUser and CGI_AuthPass.

Note that this example is for CGI programs written in Visual Basic. If you aren't using Visual Basic, the process is still the same, except you need to know the key names for username and password that are used in the INI file. For more information on this, see the Windows CGI Specification.

If you are using the Standard or DOS CGI interfaces, the environment variable names are AUTH_USER and AUTH_PASSWORD.

Problem
My CGI execution is slow and my disk seems to be beaten to death.

Solution
Nothing will improve this situation better than adding more RAM. On Windows NT, 16MB is not enough to run NT, WebSite, and do database CGI. In fact, the RAM requirements for WebSite are 32 MB minimum for Windows NT and 16 MB minimum for Windows 95.

Note that those figures are the minimums. If you have a heavy load and run complex CGI programs, or if you are running a mix of database CGI and local work on the same system, you should consider 64MB or 128MB. WebSite users universally attest to dramatically improved performance when they increase their RAM.

Problem
When I set up virtual servers, all my CGI programs stop working.

Solution
Make sure your CGI directories are properly mapped for each new server. Each virtual server must have a URL prefix. Add that prefix to the mapping for each CGI. For example:

/prefix/cgi-win/      C:\path\to\Win CGI directory

If you use the Identity wizard to set up your virtual servers, the document and CGI mapping is done automatically for you. See the Identity page in Server Admin and the instructions in Chapter 10, Virtual Servers and WebSite.

Problem
I have WebSite running under Windows 95 and I want to administer it remotely. Why am I having problems?

Solution
First, you cannot remotely administer the WebSite server running under Windows 95 from a computer running Windows NT. Administering the server from another Windows 95 system requires the following conditions:

Problem
I'm having problems with a CGI program that I wrote. Any tips for debugging it?

Solution
See the white paper on Debugging CGI Programs in the Tech Center at WebSite Central.

Problem
My CGI programs work okay except that images in the resulting documents are broken.

Solution
CGI programs create virtual documents, which have no location in file space. Thus, any relative URLs (for images or links) don't work because relative URLs are relative to the current document (see the next question for more on mapping). Note the following examples:

<img src="foo.gif">

This reference is bad because the URL path is completely relative. The server will not be able to locate this document.

<img src="/foo.gif">

This reference is better because the leading slash makes the URL path absolute to the document root of the server.

<img src="http://domain/foo.gif">

This is the best reference because the URL is complete, and it leaves no ambiguity for the image's location.

Problem
Some of my links work fine and others don't. I suspect my problem may be mapping. Can you give me some pointers?

Solution
First, read Chapter 9, Mapping, carefully and work through the examples. Apply the principles covered in that chapter to your own situation.

In a nutshell, here are some general principles on relative URLs that generally cause the most problems in creating document links in your HTML files:

Q: Relative URLs are relative to what?
A: To the current document.

Q: What is the current document?
A: The URL displayed by the browser when a document is loaded.

Q: Why is a URL with a leading slash different?
A: A leading slash denotes the current server's document root. Thus, the URL /index.html equals http://current_server/index.html

Q: Are there any URL forms that I should avoid?
A: Yes, avoid URLs beginning in ../. These URLs can easily cause grief.

Problem
When I install WebSite under Windows 95 or try to run the server self-test under Windows 95, it fails.

Solution
You may have insufficient DOS environment space. Try adding the line CommandEnvSize=8192 to the [NonWindowsApp] section of system.ini.

Troubleshooting Guidelines

The following guidelines will help you diagnose and solve problems you may encounter while using WebSite. Please work through these before calling technical support.

WebSite Central

WebSite Central, the web site maintained for WebSite users by the technical support staff at O'Reilly & Associates, provides product information, answers to frequently asked questions (FAQs), troubleshooting help, advice for particular implementations of WebSite, ideas for new uses of WebSite, sample HTML files, helpful utility programs, and opportunities to interact with other WebSite users.

You can tap the resources at WebSite Central with your browser, and find out how others have dealt with similar problems. In addition, the Frequently Asked Questions (FAQs) and Infrequently Asked Questions (IAQs) published on WebSite Central, may provide just the answer you need. You will also find pointers to other resources on the Web, such as specifi- cations, helpful application tools, and resources for products bundled with WebSite.

Contacting Technical Support

If you've thoroughly tried all the other resources to solve your problem and you still need assistance, O'Reilly & Associates provides technical support for WebSite as listed below:


Copyright © 1994-96 O'Reilly & Associates, Inc. All Rights Reserved. O'Reilly Software Online, WebSite Central, WebSite, and WebSite Professional are trademarks of O'Reilly & Associates, Inc.

All other names are the trademarks of their respective companies.