Troubleshooting

Troubleshooting

🇫🇷 Cette page est également disponible en français : fr_Troubleshooting

Common issues encountered when deploying and running VIVO on Azure Marketplace.

Run the automated diagnostic first. The make diag command checks all services, firewall rules, TLS certificate, Solr, SPARQL endpoint, and logs in a single pass from your workstation. → See Post-Deployment-Verification#automated-diagnostic for setup and usage.

---

Deployment fails — VIVO_LANGUAGES: unbound variable

Symptom:

VIVO_LANGUAGES: unbound variable
cloud-final.service: Failed

Cause: The VM was created outside of the Marketplace deployment template — the required configuration parameters were never injected.

Fix: Delete the VM and redeploy from the Azure Marketplace offer page using the standard deployment template.

---

SSH — UNPROTECTED PRIVATE KEY FILE

Symptom:

Permissions 0777 for 'key.pem' are too open.
bad permissions: ignore key

Cause: The key file is on a Windows/NTFS filesystem (e.g. /mnt/c/...). chmod has no effect there.

Fix:

cp /mnt/c/Users/<YourName>/Downloads/your-key.pem ~/.ssh/
chmod 600 ~/.ssh/your-key.pem
ssh -i ~/.ssh/your-key.pem azureuser@<public-ip>

---

Deployment error — osDisk.diskSizeGB too small

Symptom:

"code": "OperationNotAllowed",
"message": "The specified disk size 64 GB is less than the size of the corresponding disk in the VM image: 256 GB."

Cause: The deployment template from a previous offer version set a disk size smaller than the image requires. This has been fixed.

Fix: Redeploy using the current offer version from the Azure Marketplace.

---

Deployment error — linuxConfiguration.ssh.publicKeys.path invalid

Symptom:

"code": "InvalidParameter",
"target": "linuxConfiguration.ssh.publicKeys.path"

Cause: adminUsername was left empty, producing path /home//.ssh/authorized_keys.

Fix: Ensure adminUsername is filled in (default: azureuser).

---

VIVO is accessible but shows default example.org namespace

Cause: Deployment parameters (vivoNamespace, vivoAdminEmail) were left at their default values.

Fix: Redeploy with your institution's values, or manually update runtime.properties. See Configuring-VIVO.

---

Browser security warning — certificate not trusted

Symptom: Firefox/Chrome shows "Potential Security Risk" or "Your connection is not private" for the FQDN.

Cause: certbot failed to obtain a Let's Encrypt certificate during first boot.

Diagnose:

sudo grep -i certbot /var/log/vivo-first-boot.log
sudo cat /var/log/letsencrypt/letsencrypt.log | tail -30

Fix: Run certbot manually — see HTTPS-TLS-Certificate.

---

Services status check

systemctl status tomcat solr nginx
sudo journalctl -u tomcat --no-pager -n 50
sudo tail -100 /opt/tomcat/logs/catalina.out

---

Capability Map is empty — JSONP blocked by MIME type

Symptom:

The VIVO Capability Map at /vis/capabilitymap loads its frame but shows no nodes, even after sample data has been loaded and Solr contains 400+ documents. The browser console shows:

La ressource à l'adresse /visualizationAjax... a été bloquée en raison d'un type MIME
(« text/html ») incorrect (X-Content-Type-Options: nosniff)

or in English:

The resource at /visualizationAjax... was blocked due to MIME type ("text/html") mismatch
(X-Content-Type-Options: nosniff)

Cause:

VIVO's /visualizationAjax endpoint returns Content-Type: text/html for all responses, including JSONP (where the body is JavaScript of the form ipretResults({...})). Nginx applies X-Content-Type-Options: nosniff globally. Browsers comply with the nosniff directive and block execution of the JSONP callback, resulting in an empty map.

Step 1 — Verify the upstream data is present

Before fixing nginx, confirm the backend is returning data:

curl -sk "https://<fqdn>/visualizationAjax?vis=capabilitymap&query=Rhetoric&callback=ipretResults&noCacheIE=1" | head -c 200

Expected output (JSONP):

ipretResults({"researchers":[...], "researchAreas":[...]})

If the output is empty HTML, the sample data was not loaded — see Loading-Sample-Data.

Step 2 — Check the Content-Type header

curl -sk -I "https://<fqdn>/visualizationAjax?vis=capabilitymap&query=Rhetoric&callback=ipretResults&noCacheIE=1" \
  | grep -i content-type

• Returns text/html → nginx fix required (see Step 3)
• Returns application/javascript → nginx is already fixed, check browser console for other errors

Step 3 — Apply the nginx fix

Add a dedicated location /visualizationAjax {} block inside each server { listen 443 ... } block in /etc/nginx/conf.d/vivo.conf:

# JSONP fix — VIVO returns text/html for /visualizationAjax
location /visualizationAjax {
    proxy_pass         http://127.0.0.1:8080;
    proxy_set_header   Host              $host;
    proxy_set_header   X-Real-IP         $remote_addr;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto https;
    proxy_read_timeout 300s;
    proxy_connect_timeout 60s;
    proxy_hide_header  Content-Type;
    add_header Content-Type              "application/javascript; charset=UTF-8" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"   always;
    add_header X-Frame-Options           "SAMEORIGIN"                            always;
    add_header Referrer-Policy           "strict-origin-when-cross-origin"       always;
}

Why no X-Content-Type-Options: nosniff here? When a location block defines any add_header directive, it replaces all add_header directives inherited from parent blocks (nginx inheritance rule). The block above intentionally omits nosniff to allow the JSONP Content-Type: application/javascript to be accepted by the browser. All other security headers (HSTS, X-Frame-Options, Referrer-Policy) are explicitly repeated to preserve the security posture.

After editing, validate and reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Re-run the Step 2 check — content-type: application/javascript; charset=UTF-8 confirms the fix is active.

This fix is included in the Packer image template (packer/provisioners/04-configure-nginx.sh) and the Docker nginx config (docker/nginx/vivo.conf) as of commit f92ba3f. New deployments from those sources are not affected.