www.alpinux.org — page d'accueil statique de l'association, déployée par webhook

Find a file

Cédrix 256695b58d Cesser de télécharger 175 ko de logo pour en afficher 90 pixels L'en-tête chargeait alpinux-logo.png — 1024×1024, 175 ko — pour une image affichée en 90 px sur l'accueil et 66 px ailleurs. Le navigateur téléchargeait donc dix fois le poids de la page elle-même, rien que pour la réduire. alpinux-logo-180.png, déposé à côté sur static, fait 23 ko et couvre les écrans à haute densité. Les deux domaines tiers de la page — static et le wiki — gagnent au passage un preconnect : la poignée de main TLS commence pendant que le HTML se lit, au lieu d'attendre la première image. Retire aussi Gitea du menu, comme le wiki et les mises à jour avant lui : le service garde sa carte plus bas. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JYfYUZRcJmmEWJwAxZb4o2		2026-09-23 14:06:00 +02:00
deploiement	Publier toutes les pages du wiki, et une vraie page d'erreur	2026-09-23 12:42:03 +02:00
site	Cesser de télécharger 175 ko de logo pour en afficher 90 pixels	2026-09-23 14:06:00 +02:00
.gitignore	Détacher www.alpinux.org du monorepo, avec son déploiement	2026-09-20 09:47:18 +02:00
README.md	Noter ce que le serveur a fallu régler pour la 404	2026-09-23 13:52:06 +02:00

README.md

www.alpinux.org

Le site public de l'association — du HTML statique, servi sur https://alpinux.org et https://www.alpinux.org : la page d'accueil, la page des mises à jour du wiki, et la page d'erreur 404.

Elle affiche deux choses qu'elle ne contient pas : l'agenda, lu dans le calendrier public Nextcloud, et les dernières pages du wiki, lues dans derniers-articles.json que le wiki publie à chaque build. Si l'une ou l'autre source est injoignable, la section correspondante se masque et le reste de la page tient debout. Le journal des nouveautés, lui, vit dans le dépôt : site/nouveautes.json.

Je veux…

Ce que vous voulez faire	Ce que vous faites
Modifier l'accueil	Éditer `site/index.html`, pousser sur `main` — la mise en ligne suit
Annoncer une nouveauté	Ajouter une entrée en tête de `site/nouveautes.json` (voir plus bas)
Voir le rendu avant de pousser	`python3 -m http.server -d site` puis http://localhost:8000
Comprendre pourquoi ça n'est pas en ligne	`tail -20 /var/log/www-deploy.log` sur le serveur
Republier sans nouveau commit	`sudo -u abonnelc /opt/www-alpinux/deploy-www.sh`
Réinstaller la chaîne de déploiement	`sudo bash deploiement/installer.sh`
Reprendre une modification de `deploiement/`	Relancer `installer.sh` : le serveur exécute sa copie dans `/opt/www-alpinux`, pas celle du dépôt

En local, l'agenda reste vide : /public-calendars/… est relayé vers Nextcloud par le serveur, pas par http.server. Les articles du wiki, eux, s'affichent normalement.

Structure

alpinux-www/
├── site/                 ce qui part en ligne, tel quel
│   ├── index.html            l'accueil, son style et ses scripts en ligne
│   ├── modifications.html    toutes les pages du wiki, datées
│   ├── 404.html              la page d'erreur
│   ├── commun.css            la charte des deux pages secondaires
│   ├── nouveautes.json       le journal des nouveautés, lu par l'accueil
│   ├── robots.txt
│   └── sitemap.xml
└── deploiement/          la chaîne, versionnée avec le site
    ├── installer.sh          pose tout sur le serveur (root, une fois)
    ├── deploy-www.sh         git pull + rsync vers le DocumentRoot
    ├── webhook.py            service d'écoute, 127.0.0.1:9877
    ├── www-webhook.service   unité systemd
    └── vhost-deploy.conf     le relais Apache, pour trace

Annoncer une nouveauté

La section « Nouveautés » de l'accueil est dessinée à partir de site/nouveautes.json — un tableau d'entrées, url facultative :

{
  "date": "2026-09-23",
  "titre": "Listes de diffusion",
  "texte": "Une phrase ou deux, à hauteur de visiteur.",
  "url": "https://messagerie.alpinux.org"
}

