# Install the server

## Overview <a href="#overview" id="overview"></a>

This section describes a single-node SonarQube instance. For details on clustered setup, see [install-the-server-as-a-cluster](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/install-the-server-as-a-cluster "mention").

### Instance components <a href="#instance-components" id="instance-components"></a>

A SonarQube instance comprises three components:

![](https://152261287-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBmptmznn7RpPe5u7vdup%2Fuploads%2Fgit-blob-be7aaeb59f6c55b97c8e479f4e91255395447bb1%2F32797b61e4af27a9c9fd0fbb71c1773d37a85aad.png?alt=media)

SonarQube instance components

1. The SonarQube server running the following processes:
   * A web server that serves the SonarQube user interface.
   * A search server based on Elasticsearch.
   * The compute engine in charge of processing code analysis reports and saving them in the SonarQube database.
2. The database to store the following:
   * Metrics and issues for code quality and security generated during code scans.
   * The SonarQube instance configuration.
3. One or more scanners running on your build or continuous integration servers to analyze projects.

### Hosts and locations <a href="#hosts-and-locations" id="hosts-and-locations"></a>

For optimal performance, the SonarQube server and database should be installed on separate hosts, and the server host should be dedicated. The server and database hosts should be located on the same network.

All hosts must be time-synchronized.

## Installing the database <a href="#installing-the-database" id="installing-the-database"></a>

Several external [prerequisites-and-overview](https://docs.sonarsource.com/sonarqube-server/9.9/requirements/prerequisites-and-overview "mention") are supported. Be sure to follow the requirements listed for your database. They are real requirements not recommendations.

Create an empty schema and a `sonarqube` user. Grant this `sonarqube` user permissions to `create`, `update`, and `delete` objects for this schema.

<details>

<summary>Microsoft SQL Server</summary>

{% hint style="warning" %}
Collation **MUST** be case-sensitive (CS) and accent-sensitive (AS).

`READ_COMMITED_SNAPSHOT` **MUST** be set on the SonarQube database.
{% endhint %}

MS SQL database’s shared lock strategy may impact SonarQube runtime. Making sure that `is_read_committed_snapshot_on` is set to `true` to prevent SonarQube from facing potential deadlocks under heavy loads.

Example of query to check `is_read_committed_snapshot_on`:

```css-79elbk
SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name='YourSonarQubeDatabase';
```

Example of query to update `is_read_committed_snapshot_on`:

```css-79elbk
ALTER DATABASE YourSonarQubeDatabase SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;
```

**Encryption**

*If your Microsoft SQL Server doesn’t support encryption*, you must add `encrypt=false` to the JDBC URL connection string.

*If your Microsoft SQL Server requires encryption but* you don’t want SonarQube to validate the certificate, you must add `trustServerCertificate=true` to the JDBC URL connection string.

**Integrated security**

To use integrated security:

1. Download the [Microsoft SQL JDBC Auth 11.2.2 package](https://github.com/microsoft/mssql-jdbc/releases/download/v11.2.2/mssql-jdbc_auth.zip) and copy `mssql-jdbc_auth-11.2.2.x64.dll` to any folder in the path of the SonarQube host.
2. *If you’re running SonarQube as a Windows service*, make sure the Windows account under which the service is running has permission to connect your SQL server.
3. Ensure that `sonar.jdbc.username` or `sonar.jdbc.password` properties are commented out or SonarQube will use SQL authentication.

```css-79elbk
sonar.jdbc.url=jdbc:sqlserver://localhost;databaseName=sonar;integratedSecurity=true
```

**SQL authentication**

To use SQL authentication, use the following connection string. Also, ensure that `sonar.jdbc.username` and `sonar.jdbc.password` are set appropriately:

```css-79elbk
sonar.jdbc.url=jdbc:sqlserver://localhost;databaseName=sonar
sonar.jdbc.username=sonarqube
sonar.jdbc.password=mypassword
```

</details>

<details>

<summary>Oracle</summary>

If there are two SonarQube schemas on the same Oracle instance, especially if they are for two different versions, SonarQube gets confused and picks the first it finds. To avoid this issue:

* Either privileges associated to the SonarQube Oracle user should be decreased.
* Or a trigger should be defined on the Oracle side to automatically alter the SonarQube Oracle user session when establishing a new connection: `ALTER SESSION SET current_schema="MY_SONARQUBE_SCHEMA"`.

{% hint style="warning" %}
Oracle JDBC driver versions 12.1.0.1 and 12.1.0.2 have major bugs, and are not recommended for use with SonarQube ([**see more details**](https://groups.google.com/forum/#!msg/sonarqube/Ahqt1iarqJg/u0BVRJZnBQAJ)).
{% endhint %}

</details>

<details>

<summary>PostgreSQL</summary>

If you want to use a custom schema and not the default "public" one, the PostgreSQL `search_path` property must be set:

```css-79elbk
ALTER USER mySonarUser SET search_path to mySonarQubeSchema
```

</details>

## Installing SonarQube from the ZIP file <a href="#installing-sonarqube-from-the-zip-file" id="installing-sonarqube-from-the-zip-file"></a>

First, check the [prerequisites-and-overview](https://docs.sonarsource.com/sonarqube-server/9.9/requirements/prerequisites-and-overview "mention"). Then download and unzip the [distribution](https://www.sonarsource.com/products/sonarqube/downloads/) (do not unzip into a directory starting with a digit).

SonarQube cannot be run as `root` on Unix-based systems, so create a dedicated user account for SonarQube if necessary.

`<SONARQUBE_HOME>` (below) refers to the path to the directory where the SonarQube distribution has been unzipped.

### Setting access to the database <a href="#setting-access-to-the-database" id="setting-access-to-the-database"></a>

Edit `<SONARQUBE_HOME>/conf/sonar.properties` to configure the database settings. Templates are available for every supported database. Just uncomment and configure the template you need and comment out the lines dedicated to H2:

```css-79elbk
# Example for PostgreSQL with default "public" schema and default TCP port 5432
sonar.jdbc.username=sonarqube
sonar.jdbc.password=mypassword
sonar.jdbc.url=jdbc:postgresql://localhost/sonarqube
```

### Adding the JDBC driver <a href="#adding-the-jdbc-driver" id="adding-the-jdbc-driver"></a>

Drivers for the supported databases (except Oracle) are already provided. Do not replace the provided drivers; they are the only ones supported.

For Oracle, copy the JDBC driver into `<SONARQUBE_HOME>/extensions/jdbc-driver/oracle`.

### Configuring the Elasticsearch storage path <a href="#configuring-the-elasticsearch-storage-path" id="configuring-the-elasticsearch-storage-path"></a>

By default, Elasticsearch data is stored in `<SONARQUBE_HOME>/data`, but this is not recommended for production instances. Instead, you should store this data elsewhere, ideally in a dedicated volume with fast I/O. Beyond maintaining acceptable performance, doing so will also ease the upgrade of SonarQube.

Edit `<SONARQUBE_HOME>/conf/sonar.properties` to configure the following settings:

```css-79elbk
sonar.path.data=/var/sonarqube/data
sonar.path.temp=/var/sonarqube/temp
```

The user used to launch SonarQube must have read and write access to those directories.

### Starting the web server <a href="#starting-the-web-server" id="starting-the-web-server"></a>

The default port is `9000` and the context path is `/`. These values can be changed in `<SONARQUBE_HOME>/conf/sonar.properties`:

```css-79elbk
sonar.web.host=192.168.0.1
sonar.web.port=80
sonar.web.context=/sonarqube
```

Execute the following script to start the server:

* On Linux: `<SONARQUBE_HOME>/bin/linux-x86-64/sonar.sh start`
* On macOS: `<SONARQUBE_HOME>/bin/macosx-universal-64/sonar.sh start`
* On Windows: `<SONARQUBE_HOME>/bin/windows-x86-64/StartSonar.bat`

You can now browse SonarQube at [http://localhost:9000](http://localhost:9000/) (the default system administrator credentials are `admin`/`admin`).

### Adjusting the Java installation <a href="#adjusting-the-java-installation" id="adjusting-the-java-installation"></a>

By default, the scripts will use the Java executable available in the PATH. If there are multiple versions of Java installed on your server, you may need to explicitly define which version of Java is used.

It is possible to overwrite the default Java executable by setting the environmental variable `SONAR_JAVA_PATH`.

<details>

<summary>Linux</summary>

`export SONAR_JAVA_PATH="path/to/java_home/bin/java"`

</details>

<details>

<summary>Windows</summary>

`setx SONAR_JAVA_PATH "C:\Program Files\java_home\bin\java.exe"`

</details>

### Advanced installation features <a href="#advanced-installation-features" id="advanced-installation-features"></a>

* Running SonarQube as a service on [operating-the-server](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/configure-and-operate-a-server/operating-the-server "mention") or [Broken link](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/broken-reference "mention")
* Running SonarQube [operating-the-server](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/configure-and-operate-a-server/operating-the-server "mention")
* Monitoring and adjusting [monitoring](https://docs.sonarsource.com/sonarqube-server/9.9/instance-administration/monitoring "mention")

## Installing SonarQube from the Docker image <a href="#installing-sonarqube-from-the-docker-image" id="installing-sonarqube-from-the-docker-image"></a>

SonarQube docker images support running both on the `amd64` architecture and on `arm64`-based Apple Silicon.

We recommend using [Docker Engine](https://docs.docker.com/engine/) version 20.10 and above.

Follow these steps for your first installation:

1. Creating the following volumes helps prevent the loss of information when updating to a new version or upgrading to a higher edition:
   * `sonarqube_data`: contains data files, such as Elasticsearch indexes
   * `sonarqube_logs`: contains SonarQube logs about access, web process, CE process, and Elasticsearch
   * `sonarqube_extensions`: will contain any plugins you install and the Oracle JDBC driver if necessary.

Create the volumes with the following commands:

```css-79elbk
$> docker volume create --name sonarqube_data
$> docker volume create --name sonarqube_logs
$> docker volume create --name sonarqube_extensions
```

{% hint style="warning" %}
Make sure you’re using [**volumes**](https://docs.docker.com/storage/volumes/) as shown with the above commands, and not [**bind mounts**](https://docs.docker.com/storage/bind-mounts/). Using bind mounts prevents plugins from populating correctly.
{% endhint %}

Drivers for supported databases (except Oracle) are already provided. If you’re using an Oracle database, you need to add the JDBC driver to the `sonar_extensions` volume. To do this:

a. Start the SonarQube container with the embedded H2 database:

```css-79elbk
$ docker run --rm \
    -p 9000:9000 \
    -v sonarqube_extensions:/opt/sonarqube/extensions \
    <image_name>
```

b. Exit once SonarQube has started properly.

c. Copy the Oracle JDBC driver into `sonarqube_extensions/jdbc-driver/oracle`.

3\. Run the image with your database properties defined using the `-e` environment variable flag:

```css-79elbk
$> docker run -d --name sonarqube \
    -p 9000:9000 \
    -e SONAR_JDBC_URL=... \
    -e SONAR_JDBC_USERNAME=... \
    -e SONAR_JDBC_PASSWORD=... \
    -v sonarqube_data:/opt/sonarqube/data \
    -v sonarqube_extensions:/opt/sonarqube/extensions \
    -v sonarqube_logs:/opt/sonarqube/logs \
    <image_name>
```

For docker-based setups, environment variables supersede all parameters that were provided with properties. See [environment-variables](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/configure-and-operate-a-server/environment-variables "mention").

There is more information about installing and updating SonarQube plugins inside your Docker volume found on the [install-a-plugin](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/install-a-plugin "mention") page.

### Example Docker Compose configuration <a href="#example-docker-compose-configuration" id="example-docker-compose-configuration"></a>

{% hint style="info" %}

* Unless you intend to delete the database and start new when running your image , be careful not to use `-v` to `docker-compose down` and, be careful when running commands like `docker system prune` or `docker volume prune`; regardless if you use an `external: true` parameter, your database volumes will not persist beyond the initial startup and shutdown of SonarQube.
  {% endhint %}

If you’re using [Docker Compose](https://docs.docker.com/compose/), use the following example as a reference when configuring your `.yml` file. Click the heading below to expand the `.yml` file.

{% hint style="info" %}
The example below will use the latest version of the SonarQube Docker image. If want to use the LTA version of SonarQube, you need to update the example with the `sonarqube:lts-community` image tag.
{% endhint %}

<details>

<summary>Docker Compose .yml file example</summary>

```css-79elbk
version: "3"

services:
  sonarqube:
    image: sonarqube:community
    depends_on:
      - db
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: sonar
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
    ports:
      - "9000:9000"
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql:
  postgresql_data:
```

</details>

## Next steps <a href="#next-steps" id="next-steps"></a>

Once your server is installed and running, you may also want to [install-a-plugin](https://docs.sonarsource.com/sonarqube-server/9.9/setup-and-upgrade/install-a-plugin "mention"). Then you’re ready to begin [overview](https://docs.sonarsource.com/sonarqube-server/9.9/analyzing-source-code/overview "mention").

## Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

### Failed to connect to the marketplace via proxy <a href="#failed-to-connect-to-the-marketplace-via-proxy" id="failed-to-connect-to-the-marketplace-via-proxy"></a>

Double-check that settings for proxy are correctly set in `<SONARQUBE_HOME>/conf/sonar.properties`. Note that if your proxy username contains a backslash, then it should be escaped; a username `domain\user` in the file should look like this example:

```css-79elbk
http.proxyUser=domain\\user
```

For some proxies, the exception `java.net.ProtocolException: Server redirected too many times` might mean an incorrect username or password has been configured.

### Exception java.lang.RuntimeException: cannot run elasticsearch as root <a href="#exception-javalangruntimeexception-cannot-run-elasticsearch-as-root" id="exception-javalangruntimeexception-cannot-run-elasticsearch-as-root"></a>

SonarQube starts an Elasticsearch process, and the same account that is running SonarQube itself will be used for the Elasticsearch process. Since Elasticsearch cannot be run as root, that means SonarQube can’t be either. You must choose some other, non-root account with which to run SonarQube, preferably an account dedicated to the purpose.

### SonarQube DNS cache <a href="#sonarqube-dns-cache" id="sonarqube-dns-cache"></a>

When reporting Quality Gate status to DevOps platforms, SonarQube uses a DNS cache time to live policy of 30 seconds. If necessary, you can change this setting in your JVM:

```css-79elbk
echo "networkaddress.cache.ttl=5" >> "${JAVA_HOME}/conf/security/java.security" 
```

Please be aware that low values increases the risk of DNS spoofing attacks.

### Self Signed Certificates of DevOps platforms <a href="#self-signed-certificates-of-devops-platforms" id="self-signed-certificates-of-devops-platforms"></a>

When running in an environment where the DevOps platform or other related tooling is secured by self-signed certificates, the CA needs to be added to the java TrustStore of SonarQube.

<details>

<summary>For all recent scanners, a common SSL configuration</summary>

**A common configuration for all recent scanners**

We are aiming to simplify the SSL configuration for all scanners. This is a work in progress and not all scanners are updated, but we recommend always following those generic steps to be future-proof, and then look at each scanner-specific guidelines on top of it.

All scanners should support a PKCS #12 keystore containing the server or CA certificates to trust (a.k.a. the TrustStore).

The default location for the TrustStore is `$SONAR_USER_HOME/ssl/truststore.p12` (default value for SONAR\_USER\_HOME is \~/.sonar). This location can be overridden using the scanner property `sonar.scanner.truststorePath`

The default password for the TrustStore is `changeit`. This password can be overridden using the property `sonar.scanner.truststorePassword`

**SonarScanner for .NET version 9.2 and newer**

The SonarScanner for .NET 9.2+ does not support a certificate revocation list (CRL) when the issuing certificate authority is given via the TrustStore file. This means that revoked certificates will still be trusted when the issuing certificate is given via the TrustStore file.

You can still install the Certificate Authority certificate in the Windows Certmgr to have CRL support. To do this, please follow the instructions *For scanner versions 9.1 and earlier*.

</details>

<details>

<summary>For SonarScanner for .NET &#x3C; 9.2</summary>

**For scanner versions 9.1 and earlier**

Add the self-signed server certificate to the operating system TrustStore:

* On Linux and MacOS:
  1. Copy the self-signed server certificate to `/usr/local/share/ca-certificates`
  2. Run `sudo update-ca-certificates`
* On Windows: use [certutil](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil).\
  Example:

```css-79elbk
certutil -addstore -f "ROOT" <path/to/certificate>
```

*If you are using a SonarScanner for .NET version before v7.0*, the scanner invokes SonarScanner CLI and *you must add* the self-signed certificate to the Java TrustStore as explained below in *For SonarScanner for Maven, Gradle, CLI < 6.0*.

</details>

<details>

<summary>For SonarScanner for Maven, Gradle, CLI &#x3C; 6.0</summary>

**For SonarScanners Maven, Gradle, CLI 5.0.1 and earlier**

These scanners are still relying on the Java VM for the SSL configuration.

You can either:

* Insert your certificate in the default JVM TrustStore (something like `\jre\lib\security\cacerts`). To add the self-signed server certificate to the default TrustStore use the JVM tool keytool. The instructions depend on your operating system and you will find many resources online, such as [this one](https://www.ibm.com/docs/en/tnpm/1.4.2?topic=security-import-certificate-jre-keystore) for Linux.
* Provide a custom Java TrustStore by using the following properties:
  * `javax.net.ssl.trustStore`: path to the TrustStore file (pkcs12 format is recommended)
  * `javax.net.ssl.trustStorePassword`: password of the TrustStore.

{% hint style="warning" %}
These javax.net properties are JVM properties, not scanner properties. They should be passed using the `SONAR_SCANNER_OPTS` environment variable.

For example: `SONAR_SCANNER_OPTS="-Djavax.net.ssl.trustStore=C:/ssl/truststore.p12 -Djavax.net.ssl.trustStorePassword=changeit"`

On Windows, use forward slashes as path separators.
{% endhint %}

</details>

<details>

<summary>If running the scanner with Docker</summary>

There is no Docker image for the SonarScanner for .NET therefore, this section does not apply.

If you need to configure a self-signed certificate for the scanner to communicate with your SonarQube instance, the preferred way is to mount a folder containing a PKCS #12 file named `truststore.p12` (default password `changeit`) under `/opt/sonar-scanner/.sonar/ssl`.

If you have a PEM or DER certificate, you can use Keytool to generate the PKCS #12 keystore:

```css-79elbk
keytool -import -storetype PKCS12 -alias sonar -keystore truststore.p12 -file server.pem -storepass "<a password>"
```

**If running the scanner in Docker: use a mounted volume**

By default, the scanner expects the TrustStore password to be `changeit`. If you need to use a different password, inform the scanner using the `-Dsonar.scanner.truststorePassword=<YOUR PASSWORD>` property.

```css-79elbk
docker pull sonarsource/sonar-scanner-cli
docker run \
    --rm \
     -v ${DIR_WITH_TRUSTSTORE_DOT_P12}:/opt/sonar-scanner/.sonar/ssl \ 
    -v ${YOUR_CACHE_DIR}:/opt/sonar-scanner/.sonar/cache \
    -v ${YOUR_REPO}:/usr/src \
    -e SONAR_HOST_URL="http://${SONARQUBE_URL}" \
    sonarsource/sonar-scanner-cli \
    -Dsonar.scanner.truststorePassword=<a password> // Not needed if the default password is used
```

</details>

If you deploy SonarQube on Kubernetes using the official Helm Chart, you can create a new secret containing your required certificates and reference this via:

```css-79elbk
caCerts:
  enabled: true
  image: adoptopenjdk/openjdk11:alpine
  secret: your-secret
```