Hasta ahora, usar el GLI requería una instalación completa de Greenstone, o bien, que estuviera instalado el applet en el servidor. En ambos casos, la “colaboración” sobre las colecciones no era posible.

Esta nueva funcionalidad mantiene las colecciones en un servidor de Greenstone remoto permitiendo a los usuarios colaborar en la construcción de las colecciones (en diferentes tiempos) y sin una instalación local de Greenstone.

Esta sección describe como instalar la funcionalidad de construcción remota en el server y en el cliente.

El servidor puede ser Linux, Mac OS X o Windows. Debe tener instalado el runtime de JAVA (versión 1.4 o superior).

Para instalar el componente del lado del servidor:

• Descargar la última versión de Greenstone e instalarla. Elegir la opción “Biblioteca Web” al momento de hacer la instalación.
• Configurar el webserver para usarlo con Greenstone:
  • Apache v2.0 - Después de la instalación, configurar el Apache editando el archivo httpd.conf según se describe en la Guia de Instalación de Greenstone. Iniciar Apache.
  • Apache v1.3 - Apache v1.3 no es válido para esta aplicación; usar Apache v2.0.
  • IIS (No recomendado) - Ver esta página. Luego hacer click con el botón derecho sobre la carpeta "cgi-bin", elegir Propiedades, y seleccionar Configuracion. Agregar una extensión para ".pl", indicando como ejecutable el Perl de Greenstone “bin/windows/perl/bin/perl", con argumentos "%s" %s.
  • IIS 6: Editar el archivo de Greenstone "cgi-bin/gliserver.pl" y setear la opción "iis6_mode" con valor "1". Chequear que tanto Greenstone como el webserver estén funcionando correctamente con la siguiente url:

http://<mi_servidor>:<port>/gsdl/cgi-bin/library

(library.exe en Windows). El puerto por defecto será el "80", a menos que se haya cambiado en la configuración del web server.

• Editar la primera linea del archivo de Greenstone "cgi-bin/gliserver.pl" y especificar el path completo a los binarios de Perl. En Unix es algo similar a:

  #!/usr/bin/perl -w

  En Windows será (si se instaló en la ubicación por defecto)

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

• En el navegador escribir:

  <nowiki>http://<mi_servidor>:<port>/gsdl/cgi-bin/gliserver.pl?cmd=check-installation</nowiki>

  Debería recibir un mensaje diciendo "Java found" e "Installation OK!".

• Si por el contrario se obtiene un mensaje diciendo "Java failed", chequear que el entorno de ejecución de Java está instalado y está presente en el path del servidor web.
• Si se obtiene un "500 Internal Server Error", chequear que Perl está siendo ubicado correctamente por GLI. Abrir una ventana de Comando, moverse a la carpeta Program Files\Greenstone\cgi-bin, y escribir "gliserver.pl". Un mensaje del estilo "perl: bad interpreter: No such file or directory" indica que el servidor GLI no está encontrando al intérprete Perl. Ir al Paso 3 de arriba y chequear que esté bien. De otro modo, si está en Linux, puede ser que no tenga permisos de ejecución sobre el archivo gliserver.pl. Abra una ventana de consola y muevase a la carpeta cgi-bin de la instalación de Greenstone. Una vez ahí, escriba:

  ./gliserver.pl

  Si esto retorma un mensaje como "bash: ./gliserver.pl: Permission denied", entonces ejecute lo siguiente:

  chmod<br/>a+rxgliserver.pl

  Ahora vuelva a probar.<br/>Si aun no funciona, controle el archivo de log de errores del webserver.<br/> Importante: no seguir adelante con estas instrucciones hasta que todo lo anterior haya sido configurado exitosamente. De lo contrario, nada funcionará.

• Hacer que el usuario del webserver tenga permisos de escritura sobre la carpeta “collect". En Unix, usar chmod. En Windows, ejecutar lo siguiente en una ventana de DOS:

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

