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
      --set-password=USER
                         set USER's password in the app database and exit
                         (prompts for it; does not start the server)

-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. Da sich dieser Port bei jedem Start ändert, übergeben Sie -p immer für einen Server, mit dem sich andere Personen (oder ein Reverse Proxy) verbinden.
Mit -d können Sie den Ordner wählen, der omnidb.db (die Anwendungsdatenbank) und den temp-Ordner für exportierte Dateien enthält. Der Ordner muss bereits existieren; ohne -d wird ~/.omnidb/omnidb-server verwendet (automatisch angelegt). 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.
--set-password USER setzt das Passwort eines vorhandenen Benutzers direkt in der App-Datenbank und beendet sich, ohne den Server zu starten — siehe OmniDB-Konfigurationstool.

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.

Beim Start gibt der Server die zu öffnende Adresse aus, zum Beispiel omnidb-server: listening on 127.0.0.1:9000 — open http://127.0.0.1:9000/omnidb_login/ in your browser. Der allererste Start mit einem leeren Home-Verzeichnis gibt außerdem das einmalige Passwort des anfänglichen Benutzers admin aus — siehe Sicherheit und Mehrbenutzer-Server, wo auch beschrieben ist, was ein Mehrbenutzer-Server einschränkt und schützt. Beenden Sie den Server mit Ctrl-C (oder SIGTERM); er fährt geordnet herunter.

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 localhost:9000;
        proxy_http_version 1.1;
    }
}

Beachten Sie den Host-Header: Solange omnidb-server auf Loopback lauscht, beantwortet er nur Anfragen, die an 127.0.0.1:<port>, localhost:<port> oder [::1]:<port> gerichtet sind (alles andere erhält 421 Misdirected Request) — ein Schutz gegen DNS-Rebinding-Angriffe. Der Proxy muss die Anfrage daher wie oben mit einem auf die lokale Adresse gesetzten Host weiterleiten, statt den öffentlichen Hostnamen durchzureichen. Behalten Sie X-Forwarded-Proto https bei: Es teilt OmniDB mit, seine Sitzungs-Cookies als Secure zu markieren.

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.