Instalación de DSpace

Vista general de instalación

A partir de la versión 7 (y posterior), la aplicación DSpace se divide en un "frontend" (Interfaz de usuario) y un "backend" (Server API). La mayoría de las instituciones querrán instalar BOTH. Sin embargo, puede decidir si ejecutarlos en la misma máquina o máquinas separadas.

• El DSpace Frontend consiste en una interfaz de usuario construida en Angular.io. Es una aplicación web Node.js, es decir, una vez que está construida/compilada, sólo requiere Node.js para ejecutar. No se puede ejecutar "standalone", ya que requiere un DSpace Backend válido para funcionar. El frontend ofrece toda la funcionalidad orientada al usuario.
• El DSpace Backend consiste en una API de servidor ("server" webapp), construida en Spring Boot. Es una aplicación web Java. Se puede ejecutar independiente, sin embargo no tiene interfaz de usuario. El backend proporciona todas las interfaces basadas en la máquina, incluyendo la REST API, OAI-PMH, SWORD (v1 y v2) y RDF.

Recomendamos instalar el Backend primero, ya que el Frontend requiere un Backend válido para funcionar correctamente.

Instalación del Backend (API de Server)

Requisitos de backend

Backend Installation

1. Instale todos los Requisitos de Backend mencionados anteriormente.

2. Crear un usuario del sistema operativo DSpace (opcional) . Como se señala en los requisitos previos anteriores, Tomcat (o Jetty, etc.) debe funcionar como una cuenta de usuario del sistema operativo que tiene acceso completo de lectura/escribo al directorio de instalación de DSpace (es decir. [dspace]). O debe asegurarse de que el dueño de Tomcat también posee [dspace], O puede crear una nueva cuenta de usuario "dspace", y asegurarse de que Tomcat también se ejecuta como esa cuenta:

   ?

   useradd -m dspace

   La elección que tenga más sentido para usted probablemente dependerá de cómo instaló su contenedor de servicio (Tomcat/Jetty/etc). Si lo instaló desde la fuente, tendrá que crear una cuenta de usuario para ejecutarla, y esa cuenta se puede nombrar cualquier cosa, por ejemplo 'dspace'. Si utilizó el gestor de paquetes de su sistema operativo para instalar el contenedor, entonces una cuenta de usuario debería haber sido creada como parte de ese proceso y será mucho más fácil utilizar esa cuenta que tratar de cambiarla.

3. Descargue el último lanzamiento de DSpace del DSpace GitHub Repository. Puede optar por descargar el archivo zip o tar.gz proporcionado por GitHub, o puede utilizar "git" para comprobar la etiqueta adecuada (por ejemplo. dspace-8.0) o rama.
4. Desempaquetar el software DSpace. Después de descargar el software, basado en el formato de archivo de compresión, elija uno de los siguientes métodos para desempaquetar su software:
   

   1. Archivo postal. Si descargado dspace-8.0.zip haga lo siguiente:

      ?

      unzip dspace-8.0.zip

   2. .gz file. Si descartó dspace-8.0.tar.gz hacer lo siguiente:

      ?

      gunzip -c dspace-8.0.tar.gz | tar -xf -

      Para facilitar la referencia, nos referiremos a la ubicación de esta versión sin cremallera de la versión DSpace como [fuente espacio] en el resto de estas instrucciones. Después de desempaquetar el archivo, el usuario puede desear cambiar la propiedad de la carpeta dspace-8.x al usuario "dspace". (Y es posible que necesite cambiar el grupo).

5. Configuración de base de datos para PostgreSQL:
   

   • Crear un dspaceUbiador de la base de datos (este usuario puede tener cualquier nombre, pero asumiremos que lo nombra "espacio"). Esto está completamente separado de la dspaceUsuario del sistema operativo creado anteriormente:

     ?

     createuser --username=postgres --no-superuser --pwprompt dspace

     Se le pedirá (dos en dos) una contraseña para el nuevo dspaceusuario. A continuación, se le pedirá la contraseña del superusuario PostgreSQL (postgres).

   • Crear un dspacebase de datos, propiedad de la dspaceUsuario PostgreSQL. Similar al paso anterior, esto sólo se puede hacer por una cuenta de "superusuario" en PostgreSQL (por ejemplo. postgres):

     ?

     createdb --username=postgres --owner=dspace --encoding=UNICODE dspace

     Se le pedirá la contraseña del superusuario PostgreSQL (postgres).

   • Por último, DEBE habilitar la extensión pgcrypto en su nueva base de datos de dspace. Una vez más, esto sólo puede ser habilitado por una cuenta de "superusuario" (por ejemplo. postgres)

     ?

     # Login to the database as a superuser, and enable the pgcrypto extension on this database psql --username=postgres dspace -c "CREATE EXTENSION pgcrypto;"

     El comando "CREATE EXTENSION" debe regresar sin resultado si tiene éxito. Si falla o lanza un error, es probable que le falte la extensión pgcrypto requerida (ver Prequisitos de base de datos anteriores).

     • Método alternativo: Cómo habilitar pgcrypto a través de un esquema de base de datos separado. Si bien el método anterior de habilitar pgcrypto está perfectamente bien para la mayoría de los usuarios, puede haber algunos escenarios en los que un administrador de bases de datos preferiría instalar extensiones en un esquema de base de datos que está separado de las tablas de DSpace. Los desarrolladores también pueden desear instalar pgcrypto en un esquema separado si planean "liciar" (recrear) su base de datos de desarrollo con frecuencia. Mantener las extensiones en un esquema separado de las tablas de DSpace garantizará que los desarrolladores NO tendrían que volver a habilitar continuamente la extensión cada vez que ejecutes un "./dspace database clean". Si desea instalar pgcrypto en un esquema separado, aquí, cómo hacer eso:

       ?

       # Login to the database as a superuser psql --username=postgres dspace # Create a new schema in this database named "extensions" (or whatever you want to name it) CREATE SCHEMA extensions; # Enable this extension in this new schema CREATE EXTENSION pgcrypto SCHEMA extensions; # Grant rights to call functions in the extensions schema to your dspace user GRANT USAGE ON SCHEMA extensions TO dspace;     # Append "extensions" on the current session's "search_path" (if it doesn't already exist in search_path) # The "search_path" config is the list of schemas that Postgres will use SELECT set_config('search_path',current_setting('search_path') || ',extensions',false) WHERE current_setting('search_path') !~ '(^|,)extensions(,|$)'; # Verify the current session's "search_path" and make sure it's correct SHOW search_path; # Now, update the "dspace" Database to use the same "search_path" (for all future sessions) as we've set for this current session (i.e. via set_config() above) ALTER DATABASE dspace SET search_path FROM CURRENT;

