Hi!
The way AppSettingsLoaderImpl currently works binds the SonarQube “home” directory very tightly to the actual location of sonar-application.jar in a way that cannot be fooled even with symbolic links.
As a deployer, I want to unpack sonarcube-X.Y.Z.zip in a readonly location, for example /opt/sonarqube, and then be able to start an instance of sonarqube as an unprivileged user providing my own configuration file, data and log directory outside of /opt/sonarqube. This is currently impossible.
It should be easy enough to just make AppSettingsLoaderImpl.homeDir overridable from the command line, using, for example, a system property. Which I think would at least make it possible to provide your own private SonarQube home with symbolic links back to the actual files.
Hi Ann!
Yes, you’re right, in a docker/containerized environment it doesn’t really matter, so that’s not what I’m talking about.
It should be obvious to anyone familiar with unix-like environments as it is an very fundamental principle, but I guess it all boils down to the golden rule that you don’t mix binaries with configuration files, data and log files in the same directory tree.
There are numerous reasons why this is good practice, but I’ll try to explain a few of them;
Running SonarQube in multiple separate instances on the same system.
The use cases here are, for example;
Providing a set of separate SonarQube instances for different customers or departments
Spinning up a SonarQube instance as an unprivileged user for testing a sonarqube configuration
I can do this today, but I cannot share a common copy of the SonarQube distribution, each instance requires it’s own copy of the software for the simple and silly reason that each copy is hard coded to it’s own configuration file.
Updating to a new release
If I’m updating to a new SonarQube release I’d like to start from a fresh copy of the SonarQube distribution and not simply unzip the new release on top of what’s already installed. For instance, all the jar files under the lib directory tree have their version in the filename and will keep adding up with new releases. Simply a bad idea. Also, doing so would overwrite my sonar.properties file. I might also want to keep the previous installation untouched as a fallback in case anything goes wrong.
Now with my fresh copy of SonarQube I need to figure out which files I need to move over from the old copy. This might not be very hard, but if I knew that the installation directory is just a clean read-only copy of the distribution I wouldn’t have to worry about that at all, and it adds quite a bit of extra work if you’re automating it.
File permissions
SonarQube should (must?) be run as an unprivileged user. However that user needs write access to the temp, log, data and extensions directory. Many users would “solve” that problem by giving the unprivileged user ownership of the whole installation. This is bad security practice. In order to fix it properly you need to manually consider and tweak the permissions of each directory. Again, that is not anything that is necessarily very hard, but is something you ideally shouldn’t have to worry about.
Meeting packaging requirements
If anyone would like to make an official rpm, apt or whatever, package, this would have to be addressed in order to meet the packaging guidelines for those platforms.
Note that I’m not suggesting that you should change the way it is deployed out-of-the-box. I simply think it would be nice if it would be possible to deploy it in a (my opinion) more sane way without having to patch the code.
To be clear, you shouldn’t do this. You should unzip the new copy next to what’s already installed.
Yep. Part of why the new version should be next to not on top of
Ibid
Ehm… none.
What we recommend is that you re-install community plugins from scratch. Your point about leaving an intact previous version for fallback is one reason. Version compatibility is another; sometimes you need to bump the plugin version when you bump the SonarQube version.
And for the configuration, we recommend that you re-configure the new copy manually*
Yes. Must.
If you choose to configure that, then yes, SonarQube needs full access to the directories it’s supposed to use operationally.
…Or create subdirs?
Again, that’s if you choose to set external data & temp dirs.
Thanks for your input. I hope my responses don’t come across as argumentative. I’ll be honest & say I don’t remember us ever getting this kind of feedback on the packaging & I wanted to answer a few points to make sure your take isn’t based on misunderstandings.
Ann
*To be fair, that very old recommendation is from a time when the config file changed occasionally. It basically never does anymore & you’re probably safe just making a copy & plopping it into your new install
I hope my responses don’t come across as argumentative
They do, actually. Note that I was simply trying (not very successfully, it seems) to explain why separation is a very well established rule in the *nix community, using sonarqube as an example. I’m not saying it’s the only way to do it.
So let’s not get lost in details here. As you state, you can configure the location of data and temp, so let’s focus on the configuration file (i.e. sonar.properties) itself. How can I specify an alternate sonar.properties file?
