Sonar.properties not being reflected on OCP

SonarQube Server / Community Build
1

I am attempting to deploy a customized version of SonarQube (8.3) on OpenShift (3.11) using this Helm Chart.

The chart correctly initializes the container (downloads and installs plugins and populated the conf/sonar.properties file, however, the properties set are not being reflected. Is there a command that I need to run to make the changes stick?

I tested this with. SMTP settings and the server did not pick them up. These are core settings in SQ, and there are a lot of settings that I need to set for plugins such as the OpenShift authentication plugin.

2

Hi,

Unless the properties were listed in sonar.properties originally, they’re not going to work for you. There are properties that are set via that config file and properties that are set via the UI. There aren’t (supposed to be - we’ve made a couple mistakes along the way) properties that can be successfully set in both places.

 
HTH,
Ann

3

Thanks for the response!

I do not want to change the configuration settings in the UI, rather I want to “spin” up an instance of SonarQube that is already customized with plugins and settings. The aforementioned Helm Chart successfully downloads and installs plugins, and writes properties to $SONARQUBE_HOME/conf/sonar.properties

This is a sample of what the sonar.properties file looks like:

sonar.auth.github.allowUsersToSignUp=false
sonar.log.console=true

4

@ganncamp We are also facing same issue. We can see that all the properties are available at conf/sonar.properties and they are applied successfully but SonarQube GUI is not reflecting it. Properties file has below lines

sonar.auth.oidc.allowUsersToSignUp=True
sonar.auth.oidc.clientId.secured=<Removed>
sonar.auth.oidc.clientSecret.secured=<Removed>
sonar.auth.oidc.enabled=True
sonar.auth.oidc.groupsSync.claimName=groups
sonar.auth.oidc.iconPath=/static/authoidc/openid.svg
sonar.auth.oidc.issuerUri=<Removed>
sonar.auth.oidc.loginButtonText=<Removed>
sonar.auth.oidc.loginStrategy=Preferred username
sonar.auth.oidc.loginStrategy.customClaim.name=upn
sonar.auth.oidc.scopes=openid email profile

We can see OIDC login screen with this configuration which is good. But when I login into SQ I cannot see configuration is enabled which is misleading.

image
image991Ă—589 31.7 KB

Are we doing something wrong here?

5

Hi,

Yes. You’re trying to set the values in sonar.properties instead of in the UI.

It’s supposed to be that things that are settable in sonar.properties aren’t settable via the UI and things that are settable via the UI aren’t settable in sonar.properties . If you copy property names from the UI and are able to successfully set them in sonar.properties you are exploiting a bug and cannot reasonably expect it to “work” 100%.

 
Ann

6

Hi @ganncamp, Trying to summarize & confirm my understanding. You mean to say that we shouldn’t be using sonar.properties for those configuration values which can be set using UI. Is that correct?

7

Hi @Rahul_Mahulkar,

So yes. That is correct.

 
Ann

8

As a follow up, I’ve just noticed this in the hardening list for 9.0:

SONAR-11818 - Allow only system settings to be used in sonar.properties

It may or may not get worked on this time, but eventually…

 
Ann

1 Like
9

Thank you @ganncamp

10

Hallo Ann,

Is there any progress or answers on this issue. The mismatch of the configured properties via a helm diagram and the information in the gui.
All the property keys I set in the values.yaml can be found when I get a download of the system info through the gui.
But some settings are not displayed in the GUI. Like the setting: From address in the General settings tab. The gui shows that you can use Key: email.from
Another email setting; Key: email.smtp_host.secured is correctly placed in the gui.
When I look in the postgres database, within the table properties, I can’t see some of these settings, but only the ones who are shown in the gui.

So how can it be that all the new property settings are in the system info report, and not in the database? Where does SonarQube keep these settings which are not in the database?

I can find all of the settings I placed in the Chart in the SONARQUBE_HOME/conf/sonar.properties file in the running service.

Please advise.

With regards,
Bert

11

Hi @meedel,

The ticket cited above hasn’t been fixed, so there’s no update.

In general, values settable through the UI should only be set via the UI and not via properties. The fact that this works in one or two isolated cases is purely accidental and if you use that, you’re exploiting a bug that is likely to change out from under you without notice.

Yes, that’s entirely expected. That value is only setable via the UI.

Well, it shows what the key is, and that’s a design flaw we’ve just never gotten around to correcting. IMO it shouldn’t because you can’t use the key to set the value via properties.

As I said, this works accidentally in a few, isolated cases. You’re exploiting a bug.

And there’s no reason not to set these values in the UI. They’re stored in the DB, so there’s no need to write them into your YAML files since they’re not ephemeral.

 
HTH,
Ann

13

Hallo Ann,

Thanks for your quick reply and your explanation on my questions.
I understand what your saying about the differences of setting property values.

But in our present production environment we place all of these settings through the api call using the same sonar key definitions.
And that works perfectly. The settings are shown in the gui as wel as placed in the database.
We never update settings through the gui.
Also the project permission templates and user rights are done through the api.

Now we want to deploy SonarQube on kubernetes using helm charts and placing the settings in the sonarProperties section of the chart.

Regards,
Bert

14

Hi Bert,

Why would that change how you set the values
Also, the values are still stored in the DB, so there’s no need to set them over and over; just reconnect to the same database. Your values will be there.

 
Ann

15

Hello Ann, sorry for my late response.
That is what I want to explain. Deploying SonarQube using helm charts, all of the settings I have defined are placed in SonarQube. When I download the system info I can see all these settings I needed, but some of them are not shown in the properties table of the database, and also not visable in the gui.

Bert

16

Hi,

Yes, that’s expected. They’re not supposed to.

That’s unexpected. You’re exploiting a bug. You need to set these values via the UI so they will be stored in the DB, and then you don’t have a subsequent need to re-set them.

 
HTH,
Ann

18

Sorry for bringing this old thread up, but this is something that bothers me in the way it works… There is a reason why we have the tools set up like Jenkins, RabbitMQ, Grafana, with 99% of the settings in IaC. For example, if I need to set up a Jenkins for a new team or project, I can configure everything in the YAML file, copy & paste, edit a few variables, and that’s it. However, if I want to set up a new instance of SonarQube, I have to configure the SAML authentication and other settings manually every time, which is highly inefficient.

Where can I suggest allowing to set up all the properties from the config file to work better in IaC?

19

Hi,

How often are you setting up new instances of SonarQube? The idea is that you set your configuration through the UI (or via scripted API calls) and it’s stored in the database. Subsequent restarts will reuse the data in the database with no need to reconfigure.

 
Ann

1 Like
20

How often is hard to say, but that’s also part of the problem because if it’s not so often it’s hard to remember all the steps, but scripted API calls could work, can you share an example? For example how to set the sonar.core.serverBaseURL.

Thanks!!

21

Hi,

The best way to master the API is to perform the desired action via the UI and eavesdrop to see which calls the UI made to accomplish the action.

You may also find this guide helpful.

 
Ann

1 Like