Configuration & migration du serveur

Tout se règle dans un seul fichier, /etc/uversion/config.toml. L'installateur le génère, vous pouvez l'éditer ensuite librement.

Le fichier de configuration

Éditez, puis redémarrez : le serveur lit sa configuration au démarrage uniquement.

sudo nano /etc/uversion/config.toml
sudo systemctl restart uversion-server

Voici les champs que vous serez amené à toucher. C'est un extrait partiel : le fichier en contient d'autres, et certains champs obligatoires n'apparaissent pas ci-dessous. Ne remplacez jamais votre fichier par ce bloc, éditez les lignes concernées.

# EXTRAIT PARTIEL : le fichier contient d'autres sections.
# N'ecrasez jamais votre fichier avec ce bloc, editez les lignes concernees.

[server]
bind_address = "0.0.0.0"
port = 8080

[database]
# Ou toute base PostgreSQL accessible : autre disque, autre machine, service manage.
url = "postgres://uversion:MOTDEPASSE@127.0.0.1:5432/uversion"

[security]
# Le secret qui signe les sessions. Obligatoire et SANS valeur par defaut :
# absent ou plus court que 32 caracteres, le serveur refuse de demarrer.
# L'installateur en genere un. Le remplacer deconnecte tout le monde une fois.
jwt_secret = "..."

[storage]
# Le contenu des fichiers (les chunks, morceaux de fichiers). C'est ce qui grossit.
path = "/var/lib/uversion/data/chunks"

[tls]
disabled = false
https_port = 8443

[licence]
key = "..."

Où vivent les données

Trois emplacements distincts, et c'est le point qui surprend le plus. Le troisième, la configuration, est aussi celui qu'on oublie dans les sauvegardes :

Déplacer le dossier de données

C'est le cas courant : le contenu grossit, la partition système est petite. La base, elle, reste petite (elle grandit avec le nombre de révisions, pas avec la taille des fichiers).

1. Arrêter le service

sudo systemctl stop uversion-server

2. Copier le dossier

C'est le -a qui préserve droits et propriétaires. La copie, plutôt que le déplacement, vous laisse un retour en arrière possible jusqu'à la vérification finale.

sudo mkdir -p /srv/uversion
sudo rsync -a /var/lib/uversion/ /srv/uversion/
sudo chown -R uversion:uversion /srv/uversion
sudo chmod 0750 /srv/uversion

3. Pointer la configuration sur le nouveau chemin

Cette étape est obligatoire et vient avant la suivante : voir l'encadré « L'ordre compte » ci-dessous.

sudo sed -i 's#/var/lib/uversion#/srv/uversion#g' /etc/uversion/config.toml

4. Déclarer le nouveau chemin à l'installateur

Répondez le nouveau chemin à la question « Data directory ». L'installateur réécrit l'unité systemd à partir de cette réponse, puis redémarre le service.

sudo dpkg-reconfigure uversion-server
#   Data directory : /srv/uversion

5. Vérifier que l'unité pointe bien là

systemctl cat uversion-server | grep -E 'WorkingDirectory|ReadWritePaths'
systemctl status uversion-server

Mettre la base ailleurs

L'installateur crée une base locale, mais rien ne vous y oblige. Pointez url sur n'importe quelle base PostgreSQL joignable : autre disque monté en cluster séparé, autre machine, ou service managé.

[database]
url = "postgres://UTILISATEUR:MOTDEPASSE@HOTE:5432/BASE"

Puis redémarrez. Le serveur applique ses migrations au démarrage : il met à jour tout seul la structure de sa base. Une base vide est initialisée, une base plus ancienne est mise à niveau, vous n'avez rien à lancer à la main.

Il faut simplement que le rôle indiqué puisse créer des tables dans la base cible.

Base sur le disque de données

La section précédente suppose une base que vous administrez ailleurs. Si votre objectif est différent : qu'un seul disque survivant suffise à remonter le serveur quand la machine meurt, alors l'installateur peut placer la base dans le dossier de données, sous la forme d'un cluster PostgreSQL dédié : une instance PostgreSQL à part, avec son propre dossier et son propre port, indépendante de celle du système.

La question est posée à l'installation. Pour l'activer sur un serveur Debian déjà en place :

sudo dpkg-reconfigure uversion-server
#   Data directory                     : /srv/uversion
#   Put the database on the data directory too?  Yes

Sous Windows

Même promesse, mécanique différente. Windows n'a pas de clusters nommés : l'installateur déplace l'instance PostgreSQL elle-même vers le dossier de données, en re-pointant le service. Ce choix se fait au moment de l'installation, en ajoutant -DbOnDataDir aux paramètres du script. Il n'est pas proposé par une question : le script ne demande que le code d'activation, donc si vous ne passez pas ce paramètre, la base restera à son emplacement par défaut. Voir Installer sur Windows pour la forme exacte de la commande, sachant que le one-liner ne peut recevoir aucun paramètre.

