Issues with Sonarqube RPM on RHEL/CentOS 7.x

[thjo...@gmail.com]

Wanted to report some issues I'd had. I've sorted them out, but since some of them didn't directly yield to google-searches, thought it worth posting here...

At any rate, some of our developers requested installation of Sonarqube. We deploy all of our tools/services onto hardened EL7 hosts — typically CentOS but sometimes RHEL. Currently, we're doing everything on EL 7.4.

Started by following the official(?) installation instructions. Followed the links to the "native packages". After installing the RPM, tripped over a couple things:

• The RPM only includes legacy-init files, not systemd unit files. Worked around this.
• Sonarqube doesn't like to run if your hardening puts the noexec attribute onto its preferred filesystem, /tmp. Presumably, this is true of any filesystem it would use for a temp-dir. Worked around this, as well.

Work around for the first bullet was to create a systemd service-definition:

[Unit]

Description=SonarQube

After=network.target network-online.target

Wants=network-online.target

[Service]

ExecStart=/opt/sonar/bin/linux-x86-64/sonar.sh start

ExecStop=/opt/sonar/bin/linux-x86-64/sonar.sh stop

ExecReload=/opt/sonar/bin/linux-x86-64/sonar.sh restart

Group=sonar

PIDFile=/opt/sonar/bin/linux-x86-64/SonarQube.pid

Restart=always

RestartSec=30

LimitNOFILE=65536

User=sonar

Type=forking

[Install]

WantedBy=multi-user.target

Initially, I had omitted the Group=, User= and LimitNOFILE= options. However, upon initial startup, had found a couple of things that required their presence - all ElastiCache-related. Elasticache will toss a file-descriptor error absent the LimitNOFILE= option. If you get further into things, ElastiCache will also refuse to start if one attempts to start it as root. Absent the Group= and User= options, Sonarqube defaults to starting as root and, in turn, attempts to start ElastiCache as root. I could have set the RUN_AS_USER parameter in the RPM-provided sonar.sh file, but that seemed ill-advised (since it would notionally get overwritten if one did a yum update). Also seemed odd that the RPM creates a sonar user and installs everything as that user, but doesn't set an appropriate RUN_AS_USER parameter-value, but, "whatevs". 

Also had to add an /etc/sysctl.d/sonarqube file to set an acceptable vm.max_map_count value. That, however, was adequately documented ...It just seems like just including such in the RPM would make sense. Again, "whatevs".

Last issue I had was related to trying to run on a hardened system. The usual problems posed by FIPS-mode and SELinux being set to Enforcing actually didn't cause problems — at least none that have been reported to me. What caused problems was my /tmp directory having the noexec mount-option set on it. This prevente JNA from starting up - and a whole host of other things failing that prevented Elasticache from coming online. Googling about led me to setting:

sonar.search.javaAdditionalOpts=-Djava.io.tmpdir=/var/tmp/elasticsearch

In my sonar.properties file. This might be something good to have in the compatibility/preparation documentation. Would have also been good if I'd have been able to set the java.io.tmpdir to /var/run/elasticache. However, having set the systemd service-definition's User option to `sonar` seems to preclude that: is there a way to start Sonarqube as root but have it spawn its subprocesses as a different user (presumably sonar)?

[G. Ann Campbell]

Hi,

It's very kind of you to feed your lessons back into the community!

For the record, the RPM packages aren't (quite) official; they're maintained by a SonarSourcer in his free time. However, we we're looking at making them official "soon" and I'm sure we'll feed your reports into that process.

Thx!

Ann