• Editar el archivo de Greenstone "etc/main.cfg" y cambiar el status de la página de Administración a enabled:<br/><tt># Set status to "enabled" if you want the Maintenance and<br/># Administration facility to be available.<br/>status enabled</tt><br/>Esto hará que el botón "Página de Administración" aparezca en la home de Greenstone.
• Agregar algunas cuentas de usuario desde la opción “Agregar nuevo usuario” de la página de administración de Greenstone. Ver la sección “Autenticación” más adelante para mayor información.
• Chequear que el servidor tenga el archivo GLIServer.jar en la carpeta bin/java dentro de la carpeta de instalación de Greenstone. Si este archivo jar no está presente en esa carpeta, entonces hay que copiar el que está en la carpeta “gli”. Si la carpeta Gli tampoco tiene el archivo .jar, entonces hay que abrir una ventana de consola, ir a la carpeta gli y ejecutar lo siguiente:

  ./makejar.sh

Esto creará el archivo GLIServer.jar en dicha carpeta, por lo cual habrá que copiarlo a la carpeta bin/java.

Si el usuario va a utilizar el cliente GLI stand-alone, entonces esto es todo lo que se requiere en el servidor, pudiendo saltear la siguiente sección.

Si por el contrario se va a utilizar el applet de GLI, entonces es necesario hacer los siguientes 4 pasos. Para ello es necesario el kit de desarrollo de Java (Java SDK)- si aun no está instalado puede descargarse desde aquí. Asegurarse de que la carpeta que contenga el SDK esté incluida en la variable PATH del sistema, ya que esto no se hace automáticamente con la instalación.

• En la carpeta Gli de Greenstone, ejecutar

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

  Ingresar los detalles apropiados de la organización. Cuando pide ingresar la clave, escribir una clave propia o presionar Enter para que tome “greenstone” como clave.

• Ejecutar

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

Cuando lo pregunte, ingresar la clave elegida en el punto anterior.

• Mover el archivo SignedGatherer.jar a la carpeta "bin/java" de Greenstone.
• Editar el archivo de Greenstone "etc/main.cfg" y configurar el campo "gliapplet" como "enabled".

Los clientes pueden ser Linux, Mac OS X o Windows.

• Descargar la última versión del cliente GLI (5MB) y descomprimirlo.
• Ejecutar "client-gli.bat" (Windows) o "client-gli.sh" (Linux/Mac OS X). La primera vez que se corra el cliente GLI en una máquina, preguntará por las URLs del servidor de Greenstone y del servidor de GLI, las cuales son:

  http://<mi_servidor>:<port>/gsdl/cgi-bin/library

  (library.exe si el server es Windows) y

  http://<mi_servidor>:<port>/gsdl/cgi-bin/gliserver.pl

  respectivamente.

• Ir a la home de Greenstone y cliquear el botón “Interfaz de la Biblioteca Digital". Comenzarà a cargarse el applet de GLI, y luego de una breve pausa quedará habilitado el botón "Cargar Interfaz de la Biblioteca". Cliquearlo para comenzar a usar el applet.

De esta manera puede usarse elGLI para editar colecciones en el servidor, o bien, crear nuevas. La primera vez que se abre una colección en una máquina en particular, GLI leerá desde el server la información referida a los conectores y clasificadores (esto puede tomar un par de minutos).

Puede haber una gran catnidad de datos transferidos entre el cliente y el servidor. Esto puede hacer que la utilización del cliente sea impracticable si no se dispone de una conexión de alta velocidad entre ambos.

Para la autenticación se utiliza el sistema de cuentas de usuario de Greenstone. La información de los usuarios es almacenada en el archivo etc/users.db, y las páginas de Administración (llamadas desde la home de Greenstone) se usan para agregar, editar o borrar usuarios.

Los Grupos se usan para controlar las acciones que los usuarios están habilitados a ejecutar sobre las colecciones. Las opciones de los grupos han cambiado desde la versión 2.71 de Greenstone, por lo que si se está haciendo una actualización de versión es necesario editar la configuración de los grupos existentes. Las configuraciones posibles son las siguientes:

