La branche accueil-derniers-articles portait cette section, mais aussi une
seconde version du hook — or celui de main fait déjà le travail, et tourne.
Garder les deux aurait fait un conflit pour rien.
Un paragraphe est corrigé au passage : il annonçait que le hook faisait foi
sur le .htaccess et qu'il fallait y ajouter ses règles. Celui de main ajoute
son bloc à la suite d'un .htaccess existant au lieu de le remplacer ; les
règles durables se placent donc dans docs/.htaccess, que MkDocs recopie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014SsLBE8w2R235EG5an6Knb
Revue croisée avec les guides de référence du domaine. Quatre commandes
échouaient ou donnaient l'illusion de fonctionner :
- journald : le drop-in était édité avant que son répertoire existe,
nano refusait d'enregistrer ;
- restic : les variables posées par « export » ne passent pas sudo, qui
les efface — le dépôt n'était pas celui qu'on croyait ;
- la sauvegarde reposait sur « systemd-run », dont l'unité transitoire
disparaît au redémarrage : c'est la sauvegarde qui s'arrête sans que
personne ne le voie. Remplacée par un .service + .timer persistant ;
- le filet de sécurité du pare-feu n'existait que pour ufw ; l'équivalent
nftables manquait.
Ajouts de fond, par ordre d'importance : vérifier l'empreinte de la clé
d'hôte à la première connexion — le seul moment où une interception est
possible —, régénérer les clés des images clonées, AppArmor, l'audit
Lynis en fin de parcours, la sonde de supervision externe (une alerte
émise par la machine ne dit rien quand la machine est morte), la
journalisation distante, le fichier 20auto-upgrades qui commande
réellement l'automatisme, needrestart non interactif, growpart, la jail
recidive, les clés FIDO2, et AllowGroups à la place d'AllowUsers pour
qu'un second administrateur existe.
Pédagogie : le modèle de menace en ouverture, un niveau par étape avec un
parcours court de quinze minutes, des variables qu'on exporte au lieu de
les remplacer à la main, quatre encadrés « pour comprendre » (FQDN/PTR,
clé publique, activation par socket, tmpfs), et sur les trois étapes où
l'on peut se verrouiller dehors : résultat attendu, si ça échoue, et
comment revenir en arrière. Plus une annexe pour le jour où c'est raté —
console, mode rescue, chroot.
Les avertissements passent en admonitions typées : la couleur distingue
enfin l'information du danger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BE4rvHVETRoWnYNDTGssdo
L'ancienne fiche datait de Debian 11 et s'arrêtait à une liste de
commandes : rien sur les clés SSH, le pare-feu, fail2ban, les mises à
jour automatiques ni la sauvegarde. Elle portait aussi deux erreurs qui
mordent — une locale écrite avec un underscore, et l'ordre des noms sur
la ligne 127.0.1.1 qui décide de ce que renvoie « hostname -f ».
La nouvelle page couvre les quinze étapes, du DNS à la sauvegarde
testée, avec les pièges propres à Trixie : sources deb822, SSH activé
par socket, /tmp en tmpfs. Elle reste générique — aucun service
particulier n'y est déployé.
Deux extensions Markdown sont activées pour elle : les listes de tâches
(la checklist récapitulative) et mermaid (l'ordre des opérations). Aucune
dépendance nouvelle : le thème Material embarque déjà mermaid. Les deux
sont documentées dans la page Markdown du wiki.
L'adresse change, donc l'ancienne reste servie par une page de renvoi.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BE4rvHVETRoWnYNDTGssdo
.gitea-token n'était ni suivi ni ignoré : un « git add -A » l'aurait
embarqué dans un commit, et poussé un secret sur la forge.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BE4rvHVETRoWnYNDTGssdo
Le README et les pages de contribution se contredisaient : « éditer la
page dans Gitea » ignorait la bifurcation devenue la règle, le tableau
d'aiguillage ne connaissait pas trois des pages existantes, et le délai
de publication n'était pas le même des deux côtés. Le README oriente
désormais, le wiki explique — une seule source de vérité par sujet.
Nouvelle page « Relire et fusionner » : ce que fusionner publie, la
relecture, la vérification du build, les pièges du poste — renommer une
page casse son adresse, aucune redirection n'est installée.
Au passage, trois points où les pages ne se répondaient pas : la
publication immédiate depuis Obsidian ne concerne que le clone du dépôt
du wiki, la bifurcation se remet à jour après chaque fusion, et
l'accueil renvoyait au Markdown générique plutôt qu'à notre page.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BE4rvHVETRoWnYNDTGssdo
L'application a quitté alpinux.site.2026 pour son propre dépôt, et elle
est à la racine : plus de sous-dossier dynamic/ à traverser pour le
venv, le .env.example, la mise à jour ou le fichier des quiz.
Au passage, l'unité systemd est dans infra/services/, pas infra/dynamic/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BE4rvHVETRoWnYNDTGssdo
Le premier déploiement depuis le nouveau dépôt a montré deux inexactitudes de
cette page, héritées de sa rédaction initiale :
- le logo n'est pas généré au déploiement. Le thème et les pages chargent le
logo depuis static.alpinux.org par URL complète ; build-assets.py ne sert
qu'à fabriquer les fichiers à y téléverser, et demande Pillow et Chromium,
absents du serveur. L'étape correspondante et les prérequis associés sont
retirés, le script de déploiement n'a jamais appelé ce script.
- le service d'écoute n'est pas injoignable de l'extérieur : Apache proxifie
/deploy vers lui. C'est la signature HMAC qui le protège, pas l'isolement.
Au passage : procédure manuelle présentée comme un secours et non comme le mode
normal, clone par clé de déploiement en lecture seule, et tableau récapitulatif
refait autour du fait que publier se résume à git push.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PcZ7hL9aVvMhRuzxXLT2DG
Ces pages ont été écrites du temps du monorepo et décrivaient encore un clone de
alpinux.site.2026 avec un sous-dossier wiki/, ainsi qu'un déploiement par rsync
depuis un poste local — alors que le serveur construit le site lui-même, déclenché
par un webhook Gitea.
- contribuer.md, linux-mint-guide.md, l'article Linux Mint : liens et URL raw
vers alpinux-wiki. L'URL de install.sh redevient valide au passage : elle
pointait sur code/ à la racine, chemin qui n'existait pas dans le monorepo.
- deploiement-wiki.md : chemins sans le sous-dossier wiki/, script de déploiement
réel (build en staging), webhook décrit comme le mode normal et non plus comme
une option, avec la mise en garde qu'il n'écoute que ce dépôt.
- README.md : flux de publication réel, et le -d indispensable au build local
puisque site_dir vise le DocumentRoot du serveur.
deploiement-dynamic.md mentionne lui aussi un clone du monorepo, mais il concerne
l'application dynamic : à corriger avec son dépôt, pas ici.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PcZ7hL9aVvMhRuzxXLT2DG
Les vhosts, SSL et certificats sont gérés via ISPConfig (owni.alpinux.org:8080).
Supprime les références à a2ensite, certbot et la copie manuelle de vhost.conf.
