From: Omar S. <Oma...@oe...> - 2021-12-17 16:37:20
|
Thanks for these instructions! Just two additions: Please remember that the 4.x series broke binary compatibility of the database files with 4.4.0. That means you can only do a quick update without backup and restore from 3.0 to 4.3.1. After that you will most probably will need to do a dump and restore when upgrading. I co-maintain a repository meant for building exist container images from source. Maybe you can get some inspirations there for how to do this with your source. https://github.com/acdh-oeaw/docker-tools-environments/tree/master/existdb4x Due to the broken binary compatibility mentioned above this builds a patched version of 4.3.1. We upgraded log4j2 in several exist-db versions and nothing bad happened. They are in $EXIST_HOME/exist/lib/core/ So you can give that a try and replace them in your instance. If you run a security scanner like grype it may still report the vulnerability as there is a log4j1 to log4j2 translation jar also in /opt/exist/lib/user/. It is harmless itself but may hurt visibilty of instances that still need to be patched. I also maintain a patched container image for 5.3.0 and 5.2.0 These images are also different in the JRE they use (11) and the GC (Shenandoah). It is easy to change the latter if you don't trust it. https://hub.docker.com/r/acdhch/existdb/tags Am 17.12.2021 um 15:21 schrieb Juri Leino: > This also to the recently released versions of eXist-DB (5.3.1 and 4.8.0). > > It is good advise to do one of the following: > > *1. Upgrade to log4j 2.16.0* > > > Or *2. Remove the JNDI lookup class * > > > Stay safe, > Juri Best regards -- Mag. Ing. Omar Siam Austrian Center for Digital Humanities and Cultural Heritage Österreichische Akademie der Wissenschaften | Austrian Academy of Sciences Stellvertretende Behindertenvertrauensperson | Deputy representative for disabled persons Wohllebengasse 12-14, 1040 Wien, Österreich | Vienna, Austria T: +43 1 51581-7295 oma...@oe... |www.oeaw.ac.at/acdh |