Journal de construction

Cette page consigne les changements importants apportés aux systèmes qui entourent le site : environnement de développement, automatisation de la maintenance, publication et fonctionnalités notables. La page automatique des mises à jour indique quelles notes ont changé ; cette page explique quelle capacité a été ajoutée et pourquoi.

Les entrées publiques remplacent dépôts privés et vrais hôtes par des placeholders fonctionnels ; l’inventaire exact reste dans les notes d’exploitation privées.

Chaque entrée reste courte :

• Ajouts — nouvelles capacités et commandes principales ;
• Modifications — changements de comportement importants ;
• Vérifications — contrôles effectués avec succès ;
• Suite — travail volontairement différé.

2026-08-09 — Charge parallèle RSSHub en production

Ajouts

• L’image officielle RSSHub épinglée par digest immuable dans son projet Compose /srv/rsshub, avec cache mémoire, unless-stopped et contrôle de santé du conteneur.
• HTTPS par rss.example.com, Caddy et infra-edge ; le port 1200 de RSSHub reste dans Docker sans liaison d’hôte.
• Une ACCESS_KEY générée sur le VPS et seulement les variables nécessaires à la route Bilibili représentative, ainsi qu’un moniteur Kuma de santé publique sans clé.

Modifications

• infra-edge contient maintenant Caddy et RSSHub ; Caddy résout l’alias rsshub-prod.
• La version actuelle de RSSHub protège /healthz lorsque ACCESS_KEY est activée, donc le conteneur et Caddy utilisent un code dérivé lié à cette route, réservé au contrôle de santé ; la clé brute reste dans le fichier d’environnement protégé.
• Le déploiement reste parallèle : consommateur de feeds, données persistantes, planificateur et RSSHub local restent inchangés.

Vérifications

• Les requêtes DNS locales, publiques et faisant autorité ont atteint le VPS ; la santé HTTPS a répondu 200 avec TLS valide et HTTP a répondu 308.
• Une vraie route sans authentification a répondu 403. Les canaris local et VPS authentifiés ont partagé la même identité de canal RSS, 20 éléments et aucun message d’erreur.
• Le port 1200 était inaccessible par les adresses publique et Tailscale ; UFW, SSH seulement via Tailscale, Caddy, Kuma privé et zéro unité systemd en échec sont restés intacts.
• Un redémarrage limité à RSSHub est revenu à running healthy sans modifier les conteneurs Caddy ou Kuma. Un canari temporaire de compatibilité aval a récupéré des éléments représentatifs sans toucher les données de production.

Suite

• Réunir dans une phase 4 contrôlée la sauvegarde/restauration SQLite, la migration du planificateur, la bascule du point d’accès RSSHub et le retrait du repli local.

2026-08-09 — Entrée VPS partagée et supervision privée

Ajouts

• Caddy comme seule entrée Docker publique, avec uniquement les ports TCP 80/443 de l’hôte, ainsi que le pont externe réutilisable infra-edge.
• Uptime Kuma avec données persistantes et liaison d’administration exacte 127.0.0.1:3001, accessible seulement par redirection locale sur SSH via Tailscale.
• Un point /healthz en HTTPS pour infra.example.com, dont Caddy gère le certificat et la redirection HTTP vers HTTPS.

Modifications

• La mention « UFW actif » ne suffit plus à accepter la sécurité des ports Docker. Chaque déploiement vérifie ensemble les liaisons Compose, docker inspect, les sockets de l’hôte, UFW et les sondes depuis une autre machine.
• Ajout d’un test de survie à un redémarrage contrôlé : reconnexion uniquement par Tailscale, puis nouvelle validation de l’accès d’administration, des conteneurs, de l’état persistant, de TLS, des chemins refusés et des unités en échec.

Vérifications

• L’audit d’exposition n’a trouvé que Caddy TCP 80/443 sur les adresses publiques ; l’unique liaison d’hôte d’Uptime Kuma était 127.0.0.1:3001, sans autre port d’hôte Docker.
• SSH et TCP 3001 sur l’IP publique ont expiré depuis WSL2. Avec la validation normale du certificat, le point HTTPS a répondu 200 et ok, tandis que HTTP a répondu 308.
• Après un redémarrage contrôlé, Tailscale, Docker, Caddy et Kuma sain ont redémarré automatiquement, l’état initialisé de Kuma a persisté et systemctl --failed n’a signalé aucune unité.

Suite

• Conserver les migrations d’applications, l’épinglage des images, la mise en place des sauvegardes et les tests de restauration comme phases ultérieures séparées, sans élargir le changement d’entrée partagée.

2026-08-04 — Modernisation de l’environnement WSL

Ajouts

• Un processus sûr d’instantanés de configuration avec sommes de contrôle, exports Conda, listes de paquets et outils de restauration. Les projets, clés SSH privées et secrets du shell sont volontairement exclus.

• Une commande maintain pour l’entretien courant d’Ubuntu :

  maintain status   # disque, caches et mises à jour en attente
  maintain update   # mises à niveau Ubuntu sûres sans réinstallation
  maintain clean    # caches de paquets reproductibles uniquement
  maintain all      # mise à jour, nettoyage et rapport

• L’installation automatique des mises à jour de sécurité Ubuntu via systemd, limitée aux sources de sécurité officielles et sans redémarrage automatique de WSL.

• Des outils légers pour le terminal : fd, jq, shellcheck, pipx, ncdu, direnv et hyperfine.

• Un utilitaire Windows facultatif pour compacter le VHDX et récupérer de l’espace sur l’hôte après un nettoyage important des caches Linux.

Modifications

• Node.js est passé de la version 20 à 24.18.1, et la version épinglée du site a été mise à jour en conséquence.
• Conda n’active plus base à chaque ouverture de terminal. Il se charge à la première utilisation : conda activate <environment> reste disponible, tandis que les shells ordinaires utilisent Python d’Ubuntu.
• Le démarrage du shell élimine les doublons du PATH, emploie des alias Git et système plus prudents, et intègre zoxide ainsi que direnv.
• Environ 18 Go de caches de paquets ont été supprimés. L’espace est d’abord libéré dans WSL ; la réduction du VHDX Windows reste une opération distincte et explicite.

Vérifications

• Les builds Docusaurus de production ont réussi en anglais, chinois simplifié et français.
• Les projets Vite et Next.js ont passé leurs vérifications de build et de test applicables ; la dette lint préexistante n’a pas été modifiée.
• Ubuntu a installé toutes les mises à jour en attente sans paquet cassé ou partiellement configuré.
• Un shell neuf a confirmé le chargement différé de Conda, la déduplication du PATH et le bon fonctionnement des commandes de maintenance.
• L’instantané final a passé toutes les vérifications SHA-256 et ne contient ni clé privée ni fichier de secrets.

Suite

• Migrer le développement quotidien de root vers un utilisateur WSL ordinaire seulement après avoir sécurisé les modifications actives des dépôts.
• Garder la migration des projets séparée de la maintenance de l’environnement afin de pouvoir vérifier facilement la propriété des fichiers et la reconnexion de VS Code, puis revenir en arrière si nécessaire.

Modèle d’entrée

## YYYY-MM-DD — Résultat concis

### Ajouts
- Nouvelle capacité et commande ou point d’entrée principal.

### Modifications
- Changement de comportement important et sa raison.

### Vérifications
- Résultat de build, de test, de contrôle de santé ou de sauvegarde.

### Suite
- Travail volontairement différé, le cas échéant.

Mes lectures