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 avec ACCESS_KEY, donc le conteneur et Caddy utilisent un code dérivé lié uniquement à la 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 de compatibilité aval a récupéré des éléments représentatifs sans toucher les données de production.

Suite

• Réunir en phase 4 la sauvegarde/restauration SQLite, la migration du planificateur, la bascule vers RSSHub et la décision de retirer le 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, 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’initialisation 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.

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 à jour Ubuntu sur place et sans suppression
  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 vérifier et d’annuler indépendamment les permissions et la reconnexion de VS Code.

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 · Les notes ouvertes sont mémorisées dans ce navigateur.