• all-collections-editor: los usuarios de este grupo pueden crear nuevas colecciones y editar todas las existentes. (Equivalente al grupo "remote-superuser" de la versión v2.70w y anteriores).
• personal-collections-editor: los usuarios de este grupo pueden crear y editar “colecciones personales”. Las colecciones personales tienen el nombre del usuario al comienzo del nombre interno de la colección y son creadas cuando la opción “Esta es una colección personal” es seleccionada en la ventana de diálogo “Nueva Colección” del GLI.
• <nombre_colección>-collection-editor: Los usuarios de este grupo pueden crear y editar solamente la colección <nombre_colección>. (Equivalente al grupo "<nombre_colección>-maintainer" de la versión v2.70w y anteriores).

Por ejemplo, un usuario que necesita crear y editar sus propias colecciones y colaboirar con otros en una colección de documentos compartidos (llamada edocs), debería estar en el grupo "personal-collections-editor" y también en el grupo "edocs-collection-editor".

Cada colección puede ser abierta por una persona a la vez, para prevenir problemas de sincronización. Cuando se envia una petición al servidor para ejecutar una acción sobre la colección, el servidor chequeará la existencia del archivo gli.lck en la carpeta de la colección. Este archivo contiene el nombre de usuario de la persona que tiene bloqueada la colección. Cuando la colección se cierra, este archivo de bloqueo se borra.

Si la colección esta siendo bloqueada por una persona distinta a quien está haciendo la petición, entonces la acción falla. Esto es reportado al usuario y éste tiene la opción de “apropiarse” del bloqueo. Generalmente esto no es recomendado, ya que pueden perderse datos si hay múltiples usuarios editando la colección a la vez. Apropiarse del bloqueo solo debe hacerse en el caso de que GLI se haya cerrado de forma anormal y por lo tanto el archivo gli.lck no haya sido borrado.

El servidor puede configurarse para que le envíe un mail al administrador del sistema cada vez que finaliza el proceso de construcción de una colección. Para habilitar esta opción hay que editar el archivo "cgi-bin/gliserver.pl" y setear "$mail_enabled" en "1", y "$mail_to_address", "$mail_from_address", y "$mail_smtp_server" apropiadamente.

Existen algunas pocas funciones que solo están disponibles en la version GLI stand-alone. Estas funciones son:

• El panel de Descargas
• La opción del menu Archivo → Grabar imagen CD/DVD
• La opción de menú Archivo → Exportar
• La opción de renombrar cuando se selecciona un archivo o carpeta con el botos derecho del mouse.
• La opción Reemplazar cuando se selecciona un archivo o carpeta en el arbol de la colección.

Estas funciones pueden agregarse en futuras versiones.

Si experimenta problemas o mensajes de error cuando utiliza la version cliente/servidor del GLI, entonces siga los siguientes pasos.

• Asegurese de estar usando la ultima versión de Greenstone.
• Registre cualquier ventana de error de GLI y la última accción ejecutada.
• Chequee excepciones de Java. Si está usando l aversión cliente de GLI, estas excepciones aparecerán en la ventana de consola del GLI o en la terminal donde se haya ejecutado, si es un Unix. Si se esta usando el applet, los mensajes apareceran en la consola de Java (disponible desde los menues del navegador. Para Firefox, hay que descargar esta extension).
• Chequear los errores que puedan existir en los logs del webserver. Si se está usando Apache (recomendado), mirar en el archivo "error_log" que está en la carpetas "logs" del directorio de instalación.
• Si se tienen problemas con la versión applet, verificar si existen los mismos errores con la version cliente de GLI.

Si cree haber encontrado un bug, o aún no ha podido hacer funcionar esta opción, envíe un mail a la lista de usuarios de Greenstone. Por favor, incluya la siguiente información:

• El sistema operativo del servidor
• La versión de Greenstone instalada en el servidor
• La version de Java instalada en el servidor
• El sistema operativo de la máquina cliente
• Si se está usando o no el applet de GLI
• Las acciones ejecutadas que llevan a la ocurrencia del error
• El texto completo de cualquier mensaje de error de GLI

• Errores de tipo "Premature EOF" cuando se construyen las colecciones son causados por un time out del webserver, cuando los scripts de construcción no generan ningún output durante un tiempo largo. La solución es incrementar el seteo de timeout del webserver, que para el caso del Apache, significa incrementar el valor de la variable "Timeout" en el archivo conf/httpd.conf (no olvidarse reiniciar el Apache).