Wiki

Configuración y migración del servidor

Editar config.toml, mover el directorio de datos, usar una base de datos PostgreSQL en otro lugar, hacer copias de seguridad y restaurar.

Todo se configura en un único archivo, /etc/uversion/config.toml. El instalador lo genera; después puede editarlo libremente.

El archivo de configuración

Edite y luego reinicie: el servidor lee su configuración solo al arrancar.

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

Estos son los campos que acabará tocando. Es un extracto parcial: el archivo contiene otros, y algunos campos obligatorios no aparecen abajo. Nunca sobrescriba su archivo con este bloque, edite solo las líneas correspondientes.

# 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 = "..."

Permisos del archivo Contiene la clave de licencia, el secreto que firma las sesiones y la contraseña de la base de datos. Está en 0640 root:uversion: manténgalo así.

Dónde viven los datos

Tres ubicaciones distintas, y es el punto que más sorprende. La tercera, la configuración, es también la que se olvida en las copias de seguridad:

Qué	Dónde
Contenido de los archivos (los chunks, fragmentos de archivos: es lo que ocupa el espacio)	`/var/lib/uversion/data/chunks`
Certificado TLS, huella del servidor	`/var/lib/uversion/data/tls`
Identidad del servidor, ancla de licencia	`/var/lib/uversion/server-id`, `last-validated-at`
Metadatos (archivos, revisiones, usuarios, bloqueos, permisos, tareas)	PostgreSQL: `/var/lib/postgresql/16/main`
Configuración: clave de licencia, secreto de firma de sesiones, contraseña de la base de datos	`/etc/uversion/config.toml`, `/etc/uversion/licence-key`

La base de datos no sigue al directorio de datos Cambiar el directorio de datos mueve los chunks y los certificados, no la base de datos. Y la base de datos referencia los chunks por su huella: si mueve uno sin el otro, el servidor buscará chunks que no encontrará. Mueva ambos, o ninguno.

Mover el directorio de datos

Es el caso habitual: el contenido crece, la partición del sistema es pequeña. La base de datos, en cambio, se mantiene pequeña (crece con el número de revisiones, no con el tamaño de los archivos).

1. Detener el servicio

sudo systemctl stop uversion-server

2. Copiar el directorio

Es el -a el que conserva permisos y propietarios. Copiar, en lugar de mover, le deja una vuelta atrás posible hasta la comprobación final.

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. Apuntar la configuración a la nueva ruta

Este paso es obligatorio y va antes del siguiente: vea el recuadro «El orden importa» más abajo.

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

4. Declarar la nueva ruta al instalador

Responda la nueva ruta a la pregunta «Data directory». El instalador reescribe la unidad de systemd a partir de esa respuesta y luego reinicia el servicio.

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

5. Verificar que la unidad apunta realmente allí

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

Pase por dpkg-reconfigure, no escriba usted mismo la unidad de systemd El instalador escribe él mismo /etc/systemd/system/uversion-server.service.d/10-data-dir.conf, y la reescribe en cada configuración a partir de la respuesta que le dio. Un archivo colocado a mano sobrevive hasta la siguiente actualización, incluida la que activa el botón Update now: la unidad vuelve entonces a apuntar a la carpeta antigua mientras la configuración escribe en la nueva. El servicio reforzado (ProtectSystem=strict) arranca con normalidad y se rompe en el primer envío de archivo, semanas después.

El orden importa: edite config.toml antes dpkg-reconfigure por sí solo no basta. El instalador solo corrige [storage].path si la carpeta que encuentra allí ya no existe: una ruta personalizada que sigue presente se considera una elección deliberada y se deja tal cual. Como ha copiado en lugar de mover, la carpeta antigua sigue existiendo, y por tanto el paso 2 anterior es obligatorio. Una vez verificado todo y con el servidor en marcha en la nueva ruta, puede eliminar la carpeta antigua.

Nunca bajo /home ni /root El servicio se ejecuta como usuario de sistema reforzado (ProtectHome=true, y un directorio personal no es transitable por una cuenta de sistema). Una ruta bajo /home o /root impide el arranque (226/NAMESPACE o 200/CHDIR). Elija una ruta de sistema: /srv, /opt o un disco montado.

Poner la base de datos en otro lugar

El instalador crea una base de datos local, pero nada le obliga a usarla. Apunte url a cualquier base de datos PostgreSQL accesible: otro disco montado como clúster separado, otra máquina o un servicio gestionado.

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

Luego reinicie. El servidor aplica sus migraciones al arrancar: actualiza por sí solo la estructura de su base de datos. Una base de datos vacía se inicializa, una más antigua se actualiza, no tiene nada que ejecutar a mano.

Basta con que el rol indicado pueda crear tablas en la base de datos de destino.

Base de datos en el disco de datos

La sección anterior supone una base de datos que administra en otro lugar. Si su objetivo es distinto: que un solo disco superviviente baste para reconstruir el servidor cuando la máquina muere, entonces el instalador puede colocar la base de datos dentro del directorio de datos, en forma de un clúster de PostgreSQL dedicado: una instancia de PostgreSQL aparte, con su propia carpeta y su propio puerto, independiente de la del sistema.

La pregunta se plantea durante la instalación. Para activarla en un servidor Debian ya instalado:

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

En Windows

