> Is there a recommended way for testing
> if the configuration is effective and the
> lookup is indeed disabled?
The log file for the container contains an entry for JVM arguments on startup, which should include
Dlog4j2.formatMsgNoLookups=true if fixed. This can be accessed by 'docker logs xxx' on the ElasticSearch container.
It'd be nice to have a test case, though - I tried pasting a test string from the web-based tool mentioned into the MediaWiki search box, but I am not sure if this is a suitable test.
FWIW, Docker doesn't make it easy to modify an existing container's environment for quick fixes without making a whole new one. Of course the "right" way is to recompose it. However, if for any reason you don't have files to hand,
and don't want to mess around with an overlay like https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay (which I'm not sure works; it depends on the version of log4j used), or don't want to switch containers, it seems possible to modify the environment
for existing ones directly.
I found the container ID for elasticsearch with 'docker ps', stopped the docker daemon with 'systemctl stop docker' (stopping the specific container is not enough), edited config.v2.json in /var/lib/docker/containers/xxx... such
that the ES_JAVA_OPTS had the additional option and then 'systemctl start docker' - judging by tail -n 50 of the log file in that directory, the environment variable was correctly set. Take that with a huge pinch of salt,
though; I'm not a docker expert. 😅
--
Laurence 'GreenReaper' Parry