L'ordre du fichier n'a pas d'importance : la page trie sur date et n'affiche que les six entrées les plus récentes. Les plus anciennes restent dans le fichier, comme mémoire. Une entrée sans titre ou sans date au format AAAA-MM-JJ est ignorée ; si le fichier disparaît ou devient illisible, la section se masque comme les deux autres.

Les mises à jour du wiki

site/modifications.html liste toutes les pages de wiki.alpinux.org, de la plus récemment retouchée à la plus ancienne, avec un filtre par titre ou rubrique. Elle lit https://wiki.alpinux.org/toutes-les-pages.json, que le build du wiki publie à chaque fois — comme il publie déjà derniers-articles.json pour l'accueil.

Si ce fichier manque, la page se rabat sur derniers-articles.json et le dit : on obtient les vingt dernières pages au lieu de toutes, plutôt qu'une page vide. Les deux sources injoignables, elle affiche un message et renvoie vers le wiki.

Le contenu se change donc dans le dépôt du wiki, pas ici : ajouter une page à la navigation du wiki suffit à la faire apparaître.

La page 404

site/404.html reprend la charte du site, annonce clairement l'erreur et propose l'accueil, le wiki, les mises à jour et les listes de diffusion. Elle porte noindex, follow : une page d'erreur n'a rien à faire dans un moteur de recherche, mais ses liens restent bons à suivre.

Elle dépend de deux réglages qui vivent sur le serveur, pas dans ce dépôt public — en place depuis le 23 septembre 2026 :

le .htaccess du DocumentRoot porte ErrorDocument 404 /404.html, et n'envoie plus au routeur PHP que les adresses commençant par public-calendars ;
index.php, ce routeur, finit par un http_response_code(404) suivi de la page, au lieu du readfile('index.html') qu'il faisait avant.

Jusque-là, toute adresse inconnue recevait l'accueil avec un code 200 : le visiteur croyait avoir atterri quelque part, et les moteurs de recherche enregistraient autant de pages valides qu'il existe d'adresses fausses. Si ISPConfig réinitialise un jour ces fichiers, c'est ce comportement qui revient — et c'est ce qu'il faut reposer.

# ce qu'on doit lire
curl -o /dev/null -w '%{http_code}\n' https://alpinux.org/adresse-qui-nexiste-pas   # 404
curl -o /dev/null -w '%{http_code}\n' https://alpinux.org/                          # 200
curl -s https://alpinux.org/public-calendars/n5BWPYsxw7FCYozM | grep -c BEGIN:VEVENT  # > 0

Ce qui se passe après un push

git push  (sur main)
       │
Gitea (origin/main)
       │  webhook  ──▶  https://alpinux.org/deploy  ──▶  service d'écoute (signature vérifiée)
       ▼
deploy-www.sh :  git pull  →  index.html complet ?  →  rsync vers le DocumentRoot
       ▼
https://alpinux.org

Compter moins d'une minute. Le garde-fou est modeste mais réel : un index.html tronqué — transfert coupé, conflit mal résolu — ne part pas en ligne.

Les deux pièges à connaître

Supprimer un fichier ici ne le retire pas du serveur. Le rsync de déploiement est volontairement sans --delete : le DocumentRoot contient aussi des fichiers qui ne sont pas dans ce dépôt — le .htaccess qui relaie /public-calendars vers Nextcloud, les pages d'erreur et les statistiques d'ISPConfig. Un --delete les emporterait. Retirer un fichier en ligne se fait donc à la main, sur le serveur.

Le serveur n'écrit dans le DocumentRoot que par une ACL. web11/web appartient à l'utilisateur web11 ; installer.sh pose un setfacl pour l'utilisateur du service. Si ISPConfig réinitialise les droits du site un jour, le déploiement échouera avec une erreur de permission — relancer installer.sh suffit à la remettre.

Historique

Ce dépôt est né le 2026-09-20, par détachement du monorepo alpinux.site.2026 où la page vivait sous home/. Elle y était déployée à la main, et le dépôt avait fini par diverger : la version en ligne portait quatre mois de modifications faites directement sur le serveur et jamais revenues dans git. C'est ce qui a motivé le webhook.