La misma promesa, mecánica distinta. Windows no tiene clústeres con nombre: el instalador mueve la propia instancia de PostgreSQL al directorio de datos, reapuntando el servicio. Esta elección se hace en el momento de la instalación, añadiendo -DbOnDataDir a los parámetros del script. No se ofrece mediante una pregunta: el script solo pide el código de activación, así que si no pasa este parámetro, la base de datos se quedará en su ubicación por defecto. Consulte Instalar en Windows para la forma exacta del comando, teniendo en cuenta que el comando de una línea no puede recibir ningún parámetro.

# 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

El traslado se rechaza, con el motivo mostrado, si la instancia aloja otras bases de datos además de la de uVersion, o si su directorio no es autónomo: presencia de un tablespace, un pg_wal reubicado mediante un enlace de unión, o una ruta absoluta escrita en postgresql.conf. Nunca se elimina nada: el instalador copia, verifica, arranca el servicio sobre la copia nueva y solo entonces renombra el directorio antiguo.

Dos diferencias con Linux Windows no sabe hacer esperar a un servicio por un disco: no existe ningún equivalente de RequiresMountsFor. Un disco externo que llega tarde queda por tanto recogido por las acciones de recuperación del servicio, no por una dependencia. Y PostgreSQL no verifica ningún permiso en su directorio bajo Windows: es el instalador quien los restringe, no hay red de seguridad del lado del servidor.

El disco contiene entonces todo:

/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

El clúster recibe su propio puerto, asignado automáticamente (5433 si está libre), y config.toml se actualiza para apuntarlo. El clúster del sistema no se toca: puede seguir alojando otras bases de datos.

Dos contrapartidas, que conviene conocer antes de decir que sí Un directorio de datos de PostgreSQL solo se abre con la versión mayor que lo creó: una recuperación dentro de tres años puede exigir instalar explícitamente PostgreSQL 16. Y el disco lleva ahora la clave de licencia, el secreto que firma las sesiones y la contraseña de la base de datos, en un directorio accesible solo para root: trate este disco como una credencial.

Base de datos ya con datos: el instalador se niega a moverla Si su servidor ya está en marcha con datos, activar la opción no mueve nada: una mudanza interrumpida a mitad de una actualización de paquete sería peor que no mover nada. El instalador lo deja como está e imprime el procedimiento manual (detener, pg_dump, crear el clúster, restaurar, actualizar url).

Reconstruir el servidor en una máquina nueva

El disco no contiene el software: prevea PostgreSQL y el paquete uVersion, del que una copia guardada junto al disco evita una desagradable sorpresa llegado el día.

# 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

El instalador encuentra la base de datos en el disco, vuelve a colocar los archivos de configuración de PostgreSQL (que pg_createcluster había movido fuera del directorio, al disco del sistema), registra el clúster, corrige los propietarios y luego realinea el puerto y la ruta de los chunks en config.toml. Si el disco vuelve a montarse en un punto de montaje distinto al anterior, basta con indicar la nueva ruta.

El procedimiento completo, incluida la variante sin reinstalación, está escrito en el propio disco: recovery/RESTORE.md.

Copia de seguridad y restauración

Una copia de seguridad completa son tres elementos: la exportación de la base de datos (el dump), el directorio de datos y el directorio de configuración.

Copiar la base de datos

Los metadatos: archivos, revisiones, usuarios, bloqueos.

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

Copiar el directorio de datos

El contenido de los archivos, es decir, lo que ocupa el espacio.

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

Copiar la configuración

Clave de licencia, secreto de firma de sesiones, contraseña de la base de datos. No vive en el directorio de datos.

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

No olvide /etc/uversion Es el tercer elemento, y el más fácil de olvidar: no vive en el directorio de datos. /etc/uversion/config.toml lleva la clave de licencia, el secreto que firma las sesiones y la contraseña de la base de datos; /etc/uversion/licence-key lleva la licencia misma. Sin ellos, una restauración en una máquina nueva vuelve a empezar con un secreto nuevo, por lo que todo el equipo queda desconectado de golpe, y hay que volver a solicitar una licencia: el código de activación recibido al registrarse es de un solo uso y ya está consumido, solo la clave de licencia que produjo se puede reutilizar.

Para restaurar en una máquina nueva: instale el paquete y luego vuelva a colocar los tres elementos, en este orden.

1. Restaurar la base de datos

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

2. Restaurar los datos

Volver a colocar los chunks, con los permisos correctos:

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

3. Trasladar dos líneas de configuración

No el archivo entero: el que el instalador acaba de escribir lleva la contraseña de la base de datos que él mismo redefinió.

# 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. Reiniciar

sudo systemctl restart uversion-server

Instalar sobre una base de datos existente El instalador no destruye nada: si ya encuentra la base de datos uversion, la reutiliza tal cual y se limita a restablecer la contraseña del rol. Por tanto, puede restaurar su dump primero e instalar después.

Mover el clúster de PostgreSQL

Rara vez necesario: la base de datos es pequeña. Si insiste, es una operación estándar de PostgreSQL, no algo que gestione el instalador de uVersion. Atención: este clúster (la instancia de PostgreSQL del sistema, con su carpeta y su puerto) puede alojar otras bases de datos además de la de 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

Verifique después con pg_lsclusters que el clúster está en línea en la nueva ruta.