Merge branch 'main' into main

9 files changed, 425 insertions, 32 deletions

diff --git a/content/operations/2024-05-12-migration-email.md b/content/operations/2024-05-12-migration-email.md
new file mode 100644
index 0000000..45edbb4
--- /dev/null
+++ b/content/operations/2024-05-12-migration-email.md
@@ -0,0 +1,180 @@
+---
+title: "Mai 2024"
+description: "Mai 2024: perte d'une zone, migration des services email"
+date: 2024-05-12
+dateCreated: 2024-05-12
+weight: 30
+extra:
+  parent: 'operations/pannes.md'
+---
+
+12 mai 2024 : coupure de la connexion fibre sur le site à Lille (scorpio).
+Les services cryptpad et email sont impactés.  
+Après plus de 24h de coupure, on décide de migrer les services email vers un autre site pour éviter de perdre des emails qui seraient dans la file de serveurs emails à destination de deuxfleurs.
+
+# Infos infra
+
+- Sites: scorpio (Lille), neptune (Orsay)
+- machine à Lille dont on migre : ananas
+- Orsay IPv4 : 82.67.87.112 , IPv6 : 2a01:e0a:2c:540::33
+- Machines Orsay : {courgette,celeri,concombre}.machine.deuxfleurs.fr
+  + courgette (12G RAM, 500G HDD, 500G SSD Samsung 980), avec postgres (pinned)
+  + celeri (8G RAM, 2T HDD, 500G SSD Samsung 980), avec matrix
+  + concombre (8G RAM, 500G SSD Samsung 980, 500G HDD), avec jitsi/plume/woodpecker
+
+# Feuille de route emails
+
+- vérifier l'existence et l'âge des backups emails
+  + dernier backup: 9644354b  2024-05-11 02:00:05  89e2ffda19db              /mail
+  + se convaincre que c'est un backup suffisamment récent par rapport à la coupure qui a commencé samedi 11 matin à 7h07
+- ✅ choisir un serveur à Orsay
+  + courgette a postgres pin sur cette machine, on choisit une autre machine parmi celeri/concombre
+  + choix de celeri
+
+- ✅ s'assurer que restic existe sur la machine destination et qu'il est en version 0.16 ou plus
+- ✅ restore le backup avec restic (cf cheatsheet et le script restic_restore_gen) depuis la machine destination
+
+- ✅ vérifier que les entrées SPF, DKIM, DMARC sont compatibles avec Orsay
+  + entrée SPF à modifier sur Gandi
+    * entrée mx qui devrait suffire ?
+    * mais on pourrait ajouter neptune.site.deuxfleurs.fr (et enlever orion.site.deuxfleurs.fr qui n'existe plus)
+  + rien à faire pour DKIM/DMARC?
+    * Pour DKIM et DMARC rien à faire tant que la clef ne change pas, ce sont des politiques
+- ✅ vérifier que le reverse-DNS de l'IP d'Orsay est bon
+  + C'est fait:
+    * dig +short -x 82.67.87.112: neptune.site.deuxfleurs.fr.
+- ✅ vérifier que les autres entrées DNS (A,AAAA, MX) sont comme il faut :
+  + ✅ MX deuxfleurs.fr (pas besoin de modifier, il pointe bien vers smtp.deuxfleurs.fr)
+  + ✅ A smtp.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+  + ✅ AAAA smtp.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+  + ✅ A imap.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+  + ✅ AAAA imap.deuxfleurs.fr (pas besoin de modifier à la main, d53 s'en charge !)
+
+- ✅  comprendre où étaient stockés les données des emails sur ananas (chemin sur le FS)
+  + a priori /mnt/ssd/mail d'après la feuille de route précédente
+  + retrouvable dans le fichier hcl du service email -> /mnt/ssd/mail en effet
+- ✅  stopper le service nomad email (FAIT)
+  + ça devrait être OK vis à vis des enregistrement DNS et D53, car D53 ne gère pas le MX (si on retire un enregistrement DNS et quelqu'un fait une requête il va recevoir un NXDOMAIN qui sera peut être mis en cache pendant plus longtemps que l'on voudrait)
+
+- ✅  pause pendant le transfert des données !
+
+- ✅  faire des tests sur les données ?
+  + ✅ verifier que le chemin est ok (/var/ssd/mail et pas /var/ssd/mail/mail/ - restic est piegeur)
+  + ✅ il y a bien les users
+  + que peut-on faire de plus que faire confiance à restic ?
+- ✅  vérifier que les permissions (owner/group/etc) des fichiers sont ce qu'on veut
+  + https://git.deuxfleurs.fr/Deuxfleurs/nixcfg/src/branch/main/cluster/prod/app/email/build/dovecot/entrypoint.sh
+  + -> le conteneur fait le bon chown au démarrage, donc il n'y a rien à faire
+
+- ✅ relire et modifier le fichier nomad pour le service email pour déployer sur la nouvelle machine
+- ✅ démarrer le service nomad sur la nouvelle machine
+- ✅ tester les accès (IMAPS: 993, SMTPS: 465, SMTP: 25)
+  + ✅ openssl s_client -connect host:port en IPv4 et IPv6 direct
+  + ✅ vérifier que ça marche aussi avec {smtp,imap}.deuxfleurs.fr
+  + ✅ vérifier avec thunderbird
+  + ✅ vérifier SoGo
+    * interface web (OK)
+    * Exchange Active Sync
+  + ✅ vérifier Alps
+
+ℹ️ DÉBLOQUER LE PORT 25 DE LA FREEBOX PARDIOU !
+
+- ✅ vérifier la réception des emails
+  + ✅ depuis gandi (+ autres ?)
+  + ✅ depuis microsoft (OK)
+  + ✅ depuis google (OK)
+  + ✅ depuis 6clones https://www.6clones.fr/emails
+- ✅ vérifier l'envoi d'emails
+  + ✅ Le port 25 est bloqué sur la freebox 😭 😭 😭 😭 😭 😭 😭 😭
+  + ✅ chez gandi (+ autres ?)
+  + 🟧 chez microsoft (en spam)
+  + ✅ chez google
+  + ✅ avec mailtester -> https://www.mail-tester.com/
+  + ✅ vers 6clones https://www.6clones.fr/emails
+
+- ✅  configurer le backup des emails pour backuper la nouvelle machine au lieu d'ananas
+  + lancer un backup pour vérifier que ça fonctionne
+
+- ✅  Commit + Push les modifications qui ont été faites sur nixcfg !!!!
+
+- ⌛ réputation IP
+  + ✅ Spamhaus https://www.spamhaus.org/query/ip/82.67.87.112 a l'air bon
+  + ✅ Microsoft
+    * http://postmaster.live.com/snds/ (impossible à faire car on ne détient pas les IP / il n'y a pas besoin de le faire)
+    * Office 365 Anti-Spam IP Delist Portal  https://sender.office.com/
+  + ✅ Baracuda Networks  https://barracudacentral.org/ (OK: "not listed as poor")
+  + ✅ Trend Micro  http://www.mail-abuse.com/cgi-bin/lookup?ip_address=82.67.87.112
+    * BAD "dial-up user list". Demande de délistage soumise (avec email de contact prod-sysadmin@deuxfleurs.fr).
+    * on a reçu un email disant que c'est délisté; à rechecker bientôt ?
+  + ⌛ Spam-RBL https://spam-rbl.fr/bl.php?ip=82.67.87.112
+    * partiellement listé
+  + ✅ Abusix https://lookup.abusix.com/search?q=82.67.87.112
+    * not listed!
+  + ✅ SORBS http://www.sorbs.net/cgi-bin/dulexclusions
+    * OK!
+    * Du coup c'est très cool, on va ameliorer notre delivery !
+  + Pour info seulement :
+    * Meta checker -> https://multirbl.valli.org/lookup/82.67.87.112.html
+      ** partiellement listé: rbl.rbldns.ru ; a recheck dans qq heures d'après leur documentation
+    * DNS checker -> https://dnschecker.org/ip-blacklist-checker.php?query=82.67.87.112
+      ** partiellement listé: https://matrix.spfbl.net/82.67.87.112 veut $2
+
+Une fois Lille de retour :
+- ⌛ renommer le dossier contenant les données mail en mail_deprecated
+- ⌛ faire un diff entre les données sur ananas et les données du backup que l'on a restore
+- ⌛ migrer les données du diff si on peut ?
+  + On peut probablement se baser sur les dates de création des fichiers sur ananas
+
+
+## Exemple de message à envoyer aux blocklists
+
+### Reason for removal request
+
+> [EN] Deuxfleurs (deuxfleurs.fr) is an experimental & alternative non-profit email provider. This is why we are sending (legitimate!) emails from a residential IP address. We are sending mainly organic emails and few transactional emails (we don't do marketing or newsletter emails). We have strict policies to ensure that emails sent from our servers are legitimate, here is a non-exhaustive list of our trust policy: account creation is manually validated, our SMTP server is authenticated (no SMTP open relay), SPF, DKIM & DMARC are configured, our servers are closely monitored. We operate from a static IPv4 and IPv6 block bound to the fiber line allocated by the ISP, hence the dial-up classification. Thanks in advance for keeping the Internet an open place!
+
+> [FR] Deuxfleurs (deuxfleurs.fr) est une association fournissant des services d'hébergement email, et nous hébergeons nos services derrière des adresses IP résidentielles.
+> Nous envoyons principalement des emails non-automatisés (ni emails marketing ou démarchage). Nous implémentons des politiques strictes pour garantir que les emails envoyés depuis nos serveurs sont légitimes : les comptes sont validés manuellement par les administrateurs, notre serveur SMTP est authentifié (pas de relai SMTP ouvert), nous avons configuré SPF, DKIM et DMARC, et nos serveurs sont monitorés.
+> Nos serveurs opèrent derrière des IPv4 et IPv6 statiques liés à une ligne fibre FTTH (IPs probablement allouées précédemment par le FAI à des lignes DSL).
+> Merci d'avance !
+
+### Reason why the IP address is not in static allocation
+
+> This is a static allocation from the ISP. This used to be an IP address associated with DSL lines from our ISP, now recycled for FTTH lines.
+
+# Feuille de route cryptpad
+
+- problème : les backups sont probablement toujours faits depuis un ancien déploiement cryptpad
+  + confirmer ça -> oui en effet
+- si c'est bien ça, quelle taille font les données cryptpad ? Adrien peut-il les uploader en 4g en se connectant en local à ananas ?
+  + Probablement autours de 1.5/2Gio, vu que c'est ce que Quentin a récupéré du backup qui n'est pas si vieux que ça
+  + c'est l'ordre de grandeur de quand on a fait la snapshot de migration aussi
+...
+- ✅ changer la source des backups cryptpad vers le nouveau déploiement
+
+# Cheatsheet
+
+## Backups
+
+Pour lister et récupérer un backup, depuis le dépot nixcfg:
+
+```
+./restic_summary
+./restic_restore_gen mail <ID> /mnt/ssd
+```
+
+## Comparer les données entre deux dossiers
+
+```
+rclone hashsum md5 /mnt/storage/mail-bckp-2/ --output-file mail-hdd.sum
+rclone hashsum md5 /mnt/ssd/mail/ --output-file mail-ssd.sum
+sort mail-ssd.sum | md5sum
+sort mail-hdd.sum | md5sum
+```
+
+# Idées pour le futur
+- les backups de cryptpads qui sont cassés => réfléchire a une stratégie de *tests* de backups
+- on pourrait setup un MX secondaire qui queue indéfinimenet et essaie de push sur le primaire, pour pas perdre d'emails entrants en cas de down de la zone principale. /!\ a bien backup aussi cette queue
+  + MX secondaire
+  + sur le primaire, penser a bind la queue postfix aussi (ajd on pourrait perdre des emails récement reçu, mais pas encore délivré)
+- on a encore des backups de plume, mais ils sont vieux. p-e plus besoin maintenant que les médias sont sur s3?
+- hcl de backups => cron deprecated, use crons instead (ça accept les listes de cron maintenant)
diff --git a/content/operations/_index.md b/content/operations/_index.md
index 7f64bcd..9216c0f 100644
--- a/content/operations/_index.md
+++ b/content/operations/_index.md
@@ -11,9 +11,11 @@ Ce manuel recense notre savoir-faire technique, il a pour but d'accompagner nos
 
 # Notre jargon
 
-* _Un nœud_, c'est un **ordinateur** configuré pour fournir un **service** en collaborant avec d'autres.
+* _Un nœud_ (ou _node_ en anglais), c'est un **ordinateur unique** configuré pour fournir un **service** en collaborant avec d'autres.
 
-* _Une grappe_, c'est **un ensemble de nœuds** qui **coopèrent** pour fournir un **service**.
+* _Un site_ ou _une zone_, c'est un **ensemble d'ordinateurs qui sont situés au même endroit géographique**.
+
+* _Une grappe_ (ou _cluster_ en anglais), c'est **un ensemble de nœuds** qui **coopèrent** pour fournir un **service**. Même si c'est normalement le cas, une grappe n'est pas forcément composée de plusieurs sites ! On peut avoir une grappe sur une seule zone.
 
 	Une grappe est **gérée de façon cohérente** (avec le même système logiciel), **plus ou moins autonome** (elle ne dépend pas du reste du monde pour fournir des services web), **par une entité définie** (une personne physique ou un groupe de personnes).
   
diff --git a/content/operations/email_personnalise.md b/content/operations/email_personnalise.md
index 2b7433e..13ef50a 100644
--- a/content/operations/email_personnalise.md
+++ b/content/operations/email_personnalise.md
@@ -29,14 +29,21 @@ Nous vous expliquons ici comment héberger une boîte mail avec un nom de domain
 
 	* Lancez `imap-backup backup --accounts=<votre_adresse_mail>`, ce qui va télécharger tous vos e-mails sur votre ordinateur (c'est long).
 	
-1. Communiquez votre nom de domaine à un⋅e administrateur⋅ice de Deuxfleurs pour qu'iel l'ajoute à :
-
-	* la liste des [domaines gérés par Deuxfleurs dans le LDAP](https://guichet.deuxfleurs.fr/admin/ldap/ou=domains,ou=groups,dc=deuxfleurs,dc=fr),
-	* et dans la [table de signature DKIM](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg/src/branch/main/cluster/prod/app/email/config/dkim/signingtable).
-
-1. Communiquez-lui l'adresse e-mail que vous souhaitez utiliser. Vous pouvez ajouter autant d'alias que vous souhaitez, il seront reçus sur la même boîte mail. 
-
-	L'admin devra les ajouter ligne à ligne dans l'entrée `mail` dans votre profil utilisateur (en laissant votre adresse `@deuxfleurs.fr` en premier).
+1. Communiquez l'adresse courriel souhaitée à un⋅e administrateur⋅ice de Deuxfleurs. Iel devra réaliser les opérations suivantes :
+
+	* ajouter le nom de domaine à la liste des [domaines gérés par Deuxfleurs dans le LDAP](https://guichet.deuxfleurs.fr/admin/ldap/ou=domains,ou=groups,dc=deuxfleurs,dc=fr). Pour cela, une fois sur la page guichet :
+		* appuyer sur le bouton vert « +objet »
+		* Dans `Identifiant`, on peut mettre l'identifiant de l'usager⋅e concerné⋅e
+		* Dans `Description`, mettre quelque chose comme `Nom de domaine de XXX`
+		* Dans `StructuralObjectClass`, mettre `groupOfNames`
+		* Dans `ObjectClass`, mettre `groupOfNames`, puis, à la ligne, `top`, et, encore à la ligne, `dNSDomain`
+		* Valider avec le bouton « Créer l'objet »
+		* Ajouter un attribut `domain` et y mettre le nom de domaine de l'adresse courriel souhaitée
+	* ajouter le nom de domaine à la [table de signature DKIM](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg/src/branch/main/cluster/prod/app/email/config/dkim/signingtable). Une fois fait, iel devra la déployer :
+		* il faut lancer le `tlsproxy` du dépôt `nixcfg` en visant `prod`
+		* sur un autre terminal, se connecter en SSH sur une de ces machines
+		* sur encore un autre terminal, en local, à l'intérieur du dossier `nixcfg`, se situer à l'emplacement `cluster/prod/app/email/deploy`. Puis lancer `nomad plan email.hcl`. Si et seulement si la sortie paraît satisfaisante, alors lancer `noman run email.hcl`.
+	* ajouter l'adresse courriel dans l'entrée `mail` de votre profil utilisateur LDAP. Il doit y avoir une adresse courriel par ligne, et il faut laisser l'adresse en `@deuxfleurs.fr` à la première. On peut ici ajouter autant d'alias que l'on veut, et tout sera reçu sur la même boîte de réception.
 
 1. Vous devez ensuite rajouter les entrées pour votre nom de domaine en éditant votre zone DNS (si vous n'y comprenez rien, faites-vous aider de l'admin) :
 
diff --git a/content/operations/paliers.md b/content/operations/paliers.md
new file mode 100644
index 0000000..70c4fce
--- /dev/null
+++ b/content/operations/paliers.md
@@ -0,0 +1,15 @@
+---
+title: "Historique des paliers"
+description: "Historique des passages de paliers"
+weight: 80
+sort_by: "weight"
+extra:
+  parent: 'operations/_index.md'
+---
+
+Cette page sert à entretenir un historique des passages de paliers que nous réalisons dans le cadre de la modération des activités sur l'infrastructure de Deuxfleurs. La méthodologie de celle-ci, décrite dans nos [conditions générales d'utilisation](@/vie_associative/cgu.md), a été définie début mars 2024, lors de notre premier incident en la matière.
+
+## Samedi 22 juin 2024
+* Passage au palier 1 après avoir constaté beaucoup de connexions durant la nuit sur Jitsi (entre minuit et 5h du matin), sur les dernières semaines.
+* Passage au palier 2 après avoir constaté des noms de salon Jitsi présents lors du dernier incident (c'est-à-dire le premier de notre association).
+* On met en place au niveau HTTP le rejet des connexions sur les salons concernés. On met en place sur Jitsi un message d'avertissement rappelant notre détermination à lutter contre les mésusages de nos services. Nous constatons que notre service Jitsi est le 15ème résultat obtenu quand on type « Jitsi » sur Google avec une IP française, le 5ème qui correspond à une instance Jitsi. On modifie donc notre `robots.txt` pour que Jitsi ne soit plus indexé.
\ No newline at end of file
diff --git a/content/operations/prérequis-site.md b/content/operations/prérequis-site.md
new file mode 100644
index 0000000..f124568
--- /dev/null
+++ b/content/operations/prérequis-site.md
@@ -0,0 +1,58 @@
+---
+title: "Prérequis pour un site"
+description: "Prérequis pour un site"
+date: 2024-05-30
+dateCreated: 2024-05-30
+weight: 10
+extra:
+  parent: 'operations/site.md'
+---
+
+# Qu'est-ce qu'un site géographique
+
+Dans un *site géographique*, on installe une *grappe d'ordinateurs* au sein d'un *réseau local*, qu'on connecte au cluster de Deuxfleurs.
+
+On peut distinguer deux types de sites : 
+
+* _Dans un centre de données_ : chaque ordinateur de la grappe appartient au même centre de données, dispose d'une adresse IP fixe qui le connecte directement à Internet. 
+
+	Dans ce cas-ci, **l'installation et l'administration sont assez simples** (on a moins de concepts à avaler que chez un particulier).
+  Par contre, **nous ne sommes pas chez nous** : le propriétaire du centre de données peut accéder aux disques, et voit ce qui passe sur le réseau. **Chiffrement du disque vivement conseillé.**
+  
+* _Chez un particulier_ : la grappe est reliée à Internet par une *box*, qui filtre le trafic réseau selon des règles variables. La grappe se partage l'adresse IP de la box (qui peut changer régulièrement, être en IPv4 ou en IPv6). 
+
+	Dans ce cas de figure, **l'installation comme l'administration demandent plus de connaissances** : pour caricaturer, on doit installer et administrer la grappe **malgré le Fournisseur d'Accès Internet** (FAI), qui considère *a priori* que son abonnement ne sert pas à héberger des services web.
+  
+  On aura affaire à sa box (NAT, pare-feu...), au manque de garanties concernant notre adressabilité (IPv4 dynamique, IPv6 ? ...), ce qui va nous mener à devoir faire du routage. Le nœud du problème, c'est que chaque ordinateur de la grappe n'aura pas pignon sur rue (pas d'adresse IP publique et fixe par machine).
+  
+  Néanmoins, **on est chez nous !** Votre disque dur - qui contient les données personnelles de vos usagers chéris - est sous vos yeux, bien au chaud. Le seul curieux qui voit passer votre trafic réseau est votre FAI : *rien de nouveau sous le soleil*.
+ 
+# Pré-requis humains 
+
+- assurer une sécurité physique vis-à-vis des machines et des données qu'elles contiennent
+- pouvoir intervenir physiquement dans un délai de quelques jours en cas de panne d'une machine ou du réseau
+- être d'accord pour partager son réseau et son IP avec l'infrastructure de Deuxfleurs (ou alors disposer d'une seconde connexion à Internet)
+
+# Pré-requis techniques de base
+
+- disposer d'une connexion fibre / FTTH avec un débit montant d'au moins 100 Mbps
+- disposer d'une IPv4 publique dédiée et non partagée (la plupart des FAI proposent cette option)
+- avoir un FAI qui fournit de l'IPv6
+- avoir un routeur ou une box qui supporte UPnP
+- pouvoir configurer le firewall IPv6 sur le routeur ou la box pour autoriser le trafic IPv6 entrant vers les noeuds Deuxfleurs
+- ne pas déjà héberger des serveurs chez soi qui auraient besoin des mêmes ports TCP/UDP que Deuxfleurs (80, 443, 25, ...)
+
+# Pré-requis supplémentaires pour le mail
+
+Héberger un service mail demande des pré-requis supplémentaires :
+
+- pouvoir définir le reverse DNS associé à son IPv4 publique.  Free le permet, ainsi que la plupart des FAI associatifs.  Orange et SFR ne le permettent pas.
+- s'assurer que le FAI ne bloque pas le port 25 en entrée.  Certains FAI comme Free bloquent par défaut mais permettent de débloquer sur demande.  Orange ne permet pas de débloquer le port 25.
+
+# Fournisseurs d'accès Internet recommandés
+
+Pour l'instant, les FAI suivants ont été testés et remplissent tous les pré-requis :
+
+- Free
+- Belgacom
+- Rézine
diff --git a/content/operations/prérequis.md b/content/operations/prérequis.md
index 37d5179..128f2ee 100644
--- a/content/operations/prérequis.md
+++ b/content/operations/prérequis.md
@@ -1,7 +1,7 @@
 ---
 title: "Prérequis pour un nœud"
 description: "Prérequis pour un nœud"
-date: 2022-01-09T13:29:29.710Z
+date: 2024-05-30
 dateCreated: 2021-12-28T14:33:59.088Z
 weight: 10
 extra:
@@ -22,20 +22,7 @@ Héberger des services web est une tâche à la portée de la plupart des ordina
 
 # Choix d'un site géographique
 
-Dans un *site géographique*, on installe une *grappe d'ordinateurs* au sein d'un *réseau local*, qu'on connecte au cluster de Deuxfleurs.
+Dans la plupart des cas, le nouveau noeud sera ajouté à un site géographique existant.
 
-On peut distinguer deux types de sites : 
+Si il est envisagé d'installer un nouveau site géographique, voir : [guide d'installation d'un nouveau site géographique](@/operations/site.md)
 
-* _Dans un centre de données_ : chaque ordinateur de la grappe appartient au même centre de données, dispose d'une adresse IP fixe qui le connecte directement à Internet. 
-
-	Dans ce cas-ci, **l'installation et l'administration sont assez simples** (on a moins de concepts à avaler que chez un particulier).
-  Par contre, **nous ne sommes pas chez nous** : le propriétaire du centre de données peut accéder aux disques, et voit ce qui passe sur le réseau. **Chiffrement du disque vivement conseillé.**
-  
-* _Chez un particulier_ : la grappe est reliée à Internet par une *box*, qui filtre le trafic réseau selon des règles variables. La grappe se partage l'adresse IP de la box (qui peut changer régulièrement, être en IPv4 ou en IPv6). 
-
-	Dans ce cas de figure, **l'installation comme l'administration demandent plus de connaissances** : pour caricaturer, on doit installer et administrer la grappe **malgré le Fournisseur d'Accès Internet** (FAI), qui considère *a priori* que son abonnement ne sert pas à héberger des services web.
-  
-  On aura affaire à sa box (NAT, pare-feu...), au manque de garanties concernant notre adressabilité (IPv4 dynamique, IPv6 ? ...), ce qui va nous mener à devoir faire du routage. Le nœud du problème, c'est que chaque ordinateur de la grappe n'aura pas pignon sur rue (pas d'adresse IP publique et fixe par machine).
-  
-  Néanmoins, **on est chez nous !** Votre disque dur - qui contient les données personnelles de vos usagers chéris - est sous vos yeux, bien au chaud. Le seul curieux qui voit passer votre trafic réseau est votre FAI : *rien de nouveau sous le soleil*.
-  
diff --git a/content/operations/site-openwrt.md b/content/operations/site-openwrt.md
new file mode 100644
index 0000000..bd70974
--- /dev/null
+++ b/content/operations/site-openwrt.md
@@ -0,0 +1,94 @@
+---
+title: "Configuration réseau OpenWrt"
+description: "Configuration réseau OpenWrt"
+date: 2024-05-30
+dateCreated: 2024-05-30
+weight: 20
+extra:
+  parent: 'operations/site.md'
+---
+
+# Pourquoi OpenWrt
+
+Pour installer un site géographique, il y a deux possibilités pour gérer le réseau :
+
+- utiliser la box fournie par le FAI
+- utiliser son propre routeur
+
+Certaines box de FAI sont limitées : elles ne permettent parfois pas de configurer le pare-feu IPv6, ou bien elles ont un support d'UPnP pas assez fiable pour les besoins de Deuxfleurs.
+
+Dans ce cas, utiliser son propre routeur et y installer [OpenWrt](https://openwrt.org/) est un choix naturel : c'est un projet en logiciel libre, avec une grande communauté et beaucoup de modèles matériel supportés.
+Par ailleurs, OpenWrt est très modulaire, on peut installer des paquets additionnels pour rajouter des fonctionnalités comme UPnP.
+
+Attention, installer et configurer OpenWrt demande d'être à l'aise avec SSH, vim, et d'avoir quelques connaissances en réseau.
+
+# Choisir un matériel supporté par OpenWrt
+
+Voir [le site d'OpenWrt](https://openwrt.org/supported_devices).
+
+# Installer OpenWrt
+
+Voir [la documentation OpenWrt](https://openwrt.org/docs/guide-quick-start/start) et un [guide générique](https://openwrt.org/docs/guide-user/installation/generic.flashing).
+
+# Configurer OpenWrt pour un site géographique Deuxfleurs
+
+## Configuration de base
+
+- installer OpenWrt
+- se connecter en SSH sur le routeur
+- définir un mot de passe root avec `passwd`, le renseigner dans le [dépôt des secrets](@/operations/pass.md)
+- désactiver les IPv6 ULA : dans `/etc/config/network`, supprimer le bloc qui ressemble à ça :
+
+```
+config globals 'globals'
+    option ula_prefix 'fda0:8093:6a4c::/48'
+```
+
+- autoriser le trafic IPv6 en entrée.  Attention, la configuration ci-dessous autorise absolument tout le trafic IPv6 pour toutes les machines du réseau local.  Vous pouvez être plus fin si nécessaire.
+  Dans `/etc/config/firewall`, rajouter le bloc suivant :
+
+```
+config forwarding
+	option src		wan
+	option dest		lan
+	option family		ipv6
+```
+
+- définir un nom d'hôte pour le routeur, par exemple `gw-<nom du site>`. Ça se passe dans `/etc/config/system`
+- rebooter le routeur pour être sûr d'appliquer tous les changements
+
+## Configuration UPnP
+
+C'est le plus gros morceau.
+
+- installer le serveur UPnP (ici pour un OpenWrt récent qui utilise nftables et non iptables) :
+
+```bash
+opkg update
+opkg install miniupnpd-nftables
+```
+
+- configurer le serveur UPnP, ça se passe dans `/etc/config/upnpd` :
+  - mettre `option enabled` à `1`
+  - mettre `option enable_natpmp` à `0` (pas besoin pour Deuxfleurs)
+  - mettre `option log_output` à `1` (pour faciliter le debug)
+  - dans le premier bloc `perm_rule`, mettre `ext_ports` et `int_ports` à `'0-65535'` (autoriser à mapper tous les ports)
+  - dans ce meme bloc, mettre la plage d'adresse IP des machines Deuxfleurs dans `int_addr`, par exemple `192.168.5.0/24` (pour éviter que d'autres machines n'utilisent UPnP)
+
+- redémarrer le service UPnP : `/etc/init.d/miniupnpd restart`
+
+Il est également nécessaire de changer le port utilisé par LuCI (l'interface web d'OpenWrt), sinon cela empechera de mapper les ports 80 et 443 vers Tricot.
+Il faut veiller à choisir un port qui n'est utilisé par aucun service de Deuxfleurs.  Ici, on choisit 65080 en HTTP et 65443 en HTTPS.
+
+- ouvrir `/etc/config/uhttpd`
+- sur les lignes `listen_http`, changer `80` par `65080`
+- sur les lignes `listen_https`, changer `443` par `65443`
+- redémarrer le service : `/etc/init.d/uhttpd restart`
+
+Une fois cette configuration effectuée, pour accéder à l'interface web du routeur, il faut aller sur `http://192.168.X.Y:65080`.
+
+## Debug UPnP
+
+Pour cela, il faut d'abord avoir un diplonat lancé par Nomad sur une machine du site.
+
+Pour voir si le serveur UPnP reçoit bien les requetes de diplonat, afficher les logs OpenWrt avec `logread -f`.
diff --git a/content/operations/site.md b/content/operations/site.md
new file mode 100644
index 0000000..5d84ced
--- /dev/null
+++ b/content/operations/site.md
@@ -0,0 +1,19 @@
+---
+title: "Installer un site"
+description: "Installer un site géographique"
+date: 2024-05-30
+dateCreated: 2024-05-30
+weight: 19
+extra:
+  parent: 'operations/_index.md'
+---
+
+# Déployer un nouveau site géographique pour l'infrastructure Deuxfleurs
+
+Dans un *site géographique*, on installe une *grappe d'ordinateurs* au sein d'un *réseau local*, qu'on connecte au cluster de Deuxfleurs.
+
+Rajouter un nouveau site pour l'infrastructure Deuxfleurs est une opération qui demande de nombreuses étapes et peut avoir un fort impact sur la production.
+
+Avant de se lancer, il faut en parler aux autres admins et [s'assurer qu'on remplit les prérequis](@/operations/prérequis-site.md).
+
+Pour le réseau, nous avons un [guide de configuration de routeur sous OpenWrt](@/operations/site-openwrt.md)
diff --git a/content/operations/supervision.md b/content/operations/supervision.md
index 5b76a2b..6e3b1ca 100644
--- a/content/operations/supervision.md
+++ b/content/operations/supervision.md
@@ -7,17 +7,48 @@ extra:
   parent: 'operations/_index.md'
 ---
 
+# Journaux
+
+Les journaux ne sont pas centralisés aujourd'hui.
+Vous pouvez les consulter avec `docker logs`, `nomad` et `journalctl`.
+
 # Métriques
 
 Grafana est accessible à l'adresse suivante : https://grafana.deuxfleurs.fr
 
-Vous pouvez obtenir le mot de passe admin en allant le chercher dans consul KV
+La connexion est possible avec ses identifiants Guichet (via LDAP).
 
-# Journaux
+Pour les admins, il est aussi possible d'utiliser le mot de passe admin en allant le chercher dans Consul KV.
 
-Les journaux ne sont pas centralisés aujourd'hui.
-Vous pouvez les consulter avec `docker logs`, `nomad` et `journalctl`.
+Les dashboards ne sont pour l'instant pas stockés dans un dépot git, ils sont édités manuellement dans l'interface de Grafana.
+
+Il y a également une instance Grafana de staging, sans intégration LDAP/Guichet : https://grafana.staging.deuxfleurs.org
+
+# Supervision et alerting externe
+
+Nous avons un système de supervision externe, accessible à l'adresse <https://status.deuxfleurs.fr>.
+Il s'agit d'une instance de [Uptime Kuma](https://github.com/louislam/uptime-kuma), hébergée gracieusement par [RésiLien](https://resilien.fr/).
+
+Son but est de vérifier le bon fonctionnement des services exposés publiquement par Deuxfleurs : sites web statiques, services web (cryptpad, jitsi, plume), email, ainsi que l'API S3 de Garage.
+
+Pour rajouter des services à surveiller ou configurer des envois d'alertes, les identifiants de connexion sont dans le [dépôt des secrets](@/operations/pass.md).
+
+Un bot envoie les alertes sur le canal Matrix `deuxfleurs::alertes`.  Ce bot est un compte Matrix Deuxfleurs ajouté manuellement dans LDAP, les identifiants de ce compte sont dans le [dépôt des secrets](@/operations/pass.md) (entrée `monitoringbot`).
+
+# Alerting interne
+
+Nous ne disposons actuellement pas de supervision interne complète avec envoi d'alertes.
+
+Une telle supervision interne serait complémentaire à la supervision externe : elle permettrait de détecter des problèmes en amont qui ne sont pas forcément encore visibles sur les services.
+Par exemple, Garage tolère la panne d'une zone sans impacter le service, il est donc facile de ne pas se rendre compte de la panne ... jusqu'à ce qu'une deuxième panne arrive !
 
-# Alertes
+Les éléments suivants seraient pertinents à surveiller :
 
-Nous n'avons pas de système d'alerte aujourd'hui.
+- système : espace disque, état SMART des disques, charge I/O
+- connectivité : connectivité interne Wireguard, IPv6
+- état du cluster Garage (perte d'une zone ou d'un noeud)
+- état du cluster Nomad
+- état du cluster Consul
+- état du cluster Stolon
+- état des backups
+- crash dans le catalog consul / les allocs nomad