Mettre à jour ou revenir en arrière depuis l'interface web, avec sauvegarde automatique

Mettre à jour un serveur multimédia devrait être une formalité. En pratique, c'est souvent le moment où tout casse : une migration de base de données s'exécute, un plugin ne se charge plus et le serveur ne répond plus. D'habitude, vous le découvrez depuis un terminal, avec apt et quelques minutes tendues à surveiller les journaux.

Self-Update sort le terminal de cette boucle. C'est un plugin Jellyfin qui met à jour ou restaure une version antérieure de medialab Server (la variante MediaLab Works de Jellyfin 12.2) depuis l'interface web. Avant d'installer quoi que ce soit, il sauvegarde la base de données et la configuration, et si la nouvelle version ne démarre pas correctement, le serveur revient de lui-même à la version précédente. C'est ce qui rend un retour arrière assez sûr pour être lancé depuis un navigateur.

Ce tutoriel couvre tout le parcours : consulter les versions, effectuer la mise à jour (jellyfin mise à jour comprise), revenir en arrière, la vérification quotidienne à 03:00 et la mise à jour automatique en option. La page produit se trouve à /products/jf-selfupdate et la référence détaillée est le guide utilisateur.

Prérequis

• medialab Server installé depuis ses paquets (medialab-server et medialab-server-web) sur Debian ou Ubuntu. Ces paquets apportent le programme de mise à jour : /usr/lib/medialab-server/update.sh, les unités systemd medialab-update.path et medialab-update.service, et le dossier /var/lib/medialab-update.
• Au moins 1 Go libre dans /usr/lib. Avec moins, la mise à jour s'arrête avec Not enough disk space.
• Un compte MediaLab Works avec une licence couvrant le plugin (un abonnement actif, une licence à vie dans sa fenêtre de mise à jour, le bundle Jellyfin ou l'essai gratuit de 30 jours) pour mettre à jour et revenir en arrière. La consultation des versions fonctionne sans licence.
• Un accès administrateur au tableau de bord Jellyfin. L'API du plugin ne répond qu'aux administrateurs Jellyfin.

Si medialab Server a été installé depuis une archive, une installation portable ou une compilation locale, le programme de mise à jour est absent : la page explique comment installer depuis les paquets et les actions sont désactivées. Sur Jellyfin officiel, la page indique seulement comment passer à medialab Server, ce qui conserve vos données, utilisateurs, bibliothèques et plugins en place.

Étape 1 — Installer le plugin

Depuis votre dépôt de plugins privé (recommandé). Jellyfin installe et met ensuite à jour le plugin tout seul.

1. Dans votre compte MediaLab Works, ouvrez Licenses → Jellyfin plugin repository et cliquez sur Create address. Copiez-la. Elle est privée car elle contient un jeton : ne la partagez pas ; vous pouvez la régénérer ou la révoquer à tout moment.
2. Dans Jellyfin, ouvrez Dashboard → Plugins → Repositories, cliquez sur +, donnez-lui un nom (par exemple MediaLab Works), collez l'adresse et enregistrez.
3. Dans Dashboard → Plugins → Catalog, trouvez Self-Update by MediaLab, cliquez sur Install, puis redémarrez le serveur.

Depuis le catalogue public. https://medialab.works/jellyfin/manifest.json liste tous les plugins MediaLab Works publiés ; medialab Server l'ajoute de lui-même.

Manuellement, depuis un fichier zip. Téléchargez jf-selfupdate_x.y.z.zip depuis Account → Licenses (le SHA-256 est affiché à côté du bouton), extrayez-le dans un nouveau dossier Self-Update by MediaLab_x.y.z.0 dans /var/lib/jellyfin/plugins/ sur une installation par paquets, puis redémarrez le serveur.

Étape 2 — Activer la licence

1. Ouvrez Dashboard → Plugins → Self-Update by MediaLab et cliquez sur License (la page Server update dispose aussi d'un bouton License).
2. Collez votre clé de licence et cliquez sur Activate with key. Le plugin lie la clé à ce serveur et affiche la licence comme Active.
3. Pas encore de clé ? Sur la même page, saisissez votre e-mail et lancez l'essai de 30 jours, ou achetez une licence ; le plugin s'active tout seul une fois le paiement effectué.

La licence est vérifiée une fois par jour et à chaque démarrage du serveur, ainsi qu'avant une mise à jour, un retour arrière ou une mise à jour automatique, sauf si elle a été vérifiée peu de temps avant. Sans accès à internet, elle reste valide 7 jours après la dernière vérification réussie. Move license (release this server) sur la page License libère la clé pour un autre serveur.

Étape 3 — Vérifier maintenant et lire la liste des versions

Ouvrez Server update dans le menu du tableau de bord Jellyfin (administrateurs uniquement).

• Installed version affiche la révision medialab, le paquet installé (par exemple 12.2+ml4+deb12), la version de Jellyfin et la version la plus récente trouvée lors de la dernière vérification.
• Cliquez sur Check now. Le programme de mise à jour interroge le dépôt medialab, et la liste Available versions affiche toutes les versions, marquées installed, newer ou older.

Faites-le avant de planifier une maintenance. C'est une opération en lecture seule, qui fonctionne sans licence.

Étape 4 — Mettre à jour vers la version la plus récente, ou vers une version choisie

• Update to x installe la version la plus récente.
• Install à côté d'une version installe celle-ci.
• Roll back to the previous version revient à la version juste en dessous de celle installée ; Roll back à côté d'une version plus ancienne revient à celle-ci. À partir de medialab Server 12.2-ml.7, le retour arrière en dessous de 12.2-ml.7 est refusé volontairement, car les versions plus anciennes ont un programme de mise à jour moins sûr.

Chaque action demande d'abord une confirmation. Lisez-la : elle rappelle que le serveur redémarre, donc que la lecture en cours s'arrête ; que la base de données et la configuration sont sauvegardées d'abord ; et que si le serveur ne démarre pas correctement, il revient de lui-même à la version actuelle.

Pendant qu'une mise à jour est en cours, ou qu'une requête attend d'être prise en charge, une nouvelle requête est refusée.

Étape 5 — Suivre la progression pendant le redémarrage

Current operation suit la requête : envoyée, en cours, The server is restarting…, puis la page se recharge toute seule quand le serveur répond de nouveau. Le redémarrage prend généralement 1 à 3 minutes.

Last result indique ensuite comment cela s'est terminé :

• succeeded ;
• failed, rolled back automatically, avec la version vers laquelle le serveur est revenu ;
• refused, avec la raison, par exemple une version absente du dépôt.

Dans le rare cas où le serveur ne répond pas non plus après ce retour, la page indique où se trouve la sauvegarde.

Étape 6 — La vérification quotidienne à 03:00 et les mises à jour automatiques en option

La tâche planifiée Check for medialab Server updates (catégorie medialab, tous les jours à 03:00) ne fait qu'interroger le dépôt. Elle n'installe rien.

Dans Automatic update :

• Install new versions automatically est désactivé par défaut.
• Update hour (server time) est l'heure à laquelle une nouvelle version peut être installée (04:00 sauf si vous la changez). Cliquez sur Save.

Avec la mise à jour automatique activée et une licence valide, lorsque la dernière vérification a trouvé une version plus récente que celle installée, elle est installée à l'heure choisie, au plus une fois par jour, avec la même sauvegarde et le même retour arrière automatique qu'une mise à jour manuelle. Vous pouvez changer l'heure de la vérification elle-même dans Dashboard → Scheduled Tasks.

Conseils et dépannage

• Sans sudo, par conception. Le plugin s'exécute sous l'utilisateur jellyfin et écrit seulement un fichier de requête, /var/lib/medialab-update/request.json. Le service root medialab-update le valide strictement : l'action doit être update, rollback ou check, la version doit avoir le format exact de paquet (par exemple 12.2+ml4+deb12) et exister dans le dépôt. Seuls les paquets medialab-server et medialab-server-web sont installés, et uniquement depuis le dépôt apt medialab signé, dont l'adresse est fixée sur le serveur et ne provient jamais de la requête. Si une requête est refusée, c'est ce contrôle qui fait son travail.
• De l'espace libre d'abord. Vérifiez /usr/lib avant un grand saut de version. Not enough disk space est l'échec évitable le plus courant.
• Choisissez une heure calme. Une mise à jour redémarre le serveur ; la lecture en cours s'arrête pendant 1 à 3 minutes. La vérification à 03:00 et l'heure d'installation par défaut à 04:00 sont un bon point de départ pour un serveur à domicile.
• Actions refusées ? La mise à jour, le retour arrière et la mise à jour automatique exigent une licence valide ; sans licence, la vérification fonctionne toujours et rien n'est supprimé. Consultez la page License.
• Mises à jour du plugin et licences à vie. Le catalogue public propose toujours la version la plus récente du plugin. Lorsque la fenêtre de mise à jour d'une licence à vie est terminée, une version plus récente du plugin n'est pas couverte et s'arrête avec « version not licensed » jusqu'à ce que vous utilisiez Roll back to x.y.z sur sa page License ou achetiez un pass de mise à jour. Pour l'éviter, utilisez votre dépôt privé, qui ne propose que les versions autorisées par votre licence, plutôt que le catalogue public.
• Conteneurs. Dans un conteneur, mettez à jour en récupérant le nouvel étiquette d'image (12.2-ml.N) et en recréant le conteneur ; Self-Update affiche les versions disponibles mais n'installe pas de paquets dans un conteneur.

Conclusion

Ce qui compte n'est pas le bouton, mais l'ordre des opérations derrière lui : sauvegarder la base de données et la configuration, installer, et si le serveur ne revient pas, revenir à la version précédente et restaurer la sauvegarde automatiquement. Avec la vérification quotidienne à 03:00 qui fait la lecture et la mise à jour automatique désactivée tant que vous n'en décidez pas autrement, vous gardez le contrôle sans garder un terminal ouvert. Commencez à /products/jf-selfupdate, gardez le guide et le changelog à portée de main, et si quelque chose ne colle pas, la base de connaissances et la FAQ sont les étapes suivantes.