.NET

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

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.