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

• -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.

• -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. 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.

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.

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 $host;
        proxy_http_version 1.1;
    }
}

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.