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 read the following FAQ for
more help with setting up the 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 must 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-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-handler"
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. I need help setting up binary CGI support
for my Windows IIS server
Your IIS server may not be configured for executing binary CGIs.
Note that this is not the same as having Perl support. You will
need to contact your web host or have direct access to the server
to change this by following the instructions below.
First, you will need to access the IIS window on the web server
(Control Panel -> Administrative Tools -> Internet Information
Services). Next, locate the folder for your website, and select
the folder where you will be running the CGI file. You can possibly
create a new folder here (eg. "cgi-bin") or select an
existing folder where you will be uploading your search files to
(eg. "search"). Right click on the folder, and select
"Properties". Now look for "Execute Permissions"
and change the setting to "Scripts and Executables".
If the "Configuration" button is enabled, you can click
on it to check if the ".cgi" extension is mapped to an
application. If not, then it should be fine for the CGI file to
run. However, some servers may have the ".cgi" extension
mapped to ActivePerl. This means that your binary CGI would not
execute properly when executed, because it gets treated as a Perl
script. In this case, you can work-around the problem by renaming
the "search.cgi" file to "search.exe".
Note: If you are running IIS 6.0 on Windows Server 2003, you
may need to configure some extra options to enable CGI (due to additional
security requirements enforced in this OS). Namely, you will need
to allow the Web
Service Extension for CGI in the IIS Manager window.
This can be done from the IIS Manager window, by locating "Web
Service Extensions", and changing the "All Unknown CGI
Extensions" status to "Allow". However, this would
allow any CGI applications to run on the server. If you wish to
specifically allow ONLY the "search.cgi" application from
Zoom to run, you should create a new Web Service Extension. Do this
by right-clicking in the web service extensions list, and selecting
"Add a New web service extension". Enter a name (eg. "Zoom
Search Engine CGI"), and click on "Add". You will
have to specify the path to the "search.cgi" file here,
and click "OK". Once you have done this, change the status
for the new extension to "Allow". For more information,
refer to the above link and the Microsoft documentation for Configuring
CGI Applications (IIS 6.0).
Your IIS server should now be configured to run the binary CGI
search function. Index and upload your files to the folder (which
you have set the permissions to following the instructions above),
and load up the search page (search.cgi or search.exe) in your browser.
Update for GPO's: As if all this wasn't complex enough, in some rarer cases we have heard of IIS servers setup with GPO's (group policies) which alter the permissions of the "NETWORK SERVICE" account (by default, this is the account used by the web application). So because the permissions to this account are altered, it doesn't have enough permissions to run the cgi script, and you end up with a 403 - access denied error (403.19, error code 1314 to be exact). So your web application in IIS (website) uses an application pool, and that application pool runs under a specified user (default is NETWORK SERVICE). If this user doesn't have the proper permissions, it wont be able to run the cgi script. The rights it needs to have is "Adjust memory quotas for a process (SeIncreaseQuota)" and "Replace a process at token level (SeAssignPrimaryToken)". Here is a Microsoft KB article which provides several solutions. http://support.microsoft.com/kb/904056
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.
|
