mathieuandClaude Opus 5
54a22b1579
PUBLICATION.md donne les gestes pas à pas, avec le contrôle attendu à chaque étape : première mise en production, montée de version (0.1.0 → 0.1.1), retour arrière si la mise à jour échoue, désinstallation. Deux points qui se paient cher s'ils sont oubliés y sont explicites : `--version` est obligatoire pour une nouvelle version applicative (sans lui le script reproduit celle du manifeste), et la sauvegarde de sécurité pré-upgrade ne contient PAS le répertoire de données. README et A_FAIRE renvoient au fichier plutôt que de tripler la procédure. Dernière URL fictive éliminée : gitea.exemple.org subsistait dans l'exemple CI de publier-release.sh. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
78 lines
3.9 KiB
Markdown
78 lines
3.9 KiB
Markdown
# Paquet YunoHost pour MaBibli
|
|
|
|
Paquet d'installation de [MaBibli](https://git.akbar.nohost.me/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.1.1
|
|
```
|
|
|
|
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 et **pousser** `manifest.toml` — YunoHost lit le manifeste depuis Gitea, pas la copie
|
|
locale.
|
|
|
|
📖 **La marche à suivre complète est dans [`PUBLICATION.md`](PUBLICATION.md)** : première mise en
|
|
production, montée de version (avec les contrôles à chaque étape), retour arrière, et
|
|
désinstallation.
|
|
|
|
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
|
|
- `PUBLICATION.md` — mise en production et montée de version, pas à pas
|
|
- `A_FAIRE.md` — contraintes permanentes et journal des points réglés
|