Remote Greenstone 2

This document is also available in Spanish.

Until now, using the GLI has required either a complete Greenstone installation, or the GLI applet to be installed on a server machine. In both cases, collaboration on collections is not possible.

This new functionality keeps the collections on a remote Greenstone server, thus allowing users to collaborate on collections (at different times), and without a local Greenstone installation.

This section describes how to install the remote building functionality on server and client.

The server can be a Linux, Mac OS X or Windows machine. It must have the Java run-time installed (version 1.5 or newer). Note that a binary install of Greenstone includes Java.

To install the server-side functionality:

• Download the latest version of Greenstone and install it. In Greenstone versions 2.81 and before, choose the "Web Library" installation option.
• On Windows, edit your PATH environment variable to include imagemagick and ghostscript: Add the …\bin\windows\imagemagick and …\bin\windows\ghostscript folders to the PATH, making sure they are in the front, ahead of the windows system folder (eg C:\WinNT\System32) otherwise there will be problems finding the imagemagck convert.exe program.

• Configure your webserver for use with Greenstone:
  • Apache v2.0
    • Later Greenstone releases come with Apache. Or you can (download it)
    • If installing Apache manually, configure Apache by editing the conf\httpd.conf file as described in the Greenstone Installer's Guide.
    • Start Apache.
  • Apache v1.3
    • Apache v1.3 is not suitable for this application; use Apache v2.0 instead.
  • IIS (Not recommended)
    • See this page. Then right-click on the "cgi-bin" folder, choose Properties, and click Configuration. Add an extension for ".pl", specifying the Greenstone "bin/windows/perl/bin/perl" binary as the executable, with arguments "%s" %s.
  • IIS 6: Edit the Greenstone "cgi-bin/gliserver.pl" file and set the "iis6_mode" option to "1".

On Windows: before running the apache web server, rename the Greenstone local library server file server.exe (located in your toplevel Greenstone directory) to something else.

Check that your webserver and Greenstone are working correctly by visiting

http://<your-machine-name>:<port>/greenstone/cgi-bin/library.cgi

