Mise en place de la refonte de la documentation

2024-04-27 16:34:56 +02:00 · 2024-04-27 16:34:56 +02:00 · ca1bbd73e9
parent b84c3e04e6
commit ca1bbd73e9
103 changed files with 3654 additions and 2396 deletions
--- a/.mdlrc
+++ b/.mdlrc
@ -0,0 +1 @@
 style "#{File.dirname(__FILE__)}/.mdstyle.rb"
--- a/.mdstyle.rb
+++ b/.mdstyle.rb
@ -0,0 +1,5 @@
 all
 rule 'MD013', :ignore_code_blocks => true, :tables => false
 exclude_rule 'MD024'
 exclude_rule 'MD026'
 rule 'MD033', :allowed_elements => "sup"
--- a/CONTRIBUTE.md
+++ b/CONTRIBUTE.md
@ -1,17 +0,0 @@
 # Contribute
 ## Structure
 La documentation a la structure suivante
 * `tools`: dans cette section, on rassemble tous les outils utilisés et les descriptions de certains protocoles utilisés
   * Exemples d'outils : TLS, APT, debian, rsync, ssh, … À mettre dans `/tools`
   * Exemples de connaissances : IP, Firewall, NAT, DHCP, … À mettre dans `/tools`
 * `howto`: dans cette section, on regroupe les connaissances pratiques utiles : acheter un disque, dimensionner une clim, …
 * `infrastructure`: ici on décrit l'infrastructure dans sa globalité, pour faire simple ce que le Crans met à disposition du Crans
   * Exemples : LDAP administration, NFS, Plan IP & VLAN, matériel technique, PostgreSQL
 * `services`: on y décrit la liste des services offerts aux adhérents
 ## Contribuer
 Pour contribuer rien de plus simple : il suffit de créer un fichier `.md` (en Markdown) dans la section idoine.
 On priviliégiera des noms de fichier en minuscules et le plus simple possible : par exemple acheter un disque → `/howto/disk.md`.
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -0,0 +1,99 @@
 # Contribution
 Merci de contribuer à la documentation ! Même si le déploiement/la
 maintenance des différents services du Crans peut paraître plus intéressante
 que faire de la documentation, il s'agit au même titre d'une étape cruciale du
 bon fonctionnement du Crans : on ne peut pas faire fonctionner tout un parc
 informatique si on ne sait pas ce qu'il y a dedans.
 ## Contribuer
 Toute contribution est la bienvenue ! Surtout n'hésitez pas à demander de
 l'aide aux vieilles nounous si vous n'êtes pas certain⋅e de ce que vous
 faites.
 On distingue ici deux types de contributions :
 * les contributions directes, c'est-à-dire un ajout d'une documentation sur
  un ou plusieurs sujet, ou une modification d'une documentation déjà existante
  pour la corriger, la mettre à jour, ...
 * les demandes de contribution, c'est-à-dire les demandes d'ajout de
  documentation sur un sujet que vous trouvez mal expliqué et que vous ne
  comprenez pas bien (sinon vous pourriez le faire vous-même ^^), ou les
  demandes d'ajout de tutoriels dans le dossier [`howto`](howto).
 Pour les demandes de contribution, vous pouvez directement demander à une
 nounou, mais pour ne pas oublier il vaut mieux dans tous les cas ouvrir une
 issue sur le dépôt gitlab <https://gitlab.crans.org/nounous/documentation>.
 Une nounou ou un⋅e apprenti⋅e se chargera alors (lorsqu'iel aura le temps)
 d'écrire cela.
 Pour les contributions directes, il n'y a aucun problème à directement mettre
 vos modifications sur ce dépôt, à partir du moment où les
 modifications/ajouts respectent l'organisation décrite dans [la section
 Organisation du README.md](README.md#organisation) ainsi que les conventions de
 rédactions décrites ci-dessous. Si vous avez effectué ou prévoyez beaucoup
 de modifications, il peut alors être préférable de placer tous les
 changements sur une autre branche puis de faire une merge request sur gitlab
 pour qu'une autre nounou vérifie vos changements. De plus, si besoin, vous
 pouvez vous aider des fichiers `TEMPLATE.md` pour avoir une idée de comment
 structurer votre documentation.
 ## Conventions de rédaction
 ### Structuration
 Tous les fichiers doivent être écrits en
 [markdown](https://fr.wikipedia.org/wiki/Markdown). Cela permet de lire toute
 la documentation dans toutes circonstances avec des mises en forme
 standardisées. Vous pouvez trouver de la documentation markdown sur [ce
 site](https://www.markdownguide.org/) si nécessaire. Un linter est configuré
 dans ce dépôt : [markdownlint](https://github.com/markdownlint/markdownlint).
 Aucun fichier ne doit renvoyer d'avertissement après exécution de la commande
 `mdl .` à la racine du dépôt.
 **Tout dossier doit contenir un fichier `README.md`**, même si celui-ci est
 court. Il doit contenir le rôle de ce que contient le dossier avec une brêve
 description de tous les fichiers et sous-dossiers présents.
 Tout dossier peut également contenir en plus, si nécessaire et approprié, un
 fichier `TEMPLATE.md` mettant à disposition un template pour les futures
 documentations.
 De plus, mis à part les fichiers `README.md` et `TEMPLATE.md`, et les fichiers
 uniques [`CONTRIBUTING.md`](CONTRIBUTING.md), [`CRITICAL.md`](CRITICAL.md) et
 [`LICENSE.md`](LICENSE.md), tous les noms de fichiers doivent être **clairs**
 et en minuscules. Il vaut mieux un nom long qu'une abrévation peu
 compréhensible. Dans le cas d'un nom de fichiers de plusieurs mots, on les
 séparera par des tirets bas (underscores).  Par ailleurs, on évite autant que
 possible de créer des dossiers contenant 50 fichiers : on préfère avoir des
 sous-dossiers thématiques plus navigables.
 ### Mise en page
 Il n'y a jamais assez d'hyperliens : n'hésitez pas à mettre des références
 vers de la documentation officielle ou à rediriger vers d'autres fichiers de
 la documentation du Crans si cela est possible ! Cela permet de naviguer
 facilement sans se perdre dans les sous-dossiers.
 De plus, pour faciliter la lisibilité, que ce soit dans le terminal ou sur
 internet, on limite la taille des lignes à 80 caractères en comptant les
 caractères non affichés sur des rendus graphiques (comme les hyperliens ou
 les étoiles pour les mots en gras/italique/...). Si besoin, vous pouvez
 facilement configurer un formatter dans votre éditeur de texte (vim, helix,
 ...) avec simplement la commande `fold -s -w80`.
 ### Langue
 * Il serait préférable que toute la documentation soit (au minimum) être
  écrite en français. Cela ne signifie pas qu'il ne peut pas y avoir de
  traduction en anglais ou de termes informatiques anglais, mais la langue de
  rédaction devrait rester le français pour être compris par tous et toutes
  sans difficulté.
 * On privilégie le vouvoiement au tutoiement.
 * L'usage de l'écriture inclusive est recommandé, que ce soit par
  l'utilisation prioritaire de termes épicènes, par la coordination (ex: "tous
  et toutes") ou par l'emploi du point médian.
--- a/CRITICAL.md
+++ b/CRITICAL.md
@ -0,0 +1,5 @@
 # Section critique
 Tout est cassé, que faire ?
 TODO
--- a/README.md
+++ b/README.md
@ -0,0 +1,66 @@
 # Documentation Crans
 Voici la documentation technique du Crans à destination des apprenti⋅e⋅s
 et des nounous du Crans. Vous pouvez retrouver (prochainement) toute la
 documentation mise en forme à l'adresse <https://doc.crans.org>. Attention :
 ce n'est pas la documentations des utilisateurices qui se situe dans [ce
 dépôt](TODO).
 ## Utilisation
 Pour la bonne maintenance des services du Crans, il est impératif d'avoir une
 documentation permettant une bonne compréhension du fonctionnement global de
 l'infrastructure et des services. C'est pourquoi il est essentiel que ce
 dépôt soit le plus à jour possible en toutes circonstances.
 Il est par ailleurs recommandé à toutes les nounous et aux apprenti⋅e⋅s
 souhaitant s'investir dans le Crans d'avoir une copie locale de ce depôt (avec
 un petit `git clone`) : il est plus simple de dépanner un service critique
 sans avoir à chercher où est la documentation (sur un serveur gitlab qui est
 potentiellement cassé également ^^').
 Si vous voyez un service/un serveur/... non documenté, ou si vous souhaitez
 voir un tutoriel (appelé ici "how to") sur un sujet, réferrez-vous à
 [CONTRIBUTING.md](CONTRIBUTING.md). Il est **impératif** de le lire avant de
 contribuer pour une bonne cohérence organisationnelle et stylistique.
 ## Organisation
 Tous les dossiers contiennent un fichier `README.md` que vous pouvez lire pour
 comprendre le rôle de ce qui est présenté dans ce dossier ainsi qu'une
 brêve description de tous les fichiers et sous-dossiers présents.
 Voici l'organisation générale de la documentation :
 * [`compte_rendus`](compte_rendus) : ensemble des comptes rendus des IN
  (Inter-Nounous) ;
 * [`howto`](howto) : liste non exhaustive de tutoriels explicatifs sur une
  démarche précise nécessitant généralement la manipulation de plusieurs
  services ;
 * [`infrastructure`](infrastructure) : documentation concernant
  l'infrastructure du Crans, c'est-à-dire les machines (physiques et
  virtuelles), les réseaux utilisés ou encore le fonctionnement des services
  mis à disposition pour une utilisation interne au Crans (les LDAP,
  PostgreSQL, ...) ;
 * [`outils`](outils) : présentation rapide (ou détaillée selon la
  pertinence) de tous les outils et protocoles utilisés par le Crans ;
 * [`services`](services) : présentation rapide des différents services du
  Crans mis à disposition des utilisateurices.
 En plus de ces dossiers, on trouve également les fichiers suivants jouant un
 rôle particulier :
 * [`CONTRIBUTING.md`](CONTRIBUTING.md) : fichier expliquant comment bien
  contribuer à la documentation du Crans ;
 * [`CRITICAL.md`](CRITICAL.md) : que faire si c'est la panique ?
 * [`LICENSE.md`](LICENSE.md) : licence sous laquelle est publiée la
  documentation du Crans.
 * [`SECURITY.md`](SECURITY.md) : bases de sécurité, valables au Crans mais
  pas que.
--- a/ROADMAP.md
+++ b/ROADMAP.md
@ -1,59 +0,0 @@
 # ROADMAP
 ```
 .
 ├── critical
 │   ├── borg.md [DONE]
 │   ├── cas.md [ynerant]
 │   ├── gitlab.md [ÿnerant]
 │   ├── irc [esum]
 │   │   ├── anope.md
 │   │   ├── inspircd.md [DONE]
 │   │   └── thelounge.md
 │   ├── mail
 │   │   ├── autoconfig.md [DONE]
 │   │   ├── dovecot.md [DONE]
 │   │   ├── horde.md [shirenn]
 │   │   ├── mailman.md [ÿnérant]
 │   │   ├── nullmailer.md [erdnaxe]
 │   │   ├── opendkim.md [shirenn]
 │   │   ├── policyd.md [shirenn]
 │   │   ├── postfix.md [shirenn]
 │   │   ├── roundcube.md [erdnaxe]
 │   │   └── services
 │   │       └── mail.md [DONE]
 │   ├── moinmoin.md [erdnaxe]
 │   ├── monitoring
 │   │   ├── grafana.md [DONE]
 │   │   ├── ninjabot.md [DONE]
 │   │   └── prometheus.md [erdnaxe]
 │   ├── networking
 │   │   ├── bind.md [shirenn]
 │   │   ├── bird.md [DONE]
 │   │   ├── freeradius.md [vanille]
 │   │   ├── isc-dhcp-server.md [DONE]
 │   │   ├── keepalived.md [DONE]
 │   │   ├── nftables.md [DONE]
 │   │   ├── radvd.md [DONE]
 │   │   └── services
 │   │       ├── dhcp.md [DONE]
 │   │       ├── firewall.md [DONE]
 │   │       └── prefix-delegation.md [DONE]
 │   ├── owncloud.md [erdnaxe]
 │   └── services
 │       ├── borg.md [shirenn]
 │       └── monitoring.md [shirenn]
 └── services
    ├── belenios.md [DONE]
    ├── ethercalc.md [erdnaxe]
    ├── etherpad.md [erdnaxe]
    ├── framadate.md [DONE]
    ├── galene.md [DONE]
    ├── gitea.md [shirenn]
    ├── jitsi.md [ynerant]
    ├── linx.md [DONE]
    ├── re2o.md [DONE]
    ├── vsftpd.md [DONE]
    ├── zerobin.md [shirenn]
    └── zamok.md [shirenn]
 ```
--- a/SECURITY.md
+++ b/SECURITY.md
@ -0,0 +1,78 @@
 # Securité
 Le but ici est de donner quelques conseils généraux de sécurité qui est bon
 à respecter le plus possible lors de changements de l'infrastructure ou de
 services. La liste ne se veut pas exhaustive, mais permet de donner l'esprit
 global qu'il faut avoir.
 ## Sécurité des comptes utilisateurs
 Que ce soit les membres de l'association, comme les membres actif⋅ves, il faut
 prendre les précautions pour s'assurer que ses identifiants ne fuient pas dans
 la nature :
 * **Ne pas avoir de comptes locaux avec des mots de passe actifs.**
  Un compte avec possibilité d'authentification par mot de passe DOIT être
  dans l'annuaire LDAP. Cela permet de faciliter le changement de mot de
  passe et ne pas laisser des mots de passe cassés traîner.
 * **Ne pas partager un compte.**
  Et oui, on évite de filer son mot de passe à son voisin.
 * **Avoir un mot de passe solide.**
  `toto2345` n'est pas un bon mot de passe et prend en moyenne moins de 5
  minutes à être bruteforcée avec
  [john](https://fr.wikipedia.org/wiki/John_the_Ripper).
 * **Favoriser l'authentification par paire de clées.**
  Pour les services le permettant (SSH, Git...), il est préférable d'avoir
  une paire de clé. Une clé privée ne doit jamais quitter le périphérique
  où elle a été créée (que ça soit un token matériel ou une machine
  Linux). Il est préférable de protéger la clé privée par un mot de
  passe. Ainsi si une de vos machine est compromise, vous pouvez révoquer
  seulement sa clé et tracer où elle a été utilisée.
 * **Favoriser la double authentification.**
  Pour les services critiques (paiement, accès root...) il est préférable
  d'ajouter un second facteur d'authentification et d'alerter l'équipe si
  seulement le premier facteur a réussi mais le second a échoué.
  Pour les services Web, voir le standard WebAuthn. Pour OpenSSH il existe
  des intégrations avec des applications de second authentification.
 * **Utiliser un gestionnaire de mots de passe pour les secrets partagés.**
  Pour les secrets partagés au sein de l'équipe technique, on les chiffre
  pour les clés privées de chaque administrateur.
 ## Sécurité des logiciels développés
 * **Ne pas fixer strictement les versions des paquets.**
  Il faut s'assurer que les contraintes sur les dépendances permettent
  d'obtenir les mises à jour de sécurité. Souvent il n'est que nécessaire
  de fixer la version majeure (`~=2.1`, plutôt que `==2.1.1`).
 * **Privilégier le gestionnaire de paquet de la distribution.**
  La distribution rétroporte les mises à jour de sécurité. Il est donc de
  bon goût d'utiliser le plus possible ses paquets pour simplifier la mise
  à jour de l'ensemble de l'infrastructure.
 * **Utiliser des outils de linting avec des règles de sécurité.**
  Les bons outils de linting connaissent les patterns pouvant potentiellement
  se traduire en faille de sécurité.
 * **Lancer le logiciel en non-privilégiés.**
  Un logiciel ne devrait jamais avoir besoin de `root` ou de `sudo`.
  Lors de l'écriture du service, on peut également ajouter des protections
  supplémentaires pour augmenter l'isolation.
 ## Sécurité de l'infrastructure
 * **Faire ses backups, et vérifier qu'elles marchent.**
 * **Faire des scans des ports ouverts.**
  Pour cela on peut lancer `nmap` sur la plage d'adresses IP.
 * **Monitorer et alerter.**
 * **Segmenter les services.**
  Isoler les services sur différentes machines et augmenter l'indépendance
  permet d'améliorer la robustesse de l'infrastructure.
--- a/compte_rendus/2024-01-13.md
+++ b/compte_rendus/2024-01-13.md
@ -1,90 +0,0 @@
 # Réunion IN
 * Date : Samedi 13 Janvier 2024
 * Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
 * Début : 13h32
 * Fin : 15h32
 ## Présent⋅es
 * [bleizi](https://wiki.crans.org/WikiBleizi)
 * [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux)
 * GaBo
 * [vanille](https://wiki.crans.org/VanilleNiven)
 * [Otthorn](https://wiki.crans.org/SolalNathan)
 * [Hachino](https://wiki.crans.org/WikiHachino)
 * [esum](https://wiki.crans.org/Esum)
 * Korenst1
 * shirenn
 * Floflo
 * RDB
 * lzebulon
 * [Aplanos](https://wiki.crans.org/WikiAplanos)
 * Abidos
 ## Ordre du jour
 - Présentation SRS et fix `mailman` (spam, SPF, comptes bizarres)
 - Point sur les DistUpgrades des VM
 - Discussions avec la DSI (imprimante, eduroam, radius dans les locaux associatifs)
 - État de la DGNum (Crans à Ulm)
 - Autres remarques diverses
 ### Guix
 Le conseil technique s'est prononcé lors d'une séance précédente contre la mise
 en place de test Guix et a approuvé uniquement le fait de tester Nix.
 Les tests d'intégration Guix de l'infrastructure du Crans sont de facto une perte
 de temps et devraient être interrompus.
 ### Désinscription mailing lists
 Un email de plainte a levé des doutes sur le bon fonctionnement du mécanisme
 de désinscription de `lists.crans.org`. Des tests ont été réalisés en direct
 par un membre et ont confirmé que l'échec de la procédure n'est pas de la faute
 du Crans.
 ## SRS
 `shirenn` a présenté la motivation et le fonctionnement de [SRS](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme)
 pour nos redirections de mails. Il a été identifié en direct que cela est lié
 directement aux problèmes récents de surabondance d'emails "Successful Mail Delivery Report"
 sur `root@crans.org` lorsqu'un accusé de réception est demandé.
 Étant donné l'importance de ne pas perdre d'emails et la relative fragilité du
 système il est décidé de ne pas immédiatement supprimer ces reports, mais lorsque
 nous serons plus certains de la robustesse de SRS nous envisagerons de retirer
 `root` des récipients.
 ## Mailman
 Nous observons des mails acceptés qui ne sont visiblement pas conformes à la whitelist
 mise en place. L'abondance de problèmes avec mailman en général nous mène à envisager
 la migration à [sympa](https://www.sympa.community/)
 Cela pourra faire l'objet d'un projet apprentis, pour lequel lzebulon, RDB, Korenst1 et GaBo
 se disent motivés.
 ## DU (distrib upgrade)
 Tout casse à chaque fois qu'on DU un serveur.
 On va passer soon^{TM} sur NixOS.
 ## DSI: eduroam
 La DSI a accepté de mettre à jour une pratique obsolète concernant la connexion
 au wifi eduroam dans l'enceinte de l'ENS Paris-Saclay qui empêchait auparavant
 la connexion aux élèves de l'ENSAE.
 L'accès est rétabli.
 ## DSI: wifi Crans
 Pascal -- membre de la DSI de l'ENS Paris-Saclay -- est maintenant un contact du Crans.
 Cela nous donne l'opportunité de ressusciter le projet de wifi Crans dans l'ENS,
 sans toutefois être une priorité.
 Il sera important de contacter Aurore au préalable pour distuter du volume
 que l'association peut gérer.
 Sur le plan technique, OpenRadius est envisagé.
--- a/compte_rendus/2024_01_13.md
+++ b/compte_rendus/2024_01_13.md
@ -0,0 +1,91 @@
 # Réunion IN
 * Date : Samedi 13 Janvier 2024
 * Lieu : MB87 et Galène (<https://galene.crans.org/group/IN>)
 * Début : 13h32
 * Fin : 15h32
 ## Présent⋅es
 * [bleizi](https://wiki.crans.org/WikiBleizi)
 * [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux)
 * GaBo
 * [vanille](https://wiki.crans.org/VanilleNiven)
 * [Otthorn](https://wiki.crans.org/SolalNathan)
 * [Hachino](https://wiki.crans.org/WikiHachino)
 * [esum](https://wiki.crans.org/Esum)
 * Korenst1
 * shirenn
 * Floflo
 * RDB
 * lzebulon
 * [Aplanos](https://wiki.crans.org/WikiAplanos)
 * Abidos
 ## Ordre du jour
 * Présentation SRS et fix `mailman` (spam, SPF, comptes bizarres)
 * Point sur les DistUpgrades des VM
 * Discussions avec la DSI (imprimante, eduroam, radius dans les locaux
  associatifs)
 * État de la DGNum (Crans à Ulm)
 * Autres remarques diverses
 ### Guix
 Le conseil technique s'est prononcé lors d'une séance précédente contre la
 mise en place de test Guix et a approuvé uniquement le fait de tester Nix. Les
 tests d'intégration Guix de l'infrastructure du Crans sont de facto une  perte
 de temps et devraient être interrompus.
 ### Désinscription mailing lists
 Un email de plainte a levé des doutes sur le bon fonctionnement du mécanisme
 de désinscription de `lists.crans.org`. Des tests ont été réalisés en
 direct par un membre et ont confirmé que l'échec de la procédure n'est pas
 de la faute du Crans.
 ## SRS
 `shirenn` a présenté la motivation et le fonctionnement de
 [SRS](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) pour nos
 redirections de mails. Il a été identifié en direct que cela est lié
 directement aux problèmes récents de surabondance d'emails "Successful Mail
 Delivery Report" sur `root@crans.org` lorsqu'un accusé de réception est
 demandé.
 Étant donné l'importance de ne pas perdre d'emails et la relative fragilité
 du système il est décidé de ne pas immédiatement supprimer ces reports,
 mais lorsque nous serons plus certains de la robustesse de SRS nous
 envisagerons de retirer `root` des récipients.
 ## Mailman
 Nous observons des mails acceptés qui ne sont visiblement pas conformes à la
 whitelist mise en place. L'abondance de problèmes avec mailman en général
 nous mène  à envisager la migration à [sympa](https://www.sympa.community/).
 Cela pourra faire l'objet d'un projet apprentis, pour lequel lzebulon, RDB,
 Korenst1 et GaBo se disent motivés.
 ## DU (distrib upgrade)
 Tout casse à chaque fois qu'on DU un serveur.
 On va passer soon^{TM} sur NixOS.
 ## DSI: eduroam
 La DSI a accepté de mettre à jour une pratique obsolète concernant la
 connexion au wifi eduroam dans l'enceinte de l'ENS Paris-Saclay qui empêchait
 auparavant la connexion aux élèves de l'ENSAE. L'accès est rétabli.
 ## DSI: wifi Crans
 Pascal -- membre de la DSI de l'ENS Paris-Saclay -- est maintenant un contact
 du Crans. Cela nous donne l'opportunité de ressusciter le projet de wifi Crans
 dans l'ENS, sans toutefois être une priorité.
 Il sera important de contacter Aurore au préalable pour distuter du volume que
 l'association peut gérer.
 Sur le plan technique, OpenRadius est envisagé.
--- a/compte_rendus/README.md
+++ b/compte_rendus/README.md
@ -0,0 +1,20 @@
 # Comptes-rendus
 ## Présentation
 Ce dossier contient l'ensemble des comptes-rendus des IN.
 Les IN, ou Inter-Nounous, sont les réunions techniques des membres
 actifs⋅ves du Crans. Celle-ci sont publiques et sont organisées tous les
 mois. Celles-ci sont annoncées sur IRC et sur les ML
 apprenti-es@lists.crans.org et nounou@crans.org.
 ## Organisation
 Chaque fichier de ce dossier est le compte-rendu d'une réunion technique. Vous
 pouvez trouver un template de compte-rendu dans le fichier
 [`TEMPLATE.md`](TEMPLATE.md) si nécessaire. La seule contrainte pour ce
 dossier est le nom des fichiers. Les comptes-rendus sont identifiés par la
 date de la réunion : pour une réunion du JJ/MM/AAAA, le fichier devra se
 nommer `AAAA_MM_JJ.md` (et non `JJ_MM_AAAA.md` car le tri par date se fait plus
 simplement).
--- a/compte_rendus/TEMPLATE.md
+++ b/compte_rendus/TEMPLATE.md
@ -0,0 +1,34 @@
 # Réunion IN
 * Date :
 * Lieu(x) :
 * Heure de début :
 * Heure de fin :
 ## Présent⋅es
 * [Nounou 1](https://wiki.crans.org/CransNounous)
 * [Apprentie 1](https://wiki.crans.org/CransTechnique/CransApprentis)
 * [Apprenti 2](https://wiki.crans.org/CransTechnique/CransApprentis)
 * [Nounou 2](https://wiki.crans.org/CransNounous)
 * Personne sans page wiki
 ## Ordre du jour
 * [Nounou 1] Point 1
 * [Nounou 2] Point 2
   * Sous-point 1
   * Sous-point 2
 * [Apprentie 1] Point 3
 * [Nounou 1] Point 4
 * [Apprenti 2] Point 5
 ### Point 1
 Détails et résumé des discussions du point 1
 ### Point 2
 Détails et résumé des discussions du point 2
 ...
--- a/critical/monitoring/grafana.md
+++ b/critical/monitoring/grafana.md
@ -1,15 +0,0 @@
 # Grafana
 Grafana est une traceur de données à destination des humains. Il est codé en NodeJS et correctement packagé dans une source de paquets Debian.
 L'idée de Grafana est de se connecter à des sources de données puis de réaliser des dashboards contenant des modules faisant des requêtes à ces sources de données.
 Là vous vous dites « *Mais du coup il faut passer beaucoup de temps pour créer les dashboards ? C'est nul !* ». Effectivement comparé à Munin il y a plus de travail nécessaire pour afficher des données, mais cela permet une plus grande adaptabilité. Beaucoup de dashboards existent en ligne (surtout sur les dépôts de code des exporters Prometheus) et sont téléchargeable en JSON pour ensuite les importer.
 ## Securité
 Par défaut Grafana crée un compte avec pour login `admin` et mot de passe `admin`. Parfois quand on bidouille la configuration, cet utilisateur est recréé automatiquement. Pensez à le supprimer s'il apparait dans la liste des utilisateurs ou changer son mot de passe.
 Évitez d'installer des plugins qui ne sont pas de confiance.
 Le service Systemd de Grafana le conteneurise pour éviter des potentielles exécutions de code distantes.
--- a/critical/monitoring/ninjabot.md
+++ b/critical/monitoring/ninjabot.md
@ -1,8 +0,0 @@
 # NinjaBot
 NinjaBot est un bot [IRC](/tools/irc.md) qui permet d'envoyer des notifications en temps réel sur des canaux de discussion, ses sources sont disponibles [ici]().
 Au Crans il est utilisé pour retransmettre les alertes du monitoring sur `#monitoring` et possède le nick `monitoring`.
 NinjaBot utilise [Flask](https://flask.palletsprojects.com/) afin d'écouter des webhooks et de pousser des notifications en fonction des données envoyées par le webhook. Ces notification sont ensuite envoyée sur une fifo lue par le bot IRC en lui-même : il est donc possible de modifier le comportement des notifications sans redémarrer le bot en lui-même.
 NinjaBot est déployé sur la VM `monitoring` et le service systemd qui lui est associé est `ninjabot`.
--- a/critical/networking/bird.md
+++ b/critical/networking/bird.md
@ -1,148 +0,0 @@
 # Bird
 Bird est un daemon de routage. Il supporte de nombreux protocoles de routages
 comme BGP and OSPF. Au crans on l'utilise pour faire de l'échange de route avec
 notre FAI grace au protocole BGP. C'est donc le seul que je détaillerais ici
 pour le moment.
 ## Principe
 ### L'IANA, le RIPE et le CRANS, les IPs et les numéros d'AS
 Après l'adoption du protocole IP, il a été décidé que ce serait à l'IANA
 (Internet Assigned Number Authority) de se charger de l'allocation des adresses
 IPs. Elle délègue cependant cette responsabilité à des entités régionales
 appelées RIR pour Regional Internet Registry. En Europe, c'est le RIPE (pour
 Réseaux IP Européens, cocorico) qui remplit cette office. Les gens à qui un RIR
 alloue des ressources est appelée un LIR pour Local Internet Registery. Et vous
 savez quoi, depuis 2017 le crans est un LIR à part entière \o/. Et le RIPE
 (notre RIR) nous a assigné les ressources suivantes :
  - 185.230.76.0/22
  - 2a0c:700::/32
  - 204515
 Les deux premiers éléments de cette liste suivent assez logiquement ce que j'ai
 dit plus haut. Le RIPE est censé assigné au LIR européen des ressources ip. Il
 nous a donc délégué un `/22` d'IPv4 et un `/32` d'IPv6 (aussi appellée une
 mole). Mais le troisième élément semble pour le moment plus absconts. En fait
 l'IANA et les RIR ne se contente pas de fournir des adresses IP mais toutes les
 ressources relatif à l'internet. En particulier, le dernier élément de notre
 liste est un numéro d'AS pour autonomous system. Un AS est un réseaux
 informatique qui opère sa propre politique de routage interne. C'est le cas au
 crans. Un numéro d'AS est identifiant unique alloué par un RIR et est utilisé
 dans certains protocoles internet entre AS comme le protocole BGP.
 ### Le protocole BGP
 Le protocole BGP est un protocole de routage qui permet l'échange de route entre
 deux AS. J'avoue avoir un peu la flemme de rentrer dans les détails de comment
 marche le protocole (si ça vous intéresse aller lire la RFC). Mais l'idée
 générale est que deux AS pairs dans le réseaux vont s'échanger des routes qui
 décrivent ce qu'ils sont capables d'atteindre. Si un AS recoit deux chemins
 différents pour la même route, il choisira celle qui a l'AS path le plus court,
 c'est à dire celle qui passe par le moins d'AS différent avant d'arriver à bon
 port.
 ## Installation
 On tire bird2 des repository debian : `sudo apt install bird2`.
 ## Configuration
 Le logiciel n'inclut pas de page de manuel détaillant les différentes options de
 configuration mais le [https://bird.network.cz/](site internet de bird) est très
 bien fourni en explication.
 Comme le logiciel supporte plusieurs protocole sa configuration est ségmenté en
 fonction des différents protocoles configurées en plus de quelques options de
 configurations fournis générales.
 ### Options de configurations générales
 Il est nécessaire de définir l'identifiant du routeur sur le lien. Cet
 identifiant en ipv6 comme en ipv4 doit être une adresse ipv4 qui pointe vers le
 routeur pour assurer son unicité.
 ### Le protocole kernel
 Le protocole kernel permet de définir la politique que bird va utiliser pour
 inserer des routes dans le kernel. Les options import et export permettent de
 définir quels routes bird va importer de la table de routage et exporter vers la
 table de routage. Au crans, on choisit assez simplement d'insérer toutes les
 routes que bird connait dans le noyau et de ne rien importer du noyau. L'option
 scan time permet de régler la fréquence à laquelle bird lira le contenu de la
 table de routage du kernel. Il est possible d'être plus précis⋅e sur les routes
 importé et exporté du protocol en utilisant des filtres.
 ```
 protocol kernel {
 	ipv4 {
 	    import none;
    	export all;
    };
 }
 protocol kernel {
 	ipv6 {
 	    import none;
    	export all;
    };
 }
 ```
 ### Le protocole device
 C'est pas vraiment un protocole, il permet simplement à bird de lister les
 interfaces du routeur.
 ```
 protocole device {}
 ```
 ### Le protocole static
 Le protocole static permet de définir des routes manuellement. Il est possible
 de définir plusieurs types de routes mais au crans on n'en définit que d'un seul
 type : les routes reject. Le comportement de ces routes est différent selon s'il
 est inséré dans le kernel où s'il est partagé via un protocole de partage de
 routes. Dans le premier cas, il dit au kernel assez litteralement de jetter tous
 les paquets vers cette route, comme le kernel choisi la route de plus long
 préfixe qui correspond à la destination cela revient à dire au routeur de jetter
 les paquets que le routeur ne sait pas joindre dans le bloc d'ips. Cependant
 dans un protocole d'échange de routes, il signifie que le routeur connait une
 route vers les éléments de ce bloc d'ips. Par exemple,
 ```
 protocol static {
 	ipv4;
    route 185.230.76.0/22 reject;
 }
 protocol static {
 	ipv6;
    route 2a0c:700::/32 unreachable;
 }
 ```
 ### Le protocol BGP
 Comme expliqué au dessus, le protocole BGP permet de faire de l'échange de
 routes entre différents AS. Il faut spécifier notre numéro d'AS, le numéro d'AS
 du pair et l'adresse sur laquelle on souhaite le contacter. Il est possible de
 préciser avec quelle adresse on veut le contacter. On peut là aussi définir des
 filtres d'import et d'exports de routes. Par exemple,
 ```
 protocol bgp aurore4 {
    description "BGP4 session with example";
    local 203.0.113.1 as crans_asn;
    neighbor 203.0.113.2 as example_asn;
    strict bind;
    ipv4 {
        import all;
        export where source ~ [ RTS_STATIC ];
    };
 }
 protocol bgp aurore6 {
    description "BGP6 session with example";
    local 2001:db8:28::1 as crans_asn;
    neighbor 2001:db8::28::2 as example_asn;
    strict bind;
    ipv6 {
        import all;
        export where source ~ [ RTS_STATIC ];
    };
 }
 ```
--- a/critical/networking/keepalived.md
+++ b/critical/networking/keepalived.md
@ -1,90 +0,0 @@
 # Keepalived
 Keepalived est une implémentation du protocole VRRP. Il permet de partager des 
 ips entre plusieurs machines. Si celle qui qui porte l'adresse à un moment 
 tombe, c'est une des autres qui prend le relai.
 ## Principe
 Le protocole VRRP permet de s'assurer qu'un ensemble d'adresses ip soit toujours 
 tenues par un pair sur le reseaux. Par exemple, au crans, pour rajouter de la 
 résilience sur la panne d'un routeur, les ips du routeurs sont partagées entre 
 plusieurs machines. Celle qui porte les ressources en fonctionnement normal est 
 appelée le `MASTER` et les autres sont appelées les `BACKUP` et on leur assigne 
 des priorités décroissantes. Sur le lien local que partage les différentes 
 machines, elles négocient qui devrait porter les ressources actuellement. En 
 ipv4, la négociation se fait en multicast en utilisant l'ip `224.0.0.18` et en 
 ipv6 cela ce fait via le groupe `ff02::12` (il faut bien faire attention à ce 
 que le parefeu ou qu'un commutateur ne le filtre pas). Si le porteur de l'ip 
 actuel arrète de transmettre des alertes VRRP alors le candidat avec la plus 
 haute priorité s'affectera les ressources.
 ## Installation
 On se contente de tirer le logiciel des repositorys debian `sudo apt install keepalived`.
 Il y est packagé (correctement) depuis Jessie.
 ## Configuration
 Il est fortement recommandé de sortir le `man 5 keepalived.conf` qui détaille 
 assez bien les différents cas d'utilisation du logiciel.
 Le logiciel nous permet de définir quelques options générale dans la section 
 global_defs. En particulier on peut y préciser le nom de la machine et la 
 configuration de l'envoi de mail :
 ```
 global_defs {
  notification_email { root@crans.org }
  notification_email_from keepalived@crans.org
  smtp_server smtp.adm.crans.org
  router_id routeur-sam
 }
 ```
 On peut ensuite rentré dans la configuration des instances. Une instance 
 correspond à un bloc de ressource que l'on souhaite partagé entre deux machines. 
 Comme les protocoles sous-jacent sont distincts en ipv4 et en ipv6, la 
 configuration pour des ressources ipv4 et ipv6 se fait dans des blocs 
 différents. Dans une instance, on doit préciser la priorité de la machine dans 
 l'instance, l'interface surlaquelle se font les alertes vrrp, l'identifiant de 
 l'instance et un bloc définissant les ressources qui sont partagées. Il est 
 aussi possible de définir un script qui sera appelé au changement d'état. On 
 donne ici l'exemple d'une instance en ipv4.
 ```
 vrrp_instance VI_ALL {
  # Définit l'état de priorité de la machine dans l'instance
  state MASTER
  priority 150
  # Active l'envoie des mails lors des changement d'état
  smtp_alert
  # Lien sur lequel se font les alertes VRRPS
  interface ens18
  # Identifiant de l'instance sur le lien
  virtual_router_id 60
  # Fréquence des envois d'alertes VRRPs
  advert_int 2
  # Script appelé lors des changement d'état
  notify /var/local/services/keepalived/keepalived.py
  # Bloc définissant les ressources partagées
  virtual_ipaddress {
      185.230.79.62/26 brd 185.230.79.63 dev ens22 scope global
  }
 }
 ```
 ### Script de changement d'état
 Comme préciser dans la section précédente, il est possible d'appeler un script 
 lors des changements d'état de l'instance. Keepalived appelera alors le script 
 avec les paramètres suivant : `script [TYPE] [NAME] [STATE] [PRIORITY]` où 
 `[TYPE]` vaut `INSTANCE` dans notre cas, `[NAME]` donne le nom de l'instance 
 concernée, `[STATE]` donne l'état vers lequel on transitionne et `[PRIORITY]` la 
 priorité dans l'instance.
 En utilisant un script, il est possible (comme on le fait actuellement au crans) 
 de laisser à keepalived le soin de démarrer certains services.
--- a/critical/networking/prefix_delegation.md
+++ b/critical/networking/prefix_delegation.md
@ -1,14 +0,0 @@
 # Délégation de préfixe IPv6
 La longueur des adresses IPv6 (128 bits) nous permet de déléguer des préfixes (c'est à dire des sous-réseaux) IPv6.
 Il est possible de fournir des préfixes grâce au protocole DHCPv6 mais cette solution n'a pas été privilégiée au Crans : nous lui avons préféré une attribution statique.
 Dans [Re2o](/services/re2o.md) une application Django, `prefix_delegation`, a été écrite permettant notamment d'attribuer des préfixes IPv6 de taille fixée à des utilisateurs.
 Dans cette application il est possible de définir des sous-réseaux IPv6 ainsi que le taille des préfixes contenus dans ces sous-réseaux puis de créer des préfixes et de les attribuer à des adhérents en leur assignant des passerelles (machine de l'adhérent à contacter pour router ce préfixe).
 L'application fourni une API Rest HTTP permettant au script `prefix_delegation` de rafraîchir la liste des préfixes et de leur passerelle dans le noyau de la VM de routage.
 Ce script utilise un protocole particulier pour gérer ses routes, ce protocole est défini dans `/etc/iproute2/rt_protos.d` sur les machines où le script des déployé.
 Le reverse [DNS](/tools/dns.md) est également délégué : des serveurs DNS peuvent être attribués à un ou plusieurs préfixes afin de résoudre les adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent. Il est même possible de configurer du DNSSEC pour le reverse DNS. Ceci est géré par le script `dns` sur la VM `silice`.
--- a/critical/networking/radvd.md
+++ b/critical/networking/radvd.md
@ -1,88 +0,0 @@
 # Radvd
 Radvd est une implementation du mécanisme d'autoconfiguration des adresses IP en 
 ipv6. Il permet au client de connaitre l'adresse du routeur et de se construire 
 lui même une adresse à partir du préfixe annoncé par le routeur et de son 
 adresse MAC. Des extensions du protocoles permettes aussi la configuration des 
 serveurs dns.
 ## Principe
 ### Adresse ipv6 et EUI-64
 Il est possible pour un pair possédant une adresse MAC et un prefixe ipv6 de 
 taille au plus `/64` de construire une adresse ipv6. Cependant, rien n'assure 
 qu'elle soit unique à ce stade et il faudra par la suite le vérifier. Mais on ne 
 s'interesse ici qu'au processus de construction.
 De son adresse MAC (donnée à 48 bits), on dérive un identifiant de l'interface 
 sur le lien de 64 bits en insertant les 16 bits `FF:FE` au milieu de l'adresse 
 MAC puis on inverse le 7 ème bit. On peut ensuite suffixer cet identifiant au 
 préfixe dans lequel on chercher à construire notre addresse ipv6. Ainsi 
 `00:25:90:69:8c:74` devient `00:25:90:ff:fe:69:8c:74` puis 
 `02:25:90:ff:fe:69:8c:74` qui donne l'adresse `fd00::10:0225:90ff:fe69:8c74/64` 
 dans le prefixe `fd00:0:0:10::/64`.
 ### Processus d'autoconfiguration complet
 Lorsqu'une machine configure une interface supportant l'ipv6 sur un lien, celle 
 ci va tenter de se crééer une premier adresse local au lien. Elle est donc 
 judicieusement appelé ip de lien locale. Pour cela, il va se contruire comme 
 expliquer précedemment une adresse dans le prefixe `fe80::/64`. Pour s'assurer 
 qu'elle est effectivement unique, il va envoyer au groupe ipv6 all-node 
 (`ff02::1`) qui comme son nom l'indique contient tous les nœuds si quelqu'un 
 utilise déjà l'adresse. Si c'est le cas, il ne poussera pas sa configuration 
 plus loin. Sinon après un délai sans réponse, il s'assignera l'adresse. Notre 
 pair a donc maintenant une adresse sur le lien et il peut écouter les annonces 
 (judicieusement appelé routeur-advertissement ou RA) périodiques qu'envoie le 
 routeur au groupe all-node. S'il ne désire pas patienté jusqu'à la prochaine 
 annonce le client peut envoyer un routeur-sollicitation au groupe all-routers. 
 Dans ces annonces le routeur inclut entre autre le prefixe dans lequel le client 
 devrait prendre son adresse, son adresse de lien local ainsi que des informations à 
 propos des serveurs dns. Une fois ces informations récupérées le client peut 
 procéder aux dernières étape de configuration de son interface réseaux en 
 assignant l'adresse qu'il a construit à partir du préfixe que lui a fourni le 
 routeur (en vérifiant en amont son unicité sur le lien) et en configurant la 
 gateway à l'adresse de lien local du routeur.
 ## Installation
 On se contente de tirer le logiciel des repository debian `sudo apt install 
 radvd`.
 ## Configuration
 La page de manuel détaillant les options de configurations de radvd est 
 consultable en utilisant `man 5 radvd.conf`.
 La configuration du logiciel se fait par bloc d'interface sur lesquel on va 
 publier nos RA. Dans un bloc on peut ensuite définir
  * des options génériques à propos de l'annonce comme par exemple l'intervalle 
  auquel notre routeur devrait publier des annonces ou le temps que la route 
  devrait être conservé par le client.
  * les prefixes que le routeur va annoncer sur le lien et certaines options 
  associées
  * les options de configurations du DNS
 Par exemple, le bloc suivant configure des annonces sur l'interface ens1 envoyé 
 toutes les 30 secondes avec comme préfixe `2a0c:700:12::/64`, `adh.crans.org` 
 comme liste de recherche pour les dns et `2a0c:700:12::ff:fe00:9912` comme 
 adresse du serveur dns.
 ```
 interface ens1 {
        AdvSendAdvert on;
        AdvDefaultPreference high;
        MaxRtrAdvInterval 30;
        prefix 2a0c:700:12::/64 {
                AdvRouterAddr on;
        };
        # La zone DNS
        DNSSL adh.crans.org {};
        # Les DNS récursifs
        RDNSS 2a0c:700:12::ff:fe00:9912 {};
 };
 ```
--- a/critical/networking/services/firewall.md
+++ b/critical/networking/services/firewall.md
@ -1,124 +0,0 @@
 # Pare-feu
 Voir `/critical/networking/nftables.md` pour une documentation minimale sur
 NFTables.
 Voici un pare-feu basique dans lequel des adhérants se trouvent derrière un
 routeur :
 ```
 #!/usr/sbin/nft -f
 flush ruleset
 #           +~~~~~~+
 #           | IPV4 |
 #           +~~~~~~+
 define adh_prefix = 172.16.54.1 - 172.16.54.98
 define srv_prefix = 185.230.79.0/24
 define nat_out = 185.230.79.37
 #           +~~~~~~+
 #           | IPV6 |
 #           +~~~~~~+
 define adh_prefix6 = 2a0c:700:54::/64
 # définit les adresses utilisées par les adhérants
 define adh4 = 100.66.0.0/16 ### Qu'est-ce que cette adresse ?
 #           +~~~~~~~~~~~~~~+
 #           | Filter table |
 #           +~~~~~~~~~~~~~~+
 table inet filter {
 	# Définiton des ports ouverts sur chaque machine
    # (Utilise un mapping plutôt que des sets pour éviter uen complexité
    #      terrifiante en O(nm) et passer à O(n+m) \(\ddot\smile\))
 	set authorized_in_forward_tcp4 {
 		type ipv4_addr . inet_service
 		flags interval
 	}
 	set authorized_in_forward_udp4 {
 		type ipv4_addr . inet_service
 		flags interval
 	}
 	set authorized_in_forward_tcp6 {
 		type ipv6_addr . inet_service
 		flags interval
 	}
 	set authorized_in_forward_udp6 {
 		type ipv6_addr . inet_service
 		flags interval
 	}
 	chain input {
 		type filter hook input priority 0; policy drop;
        # Accept local traffic
        meta iiftype loopback accept comment "allow from loopback"
 		# Accepts existsing connections
 		ct state { related, established } accept
 		ct state invalid drop
        # Accept SSH and DHCP
        meta l4proto { udp, tcp } th dport { ssh, 67 } ct state new accept
 		# Accept ping
 		ip protocol icmp accept
 		icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept
 	}
 	chain forward {
 		type filter hook forward priority 0; policy drop;
 		# Accept established and ping connnections
 		ct state { established, related } accept
 		ct state invalid drop
        # On log tout ce qui est neuf et qui passe
        log prefix "FORWARD: "
 		ip protocol icmp accept
 		icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept
 		# Ouverture de ports pour les gens se trouvant derrière
 		ip daddr . tcp dport @authorized_in_forward_tcp4 accept
 		ip6 daddr . tcp dport @authorized_in_forward_udp4 accept
 		ip daddr . udp dport @authorized_in_forward_tcp6 accept
 		ip6 daddr . udp dport @authorized_in_forward_udp6 accept
 		# Accepter toutes les connexions sortantes des clubs / adh et les logger
 		ip saddr $adh_prefix accept
 		ip6 saddr $adh_prefix6 accept
 	}
 }
 #           +~~~~~+
 #           | NAT |
 #           +~~~~~+
 table inet loggonsTout {
 	chain prerouting {
 		type nat hook prerouting priority dstnat;
 		# On log ce qui est neuf
 		ct state new log prefix "LOGALL: "
 	}
 }
 table ip nat {
 	chain postrouting {
 		type nat hook postrouting priority srcnat;
 		# traffic des adhérants et des clubs ===> $nat_out (range)
 		ip saddr $adh_prefix snat to $nat_out persistent
 	}
 }
 ```
--- a/howto/README.md
+++ b/howto/README.md
@ -0,0 +1,24 @@
 # How To : les tutos techniques
 ## Présentation
 Ce dossier contient les "how to" (tutoriels) du Crans concernant des tâches
 techniques demandant des connaissances généralement sur plusieurs parties de
 l'infrastructure.
 Si vous souhaitez que d'autres soient ajoutés, n'hésitez pas à vous
 réferrer [au CONTRIBUTING.md](../CONTRIBUTING.md).
 ## Organisation
 * [Changer de pseudo](changer_de_pseudo.md) : comment faire pour changer le
  nom d'utilisateur (pseudonyme) d'un⋅e utilisateur⋅rice. Cela peut être
  utile par exemple lors d'un changement d'état civil.
 * [Créer une VM pour les adhérent⋅es](creer_vm_adherent.md) : comment
  faire pour créer une VM pour un⋅e adhérent⋅e.
 * [Devenir nounou](devenir_nounou.md) : guide pour les nouvelles nounous !
 * [Supprimer un⋅e utilisateur⋅rice](supprimet_utilisateur.md) : comment
  supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données.
--- a/howto/changer_de_pseudo.md
+++ b/howto/changer_de_pseudo.md
@ -1,12 +1,12 @@
-# Changement d'état civil (ou plutôt changement de pseudo)
+# Changement de pseudo
 Le pseudo est l'identifiant unique permettant de s'authentifier sur l'ensemble
 des services du Crans. Pour diverses raisons dont il n'est pas question de
-juger, un⋅e utilisateur⋅rice peut vouloir changer de pseudo. C'est pénible mais
+juger, un⋅e utilisateur⋅rice peut vouloir changer de pseudo. C'est pénible
-faisable, ce petit guide est là pour rappeler tout ce qu'il ne faut pas
+mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est
 important. Ce petit guide est là pour rappeler tout ce qu'il ne faut pas
 oublier.
 ## Re2o
 Il faut bien un début, c'est sur l'intranet qu'on commence par renommer
@ -14,23 +14,22 @@ quelqu'un⋅e.  Il suffit d'éditer le profil et de changer le pseudo.
 Ne pas oublier d'aller contrôler le LDAP sur `yson-partou` pour s'assurer que
 l'ancien compte a bien été supprimé. Pour cela, faire un `sudo shelldap` sur
-`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que `cat
+`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que
-cn=ancienpseudo` ne renvoie rien.
+`cat cn=ancienpseudo` ne renvoie rien.
 ## Zamok
 Le plus évident, il faut déplacer le home ainsi que les mails.
-Si le pseudo vient à l'instant d'être modifié, il suffit de faire un `sudo mv
+Si le pseudo vient à l'instant d'être modifié, il suffit de faire un
-/home/{ancienpseudo,nouveaupseudo}`, sinon avec l'accord de la personne on peut
+`sudo mv /home/{ancienpseudo,nouveaupseudo}`, sinon avec l'accord de la
-faire un `rsync -ar /home/{ancienpseudo,nouveaupseudo}/`, ce qui va copier le
+personne on peut faire un `rsync -ar /home/{ancienpseudo,nouveaupseudo}/`, ce
-contenu de l'ancien home dans le nouveau, mais attention au remplacement de
+qui va copier le contenu de l'ancien home dans le nouveau, mais attention au
-données. L'ancien home peut ensuite être supprimé.
+remplacement de données. L'ancien home peut ensuite être supprimé.
 De la même manière, il faut renommer `/var/mail/ancienpseudo` en
 `/var/mail/nouveaupseudo`, ou déplacer le contenu et supprimer l'ancien dossier.
 De la même manière, il faut renommer `/var/mail/ancienpseudo`
 en`/var/mail/nouveaupseudo`, ou déplacer le contenu et supprimer l'ancien
 dossier.
 ## Backups
@ -44,43 +43,44 @@ mois au cas où pour supprimer l'ancien dossier inutile.
 éternellement. Pas pour des raisons de place mais pour des raisons de
 non-conservation de données personnelles.
 ## Gitlab
 S'il n'y a pas d'ancien compte, il n'y a rien à faire.
 S'il y a un ancien compte ET un nouveau compte, c'est pénible. Il faut
-transférer les appartenances de projet d'un compte à l'autre. Ce cas ne s'étant
+transférer les appartenances de projet d'un compte à l'autre. Ce cas ne
-pour l'instant pas présenté, il sera à détailler à terme.
+s'étant pour l'instant pas présenté, il sera à détailler à terme.
-On se place dans l'hypothèse où l'on veut renommer un ancien compte. On commence
+On se place dans l'hypothèse où l'on veut renommer un ancien compte. On
-par se rendre dans l'interface d'administration de Gitlab, section utilisateurs :
+commence par se rendre dans l'interface d'administration de Gitlab, section
 utilisateurs :
 [https://gitlab.crans.org/admin/users](https://gitlab.crans.org/admin/users).
 Si la personne s'est reconnectée avec son nouveau pseudo SANS AUCUNE CONTRIBUTION,
 alors on peut supprimer librement ce nouveau compte. On se rend ensuite dans les
 paramètres de l'ancien compte, on clique sur « Éditer » et on remplace le pseudo.
 Inutile de remplacer nom et adresse mail, ces champs sont importés par LDAP.
-Ensuite, on se rend dans l'onglet « Identités », et on met à jour l'identifiant LDAP.
+Si la personne s'est reconnectée avec son nouveau pseudo SANS AUCUNE
-Normalement, la personne peut désormais se connecter en ayant perdu ni projets
+CONTRIBUTION, alors on peut supprimer librement ce nouveau compte. On se rend
-ni commits, et son adresse mail ainsi que son nom seront mis à jour à sa
+ensuite dans les paramètres de l'ancien compte, on clique sur « Éditer » et
-prochaine connexion.
+on remplace le  pseudo. Inutile de remplacer nom et adresse mail, ces champs
 sont importés par LDAP.
 Ensuite, on se rend dans l'onglet « Identités », et on met à jour
 l'identifiant LDAP. Normalement, la personne peut désormais se connecter en
 n'ayant perdu ni projets ni commits, et son adresse mail ainsi que son nom
 seront mis à jour à sa prochaine connexion.
 ## Owncloud
-Deux cas à considérer : l'utilisateur⋅rice s'est servi⋅e des agendas Owncloud
+Deux cas à considérer : l'utilisateur⋅rice s'est servi⋅e des agendas
-ou non.  Dans le premier cas, c'est pénible et cette documentation sera mise à
+Owncloud ou non.  Dans le premier cas, c'est pénible et cette documentation
-jour afin de détailler comment exporter et réimporter les calendriers.
+sera mise à jour afin de détailler comment exporter et réimporter les
 calendriers.
-Dans le cas où il n'y a rien d'important de stocké sur Owncloud, si ce n'est
+Si l'utilisateurice n'a pas utilisé d'application externe et uniquement le
-les données (mais qui sont sur Zamok), il suffit simplement de se rendre dans
+téléversement de fichiers, il suffit simplement de se rendre dans l'interface
-l'interface d'administration, section utilisateur⋅rices :
+d'administration, section utilisateur⋅rices :
 [https://owncloud.crans.org/settings/users](https://owncloud.crans.org/settings/users),
 puis de chercher l'ancien compte et de simplement le supprimer. Les données
 étant montées sur Zamok, seul le home local inutile sera supprimé.
 ## Mailman
 On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/).
@ -93,18 +93,16 @@ S'il n'y a pas de nouveau compte, on peut changer le pseudo Mailman si
 souhaité, mais l'important est surtout d'aller dans les connexions sociales et
 de changer le pseudo utilisé pour lier le compte Mailman.
 ## Wiki
-Si la connexion par le CAS est configurée, il faut penser à `mv
+Si la connexion par le CAS est configurée, il faut penser à
-/var/local/wiki/assowiki/{ancienpseudo,nouveaupseudo}`. Concerne a priori peu
+`mv /var/local/wiki/assowiki/{ancienpseudo,nouveaupseudo}`. Concerne a priori
-de monde.
+peu de monde.
 ## The Lounge
 Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut aller
-sur Zamok et `mv /etc/thelounge/users/{ancienpseudo,nouveaupseudo}.json`.
+sur Zamok et `mv /etc/thelounge/users/{ancienpseudo,nouveaupseudo}.json`. Il y
-Il y a aussi des fichiers de d'historiques des messages que l'on peut
+a aussi des fichiers de d'historiques des messages que l'on peut supprimer
-supprimer `rm /etc/thelounge/logs/{pseudo}` et
+`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3`
-`rm /etc/thelounge/logs/{pseudo}.sqlite3` ou remommer.
+ou remommer.
--- a/howto/creer_vm_adherent.md
+++ b/howto/creer_vm_adherent.md
@ -1,8 +1,9 @@
 # Création de machine virtuelle pour les adhérent⋅es
 Le crans propose un système de locations de vms dont vous pouvez retrouver les
-tarifs dans les annexes des statuts de l'association. J'en fournis un
+tarifs dans les annexes des statuts de l'association. En voici un
-récapitulatif ici mais attention celui-ci peut ne pas être à jour et seul ce qui
+récapitulatif ici, mais attention celui-ci peut ne pas être à jour et seul
-est marqué dans les statuts fait foi.
+ce qui est marqué dans les statuts fait foi.
 |      Article                            | Tarifs |
 |:---------------------------------------:|:------:|
@ -13,25 +14,34 @@ est marqué dans les statuts fait foi.
 | Disque additionnel (par tranche de 16G) | 1€     |
 Le service minimal comprend :
-  - un disque de 8G
+
-  - un cœur
+* un disque de 8G
-  - 2G de ram
+* un cœur
 * 2G de ram
 Tous les services sont proposés pour une durée de 1 an.
 ## Utilisateur⋅ices
 La documentation pour les utilisateur⋅ices se trouvent sur le
 [wiki](https://wiki.crans.org/VieCrans/VPS).
 ## Nounous et apprenti⋅es
 ### Facturation
-TODO
+
 Quand cela est possible, privilégier la note. Sinon, voir avec un⋅e
 trésorier⋅ère pour d'autres méthodes (espèces, virement, ...).
 ### LDAP
-Quand un⋅e adhérent⋅e vous demande de lui créer une vm, il faut au préalable læ
+
-rajouter dans le ldap des adhérent⋅es (qui n'est pas le même que le ldap re2o).
+Quand un⋅e adhérent⋅e vous demande de lui créer une vm, il faut au
 préalable læ rajouter dans le ldap des adhérent⋅es (qui n'est pas le même
 que le ldap  re2o).
 Celui ci se situe sur flirt et à la structure suivante:
-```
+
 ```txt
 ou=users
 ├── cn=toto
 └── cn=titi
@ -41,9 +51,11 @@ ou=hosts
 ├── cn=voyager
 └── cn=curiosity
 ```
-Pour référence ma configuration `shelldap` pour me connecter au ldap est
+
-la suivante :
+Pour référence ma configuration `shelldap` pour me connecter au ldap est la
-```
+suivante :
 ```txt
 # +---------------------------------+
 # | Connexion à flirt.adm.crans.org |
 # +---------------------------------+
@ -52,11 +64,14 @@ promptpass: yes
 binddn: cn=admin,dc=adh,dc=crans,dc=org
 basedn: dc=adh,dc=crans,dc=org
 ```
 et le mot de passe est disponible dans le password-store sous `ldap-adh`.
 #### Utilisateur⋅ices
 Les objets utilisateur⋅ices dispose des champs suivants :
-```
+
 ```txt
 dn: cn=toto,ou=users,dc=adh,dc=crans,dc=org
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
@ -75,10 +90,12 @@ sn: Passoir
 telephoneNumber: +336xxxxxxxx
 userPassword: {CRYPT}$6$…
 ```
 Le script `addadherent` du repo
 [crans-ldap](https://gitlab.crans.org/nounous/crans-ldap) permet néanmoins de
 configurer la plupart des informations à renseigner :
-```
+
 ```bash
 [ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto
 Prénom: Toto
 NOM: Passoir
@ -89,23 +106,27 @@ Date de naissance (YYYY-MM-DD): 1998-01-08
 Lieu de naissance: Cachan
 ```
-Cela rajoutera automatiquement la date de début d'adhésion mais pas celle de fin
+Cela rajoutera automatiquement la date de début d'adhésion mais pas celle de
-d'adhésion, celle-ci doit être rajoutée à la main en utilisant votre client ldap
+fin d'adhésion, celle-ci doit être rajoutée à la main en utilisant votre
-favori.
+client ldap favori.
 #### Club
 Les clubs sont des objets ldap très simple qui ne contiennent que le nom des
 adhérent⋅es qui gèrent le club :
-```
+
 ```txt
 dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
 objectClass: organization
 objectClass: top
 description: toto
 o: rover
 ```
 Similairement, un script permet de rajouter ces informations automatiquement au
 ldap :
-```
+
 ```txt
 [ _shirenn@flirt ]$ ./addclub rover
 Pseudo du responsable: toto
 Pseudo du responsable: titi
@ -113,9 +134,11 @@ Pseudo du responsable:
 ```
 #### Machines
 Les machines sont des objets ldap qui répertorient des informations sur leur
 configuration et leurs propriétaires :
-```
+
 ```txt
 dn: cn=curiosity,ou=hosts,dc=adh,dc=crans,dc=org
 objectClass: top
 objectClass: device
@ -128,9 +151,12 @@ macAddress: 02:a0:00:01:99:12
 owner: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
 serialNumber: 199
 ```
 Le script `addadherenthost` crée la machine dans le ldap
-```
+
-[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac 02:a0:00:01:99:02 --vmid 199 --club rover curiosity
+```txt
 [ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac
 02:a0:00:01:99:02 --vmid 199 --club rover curiosity
 ```
 Le part-feu par défaut laisse passer tous les paquets icmp, tous les paquets en
@ -141,18 +167,19 @@ scripts devraient mettre à jour la configuration du parefeu, du dhcp et de
 proxmox.
 ### Proxmox
 Il faut maintenant aller sur le cluster constitué de gulp, odlyd et stitch pour
 créer la machine virtuelle. C'est du clic clic dans proxmox, vous êtes assez
 grand⋅es pour savoir lire des menus. (Par contre faites bien attention à créer
 les disques sur la pool `vm`).
-Ensuite, deux possibilités, soit l'adhérent⋅e vous a juste demandé de créer la
+Il faut maintenant aller sur le cluster constitué de gulp, odlyd et stitch
-machine virtuelle et à ce moment là c'est fini et iel peut aller la configurer
+pour créer la machine virtuelle. C'est du clic clic dans proxmox, vous êtes
-seul⋅e (c.f. section suivante), soit iel vous a demandé si vous pouviez lui
+assez grand⋅es pour savoir lire des menus. (Par contre faites bien attention
-installer une distribution de son choix.
+à  créer les disques sur la pool `vm`).
-Vous pouvez alors lui demander une clé publique ssh et après avoir installer la
+Ensuite, deux possibilités, soit l'adhérent⋅e vous a juste demandé de
-vm, vous la déposer dans `/root/.ssh/authorized_keys` (en faisant attention à
+créer la machine virtuelle et à ce moment là c'est fini et iel peut aller la
-créer le `.ssh` avec les bonnes permissions `mkdir -m 0700 /root/.ssh`) et vous
+configurer seul⋅e (c.f. section suivante), soit iel vous a demandé si vous
-supprimer les mots de passe que vous avez rentrer pendant l'installation `passwd
+pouviez lui installer une distribution de son choix.
-d root`).
+
 Vous pouvez alors lui demander une clé publique ssh, et après avoir installé
 la vm, vous la déposez dans `/root/.ssh/authorized_keys` (en faisant attention
 à créer le `.ssh` avec les bonnes permissions `mkdir -m 0700 /root/.ssh`) et
 vous supprimez les mots de passe que vous avez rentrer pendant l'installation
 `passwd -d root`).
--- a/howto/devenir_nounou.md
+++ b/howto/devenir_nounou.md
@ -1,4 +1,5 @@
 # Comment devenir nounou ?
 Bonjour jeune apprenti⋅e, tu regardes sûrement avec des yeux pleins d'étoiles
 tes ainé⋅es qui actuellement disposent des droits suprêmes sur l'infrastructure
 du Crans. Ce petit document est là pour t'expliquer comment toi aussi un jour tu
@ -36,7 +37,8 @@ d'apprendre de celles-ci et de s'assurer qu'elles ne sont pas irréversibles.
 Il y a aussi quelque chose qu'il faut souligner. Et normalement quand vous
 deviendrez nounou vous allez le voir assez fréquement (à chaque fois que vous
 faîtes un sudo pour la première fois sur une machine) :
-```
+
 ```txt
 We trust you have received the usual lecture from the local System
 Administrator. It usually boils down to these three things:
@ -44,6 +46,7 @@ Administrator. It usually boils down to these three things:
    #2) Think before you type.
    #3) With great power comes great responsibility.
 ```
 Ce court texte résume bien ce que je veux aborder ici. Les droits que vous vous
 voyez confier sont une intrusion phénoménale dans la vie privée des gens. Si
 vous voulez une métaphore, vous pouvez voir ça comme si les adhérent⋅es du Crans
@ -63,6 +66,7 @@ passer aux choses plus intéréssantes : comment on se donne ces droits (et dans
 marge, comment on se les retire) ?
 ## Rentre dans le cercle
 Le groupe des superadministrateur⋅rices au Crans est le groupe nounou. On va donc
 faire un petit tour dans le ldap et sous ou=groups,cn=_nounou on rajoute les
 uids correspondant au⋅x personne⋅s qu'on souhaite ajouter. Voilà, vous avez
@ -73,6 +77,7 @@ fonctionne pas. C'est sûrement dû à ces ~~conneries~~ de replicat ldap. Il fa
 `tools/ldap.md`).
 ## Give me the password
 Vous avez *50* nouveaux mot de passes. Il est maintenant nécessaire de
 rechiffrer le pass pour vous. C'est un peu chiant mais on s'y fait. Voilà la
 procédure:
@ -99,38 +104,45 @@ complètement à quelqu'un⋅e la possibilité d'utiliser un mot de passe. Dans
 cas il faut le changer :(
 ## Thank you for your services
 Au Crans on a **plein** de services. Certains sont gentils et écoutent
 directement le ldap pour savoir qui a des droits, d'autres s'en foutent et ils
 faut se rajouter dans les admins à la main. Petite liste ci dessous.
 ### Gitlab
 Il faut aller dans la zone d'administration, puis dans la liste
 d'utilisateur⋅ices et changez le profil de l'utilisateur⋅ice de regular à admin.
 ### Mailman
 Il faut se connecter normalement au logiciel, puis allez dans la section admin
-https://lists.crans.org/admin, dans la sous page utilisateur⋅rices, on peut
+<https://lists.crans.org/admin>, dans la sous page utilisateur⋅rices, on peut
 rechercher les personnes concernées pour leur donner les deux statuts admin
 (accès à la zone d'administration) et superutilisateur (bypass tous les checks
 de droits).
 ### Owncloud
-Il faut aller dans la zone d'administration et rajouter les utilisateur⋅icess au
+
 Il faut aller dans la zone d'administration et rajouter les utilisateur⋅ices au
 groupe d'administration.
 ### Re2o
 Oh lad, j'espère que ça aussi ça existe plus. Il faut aller dans la section
 gestion des groupes et rajouter les personnes aux groupes nounous et au groupe
 superutilisateur⋅rice.
 ### Kiwi
 On édite le fichier de conf du wiki sous `/etc/moin/mywiki.py` et on rajoute son
 compte wiki dans la liste des administrateur⋅rices.
 ### IRC
 On édite le fichier `/etc/inspircd/opers.conf` pour rajouter un bloc suivant
-```
+```txt
 <oper
    name=<nick>
    password="<pass-hash>"
@ -141,10 +153,11 @@ On édite le fichier `/etc/inspircd/opers.conf` pour rajouter un bloc suivant
    autologin="on"
 >
 ```
-Où le hash du mot de passe peut être obtenu en envoyant `/quote mkpasswd
+
-hmac-sha256 <password>`. Pour rendre les changements effectifs on reload le
+Où le hash du mot de passe peut être obtenu en envoyant
-service inspircd (tips, la manière la plus rapide de perdre ses droits est de
+`/quote mkpasswd hmac-sha256 <password>`. Pour rendre les changements effectifs
-restart le serveur plutôt que de le reload ^^).
+on reload le service inspircd (tips, la manière la plus rapide de perdre ses
 droits est de restart le serveur plutôt que de le reload ^^).
 ### Mails
@ -157,4 +170,4 @@ bien à jour `redisdead`, `sputnik` et surtout `zamok` dans le dossier
 l'adresse `root@crans.org` sur votre client.
 Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de
-https://wiki.crans.org/CransNounous !
+<https://wiki.crans.org/CransNounous> !
--- a/howto/security_101.md
+++ b/howto/security_101.md
@ -1,79 +0,0 @@
 # Security 101: Quelques bases de sécurité
 Le but ici est de donner quelques conseils généraux de sécurité qui est bon à
 respecter le plus possible lors de changements de l'infrastructure ou de
 services.
 La liste ne se veut pas exhaustive, mais permet de donner l'esprit global qu'il
 faut avoir.
 ## Sécurité des comptes utilisateurs
 Que ce soit les membres de l'association, comme les membres actifs, il faut
 prendre les précautions pour s'assurer que ses identifiants ne fuient pas dans
 la nature :
  * **Ne pas avoir de comptes locaux avec des mots de passe actifs.**
    Un compte avec possibilité d'authentification par mot de passe DOIT être
    dans l'annuaire LDAP. Cela permet de faciliter le changement de mot de
    passe et ne pas laisser des mots de passe cassés traîner.
  * **Ne pas partager un compte.**
    Et oui, on évite de filer son mot de passe à son voisin.
  * **Avoir un mot de passe solide.**
    `toto2345` n'est pas un bon mot de passe et prend en moyenne moins de 5
    minutes à être bruteforcée avec
    [john](https://fr.wikipedia.org/wiki/John_the_Ripper).
  * **Favoriser l'authentification par paire de clées.**
    Pour les services le permettant (SSH, Git...), il est préférable d'avoir
    une paire de clé. Une clé privée ne doit jamais quitter le périphérique
    où elle a été créée (que ça soit un token matériel ou une machine Linux).
    Il est préférable de protéger la clé privée par un mot de passe.
    Ainsi si une de vos machine est compromise, vous pouvez révoquer seulement
    sa clé et tracer où elle a été utilisée.
  * **Favoriser la double authentification.**
    Pour les services critiques (paiement, accès root...) il est préférable
    d'ajouter un second facteur d'authentification et d'alerter l'équipe si
    seulement le premier facteur a réussi mais le second a échoué.
    Pour les services Web, voir le standard WebAuthn. Pour OpenSSH il existe
    des intégrations avec des applications de second authentification.
  * **Utiliser un gestionnaire de mots de passe pour les secrets partagés.**
    Pour les secrets partagés au sein de l'équipe technique, on les chiffre
    pour les clés privées de chaque administrateur.
 ## Sécurité des logiciels développés
  * **Ne pas fixer strictement les versions des paquets.**
    Il faut s'assurer que les contraintes sur les dépendances permettent
    d'obtenir les mises à jour de sécurité. Souvent il n'est que nécessaire
    de fixer la version majeure (`~=2.1`, plutôt que `==2.1.1`).
  * **Privilégier le gestionnaire de paquet de la distribution.**
    La distribution rétroporte les mises à jour de sécurité. Il est donc de
    bon goût d'utiliser le plus possible ses paquets pour simplifier la mise
    à jour de l'ensemble de l'infrastructure. 
  * **Utiliser des outils de linting avec des règles de sécurité.**
    Les bons outils de linting connaissent les patterns pouvant potentiellement
    se traduire en faille de sécurité.
  * **Lancer le logiciel en non-privilégiés.**
    Un logiciel ne devrait jamais avoir besoin de `root` ou de `sudo`.
    Lors de l'écriture du service, on peut également ajouter des protections
    supplémentaires pour augmenter l'isolation.
 ## Sécurité de l'infrastructure
  * **Faire ses backups, et vérifier qu'elles marchent.**
  * **Faire des scans des ports ouverts.**
    Pour cela on peut lancer `nmap` sur la plage d'adresses IP.
  * **Monitorer et alerter.**
  * **Segmenter les services.**
    Isoler les services sur différentes machines et augmenter l'indépendance
    permet d'améliorer la robustesse de l'infrastructure.
--- a/howto/supprimer_utilisateur.md
+++ b/howto/supprimer_utilisateur.md
@ -1,62 +1,64 @@
 # La suppression d'un⋅e utilisateurice
-Pour diverses raisons dont il n'est pas question de juger, un⋅e utilisateur⋅rice
+Pour diverses raisons dont il n'est pas question de juger, un⋅e
-peut vouloir supprimer son compte Crans et les données associées. En particulier
+utilisateur⋅rice peut vouloir supprimer son compte Crans et les données
-cela peut rentrer dans le cadre du
+associées. En particulier cela peut rentrer dans le cadre du
 [RGPD](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/). Il y a
 certaines informations qu'il faut garder une durée minimale, mais les autres
-doivent être supprimées à la demande de l'utilisateurice. C'est pénible mais
+doivent être supprimées à la demande de l'utilisateurice. C'est pénible
-faisable, ce petit guide est là pour rappeler tout ce qu'il ne faut pas oublier.
+mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est
 important. Ce  petit guide est là pour rappeler tout ce qu'il ne faut pas
 oublier.
 ## La demande de suppression
 Il faut s'assurer que c'est bien la bonne personne qui fait la demande. En cas
-de doute, on peut demander une preuve d'identité (pièce d'identité, mail depuis
+de doute, on peut demander une preuve d'identité (pièce d'identité, mail
-l'adresse mail crans...). Ensuite, on peut vérifier que la personne à bien
+depuis l'adresse mail crans...). Ensuite, on peut vérifier que la personne à
-compris ce que la suppression de compte impliquait : la perte de toutes les
+bien compris ce que la suppression de compte impliquait : la perte de toutes
-données non-backupées par l'utilisateurice, ne plus avoir accès aux services qui
+les données non sauvegardées par l'utilisateurice, ne plus avoir accès aux
-neccessite un compte crans... Selon ce qui est demandé (et ce qu'on a le droit
+services  qui nécessite un compte crans... Selon ce qui est demandé (et ce
-de faire), le compte peut être seulement archivé, on peut supprimer les données
+qu'on a le droit de faire), le compte peut être seulement archivé, on peut
-liées au compte (en totalité ou partie), voire les données d'un service non-lié
+supprimer les données liées au compte (en totalité ou partie), voire les
-à un compte crans (wiki...). Si la personne est encore adhérente, elle va
+données d'un service  non-lié à un compte crans (wiki...). Si la personne
-probablement devoir démissionner de l'association.
+est encore adhérente, elle va probablement devoir démissionner de
-
+l'association.
 ## Re2o
-Il faut bien un début, c'est sur l'intranet qu'on commence par supprimer/
+Il faut bien un début, c'est sur l'intranet qu'on commence par
-archiver quelqu'un⋅e.
+supprimer/archiver quelqu'un⋅e.
 ### Archiver sur Re2o
 Si la personne à une facture/adhésion de moins de 10 ans, on ne peut pas
 supprimer le compte. Dans ce cas-là, ou si c'est ce que préfère
-l'utilisateurice, on archive le compte : dans le profil, il faut changer l'état
+l'utilisateurice, on archive le compte : dans le profil, il faut changer
-de "Actif⋅ves" à "Complétement archivé⋅es". On peut éventuellement supprimer
+l'état de "Actif⋅ves" à "Complétement archivé⋅es". On peut
-certaines informations (bannissement, établissement...) mais on doit garder les
+éventuellement  supprimer certaines informations (bannissement,
-informations de contact et les factures/adhésions de moins de 10 ans.
+établissement...) mais on doit garder les informations de contact et les
 factures/adhésions de moins de 10 ans.
-On peut repasser au bout des 10 ans pour tout supprimer (ça serait bien d'avoir
+On peut repasser au bout des 10 ans pour tout supprimer (ça serait bien
-un truc automatique ou que l'utilisateurice nous le rappelle).
+d'avoir un truc automatique ou que l'utilisateurice nous le rappelle).
 ### Supprimer sur Re2o
 Il faut aller dans l'interface d'administration
-https://re2o.crans.org/admin/users/user/ et supprimer l'user. Il va falloir
+<https://re2o.crans.org/admin/users/user/> et supprimer l'user. Il va falloir
 supprimer les objets protégés avant, django vous dira lesquels.
 Ne pas oublier d'aller contrôler le LDAP sur `yson-partou` pour s'assurer que
 le compte a bien été supprimé. Pour cela, faire un `sudo shelldap` sur
-`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que `cat
+`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que `cat cn={pseudo}`
-cn={pseudo}` ne renvoie rien.
+ne renvoie rien.
 ## Zamok
 Le plus évident, il faut supprimer le home ainsi que les mails.
-Il suffit de faire un `sudo rm -rf /home/{pseudo}`, pour supprimer le home.
+Il suffit de faire un `sudo rm -rf /home/{pseudo}`, pour supprimer le home. De
-De même pour les mails dans `/var/mail/{pseudo}`.
+même pour les mails dans `/var/mail/{pseudo}`.
 ## Backups
@ -68,18 +70,19 @@ pour supprimer `/backup/borg-adh/home/{pseudo}`.
 non-conservation de données personnelles (même si les backup ne sont pas
 concernées par le RGPD).
 ## Gitlab
 S'il n'y a pas de compte, il n'y a rien à faire.
 On se place dans l'hypothèse où l'on veut supprimer un compte. On commence
-par se rendre dans l'interface d'administration de Gitlab, section utilisateurs :
+par se rendre dans l'interface d'administration de Gitlab, section utilisateurs
 :
 [https://gitlab.crans.org/admin/users](https://gitlab.crans.org/admin/users).
-On se rend dans les paramètres du compte, on clique sur « Administration des
+On se rend dans les paramètres du compte, on clique sur "Administration des
-utilisateur » puis sur 'Supprimer un compte utilisateur' ou 'Supprimer un compte
+utilisateur" puis sur "Supprimer un compte utilisateur" ou "Supprimer un
-utilisateur et ses contributions'. Dans le deuxième cas, il faut faire attention
+compte utilisateur et ses contributions". Dans le deuxième cas, il faut faire
-surtout s'il y a des contributions à des projets partagés (comme ceux du crans).
+attention surtout s'il y a des contributions à des projets partagés (comme
 ceux du  crans).
 ## Owncloud
@ -88,7 +91,6 @@ utilisateurices :
 [https://owncloud.crans.org/settings/users](https://owncloud.crans.org/settings/users),
 puis de chercher le compte et de simplement le supprimer.
 ## Mailman
 On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/).
@ -97,19 +99,19 @@ S'il n'y a pas de compte, aucune question à se poser.
 S'il y a un compte, on le supprime.
-Potentiellement, la personne est présente sur mailman de manière non-liée à son
+Potentiellement, la personne est présente sur mailman de manière non-liée à
-éventuel compte crans. Dans ce cas, il va falloir faire du ménage avec l'adresse
+son éventuel compte crans. Dans ce cas, il va falloir faire du ménage avec
-mail et donc de l'aide de l'utilisateurice qui va devoir indiquer son adresse et
+l'adresse mail et donc de l'aide de l'utilisateurice qui va devoir indiquer son
-les ML qu'iel reçoit/administre. Ça peut être un peu les bazard si il y a
+adresse et les ML qu'iel reçoit/administre. Ça peut être un peu les bazar
-plusieurs adresses non-liées. Si la personne est lae dernièr⋅e propriétaire
+si il y a plusieurs adresses non-liées. Si la personne est lae dernièr⋅e
-d'une liste, il faudra soit la supprimer soit lui trouver un nouveau
+propriétaire d'une liste, il faudra soit la supprimer soit lui trouver un⋅e
-propriétaire (c'est pas obligatoire mais alors c'est root@crans.org le
+nouvelleau propriétaire (c'est pas obligatoire mais alors c'est root@crans.org
-propriétaire par défaut, ce qui n'est pas une solution durable)
+le propriétaire par défaut, ce qui n'est pas une solution durable).
 ## Wiki
-Si la connexion par le CAS est configurée, il faut penser à `rm
+Si la connexion par le CAS est configurée, il faut penser à
-/var/local/wiki/assowiki/{pseudo}`. Concerne a priori peu de monde.
+`rm /var/local/wiki/assowiki/{pseudo}`. Concerne a priori peu de monde.
 Si la personne le demande, on peut supprimer son compte wiki et les pages qui
 concernent son compte (page perso...), historique compris. Pour cela il faut
@ -120,19 +122,18 @@ des personnes n'ayant pas de compte crans, mais il faudra le WikiNom.
 S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et
 `rm /etc/thelounge/users/{pseudo}.json` (configuration),
-`rm /etc/thelounge/logs/{pseudo}` et
+`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3`
-`rm /etc/thelounge/logs/{pseudo}.sqlite3` (pour l'historique des
+(pour l'historique des messages).
 messages).
 ## Autres données
 Il y a probablement des données personnelles qui trainent ailleurs, il faudra
-mettre à jour cette page si on en trouve. Par exemple, pour les membres actif⋅ves
+mettre à jour cette page si on en trouve. Par exemple, pour les membres
-qui ont un compte underscore ou les utilisateurices qui ont (eu) une VM (perso ou
+actif⋅ves qui ont un compte underscore ou les utilisateurices qui ont (eu) une
-de club).
+VM (perso  ou de club).
 ## Données hébergées mais pas administrée par le Crans
 Le Crans héberge des VM pour les clubs (note, serveur photos, bdd med...) qui
-peuvent contenir des données personnelles. La personne devra aller voir les admins
+peuvent contenir des données personnelles. La personne devra aller voir les
-de ces services pour supprimer les données.
+admins de ces services pour supprimer les données.
--- a/infrastructure/README.md
+++ b/infrastructure/README.md
@ -0,0 +1,20 @@
 # Infrastructure
 ## Présentation
 Ce dossier contient toute la documentation concernant l'infrastructure du
 Crans, c'est à dire les machines, les VM (machines virtuelles), les réseaux
 virtuels ou encore le fonctionnement des services internes au Crans (les LDAP,
 PostgreSQL, ...).
 ## Organisation
 * [`machines`](machines) : contient la documentation de l'ensemble des
  machines physiques et virtuelles du Crans. On y inclut également par extension
  les appareils physiques (comme les switchs).
 * [`reseaux`](reseaux) : documentation sur les réseaux (virtuels ou non)
  utilisés au Crans, et sur leur utilisation.
 * [`services`](services) : documentation sur les services mis à disposition
  par le Crans et pour le Crans (les LDAP, PostgreSQL, le CAS, ...).
--- a/infrastructure/cachan.md
+++ b/infrastructure/cachan.md
@ -1,16 +0,0 @@
 # Infrastructure restant Cachan sur le début de l'année 2022
 Le temps d'avoir un système de backups opérationnel chez Aurore et ViaRézo,
 trois serveurs sont encore présents à Cachan, à savoir Charybde, Zephir et Omnomnom.
 ## Plan d'adressage
 | VLAN | Bloc d'IPv4         | Bloc d'IPv6                             | Utilisation    |
 |------|---------------------|-----------------------------------------|----------------|
 | 8    | `82.65.62.126`      | `2a01:e0a:9d4:e1b0:a873:65ff:fe63:6f77` | Freebox        |
 | 10   | `172.17.10.0/24`    | `fd00:0:0:10::/64`                      | cachan-adm     |
 ### ADM
 Le réseau ADM est bridgé sur Charybde au réseau d'administration de Saclay.
--- a/infrastructure/cluster-adh.md
+++ b/infrastructure/cluster-adh.md
@ -1,8 +0,0 @@
 # Cluster adhérents
 Le Crans dispose d'un cluster de virtualisation [Proxmox](/tools/proxmox.md) comptant en date du 8 décembre 2021 deux virtualiseurs, à savoir :
 * `odlyd`
 * `stitch`
 * `gulp`
 Le stockage des machines virtuelles de ce cluster est fait sur `cameron` dans le dataset `pool/vm-adh` via le VLAN `san`.
--- a/infrastructure/debian.md
+++ b/infrastructure/debian.md
@ -1,24 +0,0 @@
 # Debian
 C'est le SEUL os qu'on utilise au crans.
 ## Bookworm
 Voilà la liste des machines qui ont été passées sous bookworm :
  - wall-e (100)
  - eclat (104)
  - gitlab-ci (106)
  - roundcube (107)
  - voyager (109)
  - mailman (110)
  - belenios (111)
  - ptf (113)
  - flirt (114)
  - boeing (117)
  - cas (120)
  - ecilis (122)
  - trinity (123)
  - redisdead (124)
  - routeur-2754 (127)
  - romanesco (128)
  - helloworld (131)
--- a/infrastructure/ldap-adh.md
+++ b/infrastructure/ldap-adh.md
@ -1,81 +0,0 @@
 # LDAP Adhérents
 Le Crans dispose d'une base de données stockant les machines des adhérents disposant d'une connexion active et accessible vie le protocole LDAP.
 ## Connexion
 Le serveur LDAP est hébergé sur la machine `flirt` et est accessible sur le port 389. Pour s'y connecter, on peut faire une redirection de ports comme par exemple :
 ```bash
 ssh -L 1636:172.16.10.114:636 tealc.adm.crans.org -J zamok.adm.crans.org
 ```
 Le plus simple est d'utiliser `shelldap`, permettant de naviguer simplement à travers la base (voir [la documentation sur le LDAP admin](ldap.md)). 
 ## Schéma
 Voici la hiérarchie actuelle du LDAP (mars 2023) :
 ```
 dc=adh,dc=crans,dc=org
 |
 +-cn=admin
 |
 +-cn=membership
 |
 +-cn=reader
 |
 +-ou=users
 | +-cn=user (inetOrgPerson)
 |
 +-ou=clubs
 | +-o=club (organization)
 |
 +-ou=hosts
 | +-cn=machine (device, ipHost, ieee802Device)
 |
 +-ou=networks
  +-ipNetworkNumber=<IPv6> (ipNetwork, ipHost)
 ```
 ## Utilisateurs
 Les adhérents sont ajoutés dans `ou=users` et ont les attributs suivants :
 * `cn`: le pseudo de l'adhérent
 * `givenName`: le prénom de l'adhérent
 * `sn`: le nom de famille de l'adhérent
 * `mail`: l'adresse email de l'adhérent
 * `postalAddress`: l'adresse postale de l'adhérent (au format 1 Rue Machin, 75000 Ville)
 * `telephoneNumber`: le numéro de téléphone de l'adhérent
 L'attribut `description` est utilisé afin de stocker des informations supplémentaires:
 * `birthDate`: la date de naissance de l'adhérent au format `YYYY-MM-DD`
 * `birthLocation`: la ville de naissance de l'adhérent
 * `membershipStart`: la date de la première adhésion de l'adhérent au format `YYYY-MM-DD`
 * `membershipEnd`: la date de fin de l'adhésion de l'adhérent au format `YYYY-MM-DD`
 * `re2oId`: l'identifiant d'utilisateur de l'adhérent dans l'intranet
 # Clubs
 Les clubs sont ajoutés dans `ou=clubs` et ont les attributs suivants :
 * `o`: le nom du club
 * `description`: le pseudo de l'adhérent responsable du club
 # Machines
 Les machines sont ajoutées dans `ou=hosts` et ont les attributs suivants :
 * `cn`: le nom de la machine
 * `ipHostNumber`: les addresses IP de la machine
 * `macAddress`: l'adresse MAC de la machine
 * `description`: l'ouverture de ports de la machine
 * `owner`: le dn du propriétaire de la machine (utilisateur ou club)
 # Réseaux
 Les sous-réseaux adhérents sont ajoutés dans `ou=networks` et ont les attributs suivants :
 * `dn`: le nom du sous-réseau
 * `cn`: le pseudo de l'adhérent propriétaire du sous-réseau
 * `description` (optionnel) : deux NSRecord et un DSRecord du sous-réseau
 * `ipHostNumber`: IPv6 interface avec le sous-réseau
 * `ipNetMaskNumber`: masque de sous-réseau
 * `ipNetworkNumber`: première IPv6 du sous-réseau
--- a/infrastructure/machines/debian.md
+++ b/infrastructure/machines/debian.md
@ -0,0 +1,41 @@
 # Debian
 C'est le SEUL os qu'on utilise au crans.
 ## Bookworm
 Voilà la liste des machines qui ont été passées sous bookworm :
 * wall-e (100)
 * eclat (104)
 * gitlab-ci (106)
 * roundcube (107)
 * voyager (109)
 * mailman (110)
 * belenios (111)
 * ptf (113)
 * flirt (114)
 * boeing (117)
 * cas (120)
 * ecilis (122)
 * trinity (123)
 * redisdead (124)
 * routeur-2754 (127)
 * romanesco (128)
 * helloworld (131)
--- a/infrastructure/machines/physiques/arista.md
+++ b/infrastructure/machines/physiques/arista.md
@ -1,6 +1,8 @@
 # Arista 7150S-24
-Le CRANS possède des switches [Arista 7150S-24](https://www.arista.com/en/products/7150-series) avec 24 ports SFP/SFP+.
+Le CRANS possède des switches
 [Arista 7150S-24](https://www.arista.com/en/products/7150-series) avec 24 ports
 SFP/SFP+.
 ## Se connecter au switch
@ -8,21 +10,28 @@ Il existe différentes façons de se connecter au switch.
 ### Port console en série
-Les switches Arista ont un port série au format RJ-45, il suffit de brancher un cable USB-Série+Série-Ethernet et d'utiliser `screen`.
+Les switches Arista ont un port série au format RJ-45, il suffit de brancher un
 cable USB-Série+Série-Ethernet et d'utiliser `screen`.
 Par exemple :
 ```bash
 sudo screen /dev/ttyUSB0
 ```
-Pour éviter de lancer screen en root, il est également possible d'ajouter son utilisateur dans le groupe `dialout` avec `gpasswd -a $USER dialout`.
+Pour éviter de lancer screen en root, il est également possible d'ajouter son
 utilisateur dans le groupe `dialout` avec `gpasswd -a $USER dialout`.
 ### Port de management
-> L'unité de management du switch est isolé du reste du switch. Il est donc impossible de ping les machines connectés au switch depuis l'interface d'administration.
+> L'unité de management du switch est isolé du reste du switch. Il est donc
 > impossible de ping les machines connectés au switch depuis l'interface
 > d'administration.
-Il est également possible de se connecter en SSH sur le port de management du switch, que l'on peut activer depuis la connexion en série :
+Il est également possible de se connecter en SSH sur le port de management du
-```
+switch, que l'on peut activer depuis la connexion en série :
 ```txt
 switch>enable
 switch#config
 switch(config)#management ssh
@ -36,30 +45,37 @@ switch#write
 Il faut ensuite créer un utilisateur pour la connexion ssh.
-```
+```txt
 switch(config)#username [nom d'utilisateur] secret [mot de passe]
 ```
 On peut aussi préciser sa clé ssh
-```
+
 ```txt
 switch(config)#username [nom d'utilisateur] sshkey file tftp:[ip du serveur tftp]/[fichier de clé publique]
 ```
 ## Remettre à zéro le switch
-Se connecter en série au boot du switch puis entrer dans Aboot en utilisant `^C` quand c'est indiqué puis entrer les commandes :
+Se connecter en série au boot du switch puis entrer dans Aboot en utilisant
-```
+`^C` quand c'est indiqué puis entrer les commandes :
 ```txt
 Aboot#cd /mnt/flash
 Aboot#mv startup-config startup-config.old
 Aboot#exit
 ```
-Le switch va alors reboot avec la configuration par défaut. Le login par défaut de l'administrateur est `admin` et n'a pas de mot de passe.
+Le switch va alors reboot avec la configuration par défaut. Le login par défaut
 de l'administrateur est `admin` et n'a pas de mot de passe.
 ## Autoriser les SFP tiers
-Par défaut le switch n'accepte que les SFP/SFP+ Arista, il est possible d'utiliser des SFP tiers (comme ceux de !FiberStore) avec les commandes suivantes :
+Par défaut le switch n'accepte que les SFP/SFP+ Arista, il est possible
-```
+d'utiliser des SFP tiers (comme ceux de !FiberStore) avec les commandes
 suivantes :
 ```bash
 switch>enable
 switch#bash
 [admin@switch ~]$ touch /mnt/flash/enable3px
@ -72,35 +88,43 @@ Le switch va alors reboot en mode de compatibilité avec les SFP tiers.
 ### Créer un VLAN
-Pour que le switch accepte de commuter les trames taggées il faut créer le VLAN :
+Pour que le switch accepte de commuter les trames taggées il faut créer le
-```
+VLAN :
 ```txt
 switch>enable
 switch#config
 switch(config)#vlan 2
 switch(config-vlan-2)#
 ```
-Cela suffit à créer le VLAN, la liste des VLAN peut être affichée avec la commande `show vlan`.
+Cela suffit à créer le VLAN, la liste des VLAN peut être affichée avec la
 commande `show vlan`.
 ### Configurer les VLANs
-On va commencer par la stratégie de bourrins. On va autoriser tous les VLANs sur le port courant. Pour cela, on le passe en mode trunk pour qu'il accepte de commuter sur tous les VLANs connus du switch :
+On va commencer par la stratégie de bourrins. On va autoriser tous les VLANs
 sur le port courant. Pour cela, on le passe en mode trunk pour qu'il accepte de
 commuter sur tous les VLANs connus du switch :
-```
+```txt
 switch(config)#interface ethernet 1
 switch(config-if-Et1)#switchport mode trunk
 ```
-C'est un peu violent et en plus ça a le mauvais gout de tagger tous les VLANs sauf celui dit natif (par défaut celui de plus petit nombre défini ou 1). On peut remédier au deuxième point en lui disant de tagger son VLAN natif :
+C'est un peu violent et en plus ça a le mauvais gout de tagger tous les VLANs
 sauf celui dit natif (par défaut celui de plus petit nombre défini ou 1). On
 peut remédier au deuxième point en lui disant de tagger son VLAN natif :
-```
+```txt
 switch(config)#interface ethernet 1
 switch(config-if-Et1)# switchport trunk native vlan tag
 ```
-Et si on veut restreindre le caractère bourrin d'autoriser tous les VLANs, on peut specifier lesquels nous intéressent (et même en ajouter à posteriori) :
+Et si on veut restreindre le caractère bourrin d'autoriser tous les VLANs, on
 peut specifier lesquels nous intéressent (et même en ajouter à posteriori) :
-```
+```txt
 switch(config)#interface ethernet 1
 switch(config-if-Et1)# switchport trunk allowed vlan 1-3,9-77,999
 switch(config-if-Et1)# switchport trunk allowed vlan add 7
@ -108,66 +132,93 @@ switch(config-if-Et1)# switchport trunk allowed vlan add 7
 ### Configurer le LACP
-Pour configurer le LACP entre 2 ports, on commence par les sélectionner dans l'interface de configuration, puis on lui dit de faire du LACP sur ces deux ports. On utilise le plus petit nombre de port sélectionné comme identifiant de LACP.
+Pour configurer le LACP entre 2 ports, on commence par les sélectionner dans
 l'interface de configuration, puis on lui dit de faire du LACP sur ces deux
 ports. On utilise le plus petit nombre de port sélectionné comme identifiant de
 LACP.
-```
+```txt
 thor(config)#interface ethernet 3-4
 thor(config-if-Et3-4)#channel group 3 mode active
 thor(config-if-Et3-4)#exit
 ```
-Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface Port-Channel 3.
+Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface
 Port-Channel 3.
-```
+```txt
 thor(config)#interface Port-Channel 3
 thor(config-if-Po3)#
 ```
 ### Mettre à jour le switch
-> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu ressens la nécessité de le faire, voila comment.
+> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu
 > ressens la nécessité de le faire, voila comment.
-Bon la première étape, c'est de trouver les images de EOS. Et là, c'est déjà pas trivial de les trouver… Arista fait payer les images de ses OS et du coup, il faut chercher par des moyens détourner de les trouver. Nous on les avaient trouvé là http://41.78.188.108/sw/eos/ mais rien n'assure que cela vous aidera.
+Bon la première étape, c'est de trouver les images de EOS. Et là, c'est déjà
 pas trivial de les trouver… Arista fait payer les images de ses OS et du coup,
 il faut chercher par des moyens détourner de les trouver. Nous on les avaient
 trouvé là <http://41.78.188.108/sw/eos/> mais rien n'assure que cela vous aidera.
-Ensuite on va télécharger l'image sur le switch, mais là un problème de place pourrait survenir, il n'y a pas beaucoup d'espace mémoire dans la mémoire flash et il faudra probablement supprimer l'ancienne image avant de télécharger la nouvelle (considérer la copier quelques part avant pour la sauvegarder en utilisant par exemple  {{{copy [ancienne image] scp:[user]@[ip du serveur]/[chemin vers le home du user]/[ancienne image]}}}).
+Ensuite on va télécharger l'image sur le switch, mais là un problème de place
 pourrait survenir, il n'y a pas beaucoup d'espace mémoire dans la mémoire flash
 et il faudra probablement supprimer l'ancienne image avant de télécharger la
 nouvelle (considérer la copier quelques part avant pour la sauvegarder en
 utilisant par exemple :
 ```bash
 copy [ancienne image] scp:[user]@[ip du serveur]/[chemin vers le home du user]/[ancienne image]
 ```
 ```txt
 georges(config)# delete [ancienne image] #### uniquement si nécessaire
 georges(config)# copy tftp:[ip du serveur tftp]/[nouvelle image] flash:/[nouvelle image]
 ```
 Et là on va dire à l'os de boot dessus :
-```
+```txt
 georges(config)# boot system flash:/[nouvelle image]
 ```
-Il se peut que la commande rate à cause de manque d'espace sur la mémoire flash. Si c'est le cas, je vous conseille de recopier l'ancienne image sur le switch et de passer votre chemin. Mais si vous êtes vraiment tenieux, vous pouvez essayer de stocker l'image autre part et ensuite de la deployer (mais c'est à vos risques et périls mais surtout à celui du switch). Si vous avez cependant réussi à déployer l'image, ''il ne faut surtout pas oublier de sauvegarder les modifications''.
+Il se peut que la commande rate à cause de manque d'espace sur la mémoire
 flash. Si c'est le cas, je vous conseille de recopier l'ancienne image sur le
 switch et de passer votre chemin. Mais si vous êtes vraiment tenieux, vous
 pouvez essayer de stocker l'image autre part et ensuite de la deployer (mais
 c'est à vos risques et périls mais surtout à celui du switch). Si vous avez
 cependant réussi à déployer l'image, "il ne faut surtout pas oublier de
 sauvegarder les modifications".
-```
+```txt
 georges(config)#write
 ```
 ## Rendre compatible le switch aux personnes ayant de l'hyperacousie
-Par défaut les `fan-speed` sont à 80% ce qui donne un bruit de disqueuse, tout en gardant des températures très basses tout en ayant aucune charge.
+Par défaut les `fan-speed` sont à 80% ce qui donne un bruit de disqueuse, tout
 en gardant des températures très basses tout en ayant aucune charge.
-Il peut être intéressant de baisser au moins temporairement la vitesse si vous travaillez à côté du switch et que vous êtes en visio. Le bruit généré n'est pas linéaire avec la vitesse du ventilo et trop baisser la vitesse peut éteindre violemment le switch dès qu'il chauffe trop. Déjà 10% de vitesse en moins réduit grandement le bruit.
+Il peut être intéressant de baisser au moins temporairement la vitesse si vous
 travaillez à côté du switch et que vous êtes en visio. Le bruit généré n'est
 pas linéaire avec la vitesse du ventilo et trop baisser la vitesse peut
 éteindre violemment le switch dès qu'il chauffe trop. Déjà 10% de vitesse en
 moins réduit grandement le bruit.
 Par les observations d'erdnaxe en visio, 60% est un bon compromis,
-```
+```txt
 georges(config)#environment fan-speed override 60
 ```
 Pour voir la vitesse actuelle,
-```
+```txt
 georges(config)#show environment cooling
 ```
 Pour remettre le mode auto,
-```
+```txt
 georges(config)#environment fan-speed auto
 ```
--- a/infrastructure/machines/physiques/cluster-adh.md
+++ b/infrastructure/machines/physiques/cluster-adh.md
@ -0,0 +1,13 @@
 # Cluster adhérents
 Le Crans dispose d'un cluster de virtualisation [Proxmox](/tools/proxmox.md)
 comptant en date du 8 décembre 2021 deux virtualiseurs, à savoir :
 * `odlyd`
 * `stitch`
 * `gulp`
 Le stockage des machines virtuelles de ce cluster est fait sur `cameron` dans
 le dataset `pool/vm-adh` via le VLAN `san`.
--- a/infrastructure/machines/physiques/serveurs.md
+++ b/infrastructure/machines/physiques/serveurs.md
@ -3,7 +3,7 @@
 Voici la liste des serveurs du Crans :
 | Nom du serveur | Modèle | Numéro de série | Référence | Date de la facture | Fin de garantie | Fonction |
-|-|-|-|-|-|-|-|
+|----------------|--------|-----------------|-----------|--------------------|-----------------|----------|
 | tealc | Syneto | à reporter ici | | N/A | N/A | Baie de stockage des disques des VMs et des homes des nounous |
 | cameron | Syneto | à reporter ici | | N/A | N/A | Baie de stockage des homes et des mails des adhérents |
 | sam | HP ProLiant DL360 G8 | à reporter ici | | N/A | N/A | Virtualiseur |
--- a/infrastructure/machines/physiques/sfp.md
+++ b/infrastructure/machines/physiques/sfp.md
@ -0,0 +1,38 @@
 # Optiques SFP(+) et fibres optiques
 Le Crans dispose d'un backbone 10G pour relier ses serveurs, les modules
 optiques utilisés sont des [10GBASE-SR compatibles
 Arista](https://www.fs.com/fr/products/36982.html) (afin d'être compatibles
 avec nos switches Arista). Ces modules sont reliés par des [jarretières
 optiques LC LC OM4](https://www.fs.com/fr/products/40220.html).
 Pour son interconnexion avec ViaRézo et Aurore le Crans utilise des modules
 optiques [10GBASE-LR](https://www.fs.com/fr/products/36983.html) reliés aux
 platines de fibres par des [jarretières optiques LC SC
 OS2](https://www.fs.com/fr/products/96102.html).
 ## Qu'est-ce qu'est une optique SFP ?
 C'est un module actif composé d'un micro-contrôlleur (par exemple un STM32
 Cortex-M3) et d'un ou plusieurs lasers. Il permet de relier une fibre optique
 à un switch.
 ### Codage des optiques
 Une optique est codé avec un identifiant constructeur, changeable avec une
 codeuse. Un switch d'un certain constructeur n'acceptera que certains codes.
 Par exemple sur des Quanta, coder correctement les optiques permet de collecter
 des métriques tel que leur température. Sur certains switchs il est possible
 d'activer le support des optiques avec le mauvais code.
 ## Choses à ne pas faire
 Il peut être tentant d'acheter une optique 10km pour une liaison de 100m en
 partant sur l'idée que « qui peut le plus, peut le moins ». Dans le cas de
 l'optique c'est faux. Utiliser une optique trop puissante sur une distance
 beaucoup plus petite que son design va brûler le récepteur.
 Une optique chauffe et un laser qui chauffe dérive légèrement. Malgré qu'il
 y ait des plaques à effet Peltier dans certaines optiques pour compenser, il
 reste une bonne idée de vérifier que les optiques sont correctement
 refroidites par le switch.
--- a/infrastructure/machines/physiques/thot.md
+++ b/infrastructure/machines/physiques/thot.md
@ -1,13 +1,14 @@
 # Thot
 Ce document détaille la procédure d'installation qui a été suivi pour installer
-thot. Elle n'a probablement pas sa place ici, je la déplacerais le moment venue.
+thot.
 ## Installation initiale de debian
 On utilise normalement l'installateur de debian en utilisant le partitonnement
 suivant :
-```
+```txt
                              +---------------------------+ +--------------------------+
 +-----------+---------------+ | +-----------------------+ | | +----------------------+ |
 | /dev/sda1 |   /dev/sda2   | | |       /dev/sda3       | | | |       /dev/sda4      | |
@ -38,51 +39,67 @@ suivant :
 Et on finit en installant GRUB sur /dev/sda.
 ## Dropbear
 On va maintenant installer un petit serveur ssh dans le initramfs pour qu'au
 boot du serveur on puisse se ssh et déchiffrer les disques.
 ```bash
 sudo apt install dropbear-initramfs
 ```
 On edite ensuite les options du logiciel dans
-`/etc/dropbear-initramfs/config` pour lui préciser des options de lancement:
+`/etc/dropbear-initramfs/config` pour lui préciser des options de lancement :
 ```bash
 DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s"
 ```
-L'option importante qu'on set ici est `-p 2222` qui dit au serveur ssh d'écouter 
+
-sur le port 2222 plutôt que 22. On fait ça pour qu'un client ssh ne croit pas 
+L'option importante qu'on set ici est `-p 2222` qui dit au serveur ssh
-que l'host ait changé entre l'état au boot et l'état courant.
+d'écouter sur le port 2222 plutôt que 22. On fait ça pour qu'un client ssh ne
 croit pas que l'host ait changé entre l'état au boot et l'état courant.
 En plus de ça on va fournir au serveur une clé ssh publique via laquelle on
 pourra se connecter. Pour générer une clé ssh (`ssh-keygen(1)`) on fait
-```
+
 ```bash
 ssh-keygen -t ed25519 -f <keyname>
 ```
 Puis on copie la clé publique de `<keyname>.pub` dans
 `/etc/dropbear-initramfs/authorized_keys`.
 ### Configuration réseau
 On va aussi configurer le initramfs pour configurer ses interfaces réseaux au
 boot. On édite le fichier `/etc/initramfs-tools/initramfs.conf` et on rajoute
-une variable `IP` à la fin du fichier:
+une variable `IP` à la fin du fichier :
-  - Pour qu'il prenne une ip statique
+
 * Pour qu'il prenne une ip statique
  ```bash
  IP=<ip>::<gateway>:<netmask>:<hostname>:<interface>
  ```
-  - Pour qu'il prenne une ip via dhcp
+
 * Pour qu'il prenne une ip via dhcp
  ```bash
  IP=::::<hostname>:<interface>:dhcp
  ```
 Ensuite, on régénère le initramfs
-```
+
 ```bash
 initramfs -u
 ```
-Pour tester que ça fonctionne, on reboot et après le chargement du initramfs, on 
+Pour tester que ça fonctionne, on reboot et après le chargement du initramfs,
-fait un `ssh -i <keyname> -p <ip>` suivi d'un `cryptroot-unlock` qui devrait 
+on fait un `ssh -i <keyname> -p <ip>` suivi d'un `cryptroot-unlock` qui
-vous demander la passphrase pour déchiffrer le disque.
+devrait vous demander la passphrase pour déchiffrer le disque.
 ## Installation de proxmox
-https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye
+
 <https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye>
 ## Installation de zfs
-https://timor.site/2021/11/creating-fully-encrypted-zfs-pool/
+
 <https://timor.site/2021/11/creating-fully-encrypted-zfs-pool/>
--- a/infrastructure/machines/qui_est_qui.md
+++ b/infrastructure/machines/qui_est_qui.md
@ -1,28 +1,37 @@
 # Who's who
-Bon, on aime bien choisir des noms rigolos pour les vms, mais parfois ça amène à
+Bon, on aime bien choisir des noms rigolos pour les vms, mais parfois ça
-un peu de confusion. Du coup, on va répertorier ici les différentes machines
+amène à un peu de confusion. Du coup, on va répertorier ici les différentes
-(virtuelles ou non) et leurs différentes fonctions. Si une machine n'est pas
+machines (virtuelles ou non) et leurs différentes fonctions. Si une machine
-renseigné, n'hésitez pas à aller jeter un coup d'œil sur ansible ou à raller sur
+n'est pas renseigné, n'hésitez pas à aller jeter un coup d'œil sur ansible
-#roots :)
+ou à raller sur #roots :)
 ## Zamok
-C'est le serveur physique des adhérent⋅es. Il sert principalement à deux choses,
+
-donner un terminal aux adhérents et destination finale des mails. C'est aussi
+C'est le serveur physique des adhérent⋅es. Il sert principalement à deux
-lui qui hébèrge les pages personnelles des adhérent⋅es. Le [webirc
+choses, donner un terminal aux adhérents et destination finale des mails.
-persistent](https://webirc.crans.org) y est aussi hébergé.
+C'est aussi lui qui hébèrge les pages personnelles des adhérent⋅es. Le
 [webirc persistent](https://webirc.crans.org) y est aussi hébergé.
 Liste des logiciels installés :
-  - postfix + opendkim + rspamd
+
-  - apache (bouh)
+* postfix + opendkim + rspamd
-  - webirc
+
 * apache (bouh)
 * webirc
 Redémarrage et mise à jour :
-  - pas de redémarrage automatique
+
-  - mise à jour manuelle de linux et nftables
+* pas de redémarrage automatique
-  - éviter de redémarrer car les adhérent⋅es peuvent avoir des scripts qui tournent
+
 * mise à jour manuelle de linux et nftables
 * éviter de redémarrer car les adhérent⋅es peuvent avoir des scripts qui
  tournent
 ## Tealc
 C'est le serveur qui hébèrge les disques de nos vms. C'est un gros machins
 pleins de disques qui utilise zfs pour exposer une pool en nfs sur le réseau
 pour qu'elle soit montée par le cluster proxmox. Il héberge aussi un serveur
@ -31,143 +40,194 @@ crans. C'est aussi lui qui héberge les homes des nounous et le mirroir des
 logiciels.
 Liste de logiciels installés :
-  - zfs
+
-  - postgres
+* zfs
-  - nginx
+
 * postgres
 * nginx
 Redémarrage et mise à jour :
-  - pas de redémarrage automatique
+
-  - mise à jour manuelle de postgresql
+* pas de redémarrage automatique
-  - éviter de redémarrer car tous les services perdent leur disques
+
 * mise à jour manuelle de postgresql
 * éviter de redémarrer car tous les services perdent leur disques
 ## Cameron
-C'est le serveur qui héberge les homes des adhérent⋅es et leurs répertoires
+
-mails. C'est aussi depuis lui que sont effectués les backups quotidiennes des
+C'est le serveur qui héberge les homes des adhérent⋅es et leurs
-données des adhérent⋅es. Une de ses pools sert à stocker et à exposer sur le
+répertoires mails. C'est aussi depuis lui que sont effectués les backups
-réseau les disques des vms des adhérent⋅es pour qu'elles soit montées sur le
+quotidiennes des données des adhérent⋅es. Une de ses pools sert à stocker
-cluster proxmox des adhérent⋅es.
+et à exposer sur le réseau les disques des vms des adhérent⋅es pour
 qu'elles soit montées sur le cluster proxmox des adhérent⋅es.
 Liste de logiciels installés :
-  - zfs
+
 * zfs
 Redémarrage et mise à jour :
-  - pas de redémarrage automatique
+
-  - éviter de redémarrer car tous les adhérents perdent leur disques
+* pas de redémarrage automatique
 * éviter de redémarrer car tous les adhérents perdent leur disques
 ## Sam, Daniel, Jack : le cluster proxmox du crans
 Les trois serveurs sont organisés en un cluster proxmox pour hébergé les
 machines virtuelles du crans. Ils hébergent en sus une copie en lecture seule
 des bases de données et un replicat du serveur ldap.
 Liste de logiciels installés :
-  - proxmox
+
-  - postgres
+* proxmox
-  - slapd
+
 * postgres
 * slapd
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - migrer les VM avant de redémarrer
+* pas de redémarrage automatique
 * migrer les VM avant de redémarrer
 ### wall-e : le serveur ldap
 C'est le serveur qui hébèrge le ldap d'administration. Sur celui-ci sont
-consignés toutes nos machines, les utilisateurices qui ont accès au réseau et
+consignés toutes nos machines, les utilisateurices qui ont accès au réseau
-les privilèges dont iel dispose sur celui-ci, la configuration des zones dns.
+et les privilèges dont iel dispose sur celui-ci, la configuration des zones
 dns.
 Liste de logiciels installés :
-  - slapd
+
 * slapd
 Redémarrage et mise à jour automatique
 ### routeur-{sam,daniel,jack} : les routeurs
-Les routeurs sont responsables de connecter le reste du crans au reste du monde.
+
-Chacun d'entre eux est équipé pour pouvoir effectuer cette tache seule. À tout
+Les routeurs sont responsables de connecter le reste du crans au reste du
-instant un seul d'entre eux s'occupe du routage et les autres attendent. Si un
+monde. Chacun d'entre eux est équipé pour pouvoir effectuer cette tache
-problème devait arriver au routeur actif, l'un des deux prendraient le relai via
+seule. À tout instant un seul d'entre eux s'occupe du routage et les autres
-keepalived. Chacun des routeurs disposent d'une copie du parefeu généré par un
+attendent. Si un problème devait arriver au routeur actif, l'un des deux
-script, d'un serveur radvd pour broadcast des router advertisement sur le
+prendraient le relai via keepalived. Chacun des routeurs disposent d'une copie
-réseau des adhérent⋅es, d'un serveur dhcp pour aider les machines des
+du parefeu généré par un script, d'un serveur radvd pour broadcast des
-adhérent⋅es à configurer leur ipv4 et d'un serveur bird pour échanger des routes
+router advertisement sur le réseau des adhérent⋅es, d'un serveur dhcp pour
-avec nos isps (aurore et via).
+aider les machines des adhérent⋅es à configurer leur ipv4 et d'un serveur
 bird pour échanger des routes avec nos isps (aurore et via).
 Liste de logiciels installés :
-  - nftables
+
-  - isc-dhcp-server
+* nftables
-  - radvd
+
-  - bird
+* isc-dhcp-server
-  - keepalived
+
 * radvd
 * bird
 * keepalived
 Redémarrage et mise à jour :
-  - pas de redémarrage automatique
+
-  - mise à jour manuelle de linux et nftables
+* pas de redémarrage automatique
-  - ne pas redémarrer plusieurs en même temps et faire attention avac routeur-sam car c'est notre routeur principal (un peu de downtime si on ne change pas les routes avant)
+
 * mise à jour manuelle de linux et nftables
 * ne pas redémarrer plusieurs en même temps et faire attention avec
  routeur-sam car c'est notre routeur principal (un peu de downtime si on ne
  change pas les routes avant)
 ### routeur-2754 : le routeur pour l'ENS
 Ce routeur est responsable de connecter le Crans au VLAN 2754 de l'ENS.
 Redémarrage et mise à jour :
-  - pas de redémarrage automatique
+
-  - mise à jour manuelle de linux et nftables
+* pas de redémarrage automatique
-  - redémarrage manuel possible (surtout tant qu'il sert à rien)
+
 * mise à jour manuelle de linux et nftables
 * redémarrage manuel possible (surtout tant qu'il sert à rien)
 ### eclat : le mirroir publique
 C'est la machine virtuelle qui synchronise les mirroirs de logiciels et les
-expose au reste d'internet pour que les adhérent⋅es puissent télécharger les
+expose au reste d'internet pour que les adhérent⋅es puissent télécharger
-logiciels. Le mirroir est hébergé sur tealc et c'est ce serveur que toutes nos
+les logiciels. Le mirroir est hébergé sur tealc et c'est ce serveur que
-machines viennent intérroger pour se mettre à jour. Seul les machines
+toutes nos machines viennent intérroger pour se mettre à jour. Seul les
-exterieures utilisent eclat.
+machines exterieures utilisent eclat.
 Liste de logiciels installés :
-  - rsyncd
+
-  - vsftpd
+* rsyncd
-  - nginx
+
-  - apt-mirror
+* vsftpd
 * nginx
 * apt-mirror
 Redémarrage et mise à jour automatique.
 ### gitzly : le serveur gitlab
 C'est le serveur gitlab du crans.
 Redémarrage et mise à jour :
-  - redémarrage automatique
+
-  - mise à jour manuelle de gitlab
+* redémarrage automatique
 * mise à jour manuelle de gitlab
 ### gitlab-ci : le serveur d'intégration continue
 C'est le serveur sur lesquels sont exectués les taches d'intégration continue
 grâce à docker (beurk).
 Redémarrage et mise à jour automatique.
 ### owncloud: le serveur owncloud
 C'est le serveur owncloud du crans.
 Redémarrage et mise à jour :
-  - redémarrage automatique
+
-  - mise à jour manuelle de owncloud
+* redémarrage automatique
 * mise à jour manuelle de owncloud
 ### roundcube : le (seul) webmail
-C'est le webmail sur lequel les adhérent⋅es peuvent consulter leur mails. C'est
+
-un logiciel php.
+C'est le webmail sur lequel les adhérent⋅es peuvent consulter leur mails.
 C'est un logiciel php.
 Redémarrage et mise à jour automatique.
 ### voyager : framadate & la meilleure vm
-C'est la machine virtuelle qui héberge framadate (un logiciel php), et une base
+
-de donnée mysql. Mais surtout c'est une vm qui a beaucoup servi de vms de tests
+C'est la machine virtuelle qui héberge framadate (un logiciel php), et une
-random, son état est donc chaotique et incertain.
+base de donnée mysql. Mais surtout c'est une vm qui a beaucoup servi de vms de
 tests random, son état est donc chaotique et incertain.
 Redémarrage et mise à jour automatique.
 ### kenobi: les pads
 C'est la machine virtuelle qui héberge les pads et les tmpads.
 Redémarrage et mise à jour automatique.
 ### ethercalc: les tableurs
 C'est la machine virtuelle qui héberge les tabeurs ethercalc.
 Redémarrage et mise à jour automatique.
 ### mailman : les listes de diffusion
 C'est la machine virtuelle qui héberge les listes de diffusion. On utilise
 mailman3, un logiciel django et la machine dispose aussi de son instance de
 postfix pour pouvoir envoyer et recevoir les mails.
@ -175,100 +235,124 @@ postfix pour pouvoir envoyer et recevoir les mails.
 Redémarrage et mise à jour automatique.
 ### belenios : la démocratie
-C'est la machine virtuelle qui héberge le logiciel éponyme qui sert à organiser
+
-des éléctions sécurisées. C'est un logiciel en ocaml, use with care or with L3
+C'est la machine virtuelle qui héberge le logiciel éponyme qui sert à
-info.
+organiser des éléctions sécurisées. C'est un logiciel en ocaml, use with
 care or with L3 info.
 Redémarrage et mise à jour automatique.
 ### apprentis : la machine virtuelle des apprenti⋅es
 Play ground pour que les apprenti⋅es puissent s'amuser à faire ce qu'iels
-veulent. À priori rien est installé dessus mais tout peut-être installé dessus.
+veulent. À priori rien est installé dessus mais tout peut-être installé
 dessus.
 Redémarrage et mise à jour automatique.
 ### ptf : la mémoire (fatiguée)
 C'est le serveur ftp sur lequel est hebergé les vidéos des installs party du
-crans. Il dispose d'un serveur vsftpd et d'un serveur nginx. Il est peu utilisé.
+crans. Il dispose d'un serveur vsftpd et d'un serveur nginx. Il est peu
 utilisé.
 Redémarrage et mise à jour automatique.
 ### flirt : le ldap des machines des adhérent⋅es
 C'est la machine virtuelle qui héberge le ldap sur lequel sont consignés les
 machines virtuelles des adhérent⋅es et des clubs. Elle dispose d'un serveur
-slapd. On a l'ambition de rassembler les deux ldap des adhérent⋅es un jour mais
+slapd. On a l'ambition de rassembler les deux ldap des adhérent⋅es un jour
-ça risque de pas convergé (c.f. constellation).
+mais ça risque de pas convergé (c.f. constellation).
 Redémarrage et mise à jour automatique.
 ### neree : galene
 C'est le serveur galene du crans, l'un des deux logiciels qu'on utilise pour
 faire de la visio conférence.
 Redémarrage et mise à jour automatique.
-### jitsi: 
+### jitsi : visio-conférence
-C'est le serveur jitsi du crans, l'autre logiciel qu'on utilise pour faire
+
-de la visio conférence.
+C'est le serveur jitsi du crans, l'autre logiciel qu'on utilise pour faire de
 la visio conférence.
 Redémarrage et mise à jour automatique.
 ### ferle : anchor ripe
 C'est la machine virtuelle qu'on met à disposition du ripe pour être des bons
 élèves. On a donc pas accès à la machine.
 ### boeing : pont wireguard
 C'est la machine qui héberge la plupart des ponts wireguard qu'on a vers
 l'exterieur (sputnik, thot, ft).
 Redémarrage et mise à jour automatique.
 ### fluxx : à bruler
 Redémarrage et mise à jour automatique.
 ### linx : serveur d'hébergement de fichier
 C'est la machine virtuelle qui héberge le logiciel éponyme.
 Redémarrage et mise à jour automatique.
 ### cas : cas
 C'est le cas. (django-cas)
 Redémarrage et mise à jour automatique.
 ### fyre : monitoring
 C'est la machine virtuelle qui monitore l'état de l'infrastructure. Il utilise
 la suite de logiciels prometheus, grafana et ninjaaa(bot).
 Redémarrage et mise à jour automatique.
 ### ecilis : dns de test
 C'est une machine virtuelle qui fait partie de l'infrastructure de test et qui
 héberge un dns authoritaire (knot).
 Redémarrage et mise à jour automatique.
 ### trinity : pont matrix
 C'est le pont matrix qui permet aux utilisateurices de matrix de participer aux
 discutions sur irc.
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - le redémarrage déconnecte les utilisateurices
+* pas de redémarrage automatique
 * le redémarrage déconnecte les utilisateurices
 ### irc: le serveur irc
 C'est le serveur irc du crans.
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - le redémarrage déconnecte les utilisateurices
+* pas de redémarrage automatique
 * le redémarrage déconnecte les utilisateurices
 ### kiwi: le wiki
-C'est le wiki du crans qui tourne avec moinmoin2 (c'est du python2 donc il faut pas mettre à jour debian qui va drop python2).
+
 C'est le wiki du crans qui tourne avec moinmoin2 (c'est du python2 donc il faut
 pas mettre à jour debian qui va drop python2).
 Redémarrage et mise à jour automatique.
 ### redisdead : serveur mail principale
 C'est le serveur mail principale du crans, c'est sur lui que les mails arrivent
 et de lui que les mails partent. Ce n'est cependant pas la destination finale
 des mails qui sont redirigés vers zamok. C'est un serveur postfix, mais il y a
@ -277,122 +361,158 @@ aussi un serveur opendkim et policyd sur la machine.
 Redémarrage et mise à jour automatique.
 ### en7 : la connexion de secours
 L'ens nous a donné une ip de secours sur leur réseaux au cas où il y ait un
-problème sur les routeurs et qu'on ait besoin de se connecter sur le réseaux. Il
+problème sur les routeurs et qu'on ait besoin de se connecter sur le réseaux.
-est projetté d'y hébergé un serveur dns et un serveur mail.
+Il est projetté d'y hébergé un serveur dns et un serveur mail.
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - redémarrage manuel possible (sauf en période de crise et faire attention si c'est votre point d'entrée adm)
+* pas de redémarrage automatique
 * redémarrage manuel possible (sauf en période de crise et faire attention si
  c'est votre point d'entrée adm)
 ### owl : serveur pop3/imap
 C'est le serveur qui expose aux adhérentes leur email en imap ou en pop3.
 Redémarrage et mise à jour automatique.
 ### re2o: la gestion des adhérent⋅es
 C'est l'intranet du Crans.
 Redémarrage et mise à jour automatique.
 ### yson-partout: le ldap des adhérent⋅es
 C'est le ldap qui liste les comptes des adhérent⋅es depuis re2o.
 Redémarrage et mise à jour automatique.
 ### helloworld: le serveur d'impression
 C'est le serveur qui heberge le service web pour l'impression
 Redémarrage et mise à jour automatique.
 ### listenup: ???
 J'ai aucune idée de l'utilité de cette VM.
 Redémarrage :
  - pas de redémarrage automatique
-### netns:
+* pas de redémarrage automatique
 ### netns
 Redémarrage et mise à jour automatique.
-### proxy-pve-adh:
+### proxy-pve-adh
 Comme son nom l'indique...
 Redémarrage et mise à jour automatique.
 ### romanesco: le dns récursif
 C'est le serveur DNS récursif du Crans.
 Liste de logiciels installés :
-  - unbound
+
 * unbound
 Redémarrage et mise à jour automatique.
 ### silice: le dns
 C'est le serveur DNS du Crans.
 Liste de logiciels installés :
-  - bind
+
 * bind
 Redémarrage et mise à jour automatique.
 ## Hodaur : le serverse proxy
 C'est le reverse proxy.
 Liste de logiciels installés :
- - nginx
+
 * nginx
 Redémarrage et mise à jour automatique.
-### … (les serveur avec "-dev" dans le nom ou un nom très proche d'un serveur de la liste sont des serveurs de test qui ont plus ou moins la même conf que le serveur copié)
+### ...-dev
 Les serveur avec "-dev" dans le nom ou un nom très proche d'un serveurs de la
 liste sont des serveurs de test qui ont plus ou moins la même conf que le
 serveur copié).
 ## Gulp, Odlyd, Stitch : le cluster proxmox des adhérent⋅es
 Les trois serveurs sont organisés en un cluster proxmox pour hébergé les
 machines virtuelles des adhérent⋅es.
 Liste de logiciels installés :
-  - proxmox
+
 * proxmox
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - migrer les VM avant de redémarrer
+* pas de redémarrage automatique
 * migrer les VM avant de redémarrer
 ## Thot, Ft : les serveurs de backups
 Ces deux serveurs ne sont pas dans la baie mais à des endroits distincts pour
-éviter qu'un accident dans la salle serveur détruise toutes les données. Thot
+éviter qu'un accident dans la salle serveur détruise toutes les données.
-est chez via et ft chez auro.re (une chance sur deux que je me sois trompée et
+Thot est chez via et ft chez auro.re (une chance sur deux que je me sois
-que c'est l'inverse). Ce sont des serveurs proxmox, donc peu de choses tournent
+trompée et que c'est l'inverse). Ce sont des serveurs proxmox, donc peu de
-sur les machines. On décrit dans les sections qui suiventt les vms qui sont
+choses tournent sur les machines. On décrit dans les sections qui suivent les
-hébergés sur ces serveurs.
+vms qui sont hébergés sur ces serveurs.
 Liste de logiciels installés :
-  - proxmox
+
 * proxmox
 Redémarrage :
-  - pas de redémarrage automatique
+
-  - redémarrage manuel possible (éviter si l'autre serveur de backup à des problèmes car on a pas aacès directement aux machines en cas de problème)
+* pas de redémarrage automatique
 * redémarrage manuel possible (éviter si l'autre serveur de backup à des
  problèmes car on a pas aacès directement aux machines en cas de problème)
 ## routeur-{ft,thot} : les routeurs
 Ces deux machines virtuelles servent à connecter leur hyperviseur et les
 machines virtuelles qu'il héberge au reste du réseau d'administration via un
 tunnel wireguard dont l'autre pair est boeing.
 Liste de logiciels installés :
-  - wireguard
+
 * wireguard
 Redémarrage et mise à jour automatique.
 ## backup-{ft,thot} : les serveurs de backup
 C'est sur ces machines virtuelles que sont effectivement faites les backups via
 borgmatic.
 Liste de logiciels installés :
-  - borgmatic
+
 * borgmatic
 Redémarrage et mise à jour automatique.
 ## Zbee : un serveur physique
 Un serveur physique qui sert pas.
 Redémarrage :
-  - pas de redémarrage automatique
+
 * pas de redémarrage automatique
--- a/infrastructure/reseaux/plan.md
+++ b/infrastructure/reseaux/plan.md
--- a/infrastructure/services/README.md
+++ b/infrastructure/services/README.md
@ -0,0 +1,11 @@
 # Services
 ## Présentation
 Ce dossier contient la documentation des différents services à utilisation
 interne. La  documentation des services à disposition des utilisateurices est
 disponible  dans [ce dossier](../../services).
 ## Organisation
 TODO
--- a/infrastructure/services/ldap-adh.md
+++ b/infrastructure/services/ldap-adh.md
@ -0,0 +1,114 @@
 # LDAP Adhérents
 Le Crans dispose d'une base de données stockant les machines des adhérents
 disposant d'une connexion active et accessible vie le protocole LDAP.
 ## Connexion
 Le serveur LDAP est hébergé sur la machine `flirt` et est accessible sur le
 port 389. Pour s'y connecter, on peut faire une redirection de ports comme par
 exemple :
 ```bash
 ssh -L 1636:172.16.10.114:636 tealc.adm.crans.org -J zamok.adm.crans.org
 ```
 Le plus simple est d'utiliser `shelldap`, permettant de naviguer simplement à
 travers la base (voir [la documentation sur le LDAP admin](ldap.md)).
 ## Schéma
 Voici la hiérarchie actuelle du LDAP (mars 2023) :
 ```txt
 dc=adh,dc=crans,dc=org
 |
 +-cn=admin
 |
 +-cn=membership
 |
 +-cn=reader
 |
 +-ou=users
 | +-cn=user (inetOrgPerson)
 |
 +-ou=clubs
 | +-o=club (organization)
 |
 +-ou=hosts
 | +-cn=machine (device, ipHost, ieee802Device)
 |
 +-ou=networks
  +-ipNetworkNumber=<IPv6> (ipNetwork, ipHost)
 ```
 ## Utilisateurs
 Les adhérents sont ajoutés dans `ou=users` et ont les attributs suivants :
 * `cn`: le pseudo de l'adhérent
 * `givenName`: le prénom de l'adhérent
 * `sn`: le nom de famille de l'adhérent
 * `mail`: l'adresse email de l'adhérent
 * `postalAddress`: l'adresse postale de l'adhérent (au format 1 Rue Machin,
  75000 Ville)
 * `telephoneNumber`: le numéro de téléphone de l'adhérent
 L'attribut `description` est utilisé afin de stocker des informations
 supplémentaires:
 * `birthDate`: la date de naissance de l'adhérent au format `YYYY-MM-DD`
 * `birthLocation`: la ville de naissance de l'adhérent
 * `membershipStart`: la date de la première adhésion de l'adhérent au
  format `YYYY-MM-DD`
 * `membershipEnd`: la date de fin de l'adhésion de l'adhérent au format
  `YYYY-MM-DD`
 * `re2oId`: l'identifiant d'utilisateur de l'adhérent dans l'intranet
 ## Clubs
 Les clubs sont ajoutés dans `ou=clubs` et ont les attributs suivants :
 * `o`: le nom du club
 * `description`: le pseudo de l'adhérent responsable du club
 ## Machines
 Les machines sont ajoutées dans `ou=hosts` et ont les attributs suivants :
 * `cn`: le nom de la machine
 * `ipHostNumber`: les addresses IP de la machine
 * `macAddress`: l'adresse MAC de la machine
 * `description`: l'ouverture de ports de la machine
 * `owner`: le dn du propriétaire de la machine (utilisateur ou club)
 ## Réseaux
 Les sous-réseaux adhérents sont ajoutés dans `ou=networks` et ont les
 attributs suivants :
 * `dn`: le nom du sous-réseau
 * `cn`: le pseudo de l'adhérent propriétaire du sous-réseau
 * `description` (optionnel) : deux NSRecord et un DSRecord du sous-réseau
 * `ipHostNumber`: IPv6 interface avec le sous-réseau
 * `ipNetMaskNumber`: masque de sous-réseau
 * `ipNetworkNumber`: première IPv6 du sous-réseau
--- a/infrastructure/services/ldap.md
+++ b/infrastructure/services/ldap.md
@ -1,18 +1,24 @@
 # LDAP
-Le Crans dispose d'une base de donnée avec laquelle on peut communiquer via le protocole LDAP (que nous appellerons par la suite base LDAP ou simplement LDAP) stockant l'ensemble de ses administrateurs, groupes, serveurs, réseaux et services.
+Le Crans dispose d'une base de donnée avec laquelle on peut communiquer via le
 protocole LDAP (que nous appellerons par la suite base LDAP ou simplement LDAP)
 stockant l'ensemble de ses administrateurs, groupes, serveurs, réseaux et
 services.
-La serveur LDAP se trouve sur tealc et est répliqué sur les virtualiseurs ainsi que sur sputnik et gulp.
+La serveur LDAP se trouve sur tealc et est répliqué sur les virtualiseurs
 ainsi que sur sputnik et gulp.
 ## Connexion
-Le LDAP écoute uniquement sur son interface `adm` en LDAPS et en local sur `flirt`. Pour s'y connecter, le plus simple est de se connecter en ssh sur `flirt`, puis d'utiliser `shelldap` (voir ci-dessous). 
+Le LDAP écoute uniquement sur son interface `adm` en LDAPS et en local sur
 `flirt`. Pour s'y connecter, le plus simple est de se connecter en ssh sur
 `flirt`, puis d'utiliser `shelldap` (voir ci-dessous).
 ## Schéma
 Voici la hiérarchie actuelle du LDAP (mars 2023) :
-```
+```txt
 dc=crans,dc=org
 +-ou=dns
 | +-dc=eu (dNSDomain, domain)
@ -39,17 +45,27 @@ dc=crans,dc=org
 ### DNS
-Les enregistrements DNS sont ajoutés dans `ou=dns`, il y a actuellement trois groupes : `eu`, `fr` et `org` contenant chacun le groupe `crans`, correspondant respectivement à `crans.eu`, `crans.fr` et `crans.org`. L'enregistrement DNS de `subdomain.crans.org` sera modifiable dans un attribut `description` de l'entrée `dc=crans,dc=org,ou=dns,dc=crans,dc=org` ou dans une entrée `dc=subdomain,dc=crans,dc=org,ou=dns,dc=crans,dc=org` selon le besoin. 
+Les enregistrements DNS sont ajoutés dans `ou=dns`, il y a actuellement trois
 groupes : `eu`, `fr` et `org` contenant chacun le groupe `crans`, correspondant
 respectivement à `crans.eu`, `crans.fr` et `crans.org`. L'enregistrement DNS
 de `subdomain.crans.org` sera modifiable dans un attribut `description` de
 l'entrée `dc=crans,dc=org,ou=dns,dc=crans,dc=org` ou dans une entrée
 `dc=subdomain,dc=crans,dc=org,ou=dns,dc=crans,dc=org` selon le besoin.
 ### Groupes
 Les groupes sont ajoutés dans `ou=group`, il y a actuellement deux groupes :
- * `_user`: qui contient tout le monde
+
- * `_nounou`: qui contient les nounous et permet de `sudo` sur les serveurs
+* `_user`: qui contient tout le monde ;
 * `_nounou`: qui contient les nounous et permet de `sudo` sur les serveurs.
 ### Machines
-Les machines sont ajoutées dans `ou=hosts` et sont de classe `device`. Les interfaces sont regroupées sous les machines et sont de classes `device`, `ipHost` (ce qui permet de leur ajouter une IP) et `ieee802Device` (qui permet de leur ajouter un attribut `macAddress`)
+Les machines sont ajoutées dans `ou=hosts` et sont de classe `device`. Les
 interfaces sont regroupées sous les machines et sont de classes `device`,
 `ipHost` (ce qui permet de leur ajouter une IP) et `ieee802Device` (qui permet
 de leur ajouter un attribut `macAddress`).
 ### Réseaux
@ -57,14 +73,17 @@ Les réseaux sont ajoutés dans `ou=networks` et sont de classe `ipNetwork`.
 ### Utilisateurs
-Les utilisateurs sont ajoutés dans `ou=passwd` et sont de classes `inetOrgPerson` et `posixAccount`.
+Les utilisateurs sont ajoutés dans `ou=passwd` et sont de classes
 `inetOrgPerson` et `posixAccount`.
 ### Services
-Les services (noms des protocoles TCP/UDP utilisés au Crans) sont ajoutés dans `ou=services` et sont de classe `ipService`.
+Les services (noms des protocoles TCP/UDP utilisés au Crans) sont ajoutés
 dans `ou=services` et sont de classe `ipService`.
 Voici un exemple de service :
-```
+
 ```txt
 dn: cn=ssh,ou=services,dc=crans,dc=org
 objectClass: ipService
 cn: ssh
@ -74,41 +93,58 @@ ipServiceProtocol: tcp
 ## Conventions
-La base LDAP suit un certain nombre de conventions qu'il faut respecter quand on ajoute une entrée.
+La base LDAP suit un certain nombre de conventions qu'il faut respecter quand
 on ajoute une entrée.
 ### Machines
 La description des machines indique le rôle de la machine.
-La description des interfaces sert à spécifier l'ouverture de ports sur celles-ci, par exemple :
+La description des interfaces sert à spécifier l'ouverture de ports sur
-```
+celles-ci, par exemple :
 ```txt
 description: in:service1,in:service2,out:service3
 ```
-Pour autoriser les `service1` et `service2` en entrée et le `service3` en sortie. Il ne faut pas mettre d'espace et bien préciser `in:` ou `out:` avant le nom du service qui doit exister dans `ou=services`.
+
 Pour autoriser les `service1` et `service2` en entrée et le `service3` en
 sortie. Il ne faut pas mettre d'espace et bien préciser `in:` ou `out:` avant
 le nom du service qui doit exister dans `ou=services`.
 ### Réseaux
-La description du réseau est le numéro du VLAN sur lequel ce réseau est présent.
+La description du réseau est le numéro du VLAN sur lequel ce réseau est
 présent.
 ### Utilisateurs
-Le nom d'utilisateur (`uid`) doit nécessairement commencer par un `_` (underscore), cette contrainte est forcée dans la configuration du serveur.
+Le nom d'utilisateur (`uid`) doit nécessairement commencer par un `_`
 (underscore), cette contrainte est forcée dans la configuration du serveur.
 ### Services
-Le champ description du service sert à spécifier une range de ports : on met alors le port de fin dans la description.
+Le champ description du service sert à spécifier une range de ports : on met
 alors le port de fin dans la description.
 ## Configuration
-Par défaut, la configuration de l'annuaire LDAP est dans la base LDAP elle-même. Mais on trouve ça peu pratique, et il est possible de la déplacer dans un fichier texte : `/etc/ldap/slapd.conf`. Pour cela, il suffit de supprimer `/etc/ldap/slapd.d` et de restart `sladp`.
+Par défaut, la configuration de l'annuaire LDAP est dans la base LDAP
 elle-même. Mais on trouve ça peu pratique, et il est possible de la déplacer
 dans un fichier texte : `/etc/ldap/slapd.conf`. Pour cela, il suffit de
 supprimer `/etc/ldap/slapd.d` et de restart `sladp`.
-Pour faire écouter uniquement en LDAPS sur adm, on a ajouté dans `/etc/default/slapd` :
+Pour faire écouter uniquement en LDAPS sur adm, on a ajouté dans
-```
+`/etc/default/slapd` :
 ```txt
 SLAPD_SERVICES="ldaps://172.16.10.1/ ldapi:///"
 ```
-Pour que les nounous puissent modifier les mots de passe des utilisateurs et que chacun puisse modifier son mot de passe, on ajoute la configuration suivante :
+Pour que les nounous puissent modifier les mots de passe des utilisateurs et
-```
+que chacun puisse modifier son mot de passe, on ajoute la configuration
 suivante :
 ```txt
 access to attrs=userPassword,shadowLastChange
        by anonymous auth
        by self write
@ -116,31 +152,37 @@ access to attrs=userPassword,shadowLastChange
        by * none
 ```
-Pour que tout le monde puisse modifier son shell, mail et numéro de téléphone et que les nounous puissent modifier ceux des autres
+Pour que tout le monde puisse modifier son shell, mail et numéro de
-```
+téléphone et que les nounous puissent modifier ceux des autres :
 ```txt
 access to attrs=loginShell,mail,telephoneNumber
        by self write
        by set="[cn=nounou,ou=group,dc=crans,dc=org]/memberUid & user/uid" write
        by * read
 ```
-Pour que les nounous puissent modifier tout le reste
+Pour que les nounous puissent modifier tout le reste :
-```
+
 ```txt
 access to *
        by set="[cn=nounou,ou=group,dc=crans,dc=org]/memberUid & user/uid" write
        by * read
 ```
-Le LDAPS a été configuré avec un certificat autosigné valable 1000 ans:
+Le LDAPS a été configuré avec un certificat autosigné valable 1000 ans :
-```
+
 ```txt
 TLSCertificateFile /etc/ldap/ldap.pem
 TLSCertificateKeyFile /etc/ldap/ldap.key
 ```
 ### Réplication
-Le LDAP est répliqué notamment sur les virtualiseurs et sur `sputnik` grâce à la configuration suivante :
+Le LDAP est répliqué notamment sur les virtualiseurs et sur `sputnik` grâce
-```
+à la configuration suivante :
 ```txt
 syncrepl
        rid=1
        provider=ldaps://172.16.10.1:636
@ -156,9 +198,14 @@ syncrepl
        retry="30 20 300 +"
        tls_reqcert=allow
 ```
 (les valeurs `rid`, et `credentials` sont à remplacer : `rid` doit être unique pour chaque serveur répliqué et `credentials` doit correspondre au mot de passe du `binddn`)
-Si jamais le LDAP ne se synchronise pas il faut lancer les commandes suivantes (en remplaçant la valeur de `rid` par celle du serveur répliqué) :
+(les valeurs `rid`, et `credentials` sont à remplacer : `rid` doit être
 unique pour chaque serveur répliqué et `credentials` doit correspondre au mot
 de passe du `binddn`).
 Si jamais le LDAP ne se synchronise pas il faut lancer les commandes suivantes
 (en remplaçant la valeur de `rid` par celle du serveur répliqué) :
 ```bash
 systemctl stop slapd
 slapd -c rid=1,csn=0
@ -167,16 +214,21 @@ systemctl start slapd
 ### Overlays
-Les overlays sont des modules pour slapd (le serveur LDAP) on utilise plusieurs overlays dans la base de données des membres actifs. Tout est spécifié dans `/etc/ldap/slapd.conf`.
+Les overlays sont des modules pour slapd (le serveur LDAP) on utilise plusieurs
 overlays dans la base de données des membres actifs. Tout est spécifié dans
 `/etc/ldap/slapd.conf`.
 #### auditlog
-Auditlog permet de logguer les modifications faites à la base LDAP dans un fichier LDIF.
+Auditlog permet de logguer les modifications faites à la base LDAP dans un
 fichier LDIF.
 #### constraint
-Constraint permet de restreindre certains atttributs à certaines valeurs, par exemple on force l'`uid` d'un membre actif à commencer par `_`.
+Constraint permet de restreindre certains atttributs à certaines valeurs, par
-```
+exemple on force l'`uid` d'un membre actif à commencer par `_`.
 ```txt
 constraint_attribute uid regex ^_
  restrict=ldap:///ou=passwd,dc=crans,dc=org??one?(objectClass=posixAccount)
 ```
@ -185,16 +237,19 @@ constraint_attribute uid regex ^_
 ### Curl
-C'est l'outil sans doute le plus basique pour faire des requêtes, et il supporte LDAP(S). Avec la redirection de ports définie plus haut:
+C'est l'outil sans doute le plus basique pour faire des requêtes, et il
-```
+supporte LDAP(S). Avec la redirection de ports définie plus haut :
 ```bash
 curl -k "ldaps://localhost:1636/ou=hosts,dc=crans,dc=org?cn?one?description=pve"
 ```
 me renvoie tous les virtus, ie pve1, pve2 et pve3.
-et
+me renvoie tous les virtus, ie pve1, pve2 et pve3. Et
-```
+
 ```bash
 curl -k "ldaps://localhost:1636/ou=hosts,dc=crans,dc=org?cn?one?description=radius"
 ```
 me renvoie tous les serveurs radius.
 ### Apache Directory Studio
@ -203,26 +258,40 @@ Plus d'info [ici](https://directory.apache.org/studio/).
 C'est un outil graphique pour naviguer dans un annuaire LDAP. Bien pratique !
-Pour le configurer il faut créer une nouvelle connexion (dans le menu en bas à gauche). Par exemple, pour utiliser le LDAP membres actifs du crans on peut utiliser :
+Pour le configurer il faut créer une nouvelle connexion (dans le menu en bas
 à gauche). Par exemple, pour utiliser le LDAP membres actifs du crans on peut
 utiliser :
 Dans le menu Network Parameter
- * Connection name : LDAP nounous
+
- * Hostname : localhost
+* Connection name : LDAP nounous
- * Port : 1636 (ou n'importe quel autre port).
+
- * Encryption method : Use SSL encryption (ldap://) 
+* Hostname : localhost
 * Port : 1636 (ou n'importe quel autre port).
 * Encryption method : Use SSL encryption (ldap://)
 et dans le menu Authentication
- * Authentication Method : Simple Authentication
+
- * Bind DN or user : votre DN, par exemple pour moi c'est `uid=_pollion,ou=passwd,dc=crans,dc=org`
+* Authentication Method : Simple Authentication
 * Bind DN or user : votre DN, par exemple pour moi c'est
  `uid=_pollion,ou=passwd,dc=crans,dc=org`
 Et renseignez votre mot de passe sur le LDAP Membres actifs.
-Avec cette configuration, il suffit de faire une redirection du port 636 distant vers localhost 1636 et à vous la navigation sur le LDAP !
+Avec cette configuration, il suffit de faire une redirection du port 636
 distant vers localhost 1636 et à vous la navigation sur le LDAP !
 ### Shelldap
-Pour naviguer dans la base, on peut aussi utiliser un utilitaire en ligne de commande : shelldap qui permet de se déplacer à coup de `ls`, `cd` et `cat`. shelldap est installé sur `tealc`, mais non configuré. En ajoutant la configuration dans le fichier `.shelldap.rc` :
+Pour naviguer dans la base, on peut aussi utiliser un utilitaire en ligne de
-```
+commande : shelldap qui permet de se déplacer à coup de `ls`, `cd` et `cat`.
 shelldap est installé sur `tealc`, mais non configuré. En ajoutant la
 configuration dans le fichier `.shelldap.rc` :
 ```txt
 server: ldaps://172.16.10.1:636
 binddn: uid=<_pseudo>,ou=passwd,dc=crans,dc=org
 basedn: dc=crans,dc=org
@ -232,9 +301,11 @@ tls_cacert: /etc/ldap/ldap.pem
 ```
 Et on peut ensuite se connecter au LDAP :
-```
+
 ```txt
 _shirenn@tealc $ shelldap
-Bind password: coucoupollion // Ce mot de passe est le mot de passe du compte <_pseudo>, et non l'un de ceux dans le pass crans.
+Bind password: coucoupollion // Ce mot de passe est le mot de passe du compte
 <_pseudo>, et non l'un de ceux dans le pass crans.
 ~ > ls
 cn=admin
 cn=replicator
--- a/infrastructure/sfp.md
+++ b/infrastructure/sfp.md
@ -1,22 +0,0 @@
 # Optiques SFP(+) et fibres optiques
 Le Crans dispose d'un backbone 10G pour relier ses serveurs, les modules optiques utilisés sont des [10GBASE-SR compatibles Arista](https://www.fs.com/fr/products/36982.html) (afin d'être compatibles avec nos switches Arista).
 Ces modules sont reliés par des [jarretières optiques LC LC OM4](https://www.fs.com/fr/products/40220.html).
 Pour son interconnexion avec ViaRézo et Aurore le Crans utilise des modules optiques [10GBASE-LR](https://www.fs.com/fr/products/36983.html) reliés aux platines de fibres par des [jarretières optiques LC SC OS2](https://www.fs.com/fr/products/96102.html).
 ## Qu'est-ce qu'est une optique SFP ?
 C'est un module actif composé d'un micro-contrôlleur (par exemple un STM32 Cortex-M3) et d'un ou plusieurs lasers.
 Il permet de relier une fibre optique à un switch.
 ### Codage des optiques
 Une optique est codé avec un identifiant constructeur, changeable avec une codeuse. Un switch d'un certain constructeur n'acceptera que certains codes. Par exemple sur des Quanta, coder correctement les optiques permet de collecter des métriques tel que leur température. Sur certains switchs il est possible d'activer le support des optiques avec le mauvais code.
 ## Choses à ne pas faire
 Il peut être tentant d'acheter une optique 10km pour une liaison de 100m en partant sur l'idée que « qui peut le plus, peut le moins ». Dans le cas de l'optique c'est faux. Utiliser une optique trop puissante sur une distance beaucoup plus petite que son design va brûler le récepteur.
 Une optique chauffe et un laser qui chauffe dérive légèrement. Malgré qu'il y ait des plaques à effet Peltier dans certaines optiques pour compenser, il reste une bonne idée de vérifier que les optiques sont correctement refroidites par le switch.
--- a/outils/README.md
+++ b/outils/README.md
@ -0,0 +1,40 @@
 # Outils
 ## Présentation
 Ce dossier contient une présentation rapide de plusieurs outils logiciels,
 systèmes d'exploitation et protocoles utilisés par le Crans pour
 l'installation et la maintenance des serveurs et des services qui y sont
 associés.
 Le but n'est pas de réexpliquer l'entièreté des  fonctionnalités, mais
 simplement d'avoir une explication de ce que l'on parle  pour avoir des bases
 de compréhension.
 ## Organisation
 Chaque fichier de ce dossier contient une présentation, au moins succinte, de
 l'outil ou du protocole. On peut y mettre autant de détails que l'on juge
 nécessaire bien évidemment (il vaut mieux trop de documentation que pas
 assez), mais ce n'est pas non plus absolument vital. On s'assurera en plus que
 chaque fichier contient un lien vers de la documentation officielle (si elle
 existe) et/ou vers une explication relativement simple du fonctionnement.
 Si l'outil ou le protocole est assez complexe et qu'il n'existe pas de bonne
 documentation **simple** en ligne, il est alors vivement recommandé que les
 nounous/apprenti⋅es le comprenant bien écrivent une explication de son
 fonctionnement.
 Les fichiers sont nommés par l'acronyme de l'outil ou du protocole (car on les
 connait en général mieux que les noms complets).
 On retrouve les dossiers suivants :
 * [`logiciels`](logiciels) : contient la documentation des logiciels utilisés
  par le Crans.
 * [`protocoles`](protocoles) : contient la documentation des protocoles
  utilisés pas le Crans.
 * [`os`](os) : contient la documentation des systèmes d'exploitation
  utilisés par le Crans.
--- a/outils/logiciels/README.md
+++ b/outils/logiciels/README.md
@ -0,0 +1,15 @@
 # Logiciels
 ## Présentation
 Ce dossier contient une présentation de plusieurs outils logiciels utilisés
 par le Crans.
 Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais
 simplement d'avoir une explication de ce que l'on parle  pour avoir des bases
 de compréhension.
 ## Organisation
 L'organisation est la même que décrite dans [le fichier `README.md` du
 dossier parent](../README.md).
--- a/outils/logiciels/apt.md
+++ b/outils/logiciels/apt.md
@ -1,9 +1,11 @@
 # APT
-APT (pour Advanced Package Tool) est un des gestionnaires de paquets de [Debian](https://www.debian.org/). Il dispose d'une interface en CLI, voici quelques exemples de commandes :
+APT (pour Advanced Package Tool) est un des gestionnaires de paquets de
 [Debian](https://www.debian.org/). Il dispose d'une interface en CLI, voici
 quelques exemples de commandes :
 | commande | description |
-| - | - |
+|----------|-------------|
 | `apt install package` | Installe `package` |
 | `apt search package` | Recherche `package` |
 | `apt list` | Liste les paquets |
@ -17,15 +19,22 @@ APT (pour Advanced Package Tool) est un des gestionnaires de paquets de [Debian]
 | `apt update` | Met à jour les listes de paquets |
 | `apt upgrade` | Met à jour les paquets |
-Un paquet Debian va placer des fichiers dans `/bin/`, `/usr/` par exemple. Il faut donc avoir les droits administrateurs pour installer, mettre à jour ou supprimer un paquet. Il n'est pas possible d'installer un paquet APT pour seulement un utilisateur.
+Un paquet Debian va placer des fichiers dans `/bin/`, `/usr/` par exemple. Il
 faut donc avoir les droits administrateurs pour installer, mettre à jour ou
 supprimer un paquet. Il n'est pas possible d'installer un paquet APT pour
 seulement un utilisateur.
 ## Les sources de paquets
-APT est en réalité une interface au dessus de DPKG (Debian PacKaGe) qui va simplifier le téléchargement et l'installation de paquets en les synchronisant de sources de paquets.
+APT est en réalité une interface au dessus de DPKG (Debian PacKaGe) qui va
 simplifier le téléchargement et l'installation de paquets en les
 synchronisant de sources de paquets.
-Les sources de paquets sont définies dans `/etc/apt/source.list` et dans le dossier `/etc/apt/source.list.d/`. Un système Debian classique au Crans devrait avoir les sources suivantes :
+Les sources de paquets sont définies dans `/etc/apt/source.list` et dans le
 dossier `/etc/apt/source.list.d/`. Un système Debian classique au Crans
 devrait avoir les sources suivantes :
-```
+```txt
 # Paquets principaux de Debian Buster
 deb https://ftps.crans.org/debian buster main
@ -36,10 +45,17 @@ deb https://ftps.crans.org/debian buster-updates main
 deb https://ftps.crans.org/debian-security buster/updates main
 ```
-Si on souhaite également synchroniser la liste des sources de paquets pour potentiellement les reconstruire, on peut dupliquer chaque ligne en substituant `deb` par `deb-src`.
+Si on souhaite également synchroniser la liste des sources de paquets pour
 potentiellement les reconstruire, on peut dupliquer chaque ligne en substituant
 `deb` par `deb-src`.
 ## Vérifier l'état de santé des paquets systèmes Debian
-Debian fournit un outil nommé `debsums` (Debian Checksum) pour vérifier que les fichiers installés par les paquets Debian n'ont pas été altérés. Un fichier d'un paquet peut être altéré soit par un virus ou un administrateur chaotique qui écrase ses exécutables, soit quand il s'agit de changer sa configuration.
+Debian fournit un outil nommé `debsums` (Debian Checksum) pour vérifier que
 les fichiers installés par les paquets Debian n'ont pas été altérés. Un
 fichier d'un paquet peut être altéré soit par un virus ou un administrateur
 chaotique qui écrase ses exécutables, soit quand il s'agit de changer sa
 configuration.
-Pour lister rapidement la liste des fichiers de configuration changés : `debsums -ce`
+Pour lister rapidement la liste des fichiers de configuration changés :
 `debsums -ce`.
--- a/outils/logiciels/gpg.md
+++ b/outils/logiciels/gpg.md
@ -0,0 +1,44 @@
 # GPG
 GPG (GNU Privacy Guard) est une implémentation libre et open source du
 protocole OpenPGP (Pretty Good Privacy), un protocole cryptographique
 permettant de signer, chiffrer et déchiffrer des documents (notamment des
 emails).
 ## Clef
 Une clef GPG est une clé numérique qui permet d'être identifié de façon
 unique dans le monde numérique.
 Elle est composée de deux éléments :
 * une clé privée protégée par une phrase clé qui permet d'éviter à une
  tierce personne d'utiliser cette clef si elle parvient à la voler
 * une clé publique qui une fois distribuée et signée par son entourage,
  permet à celui-ci de vérifier que les messages que l'on signe le sont bien
  avec la clé privée associée à cette clé publique.
 Elle peut être générée à l'aide d'une des commandes suivantes (selon le
 nombre d'option que vous souhaitez avoir) :
 * `gpg --generate-key`
 * `gpg --full-generate-key`
 * `gpg --full-generate-key --expert`
 ## Web of trust
 Le web of trust (ou toile de confiance en français) permet d'établir
 l'authenticité de l'appartenance d'une clef publique ; il est décentralisé :
 il n'a donc pas besoin d'autorité de certification.
 Voici les règles par défaut du web of trust d'OpenPGP, on estime que la clef
 publique appartient au bon propriétaire si :
 * On a soi-même fait confiance à cette clef
 * Une personne en qui on a totalement confiance a signé cette clef
 * Trois personnes en qui on a partiellement confiance ont signé cette clef
--- a/outils/logiciels/ssh.md
+++ b/outils/logiciels/ssh.md
@ -0,0 +1,100 @@
 # SSH
 SSH (Secure Shell) est un protocole permettant d'exécuter des commandes sur un
 serveur distant. Il utilise le port 22 en TCP.
 Sa version 2 est spécifiée par les RFC
 [4250](https://datatracker.ietf.org/doc/html/4250),
 [4251](https://datatracker.ietf.org/doc/html/4251),
 [4252](https://datatracker.ietf.org/doc/html/4252),
 [4253](https://datatracker.ietf.org/doc/html/4253) et
 [4254](https://datatracker.ietf.org/doc/html/4254).
 ## OpenSSH
 Le client de prédilection pour utiliser SSH est le client de la suite OpenSSH
 (qui fourni également un serveur et d'autres utilitaires permettant de gérer
 les clefs cryptographiques), disponible dans le paquet Debian `openssh-client`.
 ## Clefs SSH
 Vous pouvez générer des clefs cryptographiques permettant de vous
 authentifier directement sur le serveur distant (plutôt que par mot de passe)
 avec l'utilitaire `ssh-keygen` ainsi :
 ```bash
 ssh-keygen -t ${TYPE} -b ${BITS}
 ```
 Où `TYPE` peut être :
 * `rsa`
 * `ecdsa` (dans ce cas `BITS` doit valoir 256, 384 ou 521)
 * `ed25519` (dans ce cas `BITS` doit valoir 256)
 `ssh-keygen` vous demande ensuite le chemin du fichier de clef ainsi que sa
 passphrase et génère une clef privée ainsi qu'une clef publique se terminant
 par `.pub`.
 Un autre utilitaire, `ssh-copy-id` permet de copier la clef sur le serveur
 distant par exemple :
 ```bash
 ssh-copy-id -i ~/.ssh/id_ed25519.pub login@zamok.crans.org
 ```
 Attention : il faut absolument garder la clef privée sur votre serveur et ne
 pas l'envoyer sur le serveur distant.
 ## Exemples
 À la première connexion `ssh` demande s'il faut faire confiance à la clef du
 serveur :
 ```bash
 benjamin@om ~ $ ssh gitlab.crans.org
 The authenticity of host 'gitlab.crans.org (185.230.79.14)' can't be
 established.
 ECDSA key fingerprint is SHA256:StU+25vCTTs+opjyjMZTLvl+gvR+ViQWUkE1jRENnkQ.
 Are you sure you want to continue connecting (yes/no/[fingerprint])?
 ```
 Il est de bon usage de confirmer l'authenticité de cette clef afin de ne pas
 être vulnérable aux attaque de type Man in the Middle. Pour celà il y a une
 solution : l'administrateur du serveur doit vous confirmer l'empreinte
 (fingerprint) de la clef par un moyen sécurisé. Voici une liste non
 exhaustive de moyens plus ou moins sécurisés :
 * Si vous êtes vous-même l'administrateur du serveur la commande `for key in
  /etc/ssh/ssh_host_*.pub; do ssh-keygen -lf ${key}; done` sur le serveur pour
  afficher les empreintes de vos clefs.
 * Se faire confirmer la clef oralement par l'administrateur.
 * Se faire confirmer la clef par un mail d'un administrateur de confiance
  signé GPG.
 * Utiliser des clefs stockées dans le [DNS](/tools/dns.md) et signées
  DNSSEC, ceci peut se faire en ajoutant l'option `-oVerifyHostKeyDNS=yes` à
  `ssh`.
 Une fois que vous vous êtes assuré de l'authenticité de la clef vous pouvez
 entrer `yes` dans le prompt ci-dessus.
 `ssh` vous demande ensuite votre mot de passe ou la passphrase de votre clef,
 entrez le et appuyez sur Entrée pour vous connecter, félicitations vous
 devriez avoir votre shell sur le serveur distant.
 ## Exemple de conf ssh
 Après avoir `ssh-copy-id` sa clef public comme précisé plus haut on peut
 définir une conf qui permet d'aller sur nimporte quel serveur depuis votre
 machine via un `ProxyJump`.
 ```txt
 Host *.adm.crans.org
    User _usernounou
    ProxyJump _usernounou@hodaur.crans.org
 ```
--- a/outils/logiciels/systemd.org
+++ b/outils/logiciels/systemd.org
--- a/outils/logiciels/zfs.md
+++ b/outils/logiciels/zfs.md
@ -0,0 +1,201 @@
 # ZFS
 ## ZFS c'est quoi ?
 ZFS est un système de fichier avec plein de features natives, notamment de la
 gestion de volume, du RAID (RAID-Z), des snapshots, etc.
 > ZFS a été ouvert sous licence
 > [CDDL](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License)
 > incompatible avec la GPL. Par conséquent, ZFS n'est pas supporté nativement
 > par le noyau Linux.
 ## Petit glossaire
 * RAID-Z#N: Le raid de ZFS. Le chiffre #N correspond au nombre de disques que
  l'on peut perdre (e.g. RAID-Z2 correspond à du RAID 6 classique).
 * Pool: Une *pool* de stockage est le bloc de base de ZFS. C'est un ensemble
  logique de données. Une pool ZFS est composée d'un ou plusieurs *vdev*.
 * Vdev: Un *vdev* (pour ''virtual device'') est un sous élément d'une pool.
  Un vdev peut contenir un ou plusieurs disques physiques. Dans le cas où
  plusieurs disques sont utilisés, les données sont étendues (*stripped*) sur
  tous les disques afin d'améliorer sa durée de vie.
 * Dataset: *Dataset* est le terme générique pour désigner un volume de
  fichiers ZFS. Chaque dataset a un nom unique de la forme *Pool/Dataset*. La
  racine de la pool est techniquement un dataset aussi. Les dataset sont
  organisés comme des dossiers classique, avec une arborescence, et les enfants
  héritent des propriétés des parents.
 ## Installation
 Il faut ajouter les dépots `contrib` de debian dans lesquels se trouvent les
 paquets installés ci-dessous.
 Pour installer le module noyau ZFS sous Debian et les outils d'administration :
 ```bash
 apt install linux-headers-amd64
 apt install zfs-dkms
 ```
 Il faut ensuite reboot pour loader le module zfs, puis :
 ```bash
 apt install zfsutils-linux
 ```
 Cela installe aussi `zfs-zed` un daemon permettant de monitorer les pool ZFS.
 Les headers du noyau doivent être installés à chaque mise à jour du noyau.
 ## Créer une pool ZFS
 La première étape de création d'un filesystem ZFS est la création d'une
 pool. Une pool contient des vdev qui eux même contiennent des disques, la
 commande suivante permet de créer une pool de nom «pool» et montée dans
 `/pool` avec un vdev en RAIDZ-3 :
 ```bash
 zpool create -f -m /pool pool raidz3 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03494499 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03563166 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03570970 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03575828 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03614378 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03626582 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03694920 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03704580 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03707506 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03731830 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734763 \
    ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734769
 ```
 Les identifiants de disques peuvent être récupérés dans `/dev/disks/by-id/`.
 L'état des pool peut-être consulté avec la commande :
 ```bash
 zpool status
 ```
 ## Créer un dataset
 Une fois la pool créée il est préférable de créer des datasets qui
 permettent une gestion plus fine de la pool. Pour cela on utilise la commande
 suivante qui créé un dataset du nom de «home» dans la pool «pool» :
 ```bash
 zfs create pool/home
 ```
 ## Partager un dataset en NFS
 ZFS permet de partager un dataset en NFS pour cela il faut installer le paquet
 `nfs-kernel-server` :
 ```bash
 apt install nfs-kernel-server
 ```
 Le dataset «home» de la pool «pool» peut ensuite être partager ainsi :
 ```bash
 zfs set sharenfs="no_root_squash,rw=@172.16.10.0/24" pool/home
 ```
 Cette commande partage le dataset au sous-réseau `172.16.10.0/24`, l'option
 `no_root_squash` permet au root du client NFS d'avoir tous les droits sur les
 fichiers du dataset.
 Il est également préférable d'activer les acl POSIX sur la pool, dans le cas
 contraire il peut y avoir des problèmes de permissions à la création de
 fichiers :
 ```bash
 zfs set acltype=posixacl pool
 ```
 ## Détruire un dataset
 Pour détruire le dataset `pool/path` on utilise la commande :
 ```bash
 sudo zfs destroy pool/path
 ```
 ## Désactiver le sync
 Renvoyer une confirmation d'écriture sur le disque après chaque opération
 diminue énormément les performances du NFS. On peut dire à ZFS de mentir au
 NFS sur le retour des opérations sync(). Pour ça, on utilise la commande :
 ```bash
 sudo zfs set sync=disabled pool/path
 ```
 ## Changer un disque
 Récupérer le guid du disque qu'on souhaite changer avec `zdb` (`zpool status`
 peut aider à récuperer le nom du disque concerné). Une fois que c'est fait
 on peut retirer le disque avec : `zpool offline pool ${guid}` puis on remplace
 l'ancien disque par le nouveau :
 `zpool replace pool ${guid} ${nouveau disque}`.
 Après ça, on peut monitorer la reconstruction avec `zpool status`.
 ## Chiffrement
 ZFS permet de nativement chiffrer un dataset. Attention, il faut que ça soit
 fait à la **creation** du dataset. Ça ne peut pas se changer après.
 ### Créer un dataset chiffré
 Pour créer un dataset chiffré il suffit de rajouter les options de
 chiffrement avec `encryption=on`. Il faut aussi spécifier le format de la clé
 (`raw, hex, passphrase`). Par défaut, la clé va être promptée, mais il est
 possible de la stocker sur le système de fichier, ou bien via une URL.
 L'option `encryption` permet aussi de spéficier l'algorithme de chiffrement à
 utiliser.
 Par exemple:
 ```bash
 sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset
 ```
 Pour vérifier que tout va bien on peut récupérer la propriété de
 chiffrement :
 ```bash
 sudo zfs get encryption pool/dataset
 ```
 Pour changer la clé il suffit d'utiliser la commande suivante :
 ```bash
 sudo zfs key -c pool/dataset
 ```
 qui va demander la nouvelle passphrase.
 Il est aussi possible de changer la source de la clé (pour aller chercher la
 clé dans un fichier par exemple).
 ### Monter/démonter un dataset chiffré
 Par défaut le dataset sera monté. Pour le démonter il suffit d'utiliser la
 commande `unmount`. Attention, la clé de chiffrement sera toujours chargée,
 et le dataset pourra être remonté sans redemander la clé. Pour ça, il faut
 décharger la clé :
 ```bash
 sudo zfs unmount pool/dataset && sudo zfs unload-key pool/dataset
 ```
 Pour remonter le dataset il faut alors recharger la clé :
 ```bash
 sudo zfs load-key pool/dataset && sudo zfs mount pool/dataset
 ```
--- a/outils/os/README.md
+++ b/outils/os/README.md
@ -0,0 +1,15 @@
 # Systèmes d'exploitation
 ## Présentation
 Ce dossier contient une présentation des systèmes d'exploitation utilisés
 par le Crans.
 Le but n'est pas de réexpliquer l'entièreté des  fonctionnalités, mais
 simplement d'avoir une explication de ce que l'on parle  pour avoir des bases
 de compréhension.
 ## Organisation
 L'organisation est la même que décrite dans [le fichier `README.md` du
 dossier parent](../README.md).
--- a/outils/os/debian.md
+++ b/outils/os/debian.md
--- a/outils/os/nixos.md
+++ b/outils/os/nixos.md
@ -0,0 +1,6 @@
 # NixOS
 Le Crans utilise [NixOS](https://nixos.org/) sur plusieurs machines virtuelles.
 Une documentation complète est disponible au [dépôt git de la configuration
 NixOS du Crans](https://gitlab.crans.org/nounous/nixos).
--- a/outils/os/proxmox.md
+++ b/outils/os/proxmox.md
--- a/outils/protocoles/README.md
+++ b/outils/protocoles/README.md
@ -0,0 +1,15 @@
 # Protocoles
 ## Présentation
 Ce dossier contient une présentation de plusieurs protocoles utilisés par le
 Crans.
 Le but n'est pas de réexpliquer l'entièreté des  fonctionnalités, mais
 simplement d'avoir une explication de ce que l'on parle  pour avoir des bases
 de compréhension.
 ## Organisation
 L'organisation est la même que décrite dans [le fichier `README.md` du
 dossier parent](../README.md).
--- a/outils/protocoles/bgp.md
+++ b/outils/protocoles/bgp.md
@ -1,16 +1,22 @@
 # BGP
-BGP (Border Gateway Protocol) est un protocole d'échange de routes IP entre AS sur internet. On le qualifie de protocole de routage à vecteurs de chemins.
+BGP (Border Gateway Protocol) est un protocole d'échange de routes IP entre AS
 sur internet. On le qualifie de protocole de routage à vecteurs de chemins.
 BGP utilise le port 179 en TCP.
-Sa version 4 est spécifiée par la [RFC 4271](https://datatracker.ietf.org/doc/html/rfc4271).
+Sa version 4 est spécifiée par la [RFC
 4271](https://datatracker.ietf.org/doc/html/rfc4271).
-# Autonomous System
+## Autonomous System
-Un système autonome (AS) est un ensemble de préfixes IP sous le contrôle d'une seule entité ayant une politique de routage cohérente sur l'internet.
+Un système autonome (AS) est un ensemble de préfixes IP sous le contrôle
 d'une seule entité ayant une politique de routage cohérente sur l'internet.
-Chaque AS est identifié par son numéro (ASN) qui est utilisé dans le protocole BGP. À l'origine un ASN était un entier représenté sur 16 bits mais la [RFC 6793](https://datatracker.ietf.org/doc/html/rfc6793) a étendu cette représentation à 32 bits.
+Chaque AS est identifié par son numéro (ASN) qui est utilisé dans le
 protocole BGP. À l'origine un ASN était un entier représenté sur 16 bits
 mais la [RFC 6793](https://datatracker.ietf.org/doc/html/rfc6793) a étendu
 cette représentation à 32 bits.
 Certains ASN sont réservés à des usages particuliers :
--- a/outils/protocoles/dns.md
+++ b/outils/protocoles/dns.md
@ -0,0 +1,137 @@
 # DNS
 DNS (Domain Name System) est un protocole d'annuaire. Il utilises deux ports :
 * Le port 53 en UDP pour la plupart des échanges.
 * Le port 53 en TCP pour les échanges de grande taille (tels que du transfert
  de zone).
 DNS sert principalement à traduire les noms de domaines en adresse IP.
 C'est est un service hierarchisé dont le sommet est appelé la racine, et est
 représentée par un point (`.`). Chaque nom de domaine est découpé en
 plusieurs sous parties :
 Par exemple `zamok.crans.org` est un sous-domaine de `crans.org` lui-même
 sous-domaine de `org` qui est un sous-domaine de `.` (la racine).
 Il existe plusieurs types de serveurs DNS :
 * Les serveurs Autoritaires, qui s'occupent de garder à jour le gros
  dictionnaire (ou annuaire) de la zone qu'ils gouvernent (par exemple
  `crans.org`, `crans.eu` ou `crans.fr`)
 * Les serveurs Récursifs, qui s'occupent de faire des requêtes successives
  pour obtenir la valeur souhaitée, ils gardent très souvent en cache les
  informations récoltées, ce qui permet d'accélérer la réponse et d'éviter
  de surcharger les serveurs autoritaires.
 DNS permet d'associer des enregistrements (records) à des noms, ces
 enregistrements ont une classe et un type dont la liste est disponible [sur le
 site de
 l'IANA](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml).
 La classe utilisée traditionnellement est la classe `IN` (pour internet),
 voici quelques types courants :
 | Type | Description |
 |------|-------------|
 | `A` | Adresse IPv4 |
 | `AAAA` | Adresse IPv6 |
 | `CNAME` | Alias vers un autre nom de domaine |
 | `NS` | Nom d'un serveur DNS autoritaire |
 | `MX` | Nom d'un serveur mail |
 Ainsi on a par exemple les enregistrements suivants dans la zone `crans.org` :
 ```txt
 zamok.crans.org. IN A 185.230.79.1
 perso.crans.org. IN CNAME hodaur.crans.org.
 crans.org. IN NS silice.crans.org.
 crans.org. IN MX 10 redisdead.crans.org.
 ```
 Le 10 dans la valeur du champ MX est la priorité du serveur mail.
 ## host
 Pour résoudre des noms de domaines la commande privilégiée est la commande
 `host` :
 ```bash
 benjamin@tiamat ~ $ host zamok.crans.org
 zamok.crans.org has address 185.230.79.1
 zamok.crans.org has IPv6 address 2a0c:700:2:0:ec4:7aff:fe59:a1ad
 ```
 ```bash
 benjamin@tiamat ~ $ host crans.org
 crans.org has address 185.230.79.10
 crans.org has IPv6 address 2a0c:700:2::ff:fe01:4502
 crans.org mail is handled by 10 redisdead.crans.org.
 crans.org mail is handled by 15 sputnik.crans.org.
 crans.org mail is handled by 25 freebox.crans.org.
 ```
 ## dig
 La commande `dig` permet d'effectuer des requêtes DNS plus complexes que
 `host`, la commande `dig -t TYPE @server name` est équivalente à la commande
 `host -vt TYPE name server`. `dig` peut prendre des options de requête plus
 qui modifient son comportement, en voici quelques exemples :
 * `+short`: affiche uniquement la section de réponses de la requête et de
  manière compacte
 * `+dnssec`: affiche également les résultats des requêtes pour les champs
  DNSSEC associés à la requête demandée
 * `+rrcomments`: affiche des commentaires sur certains enregistrements
 * `+https`: effectue une query DNS over HTTPS (DoH)
 * `+trace`: fait les requêtes successives récursivement côté client afin
  de déterminer le résultat par exemple :
  `dig +trace @ns0.fdn.fr zamok.crans.org`:
   ```txt
   .      47747 IN  NS  a.root-servers.net.
   .      47747 IN  NS  b.root-servers.net.
   .      47747 IN  NS  c.root-servers.net.
   .      47747 IN  NS  d.root-servers.net.
   .      47747 IN  NS  e.root-servers.net.
   .      47747 IN  NS  f.root-servers.net.
   .      47747 IN  NS  g.root-servers.net.
   .      47747 IN  NS  h.root-servers.net.
   .      47747 IN  NS  i.root-servers.net.
   .      47747 IN  NS  j.root-servers.net.
   .      47747 IN  NS  k.root-servers.net.
   .      47747 IN  NS  l.root-servers.net.
   .      47747 IN  NS  m.root-servers.net.
   .      47747 IN  RRSIG NS 8 0 518400 20220629170000 20220616160000 47671 . WGw6h2UFnKlJdCnApXM7dYkGuSpmRwokdwl0PzQMt0yUUG/Dumwpijn5 MEeOCxhoP29ni62JRMCGxgIirXVOHGfiMHDcx/dnv2gMnsr1OhQjPgwj hOu/NjZVkb612QW3b/i0mwDdjcEwRFQs9wzVZIBc4mPTFjocT2C2GlQc noLupUmliv38lfaPd+knrbhIUdwD8VEHDrzpDfdwR/kws+fWDjBcgUjA 77WzsA+FiwkqNvFIhQfMG+5CSXd0PpD3pPhdA6lCKa3l1AM4Cfnbtvj6 tuejEnNvbxsBaPOkiRz642/ysLV+fhXrP4U9BnWncUwe92NtFlZYRCHe a/D+yw==
   ;; Received 525 bytes from 2001:910:800::12#53(ns0.fdn.fr) in 23 ms
   org.      172800 IN  NS  a0.org.afilias-nst.info.
   org.      172800 IN  NS  a2.org.afilias-nst.info.
   org.      172800 IN  NS  b0.org.afilias-nst.org.
   org.      172800 IN  NS  b2.org.afilias-nst.org.
   org.      172800 IN  NS  c0.org.afilias-nst.info.
   org.      172800 IN  NS  d0.org.afilias-nst.org.
   org.      86400  IN  DS  26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
   org.      86400  IN  RRSIG DS 8 1 86400 20220630050000 20220617040000 47671 . bKm4Ul/DPpqbqvF0gRS1Gzrmk9N0VU2Qa1dBIb/vbx6N+SEVK1wGpD20 BA6mdyFL2SOOuhEldC44N/cj401aLoli/9Bj71hdYl0XLcW/Hiq1xo2U 6Iqvfu4GwBGb36aLfce8DYEdnTtpbicXrFszx8dg2CAnFvCYLve6sA/r DOzs+K8LCsTi3cdOTuee3mEN1XC6SAfIrZDDtLEwZXiyxRAI7GbuM0i8 LCFHRa7YBlf8EOFNafkFsCi4qM4cHdnavVAxDH+gOeYnjVOd3yhezJb9 /hRBo3aIKGY1orjb+erQAOxhly26f8v2H/h0czKOXriNL7d4id8aa1fN qWiFeA==
   ;; Received 781 bytes from 199.7.83.42#53(l.root-servers.net) in 27 ms
   crans.org.   3600  IN  NS  sputnik.crans.org.
   crans.org.   3600  IN  NS  silice.crans.org.
   crans.org.   3600  IN  DS  40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2
   crans.org.   3600  IN  RRSIG DS 8 2 3600 20220630152826 20220609142826 41346 org. EjZHR/kgXopDL/Rqw5wMWQn2AB2stt6eu0TtGHa2Gt1/LhOPraqNbXJq Ufg7VhcCRtY4DaZnp9wnBXzK9vdqUIIRMuNQoA6mEdj8qpjRajsjfPdT D87bU6h1OH5YghQAzi2N90LGgjlDqdB50xWIZHgMeLLH53nePcAcxpxE VA4=
   ;; Received 358 bytes from 2001:500:e::1#53(a0.org.afilias-nst.info) in 243 ms
   zamok.crans.org. 3600  IN  A 185.230.79.1
   zamok.crans.org. 3600  IN  RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5
  crans.org.    3600  IN  NS  silice.crans.org.
   crans.org.   3600  IN  NS  sputnik.crans.org.
   crans.org.   3600  IN  RRSIG NS 14 2 3600 20220711101913 20220611094455 40871 crans.org. +BvWwsxxekrKHDFCXTL2d/pHP/2i75U6qah3Ee15SSDSQhjbnwCkI2+a Q6zGpnkwnSsB6HfRgoCbXp8r/rRzgAV7pGN06wPyejJRzkgRB+euSjbD tUmc8ODVxVWYH7iQ
   ;; Received 1041 bytes from 2a0c:700:2::ff:fe01:4702#53(silice.crans.org) in 23 ms
   ```
--- a/outils/protocoles/dnssec.md
+++ b/outils/protocoles/dnssec.md
@ -0,0 +1,81 @@
 # DNSSEC
 DNSSEC (Domain Name System Security Extensions) est un ensemble d'extension de
 sécurité pour DNS. Il permet d'authentifier les données obtenues par le
 protocole DNS.
 Pour cela, chaque entrée du DNS est signée cryptographiquement avec une clef
 privée. La clef publique, elle-même publiée dans le DNS permet de vérifier
 les signatures. L'authenticité de la clef publique est assurée par la zone
 parente (via les enregistrements DS), dans laquelle elle est publiée.
 Ainsi, il suffit de faire confiance à la clef publique de la racine du DNS (et
 seulement de la racine) pour pouvoir établir une chaîne de confiance dans
 tous le DNS.
 Les enregistrements DNS associés au DNSSEC sont les suivants :
 * `DNSKEY`: une clef publique servant à signer une zone
 * `DS`: un hash de clef publique d'une zone fille (conceptuellement proche
  d'un GLUE record NS)
 * `RRSIG`: une signature d'un enregistrement
 * `NSEC`: un pointeur vers la prochaine entrée DNS signée (dans l'ordre
  alphabétique), celui sert à prouver l'absence d'un enregistrement
 * `NSEC3`: une variante de `NSEC` où les entrées DNS sont hashées
 * `NSEC3PARAM`: des informations servant à calculer les hash pour les
  enregistrements `NSEC3`
 ## Exemples
 ### DNSKEY
 On lance la commande `dig -t DNSKEY @silice.crans.org crans.org` :
 ```txt
 ;; QUESTION SECTION:
 ;crans.org.     IN  DNSKEY
 ;; ANSWER SECTION:
 crans.org.    3600  IN  DNSKEY  257 3 14 Db282t/1HUd5ccAnJ0BSaidrnseZEtG/8Cj9MbzYl/GbgGxA8msR/Dq8 KfIeobLwnZFF5277dhdzAAdfKAb/XclhHBqpDtaV+bvd21n8MLR3yhdI VsFAde/yOBFW28fV
 crans.org.    3600  IN  DNSKEY  256 3 14 4gBTKamW1QSNWNSWkR0qVswo+GcIV7cmKf6y4zuqlinDcvN0a5+ppqW2 almA4TF7vh7u9jH2/iwZVmHiikgpTiRzZJzga158/AlYTqE4pTK6zhin YlPz9w/PTSdOXMU6
 ```
 La zone `crans.org` possède deux clefs de signature : une KSK (Key Signing
 Key) et une ZSK (Zone Signing Key).
 ### DS
 On lance la commande `dig -t DS @a0.org.afilias-nst.info crans.org`:
 ```txt
 ;; QUESTION SECTION:
 ;crans.org.     IN  DS
 ;; ANSWER SECTION:
 crans.org.    3600  IN  DS  40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2
 ```
 La zone `crans.org` a publié dans la zone `org` le hash d'une clef publique
 (la KSK).
 ### RRSIG
 On lance la commande `dig -t RRSIG @silice.crans.org zamok.crans.org` :
 ```txt
 ;; QUESTION SECTION:
 ;zamok.crans.org.   IN  RRSIG
 ;; ANSWER SECTION:
 zamok.crans.org.  3600  IN  RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5
 zamok.crans.org.  3600  IN  RRSIG AAAA 14 3 3600 20220711100552 20220611093221 40871 crans.org. 2XkmJYJbeKgXK0plIB/d1nnhQ6mXhubZu4k6jASlp9BumPy6WLRPUxR1 QhFV+gidKTVidsWL6faL28HH8j4pmxVGeIC50c5NOfaBa3nVTfeD+pUp MEhC0VwhBYnODuu9
 zamok.crans.org.  3600  IN  RRSIG SSHFP 14 3 3600 20220711100552 20220611093221 40871 crans.org. nd/HiLy0qw3NMo2Lwn8P/J2h1UaXjGWAFYPCK5ISQWBILPE5iO+TdaXy uyOy4l4Dc9hdanzvKQFBuE9hG9gkr3KpmtCEFWtHlg6PAu7MIqXTzpbV 4kR2wjiuCLfmPq2W
 ```
 `zamok.crans.org` possède trois enregistrements signés : ils sont de types
 `A`, `AAAA` et `SSHFP`.
--- a/outils/protocoles/http.md
+++ b/outils/protocoles/http.md
@ -0,0 +1,7 @@
 # HTTP
 HTTP (Hypertext Transfer Protocol) est un protocole permettant de servir un
 site web. Il utilise le port 80.
 Sa version sécurisé (HTTPS) consiste en une intégration de
 [TLS](tools/tls.md) au protocole et utilise le port 443.
--- a/outils/protocoles/ip.md
+++ b/outils/protocoles/ip.md
@ -0,0 +1,133 @@
 # IP
 ## Généralités
 IP (Internet Protocol) est le protocole principal de communication sur
 l'internet, actuellement deux versions sont en cours d'utilisation : IPv4 et
 IPv6.
 IP permet de transmettre des datagrammes d'un point à un autre.
 ### Adressage
 Les adresses IP sont alloués avec la méthode du CIDR (Classless Inter-Domain
 Routing). Cette méthode consiste à noter une adresse au format
 `adresse/longueur_préfixe`, elle induit une attribution des IP par blocs.
 Les `n` bits (où `n` est la longueur du préfixe) les plus significatifs
 servent à identifier le réseau auquel l'adresse appartient.
 ## IPv4
 Une adresse IPv4 s'écrit sur 32 bits et utilise une notation décimale
 pointée (4 entiers séparés par des `.`), par exemple `192.168.0.1` est une
 adresse IPv4.
 De même `192.168.0.0/24` est un exemple de notation CIDR pour un sous-réseau
 IPv4.
 Dans un réseau local les adresses IPv4 peuvent être attribuées par le
 protocole DHCP ou configurées statiquement.
 À noter que dans un sous-réseau IPv4 la première et la dernière sont
 réservées respectivement pour identifier le réseau et effectuer du broadcast
 par exemple pour le bloc `192.168.0.0/24`, l'adresse `192.168.0.0` est
 réservée et l'adresse `192.168.0.255` est l'adresse de broadcast.
 Cette restriction peut être contournée sous Linux, par exemple sous
 [Debian](/tools/debian.md) on peut modifier l'interface comme ceci :
 ```txt
 iface eth0 inet static
    broadcast -
 ```
 Ceci permet d'utiliser des blocs d'adresses IPv4 d'une taille de préfixe
 égale à 31 afin d'interconnecter deux machines.
 ### IPv4 privées
 Certains blocs d'adresses IPv4 sont réservés à des utilisations privées,
 celà signifie qu'ils ne sont pas annoncés sur l'internet. Ils sont
 spécifiés par la [RFC 1918](https://tools.ietf.org/html/rfc1918) et sont les
 suivants :
 * `10.0.0.0/8`
 * `172.16.0.0/12`
 * `192.168.0.0/16`
 ### IPv4 de lien local
 Un bloc d'IPv4 est réservé pour utilisation sur le réseau local, c'est à
 dire que ce bloc n'est normalement jamais routé, il s'agit du bloc
 `169.254.0.0/16`.
 ### IPv4 multicast
 un bloc d'IPv4 est réservé pour du multicast, il s'agit du bloc `224.0.0.0/4`.
 ## IPv6
 Une adresse IPv6 s'écrit sur 128 bits et utilise une notation hexadécimale
 séparée par des `:` (deux-points), par exemple
 `2001:0db8:0000:0000:0000:0000:0000:0000` (on regroupe les octets par groupe de
 2).
 Il existe également une notation compacte pour les adresses IPv6 : on peut
 omettre les 0 en début de bloc et remplacer la plus longue suite de blocs nuls
 par `::`, par exemple l'adresse précédente peut s'écrire `2001:db8::`.
 Ainsi `2001:db8::/32` est un exemple de notation CIDR pour un sous-réseau IPv6.
 Dans un réseau local les adresses IPv6 peuvent être attribuées par le
 protocole NDP, par le protocole DHCPv6 ou configurées statiquement.
 La liste des IPv6 attribuées est disponible
 [ici](https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml)
 et
 [là](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml).
 Il n'y a pas de broadcast en IPv6 et la première adresse du bloc peut être
 utilisée sans risque. Le broadcast est remplacé par du multicast : tous les
 nœuds sur le réseau local répondent sur l'adresse `ff02::1`.
 ### IPv6 uniques locales
 Un bloc d'adresses IPv6 est réservé pour des utilisations privées, c'est
 l'équivalent des blocs d'IPv4 privées. Il s'agit du bloc `fc00::/7`.
 ### IPv6 de lien local
 Un bloc d'IPv6 est réservé pour utilisation sur le réseau local, il s'agit
 du bloc `fe80::/10`.
 ### IPv6 multicast
 Un bloc d'IPv6 est réservé pour du multicast, il s'agit du bloc `ff00::/8`.
 ## ip
 Sous Linux la commande privilégiée pour consulter l'état de la configuration
 réseau est `ip` (fournie par la suite `iproute2`) voici quelques exemples de
 commandes :
 Afficher l'état des interfaces de la machine (adresses IP attribuées et leur
 sous-réseau) :
 ```bash
 ip address
 ```
 Afficher l'état des routes IPv4 de la machine :
 ```bash
 ip route
 ```
 Afficher l'état des routes IPv6 de la machine :
 ```bash
 ip -6 route
 ```
--- a/outils/protocoles/irc.md
+++ b/outils/protocoles/irc.md
@ -0,0 +1,36 @@
 # IRC
 IRC (Internet Relay Chat) est un protocole de communication textuelle. C'est le
 protocole privilégié pour les discussions instantanées entre membres actifs.
 Sa version 2 est spécifiée par la [RFC
 2812](https://tools.ietf.org/html/rfc2812), une [version 3](https://ircv3.net/)
 est en cours de développement.
 Il utilise 2 ports :
 * Le port 6667 en TCP pour la communication en clair.
 * Le port 6697 en TCP pour la communication chiffrée avec TLS.
 Il existe deux types d'entités dans le protocole IRC : les utilisateurs et les
 canaux. Un nom d'utilisateur (nick) commence obligatoirement par une lettre ou
 un des caractères spéciaux définis dans la RFC. Un nom de canal commence
 obligatoirement par un caractère `#`, `&`, `!` ou `+`, en pratique seul le `#`
 est implémenté de manière universelle.
 Le protocole IRC utilise des commandes, dans la plupart des clients il est
 possible d'envoyer une commande en entrant un `/` suivi de la commande dans le
 prompt du client.
 ## Modes
 Il est possible d'attribuer des «flags» aux utilisateurs et aux canaux qui
 permettent de modifier leur comportement, ceux-ci s'appellent des modes,
 certains modes sont spécifiés dans la RFC mais la quasi-totalité des
 serveurs IRC implémentent d'autres modes pour ajouter des fonctionnalités au
 protocole.
 Ces modes sont manipulables avec la commande `MODE`, par exemple `MODE nick +w`
 pour ajouter le mode `w` à l'utilisateur `nick` ou `MODE #channel -t` pour
 retirer le mode `t` du canal `#channel`.
--- a/outils/protocoles/ldap.md
+++ b/outils/protocoles/ldap.md
@ -0,0 +1,5 @@
 # LDAP
 LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à une
 base donnée arborescente (directory). Sa dernière version (version 3) est
 spécifiée dans la [RFC 4511](https://tools.ietf.org/html/rfc4511).
--- a/outils/protocoles/nfs.md
+++ b/outils/protocoles/nfs.md
@ -0,0 +1,16 @@
 # NFS
 NFS (Network File System) est un système de fichiers pouvant être monté à
 travers le réseau : le serveur NFS expose des parties de son arborescence qui
 peuvent être montées par les clients.
 NFS utilise le port 2049 en TCP et en UDP.
 Le système de fichier ZFS supporte nativement l'export NSF de tout ou partie
 de son arborescence, vous pouvez vous référer à la section *Partager un
 dataset en NFS* de la page ZFS pour savoir comment faire.
 ## Version 4
 La dernière version de NFS est la version 4.2 spécifiée par la [RFC
 7862](https://tools.ietf.org/html/rfc7862).
--- a/outils/protocoles/ntp.md
+++ b/outils/protocoles/ntp.md
@ -0,0 +1,7 @@
 # NTP
 NTP (Network Time Protocol) est un protocole de synchronisation d'horloge, il
 utilise le port 123 en UDP.
 Sa version 4 est spécifiée par la [RFC
 5905](https://tools.ietf.org/html/rfc5905).
--- a/outils/protocoles/smtp.md
+++ b/outils/protocoles/smtp.md
@ -0,0 +1,11 @@
 # SMTP
 SMTP (Simple Mail Transfer Protocol) est un protocol d'échange de courrier
 électronique. Il utilise 3 ports différents :
 * Le port 25 en TCP (smtp) pour l'échange de mail entre serveurs.
 * Le port 465 en TCP (submissions) pour la soumission de mail chiffrée par TLS.
 * Le port 587 en TCP (submission) pour la soumission de mail en clair avec
  possibilité de chiffrement via la commande STARTTLS.
--- a/outils/protocoles/snmp.md
+++ b/outils/protocoles/snmp.md
@ -7,61 +7,59 @@ connectées.
 ## SNMPv3 vs SNMPv1/v2
-Pour des raisons de sécurité, vous devriez toujours utiliser SNMPv3 qui
+Pour des raisons de sécurité, vous devriez toujours utiliser SNMPv3 qui a un
-a un système d'authentification et de chiffrement. Si votre documentation
+système d'authentification et de chiffrement. Si votre documentation parle de
-parle de « communautés SNMP », c'est que c'est de la v1 ou v2 et que vous
+"communautés SNMP", c'est que c'est de la v1 ou v2 et que vous devriez
-devriez mieux partir en courant.
+mieux partir en courant.
 ## Monitoring d'un APC Rack PDU avec Prometheus
-Lors du déménagement de Cachan vers Saclay, le Crans a récupérer un
+Lors du déménagement de Cachan vers Saclay, le Crans a récupéré un [APC
-[APC Rack PDU 2G Metered-by-Outlet with Switching](https://www.apc.com/shop/th/en/products/Rack-PDU-2G-Metered-by-Outlet-with-Switching-ZeroU-20A-208V-16A-230V-21-C13-3-C19/P-AP8659)
+Rack PDU 2G Metered-by-Outlet with
-venant de l'ancien équipement de la DSI à Cachan.
+Switching](https://www.apc.com/shop/th/en/products/Rack-PDU-2G-Metered-by-Outlet-with-Switching-ZeroU-20A-208V-16A-230V-21-C13-3-C19/P-AP8659)
-Ce Power Distribution Unit (PDU) est utilisé pour alimenter notre
+venant de l'ancien équipement de la DSI à Cachan. Ce Power Distribution Unit
-baie de serveur principale.
+(PDU) est utilisé pour alimenter notre baie de serveur principale. Cette unité
-Cette unité de distribution de courant est capable de monitorer chaque
+de distribution de courant est capable de monitorer chaque prise avec plusieurs
-prise avec plusieurs métriques utiles. Par exemple, <root@crans.org> reçoit
+métriques utiles. Par exemple, <root@crans.org> reçoit un courrier quand une
-un courrier quand une prise surcharge la distribution.
+prise surcharge la distribution.
-Dans les sous-sections on va présenter comment mettre en place le
+Dans les sous-sections on va présenter comment mettre en place le monitoring
-monitoring en SNMPv3 de ce PDU vers la base de monitoring Prometheus.
+en SNMPv3 de ce PDU vers la base de monitoring Prometheus.
 ### Configuration du SNMPv3 et des droits d'accès
-*On a réalisé ces étapes sur le firmware AOS v6.1.3.
+*On a réalisé ces étapes sur le firmware AOS v6.1.3. Si vous vous sentez
-Si vous vous sentez aventureux et mettez à jour le PDU, les menus
+aventureux et mettez à jour le PDU, les menus et identifiants risquent de
-et identifiants risquent de changer.*
+changer.*
-Connectez-vous à l'interface Web du PDU. Par défault il écoute en HTTP
+Connectez-vous à l'interface Web du PDU. Par défault il écoute en HTTP sur
-sur son port 80 et on peut s'identifier avec l'identifiant `apc` et le
+son port 80 et on peut s'identifier avec l'identifiant `apc` et le mot de passe
-mot de passe `apc`. *Néanmoins, pour sécuriser l'infrastructure, le mot de
+`apc`. *Néanmoins, pour sécuriser l'infrastructure, le mot de passe actuel
-passe actuel est dans la bibliothèque de mots de passe du Crans.*
+est dans la bibliothèque de mots de passe du Crans.*
-Après connexion, allez dans
+Après connexion, allez dans `Configuration > Network > SNMPv3 > Access` et
-`Configuration > Network > SNMPv3 > Access` et cochez
+cochez `Enable SNMPv3 access` puis appliquez.
 `Enable SNMPv3 access` puis appliquez.
-Le PDU va proposer de se redémarrer pour appliquer les changements.
+Le PDU va proposer de se redémarrer pour appliquer les changements. Déjà,
-Déjà, redémarrer le PDU ne coupe pas les prises (heureusement!), mais
+redémarrer le PDU ne coupe pas les prises (heureusement!), mais on a d'autres
-on a d'autres changements à réaliser avant de le redémarrer.
+changements à réaliser avant de le redémarrer.
-On change les identifiants pour collecter les métriques en SNMPv3.
+On change les identifiants pour collecter les métriques en SNMPv3. Allez dans
 Allez dans
 `Configuration > Network > SNMPv3 > User Profiles` et configurez un utilisateur
 Vous devriez utiliser `SHA` pour `Authentication Protocol` et `AES` pour
 `Privacy Protocol` (car `MD5` et `DES` sont vraiment faibles).
 *Au Crans, le compte s'appelle `crans`.*
-Maintenant que le compte est configuré, il faut lui autoriser l'accès.
+Maintenant que le compte est configuré, il faut lui autoriser l'accès. Allez
-Allez dans
+dans `Configuration > Network > SNMPv3 > Access Control` et choisissez
-`Configuration > Network > SNMPv3 > Access Control` et choisissez l'utilisateur,
+l'utilisateur, puis activez l'accès et mettez l'adresse IPv4 de la machine qui
-puis activez l'accès et mettez l'adresse IPv4 de la machine qui contactera le PDU en SNMP.
+contactera le  PDU en SNMP.
 ### Test de l'accès SNMP
-La commande suivante devrait maintenant marcher
+La commande suivante devrait maintenant marcher (changer `PDU_*` avec les
-(changer `PDU_*` avec les bonnes valeurs).
+bonnes valeurs). Sur les dérivées de Debian, vous devriez installer `snmp` et
 Sur les dérivées de Debian, vous devriez installer `snmp` et
 `snmp-mibs-downloader` (optionnel, télécharge une base de données non libre
 de correspondance des valeurs SNMP, appelées `MIBs`).
@ -73,7 +71,8 @@ echo "mibdirs +$HOME/.snmp/mibs" >> $HOME/.snmp/snmp.conf
 curl "https://download.schneider-electric.com/files?p_enDocType=Firmware&p_File_Name=powernet432.mib&p_Doc_Ref=APC_POWERNETMIB_432" -o $HOME/.snmp/mibs/powernet432.mib
 ```
-Une fois cela effectué, la commande suivante devrait afficher les valeurs intéressantes :
+Une fois cela effectué, la commande suivante devrait afficher les valeurs
 intéressantes :
 ```bash
 # -m ALL: try to load all SNMP MIBs to output metrics name
@ -91,25 +90,28 @@ personne habitué au SNMPv3.
 métriques utiles. Vous tombez devant un donjon qui vient de vous spammer plus
 de 2000 métriques, que faites-vous ?*
-`snmpwalk` devrez vous spammer de métriques toutes plus ou moins utiles.
+`snmpwalk` devrez vous spammer de métriques toutes plus ou moins utiles. Si
-Si vous avez la base de données de MIBs installée, la sortie devrait être
+vous avez la base de données de MIBs installée, la sortie devrait être
-lisible et vous devriez rapidement trouver votre bonheur. Sinon vous êtes
+lisible et vous devriez rapidement trouver votre bonheur. Sinon vous êtes en
-en quête soit pour deviner les identifiants des métriques intéressantes,
+quête soit pour deviner les identifiants des métriques intéressantes, soit
-soit pour aller chercher un fichier de définition MIB sur le site du
+pour aller chercher un fichier de définition MIB sur le site du constructeur.
 constructeur.
 Pour le PDU, après quelques observations, on a gardé :
-  * `rPDU2DeviceStatusLoadState`
+* `rPDU2DeviceStatusLoadState`
-  * `rPDU2DeviceStatusPower`
+
-  * `rPDU2DeviceStatusPeakPower`
+* `rPDU2DeviceStatusPower`
-  * `rPDU2PhaseStatusPowerFactor`
+
-  * `rPDU2OutletMeteredStatusPower`
+* `rPDU2DeviceStatusPeakPower`
 * `rPDU2PhaseStatusPowerFactor`
 * `rPDU2OutletMeteredStatusPower`
 ### Configuration de l'exporteur Prometheus SNMP
-*C'est bien beau le SNMPv3, mais je ne vais pas snmpwalk dans un
+*C'est bien beau le SNMPv3, mais je ne vais pas snmpwalk dans un cron tout de
-cron tout de même !*
+même !*
 Prometheus SNMP exporter est livré avec un générateur de configuration.
 Cette étape de génération permet de créer la configuration de l'exporteur
@ -139,18 +141,17 @@ modules:
      priv_password: PDU_PRIVACY_PASSPHRASE
 ```
-Sur les dérivées de Debian, vous aurez à installer `prometheus-snmp-exporter`
+Sur les dérivées de Debian, vous aurez à installer
-puis lancer
+`prometheus-snmp-exporter` puis lancer `prometheus-snmp-generator generate`
-`prometheus-snmp-generator generate` dans `/etc/prometheus/` qui contient
+dans `/etc/prometheus/` qui contient `generator.yml`.
 `generator.yml`.
 ### Collecter l'exporteur avec Prometheus
-Maintenant que l'exporteur est configuré, vous pouvez le démarrer.
+Maintenant que l'exporteur est configuré, vous pouvez le démarrer. Il
-Il écoutera sur le port `9116` par défaut.
+écoutera sur le port `9116` par défaut.
-Dans la configuraiton de Prometheus, vous pouvez ajouter une section
+Dans la configuraiton de Prometheus, vous pouvez ajouter une section pour
-pour interroger cet exporteur en utilisant la définition `apc_pdu` définie dans
+interroger cet exporteur en utilisant la définition `apc_pdu` définie  dans
 la dernière section:
 ```YAML
@ -174,9 +175,10 @@ scrape_configs:
    target_label: __address__
 ```
-La bidouille `relabel_configs` permet à Prometheus de query l'exporter avec
+La bidouille `relabel_configs` permet à Prometheus de query l'exporter avec le
-le nom d'hôte ou adresse IP du périphérique afin de collecter les métriques
+nom d'hôte ou adresse IP du périphérique afin de collecter les métriques
 SNMP tout en gardant le label `instance` propre dans sa base de données.
 Vous devriez pouvoir redémarrer Prometheus et le PDU devrait être monitoré.
 *Voilà, vous brandissez Excalibur de fierté!*
--- a/outils/protocoles/tls.md
+++ b/outils/protocoles/tls.md
@ -1,26 +1,34 @@
 # TLS
-TLS (Transport Layer Security) est un protocole cryptographique permettant une communication sécurisée sur un réseau.
+TLS (Transport Layer Security) est un protocole cryptographique permettant une
 communication sécurisée sur un réseau.
 ## TLS 1.3
-La dernière version de TLS est TLS 1.3 spécifiée dans la [RFC 8446](https://tools.ietf.org/html/rfc8446).
+La dernière version de TLS est TLS 1.3 spécifiée dans la [RFC
 8446](https://tools.ietf.org/html/rfc8446).
 ## OpenSSL
-[OpenSSL](https://www.openssl.org/) est une bibliothèque implémentant le protocole TLS elle vient avec un binaire `openssl` permettant notamment de gérer les certificats TLS et d'effectuer des connexions chiffrées.
+[OpenSSL](https://www.openssl.org/) est une bibliothèque implémentant le
 protocole TLS elle vient avec un binaire `openssl` permettant notamment de
 gérer les certificats TLS et d'effectuer des connexions chiffrées.
 ### s_client
-Le binaire `openssl` lancé avec la sous-commande `s_client` permet d'effectuer une connexion TLS à la manière de netcat. Voici un exemple :
+Le binaire `openssl` lancé avec la sous-commande `s_client` permet d'effectuer
 une connexion TLS à la manière de netcat. Voici un exemple :
 ```bash
 openssl s_client -connect irc.crans.org:6697
 ```
-Ceci permet de se connecter sur le port 6697 du serveur identifié par le nom de domaine `irc.crans.org`.
+Ceci permet de se connecter sur le port 6697 du serveur identifié par le nom
 de domaine `irc.crans.org`.
-Il est également possible d'utiliser des protocoles utilisant STARTTLS (c'est à dire passant d'une connexion en clair à une connexion chiffrée a l'aide d'une commande) :
+Il est également possible d'utiliser des protocoles utilisant STARTTLS (c'est
 à dire passant d'une connexion en clair à une connexion chiffrée a l'aide
 d'une commande) :
 ```bash
 openssl s_client -starttls smtp -connect redisdead.crans.org:25
@ -28,31 +36,45 @@ openssl s_client -starttls smtp -connect redisdead.crans.org:25
 ### genpkey
-La sous-commande `genpkey` permet de générer une clef privée, par exemple (pour générer une clef privée ED25519) :
+La sous-commande `genpkey` permet de générer une clef privée, par exemple
 (pour générer une clef privée ED25519) :
 ```bash
 openssl genpkey -algorithm ED25519 -out key.pem
 ```
-Voici les valeurs notables possible de l'option `-algorithm` et les valeurs associées de l'option `-pkeyopt` permettant d'ajuster les paramètres de la clef privée:
+Voici les valeurs notables possible de l'option `-algorithm` et les valeurs
- * `ED25519` (pas d'options)
+associées de l'option `-pkeyopt` permettant d'ajuster les paramètres de la
- * `ED448` (pas d'options)
+clef privée:
- * `RSA`
+
 * `ED25519` (pas d'options)
 * `ED448` (pas d'options)
 * `RSA`
   * `rsa_keygen_bits`: le nombre de bits de la clef privée
   * `EC`
   * `ec_paramgen_curve`: le nom de la courbe de la clef privée
 ### x509
-La sous-commande `x509` permet d'afficher des informations sur un certificat et d'effectuer des opérations de signature.
+La sous-commande `x509` permet d'afficher des informations sur un certificat et
 d'effectuer des opérations de signature.
 On peut par exemple l'utiliser pour afficher la clef publique d'un certificat :
 ```bash
 openssl x509 -pubkey -in cert.pem -noout
 ```
 Ou encore signer un certificat avec une autorité :
 ```bash
 openssl x509 -req -in cert.csr -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out cert.pem -days 3650
 ```
-Le certificat `cert.pem` est délivrée par l'autorité `ca_cert.pem` pour 10 ans (3650 jours).
+
 Le certificat `cert.pem` est délivrée par l'autorité `ca_cert.pem` pour 10
 ans (3650 jours).
--- a/services/README.md
+++ b/services/README.md
@ -0,0 +1,11 @@
 # Services
 ## Présentation
 Ce dossier contient une présentation rapide des différents services du Crans
 mis à disposition aux utilisateurices. La documentation des services du Crans
 pour le Crans est disponible dans [ce dossier](../infrastructure/services).
 ## Organisation
 TODO
--- a/services/belenios.md
+++ b/services/belenios.md
@ -1,70 +1,82 @@
 # Belenios
-Belenios est un service développé par l'Inria recréant un bureau de vote complet en ligne avec autant voire plus de sécurité grâce à des bulletins chiffrés. Il a été mis en place pour l'assemblée générale du Crans en 2020, alors que la pandémie de Covid-19 empêchait toute réunion physique.
+Belenios est un service développé par l'Inria recréant un bureau de vote
 complet en ligne avec autant voire plus de sécurité grâce à des bulletins
 chiffrés. Il a été mis en place pour l'assemblée générale du Crans en
 2020, alors que la pandémie de Covid-19 empêchait toute réunion physique.
 ## Installation
-On considère que l'on dispose d'une machine virtuelle neuve installée sous Debian Bullseye.
+On considère que l'on dispose d'une machine virtuelle neuve installée sous
 Debian Bullseye.
-Belenios n'est malheureusement pas encore packagé dans Debian. Par chance, toutes ses dépendances le sont. On installe donc toutes les dépendances via APT, puis on compile Belenios manuellement.
+Belenios n'est malheureusement pas encore packagé dans Debian. Par chance,
 toutes ses dépendances le sont. On installe donc toutes les dépendances via
 APT, puis on compile Belenios manuellement.
 ### Dépendances
-Belenios est intégrallement écrit en OcamL. On installe toutes ses dépendances Debian, comme indiqué dans le README :
+Belenios est intégralement écrit en OCaml. On installe toutes ses
 dépendances Debian, comme indiqué dans le README :
 ```bash
-$ sudo apt update
+sudo apt update
-$ sudo apt install --no-install-recommends bubblewrap build-essential ca-certificates cracklib-runtime jq libgd-securityimage-perl libgmp-dev libncurses-dev libpcre3-dev libssl-dev libsqlite3-dev m4 pkg-config unzip wget zip zlib1g-dev
+sudo apt install --no-install-recommends bubblewrap build-essential ca-certificates cracklib-runtime jq libgd-securityimage-perl libgmp-dev libncurses-dev libpcre3-dev libssl-dev libsqlite3-dev m4 pkg-config unzip wget zip zlib1g-dev
 ```
-On installe ensuite toutes les dépendances OCamL depuis les paquets Debian, ce qui est plus économe par rapport à compiler toutes les bibliothèques avec Opam :
+On installe ensuite toutes les dépendances OCamL depuis les paquets Debian, ce
 qui est plus économe par rapport à compiler toutes les bibliothèques avec
 Opam :
 ```bash
-$ sudo apt install --no-install-recommends dune eliom libatdgen-ocaml-dev libcalendar-ocaml-dev libcmdliner-ocaml-dev libcryptokit-ocaml-dev libcsv-ocaml-dev libgettext-ocaml-dev libzarith-ocaml-dev
+sudo apt install --no-install-recommends dune eliom libatdgen-ocaml-dev libcalendar-ocaml-dev libcmdliner-ocaml-dev libcryptokit-ocaml-dev libcsv-ocaml-dev libgettext-ocaml-dev libzarith-ocaml-dev
 ```
-On doit enfin installer ``ocsigenserver``, qui sert de serveur web tel Nginx ou Apache adapté pour les projets OcamL :
+On doit enfin installer `ocsigenserver`, qui sert de serveur web tel Nginx ou
 Apache adapté pour les projets OCaml :
 ```bash
-$ sudo apt install --no-install-recommends ocsigenserver
+sudo apt install --no-install-recommends ocsigenserver
 ```
 ### Compilation de Belenios
 On commence par cloner le dépôt dans un endroit adapté :
 ```bash
-$ sudo git clone https://gitlab.inria.fr/belenios/belenios.git /opt/belenios -b 1.14
+sudo git clone https://gitlab.inria.fr/belenios/belenios.git /opt/belenios -b 1.14
 ```
-Il suffit ensuite dans le dossier ``/opt/belenios`` de lancer ``make build-release-server``.
+Il suffit ensuite dans le dossier `/opt/belenios` de lancer
-
+`make build-release-server`.
 ### Liens symboliques
-Pour avoir des binaires à des endroits cohérents avec la distribution Debian, on ajoute des liens symboliques à des endroits pertinents :
+Pour avoir des binaires à des endroits cohérents avec la distribution Debian,
 on ajoute des liens symboliques à des endroits pertinents :
 ```bash
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios /usr/lib/ocaml/belenios
+sudo ln -s /opt/belenios/_run/usr/lib/belenios /usr/lib/ocaml/belenios
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform /usr/lib/ocaml/belenios-platform
+sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform /usr/lib/ocaml/belenios-platform
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-js /usr/lib/ocaml/belenios-platform-js
+sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-js /usr/lib/ocaml/belenios-platform-js
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-native /usr/lib/ocaml/belenios-platform-native
+sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-native /usr/lib/ocaml/belenios-platform-native
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-server /usr/lib/ocaml/belenios-server
+sudo ln -s /opt/belenios/_run/usr/lib/belenios-server /usr/lib/ocaml/belenios-server
-$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-tool /usr/lib/ocaml/belenios-tool
+sudo ln -s /opt/belenios/_run/usr/lib/belenios-tool /usr/lib/ocaml/belenios-tool
-$ sudo ln -s /opt/belenios/_run/usr/share/belenios-server /usr/share/belenios-server
+sudo ln -s /opt/belenios/_run/usr/share/belenios-server /usr/share/belenios-server
 ```
 ### Configuration de ocsigenserver
-On commence par créer les dossiers de données qui nous intéressent, avec les bonnes permissions :
+On commence par créer les dossiers de données qui nous intéressent, avec les
 bonnes permissions :
 ```bash
-$ sudo -u ocsigen mkdir -p /etc/ocsigenserver/conf.d /var/lib/belenios /var/lib/belenios/data /var/lib/belenios/upload /var/lib/belenios/spool /var/log/belenios
+sudo -u ocsigen mkdir -p /etc/ocsigenserver/conf.d /var/lib/belenios /var/lib/belenios/data /var/lib/belenios/upload /var/lib/belenios/spool /var/log/belenios
 ```
-On ajoute enfin le fichier de configuration fourni par Belenios dans ``/etc/ocsigenserver/conf.d/belenios.conf``, en remplaçant les bonnes variables :
+On ajoute enfin le fichier de configuration fourni par Belenios dans
 `/etc/ocsigenserver/conf.d/belenios.conf`, en remplaçant les bonnes
 variables :
 ```xml
 <!-- -*- Mode: Xml -*- -->
@ -146,28 +158,41 @@ On ajoute enfin le fichier de configuration fourni par Belenios dans ``/etc/ocsi
 </ocsigen>
 ```
-Il faut noter que ``ocsigenserver`` n'est pas lancé au démarrage par défaut et un ``systemctl start ocsigenserver`` ne fonctionne pas, un ``service ocsigenserver start`` en revanche si. Pour autoriser ``ocsigenserver`` à se lancer au démarrage, il faut modifier le fichier ``/etc/default/ocsigenserver`` pour écrire ``LAUNCH_AT_STARTUP=true``. Il sera ensuite possible de démarrer le serveur grâce à systemd.
+Il faut noter que ``ocsigenserver`` n'est pas lancé au démarrage par défaut
 et un ``systemctl start ocsigenserver`` ne fonctionne pas, un
 `service ocsigenserver start` en revanche si. Pour autoriser `ocsigenserver` à
 se lancer au démarrage, il faut modifier le fichier
 `/etc/default/ocsigenserver` pour écrire `LAUNCH_AT_STARTUP=true`. Il sera
 ensuite possible de démarrer le serveur grâce à systemd.
-En redémarrant ``ocsigenserver``, Belenios sera accessible sur son port 80. Après une configuration de reverse-proxy près, Belenios est déjà accessible :)
+En redémarrant `ocsigenserver`, Belenios sera accessible sur son port 80.
-
+Après une configuration de reverse-proxy près, Belenios est déjà accessible :)
 Pour modifier le logo, il faut regarder autour de ``/usr/share/belenios-server/logo.png``.
 Pour modifier le logo, il faut regarder autour de
 `/usr/share/belenios-server/logo.png`.
 ### Déployer avec Ansible
-L'ensemble des opérations décrites sont déployées par le rôle Ansible du Crans : `<https://gitlab.crans.org/nounous/ansible/-/tree/newinfra/roles/belenios>`
+L'ensemble des opérations décrites sont déployées par le rôle Ansible du Crans
-
+<https://gitlab.crans.org/nounous/ansible/-/tree/newinfra/roles/belenios>.
 Il prend en configuration le nom de domaine utilisé (``belenios.domain``), des adresses mails de contact (``belenios.email_contact`` et ``belenios.email_from``) ainsi que les paramètres du CAS (``belenios.cas.name`` et ``belenios.cas.server``, voir ci-dessous).
 Il prend en configuration le nom de domaine utilisé (``belenios.domain``), des
 adresses mails de contact (`belenios.email_contact` et `belenios.email_from`)
 ainsi que les paramètres du CAS (`belenios.cas.name` et `belenios.cas.server`,
 voir ci-dessous).
 ## Utilisation
-Toute personne ayant un compte Crans peut créer une élection sur Belenios en se connectant via le CAS du Crans. Cela se configure sur la ligne du fichier de configuration ocsigenserver :
+Toute personne ayant un compte Crans peut créer une élection sur Belenios en
 se connectant via le CAS du Crans. Cela se configure sur la ligne du fichier de
 configuration ocsigenserver :
 ```xml
 <auth name="{{ belenios.cas.name }}"><cas server="{{ belenios.cas.server }}"/></auth>
 ```
-On peut remplacer le nom par ``CAS Cr@ns`` et le serveur par `<https://cas.crans.org/>`.
+On peut remplacer le nom par ``CAS Cr@ns`` et le serveur par
 <https://cas.crans.org/>.
 Une fois connecté, on peut créer et administrer une élection.
@ -175,32 +200,49 @@ Une fois connecté, on peut créer et administrer une élection.
 Belenios propose deux modes pour gérer les mots de passe :
- * Automatique (mode dégradé : les codes de vote seront générés par le serveur)
+* Automatique (mode dégradé : les codes de vote seront générés par le
- * Manuel (mode sécurisé : un tiers se chargera des codes de vote)
+  serveur)
-Dans le premier mode, Belenios se charge de générer les codes de vote et les envoie lui-même par mail.
+* Manuel (mode sécurisé : un tiers se chargera des codes de vote)
 Dans le second mode, recommandé, c'est vous qui envoyez vous même les codes de vote aux électeurs.
-Le code de vote ne servant qu'à débuter l'élection pour une personne, la sécurité ne réside pas ici. C'est plus ou moins l'équivalent de donner son nom au bureau de vote. Ce n'est pas une information sensible. À la fin du vote on demande aux votants de réellement s'identifier avant de glisser les bulletins dans l'urne. On dispose de deux moyens d'authentification :
+Dans le premier mode, Belenios se charge de générer les codes de vote et les
 envoie lui-même par mail. Dans le second mode, recommandé, c'est vous qui
 envoyez vous même les codes de vote aux électeurs.
- * Générer des mots de passe confidentiels (hashés sur le serveur) par personne, géré par Belenios ;
+Le code de vote ne servant qu'à débuter l'élection pour une personne, la
- * Utiliser un CAS.
+sécurité ne réside pas ici. C'est plus ou moins l'équivalent de donner son
 nom au bureau de vote. Ce n'est pas une information sensible. À la fin du vote
 on demande aux votants de réellement s'identifier avant de glisser les
 bulletins dans l'urne. On dispose de deux moyens d'authentification :
-Il va de soi qu'on vous recommande la deuxième option. Cela peut être n'importe quel serveur CAS, pas nécessairement celui du Crans. Par exemple, on utilisera `<https://cas.crans.org/>` pour le Crans, `<https://note.crans.org/cas>` pour la Note Kfet, ou `<https://cas.inria.fr/cas>` pour celui de l'Inria.
+* Générer des mots de passe confidentiels (hashés sur le serveur) par
  personne, géré par Belenios ;
-Pensez bien à autoriser Belenios à utiliser votre serveur CAS, et à faire attention à ce que les pseudos renvoyés soient en ASCII !
+* Utiliser un CAS.
-Plus d'informations ici : `<https://www.belenios.org/setup.html>`
+Il va de soi qu'on vous recommande la deuxième option. Cela peut être
 n'importe quel serveur CAS, pas nécessairement celui du Crans. Par exemple, on
 utilisera <https://cas.crans.org/> pour le Crans,
 <https://note.crans.org/cas> pour la Note Kfet, ou
 <https://cas.inria.fr/cas> pour celui de l'Inria.
 Pensez bien à autoriser Belenios à utiliser votre serveur CAS, et à faire
 attention à ce que les pseudos renvoyés soient en ASCII !
 Plus d'informations ici : <https://www.belenios.org/setup.html>.
 ### Inscription des électeurs
-La liste des électeurs doit être arrêtée avant la création de l'élection. La liste doit être donnée sous la forme ``ADRESSE@EMAIL,PSEUDO``.
+La liste des électeurs doit être arrêtée avant la création de l'élection.
 La liste doit être donnée sous la forme `ADRESSE@EMAIL,PSEUDO`.
-Depuis la dernière version, il est également définir un poids par électeur.
+Depuis la dernière version, il est également possible de définir un poids par
 électeur.
 **Atention :**
-Belenios ne supporte pas l'UTF-8 dans les pseudos. Assurez-vous de garder des pseudos ASCII. Et dans les adresses e-mail, mais cela va de soi.
+Belenios ne supporte pas l'UTF-8 dans les pseudos. Assurez-vous de garder des
 pseudos ASCII. Et dans les adresses e-mail, mais cela va de soi.
 #### Générer la liste des adhérents avec Re2o
@ -210,23 +252,39 @@ Pas besoin de plus d'une ligne :
 "\n".join(map(lambda user: f"{user.get_mail},{user.pseudo}", utils.all_adherent(including_asso=False).filter(adherent__isnull=False)))
 ```
-C'est faux : il faut importer ```utils``` et sans doute écrire dans un fichier.
+C'est faux : il faut importer `utils` et sans doute écrire dans un fichier.
 ### Déclaration des autorités de déchiffrement
-Il s'agit de l'équivalent des assesseurs qui vont contrôler et dépouiller l'élection. Il peut y en avoir plusieurs. Chacun aura sa clé, et la clé sera nécessaire pour le dépouillement. Dans tous les cas, Belenios lui-même est une autorité de déchiffrement mais il est recommandé d'avoir une autorité extérieure.
+Il s'agit de l'équivalent des assesseurs qui vont contrôler et dépouiller
 l'élection. Il peut y en avoir plusieurs. Chacun aura sa clé, et la clé sera
 nécessaire pour le dépouillement. Dans tous les cas, Belenios lui-même est
 une autorité de déchiffrement mais il est recommandé d'avoir une autorité
 extérieure.
 **IMPORTANT :**
-Cela tient plus du mauvais pressentiment que de l'expérience, mais pensez bien à VRAIMENT conserver la clé privée en lieu sûr, elle n'est pas récupérable. Jeter sa clé privée, c'est comme acheter une urne en verre incassable avec une serrure qui tient le coup et jeter le trousseau dans les égouts, en veillant à la fondre et la broyer avant. Vous pourrez ajouter des bulletins dans l'urne mais jamais la dépouiller.
+Cela tient plus du mauvais pressentiment que de l'expérience, mais pensez bien
 à VRAIMENT conserver la clé privée en lieu sûr, elle n'est pas
 récupérable. Jeter sa clé privée, c'est comme acheter une urne en verre
 incassable avec une serrure qui tient le coup et jeter le trousseau dans les
 égouts, en veillant à la fondre et la broyer avant. Vous pourrez ajouter des
 bulletins dans l'urne mais jamais la dépouiller.
 ### Élection
-Une fois l'élection créée, il n'est plus possible de la modifier, ce qui est normal. Il est possible de définir les horaires d'ouverture de l'élection (attention : les horaires sont sur le fuseau UTC !).
+Une fois l'élection créée, il n'est plus possible de la modifier, ce qui est
-
+normal. Il est possible de définir les horaires d'ouverture de l'élection
-Pour voter, chaque participant doit présenter son code d'élection, voter pour chacune des questions, puis soumettre son bulletin en s'authentifiant via le moyen défini. Son bulletin est ensuite chiffré et enregistré. Il est possible de revoter autant de fois que nécessaire, chaque vote annulant le précédent.
+(attention : les horaires sont sur le fuseau UTC !).
 Pour voter, chaque participant doit présenter son code d'élection, voter pour
 chacune des questions, puis soumettre son bulletin en s'authentifiant via le
 moyen défini. Son bulletin est ensuite chiffré et enregistré. Il est possible
 de revoter autant de fois que nécessaire, chaque vote annulant le précédent.
 ### Dépouillement
-Après l'élection, et pas avant (ce qui n'est de toute façon pas possible), chaque autorité de déchiffrement doit soumettre sa clé privée pour ouvrir l'urne. Une fois cela fait, les résultats sont publics sur la page de l'élection.
+Après l'élection, et pas avant (ce qui n'est de toute façon pas possible),
 chaque autorité de déchiffrement doit soumettre sa clé privée pour ouvrir
 l'urne. Une fois cela fait, les résultats sont publics sur la page de
 l'élection.
--- a/services/borg.md
+++ b/services/borg.md
@ -1,4 +1,5 @@
 # Borg
 Pour prevenir certains incidents dus à des erreurs de manipulation, le collège
 technique a mis en place en système de backups. Le but de celui-ci est de
 pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé
@ -42,11 +43,14 @@ on se retrouvera avec une taille beaucoup plus raisonnable de sauvegarde. C'est
 ~la déduplication.
 ## Qu'est ce que l'on sauvegarde ?
 Au crans, on sauvegarde deux types de données :
-  - D'un côté, on a les données d'administration, c'est une partie des disques
+
 * D'un côté, on a les données d'administration, c'est une partie des disques
  de tous les serveurs (généralement le /etc et le /var sauf cas particulier),
  le home des nounous, les bases de données…
-  - De l'autre côté; on a les données des adhérents, c'est à dire : le contenu
+
 * De l'autre côté; on a les données des adhérents, c'est à dire : le contenu
  de leur répertoire personnel et de leur dossier mail qui au jour où j'écris
  ses lignes peut contenir au maximum 30G et 10G de données respectivement.
@ -58,15 +62,18 @@ utilisation assez normale du logiciel. L'explication de comment se passe les
 sauvegardes pour les données adhérents est disponible [ici](services/borg.md).
 ## Borg et borgmatic
 Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes
 incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à
 installer et utilise ssh comme protocole de transport entre lui et le client.
 Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui
 autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le
 `.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups :
-```
+
 ```txt
 command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }}
 ```
 Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur
 et le reste du travail sera réalisé par le client. Après avoir aussi installé
 `borg` sur le client, on peut déjà commencer à faire quelques sauvegardes.
@ -84,7 +91,8 @@ officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici,
 je vais plus chercher à vous donner quelques options minimales et des exemples
 d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de
 configuration partiel :
-```
+
 ```txt
 location:
    source_directories:
        - /etc
@ -118,32 +126,39 @@ que je ne détaillerais pas ici, il est maintenant possible de commencer à
 utiliser le logiciel et faire nos premières sauvegardes.
 ### Créer l'archive de stockage
 La commande suivante permet de créer l'archive où seront stockées les
 sauvegardes sur le serveur.
-```
+
-$ borgmatic init -e repokey
+```bash
 borgmatic init -e repokey
 ```
 ### Faire une première sauvegarde
 Pour faire une sauvegarde, rien de plus simple, on appelle simplement le
 programme borgmatic sans option. Il est néanmoins possible de demander un
 affichage plus verbeux pour le débogage.
-```
+
-$ borgmatic
+```bash
-$ borgmatic -v 2
+borgmatic
 borgmatic -v 2
 ```
 ### Lister les différentes sauvegardes dans l'archive
-```
+
-$ borgmatic list
+```bash
 borgmatic list
 ```
 ### Monter une sauvegarde précise sur un point de montage
-```
+
-$ borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }}
+```bash
-$ borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf
+borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }}
 borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf
 ```
 ### Automatiser les backups
 Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou
 à systemd à l'aide d'un timer.
--- a/services/framadate.md
+++ b/services/framadate.md
@ -1,50 +1,74 @@
 # Framadate
 Framadate est un software qui permet de faire un choix commun entre plusieurs
 options depuis un navigateur web.
 ## Installation
 Pour installer le logiciel, on clone le dépot du projet depuis le serveur gitlab
-de framadate : `git clone https://framagit.org/framasoft/framadate/framadate.git
+de framadate :
-b 1.1.11 /var/www/framadate`. Il est aussi nécessaire de tirer quelques
+
-dépendances à la main : `sudo apt install php-fpm php-intl php-mbstring
+```bash
-php-mysql composer`. On utilise ensuite composer pour installer les
+git clone https://framagit.org/framasoft/framadate/framadate.git -b 1.1.11 /var/www/framadate
-dépéndances php `cd /var/www/framadate; sudo -u www-data composer install`. On
+```
-créée le fichier de log à la main `sudo -u www-data touch
+
-/var/www/framadate/admin/stdout.log; sudo chmod 0600
+Il est aussi nécessaire de tirer quelques
-/var/www/framadate/admin/stdout.log`.
+dépendances à la main :
 ```bash
 sudo apt install php-fpm php-intl php-mbstring php-mysql composer
 ```
 On utilise ensuite composer pour installer les
 dépéndances php `cd /var/www/framadate; sudo -u www-data composer install`.
 On créée le fichier de log à la main
 ```bash
 sudo -u www-data touch /var/www/framadate/admin/stdout.log; sudo chmod 0600 /var/www/framadate/admin/stdout.log
 ```
 ## Configuration de la base de données
 Le logiciel a besoin d'une base de donnée, ici on a pas le choix et on doit
-utiliser une base de données mysql qu'on installera donc en local:
+utiliser une base de données mysql qu'on installera donc en local :
 `sudo apt install mariadb`. Dans laquelle on crééra (via le shell mysql `sudo mysql`):
-  - `CREATE USER 'framadate'@'localhost' WITH PASSWORD 'ploptoto';` un
+
 * `CREATE USER 'framadate'@'localhost' WITH PASSWORD 'ploptoto';` un
  utilisateur framadate
-  - `CREATE DATABASE framadate;` une base de données éponyme
+
-  - `GRANT ALL PRIVILEGES ON DATABASE framadate to 'framadate'@'localhost';` sur
+* `CREATE DATABASE framadate;` une base de données éponyme
 * `GRANT ALL PRIVILEGES ON DATABASE framadate to 'framadate'@'localhost';` sur
  laquelle on donnera tous les droits à l'utilisateur framadate
 ## Configuration du logiciel
 Le fichier de configuration du logiciel est trouvable dans
 `/var/www/framadate/app/inc/config.php`. Le fichier de configuration a des
 défauts plutôt sains mais il y a quand meme quelques options de configuration à
 préciser :
-  - pour la connexion à la base de donnée :
+
-```
+* pour la connexion à la base de donnée :
-// Database server name, leave empty to use a socket
+
-const DB_CONNECTION_STRING = 'mysql:host=localhost;dbname=framadate;port=3306';
+  ```txt
-// Database user
+  // Database server name, leave empty to use a socket
-const DB_USER= 'framadate';
+  const DB_CONNECTION_STRING = 'mysql:host=localhost;dbname=framadate;port=3306';
-// Database password
+  // Database user
-const DB_PASSWORD = 'ploptoto';
+  const DB_USER= 'framadate';
-```
+  // Database password
-  - pour le serveur smtp, on authorise l'envoir de mail `'use_smtp' => true`,
+  const DB_PASSWORD = 'ploptoto';
  ```
 * pour le serveur smtp, on authorise l'envoir de mail `'use_smtp' => true`,
  on précise le serveur smtp auquel se connecter `'port' => 25` et la source
  des mails : `const ADRESSEMAILREPONSEAUTO = 'framadate@crans.org';`
 ## Configuration nginx
 Il faut maintenant configurer nginx et protéger l'accès à la zone
 d'administration par mot de passe.
 ## Migrations
 Il ne reste plus qu'à effectuer les migrations dans la section d'administrations
 du site `https://framadate.crans.org/admin/migrations.php`
--- a/services/galene.md
+++ b/services/galene.md
@ -1,40 +1,82 @@
 # Galène, visio-conférence
-Galène est un logiciel de visio-conférence écrit en Golang (pure) sous licence MIT.
+Galène est un logiciel de visio-conférence écrit en Golang (pure) sous
-Il s'appuie sur le standard Web W3C WebRTC afin de connecter plusieurs navigateurs Web ensembles pour réaliser des visio-conférences.
+licence MIT. Il s'appuie sur le standard Web W3C WebRTC afin de connecter
 plusieurs navigateurs Web ensembles pour réaliser des visio-conférences.
 Site officiel : <https://galene.org/>
-Il est trivial à installer sur tous les systèmes d'exploitation en suivant le fichier `INSTALL` du dépôt de code. Il suffit d'avoir Golang et d'ouvrir le parefeu correctement.
+Il est trivial à installer sur tous les systèmes d'exploitation en suivant le
 fichier `INSTALL` du dépôt de code. Il suffit d'avoir Golang et d'ouvrir le
 parefeu correctement.
 ## Acronymes
-L'audio-visuel est un domaine remplie d'acronymes. Pour le bien être des futurs responsables techniques qui s'arracheront les cheveux en essayant de debugguer Galène, voici une liste partielle d'acronymes :
+L'audio-visuel est un domaine remplie d'acronymes. Pour le bien être des
 futurs responsables techniques qui s'arracheront les cheveux en essayant de
 debugguer Galène, voici une liste partielle d'acronymes :
-  * **WebRTC** : Web Real Time Communication. Protocole permettant aux navigateurs Web de gérer des flux UDP. Utilisé par exemple par WebTorrent pour réaliser du Torrent, ou par toutes les applications classiques de visio-conférences. Le chiffrement est forcé dans le standard.
+* **WebRTC** : Web Real Time Communication. Protocole permettant aux
-  * **HLS** : HTTP Live Streaming. Le principe consiste à découper un flux vidéo en segments et d'exposer ces segments sur un serveur HTTP. En 2021, le HLS est utilisé par PeerTube (sur du WebTorrent), Twitch et YouTube.
+  navigateurs Web de gérer des flux UDP. Utilisé par exemple par WebTorrent
-  * **SRT** : ce n'est pas le standard de sous-titre `.srt`, mais un protocole libre qui a pour but de remplacer `RTMP` (qui est un stream de fichier FLV, héritage de Flash Player).
+  pour réaliser du Torrent, ou par toutes les applications classiques de
-  * **RTP** : Real Time Protocol, standard audio-visuel initialement pour le téléphone SIP, VoIP, VoLTE (appels sur 4G) et la Télévision Digitale (IPTV).
+  visio-conférences. Le chiffrement est forcé dans le standard.
-  * **DTLS-SRTP** : Secure Real Time Protocol avec un chiffrement standardisé.
+
-  * **SFU** : Selective Forwarding Unit. Galène est un SFU, il reçoit des flux de plusieurs navigateurs Web et les redistribue selon des salons et permissions.
+* **HLS** : HTTP Live Streaming. Le principe consiste à découper un flux
-  * **Pion** : la librarie Golang pour utiliser WebRTC. Utilisé par Galène.
+  vidéo en segments et d'exposer ces segments sur un serveur HTTP. En 2021, le
-  * **TURN** : Traversal Using Relays around NAT. Serveur intermédiaire (proxy) pour traverser un parefeu trop limitant.
+  HLS est utilisé par PeerTube (sur du WebTorrent), Twitch et YouTube.
-  * **STUN** : Session Traversal Utilities for NAT. Serveur permettant de réfléchir les adresse IP publiques d'un utilisateur et de taper sur son parefeu de l'extérieur. Un TURN contient un STUN.
+
-  * **ICE** : Interactive Connectivity Establishment. Procédure pour trouer des parefeux (en utilisant des STUN et TURN) et ouvrir des flux UDP entre des machines distantes.
+* **SRT** : ce n'est pas le standard de sous-titre `.srt`, mais un protocole
-  * **VP8/VP9/AV1** : Codecs vidéos royalty-free développés par Google. Ils sont intégrés dans le code source de Chromium et Firefox. AV1 est le successeur de VP9 qui est le successeur de VP8. AV1 est un codec vidéo adaptatif.
+  libre qui a pour but de remplacer `RTMP` (qui est un stream de fichier FLV,
-  * **Opus** : Codec audio libre intégré dans le code source des navigateurs Web. Il est très performant pour coder de la musique ou de la voix. Il hérite de SILK qui est le codec historique de Skype.
+  héritage de Flash Player).
-  * **H264/H265** : Codecs non royalty-free (bouh!) poussés par la fondation MPEG et Apple. Les vielles versions de Safari ne supportent que ces codecs.
+
 * **RTP** : Real Time Protocol, standard audio-visuel initialement pour le
  téléphone SIP, VoIP, VoLTE (appels sur 4G) et la Télévision Digitale (IPTV).
 * **DTLS-SRTP** : Secure Real Time Protocol avec un chiffrement standardisé.
 * **SFU** : Selective Forwarding Unit. Galène est un SFU, il reçoit des
  flux de plusieurs navigateurs Web et les redistribue selon des salons et
  permissions.
 * **Pion** : la librarie Golang pour utiliser WebRTC. Utilisé par Galène.
 * **TURN** : Traversal Using Relays around NAT. Serveur intermédiaire
  (proxy) pour traverser un parefeu trop limitant.
 * **STUN** : Session Traversal Utilities for NAT. Serveur permettant de
  réfléchir les adresse IP publiques d'un utilisateur et de taper sur son
  parefeu de l'extérieur. Un TURN contient un STUN.
 * **ICE** : Interactive Connectivity Establishment. Procédure pour trouer
  des parefeux (en utilisant des STUN et TURN) et ouvrir des flux UDP entre des
  machines distantes.
 * **VP8/VP9/AV1** : Codecs vidéos royalty-free développés par Google. Ils
  sont intégrés dans le code source de Chromium et Firefox. AV1 est le
  successeur de VP9 qui est le successeur de VP8. AV1 est un codec vidéo
  adaptatif.
 * **Opus** : Codec audio libre intégré dans le code source des navigateurs
  Web. Il est très performant pour coder de la musique ou de la voix. Il hérite
  de SILK qui est le codec historique de Skype.
 * **H264/H265** : Codecs non royalty-free (bouh!) poussés par la fondation
  MPEG et Apple. Les vielles versions de Safari ne supportent que ces codecs.
 ## How to debug
-Le mieux est d'utiliser Firefox pour débugger le WebRTC car leur interface est plus intuitive.
+Le mieux est d'utiliser Firefox pour débugger le WebRTC car leur interface est
-Sur Firefox vous pouvez ouvrir `about:webrtc` et sur Chromium `chrome://webrtc-internals`.
+plus intuitive. Sur Firefox vous pouvez ouvrir `about:webrtc` et sur Chromium
 `chrome://webrtc-internals`.
-Souvent ce qui casse c'est l'ICE et la connexion met soit beaucoup de temps à s'établir, ou ne s'établit pas. Le tableau décrivant l'ICE dans Firefox est utile car il donne les raisons des fails.
+Souvent ce qui casse c'est l'ICE et la connexion met soit beaucoup de temps à
 s'établir, ou ne s'établit pas. Le tableau décrivant l'ICE dans Firefox est
 utile car il donne les raisons des fails.
 ## Faire gaffe à la sécurité
-Un TURN est un proxy. Il faut donc s'assurer qu'il ne permet pas d'accéder aux réseaux d'administration à partir de l'extérieur.
+Un TURN est un proxy. Il faut donc s'assurer qu'il ne permet pas d'accéder aux
-
+réseaux d'administration à partir de l'extérieur.
 Voir <https://www.rtcsec.com/article/slack-webrtc-turn-compromise-and-bug-bounty/>.
 Voir
 <https://www.rtcsec.com/article/slack-webrtc-turn-compromise-and-bug-bounty/>.
--- a/services/irc/inspircd.md
+++ b/services/irc/inspircd.md
@ -1,13 +1,22 @@
 # InspIRCd
-InspIRCd est un logiciel serveur implémentant le [protocole IRC](/tools/irc.md) ses sources sont disponibles sur [GitHub](https://github.com/inspircd/inspircd).
+
 InspIRCd est un logiciel serveur implémentant le
 [protocole IRC](../../outils/irc.md) ses sources sont disponibles sur
 [GitHub](https://github.com/inspircd/inspircd).
 Ce serveur est déployé sur la VM `irc` et est joignable sur `irc.crans.org`.
-InspIRCd est modulaire : la majorité de ses fonctionnalités sont fournies pas des modules qui peuvent être activés ou désactivés.
+InspIRCd est modulaire : la majorité de ses fonctionnalités sont fournies pas
 des modules qui peuvent être activés ou désactivés.
-Voici la liste (en anglais) des modes supportés par InspIRCd, la plupart d'entre eux sont fournis par des modules chargés au Crans. La liste des modules chargés peut être consulté dans l'Ansible ou dans `/etc/inspircd` sur la VM `irc`.
+Voici la liste (en anglais) des modes supportés par InspIRCd, la plupart
 d'entre eux sont fournis par des modules chargés au Crans. La liste des
 modules chargés peut être consulté dans l'Ansible ou dans `/etc/inspircd`
 sur la VM `irc`.
 InspIRCd est compilé directement sur la VM `irc`, ses sources se trouvent dans
 `/root/inspircd`. La procédure pour la compilation est la suivante :
 InspIRCd est compilé directement sur la VM `irc`, ses sources se trouvent dans `/root/inspircd`. La procédure pour la compilation est la suivante :
 ```bash
 git pull
 git checkout tags/${VERSION}
@ -39,8 +48,8 @@ InspIRCd supports 5 types of modes :
 | `c`       | blockcolor    | Switch        |                     | Channel operators | blockcolor | Enables blocking messages that contain IRC formatting codes. |
 | `D`       | delayjoin     | Switch        |                     | Channel operators | delayjoin | Prevents users from receiving `JOIN` messages until the joining user speaks. |
 | `d`       | delaymsg      | Parameter     | seconds             | Channel operators | delaymsg | Prevents newly joined users from speaking until &lt;seconds&gt; seconds have passed. |
-| `E`       | repeat        | Parameter     | (~\|*)lines:seconds | Channel operators | repeat | Configures the messages that should be considered a repeat. If prefixed with ~ the messages are blocked. If prefixed with * then offending users are banned. If not prefixed then offending users are kicked. |
+| `E`       | repeat        | Parameter     | (~/*)lines:seconds | Channel operators | repeat | Configures the messages that should be considered a repeat. If prefixed with `~` the messages are blocked. If prefixed with `*` then offending users are banned. If not prefixed then offending users are kicked. |
-| `e`       | banexception  | List          | mask                | Channel operators | banexception | Exempts users matching &lt;mask&gt; from the `b` (ban) channel mode.
+| `e`       | banexception  | List          | mask                | Channel operators | banexception | Exempts users matching &lt;mask&gt; from the `b` (ban) channel mode. |
 | `F`       | nickflood     | Parameter     | changes:seconds     | Channel operators | nickflood | Prevents more than &lt;changes&gt; nickname changes in the last &lt;seconds&gt; seconds. |
 | `f`       | flood         | Parameter     | (*)lines:seconds    | Channel operators | messageflood | Kicks users who send more than &lt;lines&gt; messages in the last &lt;seconds&gt; seconds. If prefixed with * then offending users are also banned. |
 | `g`       | filter        | List          | glob                | Channel operators | chanfilter | Prevents users from sending messages that match &lt;glob&gt;. |
@ -98,4 +107,3 @@ InspIRCd supports 5 types of modes :
 | `w`       | wallops         | Switch        |                  | Anyone           |        | Enables receiving `WALLOPS` messages from server operators. |
 | `x`       | cloak           | Switch        |                  | Anyone           | cloaking | Enables hiding of the user's hostname. |
 | `z`       | sslqueries      | Switch        |                  | Anyone           | sslmodes | Prevents messages from being sent to or received from a user that is not connected using TLS (SSL). |
--- a/services/jupyter.md
+++ b/services/jupyter.md
@ -1,29 +1,48 @@
 # Jupyter notebook, édition et exécution de code python à distance.
-https://jupyter.org/
+
 <https://jupyter.org/>
 ## Utilisation par un.e adhérent.e sur zamok
-On commence par créer le dossier "racine" de nos notebooks, normalement jupyter ne pourra pas accéder aux fichiers en dehors de ce dossier.
+
-```
+On commence par créer le dossier "racine" de nos notebooks, normalement
 jupyter ne pourra pas accéder aux fichiers en dehors de ce dossier.
 ```bash
 mkdir jupyter
 cd jupyter
 ```
-On va ensuite créer en environement virtuel python dans lequel il faut installer le package `notebook` ainsi que tous les packages nécessaires à l'exécution de notre code (par exemple `pandas`, `numpy` ou `matplotlib`).
+
-```
+On va ensuite créer en environement virtuel python dans lequel il faut
 installer le package `notebook` ainsi que tous les packages nécessaires à
 l'exécution de notre code (par exemple `pandas`, `numpy` ou `matplotlib`).
 ```bash
 python3 -m venv env
 source env/bin/activate
 pip install notebook
 ```
-On peut ensuite lancer le serveur jupyter notebook avec: `jupyter notebook`._
+
 On peut ensuite lancer le serveur jupyter notebook avec: `jupyter notebook`.
 Quelques lignes de logs devraient apparaitre dont:
-```
+
 ```txt
 To access the server, open this file in a browser:
    file:///home/paulon/.local/share/jupyter/runtime/jpserver-3662553-open.html
 Or copy and paste one of these URLs:
    http://localhost:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5
    http://127.0.0.1:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5
 ```
-On peut donc maintenant faire du port forwarding avec ssh pour accéder depuis sa machine au port utilisé par jupyter sur zamok:
+
-```
+On peut donc maintenant faire du port forwarding avec ssh pour accéder depuis
 sa machine au port utilisé par jupyter sur zamok :
 ```bash
 ssh -L <port local>:localhost:<port dans l'url de jupyter> zamok.crans.org
 ```
-On va partir du principe qu'on utilise le même port dans les deux cas, ici `8888` en faisant donc `ssh -L 8888:localhost:8888 zamok.crans.org`.\
+
-On peut alors juste copier coller l'adresse dans notre navigateur: <http://localhost:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5> et voilà!
+On va partir du principe qu'on utilise le même port dans les deux cas, ici
 `8888` en faisant donc `ssh -L 8888:localhost:8888 zamok.crans.org`.
 On peut alors juste copier coller l'adresse dans notre navigateur :
 <http://localhost:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5>
 et voilà!
--- a/services/linx.md
+++ b/services/linx.md
@ -1,21 +1,24 @@
 # Linx
 Linx est un logiciel d'hébèrgement temporaire et de partages de fichiers.
 ## Installation
-Pour installer le logiciel, on commence par installer go sur le serveur, `apt 
+
-install golang`. Puis on télécharge l'une des 
+Pour installer le logiciel, on commence par installer go sur le serveur,
 `apt install golang`. Puis on télécharge l'une des
 [https://github.com/andreimarcu/linx-server/releases](releases) du logiciel.
 On peut enfin installer le logiciel en faisant `go install` sur la le fichier
 téléchargé.
 ## Configuration
 La configuration du logiciel est relativement peut et il est laissé à
-l'utilisateur le choix de où il souhaite la placer. On propose ici de la mettre 
+l'utilisateur le choix de où il souhaite la placer. On propose ici de la
-dans `/etc/linx/server.conf`. Dans le fichier, on va préciser, l'adresse du 
+mettre dans `/etc/linx/server.conf`. Dans le fichier, on va préciser, l'adresse
-serveur, le port et l'ip à laquelle il va s'attacher, la taille maximale des 
+du serveur, le port et l'ip à laquelle il va s'attacher, la taille maximale des
 fichiers, leur temps de rétention et leur emplacements sur le disque.
-```
+```txt
 bind = 172.16.10.119:8080
 sitename = CRANS Linx
 siteurl = https://linx.crans.org/
@ -29,11 +32,12 @@ Pour vérifier que cela fonctionne, on peut maintenant lancé le logiciel en
 faisant `linx-server -config /etc/systemd/system/linx-server.conf`.
 ## Service systemd
 Pour que le logiciel puisse se lancer automatiquement au démarrage du serveur,
 on va placer un fichier d'unit systemd dans
 `/etc/systemd/system/linx-server.service`.
-```
+```txt
 [Unit]
 Description=Linx
 After=network.target
--- a/services/mail/autoconfig.md
+++ b/services/mail/autoconfig.md
@ -3,9 +3,9 @@
 Dans le protocole mail, la configuration du client mail est généralement laissé
 à la charge du client. C'est à lui de savoir à quels serveurs il souhaite se
 connecter, sur quels ports et en précisant le mécanisme ainsi que les
-informations d'authentification. Cependant ces informations n'étant pas toujours
+informations d'authentification. Cependant ces informations n'étant pas
-facilement accessible à l'utilisateur, thunderbird a mis en place une manière
+toujours facilement accessible à l'utilisateur, thunderbird a mis en place une
-externe par laquelle le client peut récupérer toutes les informations
+manière externe par laquelle le client peut récupérer toutes les informations
 nécessaires à sa configuration de tels sortes que l'utilisateur n'ait qu'à
 fournir son adresse mail et son mot de passe.
@ -14,17 +14,21 @@ fournir son adresse mail et son mot de passe.
 Attention, ce mécanisme de création de compte n'est pour le moment normalisé
 dans aucune RFC, c'est le client mail qui choisit sa propre implementation du
 mécanisme. Il est donc complètement possible que
-    1. le client n'implémente pas du tout le mécanisme ou qu'il n'en implémente
+
 1. le client n'implémente pas du tout le mécanisme ou qu'il n'en implémente
   qu'une partie
-    2. deux clients différents n'aient pas la même implémentation du mécanisme
+
 1. deux clients différents n'aient pas la même implémentation du mécanisme
 Quand on lui fournit une adresse mail de la forme `utilisateur@domain.tld`, le
 client va essayer de récupérer le contenu de l'uri suivante
-`http://autoconfig.domain.tld/mail/config-v1.1.xml` qui est un fichier xml assez
+`http://autoconfig.domain.tld/mail/config-v1.1.xml` qui est un fichier xml
-simple qui décrit en quelques lignes une configuration que le client peut
+assez simple qui décrit en quelques lignes une configuration que le client
-adopter. Une référence complète de sa syntaxe est trouvable à l'adresse suivante :
+peut adopter. Une référence complète de sa syntaxe est trouvable à
-`https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat`. Voilà
+l'adresse suivante :
-une configuration minimale dans le cas du crans :
+<https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat>.
 Voilà une configuration minimale dans le cas du crans :
 ```xml
 <clientConfig version="1.0">
  <emailProvider id="crans.org">
@ -50,17 +54,19 @@ une configuration minimale dans le cas du crans :
 ```
 Le fichier de configuration se lit assez bien, on dit à l'utilisateur de faire
-  - du smtp pour envoyer des mails en se connectant avec une connexion chiffrée
+
 * du smtp pour envoyer des mails en se connectant avec une connexion chiffrée
  à `redisdead.crans.org` sur le port `465` et en utilisant la partie locale
  de son adresse mail (le `user` dans `user@domain.tld`) comme nom
  d'utilisateur et en utilisant le mode d'authentification ~~plain~~ LOGIN
  (voir la suite)
-  - du imap pour recevoir les mails en se connectant avec une connexion STARTTLS
+
 * du imap pour recevoir les mails en se connectant avec une connexion STARTTLS
  à `owl.crans.org` sur le port `993` et en utilisant la partie locale de son
  adresse mail comme nom d'utilisateur et en utilisant le mode
  d'authentification ~~plain~~ LOGIN
-La plupart des clients mails interprète l'utilisation du mot clé `plain` comme
+La plupart des clients mails interprète l'utilisation du mot clé `plain`
-étant le méchanisme `login` du protocole SASL et non le méchanisme `plain` de ce
+comme étant le méchanisme `login` du protocole SASL et non le méchanisme
-même protocole. Au crans, les deux méthodes d'authentification étant supporté,
+`plain` de ce même protocole. Au crans, les deux méthodes d'authentification
-cela ne pose pas de soucis.
+étant supporté, cela ne pose pas de soucis.
--- a/services/mail/dovecot.md
+++ b/services/mail/dovecot.md
@ -1,27 +1,32 @@
 # Dovecot
 Dovecot est entre autre une implémentation de serveur IMAP, de serveur POP3 et
-de serveur d'authentification SASL. Les deux premiers protocoles permettent à un 
+de serveur d'authentification SASL. Les deux premiers protocoles permettent à
-utilisateur de consulter ces mails (soit en les consultant sur le serveur pour 
+un utilisateur de consulter ces mails (soit en les consultant sur le serveur
-IMAP, soit en les téléchargeant localement pour POP3) tandis que le dernier sert 
+pour IMAP, soit en les téléchargeant localement pour POP3) tandis que le
-à authentifié l'utilisateur, authentification qui pourra être utilisé par 
+dernier sert à authentifié l'utilisateur, authentification qui pourra être
-d'autre logiciels comme par exemple postfix pour vérifier l'idendité d'une 
+utilisé par d'autre logiciels comme par exemple postfix pour vérifier
-personne souhaitant envoyer un mail.
+l'idendité d'une  personne souhaitant envoyer un mail.
 ## Installation
-On tire les différents composants logiciels des repository debian : `sudo apt 
+
-install dovecot-imapd dovecot-ldap dovecot-pop3d dovecot-sieve`
+On tire les différents composants logiciels des repository debian :
 `sudo apt install dovecot-imapd dovecot-ldap dovecot-pop3d dovecot-sieve`.
 ## Configuration
 La configuration initiale packagée par debian est morcellée en une série de
 fichier commentée dans `/etc/dovecot/conf.d` qui permette de segmenter la
 configuration en fonction des différents mécanismes du logiciel.
 ### 10-auth.conf
-Ce fichier contrôle l'authentification des utilisateurs au serveur. On configure 
+
-dans le fichier directement les options de connexions puis en incluant des 
+Ce fichier contrôle l'authentification des utilisateurs au serveur. On
-fichiers 'auth-{{ mecanisme }}.conf.ext' on précise les différents bas 
+configure dans le fichier directement les options de connexions puis en
-d'utilisateurs et de mot de passe à utiliser.
+incluant des fichiers `auth-{{ mecanisme }}.conf.ext` on précise les
-```
+différents bas d'utilisateurs et de mot de passe à utiliser.
 ```txt
 # On autorise les clients à utiliser une authentification en claire car on
 # configurera par la suite le fait que tous les échanges entre le client
 # et le serveur soient chiffrées par TLS.
@ -35,7 +40,8 @@ auth_mechanisms = plain login
 Le fichier `auth-ldap.conf.ext` va lui même inclure le fichier de configuration
 de connexion au ldap.
-```
+
 ```txt
 # Addresse du serveur ldap
 uris = ldap://172.16.10.157/
 # Nom d'utilisateur et mot de passe utilisés pour s'authentifer auprès du
@ -56,10 +62,12 @@ pass_attrs = uid=user,userPassword=password
 ```
 ### 10-logging.conf
 C'est le fichier de configuration qui gère l'écriture des logs du daemon. Il
 permet de séléctionner quels événèments doivent être loggé et quels champs de
 l'objet doivent être inclus dans les logs.
-```
+
 ```txt
 plugin {
  mail_log_events = delete undelete expunge copy mailbox_delete mailbox_renam
  mail_log_fields = uid box msgid size
@ -68,9 +76,11 @@ log_timestamp = "%Y-%m-%d %H:%M:%S "
 ```
 ### 10-mail.conf
 Dans ce fichier de configuration on définit les boites mails avec lesquels
-deovecot va travailler.
+dovecot va travailler.
-```
+
 ```txt
 # Emplacement des boites mails et des indexes de dovecot
 mail_location = maildir:~/Mail:INBOX=/var/mail/%u/:INDEX=/var/dovecot-indexes/%u
 # Structure initiale à donner à une boite mail
@ -87,18 +97,22 @@ mail_plugins = $mail_plugins mail_log notify
 # Limite le nombre de connections qu'un utilisateur peut réaliser au serveur
 mail_max_userip_connections = 15
 ```
-TODO: documenter ce que font mail_log et notify; documenter la dernière ligne de 
+
-la conf
+TODO: documenter ce que font mail_log et notify; documenter la dernière ligne
 de la conf.
 ### 10-master.conf
 C'est le fichier de configuration principal de dovecot. C'est ici qu'on va
-définir les différents services que proposeront notre installation. Au crans il 
+définir les différents services que proposeront notre installation. Au crans
-s'agit d'un serveur IMAP(s), d'un serveur POP3(s) et d'un serveur SASL.
+il s'agit d'un serveur IMAP(s), d'un serveur POP3(s) et d'un serveur SASL.
 #### IMAP
-La configuration du service se décompose en deux partie : le service 
+
-de connexion et d'authentification au daemon imap et la configuration imap.
+La configuration du service se décompose en deux partie : le service de
-```
+connexion et d'authentification au daemon imap et la configuration imap.
 ```txt
 service imap-login {
 # Notre service écoute en clair sur le port 143 seulement sur le réseaux
 # d'administration (pour les webmails) et il écoute en chiffré sur le 993 pour
@ -122,8 +136,10 @@ service imap {
 ```
 #### POP3
 Le service pop3 se configure de manière analogue.
-```
+
 ```txt
 service pop3-login {
  inet_listener pop3 {
    address = 127.0.0.1, [::1], 172.16.10.126, [fd00::10:0:ff:fe01:2610]
@ -143,10 +159,13 @@ service pop3 {
 ```
 #### SASL
 Pour le service d'authentification SASL, on souhaite qu'il ne soit accessible
 qu'en local et en clair. On ne définit donc qu'un seul bloc d'écoute en local
-sur le port `4242` (il n'y a pas de port réservé par l'IANA pour le protocole).
+sur le port `4242` (il n'y a pas de port réservé par l'IANA pour le
-```
+protocole).
 ```txt
 service auth {
  client_limit = 1024
  inet_listener {
@ -157,9 +176,11 @@ service auth {
 ```
 ### 10-ssl.conf
-Dans ce fichier on se contente de dire à dovecot où trouver nos certificats pour 
+
-les connextions chiffrées :
+Dans ce fichier on se contente de dire à dovecot où trouver nos certificats
-```
+pour les connextions chiffrées :
 ```txt
 ssl_cert = </etc/letsencrypt/live/crans.org/fullchain.pem
 ssl_key = /etc/letsencrypt/live/crans.org/privkey.pem
 ```
--- a/services/mail/normes.org
+++ b/services/mail/normes.org
--- a/services/mail/services/mail.md
+++ b/services/mail/services/mail.md
@ -1,4 +1,5 @@
 # Services Mail
 Le script de services mails permet de générer des fichiers d'alias et virtual
 pour [/critical/mail/postfix](postfix) à partir de la base de données des
 adhérents du crans. Actuellement celle ci est gérée par re2o donc on fait des
@ -6,6 +7,7 @@ requêtes à l'API de re2o pour récupérer la liste des adresses, alias et
 redirections mails.
 ## Installation
 Pour installer le logiciel, il faut cloner le répertoire git
 `https://gitlab.crans.org/nounous/mail.git` . Actuellement la convention veut
 que les services soient placé sous le chemin `/var/local/services/` mais rien ne
@ -17,11 +19,14 @@ fichier `aliases` et `virtual` du dépot git
 racine du dépot sous les noms `aliases_local` et `virtual_local`.
 ## Configuration
 ### Re2o
 Pour récupérer la liste des adresses mails, le script a besoin de pouvoir parler
 à l'API re2o. Pour ça on fournit au script les informations de connexions dans le
 fichier de configuration `re2o-config.ini` à la racine du dépot :
-```
+
 ```txt
 [Re2o]
 hostname = 172.16.10.156
 username = services
@ -29,21 +34,24 @@ password = ynerant_aime_le_php
 ```
 ### mail.json
 Dans le fichier de configuration `mail.json` aussi présent à la racine, on
 réalise le reste de la configuration du logiciel. Actuellement le script ne
 prends pas d'options, on peut donc se contenter de lui passer le dictionnaire
 vide en guise de configuration.
 ```json
 {}
 ```
 ## Conformation avec les normes email
 Les milters (filtres mails) suivants sont déployés sur le serveur mail :
- - openDKIM qui appose une en-tête de signature DKIM dans les mails émis.
+* openDKIM qui appose une en-tête de signature DKIM dans les mails émis.
- - openDMARC qui vérifie le passage des tests SPF et DKIM des mails entrants. Un
+* openDMARC qui vérifie le passage des tests SPF et DKIM des mails entrants. Un
  fichier d'historique (`/var/lib/opendmarc/opendmarc.history`) est complété à
-   chaque mail vérifié.
+  chaque mail vérifié. Un script permet de remplir une base de donnée à partir
-   Un script permet de remplir une base de donnée à partir de l'historique et un
+  de l'historique et un autre d'envoyer des rapports aux émetteurs des mails
-   autre d'envoyer des rapports aux émetteurs des mails traités.
+  traités.
--- a/services/monitoring/grafana.md
+++ b/services/monitoring/grafana.md
@ -0,0 +1,26 @@
 # Grafana
 Grafana est une traceur de données à destination des humains. Il est codé en
 NodeJS et correctement packagé dans une source de paquets Debian.
 L'idée de Grafana est de se connecter à des sources de données puis de
 réaliser des dashboards contenant des modules faisant des requêtes à ces
 sources de données.
 Là vous vous dites « *Mais du coup il faut passer beaucoup de temps pour
 créer les dashboards ? C'est nul !* ». Effectivement comparé à Munin il y a
 plus de travail nécessaire pour afficher des données, mais cela permet une
 plus grande adaptabilité. Beaucoup de dashboards existent en ligne (surtout
 sur les dépôts de code des exporters Prometheus) et sont téléchargeable en
 JSON pour ensuite les importer.
 ## Securité
 Par défaut Grafana crée un compte avec pour login `admin` et mot de passe
 `admin`. Parfois quand on bidouille la configuration, cet utilisateur est
 recréé automatiquement. Pensez à le supprimer s'il apparait dans la liste
 des utilisateurs ou changer son mot de passe.
 Évitez d'installer des plugins qui ne sont pas de confiance. Le service Systemd
 de Grafana le conteneurise pour éviter des potentielles exécutions de code
 distantes.
--- a/services/monitoring/ninjabot.md
+++ b/services/monitoring/ninjabot.md
@ -0,0 +1,17 @@
 # NinjaBot
 NinjaBot est un bot [IRC](/tools/irc.md) qui permet d'envoyer des notifications
 en temps réel sur des canaux de discussion, ses sources sont disponibles
 [ici](https://gitlab.crans.org/nounous/NinjaBot).
 Au Crans il est utilisé pour retransmettre les alertes du monitoring sur
 `#monitoring` et possède le nick `monitoring`.
 NinjaBot utilise [Flask](https://flask.palletsprojects.com/) afin d'écouter
 des webhooks et de pousser des notifications en fonction des données envoyées
 par le webhook. Ces notification sont ensuite envoyée sur une fifo lue par le
 bot IRC en lui-même : il est donc possible de modifier le comportement des
 notifications sans redémarrer le bot en lui-même.
 NinjaBot est déployé sur la VM `monitoring` et le service systemd qui lui est
 associé est `ninjabot`.
--- a/services/networking/bird.md
+++ b/services/networking/bird.md
@ -0,0 +1,164 @@
 # Bird
 Bird est un daemon de routage. Il supporte de nombreux protocoles de routages
 comme BGP and OSPF. Au crans on l'utilise pour faire de l'échange de route
 avec notre FAI grace au protocole BGP. C'est donc le seul que je détaillerais
 ici pour le moment.
 ## Principe
 ### L'IANA, le RIPE et le CRANS, les IPs et les numéros d'AS
 Après l'adoption du protocole IP, il a été décidé que ce serait à l'IANA
 (Internet Assigned Number Authority) de se charger de l'allocation des adresses
 IPs. Elle délègue cependant cette responsabilité à des entités régionales
 appelées RIR pour Regional Internet Registry. En Europe, c'est le RIPE (pour
 Réseaux IP Européens, cocorico) qui remplit cette office. Les gens à qui un
 RIR alloue des ressources est appelée un LIR pour Local Internet Registery. Et
 vous savez quoi, depuis 2017 le crans est un LIR à part entière \o/. Et le
 RIPE (notre RIR) nous a assigné les ressources suivantes :
 * 185.230.76.0/22
 * 2a0c:700::/32
 * 204515
 Les deux premiers éléments de cette liste suivent assez logiquement ce que
 j'ai dit plus haut. Le RIPE est censé assigné au LIR européen des ressources
 ip. Il nous a donc délégué un `/22` d'IPv4 et un `/32` d'IPv6 (aussi
 appellée une mole). Mais le troisième élément semble pour le moment plus
 absconts. En fait l'IANA et les RIR ne se contente pas de fournir des adresses
 IP mais toutes les ressources relatif à l'internet. En particulier, le dernier
 élément de notre liste est un numéro d'AS pour autonomous system. Un AS est
 un réseaux informatique qui opère sa propre politique de routage interne.
 C'est le cas au crans. Un numéro d'AS est identifiant unique alloué par un
 RIR et est utilisé dans certains protocoles internet entre AS comme le
 protocole BGP.
 ### Le protocole BGP
 Le protocole BGP est un protocole de routage qui permet l'échange de route
 entre deux AS. J'avoue avoir un peu la flemme de rentrer dans les détails de
 comment marche le protocole (si ça vous intéresse aller lire la RFC). Mais
 l'idée générale est que deux AS pairs dans le réseaux vont s'échanger des
 routes qui décrivent ce qu'ils sont capables d'atteindre. Si un AS recoit deux
 chemins différents pour la même route, il choisira celle qui a l'AS path le
 plus court, c'est à dire celle qui passe par le moins d'AS différent avant
 d'arriver à bon port.
 ## Installation
 On tire bird2 des repository debian : `sudo apt install bird2`.
 ## Configuration
 Le logiciel n'inclut pas de page de manuel détaillant les différentes options
 de configuration mais le [https://bird.network.cz/](site internet de bird) est
 très bien fourni en explication.
 Comme le logiciel supporte plusieurs protocole sa configuration est ségmenté
 en fonction des différents protocoles configurées en plus de quelques options
 de configurations fournis générales.
 ### Options de configurations générales
 Il est nécessaire de définir l'identifiant du routeur sur le lien. Cet
 identifiant en ipv6 comme en ipv4 doit être une adresse ipv4 qui pointe vers
 le routeur pour assurer son unicité.
 ### Le protocole kernel
 Le protocole kernel permet de définir la politique que bird va utiliser pour
 inserer des routes dans le kernel. Les options import et export permettent de
 définir quels routes bird va importer de la table de routage et exporter vers
 la table de routage. Au crans, on choisit assez simplement d'insérer toutes
 les routes que bird connait dans le noyau et de ne rien importer du noyau.
 L'option scan time permet de régler la fréquence à laquelle bird lira le
 contenu de la table de routage du kernel. Il est possible d'être plus
 précis⋅e sur les routes importé et exporté du protocol en utilisant des
 filtres.
 ```txt
 protocol kernel {
  ipv4 {
    import none;
    export all;
  };
 }
 protocol kernel {
  ipv6 {
    import none;
    export all;
  };
 }
 ```
 ### Le protocole device
 C'est pas vraiment un protocole, il permet simplement à bird de lister les
 interfaces du routeur.
 ```txt
 protocole device {}
 ```
 ### Le protocole static
 Le protocole static permet de définir des routes manuellement. Il est possible
 de définir plusieurs types de routes mais au crans on n'en définit que d'un
 seul type : les routes reject. Le comportement de ces routes est différent
 selon s'il est inséré dans le kernel où s'il est partagé via un protocole
 de partage de routes. Dans le premier cas, il dit au kernel assez litteralement
 de jetter tous les paquets vers cette route, comme le kernel choisi la route de
 plus long préfixe qui correspond à la destination cela revient à dire au
 routeur de jetter les paquets que le routeur ne sait pas joindre dans le bloc
 d'ips. Cependant dans un protocole d'échange de routes, il signifie que le
 routeur connait une route vers les éléments de ce bloc d'ips. Par exemple :
 ```txt
 protocol static {
  ipv4;
  route 185.230.76.0/22 reject;
 }
 protocol static {
  ipv6;
  route 2a0c:700::/32 unreachable;
 }
 ```
 ### Le protocol BGP
 Comme expliqué au dessus, le protocole BGP permet de faire de l'échange de
 routes entre différents AS. Il faut spécifier notre numéro d'AS, le numéro
 d'AS du pair et l'adresse sur laquelle on souhaite le contacter. Il est
 possible de préciser avec quelle adresse on veut le contacter. On peut là
 aussi définir des filtres d'import et d'exports de routes. Par exemple :
 ```txt
 protocol bgp aurore4 {
    description "BGP4 session with example";
    local 203.0.113.1 as crans_asn;
    neighbor 203.0.113.2 as example_asn;
    strict bind;
    ipv4 {
        import all;
        export where source ~ [ RTS_STATIC ];
    };
 }
 protocol bgp aurore6 {
    description "BGP6 session with example";
    local 2001:db8:28::1 as crans_asn;
    neighbor 2001:db8::28::2 as example_asn;
    strict bind;
    ipv6 {
        import all;
        export where source ~ [ RTS_STATIC ];
    };
 }
 ```
--- a/services/networking/isc-dhcp-server.md
+++ b/services/networking/isc-dhcp-server.md
@ -1,53 +1,65 @@
 # ISC-DHCP-SERVER
-ISC-DHCP-SERVER est une implémentation du protocole DHCP qui permet à un hôte 
+
-via une requète DHCP au serveur de récupérer une adresse IP, des informations à 
+ISC-DHCP-SERVER est une implémentation du protocole DHCP qui permet à un
-propos des dns et l'adresse de la passerelle. Il est actuellement un peu 
+hôte  via une requète DHCP au serveur de récupérer une adresse IP, des
-vieillisant mais il est très robuste, il est envisagé de le remplacer par son 
+informations à  propos des dns et l'adresse de la passerelle. Il est
-successeur kea quand il sera plus stable.
+actuellement un peu  vieillisant mais il est très robuste, il est envisagé de
 le remplacer par son  successeur kea quand il sera plus stable.
 ## Principe
 Le protocole DHCP utilise le transport UDP et les ports 67 du serveur et 68 du
 client.
 ### Configuration initiale
 Le protocole DHCP fonctionne de la manière suivante :
-  1. le client qui cherche à configurer son interface réseaux envoie une requète 
+
-  DHCPDISCOVER sur le lien en broadcast avec comme adresse cible 255.255.255.255 
+1. le client qui cherche à configurer son interface réseaux envoie une
-  en spécifiant son adresse MAC dans la requète
+   requète DHCPDISCOVER sur le lien en broadcast avec comme adresse cible
-  1. le serveur vérifie s'il est configuré pour répondre au client :
+   255.255.255.255 en spécifiant son adresse MAC dans la requète
-    - si ce n'est pas le cas il lui renvoie un DHCPDECLINE
+
-    - sinon il lui fait une offre cohérente par rapport à sa configuration et 
+1. le serveur vérifie s'il est configuré pour répondre au client :
   * si ce n'est pas le cas il lui renvoie un DHCPDECLINE
   * sinon il lui fait une offre cohérente par rapport à sa configuration et
     son état actuel via un paquet DHCPOFFER
-  1. le client lui répond avec une requète DHCPREQUEST dans lequel il précise 
+
 1. le client lui répond avec une requète DHCPREQUEST dans lequel il précise
   l'adresse qu'il souhaiterait que le serveur dhcp lui alloue
-  1. le serveur statue finalement sur l'adresse qu'il alloue effectivement au 
+
-    client dans un paquet DHCPACK où il précise en plus de l'adresse des options 
+1. le serveur statue finalement sur l'adresse qu'il alloue effectivement au
-    configurations supplémentaires comme l'adresse des serveurs de noms ou 
+   client dans un paquet DHCPACK où il précise en plus de l'adresse des
-    l'adresse de la passerelle. Il précise aussi pour combien de temps il 
+   options configurations supplémentaires comme l'adresse des serveurs de noms
   ou l'adresse de la passerelle. Il précise aussi pour combien de temps il
   réalise cette allocation (on parle de bail ou de lease).
 ### Rafraichir le bail
 Au bout du temps configuré par le serveur DHCP, il est possible pour le client
 de demander au serveur de renouveller l'allocation de l'adresse s'il l'utilise
-encore. Pour cela, il se contente de reprendre à partir de la troisième étape 
+encore. Pour cela, il se contente de reprendre à partir de la troisième
-précédente.
+étape précédente.
 ### Filtrage et protection
 Attention, il n'est pas rare qu'on composant actif (un switch par exemple) sur 
 le lien dispose par défaut de fonctionnalité bloquant par sécurité le traffic 
 dhcp. C'est une option de sécurité désactivable. Il est aussi possible parfois 
 d'utiliser cette fonctionnalité à notre avantage pour améliorer la sécurité de 
 notre infrastructure en précisant l'adresse de notre serveur dhcp permettant au 
 switch de bloquer les acquittements dhcp excepté celle provenant de nos 
 serveurs.
-Certains switchs permettent aussi de configurer certains ports qu'il interdit au 
+Attention, il n'est pas rare qu'on composant actif (un switch par exemple) sur
-machines derrière de communiquer avec une autre adresse que celle qu'elles ont 
+le lien dispose par défaut de fonctionnalité bloquant par sécurité le
-récupéré par dhcp.
+traffic dhcp. C'est une option de sécurité désactivable. Il est aussi
 possible parfois  d'utiliser cette fonctionnalité à notre avantage pour
 améliorer la sécurité de notre infrastructure en précisant l'adresse de
 notre serveur dhcp permettant au  switch de bloquer les acquittements dhcp
 excepté celle provenant de nos serveurs.
 Certains switchs permettent aussi de configurer certains ports qu'il interdit
 au machines derrière de communiquer avec une autre adresse que celle qu'elles
 ont récupéré par dhcp.
 ## Installation
-On se contente de tirer le logiciel des repository debian `sudo apt install 
+
-isc-dhcp-server`.
+On se contente de tirer le logiciel des repository debian
 `sudo apt install isc-dhcp-server`.
 ## Configuration
@ -57,53 +69,65 @@ principale se trouve dans `/etc/dhcp/dhcpd.conf` et un fichier de configuration
 additionel se trouve dans `/etc/default/isc-dhcp-dserver`.
 ### /etc/dhcp/dhcpd.conf
 Le logiciel se configure en fonction des plages de sous-réseaux qu'on souhaite
 que le serveur dhcp administre. Il permet en plus de préciser des options de
 configurations par défaut et des options de configuration générale. Un sous
-réseau se définit dans un bloc `subnet` pour lequel on précise le sous-réseau, 
+réseau se définit dans un bloc `subnet` pour lequel on précise le
-le masque associé et l'interface sur laquelle il servira ces requètes :
+sous-réseau, le masque associé et l'interface sur laquelle il servira ces
-```
+requêtes :
 ```txt
 subnet 100.64.0.0 netmask 255.255.0.0 {
  interface "ens23";
 }
 ```
 Il y a deux manières (utilisées au crans) de régler comment le serveur dhcp
 alloue des ips à ces clients. La première est de lui donner dans un fichier
 externer une liste d'association ip MAC au format suivant :
-```
+
 ```txt
 host gulf.cachan-adh.crans.org {
  hardware ethernet 02:65:6C:01:01:01;
  fixed-address 185.230.76.12;
 }
 ```
 ```
 et de préciser l'option suivante dans le bloc de configuration du sous-réseaux.
-```
+
 ```txt
 include "/var/local/services/dhcp/generated/dhcp.adh.crans.org.list";
 ```
-Les clients présents dans cette liste seront alors considéré comme connus par le 
+
-serveur dhcp. Pour les clients qu'il ne connait pas il peut alors décider de les 
+Les clients présents dans cette liste seront alors considéré comme connus par
-accepter ou de les refuser en précisant soit `allow unknown-clients;` soit `deny 
+le serveur dhcp. Pour les clients qu'il ne connait pas il peut alors décider de
-unknown-clients;` dans le bloc de sous-réseaux.
+les accepter ou de les refuser en précisant soit `allow unknown-clients;` soit
 `deny unknown-clients;` dans le bloc de sous-réseaux.
 L'autre manière de procéder est de lui laisser gérer lui même l'allocation des
 adresses ips à utiliser en lui précisant simplement dans quels plages il a le
 droit de venir se servir, pour cela on précise l'option suivante dans le bloc :
-```
+
 ```txt
 pool {
  range 100.65.1.0 100.65.255.254;
 }
 ```
 Vu qu'a priori les clients ne sont pas connus, il faut assez fréquemment
 préciser en conjoncure de cette option l'option `allow unknown-clients;`.
 Il reste ensuite à régler la durée pour laquelle les adresses sont alloués :
-```
+
 ```txt
    default-lease-time 600;
    max-lease-time 7200;
 ```
 Ainsi que les options de configuration réseaux a passé au client :
-```
+
 ```txt
    option subnet-mask 255.255.0.0; # Précise le sous-réseaux dans lequel l'adresse assignée se trouve
    option broadcast-address 100.64.255.255; # Précise l'adresse de broadcast que le client doit configurer
    option routers 100.64.0.99; # Précise l'adresse de la passerelle
@ -113,10 +137,13 @@ Ainsi que les options de configuration réseaux a passé au client :
 ```
 ### /etc/default/isc-dhcp-server
-Ce fichier contrôle les options utilisées pour lancer le daemon isc-dhcp-server. 
+
-Dans notre cas on se contente de préciser sur quels interfaces le serveur 
+Ce fichier contrôle les options utilisées pour lancer le daemon
-devrait écouter en ipv4, mais il est possible de préciser d'autres options.
+isc-dhcp-server. Dans notre cas on se contente de préciser sur quels interfaces
-```
+le serveur devrait écouter en ipv4, mais il est possible de préciser d'autres
 options.
 ```txt
 INTERFACESv4="ens22 ens23 ens1 enp1s3"
 ```
--- a/services/networking/keepalived.md
+++ b/services/networking/keepalived.md
@ -0,0 +1,92 @@
 # Keepalived
 Keepalived est une implémentation du protocole VRRP. Il permet de partager des
 ips entre plusieurs machines. Si celle qui qui porte l'adresse à un moment
 tombe, c'est une des autres qui prend le relai.
 ## Principe
 Le protocole VRRP permet de s'assurer qu'un ensemble d'adresses ip soit
 toujours tenues par un pair sur le reseaux. Par exemple, au crans, pour
 rajouter de la résilience sur la panne d'un routeur, les ips du routeurs sont
 partagées entre plusieurs machines. Celle qui porte les ressources en
 fonctionnement normal est appelée le `MASTER` et les autres sont appelées
 les `BACKUP` et on leur assigne des priorités décroissantes. Sur le lien
 local que partage les différentes machines, elles négocient qui devrait
 porter les ressources actuellement. En ipv4, la négociation se fait en
 multicast en utilisant l'ip `224.0.0.18` et en ipv6 cela ce fait via le groupe
 `ff02::12` (il faut bien faire attention à ce que le parefeu ou qu'un
 commutateur ne le filtre pas). Si le porteur de l'ip actuel arrète de
 transmettre des alertes VRRP alors le candidat avec la plus haute priorité
 s'affectera les ressources.
 ## Installation
 On se contente de tirer le logiciel des repositorys debian
 `sudo apt install keepalived`. Il y est packagé (correctement) depuis Jessie.
 ## Configuration
 Il est fortement recommandé de sortir le `man 5 keepalived.conf` qui détaille
 assez bien les différents cas d'utilisation du logiciel.
 Le logiciel nous permet de définir quelques options générale dans la section
 global_defs. En particulier on peut y préciser le nom de la machine et la
 configuration de l'envoi de mail :
 ```txt
 global_defs {
  notification_email { root@crans.org }
  notification_email_from keepalived@crans.org
  smtp_server smtp.adm.crans.org
  router_id routeur-sam
 }
 ```
 On peut ensuite rentré dans la configuration des instances. Une instance
 correspond à un bloc de ressource que l'on souhaite partagé entre deux
 machines. Comme les protocoles sous-jacent sont distincts en ipv4 et en ipv6,
 la  configuration pour des ressources ipv4 et ipv6 se fait dans des blocs
 différents. Dans une instance, on doit préciser la priorité de la machine
 dans l'instance, l'interface surlaquelle se font les alertes vrrp,
 l'identifiant de l'instance et un bloc définissant les ressources qui sont
 partagées. Il est aussi possible de définir un script qui sera appelé au
 changement d'état. On donne ici l'exemple d'une instance en ipv4.
 ```txt
 vrrp_instance VI_ALL {
  # Définit l'état de priorité de la machine dans l'instance
  state MASTER
  priority 150
  # Active l'envoie des mails lors des changement d'état
  smtp_alert
  # Lien sur lequel se font les alertes VRRPS
  interface ens18
  # Identifiant de l'instance sur le lien
  virtual_router_id 60
  # Fréquence des envois d'alertes VRRPs
  advert_int 2
  # Script appelé lors des changement d'état
  notify /var/local/services/keepalived/keepalived.py
  # Bloc définissant les ressources partagées
  virtual_ipaddress {
      185.230.79.62/26 brd 185.230.79.63 dev ens22 scope global
  }
 }
 ```
 ### Script de changement d'état
 Comme préciser dans la section précédente, il est possible d'appeler un
 script  lors des changements d'état de l'instance. Keepalived appelera alors
 le script avec les paramètres suivant :
 `script [TYPE] [NAME] [STATE] [PRIORITY]` où `[TYPE]` vaut `INSTANCE` dans
 notre cas, `[NAME]` donne le nom de l'instance concernée, `[STATE]` donne
 l'état vers lequel on transitionne et `[PRIORITY]`  la  priorité dans
 l'instance.
 En utilisant un script, il est possible (comme on le fait actuellement au
 crans) de laisser à keepalived le soin de démarrer certains services.
--- a/services/networking/nftables.md
+++ b/services/networking/nftables.md
@ -26,10 +26,9 @@ IPv6, arp, ... . Pour cette raison, les chaînes sont regroupées dans des table
 chacune ne concernant un ou plusieurs type de protocole (généralement de couche
 3).
 La structure des règles NFTables ainsi obtenue devient :
-```
+```txt
 +------------------------------------------------------------+
 | Table concernant les paquets IP                            |
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                            |
@ -84,7 +83,6 @@ La structure des règles NFTables ainsi obtenue devient :
                       ...
 ```
 Comme le décrit le schéma précédent, les tables sont juxtaposées les unes les
 autres. Lorsqu'un paquet est traité, selon le protocole utilisé, aucune, une ou
 plusieurs tables seront utilisées pour charger les règles à appliquer. À
@ -97,6 +95,7 @@ toutes les conditions la précédant dans l'écriture de la règle sont vérifi
 Le parcourt d'une chaîne s'arrête lorsqu'un verdict s'applique au paquet
 considéré. Un verdict est une action particulière parmi peut être :
 * l'abandon du paquet
 * l'abandon du paquet avec choix du message retourné à l'émetteur
@ -107,7 +106,6 @@ considéré. Un verdict est une action particulière parmi peut être :
 * Le saut à une autre chaîne (sans retour à la chaîne en cours après)
 ## Table
 Une table est caractérisée par :
@ -117,20 +115,16 @@ Une table est caractérisée par :
 * Un type de paquet : principalement ip (pour l'IPv4), ip6 (pour l'IPv6) et inet
  (pour l'IPv4 et IPv6).
 Une table peut être ajoutée avec la commande `nft add table <nom de la table>`
 si vous souhaitez utiliser la commande `nft`, ou avec le morceau de
 configuration suivant :
-```
+```txt
 table <type> <nom de la table> {
    [contenu de la table (chaînes)]
 }
 ```
 ## Chaîne
 Une chaîne est caractérisée par :
@ -139,7 +133,6 @@ Une chaîne est caractérisée par :
 * Le nom de la chaîne
 Lors de la création / utilisation d'une chaîne, il faut aussi décider !
 * Le crochet NFTables concerné par la chaîne (input, output, ...)
@ -148,30 +141,27 @@ Lors de la création / utilisation d'une chaîne, il faut aussi décider !
 * La priorité de la chaîne (filter (=0), srcnat (=-100), dstnat (=100)).
 Une chaîne peut aussi avoir un verdict par défaut sur les paquet (accept, drop,
 reject [with MSG], ...).
 Une chaîne peut être créée par la commande
-Une chaîne peut être créée par la commande `nft add chain <type de la table>
+```txt
-<nom de la table> <nom de la chaîne> '{ type <type> hook <crochet> priority
+nft add chain <type de la table> <nom de la table> <nom de la chaîne> '{ type <type> hook <crochet> priority <priorité>; [policy <verdict par défaut>;] }'
 <priorité>; [policy <verdict par défaut>;] }'`, ou par le morceau de
 configuration textuelle suivant :
 ```
 ou par le morceau de configuration textuelle suivant :
 ```txt
 chain <nom de la chaîne> {
    type <type> hook <crochet> priority <priorité> ; policy <verdict par défaut>;
    [contenu de la chaîne]
 }
 ```
 ## Règle
-Une règle est caractérisée par :
+Une règle est caractérisée par la chaîne dans laquelle elle est contenue.
 * La chaîne dans laquelle elle est  contenue.
 Dans la définition d'une règle, il est possible d'indiquer :
@ -189,12 +179,13 @@ Dans la définition d'une règle, il est possible d'indiquer :
 * des actions, parmi lesquelles "compter les paquets" (`counter`), logger les
  paquets (`log prefix ...`).
 Pour ajouter une règle, il est possible d'utiliser
 ```txt
 nft add rule <type de la table> <nom de la table> <nom de la chaîne> '<règle>'`
 ```
-Pour ajouter une règle, il est possible d'utiliser `nft add rule <type de la
+ou d'ajouter la règle sur une ligne dans la configuration textuelle.
 table> <nom de la table> <nom de la chaîne> '<règle>'`, ou d'ajouter la règle
 sur une ligne dans la configuration textuelle.
 ## Ensembles et applications
@ -207,9 +198,9 @@ sous-jacents luiel(de crapaud)-même.
 Un ensemble peut être :
- * anonyme (eg: `{ A, B, C}`). Dans ce cas, l'ensemble est statique.
+* anonyme (eg: `{A, B, C}`). Dans ce cas, l'ensemble est statique.
- * nommé. Dans ce cas, l'ensemble peut être dynamique et avoir diverses options
+* nommé. Dans ce cas, l'ensemble peut être dynamique et avoir diverses options
  et paramètres  associés (eg: permettre de stocker des intervalles, associer
  une durée de vie aux éléments (avec éventuellement un délai par défaut),
  compter des paquets, une taille).
@ -221,34 +212,33 @@ Un ensemble peut être :
  Dans un fichier de configuration, un ensemble est déclaré (dans une table)
  par :
-   ```
+
  ```txt
  set <nom de l'ensemble> {
      type <type d'éléments>;
  }
  ```
-   Le type des éléments peut être donné explicitement ou à l'aide de `typeof
+
-   ...`, ou `...` est un critère valide (eg: `typeof tcp dport` est équivalent à
+  Le type des éléments peut être donné explicitement ou à l'aide de
-   `type inet_service`).
+  `typeof ...`, ou `...` est un critère valide (eg:
  `typeof tcp dport` est équivalent à `type inet_service`).
  Il est également possible de réaliser des produits cartésiens de types. Par
  exemple, le type `ipv4_addr . inet_service` est le type des pairs d'adresse
  IPv4 et des ports.
  Il y a de nombreuses options utiles lors de la déclaration d'un ensemble :
-   - Le nombre d'éléments max (`size <nombre>`). La valeur par défaut est 65536.
+   * Le nombre d'éléments max (`size <nombre>`). La valeur par défaut est 65536.
   - Les drapeaux (`flags ...`), dont `timeout` ou `intervals`
   - Les éléments initiaux (`elements = { e0, ..., en }`)
   * Les drapeaux (`flags ...`), dont `timeout` ou `intervals`
   * Les éléments initiaux (`elements = { e0, ..., en }`)
 ### Applications
 TODO: `nft (add|...) map ...`
 ## Interaction avec le pare-feu
 Il est souvent pratique d'ajuster les règles d'un pare-feu (ajout d'un service,
@ -256,9 +246,9 @@ de règles, réordonnancement des règles, ...). Un moyen naïf pour faire cela
 de réinitialiser le pare-feu et de charger un nouveau fichier de configuration.
 L'inconvénient est que cela :
- * vide les ensembles et applications remplis dynamiquement
+* vide les ensembles et applications remplis dynamiquement
- * permet à des intrus d'établir des connections illicites si elles sont
+* permet à des intrus d'établir des connections illicites si elles sont
  initialisées durant la remise à zéro (moins important car la recharge d'un
  fichier de configuration est rapide).
@ -268,30 +258,33 @@ La commande `nft` permet certes d'ajouter des tables, des chaînes et des règle
 dynamiquement, comme expliqué ci-dessus. Mais elle permet également de corriger
 des erreurs, ce qui peut être pratique par moments.
- * Suppression ou remplacement d'une règle par une autre :
+* Suppression ou remplacement d'une règle par une autre :
-     - Pour la suppression : `nft delete rule <type de la table> <nom de la
+   * Pour la suppression :
       table> <nom de la chaîne> handle <numéro e la poignée (du handler en
       anglais)>`
-     - Pour le remplacement : `nft replace rule <type de la table> <nom de la
+     ```bash
-       table> <nom de la chaîne> handle <numéro de la poignée (du handler en
+     nft delete rule <type de la table> <nom de la table> <nom de la chaîne> handle <numéro de la poignée (du handler en anglais)>
-       anglais)> <new_rule>`.
+     ```
   * Pour le remplacement :
     ```bash
     nft replace rule <type de la table> <nom de la table> <nom de la chaîne> handle <numéro de la poignée (du handler en anglais)> <new_rule>
     ```
    __Cas d'usage :__
-    - si vous utilisez un ensemble anonyme pour gérer quels ports
+      * si vous utilisez un ensemble anonyme pour gérer quels ports
        sont ouverts aux nouvelles connections TCP, vous pouvez le mettre à jour
        facilement.
-    - si vous voulez qu'une règle filtrant les accès TCP permette aussi l'UDP,
+      * si vous voulez qu'une règle filtrant les accès TCP permette aussi l'UDP,
-      vous pouvez par exemple souhaiter remplacer `tcp dport` par `meta l4proto
+        vous pouvez par exemple souhaiter remplacer `tcp dport` par
-      { tcp, udp} td dport`
+        `meta l4proto { tcp, udp} td dport`
- * Ajout d'une règle à un endroit précis dans le pare-feu :
+* Ajout d'une règle à un endroit précis dans le pare-feu :
  Cela peut être fait avec les règles
-   `nft <add|insert> rule <type table> <nom table> <nom chaîne> handle <numéro>
+  `nft <add|insert> rule <type table> <nom table> <nom chaîne> handle <numéro> <règle>`.
   <règle>`.
  `add` permet d'insérer la règle après la poignée spécifiée. Si aucune poignée
   n'est spécifiée, la règle est ajoutée à la fin de la chaîne.
@ -299,19 +292,15 @@ des erreurs, ce qui peut être pratique par moments.
  `insert` permet d'insérer la règle avant la poignée spécifiée. Si aucune
  poignée n'est spécifiée, la règle est ajoutée au début de la chaîne.
- * Options pratiques (`nft -option_pratique ...`) :
+* Options pratiques (`nft -option_pratique ...`) :
-   - `-t` permet de ne pas afficher le contenu des ensembles et applications
+   * `-t` permet de ne pas afficher le contenu des ensembles et applications
     dans la sortie de la commande qui suit
-
+   * `-a` permet d'afficher les numéros de poignée
-   - `-a` permet d'afficher les numéros de poignée
+   * `-n` permet d'afficher les noms des services plutôt que les ports
   - `-n` permet d'afficher les noms des services plutôt que les ports
     (déconseillé car la fonction des ports dans les noms de service n'est pas
     injective)
 ## Journalisation et surveillance
 ### Journalisation
@ -322,25 +311,23 @@ est d'usage au Cr@ns de noter toutes les nouvelles connections.
 Cela peut être fait grâce à l'action `log prefix "..."`, ou `"..."` est le
 préfixe à utiliser dans le journal du système.
 ### Surveillance
 Il est possible de demander à NFTables d'afficher des messages de débogage,
 liés entre autre aux changements, retraits ou ajouts de règles, de tables, ... à
 l'aide de la commande `nft monitor`
- * __Changements__ :
+* __Changements__
-   - Changements précis : `nft monotor ...
+   * Changements précis : `nft monotor ...
     <rules|chains|ruleset|tables|sets|elements>`, où `...` peut être rien,
     `destroy` ou `add` selon si l'on veut tout entendre, n'entendre que les
     retraits ou les ajouts.
-   - Changements quelconques : `nft monotor` pour tout entendre (y compris les
+   * Changements quelconques : `nft monotor` pour tout entendre (y compris les
     parcours des paquets marqués décrits ci-dessous).
- * __Débogage__ :
+* __Débogage__
  À des fins de débogage, il est parfois pratique de savoir par quelles règles
  un paquet donné est passé et quelle verdict il a subit. À cette fin, NFTables
  permet de marquer le paquet à l'aide de l'action `meta nftrace set 1`.
@ -348,7 +335,6 @@ l'aide de la commande `nft monitor`
  Les événements internes de NFTables concernant ce paquet peuvent ensuite être
  affichés avec la commande `nft monitor trace`.
 ## Divers
 * `nft flush ruleset` vide la table
@ -367,4 +353,3 @@ l'aide de la commande `nft monitor`
 * Il est possible d'utiliser des variables dans un fichier de configuration.
  Leur valeur sera substituée lors de la lecture du fichier. Un exemple est
  donné dans le fichier `services/firewall.md`.
--- a/services/networking/prefix_delegation.md
+++ b/services/networking/prefix_delegation.md
@ -0,0 +1,31 @@
 # Délégation de préfixe IPv6
 La longueur des adresses IPv6 (128 bits) nous permet de déléguer des
 préfixes (c'est à dire des sous-réseaux) IPv6.
 Il est possible de fournir des préfixes grâce au protocole DHCPv6 mais cette
 solution n'a pas été privilégiée au Crans : nous lui avons préféré une
 attribution statique.
 Dans [Re2o](/services/re2o.md) une application Django, `prefix_delegation`, a
 été écrite permettant notamment d'attribuer des préfixes IPv6 de taille
 fixée à des utilisateurs.
 Dans cette application il est possible de définir des sous-réseaux IPv6 ainsi
 que le taille des préfixes contenus dans ces sous-réseaux puis de créer des
 préfixes et de les attribuer à des adhérents en leur assignant des
 passerelles (machine de l'adhérent à contacter pour router ce préfixe).
 L'application fourni une API Rest HTTP permettant au script `prefix_delegation`
 de rafraîchir la liste des préfixes et de leur passerelle dans le noyau de la
 VM de routage.
 Ce script utilise un protocole particulier pour gérer ses routes, ce protocole
 est défini dans `/etc/iproute2/rt_protos.d` sur les machines où le script des
 déployé.
 Le reverse [DNS](/tools/dns.md) est également délégué : des serveurs DNS
 peuvent être attribués à un ou plusieurs préfixes afin de résoudre les
 adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent. Il
 est même possible de configurer du DNSSEC pour le reverse DNS. Ceci est géré
 par le script `dns` sur la VM `silice`.
--- a/services/networking/radvd.md
+++ b/services/networking/radvd.md
@ -0,0 +1,91 @@
 # Radvd
 Radvd est une implementation du mécanisme d'autoconfiguration des adresses IP
 en ipv6. Il permet au client de connaitre l'adresse du routeur et de se
 construire lui même une adresse à partir du préfixe annoncé par le routeur
 et de son adresse MAC. Des extensions du protocoles permettes aussi la
 configuration des serveurs dns.
 ## Principe
 ### Adresse ipv6 et EUI-64
 Il est possible pour un pair possédant une adresse MAC et un prefixe ipv6 de
 taille au plus `/64` de construire une adresse ipv6. Cependant, rien n'assure
 qu'elle soit unique à ce stade et il faudra par la suite le vérifier. Mais on
 ne s'interesse ici qu'au processus de construction.
 De son adresse MAC (donnée à 48 bits), on dérive un identifiant de
 l'interface sur le lien de 64 bits en insertant les 16 bits `FF:FE` au milieu
 de l'adresse MAC puis on inverse le 7 ème bit. On peut ensuite suffixer cet
 identifiant au préfixe dans lequel on chercher à construire notre addresse
 ipv6. Ainsi `00:25:90:69:8c:74` devient `00:25:90:ff:fe:69:8c:74` puis
 `02:25:90:ff:fe:69:8c:74` qui donne l'adresse `fd00::10:0225:90ff:fe69:8c74/64`
 dans le prefixe `fd00:0:0:10::/64`.
 ### Processus d'autoconfiguration complet
 Lorsqu'une machine configure une interface supportant l'ipv6 sur un lien, celle
 ci va tenter de se crééer une premier adresse local au lien. Elle est donc
 judicieusement appelé ip de lien locale. Pour cela, il va se contruire comme
 expliquer précedemment une adresse dans le prefixe `fe80::/64`. Pour s'assurer
 qu'elle est effectivement unique, il va envoyer au groupe ipv6 all-node
 (`ff02::1`) qui comme son nom l'indique contient tous les nœuds si quelqu'un
 utilise déjà l'adresse. Si c'est le cas, il ne poussera pas sa configuration
 plus loin. Sinon après un délai sans réponse, il s'assignera l'adresse.
 Notre pair a donc maintenant une adresse sur le lien et il peut écouter les
 annonces (judicieusement appelé routeur-advertissement ou RA) périodiques
 qu'envoie le routeur au groupe all-node. S'il ne désire pas patienté jusqu'à
 la prochaine annonce le client peut envoyer un routeur-sollicitation au groupe
 all-routers. Dans ces annonces le routeur inclut entre autre le prefixe dans
 lequel le client devrait prendre son adresse, son adresse de lien local ainsi
 que des informations à propos des serveurs dns. Une fois ces informations
 récupérées le client peut procéder aux dernières étape de configuration
 de son interface réseaux en assignant l'adresse qu'il a construit à partir
 du préfixe que lui a fourni le routeur (en vérifiant en amont son unicité
 sur le lien) et en configurant la gateway à l'adresse de lien local du
 routeur.
 ## Installation
 On se contente de tirer le logiciel des repository debian
 `sudo apt install radvd`.
 ## Configuration
 La page de manuel détaillant les options de configurations de radvd est
 consultable en utilisant `man 5 radvd.conf`.
 La configuration du logiciel se fait par bloc d'interface sur lesquel on va
 publier nos RA. Dans un bloc on peut ensuite définir
 * des options génériques à propos de l'annonce comme par exemple l'intervalle
  auquel notre routeur devrait publier des annonces ou le temps que la route
  devrait être conservé par le client.
 * les prefixes que le routeur va annoncer sur le lien et certaines options
  associées
 * les options de configurations du DNS
 Par exemple, le bloc suivant configure des annonces sur l'interface ens1 envoyé
 toutes les 30 secondes avec comme préfixe `2a0c:700:12::/64`, `adh.crans.org`
 comme liste de recherche pour les dns et `2a0c:700:12::ff:fe00:9912` comme
 adresse du serveur dns.
 ```txt
 interface ens1 {
        AdvSendAdvert on;
        AdvDefaultPreference high;
        MaxRtrAdvInterval 30;
        prefix 2a0c:700:12::/64 {
                AdvRouterAddr on;
        };
        # La zone DNS
        DNSSL adh.crans.org {};
        # Les DNS récursifs
        RDNSS 2a0c:700:12::ff:fe00:9912 {};
 };
 ```
--- a/services/networking/services/dhcp.md
+++ b/services/networking/services/dhcp.md
@ -7,19 +7,23 @@ fait des requêtes à l'API de re2o pour récupérer la liste des machines des
 adhérents.
 ## Installation
 Pour installer le logiciel, il faut cloner le répertoire git
-`https://gitlab.crans.org/nounous/dhcp.git` . Actuellement la convention veut 
+<https://gitlab.crans.org/nounous/dhcp.git>. Actuellement la convention veut
 que les services soient placé sous le chemin `/var/local/services/` mais rien ne
 l'impose. Pour tourner  le script a besoin du paquet `python3-jinja2`. Il faut
 aussi crééer le dossier `generated` à la racine du dépot dans lequel seront
 stocker les fichiers de bails générer.
 ## Configuration
 ### Re2o
 Pour récupérer la liste des machines, le script a besoin de pouvoir parler à
 l'API re2o. Pour ça on fournit au script les informations de connexions dans le
 fichier de configuration `re2o-config.ini` à la racine du dépot :
-```
+
 ```txt
 [Re2o]
 hostname = 172.16.10.156
 username = services
@ -27,10 +31,12 @@ password = ynerant_aime_le_php
 ```
 ### dhcp.json
 Dans le fichier de configuration `dhcp.json` aussi présent à la racine, on
 réalise le reste de la configuration du logiciel. Une seule option est supporté
 pour le moment : `extensions` qui permet de filtrer sur les extensions des
 machines pour lesquels on souhaite exporter un fichier de bails :
 ```json
 {
    "extensions": [
--- a/services/networking/services/firewall.md
+++ b/services/networking/services/firewall.md
@ -0,0 +1,114 @@
 # Pare-feu
 Voir `/critical/networking/nftables.md` pour une documentation minimale sur
 NFTables.
 Voici un pare-feu basique dans lequel des adhérants se trouvent derrière un
 routeur :
 ```txt
 #!/usr/sbin/nft -f
 flush ruleset
 #           +~~~~~~+
 #           | IPV4 |
 #           +~~~~~~+
 define adh_prefix = 172.16.54.1 - 172.16.54.98
 define srv_prefix = 185.230.79.0/24
 define nat_out = 185.230.79.37
 #           +~~~~~~+
 #           | IPV6 |
 #           +~~~~~~+
 define adh_prefix6 = 2a0c:700:54::/64
 # définit les adresses utilisées par les adhérants
 define adh4 = 100.66.0.0/16 ### Qu'est-ce que cette adresse ?
 #           +~~~~~~~~~~~~~~+
 #           | Filter table |
 #           +~~~~~~~~~~~~~~+
 table inet filter {
    # Définiton des ports ouverts sur chaque machine
    # (Utilise un mapping plutôt que des sets pour éviter uen complexité
    # terrifiante en O(nm) et passer à O(n+m) \(\ddot\smile\))
    set authorized_in_forward_tcp4 {
        type ipv4_addr . inet_service
        flags interval
    }
    set authorized_in_forward_udp4 {
        type ipv4_addr . inet_service
        flags interval
    }
    set authorized_in_forward_tcp6 {
        type ipv6_addr . inet_service
        flags interval
    }
    set authorized_in_forward_udp6 {
        type ipv6_addr . inet_service
        flags interval
    }
    chain input {
        type filter hook input priority 0; policy drop;
        # Accept local traffic
        meta iiftype loopback accept comment "allow from loopback"
        # Accepts existsing connections
        ct state { related, established } accept
        ct state invalid drop
        # Accept SSH and DHCP
        meta l4proto { udp, tcp } th dport { ssh, 67 } ct state new accept
        # Accept ping
        ip protocol icmp accept icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        # Accept established and ping connnections
        ct state { established, related } accept
        ct state invalid drop
        # On log tout ce qui est neuf et qui passe
        log prefix "FORWARD: "
        ip protocol icmp accept icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept
        # Ouverture de ports pour les gens se trouvant derrière
        ip daddr . tcp dport @authorized_in_forward_tcp4 accept
        ip6 daddr . tcp dport @authorized_in_forward_udp4 accept
        ip daddr . udp dport @authorized_in_forward_tcp6 accept
        ip6 daddr . udp dport @authorized_in_forward_udp6 accept
        # Accepter toutes les connexions sortantes des clubs / adh et les logger
        ip saddr $adh_prefix accept
        ip6 saddr $adh_prefix6 accept
    }
 }
 #           +~~~~~+
 #           | NAT |
 #           +~~~~~+
 table inet loggonsTout {
    chain prerouting {
        type nat hook prerouting priority dstnat;
        # On log ce qui est neuf
        ct state new log prefix "LOGALL: "
    }
 }
 table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat;
        # traffic des adhérants et des clubs ===> $nat_out (range)
        ip saddr $adh_prefix snat to $nat_out persistent
    }
 }
 ```
--- a/services/re2o.md
+++ b/services/re2o.md
@ -1,6 +1,14 @@
 # Re2o
 Re2o est un système de gestion d'association réseau étudiante écrit en [Django](https://www.djangoproject.com/) un framework [Python](https://www.python.org/) permettant de développer facilement des sites webs interagissant avec une base de données ses sources sont disponibles sur le [GitLab FedeRez](https://gitlab.federez.net/re2o/re2o).
-Re2o permet de gérer la base de données des adhérents et de leur machine ainsi que quelques autres objets tels que les définitions des zones [DNS](/tools/dns.md).
+Re2o est un système de gestion d'association réseau étudiante écrit en
 [Django](https://www.djangoproject.com/) un framework
 [Python](https://www.python.org/) permettant de développer facilement des
 sites webs interagissant avec une base de données ses sources sont disponibles
 sur le [GitLab FedeRez](https://gitlab.federez.net/re2o/re2o).
-Il est déployé sur la VM `re2o` et est joignable en [HTTP](tools/http.md)(S) sur `intranet.crans.org`.
+Re2o permet de gérer la base de données des adhérents et de leur machine
 ainsi que quelques autres objets tels que les définitions des zones
 [DNS](/tools/dns.md).
 Il est déployé sur la VM `re2o` et est joignable en [HTTP](tools/http.md)(S)
 sur `intranet.crans.org`.
--- a/services/vsftpd.md
+++ b/services/vsftpd.md
@ -1,63 +1,74 @@
 # VSFTPD
-VSFTPD est une implémentation de serveur ftp connue pour être très sécurisée 
+
-(comme son nom, very secure FTP daemon, l'indique). Un serveur FTP est un 
+VSFTPD est une implémentation de serveur ftp connue pour être très
-serveur d'échange de fichier un peu daté qui permet à des clients de récuperer 
+sécurisée  (comme son nom, very secure FTP daemon, l'indique). Un serveur FTP
-des fichiers d'un serveur, et de les y pousser. Aujourd'hui on lui préferait 
+est un  serveur d'échange de fichier un peu daté qui permet à des clients de
-l'utilisation de sftp qui utilise le protocole ssh comme support si le client a 
+récuperer  des fichiers d'un serveur, et de les y pousser. Aujourd'hui on lui
-besoin d'un accès en écriture au serveur ou simplement du protocole http/https 
+préferait  l'utilisation de sftp qui utilise le protocole ssh comme support si
-sinon. Cependant certaines technologies ainsi que des sysadmins vieillissant ne 
+le client a  besoin d'un accès en écriture au serveur ou simplement du
-savent pas faire autre chose que du ftp. C'est pour ça entre autre qu'on 
+protocole http/https  sinon. Cependant certaines technologies ainsi que des
-continue de supporter le protocole à certains endroits dans l'infrastructure.
+sysadmins vieillissant ne  savent pas faire autre chose que du ftp. C'est pour
 ça entre autre qu'on  continue de supporter le protocole à certains endroits
 dans l'infrastructure.
 ## Principe
 Comme décrit plus tôt, le protocole FTP est un ancêtre de l'internet (la
 première RFC qui le mentionne prédate l'utilisation de la stack TCP/IP). En
-particulier il n'a initialement pas été prévu pour opérer à travers des parefeu 
+particulier il n'a initialement pas été prévu pour opérer à travers des
-et des nats. C'est pourquoi aujourd'hui un serveur FTP peut fonctionner de deux 
+pare-feu et des NAT. C'est pourquoi aujourd'hui un serveur FTP peut
-manières différentes :
+fonctionner de deux manières différentes :
 ### FTP actif
-Quand un client initie une connection avec un serveur FTP, il fournit au serveur 
+
-un numéro de port sur lequel le serveur pourra tenter de se connecter pour 
+Quand un client initie une connection avec un serveur FTP, il fournit au
-procéder à l'échange de données. Cependant au moment où le client redirige le 
+serveur  un numéro de port sur lequel le serveur pourra tenter de se connecter
-serveur sur un autre port, rien ne permet d'affirmer que celui sera contactable 
+pour procéder à l'échange de données. Cependant au moment où le client
-par le serveur (en fait de nos jours, si les deux machines ne sont pas sur le 
+redirige le  serveur sur un autre port, rien ne permet d'affirmer que celui
-même réseau local, il est quasiment certain que le serveur n'arrivera pas à 
+sera contactable par le serveur (en fait de nos jours, si les deux machines ne
-contacter le client).
+sont pas sur le même réseau local, il est quasiment certain que le serveur
 n'arrivera pas à contacter le client).
 ### FTP passif
 Pour remedier à ça, le protocole ftp surporte maintenant un mode passif, où
-c'est à la charge du serveur de rediriger l'utilisateur sur un port contactable 
+c'est à la charge du serveur de rediriger l'utilisateur sur un port
-du serveur.
+contactable  du serveur.
 ### Connexion au serveur
 Pour se connecter à un serveur ftp un client peut le faire de manière anonyme
-si le serveur lui permet. Mais il est possible de restreindre l'accès à une base 
+si le serveur lui permet. Mais il est possible de restreindre l'accès à une
-d'utilisateurs sécurisée par mot de passe. Cependant, le protocole ne prévoit 
+base d'utilisateurs sécurisée par mot de passe. Cependant, le protocole ne
-pas que le message soit chiffrée pendant le transfert.
+prévoit pas que le message soit chiffrée pendant le transfert.
 ### Support de TLS
-Le support de TLS a été ajouté au protocole. Il est possible pour le client de 
+
-demander à l'initialisation de la connexion que celle-ci s'effectue de manière 
+Le support de TLS a été ajouté au protocole. Il est possible pour le client
-chiffrée. Cela permet en particulier d'éviter de faire transiter des messages en 
+de demander à l'initialisation de la connexion que celle-ci s'effectue de
-clair sur le réseau.
+manière chiffrée. Cela permet en particulier d'éviter de faire transiter des
 messages en clair sur le réseau.
 ## Installation
-On se contente de tirer le logiciels des dépots de logiciels de debian : `sudo 
+
-apt install vsftpd`.
+On se contente de tirer le logiciels des dépots de logiciels de debian :
 `sudo apt install vsftpd`.
 ## Configuration
-Munissez vous de votre `man 5 vsftpd.conf` préférée et d'un bon remontant parce 
+
-que mes ailleux c'est pas clair.
+Munissez vous de votre `man 5 vsftpd.conf` préférée et d'un bon remontant
 parce que mes ailleux c'est pas clair.
 ### Configuration réseau
-L'option `listen_ipv6=YES` permet de dire au daemon d'écouter **aussi** en ipv6. 
+
-Elle ne doit donc pas être utilisée avec l'option `listen=YES` qui ne ne 
+L'option `listen_ipv6=YES` permet de dire au daemon d'écouter **aussi** en
-configurera qu'un socket ipv4.
+ipv6. Elle ne doit donc pas être utilisée avec l'option `listen=YES` qui ne
 ne configurera qu'un socket ipv4.
 Comme expliquer précedemment pour fonctionner de nos jours il est assez
-fréquen qu'un serveur ftp doivent supporter le mode passif.
+fréquent qu'un serveur ftp doivent supporter le mode passif.
-```
+
 ```txt
 # Autorise le client à demander au serveur l'utilisation du mode passif
 pasv_enable=YES
 # Configure la range de ports du serveurs vers l'un desquels le serveur pourra
@ -67,9 +78,11 @@ pasv_max_port=48000
 ```
 ### Configuration SSL
-Il est possible de fournir à vsftpd un certificat et une clé privée pour qu'un
+
-client puisse demander l'établissement d'une connexion chiffrée.
+Il est possible de fournir à vsftpd un certificat et une clé privée pour
-```
+qu'un client puisse demander l'établissement d'une connexion chiffrée.
 ```txt
 # Active le chiffrement
 ssl_enable=YES
 # Rensigne l'emplacement des certificats
@ -80,21 +93,25 @@ allow_anon_ssl=YES
 ```
 ### Écriture des logs
-On peut demander à vsftpd de logger les connexions, les téléchargements et les 
+
-téléversements au serveurs.
+On peut demander à vsftpd de logger les connexions, les téléchargements et
-```
+les téléversements au serveurs.
 ```txt
 xferlog_enable=YES
 ```
 ### Configuration des utilisateurs
 Ici la configuration des utilisateurs dépend principalement de ce que l'on
 souhaite faire avec le serveur. Je couvrirais donc les deux cas d'utilisations
 qu'on a au crans, le cas d'un mirroir de logiciel (donc accesible pour des
-utilisateurs non privilégiés en lecture seule uniquement) et le cas d'un serveur 
+utilisateurs non privilégiés en lecture seule uniquement) et le cas d'un
-où une liste d'utilisateur peut venir déposer des fichiers.
+serveur où une liste d'utilisateur peut venir déposer des fichiers.
 Pour notre premier cas d'utilisation, la configuration est triviale :
-```
+
 ```txt
 # Autorise les utilisateurs anonymes à se connecter
 anonymous_enable=YES
 # Expose le dossier /pool/mirror/pub à ces utilisateurs en lecture seule
@ -102,7 +119,8 @@ anon_root=/pool/mirror/root
 ```
 Pour le second, c'est un peu plus déclicat :
-```
+
 ```txt
 # Autorise la connexion aux utilisateurs locaux (compte unix)
 local_enable=YES
 # Restreint les utilisateurs qui peuvent se connecter à ceux présent dans
--- a/services/zamok.md
+++ b/services/zamok.md
@ -4,9 +4,14 @@
 ## Mais qui es-tu, zamok ?
-De tout temps, l'homme a cherché à répondre à la question de sa genèse. Cette page n'aidera en aucun façon. Zamok, en Nouveau Criméen, ça veut dire château. Il paraît aussi que ça veut dire « Clef », mais j'ai pas trouvé dans quelle langue.
+De tout temps, l'homme a cherché à répondre à la question de sa genèse.
 Cette page n'aidera en aucun façon. Zamok, en Nouveau Criméen, ça veut dire
 château. Il paraît aussi que ça veut dire « Clef », mais j'ai pas trouvé
 dans quelle langue.
-En tout cas, Zamok est la fidèle bécane (qui a changé cinq fois de boîte) qui permet aux adhérents geeks de se connecter à une machine tout le temps allumée pour discuter sur IRC et faire tourner à la sauvage ses algorithmes.
+En tout cas, Zamok est la fidèle bécane (qui a changé cinq fois de boîte)
 qui permet aux adhérents geeks de se connecter à une machine tout le temps
 allumée pour discuter sur IRC et faire tourner à la sauvage ses algorithmes.
 Zamok héberge aussi les créations web des adhérents ou des clubs.
@ -14,12 +19,14 @@ Ah, et les mails sont triés dessus.
 ## Les services
- * `ssh` permet d'obtenir un shell sur zamok, on peut alors avoir accès à différents services par ce biais (liste non exhaustive) :
+* `ssh` permet d'obtenir un shell sur zamok, on peut alors avoir accès à
  différents services par ce biais (liste non exhaustive) :
   * lecture de mails avec `mutt`
   * utilisation de `latex`
   * utilisation d'`emacs` et `gnus`
   * conversion d'images avec `convert`
   * différents shells Unix (dont `zsh`, `bash`, `tclsh`, `ksh`, `sh`)
- * Un serveur web qui permet l'accès aux pages personnelles des adhérents.
+* Un serveur web qui permet l'accès aux pages personnelles des adhérents.
- * Un serveur MySQL pour les pages personnelles des adhérents
+* Un serveur MySQL pour les pages personnelles des adhérents
- * C'est le serveur sur lequel les mails des comptes Cr@ns sont délivrés (procmail, spam assassin, etc)
+* C'est le serveur sur lequel les mails des comptes Cr@ns sont délivrés
  (procmail, spam assassin, etc)
--- a/tools/dns.md
+++ b/tools/dns.md
@ -1,104 +0,0 @@
 # DNS
 DNS (Domain Name System) est un protocole d'annuaire. Il utilises deux ports :
 * Le port 53 en UDP pour la plupart des échanges.
 * Le port 53 en TCP pour les échanges de grande taille (tels que du transfert de zone).
 DNS sert principalement à traduire les noms de domaines en adresse IP.
 C'est est un service hierarchisé dont le sommet est appelé la racine, et est représentée par un point (`.`). Chaque nom de domaine est découpé en plusieurs sous parties :
 Par exemple `zamok.crans.org` est un sous-domaine de `crans.org` lui-même sous-domaine de `org` qui est un sous-domaine de `.` (la racine).
 Il existe plusieurs types de serveurs DNS :
 * Les serveurs Autoritaires, qui s'occupent de garder à jour le gros dictionnaire (ou annuaire) de la zone qu'ils gouvernent (par exemple `crans.org`, `crans.eu` ou `crans.fr`)
 * Les serveurs Récursifs, qui s'occupent de faire des requêtes successives pour obtenir la valeur souhaitée, ils gardent très souvent en cache les informations récoltées, ce qui permet d'accélérer la réponse et d'éviter de surcharger les serveurs autoritaires.
 DNS permet d'associer des enregistrements (records) à des noms, ces enregistrements ont une classe et un type dont la liste est disponible [sur le site de l'IANA](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml).
 La classe utilisée traditionnellement est la classe `IN` (pour internet), voici quelques types courants :
 | Type | Description |
 |------|-------------|
 | `A` | Adresse IPv4 |
 | `AAAA` | Adresse IPv6 |
 | `CNAME` | Alias vers un autre nom de domaine |
 | `NS` | Nom d'un serveur DNS autoritaire |
 | `MX` | Nom d'un serveur mail |
 Ainsi on a par exemple les enregistrements suivants dans la zone `crans.org`:
 ```
 zamok.crans.org. IN A 185.230.79.1
 perso.crans.org. IN CNAME hodaur.crans.org.
 crans.org. IN NS silice.crans.org.
 crans.org. IN MX 10 redisdead.crans.org.
 ```
 Le 10 dans la valeur du champ MX est la priorité du serveur mail.
 ## host
 Pour résoudre des noms de domaines la commande privilégiée est la commande `host` :
 ```
 benjamin@tiamat ~ $ host zamok.crans.org
 zamok.crans.org has address 185.230.79.1
 zamok.crans.org has IPv6 address 2a0c:700:2:0:ec4:7aff:fe59:a1ad
 ```
 ```
 benjamin@tiamat ~ $ host crans.org
 crans.org has address 185.230.79.10
 crans.org has IPv6 address 2a0c:700:2::ff:fe01:4502
 crans.org mail is handled by 10 redisdead.crans.org.
 crans.org mail is handled by 15 sputnik.crans.org.
 crans.org mail is handled by 25 freebox.crans.org.
 ```
 ## dig
 La commande `dig` permet d'effectuer des requêtes DNS plus complexes que `host`, la commande `dig -t TYPE @server name` est équivalente à la commande `host -vt TYPE name server`. `dig` peut prendre des options de requête plus qui modifient son comportement, en voici quelques exemples :
 * `+short`: affiche uniquement la section de réponses de la requête et de manière compacte
 * `+dnssec`: affiche également les résultats des requêtes pour les champs DNSSEC associés à la requête demandée
 * `+rrcomments`: affiche des commentaires sur certains enregistrements
 * `+https`: effectue une query DNS over HTTPS (DoH)
 * `+trace`: fait les requêtes successives récursivement côté client afin de déterminer le résultat par exemple : `dig +trace @ns0.fdn.fr zamok.crans.org`:
   ```
   .			47747	IN	NS	a.root-servers.net.
   .			47747	IN	NS	b.root-servers.net.
   .			47747	IN	NS	c.root-servers.net.
   .			47747	IN	NS	d.root-servers.net.
   .			47747	IN	NS	e.root-servers.net.
   .			47747	IN	NS	f.root-servers.net.
   .			47747	IN	NS	g.root-servers.net.
   .			47747	IN	NS	h.root-servers.net.
   .			47747	IN	NS	i.root-servers.net.
   .			47747	IN	NS	j.root-servers.net.
   .			47747	IN	NS	k.root-servers.net.
   .			47747	IN	NS	l.root-servers.net.
   .			47747	IN	NS	m.root-servers.net.
   .			47747	IN	RRSIG	NS 8 0 518400 20220629170000 20220616160000 47671 . WGw6h2UFnKlJdCnApXM7dYkGuSpmRwokdwl0PzQMt0yUUG/Dumwpijn5 MEeOCxhoP29ni62JRMCGxgIirXVOHGfiMHDcx/dnv2gMnsr1OhQjPgwj hOu/NjZVkb612QW3b/i0mwDdjcEwRFQs9wzVZIBc4mPTFjocT2C2GlQc noLupUmliv38lfaPd+knrbhIUdwD8VEHDrzpDfdwR/kws+fWDjBcgUjA 77WzsA+FiwkqNvFIhQfMG+5CSXd0PpD3pPhdA6lCKa3l1AM4Cfnbtvj6 tuejEnNvbxsBaPOkiRz642/ysLV+fhXrP4U9BnWncUwe92NtFlZYRCHe a/D+yw==
   ;; Received 525 bytes from 2001:910:800::12#53(ns0.fdn.fr) in 23 ms
   org.			172800	IN	NS	a0.org.afilias-nst.info.
   org.			172800	IN	NS	a2.org.afilias-nst.info.
   org.			172800	IN	NS	b0.org.afilias-nst.org.
   org.			172800	IN	NS	b2.org.afilias-nst.org.
   org.			172800	IN	NS	c0.org.afilias-nst.info.
   org.			172800	IN	NS	d0.org.afilias-nst.org.
   org.			86400	IN	DS	26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
   org.			86400	IN	RRSIG	DS 8 1 86400 20220630050000 20220617040000 47671 . bKm4Ul/DPpqbqvF0gRS1Gzrmk9N0VU2Qa1dBIb/vbx6N+SEVK1wGpD20 BA6mdyFL2SOOuhEldC44N/cj401aLoli/9Bj71hdYl0XLcW/Hiq1xo2U 6Iqvfu4GwBGb36aLfce8DYEdnTtpbicXrFszx8dg2CAnFvCYLve6sA/r DOzs+K8LCsTi3cdOTuee3mEN1XC6SAfIrZDDtLEwZXiyxRAI7GbuM0i8 LCFHRa7YBlf8EOFNafkFsCi4qM4cHdnavVAxDH+gOeYnjVOd3yhezJb9 /hRBo3aIKGY1orjb+erQAOxhly26f8v2H/h0czKOXriNL7d4id8aa1fN qWiFeA==
   ;; Received 781 bytes from 199.7.83.42#53(l.root-servers.net) in 27 ms
   crans.org.		3600	IN	NS	sputnik.crans.org.
   crans.org.		3600	IN	NS	silice.crans.org.
   crans.org.		3600	IN	DS	40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2
   crans.org.		3600	IN	RRSIG	DS 8 2 3600 20220630152826 20220609142826 41346 org. EjZHR/kgXopDL/Rqw5wMWQn2AB2stt6eu0TtGHa2Gt1/LhOPraqNbXJq Ufg7VhcCRtY4DaZnp9wnBXzK9vdqUIIRMuNQoA6mEdj8qpjRajsjfPdT D87bU6h1OH5YghQAzi2N90LGgjlDqdB50xWIZHgMeLLH53nePcAcxpxE VA4=
   ;; Received 358 bytes from 2001:500:e::1#53(a0.org.afilias-nst.info) in 243 ms
   zamok.crans.org.	3600	IN	A	185.230.79.1
   zamok.crans.org.	3600	IN	RRSIG	A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5
   crans.org.		3600	IN	NS	silice.crans.org.
   crans.org.		3600	IN	NS	sputnik.crans.org.
   crans.org.		3600	IN	RRSIG	NS 14 2 3600 20220711101913 20220611094455 40871 crans.org. +BvWwsxxekrKHDFCXTL2d/pHP/2i75U6qah3Ee15SSDSQhjbnwCkI2+a Q6zGpnkwnSsB6HfRgoCbXp8r/rRzgAV7pGN06wPyejJRzkgRB+euSjbD tUmc8ODVxVWYH7iQ
   ;; Received 1041 bytes from 2a0c:700:2::ff:fe01:4702#53(silice.crans.org) in 23 ms
   ```
--- a/tools/dnssec.md
+++ b/tools/dnssec.md
@ -1,59 +0,0 @@
 # DNSSEC
 DNSSEC (Domain Name System Security Extensions) est un ensemble d'extension de sécurité pour DNS. Il permet d'authentifier les données obtenues par le protocole DNS.
 Pour cela, chaque entrée du DNS est signée cryptographiquement avec une clef privée. La clef publique, elle-même publiée dans le DNS permet de vérifier les signatures. L'authenticité de la clef publique est assurée par la zone parente (via les enregistrements DS), dans laquelle elle est publiée.
 Ainsi, il suffit de faire confiance à la clef publique de la racine du DNS (et seulement de la racine) pour pouvoir établir une chaîne de confiance dans tous le DNS.
 Les enregistrements DNS associés au DNSSEC sont les suivants :
 * `DNSKEY`: une clef publique servant à signer une zone
 * `DS`: un hash de clef publique d'une zone fille (conceptuellement proche d'un GLUE record NS)
 * `RRSIG`: une signature d'un enregistrement
 * `NSEC`: un pointeur vers la prochaine entrée DNS signée (dans l'ordre alphabétique), celui sert à prouver l'absence d'un enregistrement
 * `NSEC3`: une variante de `NSEC` où les entrées DNS sont hashées
 * `NSEC3PARAM`: des informations servant à calculer les hash pour les enregistrements `NSEC3`
 ## Exemples
 ### DNSKEY
 On lance la commande `dig -t DNSKEY @silice.crans.org crans.org`:
 ```
 ;; QUESTION SECTION:
 ;crans.org.			IN	DNSKEY
 ;; ANSWER SECTION:
 crans.org.		3600	IN	DNSKEY	257 3 14 Db282t/1HUd5ccAnJ0BSaidrnseZEtG/8Cj9MbzYl/GbgGxA8msR/Dq8 KfIeobLwnZFF5277dhdzAAdfKAb/XclhHBqpDtaV+bvd21n8MLR3yhdI VsFAde/yOBFW28fV
 crans.org.		3600	IN	DNSKEY	256 3 14 4gBTKamW1QSNWNSWkR0qVswo+GcIV7cmKf6y4zuqlinDcvN0a5+ppqW2 almA4TF7vh7u9jH2/iwZVmHiikgpTiRzZJzga158/AlYTqE4pTK6zhin YlPz9w/PTSdOXMU6
 ```
 La zone `crans.org` possède deux clefs de signature : une KSK (Key Signing Key) et une ZSK (Zone Signing Key).
 ### DS
 On lance la commande `dig -t DS @a0.org.afilias-nst.info crans.org`:
 ```
 ;; QUESTION SECTION:
 ;crans.org.			IN	DS
 ;; ANSWER SECTION:
 crans.org.		3600	IN	DS	40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2
 ```
 La zone `crans.org` a publié dans la zone `org` le hash d'une clef publique (la KSK).
 ### RRSIG
 On lance la commande `dig -t RRSIG @silice.crans.org zamok.crans.org`:
 ```
 ;; QUESTION SECTION:
 ;zamok.crans.org.		IN	RRSIG
 ;; ANSWER SECTION:
 zamok.crans.org.	3600	IN	RRSIG	A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5
 zamok.crans.org.	3600	IN	RRSIG	AAAA 14 3 3600 20220711100552 20220611093221 40871 crans.org. 2XkmJYJbeKgXK0plIB/d1nnhQ6mXhubZu4k6jASlp9BumPy6WLRPUxR1 QhFV+gidKTVidsWL6faL28HH8j4pmxVGeIC50c5NOfaBa3nVTfeD+pUp MEhC0VwhBYnODuu9
 zamok.crans.org.	3600	IN	RRSIG	SSHFP 14 3 3600 20220711100552 20220611093221 40871 crans.org. nd/HiLy0qw3NMo2Lwn8P/J2h1UaXjGWAFYPCK5ISQWBILPE5iO+TdaXy uyOy4l4Dc9hdanzvKQFBuE9hG9gkr3KpmtCEFWtHlg6PAu7MIqXTzpbV 4kR2wjiuCLfmPq2W
 ```
 `zamok.crans.org` possède trois enregistrements signés : ils sont de types `A`, `AAAA` et `SSHFP`.
--- a/tools/gpg.md
+++ b/tools/gpg.md
@ -1,25 +0,0 @@
 # GPG
 GPG (GNU Privacy Guard) est une implémentation libre et open source du protocole OpenPGP (Pretty Good Privacy), un protocole cryptographique permettant de signer, chiffrer et déchiffrer des documents (notamment des emails).
 # Clef
 Une clef GPG est une clé numérique qui permet d'être identifié de façon unique dans le monde numérique. 
 Elle est composée de deux éléments :
 * une clé privée protégée par une phrase clé qui permet d'éviter à une tierce personne d'utiliser cette clef si elle parvient à la voler
 * une clé publique qui une fois distribuée et signée par son entourage, permet à celui-ci de vérifier que les messages que l'on signe le sont bien avec la clé privée associée à cette clé publique
 Elle peut être générée à l'aide d'une des commandes suivantes (selon le nombre d'option que vous souhaitez avoir) :
 * `gpg --generate-key`
 * `gpg --full-generate-key`
 * `gpg --full-generate-key --expert`
 # Web of trust
 Le web of trust (ou toile de confiance en français) permet d'établir l'authenticité de l'appartenance d'une clef publique ; il est décentralisé : il n'a donc pas besoin d'autorité de certification.
 Voici les règles par défaut du web of trust d'OpenPGP, on estime que la clef publique appartient au bon propriétaire si :
 * On a soi-même fait confiance à cette clef
 * Une personne en qui on a totalement confiance a signé cette clef
 * Trois personnes en qui on a partiellement confiance ont signé cette clef
--- a/tools/http.md
+++ b/tools/http.md
@ -1,5 +0,0 @@
 # HTTP
 HTTP (Hypertext Transfer Protocol) est un protocole permettant de servir un site web. Il utilise le port 80.
 Sa version sécurisé (HTTPS) consiste en une intégration de [TLS](tools/tls.md) au protocole et utilise le port 443.
--- a/tools/ip.md
+++ b/tools/ip.md
@ -1,91 +0,0 @@
 # IP
 ## Généralités
 IP (Internet Protocol) est le protocole principal de communication sur l'internet, actuellement deux versions sont en cours d'utilisation : IPv4 et IPv6.
 IP permet de transmettre des datagrammes d'un point à un autre.
 ### Adressage
 Les adresses IP sont alloués avec la méthode du CIDR (Classless Inter-Domain Routing). Cette méthode consiste à noter une adresse au format `adresse/longueur_préfixe`, elle induit une attribution des IP par blocs.
 Les `n` bits (où `n` est la longueur du préfixe) les plus significatifs servent à identifier le réseau auquel l'adresse appartient.
 ## IPv4
 Une adresse IPv4 s'écrit sur 32 bits et utilise une notation décimale pointée (4 entiers séparés par des `.`), par exemple `192.168.0.1` est une adresse IPv4.
 De même `192.168.0.0/24` est un exemple de notation CIDR pour un sous-réseau IPv4.
 Dans un réseau local les adresses IPv4 peuvent être attribuées par le protocole DHCP ou configurées statiquement.
 À noter que dans un sous-réseau IPv4 la première et la dernière sont réservées respectivement pour identifier le réseau et effectuer du broadcast : par exemple pour le bloc `192.168.0.0/24`, l'adresse `192.168.0.0` est réservée et l'adresse `192.168.0.255` est l'adresse de broadcast.
 Cette restriction peut être contournée sous Linux, par exemple sous [Debian](/tools/debian.md) on peut modifier l'interface comme ceci :
 ```
 iface eth0 inet static
    broadcast -
 ```
 Ceci permet d'utiliser des blocs d'adresses IPv4 d'une taille de préfixe égale à 31 afin d'interconnecter deux machines.
 ### IPv4 privées
 Certains blocs d'adresses IPv4 sont réservés à des utilisations privées, celà signifie qu'ils ne sont pas annoncés sur l'internet. Ils sont spécifiés par la [RFC 1918](https://tools.ietf.org/html/rfc1918) et sont les suivants :
 * `10.0.0.0/8`
 * `172.16.0.0/12`
 * `192.168.0.0/16`
 ### IPv4 de lien local
 Un bloc d'IPv4 est réservé pour utilisation sur le réseau local, c'est à dire que ce bloc n'est normalement jamais routé, il s'agit du bloc `169.254.0.0/16`.
 ### IPv4 multicast
 un bloc d'IPv4 est réservé pour du multicast, il s'agit du bloc `224.0.0.0/4`.
 ## IPv6
 Une adresse IPv6 s'écrit sur 128 bits et utilise une notation hexadécimale séparée par des `:` (deux-points), par exemple `2001:0db8:0000:0000:0000:0000:0000:0000` (on regroupe les octets par groupe de 2).
 Il existe également une notation compacte pour les adresses IPv6 : on peut omettre les 0 en début de bloc et remplacer la plus longue suite de blocs nuls par `::`, par exemple l'adresse précédente peut s'écrire `2001:db8::`.
 Ainsi `2001:db8::/32` est un exemple de notation CIDR pour un sous-réseau IPv6.
 Dans un réseau local les adresses IPv6 peuvent être attribuées par le protocole NDP, par le protocole DHCPv6 ou configurées statiquement.
 La liste des IPv6 attribuées est disponible [ici](https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml) et [là](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml).
 Il n'y a pas de broadcast en IPv6 et la première adresse du bloc peut être utilisée sans risque. Le broadcast est remplacé par du multicast : tous les nœuds sur le réseau local répondent sur l'adresse `ff02::1`.
 ### IPv6 uniques locales
 Un bloc d'adresses IPv6 est réservé pour des utilisations privées, c'est l'équivalent des blocs d'IPv4 privées. Il s'agit du bloc `fc00::/7`
 ### IPv6 de lien local
 Un bloc d'IPv6 est réservé pour utilisation sur le réseau local, il s'agit du bloc `fe80::/10`.
 ### IPv6 multicast
 Un bloc d'IPv6 est réservé pour du multicast, il s'agit du bloc `ff00::/8`.
 ## ip
 Sous Linux la commande privilégiée pour consulter l'état de la configuration réseau est `ip` (fournie par la suite `iproute2`) voici quelques exemples de commandes :
 Afficher l'état des interfaces de la machine (adresses IP attribuées et leur sous-réseau) :
 ```bash
 ip address
 ```
 Afficher l'état des routes IPv4 de la machine :
 ```bash
 ip route
 ```
 Afficher l'état des routes IPv6 de la machine :
 ```bash
 ip -6 route
 ```
--- a/tools/irc.md
+++ b/tools/irc.md
@ -1,19 +0,0 @@
 # IRC
 IRC (Internet Relay Chat) est un protocole de communication textuelle. C'est le protocole privilégié pour les discussions instantanées entre membres actifs.
 Sa version 2 est spécifiée par la [RFC 2812](https://tools.ietf.org/html/rfc2812), une [version 3](https://ircv3.net/) est en cours de développement.
 Il utilise 2 ports :
 * Le port 6667 en TCP pour la communication en clair.
 * Le port 6697 en TCP pour la communication chiffrée avec TLS.
 Il existe deux types d'entités dans le protocole IRC : les utilisateurs et les canaux. Un nom d'utilisateur (nick) commence obligatoirement par une lettre ou un des caractères spéciaux définis dans la RFC. Un nom de canal commence obligatoirement par un caractère `#`, `&`, `!` ou `+`, en pratique seul le `#` est implémenté de manière universelle.
 Le protocole IRC utilise des commandes, dans la plupart des clients il est possible d'envoyer une commande en entrant un `/` suivi de la commande dans le prompt du client.
 ## Modes
 Il est possible d'attribuer des «flags» aux utilisateurs et aux canaux qui permettent de modifier leur comportement, ceux-ci s'appellent des modes, certains modes sont spécifiés dans la RFC mais la quasi-totalité des serveurs IRC implémentent d'autres modes pour ajouter des fonctionnalités au protocole.
 Ces modes sont manipulables avec la commande `MODE`, par exemple `MODE nick +w` pour ajouter le mode `w` à l'utilisateur `nick` ou `MODE #channel -t` pour retirer le mode `t` du canal `#channel`.
--- a/tools/ldap.md
+++ b/tools/ldap.md
@ -1,3 +0,0 @@
 # LDAP
 LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à une base donnée arborescente (directory). Sa dernière version (version 3) est spécifiée dans la [RFC 4511](https://tools.ietf.org/html/rfc4511).
--- a/tools/nfs.md
+++ b/tools/nfs.md
@ -1,11 +0,0 @@
 # NFS
 NFS (Network File System) est un système de fichiers pouvant être monté à travers le réseau : le serveur NFS expose des parties de son arborescence qui peuvent être montées par les clients.
 NFS utilise le port 2049 en TCP et en UDP.
 Le système de fichier ZFS supporte nativement l'export NSF de tout ou partie de son arborescence, vous pouvez vous référer à la section *Partager un dataset en NFS* de la page ZFS pour savoir comment faire.
 ## Version 4
 La dernière version de NFS est la version 4.2 spécifiée par la [RFC 7862](https://tools.ietf.org/html/rfc7862).
--- a/tools/ntp.md
+++ b/tools/ntp.md
@ -1,5 +0,0 @@
 # NTP
 NTP (Network Time Protocol) est un protocole de synchronisation d'horloge, il utilise le port 123 en UDP.
 Sa version 4 est spécifiée par la [RFC 5905](https://tools.ietf.org/html/rfc5905).
--- a/Show More
+++ b/Show More
		`@ -0,0 +1 @@`
							`style "#{File.dirname(__FILE__)}/.mdstyle.rb"`
		`@ -1,3 +0,0 @@`
			`# LDAP`

			`LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à une base donnée arborescente (directory). Sa dernière version (version 3) est spécifiée dans la [RFC 4511](https://tools.ietf.org/html/rfc4511).`