# Paquet YunoHost pour MaBibli

Paquet d'installation de [MaBibli](https://gitea.example.org/mathieu/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 ».

```bash
# 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