(For Greenstone 2.81 and older:

• use http://<your-machine-name>:<port>/gsdl/cgi-bin/library.cgi
• and if on Linux, try just "library" instead of "library.cgi" at the end. If you're on Windows, try "library.exe" instead at the end).

The port will be the number you configured your Apache web server to listen on. This tends to be 8080 or 80, unless these are already in use.

• Make sure you have edited the gsdlsite.cfg file to contain the appropriate values, such as for GSDLHOME. See step 3.2 on this page.

Note: In Greenstone 2.83 and onwards, you should be able to skip this step if you are using a release of Greenstone from an installer, as the installer automatically does the replacement.

Edit the first line of the Greenstone "cgi-bin/gliserver.pl" file and specify the full path of the perl binary.

On Unix it is likely to be:

    #!/usr/bin/perl -w

On Windows this would be something like (if installed in the default location):

    #!C:\Program Files\Greenstone\bin\windows\perl\bin\perl -w

Note that when using Greenstone 2.82 on Windows, it has the path to perl slightly wrong, so do correct it: …\bin\windows\perl\bin\perl

• Visit http://<your-machine-name>:<port>/greenstone/cgi-bin/gliserver.pl?cmd=check-installation

in a web browser. (In Greenstone 2.81 and earlier, visit http://<your-machine-name>:<port>/gsdl/cgi-bin/gliserver.pl?cmd=check-installation.) You should get a message saying "Java found" and "Installation OK!".

• If you get a message saying "Java failed", check that the Java run-time environment is installed and on the webserver's path.
• If you get "500 Internal Server Error", check that Perl is being located correctly by the GLI server program. Open a command window, go to your cgi-bin directory (perhaps Program Files\Greenstone\cgi-bin), and type "gliserver.pl". A message like "perl: bad interpreter: No such file or directory" indicates that the GLI server is not finding the Perl interpreter. Go to step 3 above and investigate.

Otherwise, if you're on Linux, it may have to do with not having executable permissions on gliserver.pl. Open an x-term and cd into your greenstone installation folder's cgi-bin folder. There, type:

./gliserver.pl

If it returns a message like "bash: ./gliserver.pl: Permission denied", then type the following to make it executable:

chmod a+rx gliserver.pl

Now see if it works.

• Otherwise, check the error log of your webserver for the cause (look for a file called "apache\logs\error_log" and check the last few lines).

Important: Do not continue with these instructions until this is successful, because otherwise nothing will work!

• If your web server is running as a different user, make sure the collect directory has the right permissions. In such a case, make the Greenstone "collect" directory writeable by the webserver user.

On Unix, use chmod.

On Windows, if using the included Apache web server, it will run under your User Account and the following tends not to be necessary. Otherwise, you would run the following in a DOS prompt:

    cacls "C:\Program Files\Greenstone\collect" /P Everyone:F

If you're working in a language other than English (say German or French), the word "Everyone" in the command above could well be in the language your machine is set to. For instance "Tout le monde" in French (use quotes since it is more than one word).

• In Greenstone versions earlier than 2.82, you will need to edit the Greenstone "etc/main.cfg" file by changing status for the Administration page to enabled:

# Set status to "enabled" if you want the Maintenance and
# Administration facility to be available.
status  	enabled

This will make the "Administration Page" button appear on the Greenstone home page.

• Add some user accounts by visiting the Greenstone home page and clicking the "Administration Page" button, then "add a new user". See the Authentication section below for more information.
• Check that your Greenstone server side installation contains the GLIServer.jar file in your greenstone installation folder's bin/java. If this jar file is not present in that folder, then copy your greenstone folder's gli/GLIServer.jar over into that bin/java/. If the gli folder doesn't contain it either, then open a Linux X-term, go into the gli folder and run

./makejar.sh

On Windows, you'd type the following in the DOS prompt:

makejar.bat

This will create the GLIServer.jar file in the gli folder which you can manually copy into the bin/java folder.

If your end users will use the stand-alone GLI client, this is all that is required on the server, and you can skip the next section.

If your end users will be using the GLI applet, you also need to do the following four steps. These require the Java SDK – if you don't already have this you can download it from here; make sure that the Java SDK's bin directory is included in the PATH environment variable, which may not have been done automatically upon installation.

• In the Greenstone "gli" directory, run

    keytool -genkey -alias privateKey -keystore appletstore -storepass greenstone

Enter the appropriate details for your organization. When it asks to enter the key password for <privateKey>, choose your own password or hit Enter to use "greenstone".

• Run

    jarsigner -keystore appletstore -signedjar SignedGatherer.jar GLI.jar privateKey

When it prompts, enter the password you used above.

• Move the created SignedGatherer.jar file into the Greenstone "bin/java" directory for GS2. For GS3, move SignedGatherer.jar into web/applet.
• For GS2, edit the Greenstone "etc/main.cfg" file and set the "gliapplet" field to "enabled". For GS3, open web/interfaces/default/transform/pages/home.xsl for editing and uncomment the line <gslib:libraryInterfaceLink/><br/> by removing the surrounding HTML comment symbols, < ! - - and - - >.

The clients can be Linux, Mac OS X or Windows machines.

To use the stand-alone GLI client:

• Download the latest version of the GLI client (5MB) and unzip it.
• Run "client-gli.bat" (Windows) or "client-gli.sh" (Linux/Mac OS X).

The first time you run the GLI client on a machine it will ask for the Greenstone library and gliserver URLs. The first will be

http://<your-machine-name>:<port>/gsdl/cgi-bin/library.cgi

Alternatively, if you are using an older version of Greenstone (2.81 and earlier), this URL will end on "library.exe" if the server is Windows and "library" on Linux. The gliserver URL it requires will be

http://<your-machine-name>:<port>/gsdl/cgi-bin/gliserver.pl

To use the GLI applet:

• Follow the steps at the end of Server first.
• Visit your Greenstone library homepage and click the "The Librarian Interface" button there. The GLI applet will begin loading, and after a short wait a "Launch Greenstone Librarian Interface" button will become available. Click this to start using the GLI applet.

You can now use the GLI to edit collections on the server or create new collections. The first time a collection is opened on a particular machine the GLI will read the plugin and classifier information from the server (this may take a minute or two).

There can be a lot of data transferred between the client and the server. This can make using the client impractical if you don't have a high speed connection between it and the server.

The existing Greenstone user account system is used for authentication. User information is stored in the etc/users.db file, and the Administration pages (linked from your Greenstone library homepage) are used for adding, editing and removing users.

Groups are used to control the actions that users are allowed to perform on collections. The group settings have changed for Greenstone v2.71, and you will need to edit your existing users if you are upgrading. The possible group settings are:

• all-collections-editor: Users in this group can create new collections and edit all collections. (Equivalent to the "remote-superuser" group of Greenstone v2.70w and earlier).
• personal-collections-editor: Users in this group can create and edit "personal" collections. Personal collections have the user's username at the start of the internal collection name, and are created when the "this is a personal collection" option is ticked in the GLI "New Collection" dialog.
• <collection-name>-collection-editor: Users in this group can create and edit the "<collection-name>" collection. (Equivalent to the "<collection-name>-maintainer" group of Greenstone v2.70w and earlier).

For example, a user who needs to create and edit their own collections, and collaborate with others on a shared "papers" collection, should be in the "personal-collections-editor", and "papers-collection-editor" groups.

Each collection may only be open by one person at a time, to prevent synchronization problems. When a request is sent to the server to perform an action on a collection, the server will check for a gli.lck file in the collection directory. This file contains the username of the person who has the collection locked. When the collection is closed, this lock file is deleted.

If the collection is locked by someone other than the person making the request, the action fails. This is reported to the user on the client side, and this user is given the option of "stealing" the lock. Generally this is not recommended, since work may be lost if multiple users are editing a collection at one time. Stealing the lock should only be done in the case where the GLI has exited abnormally and the lock file was not deleted, and only after consulting with the user who has the collection locked.

The server can be configured to e-mail the system administrator whenever a collection finishes building. To enable this, edit the Greenstone "cgi-bin/gliserver.pl" file and set "$mail_enabled" to "1", and "$mail_to_address", "$mail_from_address", and "$mail_smtp_server" appropriately.

There are a few items of functionality that are available in the standalone GLI but not in the client/applet version. These are:

• The Download pane
• The File &amp;rarr; Write CD/DVD Image… menu item
• The File &amp;rarr; Export… menu item
• The Rename option when right-clicking on a file or folder in the collection tree <i>(will be available in Greenstone 2.73)</i>
• The Replace option when right-clicking on a file or folder in the collection tree

This functionality may be added in the future.

If you are experiencing problems or error messages when using the client/server version of the GLI, please follow these steps:

• Make sure you are using the latest version of Greenstone and have downloaded any patches on this page.
• Record any popup GLI error messages, and the last action you performed.
• Check for Java exceptions. If you're using the client version of the GLI, these will appear in the black GLI window (Windows) or in the terminal where you ran the GLI (Unix). If you're using the applet version of the GLI, these will appear in the Java Console (available from one of your browser menus – for Firefox you may have to download this extension).
• Check for errors at the bottom of the log files of your webserver. If you're using Apache (recommended), look in the "error_log" file in the Apache "logs" directory.
• If you are having problems with the applet version, please check if you have the same problems with the client version.

If you think you have found a bug, or still can't get this functionality working, send a message to the Greenstone Users mailing list. Please include the following information:

• The operating system of the server machine
• The version of Greenstone installed on the server machine
• The version of Java installed on the server machine
• The operating system of the client machine
• Whether you are using the client or applet version of the GLI
• The actions you performed leading up to where the error or problem occurs
• The complete text of any popup GLI error messages, exceptions or errors in the webserver log file

• Errors such as "An error has occurred on the remote Greenstone server while performing this operation: Collection archives zip file /home/Greenstone/collect/admin-test1-archives-1358677588928.zip could not be created." may be due to the tmp directory not being writable. Make sure the folder Greenstone/tmp is world writable.
• "Premature EOF" errors when building collections are caused by the webserver timing out when no output is generated by the build scripts for some time. The solution is to increase the webserver's timeout setting. For Apache this means increasing the "Timeout" value in the conf/httpd.conf file (don't forget to restart Apache).
• "Stack Overflow Errors" Building large collections might result in a stack overflow error. Try increasing the stack size for GLI: For linux/Mac, in gli.sh, look for lines starting with

$"javapath" -Xmx128M -classpath classes/:GLI.jar

Add -Xss16M after the -Xmx128M, which increases the stack size from 2 to 16M. On Windows, in gli.bat, look for the lines starting

"%JAVA_EXECUTABLE%" -Xmx128M -cp classes/;GLI.jar

and do the same thing.

• When trying to load the dictionary (in Dictionary.java: ResourceBundle.getBundle(…)), the applet looks in the wrong place initially, causing errors in the Apache error_log. Finding some way of telling Java to look in the JAR file immediately would be nice.
• Pressing the "Cancel Build" button during the importing or building process doesn't have an immediate effect. The GLI code needs to be changed so GShell (and at a further level, RemoteGreenstoneServer) is a listener on the Cancel button. This will mean the cancel event can be processed much quicker.
• When the GLI is quit with jobs still on the remote Greenstone server queue, it will wait until these are finished before exiting. A dialog telling the user what is happening would be nice. This should probably have a "force quit" button, even if this is not recommended.
• Loading the options for DBPlug.pm causes an exception when using a Windows server. If you need to use DBPlug then you must install the DBI and DBD modules that it requires.