Déployer omnidb-server

Remarque : depuis la réécriture 3.6.x, omnidb-server est un binaire natif unique (plus de paire séparée webserver/websocket-server, plus de Django/CherryPy/Tornado) qui répond lui-même à chaque requête sur un seul port, en utilisant du long-polling plutôt que des websockets pour les mises à jour en arrière-plan des requêtes/console/supervision. Il n’y a plus non plus de fichier de configuration ni de support TLS intégré — tout se configure via des options en ligne de commande, et toute terminaison TLS doit être gérée par un reverse proxy placé devant.

Options en ligne de commande

Usage: omnidb-server [options]

Options:
  -A, --app              exécution en mode application de bureau (se lie
                          toujours uniquement en local, quel que soit -H)
  -H HOST, --host=HOST   adresse d'écoute (par défaut : 127.0.0.1)
  -p PORT, --port=PORT   port d'écoute (par défaut : un port libre choisi
                          par le système)
  -d HOMEDIR, --homedir=HOMEDIR
                         répertoire personnel contenant la base de données
                         omnidb.db et le dossier temporaire utilisé pour
                         les fichiers exportés
      --set-password=USER
                         définit le mot de passe de USER dans la base de
                         données de l'application et quitte (le demande ;
                         ne démarre pas le serveur)

-H spécifie l’adresse d’écoute. Par défaut 127.0.0.1 (uniquement en local) — indiquez 0.0.0.0 pour accepter les connexions depuis d’autres machines, ou une adresse d’interface spécifique.
-p spécifie le port d’écoute, utilisé dans l’URL du navigateur lors de l’accès direct à OmniDB. S’il est omis, le système choisit un port libre et l’affiche sur la sortie d’erreur standard (stderr) au démarrage. Comme ce port change à chaque démarrage, indiquez toujours -p pour un serveur auquel d’autres personnes (ou un reverse proxy) se connectent.
-d permet de choisir le dossier qui stocke omnidb.db (la base de données de l’application) et le dossier temp utilisé pour les fichiers exportés. Le dossier doit déjà exister ; sans -d, c’est ~/.omnidb/omnidb-server qui est utilisé (créé automatiquement). Grâce à cette option, il est possible d’exécuter plusieurs instances d’omnidb-server, chacune pointant vers un dossier différent — pratique pour les déploiements Docker où vous montez un volume à cet endroit.
--set-password USER définit le mot de passe d’un utilisateur existant directement dans la base de données de l’application et quitte sans démarrer le serveur — voir Outil de configuration OmniDB.

Remarque de sécurité : un serveur démarré avec -H défini sur autre chose que la boucle locale ne devrait jamais être démarré également avec -A/--app — le lien de connexion automatique de bureau que ce mode génère n’est censé être accessible que localement, c’est pourquoi -A force toujours une liaison en local, quel que soit -H, en l’ignorant purement et simplement plutôt que de risquer cette combinaison.

Au démarrage, le serveur affiche l’adresse à ouvrir, par exemple omnidb-server: listening on 127.0.0.1:9000 — open http://127.0.0.1:9000/omnidb_login/ in your browser. Le tout premier démarrage sur un répertoire personnel vide affiche également le mot de passe à usage unique de l’utilisateur admin initial — voir Sécurité et serveur multi-utilisateur, qui décrit aussi ce qu’un serveur multi-utilisateur restreint et protège. Arrêtez le serveur avec Ctrl-C (ou SIGTERM) ; il s’arrête proprement.

Voyons comment déployer omnidb-server dans différents scénarios :

Déployer OmniDB directement

Exécuter omnidb-server avec -H 0.0.0.0 (ou une interface publique spécifique) le rend directement accessible depuis d’autres machines — mais comme il n’y a pas de support TLS intégré, cela signifie du HTTP simple, non chiffré. Ce n’est pas recommandé au-delà d’un réseau local de confiance : les cookies de session et les résultats de requêtes circuleraient sinon en clair. Pour tout ce qui est accessible depuis l’internet au sens large, placez plutôt un reverse proxy à terminaison TLS (voir ci-dessous) devant, au lieu d’exposer directement omnidb-server.

Déployer OmniDB derrière un reverse proxy

L’approche recommandée : exécutez omnidb-server en écoutant uniquement sur 127.0.0.1 (la valeur par défaut, donc -H peut être omis) et laissez un reverse proxy tel que Nginx ou Caddy gérer la terminaison TLS et transmettre du HTTP simple localement.

./omnidb-server -p 9000

Exemple de configuration 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;
    }
}

Notez l’en-tête Host : tant qu’omnidb-server écoute sur la boucle locale, il ne répond qu’aux requêtes adressées à 127.0.0.1:<port>, localhost:<port> ou [::1]:<port> (toute autre requête reçoit 421 Misdirected Request) — une protection contre les attaques de DNS rebinding. Le proxy doit donc transmettre la requête avec Host défini sur l’adresse locale, comme ci-dessus, plutôt que de relayer le nom d’hôte public. Conservez X-Forwarded-Proto https : il indique à OmniDB de marquer ses cookies de session comme Secure.

Puisque tout (y compris les mises à jour en arrière-plan des requêtes/console) est servi via du long-polling HTTP simple plutôt que des websockets, un seul bloc location / couvrant toute l’application suffit — il n’y a plus de chemin de mise à niveau websocket séparé ni de motif /wss à router spécifiquement.