Distribuzione di omnidb-server
Nota: a partire dalla riscrittura della versione 3.6.x, omnidb-server è un unico binario
nativo (niente più coppia separata webserver/websocket-server, niente Django/CherryPy/Tornado) che risponde
da solo a ogni richiesta su un’unica porta, usando il long-polling invece dei websocket per
gli aggiornamenti in background di query/console/monitoraggio. Non esiste più nemmeno un file di
configurazione o un supporto TLS integrato — tutto viene impostato tramite flag da riga di comando, ed eventuale
terminazione TLS deve essere gestita da un reverse proxy posto davanti al server.
Opzioni della riga di comando
Usage: omnidb-server [options]
Options:
-A, --app run in desktop app mode (always binds loopback-only,
regardless of -H)
-H HOST, --host=HOST listening address (default: 127.0.0.1)
-p PORT, --port=PORT listening port (default: an OS-chosen free port)
-d HOMEDIR, --homedir=HOMEDIR
home directory containing the omnidb.db database and
the temp folder used for exported files
-
-Hspecifica l’indirizzo su cui rimanere in ascolto. Il valore predefinito è127.0.0.1(solo loopback) — passa0.0.0.0per accettare connessioni da altre macchine, oppure l’indirizzo di un’interfaccia specifica. -
-pspecifica la porta su cui rimanere in ascolto, usata nell’URL del browser quando si accede direttamente a OmniDB. Se omessa, il sistema operativo sceglie una porta libera e la stampa su stderr all’avvio. -
-dpermette di scegliere la cartella che contieneomnidb.db(il database dell’applicazione) e la cartellatempusata per i file esportati. Con questa opzione è possibile eseguire più istanze diomnidb-server, ciascuna puntando a una directory diversa — utile per le distribuzioni Docker in cui si monta un volume in quella posizione.
Nota sulla sicurezza: un server avviato con -H impostato su un valore diverso da
loopback non dovrebbe mai essere avviato anche con -A/--app — il link di
auto-login desktop generato da quella modalità è pensato per essere raggiungibile solo localmente, quindi
-A forza sempre l’ascolto su loopback indipendentemente da -H, ignorandolo completamente
piuttosto che rischiare questa combinazione.
Vediamo come distribuire omnidb-server in diversi scenari:
Distribuzione diretta di OmniDB
Eseguire omnidb-server con -H 0.0.0.0 (o un’interfaccia pubblica specifica) lo rende
direttamente raggiungibile da altre macchine — ma poiché non esiste un supporto TLS integrato,
questo significa HTTP semplice, non cifrato. Ciò non è consigliato per
qualsiasi utilizzo che vada oltre una rete locale affidabile: i cookie di sessione e i risultati delle query
viaggerebbero altrimenti in chiaro. Per qualsiasi cosa raggiungibile dalla rete internet più ampia, metti
davanti un reverse proxy con terminazione TLS (vedi sotto) invece di esporre
direttamente omnidb-server.
Distribuzione di OmniDB dietro un reverse proxy
L’approccio consigliato: esegui omnidb-server in ascolto solo su 127.0.0.1
(il valore predefinito, quindi -H può essere omesso) e lascia che un reverse proxy come
Nginx o
Caddy gestisca
la terminazione TLS e inoltri HTTP semplice localmente.
./omnidb-server -p 9000
Esempio di configurazione Nginx:
server {
listen 443 ssl;
listen [::]:443 ssl;
include snippets/ssl-domain.conf;
include snippets/ssl-params.conf;
server_name domain.org;
client_max_body_size 75M;
location / {
proxy_pass http://127.0.0.1:9000;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl https;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_http_version 1.1;
}
}
Poiché tutto (compresi gli aggiornamenti in background di query/console) viene servito tramite
long-polling HTTP semplice invece che con websocket, basta un unico blocco location /
che copra l’intera applicazione — non esiste più un percorso separato di upgrade
websocket o un pattern /wss da instradare in modo speciale.