mabibli_ynh/README.md

Paquet YunoHost pour MaBibli

Paquet d'installation de MaBibli, application de gestion de bibliothèque personnelle (catalogue, prêts, scan ISBN).

Ce dépôt ne contient aucun code C#. Il porte uniquement de quoi installer sur YunoHost une archive déjà compilée : le manifeste, les configurations nginx et systemd, et les scripts d'installation.

Contenu

Fichier	Rôle
manifest.toml	Identité, version, URL de l'archive et son sha256, ressources (utilisateur système, répertoires, port, permissions)
conf/systemd.service	Unité du service — écoute sur 127.0.0.1, base dans le répertoire de données, durcissement
conf/nginx.conf	Reverse proxy et intégration SSOwat
scripts/_common.sh	Variables partagées et sauvegarde/restauration cohérente de la base SQLite
scripts/install remove upgrade backup restore	Cycle de vie de l'application
build/publier-release.sh	Compile, archive, calcule le sha256 et met à jour manifest.toml

Publier une nouvelle version

Le serveur ne compile jamais : il télécharge une archive déjà produite. La chaîne est donc « compiler ici, déposer une release, mettre à jour le manifeste ».

# Depuis ce dépôt, avec le dépôt du code à côté (../mabibli)
./build/publier-release.sh --version 0.2.0 --base-url https://gitea.exemple.org/mathieu/mabibli/releases/download

Le script :

1. lance dotnet publish MaBibli.Api -c Release -r linux-x64 --self-contained ;
2. vérifie que le binaire est là, que wwwroot/ a bien été embarqué, et que toutes les ressources référencées par index.html existent réellement dans le publish ;
3. produit build/dist/mabibli-<version>-linux-x64.tar.gz, de façon reproductible ;
4. en calcule le sha256 ;
5. réécrit version, amd64.url et amd64.sha256 dans manifest.toml.

Restent à faire à la main : créer le tag et la release sur Gitea, y téléverser l'archive, puis committer manifest.toml.

Le script ne dépend d'aucun environnement de CI : tout passe par des options ou des variables d'environnement (MABIBLI_SOURCE_DIR, MABIBLI_VERSION, MABIBLI_BASE_URL, MABIBLI_OUTPUT_DIR), il ne pose aucune question et s'arrête à la première erreur. Il est donc utilisable tel quel dans Gitea Actions le jour où un runner sera disponible.

Points de conception

Le service n'écoute que sur 127.0.0.1. L'application déduit l'identité de l'en-tête YNH_USER injecté par SSOwat ; cet en-tête n'est digne de confiance que si nginx est le seul chemin d'accès. Un service exposé sur le réseau permettrait de forger YNH_USER et de contourner le portail. La contrainte est écrite dans conf/systemd.service (ASPNETCORE_URLS) et le port n'est pas ouvert au pare-feu.

Aucune compilation sur le serveur. Le publish est self-contained : il embarque son propre runtime .NET, donc aucun paquet dotnet-runtime n'est nécessaire. ynh_setup_source vérifie le sha256 de l'archive avant de la déployer.

Les données survivent aux mises à jour. La base SQLite vit dans le répertoire de données, pas à côté du binaire ; upgrade ne remplace que le répertoire d'installation.

La sauvegarde passe par l'API de sauvegarde en ligne de SQLite. La base est en mode WAL : copier le seul fichier .db d'une base active peut ne rien sauvegarder du tout. Voir doc/ADMIN.md.

Documentation

• doc/DESCRIPTION.md — présentation affichée dans le catalogue YunoHost
• doc/ADMIN.md — authentification, emplacement des données, sauvegarde, contraintes