Vulnerability scan warnings¶

Warnings display in a red banner at the top of the MSR web UI to indicate potential vulnerability scanning issues.

Warning	Cause
Warning: Cannot perform security scans because no vulnerability database was found.	Displays when vulnerabilty scanning is enabled but there is no vulnerability database available to MSR. Typically, the warning displays when a vulnerability database update is run for the first time and the operation fails, as no usable vulnerability database exists at this point.
Warning: Last vulnerability database sync failed.	Displays when a vulnerability database update fails, even though there is a previous usable vulnerabilty database available for vulnerability scans. The warning typically displays when a vulnerability database update fails, despite successful completion of a prior vulnerability database update.

Note

The terms vulnerability database sync and vulnerability database update are interchangeable, in the context of MSR web UI warnings.

Note

The issuing of warnings is the same regardless of whether vulnerability database updating is done manually or is performed automatically through a job.

MSR undergoes a number of steps in performing a vulnerability database update, including TAR file download and extraction, file validation, and the update operation itself. Errors that can trigger warnings can occur at any point in the update process. These errors can include such system-related matters as low disk space, issues with the transient network, or configuration complications. As such, the best strategy for troubleshooting MSR vulnerability scanning issues is to review the logs.

View the logs for an online vulnerability database update¶

Online vulnerability database updates are performed by a jobrunner container, the logs for which you can view through a docker CLI command or by using the MSR web UI

CLI command:
```
docker logs <jobrunner-container-name>
```
MSR web UI:

Navigate to System > Job Logs in the left-side navigation panel.

View the logs for an offline vulnerability database update¶

The MSR vulnerability database update occurs through the dtr-api container. As such, access the logs for that container to ascertain the reason for update failure.

Obtain more log information¶

If the logs do not initially offer adequate detail on the cause of vulnerability database update failure, you can display additional logs by setting MSR to enable debug logging.

MSR Operator

Use MSR Operator to enable and disable debug logging.

Edit the custom resource manifest to enable and disable debug logging. For example:
```
spec:
  logLevel: 'debug'
```

Apply the changes to the custom resource:

kubectl apply -f cr-sample-manifest.yaml

Verify completion of the reconciliation process for the custom resource:

kubectl get msrs.msr.mirantis.com
kubectl get rethinkdbs.rethinkdb.com

Helm chart

Use Helm to enable and disable debug logging. For example:

helm upgrade --reuse-values --set logLevel=debug [RELEASE] [CHART]

Swarm

For Swarm deployments, update the log level for each service:

docker service update msr_msr-api-server --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-garant --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-jobrunner --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-nginx --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-notary-server --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-notary-signer --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-registry --env-add MSR_LOG_LEVEL=debug
docker service update msr_msr-scanningstore --env-add DEBUG=true