Dépannage¶

Plateforme	Fichier de journal
Linux	`/var/log/drovio-server/drovio-server.log`
Windows	`C:\ProgramData\Drovio\Drovio Server\Logs\drovio-server.log`

Le fichier de journal est toujours le premier endroit où regarder. Chaque section ci-dessous vous indique quoi y chercher.

Le panneau d'administration est injoignable¶

Vérifiez que le service tourne. Voir Démarrer et arrêter le service pour votre plateforme. S'il ne tourne pas, le journal vous dit pourquoi.
Vérifiez le port. Par défaut, Drovio Server écoute sur le port 8090 en HTTP, ou sur celui défini par https_port quand HTTPS est activé. Assurez-vous qu'aucun autre processus n'occupe ce port.
Vérifiez l'accessibilité. Si vous accédez au panneau depuis une autre machine, vérifiez que l'hôte répond au ping et qu'aucun pare-feu ne bloque le port.

L'application Drovio ne se connecte pas¶

L'application Drovio a besoin de l'URL définie dans http.url. Si elle est erronée ou injoignable depuis le réseau du client, l'application affiche une erreur de connexion.

Vérifiez que l'URL résout bien vers le serveur et que le port est ouvert.
Si HTTPS est activé, assurez-vous que la chaîne de certificats complète est dans le magasin de clés. Un certificat intermédiaire manquant en est la cause la plus fréquente : les navigateurs peuvent le tolérer, l'application Drovio non. Voir Activer HTTPS, étape 5.

Erreurs de connexion à la base de données¶

Le journal affiche Failed to start Drovio Server ou des échecs de requêtes peu après le démarrage.

Vérifiez que PostgreSQL tourne et qu'il est joignable depuis le serveur.
Contrôlez database.host, database.port, database.name et les identifiants dans la configuration.
Si vous utilisez ssl_mode en verify-ca ou verify-full, vérifiez que le chemin du certificat d'autorité est correct.
En haute disponibilité, vérifiez que la somme des tailles de pool de toutes les instances ne dépasse pas max_connections côté PostgreSQL.

Certificat HTTPS refusé¶

Après l'activation de TLS, l'application Drovio ou un navigateur refuse la connexion.

openssl s_client -connect your_hostname:443 -showcerts </dev/null

La sortie doit montrer votre certificat et le certificat intermédiaire. Si l'intermédiaire manque, réimportez la chaîne complète. Voir Activer HTTPS.

La ligne de journal SSL certificate reloading has failed signifie que SIGUSR2 a bien été reçu mais que le magasin de clés n'a pas pu être lu. Le certificat précédent reste actif.

L'authentification SSO échoue¶

Le journal contient Could not authenticate user (SSO) ou Can't build SSO configuration.

URL de callback non concordante. Le redirect URI déclaré auprès de votre fournisseur d'identité doit correspondre exactement : https://votre-serveur/sso/auth/callback/saml en SAML ou https://votre-serveur/sso/auth/callback/oidc en OIDC. Voir SSO.
Métadonnées du fournisseur d'identité injoignables. Si idp_metadata_path désigne une URL, le serveur doit pouvoir l'atteindre au démarrage. Un fichier local évite cette dépendance.
SAML et OIDC activés en même temps. Un seul peut l'être. Le journal indique SAML and OIDC can't be both enabled.

L'authentification LDAP échoue¶

Le journal préfixe chaque échec LDAP par sa cause :

Message de journal	Ce qu'il faut vérifier
`service account bind failed`	`service_account_dn` et le mot de passe
`search failed`	`base` et `search_filter`
`user not found`	`base` et `search_filter`, trop restrictifs
`matched multiple entries`	`search_filter`, trop large
`user bind failed`	Les identifiants de l'utilisateur ou l'état de son compte : désactivé, verrouillé, expiré

Si vous utilisez ldap:// plutôt que ldaps://, le journal avertit une fois que les identifiants circulent en clair. Préférez LDAPS sur le port 636, avec ca_certificate_path.

Toujours bloqué ?

Écrivez à support@drovio.com. Joindre le fichier de journal accélère considérablement le diagnostic.