Configure sonar to write data outside of SONAR_HOME

Suggest new features
1

Can we have runtime data written outside of SONAR_HOME? And loading custom configuration outside of SONAR_HOME as well.

Possible use cases

  • docker container
  • per user configuration with sonar installed by root

Preferably sonar can support an environment variable named SONAR_BASE, which defaults to SONAR_HOME, but can be customized by the user, so that when specified, sonar would load configuration from there and write runtime data there as well, including logs, pid file etc.

A good example is Apache Tomcat which provides CATALINA_HOME and CATALINA_BASE for exactly the same purpose.

2

Hi,

Welcome to the community!

You can (and probably should in a production environment) configure storing your ES indices somewhere else. Additionally, you’re supposed to create volumes for data, extensions and logs for Docker. Could you clarify what you feel is missing?

 
Thx,
Ann

3

Hi, Ann,

Thank you for looking into this. The problem is in the server installation guide, https://docs.sonarqube.org/latest/setup/install-server/
It’s required to modify the files inside $SONAR_HOME, specifically $SONARQUBE-HOME/conf/sonar.properties

Edit $SONARQUBE-HOME/conf/sonar.properties to configure …

What needed is to be able to run sonar from a readonly filesystem, for that we need a way to tell SONAR to be able to read sonar.properties and other configuration files from a place outside of SONAR_HOME, as well as the files sonar would write to, at least but not limited to data files. logs, pid files etc.

4

Hi,

I believe everything in sonar.properties can be set via env vars.

 
Ann

5

Hi, Ann,

Thanks, I’ve read that, and I have tried setting SONAR_PATH_TEMP, but that doesn’t work, sonar console still says <SONAR_HOME>/temp is used, see the output below:

$ export SONAR_PATH_TEMP=/var/tmp/sonar

$ sonar console
Running SonarQube…
wrapper | → Wrapper Started as Console
wrapper | Launching a JVM…
jvm 1 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
jvm 1 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
jvm 1 |
jvm 1 | 2020.09.24 08:56:16 INFO app[o.s.a.AppFileSystem] Cleaning or creating temp directory /usr/local/Cellar/sonarqube-lts/7.9.4/libexec/temp
jvm 1 | 2020.09.24 08:56:16 INFO app[o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
…

BTW, I don’t see SONAR_PATH_TEMP used anywhere in the source, except one reference in the manual, anything I missed?
See: https://github.com/SonarSource/sonarqube/search?q=SONAR_PATH_TEMP

7

Hi @ryenus

could you tell us a little more about the environment that you are using? i just tried to reproduce it with one of our docker images and for me it looks like this functionality is already in place and working fine, so i would guess if it is not working for you then there might be a environment that we didn’t think of or something is not correct with your setup.

docker run -it -p 9000:9000 -e SONAR_PATH_TEMP=/tmp/sonarqube/ --name=sonarqube-test sonarqube:8.4-community

2020.09.24 14:07:14 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /tmp/sonarqube
2020.09.24 14:07:14 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2020.09.24 14:07:14 INFO  app[][o.s.a.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch
2020.09.24 14:07:15 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
8

Hi, Tobias,

Thank you for looking into this, possibly because I’m using sonar 7.9.4 LTS version?

For details please refer to https://github.com/Homebrew/homebrew-core/pull/60319/

BTW, if you know tomcat and how CATALINE_BASE works, then it would be much
easier to understand the motivation.

9

Hi @ryenus ,

the last LTS did not have real docker support, so yeah this environment variable is not available there. For 7.9.4 it would be:

docker run -it -p 9000:9000 sonarqube:7.4-community -Dsonar.path.temp=/tmp/sonarqube/

2020.09.25 05:59:34 INFO  app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /tmp/sonarqube
2020.09.25 05:59:34 INFO  app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2020.09.25 05:59:34 INFO  app[][o.s.a.p.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch -Epath.conf=/tmp/sonarqube/conf/es
2020.09.25 05:59:34 INFO  app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running

i looked into the usage of CATALINE_BASE and CATALINE_HOME and for me it seems like this would only make sense if there were multiple applications using the same tomcat server, but we embed tomcat into sonarqube so there should not be another application running.
I also had a look at the thread you are referring to and what i got from this thread is that there are tests failing because sonarqube is writing into its own install directory?

Maybe i can explain the reasoning behind this:
we are currently only releasing a zip file and docker images. the zip contains everything you need in order to run sonarqube on your system except java, which makes it great for shipping to various distributions and operating systems. we also leave you the option to not use sonar.sh/bat start but to wrap the init system of your choice around lib/sonar-application-7.9.4.jar so you can redirect the log output somewhere else. you could even create a symlink to another location for the data that is bothering you and your filesystem supports symlinks.

all in all i would say it makes very little sense to move away from this centralized approach only because of test failures in one package managers test even thou it is stated that sonar starts anyway.

Hope i could answer your question