gDown Installation

gDown s'installe seul, sur une machine ou en cluster, avec un seul script. Le script ne fait que vérifier puis installer : il contrôle un manifeste signé (Ed25519) et le SHA-256 du binaire avant d'écrire quoi que ce soit.

gDown devient un service systemd (utilisateur gluonify-gdown, données dans /var/lib/gluonify-gdown). Un premier nœud démarre un nouveau cluster d'un seul membre ; le mot de passe administrateur généré est gardé dans un fichier lisible par root seul.

Lancez la première commande sur la première machine. Son jeton de cluster est dans /etc/gluonify-gdown/gdown.env (GLUONIFY_GDOWN_AUTH_TOKEN) : recopiez-le, puis lancez la dernière commande sur chacune des autres machines, avec --seed qui désigne le premier nœud. Le jeton passe par l'environnement, jamais en argument. Le nouveau membre se configure à partir du premier nœud et rejoint le cluster. Trois membres continuent de fonctionner quand l'un est perdu.

Options

  • --node-id : nom du membre (par défaut, le nom de la machine).
  • --advertise-host : l'adresse par laquelle les autres membres joignent celui-ci (par défaut, le nom de la machine).
  • --seed : URL d'un membre d'un cluster existant ; à omettre sur le premier nœud.
  • --data-dir : dossier des données (par défaut /var/lib/gluonify-gdown).
  • --version : version à installer (par défaut, la dernière).
  • --key-sha256 : empreinte de la clé de publication ; le script refuse toute autre clé.

Ports

8080 (HTTP : API, console web), 7687 (Bolt) et 9000 (Raft, entre membres seulement). Ouvrez 9000 entre les machines d'un cluster, et pour vos clients rien de plus que 8080 et 7687.

Docker

L’image publique gluonify/gdown fait tourner l’exécutable natif sur Red Hat UBI 9 micro (depuis la 0.6.1), pour linux/amd64 et linux/arm64 : utilisateur non root (uid 10001, ou tout uid du groupe 0, comme les attribue OpenShift), données dans le volume /data, système de fichiers racine en lecture seule, sonde de santé assurée par l’exécutable lui-même (pas de curl dans l’image). Elle tourne telle quelle sous la politique restricted-v2 d’OpenShift ; un StatefulSet de trois membres est sur cette page. Elle n’a pas de mot de passe par défaut et refuse de démarrer sans le mot de passe de l’administrateur initial (de préférence dans un fichier, un secret Docker, ou dans l’environnement) ou un fournisseur OpenID Connect. Depuis la 0.6.0, l’exécutable est construit par Oracle GraalVM 25 avec optimisation guidée par profil (PGO) ; les parties d’Oracle GraalVM qu’il contient sont redistribuées gratuitement selon les GraalVM Free Terms and Conditions (GFTC), dont le texte est livré dans l’image sous /licenses.

Trois membres en TLS mutuel (Docker Compose)

L’exemple Compose démarre trois membres, avec le TLS mutuel sur Raft entre eux, HTTPS pour la console et l’API, et Bolt sur TLS. Deux scripts produisent des certificats de test et des secrets aléatoires ; en production, utilisez votre propre autorité de certification.

  • Secrets : le mot de passe de l’administrateur initial peut être donné directement dans GLUONIFY_GDOWN_AUTH_LOCAL_INITIAL_ADMIN_PASSWORD, mais GLUONIFY_GDOWN_AUTH_LOCAL_INITIAL_ADMIN_PASSWORD_FILE (un fichier, par exemple un secret Docker) est recommandé, car l’environnement apparaît dans docker inspect ; de même pour le jeton de service, par GLUONIFY_GDOWN_AUTH_TOKEN_FILE.
  • Sans TLS entre les membres, le cluster fonctionne, mais Raft circule en clair : gDown l’écrit en avertissement au démarrage et à chaque jonction. Le TLS mutuel est la configuration recommandée.
  • Volumes : /data (bases et journal Raft, à conserver) et /var/lib/gdown/native, où la bibliothèque TLS est dépaquetée (il doit autoriser l’exécution, contrairement à un /tmp noexec).
  • Les images sont signées avec cosign par la clé de Gluonify et portent un SBOM et une attestation de provenance ; une mise à jour remplace un membre à la fois.

