omnidb-server bereitstellen

Hinweis: Seit der Neufassung in 3.6.x ist omnidb-server eine einzige native Binärdatei (kein separates Paar aus Webserver/WebSocket-Server, kein Django/CherryPy/Tornado), die jede Anfrage selbst über einen einzigen Port beantwortet und dabei für Hintergrundaktualisierungen von Abfragen, Konsole und Monitoring Long-Polling statt WebSockets verwendet. Es gibt außerdem keine Konfigurationsdatei und keine eingebaute TLS-Unterstützung mehr — alles wird über Kommandozeilenoptionen gesetzt, und jede TLS-Terminierung muss von einem vorgeschalteten Reverse-Proxy übernommen werden.

Kommandozeilenoptionen

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

-H gibt die Adresse an, auf der gelauscht wird. Standardmäßig 127.0.0.1 (nur Loopback) — übergeben Sie 0.0.0.0, um Verbindungen von anderen Maschinen zuzulassen, oder eine bestimmte Schnittstellenadresse.
-p gibt den Port an, auf dem gelauscht wird; er wird in der Browser-URL verwendet, wenn Sie direkt auf OmniDB zugreifen. Wird er weggelassen, wählt das Betriebssystem einen freien Port und gibt ihn beim Start auf stderr aus.
Mit -d können Sie den Ordner wählen, der omnidb.db (die Anwendungsdatenbank) und den temp-Ordner für exportierte Dateien enthält. Damit lassen sich mehrere Instanzen von omnidb-server betreiben, die jeweils auf ein anderes Verzeichnis zeigen — praktisch für Docker-Deployments, bei denen dort ein Volume eingehängt wird.

Sicherheitshinweis: Ein Server, der mit -H auf etwas anderes als Loopback gesetzt gestartet wird, sollte niemals gleichzeitig mit -A/--app gestartet werden — der Auto-Login-Link für den Desktop, den dieser Modus erzeugt, soll nur lokal erreichbar sein, daher erzwingt -A immer eine Loopback-Bindung unabhängig von -H und ignoriert diese Option vollständig, statt diese Kombination zu riskieren.

Schauen wir uns an, wie sich omnidb-server in verschiedenen Szenarien bereitstellen lässt:

OmniDB direkt bereitstellen

Wird omnidb-server mit -H 0.0.0.0 (oder einer bestimmten öffentlichen Schnittstelle) ausgeführt, ist er direkt von anderen Maschinen erreichbar — da es jedoch keine eingebaute TLS-Unterstützung gibt, bedeutet dies unverschlüsseltes HTTP im Klartext. Dies wird nicht empfohlen für alles, was über ein vertrauenswürdiges lokales Netzwerk hinausgeht: Sitzungscookies und Abfrageergebnisse würden sonst unverschlüsselt übertragen. Für alles, was aus dem weiteren Internet erreichbar sein soll, schalten Sie stattdessen einen TLS-terminierenden Reverse-Proxy (siehe unten) davor, statt omnidb-server direkt freizugeben.

OmniDB hinter einem Reverse-Proxy bereitstellen

Der empfohlene Ansatz: Lassen Sie omnidb-server nur auf 127.0.0.1 lauschen (die Standardeinstellung, sodass -H weggelassen werden kann) und überlassen Sie einem Reverse-Proxy wie Nginx oder Caddy die TLS-Terminierung; dieser leitet dann einfaches HTTP lokal weiter.

./omnidb-server -p 9000

Beispielkonfiguration für 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;
    }
}

Da alles (einschließlich Hintergrundaktualisierungen für Abfragen und Konsole) über einfaches HTTP-Long-Polling statt über WebSockets ausgeliefert wird, genügt ein einziger location /-Block für die gesamte Anwendung — es gibt keinen separaten WebSocket-Upgrade-Pfad und kein /wss-Muster mehr, das gesondert geroutet werden müsste.