Remote Greenstone

Remote Greenstone involves using a version of GLI locally to edit collections on a remote Greenstone server, thus allowing users to collaborate on collections (at different times), and without a local Greenstone installation.

Client GLI vs applet - now deprecated.

Setting up Remote Greenstone Functionality



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 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 possible group settings are:

  • all-collections-editor: Users in this group can create new collections and edit all collections.
  • 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.

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.

Collection locking

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.

E-mail notifications

The server can be configured to e-mail the system administrator whenever a collection finishes building. To enable this, edit the file (in cgi-bin for Greenstone2; in web/WEB-INF/cgi for Greenstone 3) and set "$mail_enabled" to "1", and "$mail_to_address", "$mail_from_address", and "$mail_smtp_server" appropriately.

Missing functionality

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.


The commands that takes are:

CommandOther ArgumentsOnly GSx?Output
cmd=check-installation blah… Installation OK!
cmd=greenstone-server-version Greenstone server version is: 3
cmd=get-library-url-suffix Greenstone library URL suffix is: /greenstone3
cmd=get-site-names 3 gateway—–localsite—–
cmd=user-validationun=username&pw=password 3 administrator,all-collections-editor: the list of groups associated with that user. OR "Authentication failed: error message"