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.
Im weiteren werden die grundlegenden Systemanforderungen beschrieben, welche für den Betrieb einer MyCoRe-Anwendung unter LTS 2018.06 erforderlich sind.
MyCoRe LTS 2018 wird auf Servern mit den folgenden Betriebsystemen verwendet (Neuere Versionen sollten kein Problem darstellen):
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.
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.
Die Datei persistence.xml muss um einen Eintrag für Viewer-Mapping ergänzt werden.
|
|
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:
|
|
Weiterhin MUSS der Parameter -DMCR.AppName={MCR.AppName} beim Tomcat-Start mit gegeben werden.
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
|
|
Die Solr-Properties und MyCoRe-PI-Properties wurden zum Teil umgebannt und müssen angepasst werden. Details dazu siehe MyCoRe-Migration.
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.
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:
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.