Questions in this section are of an "emergency" nature. They represent the most common and frantic support inquiries we receive.

I can't login to my account!

Please make sure you are doing the following:

1. Using a Telnet or FTP client. Common applications on the Macintosh are NCSA Telnet and Fetch; on a PC, most TCP/IP stacks (such as Trumpet) include some sort of basic Telnet and FTP clients. If you have a Unix shell account, the commands telnet and ftp should be immediately available to you (if not, you may have a restricted shell; ask your local administrator).
2. Using the one-word account name when prompted. Do not use your Virtual Domain. Do not attach "@lstar.net" to the account name. Use only your simple, two to eight letter, account name.
3. Typing your password correctly. Case is significant for almost everything in Unix (a notable exception is domain name resolution), including passwords. Also, make sure you aren't using a "1" (numeral one) in place of a "l" (lowercase L), or interchanging a zero and a capital O.
4. If all else fails, contact us.

   Your files need to be uploaded to the htdocs subdirectory, under your home directory. This means that after logging in via FTP, you need to issue the command cd htdocs before uploading files.

   If your name has been freshly registered, it may take a couple of days for its information to become visible at the root nameservers and in the caches of systems around the world. If the problem persists, or you are unable to receive e-mail at your domain (the most common bounce error is "mail loops back to myself"), please let us know as soon as possible.

Unfortunately, imagemap handling doesn't provide very good error response. For a walkthrough and some hints about possible causes of the problem, please visit the How-To Guide for Imagemaps.

The most common cause of this is a CGI script that doesn't actually execute successfully. If your CGI script won't run at all, the Web server just throws up its hands and gives out this generic, unhelpful error.

The most common causes of this problem are:

• Uploading a text CGI script (ie, a Perl script) in binary mode from a PC or Macintosh. These systems use a different linefeed convention from Unix, and you must set your FTP client to ASCII or text mode when uploading them. If you do not, the script simply will not work.
• Failing to set the executable bits on the script. This is done with the command chmod 755 filename via Telnet or the more complex quote site chmod 755 filename via FTP (your client may have its own interface for this).
• Using the wrong URL to reach your script. The URL should resemble http://www.domain.com/cgi-bin/filename.
• Run-time or interpreter errors.

For further details on debugging your CGI scripts, please visit our How-To Guide on the subject.

This is the result of trying to use a POST method form to submit data to a CGI script that does not exist (or in some cases, cannot be executed due to permissions). The server's error is completely misleading. Your form probably contains something like:

<FORM METHOD="POST" ACTION="http://www.yourcompany.com/cgi_bin/results.cgi">

In this case, note the typo: cgi_bin instead of cgi-bin.

There are two ways to make sure a CGI script is executed as CGI rather than sent to the browser as text:

• Use an extension of .cgi or .pl (which indicates a Perl script). These extensions are always executed as CGI by the Web server. This is the best way to protect your scripts.
• Place the CGI program in a special cgi-bin directory for your Virtual Domain, and mark it as executable with the chmod command. Programs in these directories must be executable in order to run, and they are never returned as text.

If you're trying to provide a script for people to download, you cannot use the .cgi or .pl extension for the file. Rename the file to, for example, filename.pl.txt for downloading purposes, or better yet, create a tar archive for your users to download; such archives can include README files and other useful support material.

Certain aspects of system setup vary from provider to provider. Here are a few things that may be different:

• Our Web server is Apache, a descendant of NCSA. Other providers may be using CERN, NCSA itself, Netscape, or others. The most obvious differences are usually in .htaccess (the access control and configuration file) and how imagemaps are handled.
• We run Linux. Other providers may be using Sun's Solaris, SGI's Irix, Microsoft's Windows NT, or many others. Although most commands and system features are essentially the same between Unix variants, many things are radically different in, for example, Windows NT.
• Other things... who knows? Please let us know of any other differences you encounter.

Return to Frequently Asked Questions