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
-
-Hespecifica o endereço em que escutar. A predefinição é127.0.0.1(apenas loopback) — passe0.0.0.0para aceitar ligações de outras máquinas, ou o endereço de uma interface específica. -
-pespecifica a porta em que escutar, usada no URL do browser ao aceder diretamente ao OmniDB. Se omitida, o sistema operativo escolhe uma porta livre e imprime-a para o stderr ao iniciar. -
-dpermite escolher a pasta que armazena oomnidb.db(a base de dados da aplicação) e a pastatempusada para ficheiros exportados. Com esta opção é possível executar várias instâncias doomnidb-server, cada uma a apontar para uma pasta diferente — útil para implementações Docker onde se monta um volume nesse local.
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.