Question on format of environmental variables when upgrading from 7.8-developer to 8.4.1-developer via 7.9.6-community

  • 7.8-developer
  • Upgrade to 8.4.1-developer via 7.9.6-community
  • I’ve successfully upgraded my lab version using this path but I couldnt include the LDAP config in the deployment due to networking restrictions in my K8S lab cluster

Hey there,

I have a question on env variables for LDAP when upgrading sonarqube ( deployed in kubernetes)

My current helm chart for sonarqube in my prod cluster uses a config map to override the startup script and inject the database and LDAP configuration.

For upgrade in my lab I deleted this configmap from the helm chart and edited the deployment to use updated environmental variables as per this link

this worked fine when going via the 7.9.6-community version also

I wasnt able to test if those LDAP env variables will work when going via the 7.9.6-community version however as my lab cluster cant access my AD due to network restrictions

I cant find an equivalent link for the 7.9.6 version so thought I would check here.

One thing I did find that was unusual is that the link for 8.4.1 says that the Database variables for PostGres should start with SONAR_ . This wouldnt work for me though and it kept ignoring the variables and creating an embedded DB. I changed them to SONARQUBE_ and it worked fine

So my question is should the below work when upgrading to 7.9.6 and 8.4.1? or will I need to create a seperate helm for 7.9.6

          - name: SONAR_SECURITY_REALM
            value: LDAP
          - name: LDAP_BINDDN
                name: sonarqube-ldaps-secrets
                key: ldaps-username
          - name: LDAP_BINDPASSWORD
                name: sonarqube-ldaps-secrets
                key: ldaps-password
          - name: LDAP_URL
                name: sonarqube-ldaps-secrets
                key: ldaps-url
          - name: LDAP_USER_BASEDN
                name: sonarqube-ldaps-secrets
                key: ldaps-user-basedn
          - name: LDAP_USER_REQUEST
                name: sonarqube-ldaps-secrets
                key: ldaps-user-request
          - name: SONARQUBE_JDBC_URL
                name: sonarqube-pgsql-secrets
                key: pgsql-host
                name: sonarqube-pgsql-secrets
                key: pgsql-password
            value: {{ .Values.SonarQube.PgUser }}
            value: cn
            value: email
            value: "" 

Hi @DeirdreRodgers ,

the SONARQUBE_ notation is deprecated an was introduced with the first steps to support env vars in sonarqube. in the 8.x series they will still work, but are deprecated in favor of the SONAR_ prefix.

regarding your LDAP configuration, this should work if you are using our image and not overwrite the script, as the parsing of these env vars is handled in there. in the 7.x release circle the application did not have real support to read configuration from env vars, but this was implemented in the 8.x circle.

maybe you can take some inspiration from our helm chart when moving forward into the 8.x circle. 8.4 is btw eol. i’d target 8.9.1 LTS soon.

hope that clarifies things a bit :slight_smile:

Thank you @Tobias_Trabelsi :slight_smile:

Would that mean that when I do the first part of the upgrade to 7.9.6-community that it wont accept the LDAP variables as I’ve posted them above?

If so could I just leave them out just to get it to work so it upgrades the database and then reinsert them to upgrade to 8.4.1? Or if they arent supported do they just get ignored?

Yes thank you for the advice, i’m planning to upgrade to the very latest version in the next few months. Thanks for the helm chart

always happy to help :slight_smile:

no if you take a look at the for the 7.9.6 image, you will see the following line in there

if [[ "$envvar_key" =~ sonar.* ]] || [[ "$envvar_key" =~ ldap.* ]];

so everything that starts with SONAR or LDAP will be passed to the sonar-application.jar as a java parameter (e.g. -Dsonar.jdbc.username or -Dldap.url) and is therefore processed by SQ.

you don’t have to as stated above, but the DB migration is independent from these properties.

Thats great thanks for clarifying

Cool I was just concerned that if the LDAP variables werent accepted it might cause the sonarservice to crash before I could initiate the db migration step.

Thanks again for the support @Tobias_Trabelsi . It is much appreciated

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.