Zoom Search Engine FAQ - Troubleshooting CGI
Q. I have uploaded
my files but get an error "no search query entered", or
"error reading ..." or "Forbidden you don't have
permission ..."
- Check that you have uploaded all files required (listed at the
end of indexing).
- Check that you have uploaded these files in binary mode
with your FTP client (NOT ascii or text mode)
- Check that you have public read permissions on all files uploaded
(all the .zdat files, as well as the search_template.html)
- Check that you have specified execute permission ("chmod
755" via FTP) on the CGI file (search.cgi)
- Check that you have uploaded your search files to a location
on the server that has permission to run CGI files. Many hosting
companies only allow CGI programs to run from within the "cgi-bin"
directory on the server.
Q. I get a "404 Page not found"
message when running the CGI.
First, check the above list of common
CGI issues.
Make sure you have the correct file path for accessing the CGI
you uploaded. Check if you have any virtual or redirected paths,
or server side folder aliases set up. This may be misleading as
to where the actual contents of the folder is located in FTP.
If you are using an IIS 6.0 server, check the FAQ further below
regarding configuring IIS for CGI. IIS 6.0
returns a "404" error when CGI is not properly configured.
If your web server is running Slackware, check that it is
running at least Slackware 7.0 or later. Earlier versions of Slackware
has a required library as a installation option rather than as a
core part of the system. If you are using a more recent version
of Slackware and you still can not get it to work, then contact
us via the email address on the Support
page.
Q. I get a "500 Internal
Server Error" message when running the CGI.
First, check the above list of common
CGI issues.
Next, check that you have selected the correct build for your server's
operating system. There is a Target OS selection window after you
click on "CGI" in the Indexer. Note that you must re-index
your site and re-upload the files after changing this option before
it will take effect.
If this does not solve your problem, then check the following questions
regarding "Premature end of script"
error and "Unrecognized character"
error.
Q. I get a "Premature end
of script headers" error
Q. I get an error similar to "Unrecognized
character \x90 ... "
Q. I get a "The specified CGI application misbehaved by not returning a complete set of HTTP headers" error
For IIS users
Your web server may be configured to handle all CGI files as Perl
scripts. The Zoom CGI search application however is NOT a Perl script,
but a binary executable, so it will fail to run in this web server
configuration.
You can work-around this issue by renaming the "search.cgi"
file to be "search.exe". Also consult our support page dedicated to setting up CGI for Windows
IIS.
If the above does not help, your problem may be due to a bug in IIS 5.0 and IIS 6.0 related to running on a fast multi-processor computer. For more information and a hotfix from Microsoft, see this knowledge base article on Microsoft's website.
For Apache users
There are a number of different situations which may result in
this error message, and they are all related to the way your Apache
server is configured.
First, your Apache server may be using suEXEC,
which is a feature that handles the execution of CGI and scripts
and allows them to run under your own user ID (with a number of
security restrictions). If this is the case, you should first check the user account/group that has ownership
of the CGI file. See if this matches the suEXEC configuration for what it can execute. Second,
make sure that the "search.cgi" file does not have write permissions
enabled for anyone besides yourself. ie: make sure you do NOT have
"search.cgi" set to a "chmod 777" setting. Likewise
with the "cgi-bin" folder, or any of the .zdat files.
You should only need to specify "chmod 755" for "search.cgi"
(and the "cgi-bin" folder), and "chmod 644"
for the .zdat files.
Even the log folder must not have public write permission. The
log folder should only be permitted for owner write (eg: "chmod
744"). This will be enough for the logging to work under the
suEXEC security model, because all CGIs will be running under your
own user ID.
If the above does not solve your problem, then you should
check if your server is configured to handle all CGI files as Perl
scripts. The Zoom CGI search application is NOT a Perl script, but
a binary executable, so it will fail to run in this web server configuration.
You will need to change your server configuration via the "httpd.conf"
file. If your "cgi-bin" folder do not contain any other
Perl scripts, then you can change the settings to use "cgi-script" or "cgi-handler",
instead of "perl-handler". However, if your "cgi-bin"
folder does contain Perl scripts, then it may be best to
create a separate directory for non-Perl CGI, and add it to your
"httpd.conf" file. Specify handlers for it the same way
as your existing cgi-bin directory, but use "cgi-script"
instead of "perl-handler".
Another possibility for this error message is if the Apache RLimitCPU
and RLimitMEM
directives are set too low and the CGI is being killed off by the
server, whilst in the middle of execution.
If you can not make the server configuration changes above, you
should contact your web host regarding the execution of binary CGI
files.
If your web host will not allow you to run binary CGI files,
you can use one of the scripted alternatives such as PHP
and ASP. Both of these are functionally
identical except for being slower on very large sites (while CGI
offers a more enterprise solution). You can see a comparison of
their performance on our benchmarks
page. If you are unsure what PHP, ASP or CGI are, you can also
find more information here.
Q. The search stats report tool is failing
to load my CGI log file
Note that Apache does not allow text files to be served via HTTP
from the cgi-bin directory (it treats all files as scripts). As
a quick test, try to open the file from the HTTP address via your
web browser - and see if it returns an error. If so, this would
be why Zoom was unable to retrieve the file.
What you should do is either:
- Download the file via FTP, and open the local copy of the file
from the search stats reports window.
- Change your search log path to somewhere outside of the cgi-bin
directory. eg. instead of "./logs/searchwords.log",
something like "../logs/searchwords.log", so that it
will be accessible from a URL like "http://www.mysite.com/logs/searchwords.log"
and NOT "http://www.mysite.com/cgi-bin/logs/searchwords.log"
Note the need for the appropriate folder permissions if you intend
to store your log files in a different directory.
Q. Search.cgi returns "bad ELF interpreter: No such file or directory" error
While trying to debug search.cgi by running the Linux version from the Linux command line. You might get this error
bash: ./search.cgi: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
This can occur if you are running the 32bit search.cgi on a 64bit version of Linux without the 32bit Linux libraries installed.
Installing the 32bit libraries can resolve this error. For example on Ubuntu run this command.
sudo apt-get install ia32-libs
On Centos run this command.
yum install glibc.i686
Different command may be required depending on your Linux distribution.
|
