Risoluzione dei problemi¶

Piattaforma	File di log
Linux	`/var/log/drovio-server/drovio-server.log`
Windows	`C:\ProgramData\Drovio\Drovio Server\Logs\drovio-server.log`

Il file di log è sempre il primo posto in cui guardare. Ogni sezione qui sotto vi indica che cosa cercarvi.

Il pannello di amministrazione è irraggiungibile¶

Verificate che il servizio giri. Vedere Avviare e arrestare il servizio per la vostra piattaforma. Se non gira, il log vi dice perché.
Verificate la porta. Per impostazione predefinita, Drovio Server ascolta sulla porta 8090 in HTTP, oppure su quella definita da https_port quando HTTPS è attivato. Assicuratevi che nessun altro processo occupi quella porta.
Verificate la raggiungibilità. Se accedete al pannello da un'altra macchina, verificate che l'host risponda al ping e che nessun firewall blocchi la porta.

L'applicazione Drovio non si connette¶

L'applicazione Drovio ha bisogno dell'URL definito in http.url. Se è errato o irraggiungibile dalla rete del client, l'applicazione mostra un errore di connessione.

Verificate che l'URL risolva effettivamente verso il server e che la porta sia aperta.
Se HTTPS è attivato, assicuratevi che la catena di certificati completa sia nel keystore. Un certificato intermedio mancante ne è la causa più frequente: i browser possono tollerarlo, l'applicazione Drovio no. Vedere Attivare HTTPS, passaggio 5.

Errori di connessione alla base di dati¶

Il log mostra Failed to start Drovio Server oppure dei fallimenti di query poco dopo l'avvio.

Verificate che PostgreSQL giri e che sia raggiungibile dal server.
Controllate database.host, database.port, database.name e le credenziali nella configurazione.
Se usate ssl_mode con verify-ca o verify-full, verificate che il percorso del certificato dell'autorità sia corretto.
In alta disponibilità, verificate che la somma delle dimensioni dei pool di tutte le istanze non superi max_connections lato PostgreSQL.

Certificato HTTPS rifiutato¶

Dopo l'attivazione di TLS, l'applicazione Drovio o un browser rifiuta la connessione.

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

L'output deve mostrare il vostro certificato e il certificato intermedio. Se l'intermedio manca, reimportate la catena completa. Vedere Attivare HTTPS.

La riga di log SSL certificate reloading has failed significa che SIGUSR2 è stato ricevuto ma che il keystore non ha potuto essere letto. Il certificato precedente resta attivo.

L'autenticazione SSO fallisce¶

Il log contiene Could not authenticate user (SSO) oppure Can't build SSO configuration.

URL di callback non concordante. Il redirect URI dichiarato presso il vostro provider di identità deve corrispondere esattamente: https://vostro-server/sso/auth/callback/saml in SAML oppure https://vostro-server/sso/auth/callback/oidc in OIDC. Vedere SSO.
Metadati del provider di identità irraggiungibili. Se idp_metadata_path designa un URL, il server deve poterlo raggiungere all'avvio. Un file locale evita questa dipendenza.
SAML e OIDC attivati contemporaneamente. Uno solo può esserlo. Il log indica SAML and OIDC can't be both enabled.

L'autenticazione LDAP fallisce¶

Il log antepone a ogni fallimento LDAP la sua causa:

Messaggio di log	Che cosa verificare
`service account bind failed`	`service_account_dn` e la password
`search failed`	`base` e `search_filter`
`user not found`	`base` e `search_filter`, troppo restrittivi
`matched multiple entries`	`search_filter`, troppo ampio
`user bind failed`	Le credenziali dell'utente o lo stato del suo account: disattivato, bloccato, scaduto

Se usate ldap:// piuttosto che ldaps://, il log avverte una volta che le credenziali circolano in chiaro. Preferite LDAPS sulla porta 636, con ca_certificate_path.

Ancora bloccati?

Scrivete a support@drovio.com. Allegare il file di log accelera considerevolmente la diagnosi.