For Greenstone to work properly, access permissions for certain files must be set up appropriately. Also, there is a configuration file associated with each Greenstone site. The install procedure creates a generic configuration file based on your installation choices; however its contents can be tailored to cope with different situations. This section explains both of these issues.

This section is irrelevant for Windows 95/98, because these systems don't identify the owners of files.

On Windows NT, 2000 and Unix systems, cgi scripts don't run as normal users, because users can't be identified over the Web. Instead, they run as the user who started up the webserver program (on Windows systems), or as a special user (commonly called nobody on Unix systems). Because of this, all files and directories within C:\Program Files\gsdl need to be globally readable (or at least readable by the cgi-script user, perhaps “nobody”). To test whether file permissions are set up correctly, run the program library.exe from the command line. If the files are in the right places but the permissions are set incorrectly, it will run from the command line—that is, when you execute it—but not from a browser—that is, when the “nobody” user executes it. Another test is to log in as another user to see if the file permissions are specific to your original user account.

To work through a Web browser, all the Greenstone directories must be globally readable. Also, the C:\Program Files\gsdl\etc directory and all its contents must be globally writable. This is the directory into which the library program writes the usage log, error and initialization logs, and various user databases. If you're reluctant to make this directory globally writable, you can set permissions so that just the files errout.txt, initout.txt, key.db, users.db, history.db and usage.txt are writable by the cgi user.

If file permissions are not set up correctly for C:\Program Files\gsdl\etc, you may find that user authentication and search history do not work, and that no usage log (usage.txt) is generated.

The install procedure creates a generic Greenstone site configuration file based on your installation choices. For our installation this file is C:\Program Files\gsdl\cgi-bin\gsdlsite.cfg and its content is:

# Site configuration file for Greenstone.
# Lines begining with
# are comments.
# This file should be placed in the same directory as your library
# executable file. it should be edited to suit your site.
# points to the GSDLHOME directory
gsdlhome “C:/Program Files/gsdl ”
# this is the http address of GSDLHOME
# if your webservers DocumentRoot is set to $GSDLHOME
# then httpprefix can be commented out
httpprefix /gsdl
# this is the http address of the directory which
# contains the images for the interface.
httpimg /gsdl/images
# should contain the http address of this cgi script. This
# is not needed if the http server sets the environment variable
# SCRIPT_NAME
#gwcgi         /cgi-bin/library
# 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.
#maxrequests 10000

You can customise your installation by editing this file, although you will probably not need to do so.

The gsdlhome line simply points to the C:\Program Files\gsdl directory.

httpprefix is the web address of the directory that Greenstone is installed in. We explained earlier how to create an alias so that URLs of the form http://localhost/gsdl/ … are sought in the C:\Program Files\gsdl directory. Putting a line httpprefix/gsdl into the gsdlsite configuration file establishes the same convention for the Greenstone software.

httpimg is the web address of the C:\Program Files\gsdl\images directory, which contains all the gif images used in the interface. In any standard Greenstone installation this will always be httpprefix/images, and the line in the file above is left untouched.

gwcgi is the web address of the library cgi program. This is not required by most webservers (including Apache), and should remain commented out. Don't uncomment it unless you're sure you need to, because that may introduce problems.

maxrequests is only used by versions of Greenstone that are compiled with the “fast-cgi” option on. The standard binary distribution does not include this option because not all webservers are configured to support it. Fastcgi speeds up cgi executions by keeping the main executable in memory between invocations of the software, rather than loading it in from disk each time a web page is requested from the Greenstone software. The trade-off is the amount of memory used, which can grow the longer the program remains in memory. Once maxrequests pages have been generated, the cgi program quits, thereby freeing any accumulated memory. To respond to the next request for a Web page, the cgi program is read in from disk again, and a new cycle of page requests is begun. Most installations use the standard cgi protocol, which means that maxrequests can be safely ignored.