-
Notifications
You must be signed in to change notification settings - Fork 64
Update einspielen für Kitodo 3.x am Beispiel 3.3.1 auf 3.4.1
(gerne ergänzen oder korrigieren)
Ein Erfahrungsbericht/Log der UB Erlangen-Nürnberg
Der Versionssprung 3.3.1 zu 3.4.1 ist relativ umfangreich, da viele Abhängigkeiten ebenfalls auf eine neuere Version geupdatet werden müssen. Bei Updates zwischen anderen Versionen können einige Schritte entfallen
Ausgeführt auf einem Ubuntu 18.04
-
Tomcat 8 stoppen
-
Tomcat 8 deinstallieren
-
Java 8 deinstallieren
-
Elasticsearch deinstallieren
- den alten Index löschen unter /var/lib/elasticsearch/nodes
-
Elasticsearch 7 nach Anleitung installieren: https://github.com/kitodo/kitodo-production/wiki/Installationsanleitung-f%C3%BCr-Kitodo.Production-3.4#5-elasticsearch-installieren
-
Java 11 installieren (headless jre genügt.)
-
Tomcat 9 installieren
- Sofern SSL/HTTPS erwünscht:
- User tomcat9 der gruppe ssl-certs hinzufügen (für Zugriff auf /etc/ssl/private)
- Port-Freigaben/Blocks überprüfen:
sudo iptables -L -n -v
- In /var/lib/tomcat9/conf/server.xml Abschnitt für https hinzufügen
- Tomcat erlauben, auf
/usr/local/kitodo
zuzugreifen. Dazusudo systemctl edit tomcat9.service
und eintragen:[Service] ReadWritePaths=/usr/local/kitodo
- Sofern SSL/HTTPS erwünscht:
-
Mysql-Updates einspielen
- Liste der DB-Updates unter https://github.com/kitodo/kitodo-production/blob/kitodo-production-3.4.1/Kitodo-DataManagement/src/main/resources /db/migration/ mit in Kitodo vorhandenen Updates vergleichen
- Wenn auf die Branches/Tags der verwendeten Versionen zugegriffen wird, kann ermittelt werden, welche SQL-Updates für das Update einzuspielen sind.
- hier: V2_107__Add_authorities_for_upload_and_delete_media.sql neu hinzugekommen
- ermittelte Dateien in die DB einspielen: Mittels Befehl
mysql --user xxx -p kitodo < Vxxx.sql
- Eingespielte Updates in der Tabelle flyway_schema_history händisch eintragen: diese Tabelle sollte händisch gepflegt werden, da die SQL-Updates keine Einträge vornehmen, die Tabelle aber den Überblick stark erleichtert.
- Liste der DB-Updates unter https://github.com/kitodo/kitodo-production/blob/kitodo-production-3.4.1/Kitodo-DataManagement/src/main/resources /db/migration/ mit in Kitodo vorhandenen Updates vergleichen
-
Kitodo 3.4.1 -war deployen als kitodo##3.4.1.war (## macht, dass alles danach im URL-Pfad ignoriert wird, also die Versionnummer)
- War-Datei downloaden, hier: von https://github.com/kitodo/kitodo-production/releases/tag/kitodo-production-3.4.1
- unter /var/lib/tomcat9/webapps platzieren
- In WEB-INF/classes/kitodo-config.properties ändern: (optional)
- numberOfMetaBackups=0
-
Die Kitodo-Module müssen extra geupdatet werden:
- Die entsprechende *config_modules.zip-Datei des Releases downloaden, extrahieren und die Jars im Verzeichnis modules in das Verzeichnis /usr/local/kitodo/modules kopieren.
- Die Alten jars ggf. löschen
-
Unter /usr/local/kitodo müssen Verzeichnisse und Dateien evtl. neuem User/Group zugeordnet werden: Tomcat 8 hatte User/Group tomcat8/tomcat8, Tomcat9 hingegen tomcat/tomcat.
- Betrifft insbesondere metadata-Verzeichnis und alle Verzeichnisse und Dateien darin.
- Befehl
sudo chown -R tomcat:tomcat metadata
o.ä.
-
Elasticsearch Index neu bauen
- ggf. jeden Index einzeln aufbauen
- Troubleshoot: Wenn die Indexierung von Vorgängen hängen bleibt, dann zunächst einen Vorgang anlegen und danach für Vorgänge die "Komplette Indexierung starten" (s. Mail von Frau Huber in Kitodo-Mailingliste vom 21.01.2022)
- ggf. Tomcat neu starten