I installed Greenstone 2.84 using the Greenstone-2.84-linux executable. Everything seems to be setup correctly, however when attempting to go to the homepage (library.cgi), I am prompted with an internal server error. This is odd, because other CGI scripts in that same directory appear to be working somewhat correctly. Note that this is running on Fedora 64 bit. Here is a copy of my virtual host's file:
ServerAlias lis558_greenstone lis558_greenstone.scilsnet lis558_greenstone.scilsnet.rutgers.edu
DirectoryIndex index.html index.htm index.php
Alias /htdocs/ "/www/lis558_greenstone.scilsnet.rutgers.edu/htdocs"
Options FollowSymLinks +Indexes
# Deny from all
# <FilesMatch "\.(gif|jpe?g|png|css|mov|mpeg|ps|pdf|doc|rtf|jar|class)$">
# Order allow,deny
Allow from all
ScriptAlias /cgi-bin/ "/www/lis558_greenstone.scilsnet.rutgers.edu/htdocs/cgi-bin/"
AddHandler cgi-script .cgi .pl
CustomLog /www/lis558_greenstone.scilsnet.rutgers.edu/logs/access_log combined
Redirect /index.html http://lis558_greenstone.scilsnet.rutgers.edu/cgi-bin/library.cgi
Here is what I see in the apache error log from that virtual host ( for library.cgi):
(2)No such file or directory: exec of'/www/lis558_greenstone.scilsnet.rutgers.edu/htdocs/cgi-bin/library.cgi' failed
Premature end of script headers: library.cgi
Here what happens in the error_log when I run other scripts in that same directory:
File does not exist: /www/lis558_greenstone.scilsnet.rutgers.edu/htdocs/usabbnr.gif, referer: http:// lis558_greenstone.scilsnet.rutgers.edu/cgi-bin/savereport.cgi
After some research, I was told to debug the script with Perl directly, this is what happens:
# perl -w /www/lis558_greenstone.scilsnet.rutgers.edu/htdocs/cgi-bin/library.cgi
Unrecognized character \x7F in column 1 at /www/lis558_greenstone.scilsnet.rutgers.edu/htdocs/cgi-bin/library.cgi line 1.
So it appeared that something was wrong with the Perl, perhaps a missing hashbang. But the very first line of my gliserver.pl file contains:
Also, here is my gsdlsite.cfg, which seems to be configured correctly. I've tried specifying the "perlpath" with no success, along with the "gwcgi" directive:
# this file should be placed in the same directory as your library
# executable file. it defines parameters that are particular to a
# given site, and therefore should be edited to suit your site.
# points to the GSDLHOME directory
# This must be set, and must point to the top level Greenstone directory
# (usually gsdl or Greenstone)
# this is the http address of GSDLHOME
# if your webserver's DocumentRoot is set to $GSDLHOME
# then httpprefix can be commented out
# this is the http address of the Greenstone web directory (which contains
# images, style etc)
# if your web directory is a top level folder inside $GSDLHOME, then this
# can remain commented out, and will default to httpprefix/web
# this should contain the http address of the library.cgi script. This
# is not needed if the http server sets the environment variable
# Generally this is not needed with Apache
# maxrequests is the most requests a fastcgi process
# will serve before it exits. This can be set to a
# low figure (like 1) while debugging and then set
# to a high figure (like 10000) when everything is
# working well.
# Only applies if you are using fastcgi
# Remote Greenstone Options (for server side)
# If Perl is not already on your PATH, set the following to the
# full path of the perl bin directory (Perl's parent folder)
# and it will be prepended to the PATH.
# Options for FLI
# If using Greenstone's GLIServer to run the Fedora Librarian
# Interface (FLI), then you need to set fedora version and fedora home
# variables, either below, or as environment variables.
# FEDORA_VERSION is the major version number of Fedora and
# FEDORA_HOME is the full path to your Fedora installation.
# Setting fedorahome and fedoraversion here will over-ride the
# FEDORA_HOME and FEDORA_VERSION environment variables.
# If using Greenstone's GLIServer to run the Fedora Librarian
# Interface (FLI), then you need to set the full path to Java either as below
# or as the JAVA_HOME environment variable.
# Setting javahome here will over-ride the JAVA_HOME environment variable.
# Options for Open Office (used in converting Office documents)
# If using Open Office on Windows, then you can optionally customise the
# following properties (defaults are as shown). E.g. if Open Office is not
# located in C:\Program Files\OpenOffice.org 3\program, then you'll want
# to provide its new path by specifying soffice_home.
#soffice_home "C:\Program Files\OpenOffice.org 3\program"
# Leave an empty line at the end
Thanks in advance. I'm pretty stumped at this point..
i'm surprised that after one year nobody replied this.
Short answer: binaries of greenstone don't work on 64bit linux, you will need to recompile if you are forced to use that machine.
in my case, last week we changed the machine we used for greenstone and following the current trends I installed a 64bit SO (Ubuntu Server) on that new server hoping for better performance than the old machine (it had 32 bit Ubuntu Desktop). at the moment of starting the server I ran into the same messages you got HTTP 500 and "Premature end of script headers".
Searching deeper I discovered that just executing library.cgi returned NOTHING, not even a blank line. It was a very strange behavior, because a CGI script must return some HTTP Headers even if no arguments are passed into. As a side note, the file library.cgi is a binary ELF executable, not a Perl script (the one who told you to run `perl library.cgi` needs a smash).
Then, thinking about the things I made different in this new installation of greenstone got the conclusion that the only thing diff was the SO, after installing a 32bit SO (Ubuntu Server again) and executing from shell `library.cgi` it gave a lot of debug info and then appeared a prompt asking for the query string. Entering via browser gave me expected results, the default greenstone home page.
Some days later, almost by a casuality, saw in a forum page (sorry, don't remember which) that binary version of greenstone is built against 32bit libraries of a XML perl module that is incompatible with 64bit SO. If you really need to use a 64bit SO for installing greenstone you will need to recompile linking this time with a 64bit version of those XML processing Perl modules.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.