2018.06

Nutzungsvoraussetzungen Release LTS 2018.06

Diese Seite fasst Informationen für die Nutzung von MyCoRe LTS 2018-06 und die Migration vom LTS-Release 2017.06 zum LTS-Release 2018.06 zusammen.

Systemanforderungen

Im weiteren werden die grundlegenden Systemanforderungen beschrieben, welche für den Betrieb einer MyCoRe-Anwendung unter LTS 2018.06 erforderlich sind.

Betriebssystem

MyCoRe LTS 2018 wird auf Servern mit den folgenden Betriebsystemen verwendet (Neuere Versionen sollten kein Problem darstellen):

  • Open SuSE Leap 42.3 / Leap 15 / Leap 15.1
  • SuSE SLES 12 SP 3+ / SuSE SLES 15 / SuSE SLES 15.1
  • Ubuntu 18.04 LTS
  • CentOS 7
  • Windows 7 und 10 für Test- und Entwicklungssysteme

Standardsoftware

Zur Arbeit mit MyCoRe LTS 2018 Release sind folgende Softwarekomponenten erforderlich bzw. empfohlen. Diese stammen alle von Drittanbietern und sind im Normalfall in den aktuellen Linux-Distributionen enthalten.

  • Java 8
  • Tomcat 8.4 oder Jetty 9.4.9 (alternativ ein System mit Unterstützung von Servlet-3.1)
  • SOLR 7.0.1 oder höher (ebenfalls kompatibel mit 4.10)
  • eine hibernate-fähige relationale Datenbank wie PostgreSQL, MySQL, DB2; für Testzwecke ist H2 als Datenbank integriert
  • Git 2.12 oder höher
  • Apache Maven 3.3.9 oder höher

Migrationsschritte

MyCoRe-Komponenten

Mit Release 2018.06 entfällt die alle MyCoRe-Komponenten zusammenfassende Komponente mycore-complete. Es ist nun erforderlich, alle einzelnen Komponenten in den Maven dependencies anzugeben, welche von der Anwendung tatsächlich benötigt werden.

persistence.xml

Die Datei persistence.xml muss um einen Eintrag für Viewer-Mapping ergänzt werden.

1
<mapping-file>META-INF/mycore-viewer-mappings.xml</mapping-file>

jwt.secret

Die Datei jwt.secret ist zum Signieren des JSON-Web-Tokens gedacht. Jeder kann mit dieser Datei gültige Tokens erzeugen, denen dann MyCoRe über die REST-API blind vertraut. MyCoRe benutzt diese, um Tokens zu erzeugen und wenn es diese erhält mit dem privaten Schlüssel zu validieren. Sie enthält 4K an Zufallsdaten und wird im Konfigurationsverzeichnis abgelegt. Sollte das jwt.secret noch nicht existieren, generiert MyCoRe die Datei anhand von Zufallsdaten. Dies kann abhängig vom Input wenige Sekunden aber auch mehrere Stunden dauern.

Das Secret kann auch händisch z.B. mit folgendem Befehl erzeugt werden:

1
2
        openssl rand 4096 &gt; ~/.mycore/{MCR.AppName}/jwt.secret
      

Weiterhin MUSS der Parameter -DMCR.AppName={MCR.AppName} beim Tomcat-Start mit gegeben werden.

Proxy-Header

Damit MyCoRe auch hinter einem Proxy sauber funktioniert wurde die Nutznung der Proxy-Header realisiert. Läuft die Anwendung hinter einem Apache muss dieser ggf. umkonfiguriert werden. Details dazu siehe auch MCR-1842

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
location /mir {
  gzip_types      text/xml application/json;
  gzip_vary       on;
  gzip_proxied    any;
  proxy_pass      http://localhost:8291/mir;
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Path "/mir";
  proxy_set_header X-Forwarded-Port $server_port;
  proxy_cache     STATIC;
  #proxy_cache_valid 200 1d;
  proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
}
      

Properties

Die Solr-Properties und MyCoRe-PI-Properties wurden zum Teil umgebannt und müssen angepasst werden. Details dazu siehe MyCoRe-Migration.

Migration auf MCRMetadataHistoryManager

Die "Deletion Policy“ braucht man zwingend für DINI-Repositorien und OAI2. Daher muss der MCRMetadataHistoryManager im Einsatz seien. Initial erfolgt dies über die beiden Kommandos mycore.sh clear metadata history completely und mycore.sh build metadata history completely. Weiterhin muss der MCRMetadataHistoryManager als EventHandler aktiv sein.

rfc5646

Die Sprachklassifikation rfc4646 wurde durch eine neuere und vollständige Version rfc5646 abgelöst. Details können dem Github-Commit entnommen werden. Für die Migration sind in der CLI folgende Schritte nötig:

  1. Laden der neuen Klassifikation:
  2. Selektieren aller zu migrierenden Objekte mit Hilfe einer Solr-Query: select objects with solr query +objectType:mods +category.top:rfc4646\:* in core main In der Konsole sollte diese Nachricht erscheinen: INFO: 264 objects selected
  3. Migration der Objekte mit dem folgenden CLI-Befehl: execute for selected xslt {x} with file resource:xsl/mycoreobject-migrate-language.xsl
  4. Löschen der alten Klassifikation:

REST-API-ACLs

Anstatt von 'write' muss die Zugriffsrecht 'writedb' und anstelle von 'delete' heisst es nun 'deletedb'. Damit verhält sich diese Konfiguration wie alle anderen ACLs. Details siehe MCR-1924.