OpenShift et Kubernetes

L’image tourne telle quelle sous la politique restricted-v2 d’OpenShift : uid aléatoire dans le groupe 0, aucune capacité, système de fichiers racine en lecture seule. Laissez runAsUser vide (OpenShift le choisit, et son fsGroup rend le volume inscriptible) : pas besoin d’anyuid. Créez le secret avec le mot de passe administrateur et le jeton de service, puis appliquez le manifeste : un Service headless et un StatefulSet de trois membres où gdown-0 amorce le cluster et les autres le rejoignent.

Raft circule en clair entre les membres : ajoutez les variables TLS de l’exemple Compose du cluster pour le chiffrer. HTTP passe par une Route, Bolt par un Service LoadBalancer (une Route ne porte que HTTP) ; n’exposez jamais le port 9000. Vérifié sous Docker avec des uid aléatoires du groupe 0, pas encore sur un cluster OpenShift.

Connexion avec Microsoft Entra ID

gDown accepte les jetons d’accès d’Entra ID en HTTP, WebSocket et Bolt, et sa console connecte les personnes par Entra ID (code d’autorisation avec PKCE). Les droits viennent des rôles d’application, dans le claim roles.

  1. Enregistrez l’API (un seul locataire) et mettez accessTokenAcceptedVersion à 2 dans son manifeste, pour obtenir des jetons v2.
  2. Exposez une API : URI d’ID d’application api://<api-client-id> et une étendue gdown.access, que les clients demandent pour obtenir un jeton destiné à gDown.
  3. Créez les rôles d’application gDown.Reader, gDown.Writer et gDown.Admin ; attribuez-les à des utilisateurs ou des groupes, et aux démons comme permissions d’application.
  4. Enregistrez la console comme application monopage (PKCE, sans secret) avec l’adresse de la console comme URI de redirection, et donnez-lui la permission déléguée gdown.access.
  5. Montez la configuration ci-dessous dans l’image, en /opt/gdown/config/application.properties.

Ce que le jeton doit porter

iss = https://login.microsoftonline.com/<tenant-id>/v2.0 (votre locataire, jeton v2) ; aud = l’identifiant client de l’API (un jeton destiné à une autre API est refusé) ; roles = les rôles d’application, associés à reader, writer ou admin ; tid = votre locataire (vérifié par iss, ou par allowed-tenants avec plusieurs locataires) ; exp et la signature de Microsoft. Le claim scp est informatif : les droits n’en dépendent pas.

Préférez les rôles d’application au claim groups : au-delà de 200 groupes, Entra le retire (dépassement), et gDown n’appelle pas Microsoft Graph. Un jeton reste valable jusqu’à son expiration.

Licence

Copyright (c) 2026 Gluonify. gDown est publié sous Business Source License 1.1 : vous pouvez le copier, le modifier, le redistribuer et l'utiliser en production, sauf pour fournir à des tiers un service de base de données hébergé ou géré. Quatre ans après chaque version, celle-ci passe sous licence Apache 2.0. Pour tout autre usage, une licence commerciale est disponible. Les composants tiers restent sous leurs propres licences, listées dans le fichier NOTICE du dépôt.

Neo4j, Bolt et Cypher sont des marques de Neo4j, Inc. openCypher est un projet de l'openCypher Implementers Group (son TCK est sous licence Apache 2.0). Oracle, Java et GraalVM sont des marques d'Oracle et/ou de ses sociétés affiliées. Red Hat, UBI et Mandrel sont des marques de Red Hat, Inc. Docker est une marque de Docker, Inc. gDown et Gluonify ne sont ni affiliés à, ni parrainés, ni approuvés par aucun d'eux ; « compatible avec » ne désigne que la compatibilité de protocole et de langage.