# PowerShell en administrateur, installation en ligne de commande
& ([scriptblock]::Create((iwr https://uversion.io/downloads/server/install.ps1 -UseBasicParsing).Content)) `
    -LicenceKey "UV-XXXX-XXXX-XXXX" -DataDir "D:\uVersion" -DbOnDataDir

# verifier ensuite ou pointe le service PostgreSQL
(Get-CimInstance Win32_Service -Filter "Name='postgresql-x64-16'").PathName

Le déplacement est refusé, avec la raison affichée, si l'instance héberge d'autres bases que celle d'uVersion, ou si son répertoire n'est pas autonome : présence d'un tablespace, pg_wal déplacé par une jonction, ou chemin absolu inscrit dans postgresql.conf. Rien n'est jamais supprimé : l'installateur copie, vérifie, démarre le service sur la nouvelle copie, et ne renomme l'ancien répertoire qu'ensuite.

Le disque contient alors tout :

/srv/uversion/
├── data/chunks       contenu des fichiers
├── data/tls          certificat, empreinte
├── pgdata/16         LA BASE (cluster PostgreSQL dedie)
└── recovery/         procedure + fichiers necessaires a la reprise
    ├── RESTORE.md
    ├── pgconf/       postgresql.conf, pg_hba.conf, pg_ident.conf
    ├── etc/          copie de config.toml et du mot de passe
    └── cluster.env

Le cluster reçoit son propre port, attribué automatiquement (5433 s'il est libre), et config.toml est mis à jour pour le viser. Le cluster système n'est pas touché : il peut continuer d'héberger d'autres bases.

Remonter le serveur sur une machine neuve

Le disque ne contient pas les logiciels : prévoyez PostgreSQL et le paquet uVersion, dont une copie gardée à côté du disque évite une mauvaise surprise le jour venu.

# sur la machine neuve
sudo apt install postgresql-16
# montez le disque, par exemple sur /srv/uversion
sudo apt install ./uversion-server_*.deb
#   dossier de donnees : le point de montage du disque
#   base sur le dossier de donnees : oui

L'installateur trouve la base sur le disque, remet en place les fichiers de configuration PostgreSQL (que pg_createcluster avait déplacés hors du répertoire, sur le disque système), enregistre le cluster, corrige les propriétaires, puis réaligne le port et le chemin des chunks dans config.toml. Si le disque remonte sur un autre point de montage qu'avant, indiquez simplement le nouveau chemin.

La procédure complète, y compris la variante sans réinstallation, est écrite sur le disque lui-même : recovery/RESTORE.md.

Sauvegarder et restaurer

Une sauvegarde complète, ce sont trois éléments : l'export de la base (le dump), le dossier de données, et le dossier de configuration.

Sauvegarder la base

Les métadonnées : fichiers, révisions, utilisateurs, verrous.

sudo -u postgres pg_dump uversion > uversion-$(date +%F).sql

Sauvegarder le dossier de données

Le contenu des fichiers, c'est-à-dire ce qui occupe la place.

sudo tar -C /var/lib/uversion -czf uversion-data-$(date +%F).tar.gz .

Sauvegarder la configuration

Clé de licence, secret de signature des sessions, mot de passe de la base. Elle ne vit pas dans le dossier de données.

sudo tar -C /etc -czf uversion-etc-$(date +%F).tar.gz uversion

Pour restaurer sur une machine neuve : installez le paquet, puis remettez les trois éléments en place, dans cet ordre.

1. Restaurer la base

sudo -u postgres createdb -O uversion uversion      # seulement si elle n'existe pas
sudo -u postgres psql uversion < sauvegarde.sql

2. Restaurer les données

Remettre les chunks, avec les bons droits :

sudo rsync -a /mnt/backup/uversion/ /var/lib/uversion/
sudo chown -R uversion:uversion /var/lib/uversion
sudo chmod 0750 /var/lib/uversion

3. Reporter deux lignes de configuration

Pas le fichier entier : celui que l'installateur vient d'écrire porte le mot de passe de base qu'il a lui-même redéfini.

# N'ECRASEZ PAS le fichier neuf : ouvrez l'ancien a cote et recopiez-en
# deux lignes, et deux seulement.
#   [security] jwt_secret  -> sinon toute l'equipe est deconnectee
#   [licence]  key         -> sinon il faut redemander une licence
# Gardez le [database] url que l'installateur vient d'ecrire : il porte le
# mot de passe qu'il a lui-meme redefini.
sudo nano /etc/uversion/config.toml

4. Redémarrer

sudo systemctl restart uversion-server

Déplacer le cluster PostgreSQL

Rarement nécessaire : la base est petite. Si vous y tenez, c'est une opération PostgreSQL standard, pas quelque chose que gère l'installateur uVersion. Attention, ce cluster (l'instance PostgreSQL du système, avec son dossier et son port) peut héberger d'autres bases que celle d'uVersion.

sudo systemctl stop uversion-server
sudo pg_ctlcluster 16 main stop

sudo mkdir -p /srv/pgdata
sudo rsync -a /var/lib/postgresql/16/main/ /srv/pgdata/16/main/
sudo chown -R postgres:postgres /srv/pgdata

sudo sed -i "s#^data_directory =.*#data_directory = '/srv/pgdata/16/main'#" \
  /etc/postgresql/16/main/postgresql.conf

sudo pg_ctlcluster 16 main start
sudo systemctl start uversion-server

Vérifiez ensuite avec pg_lsclusters que le cluster est en ligne sur le nouveau chemin.