6. Configuración inicial (local.cfg): Crea tu propio[dspace-source]/dspace/config/local.cfgArchivo de configuración. Quizás desee simplemente copiar el proporcionado[dspace-source]/dspace/config/local.cfg.EXAMPLE. Este archivo local.cfg se puede utilizar para almacenarcualquiercambios de configuración que desea hacer que son locales de su instalación (verlocal.cfg archivo de configuracióndocumentación). Cualquier configuración puede ser copiada en este archivo local.cfg desde el dspace.cfg o cualquier otro archivo *.cfg con el fin de anular la configuración predeterminada (ver nota más abajo). Para la instalación inicial de DSpace, hay algunos ajustes de clave que probablemente querrá anular.[dspace-source]/dspace/config/local.cfg.EXAMPLE. (NOTA: Configuraciones seguidas con un asterisco (*) son muy recomendables, mientras que todas las demás son opcionales durante la instalación inicial y pueden ser personalizadas en un momento posterior.)
   
   • dspace.dir*- debe ser configurado en el directorio [dspace] (instalación) (NOTA: En Windows asegúrese de usar barras delanteras para la ruta del directorio. Por ejemplo: "C:/dspace" es una ruta válida para Windows.)
   • dspace.server.url*- URL completa de este backend DSpace (incluyendo el puerto y cualquier suentro). No termines con '/'. Por ejemplo: http://localhost:8080/server
   • dspace.ui.url*- URL completa del frontend DSpace (incluyendo el puerto y cualquier suentro). REQUIERDO para la API REST a las solicitudes de confianza del frontend DSpace. No termines con '/'. Por ejemplo: http://localhost:4000
   • dspace.name- El nombre "adecuado" de tu servidor, por ejemplo. "Mi biblioteca digital".
   • solr.server* - URL completa del servidor Solr. DSpace hace uso de Solr para la indización. http://localhost:8983/solr a menos que haya cambiado el puerto o instale a Solr en algún otro host.
   • default.language - Lenguaje predeterminado para todos los valores de metadatos (predeterminación a "en-US")
   • db.url* - La URL completa de JDBC a su base de datos (ejemplos se proporcionan en el local.cfg.EXAMPLE)

   • db.driver* - Qué controlador de base de datos para usar para PostgreSQL (por defecto debe estar bien)

   • db.dialect* - Qué dialécto de base de datos para PostgreSQL (el incumplimiento debe estar bien)
   • db.username* - el nombre de usuario de la base de datos utilizado en el paso anterior.
   • db.password* - la contraseña utilizada en el paso anterior.
   • db.schema* - el esquema de base de datos para usar (ejemplos se proporcionan en el local.cfg.EXAMPLE)
   • mail.server- nombre de dominio totalmente calificado de su servidor de correo saliente.
   • mail.from.address- la dirección "Des": para poner en el correo electrónico enviado por DSpace.
   • feedback.recipient- buzón de correo para correo de retroalimentación.
   • mail.admin- buzón para administrador del sitio de DSpace.
   • alert.recipient- buzón para errores/alertas del servidor (no esencial pero muy útil)

   • registration.notify- buzón de correos electrónicos cuando los nuevos usuarios se registran (opcional)

     Su archivo local.cfg puede anular CUALQUIER configuración de otros archivos *.cfg en DSpace

     El local.cfg.EXAMPLEsolo incluye un pequeño subconjunto de las configuraciones disponibles con DSpace. Proporga un buen punto de partida para su propio local.cfgArchivo.

     Sin embargo, debe ser consciente de que cualquier configuración ahora se puede copiar en su local.cfgpara anular la configuración predeterminada. Esto incluye CUALQUIER de las configuraciones/configuraciones en:

     • El archivo dspace.cfg primario ([dspace]/config/dspace.cfg)
     • Cualquiera de los archivos de configuración del módulo ( [dspace]/config/modules/*.cfgficheros)
     • Cualquiera de los ajustes de la Bota de Primavera ([dspace-src]/dspace-server-webapp/src/main/resources/application.properties)

     Las configuraciones individuales también pueden ser comentadas o eliminadas en su local.cfg, con el fin de volver a habilitar la configuración predeterminada.

     Consulte la sección de Referencia de Configuración para más detalles.

7. DSpace Directory: Crear el directorio para la instalación de backend de DSpace (es decir, [dspace]). Como root (o un usuario con los permisos apropiados), ejecute:

   ?

   mkdir [dspace] chown dspace [dspace]

   (Asumiendo el nombre de usuario de dspace UNIX.)

8. Construye el paquete de instalación: Como usuario de dspace UNIX, generar el paquete de instalación DSpace.

   ?

   cd [dspace-source] mvn package

9. Instale DSpace Backend: Como usuario de dspace UNIX, instale DSpace en [dspace]:

   ?

   cd [dspace-source]/dspace/target/dspace-installer ant fresh_install

   Para ver una lista completa de objetivos de construcción, ejecute: ant helpLo más probable que vaya mal aquí es la prueba de la conexión de su base de datos. Vea la Common Installation IssuesSección de Temas de Instalación Común a continuación para más detalles.

10. Inicializa tu base de datos: Si bien este paso es opcional (como la base de datos DSpace debería auto-inicializarse en la primera startup), siempre es bueno verificar una última vez que tu conexión con base de datos está funcionando correctamente. Para inicializar la base de datos:

    ?

    [dspace]/bin/dspace database migrate

    1. Después de ejecutar este script, es una buena idea ejecutar "./dspace database info" para comprobar que su base de datos ha sido completamente inicializada. Una base de datos completamente inicializada debería incluir el estado de todas las migraciones como "éxito" o "Fuera del Orden". Si alguna migración ha fallado o todavía se enumeran como "Pending", entonces usted necesita comprobar su "dspace.log" para posibles mensajes "ERROR". Si aparecieran errores, tendrás que resolverlos antes de continuar.

11. Copiar núcleos de Solr: La instalación de DSpace crea un conjunto de seis núcleos Solr vacíos ya configurados.

    1. Copiarlos de [dspace]/sol a el lugar donde su instancia Solr los descubrirá. Por ejemplo:

       ?

       # [solr] is the location where Solr is installed. # NOTE: On Debian systems the configsets may be under /var/solr/data/configsets cp -R [dspace]/solr/* [solr]/server/solr/configsets   # Make sure everything is owned by the system user who owns Solr # Usually this is a 'solr' user account # See https://solr.apache.org/guide/8_1/taking-solr-to-production.html#create-the-solr-user chown -R solr:solr [solr]/server/solr/configsets

    2. Empieza (o reinicia) Solr. Por ejemplo:

       ?

       [solr]/bin/solr restart

        

    3. Puede comprobar el estado de Solr y sus nuevos núcleos de DSpace mediante el uso de su interfaz web administrativa. Exájate a ${solr.server}(e.g. http://localhost:8983/solr/)para ver si Solr está funcionando bien, entonces mira los núcleos seleccionando (a la izquierda) Core Admin o usando la lista de caída Core Selector.

       1. Por ejemplo, para probar que su núcleo de "búsqueda" se configura correctamente, intente acceder a la URL  ${solr.server}/search/select. Debería hacer una consulta vacía contra el núcleo de "búsqueda", devolviendo un resultado JSON vacío. Si devuelve un error, entonces eso significa que su núcleo de "búsqueda" está desaparecido o no se instala correctamente.
12. Implementar la aplicación web
    Tenemos diferentes posibilidades en este caso:
    • Implemente la aplicación WAR a Tomcat (instalación tradicional):El backend de DSpace consiste en una sola "servidora" webapp (en [dspace]/webapps/serverNecesitas implementar esta webapp en tu Contenedor Servlet (por ejemplo. Tomcat). Generalmente, hay dos opciones (o técnicas) que usted podría utilizar... ya sea configurar Tomcat para encontrar la web de "server" DSpace, o copiar la webapp "servidor" en la carpeta de aplicaciones web de Tomcat.

      • Técnica A. Dígale a su instalación de Tomcat/Jetty/Resin dónde encontrar su aplicación web DSpace (s). Como ejemplo, en el directorio [tomcat]/conf/Catalina/localhostpuede añadir archivos similares a los siguientes (pero reemplazar [dspace]con la ubicación de su instalación):

        DEFINE A CONTEXTO PATH FOR DSpace Server webapp: server.xml

        ?

        <?xml version='1.0'?> <Context     docBase="[dspace]/webapps/server"/>

        El nombre del archivo (sin incluir el sufijo ".xml") será el nombre del contexto, por ejemplo server.xmldefine el contexto en http://host:8080/server. Definir el contexto raíz (http://host:8080/), nombre el archivo de ese contexto ROOT.xml. Opcionalmente, también puede optar por instalar la vieja webapp "desesperada" "descansado" si usted

      • Técnica B.Simple y completo. Usted sólo copia (o todos) de las aplicaciones web de DSpace que desea utilizar desde el directorio [dspace]/webapps al directorio apropiado en su instalación Tomcat/Jetty/Resin. Por ejemplo:
        cp -R [dspace]/webapps/* [tomcat]/webapps(Esto copiará todas las aplicaciones web a Tomcat).
        cp -R [dspace]/webapps/server [tomcat]/webapps(Esto copiará sólo la aplicación web Server a Tomcat.)

        Definir el contexto raíz (http://host:8080/), nombre de la dirección de ese contexto ROOT.

    • Implemente aplicación Runnable JAR (NUEVA): El backend de DSpace ahora construye una aplicación Runnable JAR hecha con SpringBoot. Después de construir DSpace, un nuevo "server-boot.jar" estará disponible en [dspace]/webapps/server-boot.jar. Este archivo JAR contiene toda la aplicación web "server", Tomcat incrustado, y la configuración de "dspace.dir" realizada durante la fase de compilación. Puede ejecutar este JAR con el siguiente comando:

      Ejecución de botas de servidor

      ?

      java -jar [dspace]/webapps/server-boot.jar

      Al ejecutarlo, el servidor arrancará con la configuración que hayas hecho durante la fase de construcción. Hay parámetros opcionales que puede utilizar para anular los valores de compilación:

      • spring.config.location- referencia al archivo application.propperties a utilizar

        ?

        --spring.config.location=file:///path/to/target/application.properties

      • dspace.dir- referencia al directorio de instalación de la aplicación (valor por defecto en application.properties)

        ?

        --dspace.dir=/path/to/install/folder

      • logging.config- Archivo de configuración de registro del proyecto (valor por defecto en application.properties )

        ?

        --logging.config=file:///path/to/target/file/log2.xml

      • Estos son sólo los principales, obviamente, se puede anular cada propiedad que se puede encontrar dentro de los archivos de configuración simplemente al agregarlo como argumento del comando de ejecución, al igual que este: --[prop]=[value]. O puede optar por utilizar la anulación de la variación ambiental como se describe en la Referencia de Configuración

13. Crear una cuenta Administrador: Crear una cuenta de administrador inicial desde la línea de comandos:

    ?

    [dspace]/bin/dspace create-administrator

    
    

14. Inicio inicial.Ahora el momento de la verdad. Arranca (o reiniciar) Tomcat/Jetty/Resin.
    
    1. REST API Interface - (e.g.) http://dspace.myu.edu:8080/server/
    2. OAI-PMH Interface - (e.g.) http://dspace.myu.edu:8080/server/oai/request?verb=Identify
    3. Para un ejemplo de cómo se ve el backend predeterminado, visite el Demo Backend: https://demo.dspace.org/server/
15. Configuración de tareas programadas para procesos entre bastidores: Para que todas las características de DSpace funcionen correctamente, hay algunas tareas programadas que usted DEBE configurar para ejecutar de forma regular. Algunos ejemplos son tareas que ayudan a crear miniaturas (para imágenes), hacer indexación de texto completo (del contenido textual) y enviar correos electrónicos de suscripción. Consulte las tareas programadas vía Cron para más detalles.
16. Instalación de producción (añadía de soporte HTTPS):Ejecutar el DSpace Backend en HTTP & port 8080 es sólo utilizable para entornos de desarrollo local (donde está ejecutando la interfaz de usuario y la API REST de la misma máquina, y sólo accediendo a ellos a través de URLs locales).  Si quieres ejecutar DSpace en Producción, DEBES ejecutar el backend con soporte HTTPS(A lo contrario los inicios de sesión no funcionarán fuera de su dominio local).
    1. Para el soporte HTTPS, recomendamos instalar Apache HTTPD o Nginx, configurar SSL a ese nivel y hacer sus solicitudes a su instalación de Tomcat (o Runnable JAR). Tenga en cuenta que si desea alojar tanto el DSpace Backend como Frontend en el mismo servidor, puede utilizar una instalación de Apache HTTPD o NGinx para administrar HTTPS/SSL y proxy a ambos.
    2. Apache HTTPD:Estas instrucciones son específicas de Apache HTTPD, pero se puede lograr una configuración similar con NGinx (ver más abajo)
       1. Instale Apache HTTPD, por ejemplo. sudo apt install apache2
       2. Instalamod-headers,mod-proxyymod.proxy-ajpmódulos (o mod-proxy-http), por ejemplo.sudo a2enmod headers; sudo a2enmod proxy; sudo a2enmod proxy_ajp

          1. Alternativamente, puedes optar por usar mod-proxy-http para crear un proxy http. A continuación se comenta un ejemplo separado

       3. Para que mod-proxy-ajp se comunique con Tomcat, tendrás que activar el conector AJP de Tomcat en tu Tomcat's server.xml:

          ?

          <Connector protocol="AJP/1.3" port="8009" redirectPort="8443" URIEncoding="UTF-8" />

       4. Reinician Apache para habilitar estos módulos
       5. Obtenga un certificado SSL para soporte HTTPS. Si aún no tienes uno, puedes usar Let's Encrypt (para gratis) usando la herramienta "certbot": https://certbot.eff.org/

       6. Ahora, configura un nuevo VirtualHost para tu sitio (usando HTTPS / port 443) que proxie todas las solicitudes al conector AJP de Tomcat (corriendo en el puerto 8009)

          ?

          <VirtualHost _default_:443>     # Add your domain here. We've added "my.dspace.edu" as an example     ServerName my.dspace.edu     .. setup your host how you want, including log settings...     .. setup your host how you want, including log settings...       # Most installs will need these options enabled to ensure DSpace knows its hostname and scheme (http or https)     # Also required to ensure correct sitemap URLs appear in /robots.txt for User Interface.     ProxyPreserveHost On     RequestHeader set X-Forwarded-Proto https       SSLEngine on     SSLCertificateFile [full-path-to-PEM-cert]     SSLCertificateKeyFile [full-path-to-cert-KEY]     # LetsEncrypt certificates (and possibly others) may require a chain file be specified     # in order for the UI / Node.js to validate the HTTPS connection.     #SSLCertificateChainFile [full-path-to-chain-file]       # Proxy all HTTPS requests to "/server" from Apache to Tomcat via AJP connector     ProxyPass /server ajp://localhost:8009/server     ProxyPassReverse /server ajp://localhost:8009/server       # If you would rather use mod_proxy_http as an http proxy to port 8080     # then use these settings instead     #ProxyPass /server http://localhost:8080/server     #ProxyPassReverse /server http://localhost:8080/server </VirtualHost>

    3. NGinx:Estas instrucciones son específicas de NGinx.
       1. Instalar/Setup NGinx

       2. Modelo configuración de "bloqueo de servidor" NGinx. Tenga en cuenta que sólo estamos proporcionando ajustes de ejemplo básicos.

          ?

          # Setup HTTP to redirect to HTTPS server {   listen 80;   # Add your domain here. We've added "my.dspace.edu" as an example   server_name my.dspace.edu;   rewrite ^ https://my.dspace.edu permanent; }   # Setup HTTPS access server {   listen 443 ssl;   # Add your domain here. We've added "my.dspace.edu" as an example   server_name my.dspace.edu;     # Add your SSL certificate/key path here   # NOTE: For LetsEncrypt, the certificate should be the full certificate chain file   ssl_certificate my.dspace.edu.crt (or PEM);   ssl_certificate_key my.dspace.edu.key;     # Proxy all HTTPS requests to "/server" from NGinx to Tomcat on port 8080   location /server {     proxy_set_header X-Forwarded-Proto https;     proxy_set_header X-Forwarded-Host $host;     proxy_pass http://localhost:8080/server;   } }

    4. Después de cambiar a HTTPS, asegúrese de volver atrás y actualizar las URLs (principalmente dspace.server.url) en su local.cfg para que coinficion la nueva URL de su backend (REST API). Esto requerirá reiniciar brevemente Tomcat.

Instalación de la Frontend (Interfaz de UCE)

Requisitos de Frontend

Instalación frontend

1. Código de descarga (a [a] [angular espacio-angular]):Descargar elúltima versión dspace-angulardel repositorio DSpace GitHub. Puede optar por descargar el archivo zip o tar.gz proporcionado por GitHub, o puede utilizar "git" para comprobar la etiqueta adecuada (por ejemplo.dspace-8.0) o rama.
   1. NOTA: Para el resto de estas instrucciones, nos referiremos a la ubicación del código fuente como [dspace-angular].

2. Dependientes de instalación: Instale todas las dependencias locales requeridas ejecutando lo siguiente desde dentro de la descomprimida [dspace-angular]Directorio

   ?

   # change directory to our repo cd [dspace-angular]   # install the local dependencies yarn install   # NOTE: Some dependencies occasionally get overly strict over exact versions of Node & Yarn. # If you are running a supported version of Node & Yarn, but see a message like # `The engine "node" is incompatible with this module.`, you can disregard it using this flag: # yarn install --ignore-engines

3. Construir/Compilar: Construir la interfaz de usuario para la producción. Esto construye código fuente (sub [dspace-angular]/src/) para crear una versión compilada de la interfaz de usuario en el [dspace-angular]/distla carpeta. Esto /distla carpeta es lo que desplegaremos y ejecutaremos para iniciar la interfaz de usuario.

   ?

   yarn build:prod

   1. Sólo tienes que reconstruir la aplicación de IU si cambias el código fuente (bajo [dspace-angular]/src/). Simplemente cambiar las configuraciones (por ejemplo, config.prod.yml, ver más abajo) no requiere una reconstrucción, sino que sólo requiere reiniciar la interfaz de usuario.

4. Implementación (a [a [dspace-ui-deploy]): (Sólo recomendado para las configuraciones de producción) Elija/Crear un directorio en su servidor donde desea ejecutar la interfaz de usuario compilada. Llamaremos a esto. [dspace-ui-deploy].

   [dspace-ui-deploy] vs [espacial-angular]

   [dspace-angular]es el directorio donde se ha descargado y construido el código fuente de interfaz de usuario (por las instrucciones anteriores). Para el despliegue/corriendo la interfaz de usuario, recomendamos crear una [dspace-ui-deploy]Directorio. Esto mantiene su funcionamiento, producción Interfaz de usuario separada de su directorio de código fuente y también minimiza el tiempo de in down cuando se reconstruye su interfaz de usuario. Usted puede incluso elegir desplegarse en un [dspace-ui-deploy] directorio en un servidor diferente (y copiar el /distdirectorio a través de FTP o similar).

   Si está instalando la interfaz de usuario por primera vez, o sólo quiere una configuración sencilla, puede optar por que [dspace-ui-despley] y [el espacio-angular] sea el mismo directorio. Esto significaría que no tienes que copiar tu carpeta /dista a otro lugar. Sin embargo, la desventaja es que su sitio de ejecución se volverá insensible cada vez que haga un re-construild/re-compile (es decir, rerun "yarn build:prod") ya que este proceso de compilación primero eliminará el [dspace-angular]/distdirectorio antes de reconstruirlo.

   1. Copia todo [dspace-angular]/dist/carpeta de esta ubicación. Por ejemplo:

      ?

      cp -r [dspace-angular]/dist [dspace-ui-deploy]

       

   2. ADVERTENCIA: En este momento, usted DEBE copiar toda la carpeta "dista" y asegurarse de NO cambiar su nombre. Por lo tanto, la estructura del directorio debe verse así:

      Contenido de la carpeta [dspace-ui-deploy]

      ?

      [dspace-ui-deploy]     /dist        /browser (compiled client-side code)        /server  (compiled server-side code, including "main.js")     /config     (Optionally created in the "Configuration" step below)        /config.prod.yml (Optionally created in the "Configuration" step below)

   3. NOTA: la cuenta de OS que ejecuta la interfaz de usuario a través de Node.js (ver más abajo) DEBEN tener privilegios de escritura a la [dspace-ui-deploy]directorio (porque en la puesta en marcha, la configuración de la hora en ejecución está escrita para [dspace-ui-deploy]/dist/browser/assets/config.json)

5. Configuración: Tienes dos opciones para Configuración de interfaz de usuario, Variables de ambiente o configuración basada en YAML (Configuración basada en YAML (config.prod.yml). Elige uno.

   1. Configuración de YAML: Crear un "config.prod.yml" en [dspace-ui-deploy]/config/config.prod.yml. Usted puede desear utilizar el [dspace-angular]/config/config.example.yml como punto de partida. Esto config.prod.ymlarchivo se puede utilizar para anular cualquiera de las configuraciones predeterminadas listadas en el config.example.yml(en ese mismo directorio). Como mínimo, este archivo DEBE incluir una sección de "descanso" (y también puede incluir una sección "ui", similar a la siguiente (segumente en mente, sólo tiene que incluir la configuración que necesita modificar).

      Ejemplo config.prod.yml

      ?

      # The "ui" section defines where you want Node.js to run/respond. It often is a *localhost* (non-public) URL, especially if you are using a Proxy. # In this example, we are setting up our UI to just use localhost, port 4000. # This is a common setup for when you want to use Apache or Nginx to handle HTTPS and proxy requests to Node on port 4000 ui:   ssl: false   host: localhost   port: 4000   nameSpace: /   # This example is valid if your Backend is publicly available at https://api.mydspace.edu/server/ # The REST settings MUST correspond to the primary/public URL of the backend. Usually, this means they must be kept in sync # with the value of "dspace.server.url" in the backend's local.cfg rest:   ssl: true   host: api.mydspace.edu   port: 443   nameSpace: /server

   2. Variables de medio ambiente: Cada configuración de la interfaz de usuario puede especificarse a través de un entorno variable. Ver Configuración Anérida en la documentación de configuración de interfaz de usuario para más detalles. Por ejemplo, las variables de entorno inferiores proporcionan la misma configuración que el ejemplo de config.prod.yml arriba.

      Ejemplo Variables del medio ambiente

      ?

      # All environment variables MUST # (1) be prefixed with "DSPACE_" # (2) use underscores as separators (no dots allowed), and # (3) use all uppercase   # "ui" section DSPACE_UI_SSL = false DSPACE_UI_HOST = localhost DSPACE_UI_PORT = 4000 DSPACE_UI_NAMESPACE = /   # "rest" section DSPACE_REST_SSL = true DSPACE_REST_HOST = api.mydspace.edu DSPACE_REST_PORT = 443 DSPACE_REST_NAMESPACE = /server

      1. NOTA: Al usar PM2, algunos pueden encontrar más fácil de usar Variables de medio ambiente, ya que le permite especificar configuras de DSpace UI dentro de su configuración PM2. Véase las instrucciones de PM2 a continuación.

   3. Consejos de configuración:
      1. Consulte la documentación de la configuración de interfaz de usuario para una lista de todas las configuraciones disponibles.
      2. En la sección "ui" anterior, usted puede que desee comenzar con "sl: false" y "portar: 4000" sólo para estar seguro de que todo lo demás está funcionando correctamente antes de añadir soporte HTTPS. KEEP IN MIND, recomendamos que siempre use HTTPS for Production. (Véase la sección HTTPS infra)
      3. (Opcionalmente) Pruebe la conexión a su API REST desde la interfaz de usuario desde la línea de comandos. Esto no es necesario, pero a veces puede ayudarle a descubrir problemas de configuración inmediata si la prueba falla.
         1. Si está utilizando configuras YAML, copie su config.prod.yml de nuevo en su carpeta de código fuente en [dspace-angular]/config/config.prod.yml 
         2. De [dspace-angular], corre yarn test:restEste script intentará una conexión básica de Node.js a la API REST que se configura en su archivo "config.prod.yml" y validará la respuesta.
         3. Una conexión exitosa debe devolver una respuesta de 200 y todas las comprobaciones de validación JSON deben devolver "verdala"
         4. Si recibe un error de conexión o un código de respuesta diferente, DEBE fijar su API REST antes de que la interfaz de usuario pueda funcionar. Vea también los " Temas de instalación común " a continuación. Si recibes un error SSL, ve " Usar un certificado SSL autofirmado hace que el Frontend no pueda acceder al Backend "
      4. Cuando se utiliza un subpatamino (nombreSpace) en la URL de la base de servidor de IU (por ejemplo, " http://localhost:4000/sisite/ " en lugar de " http://localhost:4000/ "), debe asegurarse de que la URL  sin el subpatamino se añade al  rest.cors.allowed-originslista en  [dspace]/config/modules/rest.cfgo la  local.cfganular. El valor predeterminado utilizado para esta configuración supone que Origin y DSpace URL son idénticos, pero los orígenes de CORS no contienen un suentro.
6. Arranca la interfaz del usuario:  La interfaz de usuario compilada sólo requiere que Node.js se ejecute. Sin embargo, la mayoría de los usuarios pueden querer utilizar PM2 (o un gestor de procesos Node.js similar) en Producción para proporcionar herramientas de registro y reinicio más fáciles.

   1. Inicio rápido: Para iniciar / probar rápidamente la interfaz de usuario, puede utilizar Node.js. Esto sólo se recomienda para probar rápidamente la interfaz de usuario está funcionando, ya que no hay registros disponibles.

      ?

      # You MUST start the UI from within the deployment directory cd [dspace-ui-deploy]   # Run the "server/main.js" file to startup the User Interface node ./dist/server/main.js   # Stop the UI by killing it via Ctrl+C

   2. Corre a través de PM2: El uso de PM2 (o un gestor de procesos de Node.js diferente) es muy recomendable para escenarios de producción. He aquí un ejemplo de una configuración de producción de PM2.

      1. Primero necesita crear un archivo de configuración de PM2 JSON que ejecutará la interfaz de usuario. Este archivo se puede nombrar cualquier cosa y colocar donde quiera, pero es posible que desee guardarlo en su directorio de implementación (por ejemplo. [dspace-ui-deploy]/dspace-ui.json).

         dspace-ui.json

         ?

         {     "apps": [         {            "name": "dspace-ui",            "cwd": "/full/path/to/dspace-ui-deploy",            "script": "dist/server/main.js",            "instances": "max",            "exec_mode": "cluster",            "env": {               "NODE_ENV": "production"            }         }     ] }

         1. NOTA: La configuración de "cwd" DEBE corresponder a tu [dspace-ui-deploy] ruta de la carpeta.
         2. NOTA No 2: Los ajustes de "execádo" e "instancias" son opcionales pero muy recomendables. Establecer "exec-mode" para "cluster" activa el modo de racimo de PM2. Esto proporcionará un mejor rendimiento en la producción, ya que permite PM2 escalar su sitio a través de múltiples CPUs. La configuración de "instancias" le dice a PM2 cuántas CPU escalar a través ("máximo" significa todas las CPU, pero también puede especificar un número.)

         3. NOTA No.: Si desea configurar su interfaz de usuario utilizando Variables de Medio Ambiente, especifique esas Variables de Medio Ambiente en la sección "env". Por ejemplo:

            Configuración a través de Variables de Medio Ambiente

            ?

            "env": {    "NODE_ENV": "production",    "DSPACE_REST_SSL": "true",    "DSPACE_REST_HOST": "demo.dspace.org",    "DSPACE_REST_PORT": "443",    "DSPACE_REST_NAMESPACE": "/server" }

         4. NOTA No 4: Si está usando Windows, hay otras dos reglas a tener en cuenta en esta configuración de JSON. En primer lugar, todos los caminos deben incluir dobles revolver (por ejemplo, "C:edspace-ui-deploy"). En segundo lugar, se requiere el modo de "cluster". Aquí hay una configuración de ejemplo para Windows:

            dspace-ui.json (para Windows)

            ?

            {     "apps": [         {            "name": "dspace-ui",            "cwd": "C:\\full\\path\\to\\dspace-ui-deploy",            "script": "dist\\server\\main.js",            "instances": "max",            "exec_mode": "cluster",            "env": {               "NODE_ENV": "production"            }         }     ] }

      2. Ahora, inicie la aplicación usando PM2 utilizando el archivo de configuración que creó en el paso anterior

         ?

         # In this example, we are assuming the config is named "dspace-ui.json" pm2 start dspace-ui.json   # To see the logs, you'd run # pm2 logs   # To stop it, you'd run # pm2 stop dspace-ui.json   # If you need to change your PM2 configs, delete the old config and restart # pm2 delete dspace-ui.json

      3. Para obtener más comandos PM2 vea https://pm2.keymetrics.io/docs/usage/quick-start/
      4. HINT: También es posible que desee instalar/configurar pm2-logrotate para asegurarse de que la carpeta de registro de PM2 no se llen en el tiempo.
      5. DidPM2 no funcionó o lanzó un error inmediato? Es probable que algo en su instalación o configuración de la interfaz de usuario sea incorrecto. Compruebe los registros de PM2 ("registros de pm2) primero en busca de errores. Si el problema no es obvio, trate de ver si usted puede ejecutar la interfaz de usuario utilizando el método "Quick Start" (usando sólo Node.js) en su lugar. Una vez que "Quick Start" esté funcionando, pruebe PM2 de nuevo.
      6. Si ni PM2 ni el método "Quick Start" funcionan para usted: entonces consulte la sección "Interfaz de usuario nunca aparece (no aparece contenido) " en los temas de instalación comunes a continuación
7. Pruébalo: En este punto, la interfaz de usuario debe estar disponible en la URL que configuraste.
   
   1. Para un ejemplo de cómo es el frontend predeterminado, visite el Demo Frontend: https://demo.dspace.org/
   2. Si la interfaz de usuario no comienza o lanza errores, es probable que sea un problema de configuración. Consulte Commons Installation Issues a continuación para mensajes de error comunes que pueda ver y cómo resolverlos.
   3. Si usted tiene un problema especialmente difícil de depurar, usted puede desear detener la PM2. En su lugar, intente ejecutar la interfaz de usuario a través del método "Quick Start" (usando sólo Node.js). Este comando podría proporcionarle un mensaje de error más específico, si PM2 no está devolviendo suficiente información.
8. Añadir soporte HTTPS:Para el soporte HTTPS (port 443), tienes dos opciones
   1. (Recomendación)Instalar cualquiera de los dosApache HTTPDo oNginxactuar como un "proxy inversa" para el frontend (y backend). Esto le permite administrar los certificados HTTPS (SSL) ya sea en Apache HTTPD o Nginx, y proxy todas las solicitudes al frontend (correr en el puerto 4000) y backend (correr en el puerto 8080). Este es nuestro enfoque recomendado actual. Estas instrucciones son específicas de Apache, pero se puede lograr una configuración similar con Nginx.
      1. Si ya tiene instalado Apache / Nginx para el backend, puede utilizar el mismo Apache / Nginx. También puede elegir instalar uno separado (o cualquier enfoque está bien).
         1. Instale Apache HTTPD, por ejemplo. sudo apt install apache2
         2. Instale los módulos de mod.proxy y mod-proxyhttp, por ejemplo. sudo a2enmod proxy; sudo a2enmod proxy_http
         3. Reinician Apache para habilitar
         4. Obtenga un certificado SSL para soporte HTTPS. Si aún no tienes uno, puedes usar Let's Encrypt (para gratis) usando la herramienta "certbot": https://certbot.eff.org/

      2. Configuración de la muestra HTTPD de Apache:

         1. Ahora, configura (o actualización) el nuevo VirtualHost para tu sitio de IU (preferiblemente usando HTTPS / puerto 443) que proxie todas las solicitudes a PM2 que se ejecuta en el puerto 4000.

            ?

            <VirtualHost _default_:443>     # Add your domain here. We've added "my.dspace.edu" as an example     ServerName my.dspace.edu     .. setup your host how you want, including log settings...             # Most installs will need these options enabled to ensure DSpace knows its hostname and scheme (http or https)     # Also required to ensure correct sitemap URLs appear in /robots.txt for User Interface.     ProxyPreserveHost On     RequestHeader set X-Forwarded-Proto https       # These SSL settings are identical to those for the backend installation (see above)     # If you already have the backend running HTTPS, just add the new Proxy settings below.     SSLEngine on     SSLCertificateFile [full-path-to-PEM-cert]     SSLCertificateKeyFile [full-path-to-cert-KEY]     # LetsEncrypt certificates (and possibly others) may require a chain file be specified     # in order for the UI / Node.js to validate the HTTPS connection.     #SSLCertificateChainFile [full-path-to-chain-file]       # These Proxy settings are for the backend. They are described in the backend installation (see above)     # If you already have the backend running HTTPS, just append the new Proxy settings below.     # Proxy all HTTPS requests to "/server" from Apache to Tomcat via AJP connector     # (In this example: https://my.dspace.edu/server/ will display the REST API)     ProxyPass /server ajp://localhost:8009/server     ProxyPassReverse /server ajp://localhost:8009/server       # [NEW FOR UI:] Proxy all HTTPS requests from Apache to PM2 on localhost, port 4000     # NOTE that this proxy URL must match the "ui" settings in your config.prod.yml     # (In this example: https://my.dspace.edu/ will display the User Interface)     ProxyPass / http://localhost:4000/     ProxyPassReverse / http://localhost:4000/ </VirtualHost>

      3. Configuración de la muestra de NGinx

         1. Modelo configuración de "bloqueo de servidor" NGinx. Tenga en cuenta que sólo estamos proporcionando ajustes de ejemplo básicos.

            ?

            # Setup HTTPS access server {   listen 443 ssl;   # Add your domain here. We've added "my.dspace.edu" as an example   server_name my.dspace.edu;     # Add your SSL certificate/key path here   # NOTE: For LetsEncrypt, the certificate should be the full certificate chain file   # These SSL settings are identical to those for the backend installation (see above)   # If you already have the backend running HTTPS, just add the new Proxy settings below.   ssl_certificate my.dspace.edu.crt (or PEM);   ssl_certificate_key my.dspace.edu.key;     # Proxy all HTTPS requests to "/server" from NGinx to Tomcat on port 8080   # These Proxy settings are for the backend. They are described in the backend installation (see above)   location /server {     proxy_set_header X-Forwarded-Proto https;     proxy_set_header X-Forwarded-Host $host;     proxy_pass http://localhost:8080/server;   }     # [NEW FOR UI:] Proxy all HTTPS requests from NGinx to PM2 on localhost, port 4000   # NOTE that this proxy URL must match the "ui" settings in your config.prod.yml   # (In this example: https://my.dspace.edu/ will display the User Interface)   location / {     proxy_set_header X-Forwarded-Proto https;     proxy_set_header X-Forwarded-Host $host;     proxy_pass http://localhost:4000/;   } }

      4. HINT-1: Debido a que está usando un proxy para el soporte HTTPS, en su Configuración de interfaz de usuario, sus ajustes "ui" todavía tendrán "ssl: false" y "puerto: 4000". Esto está perfectamente bien.
      5. HINT-2: para forzar a la interfaz de usuario a conectarse al backend usando HTTPS, debe verificar su configuración de "descanse" en su Configuración de Interfaz de Usuario la "dspace.server.url" en su backend "local.cfg" y ambos usen la URL HTTPS. Por lo tanto, si su backend (REST API) se ajusta a https://my.dspace.edu/server/, ambos ajustes deben especificar esa URL HTTPS.
      6. HINT-3: para forzar el backend a reconocer la interfaz de usuario HTTPS, asegúrese de actualizar su "dspace.ui.url" en su backend "local.cfg" para usar la nueva URL de HTTPS UI (por ejemplo, https://my.dspace.edu).
   2. (Alternativamente)Puede utilizar el soporte HTTPS básico integrado en nuestro servidor de interfaz de usuario y nodo. (Esto puede ser mejor actualmente para entornos no de producción, ya que no ha sido bien probado)
      1. Crear un [dspace-ui-deploy]/config/ssl/carpeta y añadir un key.pemy cert.pema esa carpeta (deben tener esos nombres exactos)
      2. En tuConfiguración de interfaz de usuario, retro Regresar y actualizar lo siguiente:
         
         1. Estallar "ui ssl" a verdad
         2. Actualizar "ui puerto" que será 443
            1. Para ejecutar Node/PM2 en el puerto 443, es probable que también tenga que proporcionar nodo con permisos especiales, como en este ejemplo.
      3. Reiniciar la IU
      4. Tenga en cuenta, mientras que esta configuración es simple, es posible que no tenga el mismo nivel de registros de producción detallados que lo haría con Apache HTTPD o Nginx

Qué sigue?

Después de una instalación exitosa, es posible que desee echar un vista más de cerca

• Performance Tuning DSpace : Si usted está notando alguna lentitud en su sitio de producción, tenemos una guía de cómo podría acelerar las cosas.
• Personalización de la interfaz del usuario: Documentación sobre la personalización de la interfaz del usuario con su propia marca / temas
• Configuración de interfaz del usuario: Configuraciones adicionales disponibles en la interfaz de usuario.
• Interfaz de usuario de la presentación : Opciones para configurar/personalizar el proceso de envío predeterminado (depósito)
• Flujo de trabajo configurable : Opciones para configurar/personalizar el proceso de aprobación de flujo de trabajo predeterminado
• Tareas programadas vía Cron: Varias funciones de DSpace requieren que un script de línea de comandos se ejecute regularmente a través de cron.
• Referencia de configuración : Detalles sobre las opciones de configuración disponibles para el Backend
• Instalación de Servidor de Mango: Opcionalmente, es posible que desee habilitar URLs persistentes para su sitio DSpace usando el Registro de la Red de Manejas de CRNI
• Estadísticas y métricas: Opcionalmente, es posible que desee configurar una (o más) opciones de estadísticas dentro de DSpace, incluyendo Google Analytics y (interno) Solr Statistics
• Soporte multilingue: Opcionalmente, es posible que desee habilitar el soporte multilingue en su sitio DSpace.
• Utilizando DSpace : Varias otras páginas que describen el uso y configuraciones adicionales relacionadas con otras características de DSpace.
• Administración de sistemas: Varias otras páginas que describen opciones/configuraciones de instalación de backend adicionales.

Si te has topado con problemas de instalación, es posible que quieras...

• Visite la resolución de problemas una guía de error para consejos sobre la localización de la causa del error
• Cuestiones de instalación de los comunes (ver más abajo)
• Solicitar soporte a través de una de las opciones de soporte documentadas en esa página

Problemas comunes de instalación

Soluvilegise un error o encontrar mensajes de error detallados

Vea la guía de errores de la resolución de problemas, busque la sección en "DSpace 7.x o 8.x". Esto le proporcionará pistas sobre la localización de mensajes de error tanto en la interfaz de usuario (frontend) como en la REST API (backend)

La interfaz de usuario nunca aparece (no aparece contenido) o "Serservador de Proxy recibió una respuesta inválida"

Lo más probable es que su interfaz de usuario (UI) esté lanzando un error severo o no empezar correctamente. La mejor manera de depurar este problema sería iniciar la interfaz de usuario en el modo de desarrollo para ver si puede darle un error más descriptivo.

1. Primero, crear un [dspace-ui-deploy]/config/config.dev.ymlarchivo de configuración para el desarrollo. Este archivo soporta los mismos ajustes que sus configs existentes. Por lo tanto, puede copiar sobre cualquier configuración que desee probar.

2. Inicia la interfaz de usuario en el modo de desarrollo (esto no requiere un proxy como Apache o Nginx)

   ?

   yarn start:dev

3. Esto arrancará la interfaz del usuario en cualquier puerto que haya especificado en "config.dev.yml"
4. En este punto, intente acceder a la interfaz de usuario desde tu navegador web. Incluso si no está funcionando completamente, usted debe ser capaz de obtener más información de DevTools de su navegador con respecto al error subyacente. Vea la página de error de la resolución de problemas, busque la sección en "DSpace 7.x o 8.x". Tiene una guía para localizar mensajes de error de interfaz de usuario en las herramientas de desarrollo de tu navegador.

Una vez que haya encontrado el error subyacente, puede ser uno de los "cuestiones de instalación comunes" que se enumeran a continuación.

Interfaz de usuario carga parcialmente pero luego gira (nuncas cargas completamente o algún contenido no se carga)

Lo más probable es que su interfaz de usuario (UI) esté lanzando un error o recibiendo una respuesta inesperada del backend REST API. Dado que la interfaz de usuario se basa Javascript, se ejecuta completamente en su navegador. Eso significa que el error que está golpeando se ve más fácilmente en su navegador (y de hecho el error puede nunca aparecer en archivos de registro).

Vea la página de error de la resolución de problemas, busque la sección en "DSpace 7.x o 8.x". Tiene una guía para localizar mensajes de error de interfaz de usuario en las herramientas de desarrollo de tu navegador.

"500 servicio no disponible" en la interfaz del usuario

Este error está diciendo que el frontend está funcionando, pero es incapaz de comunicarse con su backend. Es lo mismo que la "sección No Enlaces encontrada en"... error descrito en la siguiente sección. Por favor, siga los detalles de la resolución de problemas en esa sección.

"No .

Al iniciar la interfaz de usuario por primera vez, puede que vea un error que se ve...

Este error significa que la interfaz de usuario no puede ponerse en contacto con la API REST listada en [rest-api-url]y/o la respuesta de esa [rest-api-url]es inesperado (ya que no contiene los "-vinculos" a los puntos finales disponibles en esa API REST). Un DSpace válido [rest-api-url]responderá con JSON similar a nuestra demo API en https://demo.dspace.org/server/api

Primero, pruebe la conexión a su REST API desde la interfaz de usuario desde la línea de comandos.

• Una conexión exitosa debe devolver una Respuesta 200 y todas las comprobaciones de validación JSON deben devolver "verda".
• Si recibe un error de conexión o un código de respuesta diferente, DEBE arreglar su API REST antes de que la interfaz de usuario pueda funcionar (ver pistas adicionales a continuación para causas probables).

Por lo general, el problema central es causado por uno de los siguientes escenarios:

• Un posible problema de configuraciónen el frontend o backend.
  • Comproba' sección de "descanse" de suconfig.*.ymlArchivo de configuración para la interfaz de usuario. Esa sección de configuración define qué REST API intentará usar la interfaz de usuario. Si la configuración NO mapea a una API REST de DSpace válida, entonces verá este error "No se encuentra". error. Tenga en cuenta que la API REST debe usar HTTPS (la única excepción es si tanto el frontend como el backend están corriendo en URLs basadas en "localhost")
  • Comaifique la configuración de "dspace.ui.url" de su backend y verifique que corresponde a la URL pública de la Interfaz de Usuario (es decir, la misma URL que utiliza en su navegador)
  • Verifique el backend "confianza" el frontend a través de la configuración "rest.cors.aperdido-origen" (en rep.cfg o local.cfg). Este entorno debe enumerar a todos los clientes basados en la web que confíen en el backend (REST API). Por defecto, "dspace.ui.url" debe ser listado... pero debe verificar que no ha sido modificado.
• Una posible emisión de certificados SSL.Esta emisión también puede aparecer si el certificado SSL de la API REST es cualquiera de los dosno confiada (por el frontend) o caducada.

  • Si está utilizando un certificado de estilo Let's Encrypt, es posible que tenga que modificar la configuración de Apache de su backend para proporcionar también un archivo de cadena de la siguiente manera:

    ?

    # For example: /etc/letsencrypt/live/[domain]/cert.pem SSLCertificateFile [full-path-to-PEM-cert] # For example: /etc/letsencrypt/live/[domain]/privkey.pem SSLCertificateKeyFile [full-path-to-cert-KEY] # For example: /etc/letsencrypt/live/[domain]/chain.pem SSLCertificateChainFile [full-path-to-chain-file]

  • Según los documentos Apache, también puede utilizar la configuración de SSLCertificateFile para especificar los certificados de CA intermedios junto con el certificado principal.
  • Para las certáts autofirmas, véase también " Usar un certificado SSL autofirmado hace que el Frontend no pueda acceder al Backend " cuestión común listada a continuación.
• Algo que bloquea el acceso a la API REST. Esto puede ser un problema de poder, un problema de cortafuera de fuego, o algo más que generalmente bloquea el puerto (por ejemplo, puerto 443 para SSL).

  • Verifique que puede acceder a la API REST desde la máquina donde está en marcha Node.js (es decir, su interfaz de usuario está en marcha). Por ejemplo, pruebe un simple "engancho" o "curl" para verificar que la REST API está devolviendo JSON esperado similar a nuestra demo API en https://demo.dspace.org/server/api

    ?

    # Attempt to access the REST API via HTTPS from command-line on the machine where Node.js is running. # If this fails or throws a SSL cert error, you must fix it. wget https://[rest.host]/server/api

  • En la mayoría de los escenarios de producción, su REST API debe ser accesible al público en la web, a menos que tenga garantizado que todos sus usuarios de DSpace accederán al sitio detrás de una VPN o similar. Por lo tanto, este error "No se encontró" también puede ocurrir si estás accediendo a la interfaz de usuario desde un cliente de computadora/náseador web que no puede acceder a la API REST.

Si ninguna de las sugerencias anteriores ayudó, es posible que desee mirar más de cerca los registros de solicitud en su navegador (usando los registros Dev del navegador) y los registros del lado del servidor, para asegurarse de que las solicitudes de su interfaz de usuario van a donde usted espera, y ver si aparecen también en el backend. Consejos para encontrar estos registros se pueden encontrar en la sección "DSpace 7.x o 8.x" de nuestra Troubleshoot una guía de errores.

"RangeError: Rebajo máximo tamaño de la pila de llamadas"

Al iniciar la interfaz de usuario por primera vez, puede que vea un error que se ve...

Este error significa que la interfaz de usuario está tratando de ponerse en contacto con su API REST, pero está teniendo problemas para hacerlo (posiblemente porque una redirección o HTTP-HTTPS está causando problemas o un bucle de rediraciones).

Comprobación de la...dspace.server.url" estableciendo en su local.cfg en el backend. Es la misma URL que usas en tu navegador para acceder al backend? Tenga en cuenta que el modo (http vs https), dominio, puerto y subpats (s) todos deben coincidir, y no debe terminar en una barra de seguimiento.

También revise la sección "descanse" de suconfig.*.ymlArchivo de configuración para la interfaz de usuario. Asegúrese de que también está apuntando a la misma URL exacta que esa "dspace.server.url"estar fijamente. Una vez más, compruebe el modo, dominio, puerto y rutas coinciden exactamente.

"XMLHttpRequest.. ha sido bloqueado por la política CORS" o "error de CORS" o "Petición CORS inválido"

Si usted está viendo un error CORS en su navegador, esto significa que está accediendo a la API REST a través de una aplicación cliente "corustada". Para solucionar este error, debe cambiar su configuración REST API / Backend para confiar en la aplicación.

• Por defecto, el DSpace REST API / Backend sólo confiará en la aplicación en dspace.ui.url. Por lo tanto, primero debe verificar que su dspace.ui.urlLa configuración (en su local.cfg) coincide exactamente con la URL principal de su Interfaz de usuario (es decir, la URL que ve en el navegador). Este debe ser un partido exacto: el modo (http vs https), dominio, puerto y supatidades deben coincidir.
• Si necesita confiar en aplicaciones/ URLs adicionales de clientes, esas DEBEN ser añadidos a la rest.cors.allowed-originsconfiguración. Consulte REST API para más detalles sobre esta configuración.
• Además, compruebe sus archivos de registro de Tomcat (o contenedor de servicio). Si Tomcat lanza una sintaxis u otro error importante, puede devolver una respuesta de error que desencadena un error CORS. En este escenario, el error CORS es sólo un efecto secundario de un error mayor.

Si modifica cualquiera de los ajustes anteriores, tendrá que reiniciar Tomcat para que los cambios surta efecto.

No se puede iniciar sesión desde la interfaz de usuario con una contraseña que sé que es válida

Si no puede iniciar sesión a través de la interfaz de usuario con una contraseña válida, debe comprobar qué error subyacente está siendo devuelto por la API REST. La forma más fácil de hacer esto es usando las Herramitas Dev de su navegador web como se describe en nuestra guía de errores de la resolución (ver la sección "Pírate esta primera" para DSpace 7).

Si la contraseña es válida, es más que probable que veas que el error subyacente es el error "403 Provido" con un mensaje que dice "El acceso se niega. CSRF Token inválido" (ver indicios de resolver esto en la siguiente sección)

Error de "403 Provito" con un mensaje que dice "Se niega el acceso. Token CSRF inválido"

Primero, compruebe doble que está viendo ese mensaje de error exacto. A 403 ForbiddenEl error puede ser lanzado en una variedad de escenarios. Por ejemplo, se puede lanzar un 403 si una página requiere un inicio de sesión, si ha introducido un nombre de usuario o contraseña inválido, o incluso a veces cuando hay un error CORS (consulte el problema de instalación anterior para resolver eso).

Si usted está viendo el mensaje "Invalid CSRF Token" (especialmente en cada login), esto suele ser el resultado de un problema de configuración / configuración.

Aquí hay algunas cosas que deberías comprobarlo dos veces:

1. Si usted había estado trabajando, y este error parece aleatorio, es posiblemente queDSPACE-XSRF-COOKIEcookies en su navegador acaba de conseguir "fuera de sincronización" (esto puede ocurrir si está iniciando la API REST y la interfaz de usuario por separado en el mismo navegador).
   1. Cerrar sesión e iniciar sesión y probar la misma acción de nuevo. Si funciona esta vez, entonces esa galleta estaba "fuera de sincronía". Si falla por segunda vez, entonces hay un problema de configuración probable... ver sugerencias a continuación.
2. Asegúrese de que su backend está ejecutando HTTPSEsta es la causa más común de este error. El único escenario en el que puede ejecutar el backend en HTTP es cuando tanto las URL frontend & backend son URLs basadas en "localhost". 
   1. La razón de este requisito HTTPS es que la mayoría de los navegadores modernos bloquearán automáticamente las cookies de dominio cruzado al usar HTTP. Las cookies cruzadas sonnecesariopara la autenticación exitosa.excepciónes cuando tanto el frontend como el backend están utilizando URLs locales (como en ese escenario las cookies ya no necesitan ser enviadas entre dominio). Una descripción más técnica de este comportamiento está en los sub-bullets a continuación.
      1. Si el REST API Backend está ejecutando HTTP, siempre enviará el necesario DSPACE-XSRF-COOKIEcookies con un valor de SameSite=Lax. Esta configuración significa que la cookie no será enviada (por su navegador) a ningún otro dominio. Efectivamente, esto bloqueará todos los inicios de sesión de cualquier dominio que no sea el mismo que la API REST (ya que esta cookie no se enviará de vuelta a la API REST como se requiere para la validación CSRF). En otras palabras, ejecutar la API REST en HTTP sólo es posible si la interfaz de usuario se ejecuta en el mismo dominio. Por ejemplo, correr tanto en 'localhost' con HTTP es una configuración de desarrollo común, y esto funcionará bien.
      2. Para permitir los inicios de sesión de dominio cruzado, DEBE habilitar HTTPS en la API REST. Esto resultará en la DSPACE-XSRF-COOKIEcookies que se está poniendo en SameSite=None; Secure. Esta configuración significa que la cookie se enviará dominio cruzado, pero sólo para solicitudes HTTPS. También permite que la interfaz de usuario (u otras aplicaciones cliente) esté en cualquier dominio, siempre que el dominio sea confiado por CORS (ver rest.cors.allowed-originsconfiguración en REST API)
3. Verifique que la sección "descanso" de su interfaz de usuario coinice con el valor de "dspace.server.url" configuración en el Backend. Esto simplemente asegura que su interfaz de usuario está enviando solicitudes a la API REST correcta. También preste mucha atención que ambos especifiquen HTTPS cuando sea necesario (ver bala anterior).
4. Verifica que tu "dspace.server.url" configuración en el Backend coincide con la URL principal de la API REST (es decir, la URL que ves en el navegador). Todo esto debe coincidir con una coincidencia exacta: el modo (http vs https https), el dominio, el puerto y los subpats (s) todo debe coincidir, y no debe terminar en una barra de pistas (por ejemplo, "https://demo.dspace.org/server" es válida, pero " https://demo.dspace.org/server /" puede causar problemas).
5. Verifica que tu "dspace.ui.url" configuración en el Backend coincide con la URL principal de su Interfaz de Usuario (es decir, la URL que ve en el navegador). Este debe ser un partido exacto: el modo (http vs https), dominio, puerto y subpatizar (s) todos deben coincidir, y no debe terminar en una barra de senderos (por ejemplo, "https://demo.dspace.org" es válido, pero " https://demo.dspace.org/ " puede causar problemas).
6. Verifique que nada (por ejemplo, un proxy) esté bloqueando que las cookies y los encabezados HTTP se pasen entre la interfaz de usuario y la API REST. La protección CSRF de DSpace se basa en que el cliente (Interfaz de Usuario) pueda devolver a ambos una DSPACE-XSRF-COOKIEcookies y una coincidencia X-XSRF-TOKENcabecera de vuelta a la API REST para validación. Vea nuestro contrato REST para más detalles https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md
7. Si usted está ejecutando una aplicación personalizada, o accediendo a la API REST desde la línea de comandos (u otra herramienta de terceros como Cartero), DEBE asegurarse de que está enviando el token CSRF en cada solicitud de modificación. Vea nuestro contrato REST para más detalles https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

Para obtener más información sobre cómo funciona la protección CSRF de DSpace, vea nuestro contrato REST en https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

El uso de un certificado SSL autoinfirmada hace que Frontend no pueda acceder al Backend

Si configura el backend para usar HTTPS con un certificado SSL autofirmado, entonces Node.js (que el frontend ejecuta en) no puede "confiar" en ese certificado por defecto. Esto dará como resultado que el Frontend no pueda hacer peticiones al Backend.

Una posible solución (sin probar hasta ahora) es intentar establecer la variable de entorno NODE-EXTRA-CA-CERTS (que le dice a Node.js que confíe en los certificados adicionales de CA).

Otra opción es evitar el uso de un certificado SSL autofirmado. En su lugar, cree un certificado SSL real y emitido usando algo como Let's Encrypt (o servicios gratuitos similares)

Mi REST API se está ejecutando bajo HTTPS, pero algunas de sus URLs de "enlace" están cambiando a HTTP

Este escenario puede ocurrir cuando usted está ejecutando la API REST detrás de un proxy HTTP (por ejemplo. Apache HTTPD's mod_proxy_http, Ngnix's proxy_passo cualquier otro proxy que esté reendenndo de HTTPS a HTTP).

La solución es para asegurar que la DSpace REST API se envía el X-Forwarded-Protocabecera (por su servicio de proxy), diciéndolo que el protocolo reenviado es HTTPS

En general, cuando se ejecuta detrás de un proxy, la DSpace REST API depende de encabezados X-Forwarded-* precisos para ser enviados por ese proxy.

El robots de My User Interface.txt tiene URLs de mapa de sitio incorrectos

Este escenario puede ocurrir cuando usted está ejecutando la interfaz del usuario detrás de un proxy HTTP (por ejemplo. Apache HTTPD's mod_proxy_http, Ngnix's proxy_passo cualquier otro proxy que esté reendenndo de HTTPS a HTTP).

La solución es para asegurar que la interfaz del usuario DSpace (en primera línea) se envíe la correcta X-Forwarded-Protoy Host(o X-Forwarded-Host) cabeceras para decirle el nombre y esquema de host correcto (HTTP o HTTPS)

No se puede subir archivo de la interfaz de usuario

Si todo parece estar funcionando, pero no puede subir archivos, es importante primero comprobar sus registros para detectar posibles errores de backend. Ver la resolución de problemas una página de error.

Si usted está ejecutando DSpace en un sistema basado en Debian (por ejemplo. Ubuntu), algunos usuarios han informado que se requiere la subvención "LeerWrite" acceso a Apache Tomcat (donde el backend está ejecutando) a través del archivo de servicio (por ejemplo, /lib/systemd/system/tomcat9.service). En el [Service]sección que necesitas para añadir algo como esto:

Javascript amontap de memoria

En algunas versiones de Node.js o algunos sistemas operativos, los sitios han informado viendo un error de "Javascript amontonado fuera de memoria" al tratar de ejecutar la interfaz del usuario en el modo de desarrollo (Eyarn start:dev). Esto no parece ocurrir en todos los sistemas, pero la solución es siempre la misma. Debe asegurarse de que Node.js recibe al menos 4 GB de memoria a través de la variable de entorno "NODE-OPTIONS"

NOTA: Más discusión sobre este tema se puede encontrar en https://github.com/DSpace/dspace-angular/issues/2259 Parece que sólo ocurre en sistemas donde la memoria predeterminada asignada para Nodo no es suficiente para construir DSpace en modo de desarrollo.

Este mismo escenario también se puede utilizar en escenarios de producción para darle a Node.js más memoria con la que trabajar. Ver Performance Tuning DSpace para más detalles.

Solr responde con "Expected mime type application/octet-stream but got text/html" (404 Not Found)

Este error ocurre cuando Solr no se presenta correctamente, o su backend de DSpace no puede encontrar/comunicarse con Solr. Aquí hay algunas cosas que deberías comprobarlo doblemente:

1. Verifique que Solr esté ejecutando y/o compruebe si hay errores en sus registros. Trate de reiniciarlo (generalmente a través de un comando como [solr]/bin/solr restart), y verificar que es accesible a través de wget o un navegador web (generalmente en una URL como http://localhost:8983/solr)
2. Verifique que solr.serverLa configuración (en local.cfg) es correcta para su instalación de Solr. Esto debe corresponder a la URL principal de su sitio Solr (generalmente algo así como http://localhost:8983/solr). Si usas wgeto un navegador de la máquina que ejecuta su backend de DSpace, usted debe obtener una respuesta de esa URL (debería devolver la interfaz de usuario de administración de Solr).
3. Verifique que los núcleos de DSpace Solr requeridos se han instalado/configurado correctamente (por instrucciones de instalación anteriores). Cuando esté correctamente instalado, usted debe ser capaz de obtener una respuesta de ellos. Por ejemplo, la URL ${solr.server}/search/selectdebe hacer una consulta vacía contra el núcleo de "búsqueda", devolviendo un resultado JSON vacío.
4. Si Solr está corriendo y estás seguro solr.serverestá establecido correctamente, compruebe que nada más podría estar bloqueando el backend de DSpace de acceder a Solr. Por ejemplo, si Solr está en una máquina separada, verifique que no hay cortafunciones o proxy que podría estar bloqueando el acceso entre la máquina de backend DSpace y la máquina Solr.

Errores de la base de datos ocurren cuando se ejecuta ant fresh_install

Hay dos errores comunes que ocurren.

• If your error looks like this:

  ?

  [java] 2004-03-25 15:17:07,730 INFO         org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database [java] 2004-03-25 15:17:08,816 FATAL         org.dspace.storage.rdbms.InitializeDatabase @ Caught exception: [java] org.postgresql.util.PSQLException: Connection refused. Check         that the hostname and port are correct and that the postmaster is         accepting TCP/IP connections. [java]     at         org.postgresql.jdbc1.AbstractJdbc1Connection.openConnection(AbstractJd bc1Connection.java:204) [java]     at org.postgresql.Driver.connect(Driver.java:139)

  it usually means you haven't yet added the relevant configuration parameter to your PostgreSQL configuration (see above), or perhaps you haven't restarted PostgreSQL after making the change. Also, make sure that the db.username and db.password properties are correctly set in [dspace]/config/dspace.cfg. An easy way to check that your DB is working OK over TCP/IP is to try this on the command line:

  ?

  psql -U dspace -W -h localhost

  Enter the dspace database password, and you should be dropped into the psql tool with a dspace=> prompt.

• Another common error looks like this:

  ?

  [java] 2004-03-25 16:37:16,757 INFO         org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database [java] 2004-03-25 16:37:17,139 WARN         org.dspace.storage.rdbms.DatabaseManager @ Exception initializing DB         pool [java] java.lang.ClassNotFoundException: org.postgresql.Driver [java]     at java.net.URLClassLoader$1.run(URLClassLoader.java:198) [java]     at java.security.AccessController.doPrivileged(Native        Method) [java]     at        java.net.URLClassLoader.findClass(URLClassLoader.java:186)

  This means that the PostgreSQL JDBC driver is not present in [dspace]/lib. See above.