.NET

Despliegue de omnidb-server

Nota: desde la reescritura 3.6.x, omnidb-server es un único binario nativo (sin el par independiente de servidor web/servidor de websockets, sin Django/CherryPy/Tornado) que responde a cada solicitud por sí mismo a través de un único puerto, usando long-polling en lugar de websockets para las actualizaciones de consultas/consola/monitorización en segundo plano. Tampoco existe ya archivo de configuración ni soporte TLS integrado — todo se configura mediante opciones de línea de comandos, y cualquier terminación TLS debe ser gestionada por un proxy inverso situado delante.

Opciones de 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 de seguridad: un servidor iniciado con -H configurado en cualquier valor distinto de loopback nunca debería iniciarse también con -A/--app — el enlace de inicio de sesión automático de escritorio que genera ese modo solo está pensado para ser accesible localmente, por lo que -A siempre fuerza el enlace a loopback independientemente de -H, ignorándolo por completo en lugar de arriesgarse a esa combinación.

Veamos cómo desplegar omnidb-server en distintos escenarios:

Despliegue directo de OmniDB

Ejecutar omnidb-server con -H 0.0.0.0 (o una interfaz pública específica) lo hace directamente accesible desde otras máquinas — pero, dado que no hay soporte TLS integrado, esto significa HTTP sin cifrar. Esto no se recomienda para nada más allá de una red local de confianza: de lo contrario, las cookies de sesión y los resultados de las consultas viajarían en claro. Para cualquier caso accesible desde internet en general, coloque delante un proxy inverso con terminación TLS (ver más abajo) en lugar de exponer omnidb-server directamente.

Despliegue de OmniDB detrás de un proxy inverso

El enfoque recomendado: ejecute omnidb-server escuchando solo en 127.0.0.1 (el valor predeterminado, por lo que -H puede omitirse) y deje que un proxy inverso como Nginx o Caddy se encargue de la terminación TLS y reenvíe HTTP sin cifrar localmente.

./omnidb-server -p 9000

Ejemplo de configuración de 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;
    }
}

Dado que todo (incluidas las actualizaciones de consultas/consola en segundo plano) se sirve mediante long-polling sobre HTTP sin cifrar en lugar de websockets, basta con un único bloque location / que cubra toda la aplicación — ya no hay una ruta de actualización de websocket separada ni un patrón /wss que enrutar de forma especial.