.NET

Implementar o omnidb-server

Nota: desde a reescrita 3.6.x, o omnidb-server é um único binário nativo (sem o par separado de servidor web/servidor websocket, sem Django/CherryPy/Tornado) que responde a todos os pedidos por si próprio através de uma única porta, usando long-polling em vez de websockets para as atualizações em segundo plano de consultas/consola/monitorização. Também já não existe ficheiro de configuração nem suporte de TLS incorporado — tudo é definido através de flags de linha de comandos, e qualquer terminação de TLS tem de ser gerida por um proxy inverso à sua frente.

Opções de linha de comandos

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 de segurança: um servidor iniciado com -H definido como qualquer valor diferente de loopback nunca deve também ser iniciado com -A/--app — a ligação de início de sessão automático de ambiente de trabalho que esse modo gera destina-se apenas a ser acedida localmente, pelo que -A força sempre a vinculação a loopback independentemente de -H, ignorando-o por completo em vez de arriscar essa combinação.

Vejamos como implementar o omnidb-server em diferentes cenários:

Implementar o OmniDB diretamente

Executar o omnidb-server com -H 0.0.0.0 (ou uma interface pública específica) torna-o diretamente acessível a partir de outras máquinas — mas, como não existe suporte de TLS incorporado, isto significa HTTP simples, não encriptado. Isto não é recomendado para seja o que for além de uma rede local de confiança: os cookies de sessão e os resultados de consultas de outro modo viajariam sem qualquer proteção. Para qualquer coisa acessível a partir da internet em geral, coloque um proxy inverso com terminação TLS (ver abaixo) à frente, em vez de expor o omnidb-server diretamente.

Implementar o OmniDB atrás de um proxy inverso

A abordagem recomendada: execute o omnidb-server a escutar apenas em 127.0.0.1 (a predefinição, pelo que -H pode ser omitido) e deixe um proxy inverso como o Nginx ou o Caddy tratar da terminação de TLS e encaminhar HTTP simples para ele localmente.

./omnidb-server -p 9000

Exemplo de configuração do 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;
    }
}

Como tudo (incluindo as atualizações em segundo plano de consultas/consola) é servido através de long-polling HTTP simples em vez de websockets, basta um único bloco location / a cobrir toda a aplicação — já não existe um caminho separado de atualização para websocket nem um padrão /wss a encaminhar de forma especial.