Enlève tout et lie vers le wiki à la place

20 files changed, 0 insertions, 834 deletions

diff --git a/src/Technique/Développement/Bottin.md b/src/Technique/Développement/Bottin.md
deleted file mode 100644
index 4f7d464..0000000
--- a/src/Technique/Développement/Bottin.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Bottin
-
-Bottin est un annuaire LDAP distribué développé en Go visant la simplicité d'installation et d'utilisation (comparé à des solutions comme OpenLDAP ou Keycloak) tout en offrant la résilience que l'on peut attendre d'un système d'authentification. Il se base pour le stockage distribué sur [Consul](https://www.consul.io/).
-
-## Statut du développement
-
-Bottin est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif.
-Le code de Bottin se trouve ici : https://git.deuxfleurs.fr/Deuxfleurs/bottin
diff --git a/src/Technique/Développement/Diplonat.md b/src/Technique/Développement/Diplonat.md
deleted file mode 100644
index 1345b36..0000000
--- a/src/Technique/Développement/Diplonat.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Diplonat
-
-Diplonat est un utilitaire qui facilite l'hébergement de services dans un environnement réseau dynamique. Le cas le plus commun est lorsqu'il faut exposer un serveur situé dans un sous-réseau domestique, derrière un routeur souvent fourni par un FAI grand public. Diplonat aide alors à gérer les règles NAT de la passerelle, les règles de pare-feu du serveur lui-même, et potentiellement l'enregistrement DNS pour qu'il suive l'IP dynamique du sous-réseau.
-
-## Status du développement
-
-Diplonat est en développement, le code est versionné ici : https://git.deuxfleurs.fr/Deuxfleurs/diplonat . Il est exploité dans le cadre des activités de deuxfleurs.
diff --git a/src/Technique/Développement/Garage/index.md b/src/Technique/Développement/Garage/index.md
deleted file mode 100644
index af6103b..0000000
--- a/src/Technique/Développement/Garage/index.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Garage
-
-Garage est un utilitaire de stockage d'objets léger, distribué, et compatible avec l'interface Amazon S3. Il poursuit les objectifs suivants :
-
-* être aussi autonome que possible
-* être facile à installer
-* demeurer robuste face aux pannes de réseau, à la latence du réseau, aux pannes de disques durs, et aux erreurs d'administrateurs système
-* être simple
-* être déployé sur de multiples centres de donnée
-
-Il ne cherche pas à :
-
-* fournir des performances exceptionnelles
-* implémenter complètement l'API de S3
-* implémenter des codes d'effacement (notre modèle consiste en dupliquer les données telles quelles sur plusieurs nœuds)
-
-À l'heure actuelle, Garage est déployé sur notre grappe de serveurs (ce site même est hébergé sur Garage !), mais doit tout de même être considéré comme une démonstration technique.
-
-Si vous voulez en savoir plus sur Garage, vous pouvez consulter notre [documentation](https://garagehq.deuxfleurs.fr/) :
-
-* [Introduction rapide](https://garagehq.deuxfleurs.fr/quick_start/index.html) : apprenez à interagir efficacement avec Garage
-* [Travaux liés](https://garagehq.deuxfleurs.fr/design/related_work.html) : pour comprendre pourquoi nous avons développé notre propre logiciel au lieu d'en choisir un existant
-* [Technique interne](https://garagehq.deuxfleurs.fr/design/internals.html) : une brève description des modèles de données utilisés dans Garage
-
-Liens externes :
-
-* [Dépôt](https://git.deuxfleurs.fr/Deuxfleurs/garage/) : Garage est un logiciel libre développé sur notre propre instance Gitea
-
-Conférences :
-
-* [(en français, et informel) 2 décembre 2020 : pourquoi nous avons choisi de réinventer la roue](https://git.deuxfleurs.fr/Deuxfleurs/garage/raw/branch/main/doc/talks/2020-12-02_wide-team/talk.pdf)
-* [(en anglais, et formel) 28 avril 2021 : le stockage objet distribué est centralisé](https://git.deuxfleurs.fr/Deuxfleurs/garage/raw/branch/main/doc/talks/2021-04-28_spirals-team/talk.pdf)
\ No newline at end of file
diff --git a/src/Technique/Développement/Guichet.md b/src/Technique/Développement/Guichet.md
deleted file mode 100644
index 089622a..0000000
--- a/src/Technique/Développement/Guichet.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Guichet
-
-Guichet est une interface de gestion utilisateur LDAP pour Bottin.
-Il vise notamment à permettre aux utilisateurs de modifier leurs identifinats ainsi que leurs données personnelles.
-
-## Statut du développement
-
-Guichet est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif.
-Le code est ici : https://git.deuxfleurs.fr/Deuxfleurs/guichet
diff --git a/src/Technique/Développement/index.md b/src/Technique/Développement/index.md
deleted file mode 100644
index e69de29..0000000
--- a/src/Technique/Développement/index.md
+++ /dev/null
diff --git a/src/Technique/Infra/Energie.md b/src/Technique/Infra/Energie.md
deleted file mode 100644
index ee70536..0000000
--- a/src/Technique/Infra/Energie.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# Énergie
-
-## Notre avis
-
-Aujourd'hui Google se targue d'utiliser 100% d'énergie renouvelable (EnR) dans ses datacenters, rendant toute alternative inutile ? Pas si vite, la comparaison n'est pas simple : les énergies renouvelables ne produisent pas en permanence, le nucléaire est peu carbonné, les éoliennes ont une durée de vie courte et génèrent des rejets lors de leur fabrication, etc. 
-
-Bien que l'on pourrait faire de longues comparaisons, nous pensons que les enjeux sont ailleurs : dans les usages et le renouvellement du matériel. En effet, il faut utiliser 48 ans un ordinateur pour qu'il émette autant de carbone via sa consommation électrique en France qu'il en a nécessité pour sa fabrication. Et ça vaut également pour les smartphones et les serveurs. En sachant qu'un téléphone est renouvellé en moyenne tous les deux ans, qu'un ordinateur probablement tous les 5 ans ou moins et que les serveurs sont souvent renouvellés en entreprise à l'expiration de leur garantie, dans les 5 ans donc, les appareils numériques polluent avant tout lors de leur fabrication. À celà s'ajoute de nombreux gadgets vendus par les GAFAM comme les assistants personnels, les montres connectés, etc. qui eux aussi génèrent de la pollution lors de leur fabrication et à l'usage. 
-
-**Nous choisissons donc de créer nos propres infrastructures en réponse pour agir efficacement là où ça compte : moins de matériel, renouvellé moins souvent.
-Nous proposons donc des services standards et sobres et compatibles avec vos appareils existants.
-De notre côté, nous utilisons longtemps nos serveurs achetés d'occasions et minimisons leur nombre**. 
-
-D'où sont tirées ces infos ? Vous voulez en savoir plus ? C'est par ici :
-  - [Le numérique carbure au charbon (Monde Diplomatique, mars 2020, payant)](https://www.monde-diplomatique.fr/2020/03/BROCA/61553)  
-    - [Brochure de l'article (accès libre)](https://tarage.noblogs.org/post/2020/02/26/le-numerique-carbure-au-charbon-sebastien-broca/)  
-    - [Miroir local de la brochure (accès libre)](./assets/charbon.pdf)
-  - [Quelle est l’empreinte carbone d’un ordinateur ? (Green IT, février 2011, accès libre)](https://www.greenit.fr/2011/02/10/quelle-est-l-empreinte-carbone-d-un-ordinateur/)
-
-## Évaluation empirique de notre consommation
-
-(Quentin, atuin.site) Durant l'épidémie SARS-COV-2, mon appartement était vide durant un mois.
-L'occasion d'estimer au plus près la consommation énergétique de mes composants à partir de la facture EDF.
-
-Mes composants allumés durant ce mois :
-  * Un réfrigérateur demi taille sous le plan de travail
-  * Une freebox mini 4k
-  * Un switch netgear
-  * 3 Lenovo Thinkcentre M82
-
-La facture d'avril 2020 me donne :
-  * 87 kWh pour 23€
-
-On rappelle `P = E / t`  
-Sur un mois on a donc `P [en W] = E [en kWh] * 1000 / (30 [en jours] * 24 [en heures/jours])`  
-Autrement dit : `P = E * 1.388889` et `E = P / 1.38889`
-
-On estimera également à partir d'une recherche rapide sur interne que le réfrigérateur consomme environ 120 kWh par an, donc 10 kWh par mois.
-
-Quelques déductions :
-  * Prix du kWh : 0,26€
-  * Énergie par mois dédiée pour deuxfleurs.fr : 77 kWh
-  * Consommation instantanée équivalente : 106 W
-  * Coût en électricité : 20€ 
-
-Selon Maximilien, quelques puissances indicatives :
-  * Un PC de bureau c'est entre 25 et 30 W
-  * Son serveur Dell R710 c'est environ 100 W en *idle*
-  * Un routeur haut de gamme c'est 13 W
-
-Ces données sont bien cohérentes avec les résultats précédents.
-On peut estimer le coût en électricité de chacun de ces appareils au passage (considérant qu'ils restent allumés le mois entier) :
-  * Un Dell R710 : 100W -> 19 €/mois
-  * Une tour type Lenovo Thinkcentre M82 : 28 W -> 5,2 €/mois
-  * Un routeur ou un switch : 10 W -> 1,9 €/mois
-
-Pour continuer la réflexion, il serait intéressant d'étudier la consommation des serveurs à base ARM considérant notre charge.
-Cependant, avoir des tours semble être plus pertinent que des serveurs pro qui consomment toujours beaucoup comparés à une tour (bien que les performances ne soient pas comparables, bien entendu).
-Idéalement, avoir des mesures directement sur les équipement permettrait d'avoir des mesures plus solides et pouvoir mieux identifier les équipements énergivores.
-
-**Moins cher dans un datacenter ?** - Scaleway et OVH proposent des VPS à des prix compétitifs (à partir de 3 €/mois). Mettre une vieille machine en auto-hébergement peut donc couter plus cher en électricité que louer une machine chez eux. En se focalisant seulement sur ces deux points, on pourrait identifier un point de bascule puissance/énergie à partir duquel il devient plus intéressant de s'auto-héberger que d'externaliser. Avec les Lenovo Thinkcentre M82 des machines qui ont 5 ans, on est à peine gagnant : pour 5€ d'électricité par mois, une machine équivalente en *bare metal* en location dans un datacenter coûte dans les 10€ à 15€. Mais même la, la différence de prix reste faible. Je vois deux explications : 
-  * du matériel qui consomme moins 
-  * de l'électricité moins chère. 
-
-**On consomme plus alors ?** - Pour avoir une approche écologique, il nous faudrait donc comparer la consommation des serveurs et non les prix finaux pratiqués par les hébergeurs. Et pour comparer le renouvellement du matériel, il faudrait comparer la consommation énergétique sur la durée de vie complète de l'appareil en y incluant **sa frabrication**.
-À mon avis le bilan écologique de l'auto-hébergement n'est pas pire qu'en datacenter et pourrait même être meilleur...
-
-
diff --git a/src/Technique/Infra/Internet.md b/src/Technique/Infra/Internet.md
deleted file mode 100644
index 2ab66e4..0000000
--- a/src/Technique/Infra/Internet.md
+++ /dev/null
@@ -1,88 +0,0 @@
-Cette page regroupe un résumé de tous les problèmes que vous pourriez rencontrer en voulant faire de l'auto hébergement avec "votre connexion internet".
-
-## Côté Opérateur
-
-
-### Congestion
-
-#### Congestion sur la livraison
-
-Entre janvier et mars, les serveurs hébergés derrière une connexion Free ont eu des problèmes en soirée.
-Le problème a été résolu depuis.
-
-Plus d'informations ici : https://www.aduf.org/viewtopic.php?t=286599&start=0
-
-#### Congestion liée au peering
-
-*À compléter*
-
-### Adressage
-
-#### Pas d'IPv4 publique
-
-Certains FAI ne donnent pas d'IPv4 publique du tout (même pas au niveau du routeur).
-À la place, ils mettent en place un NAT nommé carrier-grade NAT que vous ne pouvez pas configurer.
-Parfois, il suffit de les appels.
-
-Exemple : Ora/Viti en Polynésie française
-
-#### Pas d'IPv6 du tout
-
-FAI connus pour ne pas proposer d'IPv6 :
-
-* SFR/FTTH
-
-#### IPv6 de mauvaisee qualité
-
-*Ajouter des explications à propos du tunneling*
-
-#### Adresse IP publique dynamique
-
-FAI connus pour proposer une adresse IP publique dynamique :
-
-* Orange/ADSL (rotation quotidienne et à chaque resynchro)
-* Orange/FTTH (rotation ~1 fois/mois)
-
-### Autre
-
-#### Blocage du port 25 en sortie (impossibilité d'héberger un serveur email)
-
-* Débloquable chez Free/\* dans l'interface (gratuit)
-* Bloqué chez Orange/\* (sauf à passer sur une offre pro et encore...)
-* Débloqué chez SFR/FTTH
-* Débloqué chez Numéricable/Coaxial
-* Inconnu chez Bouygues/\*
-
-#### Reverse DNS
-
-*Expliquer pourquoi c'est utile*
-
-* Orange : Ne propose pas de configurer le reverse
-* SFR : Inconnu, probablement que non
-* Numéricable : Inconnu, probablement que non
-* Bouygues : Inconnu, probablement que non
-* Free : Oui mais service cassé dans certains cas (récupérations d'IPv4)
-
-## Chez vous
-
-### Votre routeur ("box")
-
-#### NAT hairpinning
-
-Vous avez besoin du NAT hairpinning pour accéder aux services publics que vous proposez derrière un NAT depuis le réseau interne du serveur. Typiquement quand vous n'avez que de l'IPv4 et qu'une seule IP publique portée par votre routeur.
-
-*Ajouter de la doc sur le NAT hairpinning*
-
-Routeurs connus pour avoir des problèmes de NAT hairpinning :
-
-* Orange : Probablement toutes les box
-  * Livebox 2 Sagem
-  * Livebox 4 Sagemcom
-* Bouygues : Suspicions sur toutes les box
-* Free : 100% OK
-* Numéricable : Inconnu
-* SFR : Inconnu
-
-#### Problèmes de qualité du routeur
-
-*À compléter*
diff --git a/src/Technique/Infra/assets/charbon.pdf b/src/Technique/Infra/assets/charbon.pdf
deleted file mode 100644
index 492da2f..0000000
--- a/src/Technique/Infra/assets/charbon.pdf
+++ /dev/null
diff --git a/src/Technique/Infra/img/fbx.jpg b/src/Technique/Infra/img/fbx.jpg
deleted file mode 100644
index ee4e1cd..0000000
--- a/src/Technique/Infra/img/fbx.jpg
+++ /dev/null
diff --git a/src/Technique/Infra/img/io.jpg b/src/Technique/Infra/img/io.jpg
deleted file mode 100644
index 79f6685..0000000
--- a/src/Technique/Infra/img/io.jpg
+++ /dev/null
diff --git a/src/Technique/Infra/img/lenovo.jpg b/src/Technique/Infra/img/lenovo.jpg
deleted file mode 100644
index 08f05b7..0000000
--- a/src/Technique/Infra/img/lenovo.jpg
+++ /dev/null
diff --git a/src/Technique/Infra/index.md b/src/Technique/Infra/index.md
deleted file mode 100644
index 713e220..0000000
--- a/src/Technique/Infra/index.md
+++ /dev/null
@@ -1,191 +0,0 @@
-# Infrastructure
-
-## Physique
-
-Un site est constitué de l'ensemble du matériel à un lieu donné géré par une (ou plusieurs) personne donnée.
-Le lieu géographique peut évoluer dans le temps, comme par exemple lors d'un déménagement.
-Le nommage du site est donc arbitraire, nous recommandons le choix d'un corps céleste, tout aussi étrange soit-il.
-Ce découpage en sites est important pour certaines de nos applications.
-
-### 🐢 atuin.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Alex et Quentin |
-| Hébergement | 🏡 Quentin |
-| Région | Bretagne |
-| FAI | Free - 1Gbps, ✅ IPv4 publique, ✅ IPv4 fixe, ✅ IPv6 publique, ✅ IPv6 fixe, ✅ SMTP, ❌ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| Lenovo Thinkcentre M82 | Serveur | x3 | Intel G3420 @ 3.20GHz (2 cœurs), 8Go RAM, 128GB SSD, 1TB HDD | ![photo serveur](img/lenovo.jpg)
-| Freebox Mini 4k | Routeur | x1 | 4 ports @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique |![photo freebox](img/fbx.jpg)
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| [deuxfleurs.fr](https://deuxfleurs.fr) | Site principal de Deuxfleurs |
-| [garagehq.deuxfleurs.fr](https://garagehq.deuxfleurs.fr) | Site web de Garage |
-| [Synapse](https://im.deuxfleurs.fr) | Serveur Matrix |
-| [Element](https://riot.deuxfleurs.fr) | Client web pour Matrix |
-| [Jitsi](https://jitsi.deuxfleurs.fr) | Service de visioconférence |
-| [SoGo](https://sogo.deuxfleurs.fr) | Client mail SoGo |
-| [Alps](https://alps.deuxfleurs.fr) | Client mail Alps (plus léger) |
-| [Plume](https://plume.deuxfleurs.fr) | Blog collaboratif et fédéré |
-| [Platôo](https://platoo.deuxfleurs.fr) | Jeux de plateau en ligne |
-| [Drone](https://drone.deuxfleurs.fr) | Serveur d'intégration continue |
-| [Garage](https://garage.deuxfleurs.fr) | Serveur de stockage de données |
-
-### ⚔️  mars.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Adrien (et Quentin) |
-| Hébergement | 🏢 Gandi |
-| Région | Île-de-France |
-| FAI | Gandi -  ✅ IPv4 publique, ✅ IPv4 fixe, ❓ IPv6 publique, ❓ IPv6 fixe, ❓ SMTP, ❓ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| VPS | Serveur | x1 | 1 vCPU, 3Go RAM, 70 GB Block Storage | N/A |
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| [Gitea](https://git.deuxfleurs.fr) | Forge logicielle |
-
-### 🪐 saturne.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Alex |
-| Hébergement | 🏢 Kimsufi (filiale d'OVH) |
-| Région | Hauts-de-France |
-| FAI | OVH - ✅ IPv4 publique, ✅ IPv4 fixe, ✅ IPv6 publique, ✅ IPv6 fixe, ✅ SMTP, ✅ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| Kimsufi | Serveur | x1 | Intel Atom N2800 @ 1.86Ghz (4 cœurs), 4Go RAM, 2TB HDD, réseau 100Mbit/s | N/A |
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| [Cryptpad](https://p.adnab.me) | Suite bureautique chiffrée de bout en bout |
-
-### ✉️  mercure.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Quentin et Maximilien |
-| Hébergement | 🏡 Maximilien |
-| Région | Île-de-France |
-| FAI | Free 10Gbps/700Mbps - ✅ IPv4 publique, ✅ IPv4 fixe, ✅ IPv6 fixe, ✅ IPv6 publique, ❌ SMTP, ❌ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| [Microtik RB4011iGS+RM](https://mikrotik.com/product/rb4011igs_rm) | Routeur | x1 | Routeur et pare-feu, ports 1x10G SFP+ et 10x1G | TBA |
-| Serveur Dell R710  | Hyperviseur | x3 | 2 socket, Xeon E5520 (4c8t @ 2.26Ghz), 80Go RAM, 500GB NVMe, 1TB RAID matériel, réseau LACP 2x1G | TBA |
-| metro.mercure.site | LXC | x1 | 2 CPU, 2Go RAM, 25 GB NVMe | N/A |
-| bkp.mercure.site | VM | x1 | 4 vCPU, 8Go RAM, 40 GB Block Storage | N/A |
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| [Grafana](https://grafana.home.mricher.fr) | Interface de monitoring de l'infrastructure |
-| | Target de backups (Consul) |
-
-### ☁️  bespin.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Quentin et Maximilien |
-| Hébergement | 🏡 Maximilien |
-| Région | 🇧🇪 Belgique |
-| FAI | Telenet 1Gbps/40Mbps - ✅ IPv4 publique, (✅) IPv4 fixe, (✅) IPv6 fixe, ✅ IPv6 publique, ❌ SMTP, ❌ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| Tour récente | Hyperviseur | x1 | 4 CPU @ 4.3Ghz (i5-3570k), 16Go RAM, 2xSSD 500GB RAID1, 6 HDD 4TB RAID6 (14Tio utile) | N/A |
-| drone-runner.bespin.site | VM | x1 | 4 vCPU, 6Go RAM, 40Go SSD | N/A |
-
-| Service | Description |
-| -- | -- |
-| Drone (runner) | Worker pour l'intégration continue |
-
-### ♃ jupiter.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Jill, Alex et Quentin |
-| Hébergement | 🏡 Jill & Trinity |
-| Région | Bretagne |
-| FAI | Free - (✅) IPv4 publique, (✅) IPv4 fixe, ✅ IPv6 fixe, ✅ IPv6 publique, (✅) SMTP, ❌ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| Tour un peu vieille | Serveur | x1 | 4 cœurs, 4Go RAM, SSD 250Go + HDD 2To | [ici](img/io.jpg) |
-| Freebox | Routeur | x1 | N/A | N/A |
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| Garage | Serveur de stockage de données |
-
-### ♆ neptune.site
-
-Informations générales :
-
-| Caractéristiques | Détails |
-| --: | :-- |
-| Administration | Alex |
-| Hébergement | 🏡 Alex |
-| Région | Ile de France |
-| FAI | Free (bientôt) - (✅) IPv4 publique, (✅) IPv4 fixe, ✅ IPv6 fixe, ✅ IPv6 publique, (✅) SMTP, ❌ Reverse DNS |
-
-Liste du matériel :
-
-| Désignation | Rôle | Quantité | Détails | Image |
-| -- | -- | -- | -- | -- |
-| ThinkCentre M73 Tiny | Serveur | x1 | 4 cœurs, 8Go RAM, SSD 120Go | N/A |
-| ThinkCentre M73 Tiny | Serveur | x2 | 4 cœurs, 8Go RAM, SSD 240Go | N/A |
-| WRT54G v3.1 | Switch/Routeur | x1 | 5 ports 100Mbit + wifi 802.11b/g | N/A |
-| Freebox (bientôt) | Routeur | x1 | N/A | N/A |
-
-Services hébergés :
-
-| Service | Description |
-| -- | -- |
-| Garage | (bientôt) Noeuds du cluster de prod ET/OU du cluster staging |
-
-## Réseau
-
-## Logiciel
diff --git a/src/Technique/Jalon/CHATONS.md b/src/Technique/Jalon/CHATONS.md
deleted file mode 100644
index 0c509bf..0000000
--- a/src/Technique/Jalon/CHATONS.md
+++ /dev/null
@@ -1,17 +0,0 @@
-Nous souhaiterions devenir un CHATON, pour ça il faudrait au moins :
-
-- Avoir des backups sur les services "stables"
-- Avoir des performances satisfaisantes sur les services, actuellement ces services cochent les cases :
-  - Jitsi
-  - Riot/Matrix
-  - CryptPad
-  - Gitea
-- Avoir un modèle plus clair / écrire plus largement comment un membre peut nous rejoindre
-- Corriger les problèmes de robustesse simple de l'infrastructure :
-  - Ordonancement des services au boot
-    - Nomad démarre avant que le réseau soit prêt
-    - Consul démarre avant que le réseau soit prêt
-    - GlusterFS n'a pas démarré quand le fstab est lu, donc la partition n'est pas montée
-  - Reconfiguration du NAT / des ports dans le firewall
-    - En cours via le développement de Diplonat
-- Compléter cette liste en lisant la charte du site web des chatons
diff --git a/src/Technique/Jalon/Interconnexion.md b/src/Technique/Jalon/Interconnexion.md
deleted file mode 100644
index 864e376..0000000
--- a/src/Technique/Jalon/Interconnexion.md
+++ /dev/null
@@ -1,117 +0,0 @@
-# Interconnectons nos infrastructures
-
-*Ce document est une "demande de commentaire". Amendez-le, modifiez-le, ajoutez vos réserves ou vos solutions alternatives librement.*
-
-## Contexte
-
-Nous avons une architecture type micro-services.
-Chaque service n'est pas attaché à une machine, il peut en changer pour mieux répartir la charge ou en cas d'incident.
-La plupart de ces services sont consommés en interne, leur adresse est découverte grâce au serveur DNS exposé par Consul. Ils ne sont donc pas exposés sur internet.
-Principe de minimisation de la surface d'attaque : consommé en interne donc pas de raison d'être disponible en externe.
-Qui plus est, la communication entre ces services se fait souvent en clair pour des raisons de simplicités.
-Ce n'est pas (trop) problématique, car le réseau interne n'est pas (supposé) surveillé.
-
-## Problème
-
-On ne peut pas consommer les services internes d'une infrastructure A depuis une infrastructure B.
-Par exemple, on voudrait que le serveur LDAP géré par Quentin soit consommable par le serveur Git géré par Adrien, avec ces propriétés :
-
-* sans qu'il soit exposé directement sur internet,
-* sans que la communication entre A et B puisse être espionnée,
-* sans que le service soit "attaché" à une machine en particulier.
-
-## Difficultés techniques
-
-D'un point de vue topologie réseau, on a une première contrainte, le NAT en IPv4.
-En effet, si on a des serveurs derrière un même NAT ils auront envie de communiquer via l'IP interne.
-Mais les algos de gestion de membre (membership management) de Consul & co pourrait être empoisonné par ces IPs qui n'auraient que de valeur en interne.
-Après, on peut imaginer qu'on leur donne que l'IP externe pour communiquer, et se baser sur le NAT hairpinning de la box pour les communications intra cluster, mais ça rajoute une pression inutile sur la box : tout le traffic inter cluster sera rerouté et réécrit par la box, on se retrouve avec des traitements L3 inutiles.
-C'est particulièrement critique si on commence à faire du transfert de données (comme Garage par exemple).
-
-## Être adressable sur Internet
-
-Cette complexité devrait être évitée à mon avis. Pour cela je propose de baser nos communications de cluster via IPv6 seulement pour pouvoir adresser tout le monde directement. Je propose d'éditer un cahier des charges de la configuration minimale qu'une personne doit remplir pour s'interconnecter à l'infrastructure Deuxfleurs. Voilà une ébauche :
-
-- Avoir une IPv6 routable sur Internet
-- Ne pas avoir de filtrage de port imposé par son fournisseur d'accès (exception possible pour le port 25 en sortie...)
-- Avoir au minimum 1Go de RAM
-- Avoir un processeur x86
-
-## Trouver un service et chiffrer systématiquement
-
-Maintenant que toutes les machines de toutes les infrastructures peuvent toutes communiquer entre elles, il nous reste encore deux problèmes :
-- Les services ne sont pas attachés à une machine, et donc pas attachés à une adresse réseau
-- Le trafic passant en clair sur internet est supposé espionné
-
-Il nous faut donc deux propriétés qui découlent directement de ces deux besoins :
-- Un moyen de permettre à un service C de communiquer avec un service D
-- Chiffrer systématiquement le traffic qui part sur internet
-
-Voici quelques solutions auxquelles je pense :
-
-### La *low-tech* : TLS au niveau applicatif et Consul DNS en service discovery
-
-Étant donné que toutes les machines sont adressables en IPv6, on pourrait imaginer continuer dans la lancée actuelle et enregistrer l'IPv6 publique plutôt que l'IPv4 privée. Il faudrait s'assurer que les applications fassent elles-mêmes le TLS au niveau applicatif. Mais ça voudrait dire que les services seraient exposés sur Internet en IPv6 et que notre seule protection serait le controle d'authentification réalisée par l'application (pour l'auth) et le TLS applicatif pas oublié (pour le chiffrement - et l'auth potentiellement en mutual auth).
-On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le firewall des serveurs pour autoriser le trafic IPv6 global qu'entre serveurs de l'infra. Et seuls les ports des services publics actuels seraient ouverts à tous en IPv6.
-
-**Avantages:**
-
-- Bye bye le NAT
-- Basé sur des protocoles standard
-- Conceptuellement "simple"
-
-**Inconvénients:**
-
-- Complexité de mise en place, car il faut s'assurer que **tous** les services internes du cluster utilisent une authentification et que celle-ci est bien configurée
-- Pas de défense en profondeur, donc il restera toujours le risque d'un service mal configuré qui permet de compromettre le système
-- Certains services ne savent peut-être pas faire d'authentification ? Par exemple GlusterFS (pour l'instant on ne s'en est pas débarassés) est-il capable de faire du TLS entre les noeuds ?
-- Si on choisit de rajouter un firewall, sait-on le configurer automatiquement lorsque les services changent de machine/de port ?
-
-### La *networking* : Ajouter un VPN
-
-Solution étudiée par TeDomum/ACID. Ils partent sur Wesher. Voici leur avis :
-
-> On s'est posé la question d'utiliser un service mesh plutôt qu'un mesh d'infrastructure. Et il se trouve que ça collait peu à notre besoin. Il y a trop de choses au-dessus pas conçues pour être à poil sur internet et qui rentreraient pas dans le service mesh.
->
-> Consul est top si tu veux interconnecter des clusters k8s dans des régions différentes. Mais si tu fais un cluster étendu y'a trop de choses exposées par défaut sans tls ou sans authent sur le réseau d'infra k8s. Et trop de choses dans plein de techno où il attend une forme de l2 partagé ou une proximité réseau, même virtuelle, comme les acl par préfixe IP dans les solutions de stockage, l'allocation de préfixe d'adressage dans les ipam de la plupart des cni, etc.
->
-> On pourrait probablement s'en sortir en oubliant le cluster étendu géographique et en dégainant des solutions de synchro multi clusters avec plein de petits clusters et un service mesh par-dessus. Mais c'est beaucoup plus complexe de mise en oeuvre et beaucoup plus coûteux qu'un bon vieux vpn en dessous.
->
-> Bref. On veut faire simple et efficace.
-
-Solutions possibles: Wireguard/[Wesher](https://github.com/costela/wesher), `tinc`, cjdns/yggdrasil.
-
-**Avantages:**
-
-- Indépendant de toute autre problématique sur le cluster
-- Sans doute la solution la plus rapide à déployer à partir de l'état actuel
-- Les services continuent à se parler sur un réseau normal (cf les remarques de TeDomum ci-dessus)
-- Si les services communiquent en TLS et s'authentifie les uns aux autres ça fait une 2e couche de sécurité
-
-**Inconvénient:**
-
-- Ajoute un niveau de complexité au niveau global
-- N'implémente pas de politique de sécurité entre les services du cluster
-- Consommateur de CPU à haut débit
-- Protocoles de routage non-standard dans le cas des protocoles à base de mesh
-- (Certains clients VPN ne sont dispo que sur archi x86)
-
-### La *micro-service architecture* : utiliser un service mesh
-
-Consul Connect permet de reporter le problème de l'interconnexion des infrastructures non plus au niveau des applications mais au niveau du cluster. Une fois Consul et Consul Connect bien configuré, tout le trafic sera alors chiffré d'un micro service à un autre avec du TLS et de l'authentification mutuelle. Consul sera lui-même en charge de trouver comment faire communiquer les éléments.
-
-**Avantages:**
-
-- Solution bien intégrée avec les autres outils Hashicorp (Nomad et Consul)
-- Sécurisation supplémentaire à base d'intent et d'ACL
-- Gestion intégrée du nommage, du routage et de la sécurité
-
-**Inconvénients:**
-
-- Nécessite sans doute pas mal de travail pour le mettre en place
-- Ajoute un outil potentiellement complexe et peu maîtrisé
-- Les applications ne se parlent plus directement sur le réseau -> problèmes dans certains cas (par exemple Garage peut-il toujours fonctionner ?)
-- Consommateur de CPU à haut débit
-- Protocole encore moins standard que le VPN (en estimant que si Wireguard a atterri dans le noyau, c'est que c'est relativement standard quand même)
-
-**Conclusion:** L'arbitrage entre la solution VPN et la solution service mesh se fait sur les deux points suivants: outil permettant de sécuriser les connexions en les autorisant au cas-par-cas (ACL+intent) vs. outil permettant de préserver un fonctionnement comme en LAN et où les applications peuvent utiliser les propriétés d'un tel réseau "classique".
diff --git a/src/Technique/Jalon/index.md b/src/Technique/Jalon/index.md
deleted file mode 100644
index 90d82c6..0000000
--- a/src/Technique/Jalon/index.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Jalons
-
-Les jalons définissent les grands objectifs techniques que nous souhaitons atteindre.
-Ils nous servent à garder le cap quand on a la tête dans le technique tout en clarifiant nos pensées.
-Nous valorisons la critique et les décisions participatives, tout le monde est donc encouragé à venir donner son avis et enrichir cette page en l'éditant directement ou en proposant une merge request.
-
-## Vers l'auto-hébergement résilient
-
-**Auto hébergement** : nos valeurs -> soit en justice, soit en vulgarisant, soit en proposant une alternative -> proposer une alternative nécessite de reprendre le contrôle.
-
-**Résilient** : la course à l'uptime est veine. dans l'absolu on pourrait accepter un service qui serait down une heure par jour. le vrai enjeu, c'est la pression portée sur les administrateurs. ne pas se retrouver l'esclave de la machine. c'est LA raison pour laquelle tout le monde arrête l'auto hébergement un jour ou un autre dans sa vie.
-
-### Pt. 1 : La vieille tour (de Babel)
-
-10 ans d'essai, 3 *setups* différents, plus de puissance qu'ajd -> pas un pb de puissance.
-Connexion ADSL, CPL.
-
-Expérience :
-  * Crash d'une carte mère x2
-  * Crash d'un disque dur
-  * OS cassé
-  * CPL planté
-  * Barrette de RAM cassée
-  * Plus d'électricité
-  * Problèmes de peering
-
-Tout est un SPOF. Aller-retour Rennes-Nevers.
-Diagnostique à la hâte, commande de RAM alors que MOBO broken.
-
-### Pt. 2 : La grappe (mousse et pampre)
-
-*Je faisais un brin de causette, le genre réservé, tu me connais. Mousse et pampre. Voilà tout d'un coup qu'un petit cave est venu me chercher, les gros mots et tout !*
-
-La grappe de serveur, ou *cluster* dans la langue de Shakespeare.
-Enlever certains points de failure.
-
-Expérience :
-  * Coupure électrique ~2h x3 
-
-SPOF :
-  * Connexion
-  * Routeur
-  * Switch
-  * Électricité
-
-### Pt. 3 : La foule (feat Edith Piaf)
-
-*Emportés par la foule qui nous traîne, qui nous entraîne...*
-
-objectif : plus de SPOF
diff --git a/src/Technique/Operations/Assets/exemple_offre.txt b/src/Technique/Operations/Assets/exemple_offre.txt
deleted file mode 100644
index 3af76ec..0000000
--- a/src/Technique/Operations/Assets/exemple_offre.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-type: offer, sdp: v=0
-o=- 1923518516 2 IN IP4 127.0.0.1
-s=-
-t=0 0
-a=msid-semantic: WMS 48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=group:BUNDLE audio video data
-m=audio 10000 RTP/SAVPF 111 103 104 126
-c=IN IP4 82.253.205.190
-a=rtpmap:111 opus/48000/2
-a=rtpmap:103 ISAC/16000
-a=rtpmap:104 ISAC/32000
-a=rtpmap:126 telephone-event/8000
-a=fmtp:111 minptime=10;useinbandfec=1
-a=rtcp:9 IN IP4 0.0.0.0
-a=rtcp-fb:111 transport-cc
-a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
-a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
-a=setup:actpass
-a=mid:audio
-a=sendrecv
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=ssrc:3265394670 cname:mixed
-a=ssrc:3265394670 msid:mixedmslabel mixedlabelaudio0
-a=ssrc:3265394670 mslabel:mixedmslabel
-a=ssrc:3265394670 label:mixedlabelaudio0
-a=ssrc:3761143749 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3761143749 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 8a034425-b6b5-4928-ab5f-9ca0ec4168c4-1
-a=ssrc:3761143749 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3761143749 label:8a034425-b6b5-4928-ab5f-9ca0ec4168c4-1
-a=ssrc:3240916804 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:3240916804 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 45de0b7f-8590-4232-9bde-77d55a7366b5-1
-a=rtcp-mux
-m=video 10000 RTP/SAVPF 100 107 101 96 97 99
-c=IN IP4 82.253.205.190
-a=rtpmap:100 VP8/90000
-a=rtpmap:107 H264/90000
-a=rtpmap:101 VP9/90000
-a=rtpmap:96 rtx/90000
-a=rtpmap:97 rtx/90000
-a=rtpmap:99 rtx/90000
-a=fmtp:100 x-google-start-bitrate=800
-a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f;x-google-start-bitrate=800
-a=fmtp:101 x-google-start-bitrate=800
-a=fmtp:96 apt=100
-a=fmtp:97 apt=101
-a=fmtp:99 apt=107
-a=rtcp:9 IN IP4 0.0.0.0
-a=rtcp-fb:100 ccm fir
-a=rtcp-fb:100 nack
-a=rtcp-fb:100 nack pli
-a=rtcp-fb:100 transport-cc
-a=rtcp-fb:107 ccm fir
-a=rtcp-fb:107 nack
-a=rtcp-fb:107 nack pli
-a=rtcp-fb:107 transport-cc
-a=rtcp-fb:101 ccm fir
-a=rtcp-fb:101 nack
-a=rtcp-fb:101 nack pli
-a=rtcp-fb:101 transport-cc
-a=rtcp-fb:96 ccm fir
-a=rtcp-fb:96 nack
-a=rtcp-fb:96 nack pli
-a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
-a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
-a=setup:actpass
-a=mid:video
-a=sendrecv
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=ssrc:3339205972 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:3339205972 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 4de277cb-7421-402a-bbb1-2090dab4540e-1
-a=ssrc:3560865865 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3560865865 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:3560865865 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3560865865 label:21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:1942865873 cname:mixed
-a=ssrc:1942865873 msid:mixedmslabel mixedlabelvideo0
-a=ssrc:1942865873 mslabel:mixedmslabel
-a=ssrc:1942865873 label:mixedlabelvideo0
-a=ssrc:3656552182 cname:sMYSy0kNyRU3eK0c-1
-a=ssrc:3656552182 msid:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1 21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:3656552182 mslabel:48d3ae09-99f6-4a73-bad1-1b0963eaf3cc-1
-a=ssrc:3656552182 label:21a02fe8-c9f4-49fe-aaef-4c4ad48a3516-1
-a=ssrc:4136660991 cname:75Ayhq4Cuv7k5JAP-1
-a=ssrc:4136660991 msid:27755a82-e9e7-4cc4-bdb3-354a06b3f32a-1 4de277cb-7421-402a-bbb1-2090dab4540e-1
-a=ssrc-group:FID 3560865865 3656552182
-a=ssrc-group:FID 3339205972 4136660991
-a=rtcp-mux
-a=x-google-flag:conference
-m=application 10000 DTLS/SCTP 5000
-c=IN IP4 82.253.205.190
-a=setup:actpass
-a=mid:data
-a=ice-ufrag:97nc61e52b11gu
-a=ice-pwd:k2df7f8vgknj27sctj550cl2u
-a=fingerprint:sha-1 FC:4F:0B:F5:34:07:D8:09:47:D2:3C:FE:D1:8E:05:4B:05:10:CD:A1
-a=candidate:1 1 ssltcp 2130706431 172.17.0.1 8080 typ host generation 0
-a=candidate:2 1 ssltcp 2130706431 192.168.1.4 8080 typ host generation 0
-a=candidate:4 1 udp 2113932031 172.17.0.1 10000 typ host generation 0
-a=candidate:5 1 udp 2113932031 192.168.1.4 10000 typ host generation 0
-a=candidate:3 1 ssltcp 1677724415 82.253.205.190 8080 typ srflx raddr 192.168.1.4 rport 8080 generation 0
-a=candidate:6 1 udp 1677724415 82.253.205.190 10000 typ srflx raddr 192.168.1.4 rport 10000 generation 0
-a=sctpmap:5000 webrtc-datachannel 1024
diff --git a/src/Technique/Operations/Assets/livebox_parefeu_personnalise.png b/src/Technique/Operations/Assets/livebox_parefeu_personnalise.png
deleted file mode 100644
index 16c922a..0000000
--- a/src/Technique/Operations/Assets/livebox_parefeu_personnalise.png
+++ /dev/null
diff --git a/src/Technique/Operations/Jitsi.md b/src/Technique/Operations/Jitsi.md
deleted file mode 100644
index 5f26131..0000000
--- a/src/Technique/Operations/Jitsi.md
+++ /dev/null
@@ -1,94 +0,0 @@
-## 2020-04-02 Campagne de debug Jitsi
-
-Contact: Quentin
-
-### Description du problème
-
-Les conversations à 3+ donc relayées par le serveur ne fonctionnent pas bien.
-Louison m'a rapporté que ça avait marché pour lui (3 utilisateurs avec un Webkit).
-Mais moi ça a échoué hier soir (01/04/2020) avec des participants sous Firefox.
-Le bug est toujours le même : on entend 2 personnes sur 3 ou on voit 2 personnes sur 3, on recharge la page et c'est quelqu'un d'autre pour qui ça ne fonctionne plus. Souvent c'est que dans un sens.
-À chaque fois en passant sur Facebook Messenger, le problème est résolu instantanément.
-Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de groupe (et ne supporte donc pas Firefox).
-
-D'où mes 2 suspicions :
-
-- Firefox a un bug quelconque dans sa pile WebRTC déclenché par le mode conversation de groupe
-- Jitsi a un problème avec les déconnexions/changement de connexion/petit hoquets du réseau et n'arrive pas à se reconnecter. Ça pourrait être rendu pire à certain moment de la journée comme le soir où le réseau est plus sollicité. Et ce serait provoqué lors du reload on repasse de 3 à 2, en P2P donc puis de nouveau de 2 à 3.
-
-### Approfondissement
-
-Avant d'aller plus loin, nous avons voulu prendre le temps d'identifier précisément les problèmes d'expérience utilisateurs et leur corrélation avec la plateforme de l'utilisateur (navigateur, OS).
-
-Pour celà, nous avons suivi deux approches :
-1. Mener nos propres tests
-2. Chercher d'autres retours
-
-#### Mener nos propres tests
-
-Nous avons effectué deux appels : un avec Firefox seulement et un avec Chrome/Chromium seulement.
-Merci à Alex, Adrien et Maximilien pour leur participation.
-
-Voilà les conclusions que nous avons tirées de nos tests :
-
-- L'appel avec Firefox a déclenché le bug immédiatement, peu importe la version de Firefox ou de l'OS (firefox stable/nightly, fedora stable/beta, etc.)
-- Le passage de tout le monde sous Chrome/Chromium a permis d'avoir une conversation stable.
-- Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a dû ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible)
-
-Nous avons donc demandé à Adrien quels étaient les ports ouverts par défaut dans le mode élevé de sa box :
-
-![Livebox Parefeu Personnalisé](Assets/livebox_parefeu_personnalise.png)
-
-Nous avons dans un premier temps retenu le port `995/tcp` pour Jitsi, le port UDP ne pouvant être changé (limitation de Jitsi).
-Cependant, pour des raisons de sécurité, les navigateurs ne peuvent pas utiliser les ports en dessous de `1024/*`, à l'exception des ports `80/tcp` et `443/tcp` comme l'indique ;'issue [#3583](https://bugs.chromium.org/p/webrtc/issues/detail?id=3583) de Chromium.
-
-La capture n'indique pas de port TCP supérieur à 1024, nous ne pouvons donc pas résoudre ce problème de notre côté, car à l'heure actuelle, nos ports `80/tcp` et `443/tcp` sont utilisés et nous n'avons qu'une seule IP publique.
-Les utilisateurs activant le parefeu en mode élevé devront ajouter une exception dans leur parefeu eux-mêmes.
-
-#### Chercher d'autres retours
-
-[Tedomum](https://tedomum.net/) a eu connaissance de problèmes similaires.
-Ils ont également identifié Firefox et assurent qu'avec l'application Android ça marche bien.
-Ils me confirment que le problème vient bien du logiciel et non pas de notre déploiement.
-Ils m'ont pointé entre autres vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
-Apparemment une issue est dédiée en particulier au problème que nous rencontrons de déconnexion partielle d'un participant, mais nous ne l'avons pas encore retrouvée.
-
-### Correctifs
-
-  1. Notre instance Jitsi a été reconfigurée pour refuser Firefox. Suivre l'avancée du développement de Jitsi pour Firefox
-    * [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
-    * [#5439](https://github.com/jitsi/jitsi-meet/issues/5439)
-    * _À compléter_
-  2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Or ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant).
-    * Un déploiement en IPv6 pourrait résoudre le problème pour une partie des utilisateurs
-    * Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème
-    * Avoir un frontend layer 4 (niveau TCP) qui trouve une signature pour router du DTLS vers videobridge et du TLS vers traefik
-
-### À propos du control/data plane de Jitsi
-
-Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`.
-
-WebRTC fonctionne en deux étapes :
-- Des offres doivent être échangées via un serveur de signaling quelconque
-- Ensuite, ces offres servent à connecter des clients directement via un protocole TCP ou UDP avec un thin layer propre à WebRTC
-
-#### Le control plane de Jitsi : Prosody sur HTTPS via Bosh/XMPP
-
-Le serveur de signaling Jitsi n'est autre que le serveur de chat prosody.
-Pour ça, prosody est exposé à travers HTTP grâce au protocole BOSH (XMPP overs HTTPS).
-Une fois l'offre reçue ([exemple](Assets/exemple_offre.txt)), elle est enregistrée dans le navigateur à l'aide de `setRemoteDescription` pour initialiser le data plane.
-On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/).
-
-Quand plus de deux participants sont connectés dans la conversation, Jitsi n'envoie pas les offres de chaque participant aux autres participants. À la place, elle envoie qu'une seule offre, celle de son VideoBridge.
-
-Ainsi, le VideoBridge est une sorte de client WebRTC particulier, qui récolte et redispatche à travers WebRTC tous les flux video/audio.
-
-#### Le data plane de Jitsi : videobridge sur DTLS/SCTP via WebRTC
-
-WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataChannel|DataFormat](https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel#Data_format) :
-- `UDP/DTLS/SCTP`
-- `TCP/DTLS/SCTP`
-
-On a donc un format de données arbitraire encapsulé dans du SCTP lui-même encapsulé dans du DTLS.
-DTLS est prévu pour les datagrammes à l'origine, car WebRTC est prévu d'abord pour fonctionner sous UDP.
-Le TCP est là en mode dégradé, en secours, il sert juste de tunnel pour relayer des datagrammes.
diff --git a/src/Technique/Operations/index.md b/src/Technique/Operations/index.md
deleted file mode 100644
index d0498b9..0000000
--- a/src/Technique/Operations/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
-## Créer un utilisateur Postgres
-
-  1. Créer un compte de service dans Guichet
-  2. `exec` dans un conteneur `stolon-keeper` sur une machine
-  3. Executer `psql -h psql-proxy.service.2.cluster.deuxfleurs.fr`
-  4. Rentrer le mot de passe
-  5. Créer l'utilisateur `CREATE USER <username>;`
-  6. (Optionnel) Lui créer une base de données : `CREATE DATABASE <dbname> OWNER <username>`
-  7. (Optionnel) Lui donner les privileges appropriés, eg. `GRANT READ PRIVILEGES ON DATABASE <anotherdbname> TO <username>;`
-  8. Vérifier les permissions : `psql -h psql-proxy.service.2.cluster.deuxfleurs.fr -U <username> <dbname>`
-
diff --git a/src/Technique/index.md b/src/Technique/index.md
deleted file mode 100644
index 0afc8f4..0000000
--- a/src/Technique/index.md
+++ /dev/null
@@ -1,25 +0,0 @@
-Deuxfleurs utilise les composants suivants dans son infrastructure:
-
-- Ansible (configuration des noeuds)
-- Docker (conteneurs)
-- Nomad (orchestration des conteneurs)
-- Consul (stockage clef/valeur distribué, découverte de services)
-- Glusterfs (système de fichiers distribué)
-- Stolon (système de réplication pour PostgreSQL)
-- Drone (intégration continue et déploiement continu)
-
-Les services proposés sont les suivants:
-
-- Chat via Matrix (Synapse, Riot)
-- Email (Postfix, Dovecot, SoGo)
-- Stockage (Seafile)
-
-Par ailleurs, nous avons développé nous-même un certain nombre d'outils pour compléter la stack:
-
-- [Bottin](https://bottin.eu), un serveur LDAP (gestion des comptes utilisateurs) basé sur le stockage clef/valeur de Consul
-- [Guichet](https://git.deuxfleurs.fr/Deuxfleurs/Guichet/), une interface web de gestion des utilisateurs
-- [Easybridge](https://git.deuxfleurs.fr/lx/Easybridge/), un bridge entre Matrix et d'autres réseaux
-- [Diplonat](https://git.deuxfleurs.fr/Deuxfleurs/diplonat/), un outil permettant de configurer automatiquement les redirections de ports d'un routeur
-- [Garage](https://git.deuxfleurs.fr/lx/garage/), un stockage d'objets distribué multi-sites implémentant un sous-ensemble de l'API Amazon S3
-
-Le code de l'infrastructure [est publiquement disponible](https://git.deuxfleurs.fr/Deuxfleurs/deuxfleurs.fr/).