From f3b7e90693bf2b51a53a23d98a60bbf04065103a Mon Sep 17 00:00:00 2001 From: Quentin Dufour Date: Wed, 1 Mar 2023 19:45:01 +0100 Subject: rework infrastructures --- content/formations/_index.md | 2 + content/infrastructures/bottin.md | 18 +++++ content/infrastructures/developpement.md | 34 ++++++++ content/infrastructures/diplonat.md | 17 ++++ content/infrastructures/energie.md | 15 ++-- content/infrastructures/garage.md | 42 ++++++++++ content/infrastructures/guichet.md | 19 +++++ content/infrastructures/logiciels.md | 94 ++++++++++++++++++++++ content/infrastructures/logiciels/_index.md | 8 -- content/infrastructures/logiciels/bottin.md | 16 ---- .../infrastructures/logiciels/conception/_index.md | 7 -- .../logiciels/conception/vie_privee.md | 86 -------------------- content/infrastructures/logiciels/diplonat.md | 15 ---- content/infrastructures/logiciels/garage.md | 40 --------- content/infrastructures/logiciels/guichet.md | 17 ---- content/infrastructures/logiciels/tricot.md | 16 ---- content/infrastructures/machines.md | 53 ++++++++++++ content/infrastructures/machines/_index.md | 51 ------------ content/infrastructures/machines/developpement.md | 32 -------- content/infrastructures/machines/production.md | 64 --------------- content/infrastructures/machines/support.md | 48 ----------- content/infrastructures/machines/xp.md | 35 -------- content/infrastructures/production.md | 66 +++++++++++++++ content/infrastructures/reseau.md | 15 ++-- content/infrastructures/services.md | 11 ++- content/infrastructures/support.md | 50 ++++++++++++ content/infrastructures/tricot.md | 18 +++++ content/infrastructures/xp.md | 37 +++++++++ content/operations/_index.md | 12 +-- content/prise_en_main/_index.md | 2 + content/vie_associative/_index.md | 14 ++-- templates/_nav.html | 28 +++---- 32 files changed, 505 insertions(+), 477 deletions(-) create mode 100644 content/infrastructures/bottin.md create mode 100644 content/infrastructures/developpement.md create mode 100644 content/infrastructures/diplonat.md create mode 100644 content/infrastructures/garage.md create mode 100644 content/infrastructures/guichet.md create mode 100644 content/infrastructures/logiciels.md delete mode 100644 content/infrastructures/logiciels/_index.md delete mode 100644 content/infrastructures/logiciels/bottin.md delete mode 100644 content/infrastructures/logiciels/conception/_index.md delete mode 100644 content/infrastructures/logiciels/conception/vie_privee.md delete mode 100644 content/infrastructures/logiciels/diplonat.md delete mode 100644 content/infrastructures/logiciels/garage.md delete mode 100644 content/infrastructures/logiciels/guichet.md delete mode 100644 content/infrastructures/logiciels/tricot.md create mode 100644 content/infrastructures/machines.md delete mode 100644 content/infrastructures/machines/_index.md delete mode 100644 content/infrastructures/machines/developpement.md delete mode 100644 content/infrastructures/machines/production.md delete mode 100644 content/infrastructures/machines/support.md delete mode 100644 content/infrastructures/machines/xp.md create mode 100644 content/infrastructures/production.md create mode 100644 content/infrastructures/support.md create mode 100644 content/infrastructures/tricot.md create mode 100644 content/infrastructures/xp.md diff --git a/content/formations/_index.md b/content/formations/_index.md index 2804f6c..fe473bc 100644 --- a/content/formations/_index.md +++ b/content/formations/_index.md @@ -3,6 +3,8 @@ title: "Se former" description: "Se former" weight: 30 sort_by: "weight" +extra: + parent: 'formations/_index.md' --- Ce manuel vous propose de vous former sur les questions portées par l'association, que ce soit sur l'impact social du numérique ou l'administration d'une machine Linux, avec dans l'idée que vous pourrez vous impliquer d'avantange dans nos activités après, en faisant des ateliers ou en participant à opérer les machines et les logiciels. diff --git a/content/infrastructures/bottin.md b/content/infrastructures/bottin.md new file mode 100644 index 0000000..e8dd8e0 --- /dev/null +++ b/content/infrastructures/bottin.md @@ -0,0 +1,18 @@ +--- +title: "Bottin" +description: "Un annuaire LDAP pour le distribué" +date: 2021-11-09T12:40:01.746Z +dateCreated: 2021-11-09T12:39:59.725Z +weight: 10 +extra: + parent: 'infrastructures/logiciels.md' +--- + +# 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 : diff --git a/content/infrastructures/developpement.md b/content/infrastructures/developpement.md new file mode 100644 index 0000000..a16a88d --- /dev/null +++ b/content/infrastructures/developpement.md @@ -0,0 +1,34 @@ +--- +title: "Développement" +description: "Développement" +weight: 30 +extra: + parent: 'infrastructures/machines.md' +--- + +Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, +les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour +des attaques de chaine d'approvisionnement (*supply chain attack*). + +# Bruxelles (Bespin) + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| Forge Gitea | VM | x1 | ? | +| Runner Drone | VM | x1 | 16 cœurs, 8Go RAM, 25Go + 25Go + 50Go| +| | | | `ssh 2a02:1811:3612:b300:e99c:c591:a17f:210` | + +# Autres runners Drone + +## Rennes (Jupiter) + +(information à rajouter) + +## Lyon (Aurora) + +![Photo d'illustration du PC portable utilisé](/img/serv_easynotebg46.jpg) + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| Packard Bell EasyNote BG46 (2007) | Serveur | x1 | Intel T5750 @ 2.00Ghz (2 cœurs), 3Go RAM, HDD 500Go | +| Freebox Mini 4k | Routeur | x1 | 4 ports @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique | diff --git a/content/infrastructures/diplonat.md b/content/infrastructures/diplonat.md new file mode 100644 index 0000000..34a4fe7 --- /dev/null +++ b/content/infrastructures/diplonat.md @@ -0,0 +1,17 @@ +--- +title: "Diplonat" +description: "" +date: 2021-11-09T12:42:17.716Z +dateCreated: 2021-11-09T12:42:15.729Z +weight: 30 +extra: + parent: 'infrastructures/logiciels.md' +--- + +# 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 : . Il est exploité dans le cadre des activités de deuxfleurs. diff --git a/content/infrastructures/energie.md b/content/infrastructures/energie.md index d98f331..2728825 100644 --- a/content/infrastructures/energie.md +++ b/content/infrastructures/energie.md @@ -1,9 +1,12 @@ -+++ -title = "Énergie" -description = "Consommation électrique" -date = 2021-11-09T12:54:33.129Z -dateCreated = 2021-11-09T12:54:30.985Z -+++ +--- +title: "Énergie" +description: "Consommation électrique" +date: 2021-11-09T12:54:33.129Z +dateCreated: 2021-11-09T12:54:30.985Z +weight: 20 +extra: + parent: 'infrastructures/_index.md' +--- # Notre avis diff --git a/content/infrastructures/garage.md b/content/infrastructures/garage.md new file mode 100644 index 0000000..7f28eae --- /dev/null +++ b/content/infrastructures/garage.md @@ -0,0 +1,42 @@ +--- +title: "Garage" +description: "" +date: 2021-11-09T12:42:59.273Z +dateCreated: 2021-11-09T12:42:57.245Z +weight: 40 +extra: + parent: 'infrastructures/logiciels.md' +--- + +# 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) diff --git a/content/infrastructures/guichet.md b/content/infrastructures/guichet.md new file mode 100644 index 0000000..684f410 --- /dev/null +++ b/content/infrastructures/guichet.md @@ -0,0 +1,19 @@ +--- +title: "Guichet" +description: "" +date: 2021-11-09T12:39:27.819Z +dateCreated: 2021-11-09T12:39:25.808Z +weight: 20 +extra: + parent: 'infrastructures/logiciels.md' +--- + +# 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 : diff --git a/content/infrastructures/logiciels.md b/content/infrastructures/logiciels.md new file mode 100644 index 0000000..f72013d --- /dev/null +++ b/content/infrastructures/logiciels.md @@ -0,0 +1,94 @@ +--- +title: "Logiciels" +description: "Logiciels" +weight: 90 +sort_by: "weight" +extra: + parent: 'infrastructures/_index.md' +--- + +Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infra. + +# Principes de conception + +Nou essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes. + +## Vie privée + +Que ce soit à l'intérieur ou l'extérieur de l'association, des demandes pour d'avantage de garanties sur la vie privée ont été formulées. + +### Propriétés recherchées + +Quelques propriétés en vrac qu'on peut, ou ne pas, désirer : + +### Messagerie instantanée + + - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles (eg. une photo que j'ai prise, mes réactions) + - Je ne veux pas que les métadonnées autour de mes messages soient accessibles (eg. les salons de discussions auxquels je prends pars, l'horodatage des messages, les personnes avec qui j'échange) + - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (autres personnes dans le salon de communication, horodatage, etc.) + +### Courrier électronique (de l'email au mixnet) + + - Je ne veux pas que le contenu de mes emails et pièces jointes soit lisible (eg. le doc que j'ai joint) + - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinaire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké) + - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocol (destinaires, présence de pièce jointe, + +### Synchronisation et collaboration sur des fichiers + - Je ne veux pas que le contenu de mes fichiers soit accessible + - Je ne veux pas que les métadonnées de mon fichier soient accessibles (eg. nom du fichier, dossier, format, taille, hash, etc.) + - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (taille, collaborateurs, type, etc.) + +## Attaquants + +Quelques attaquants que l'on peut, ou ne pas, considérer : + + - Hébergeur de la machine (eg. branche un clavier et un écran sur l'ordi et récupère un accès admin) + - Administrateur Système (eg. utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé) + - Développeurs (eg. ajout d'une porte dérobée au moment de l'écriture du code) + - Chaine logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur) + - Opérateur Internet (eg. Orange) + - Regroupement d'opérateurs internet (cf "Tor netflow") + - Personne externe via internet (eg. hacker) + - Personne externe physique (eg. voleur) + - Regroupement d'acteurs (eg. opérateurs internet, externe physique ET internet) + - Utilisateurs (eg. pas de chiffrement sur son téléphone) + +## Un exemple de ce qu'on pourrait faire + +Prenons l'exemple de la messagerie instantanée. Pour l'instant, on peut définir les types de réseaux suivants : + +- centralisé, pas chiffré (Messenger) +- centralisé, chiffé de bout en bout (avec toute une gamme d'implems, la meilleure étant peut-être Signal) +- fédéré, pas chiffré (E-mail, IRC, XMPP sans omemo, Matrix sans E2EE) +- fédéré, chiffré (XMPP + Omemo, Matrix + E2EE) +- distribué, chiffré (Tox, Retroshare) +- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks, ...) + +Seule la dernière catégorie s'adresse au cas d'un "global passive attacker". On peut imaginer d'abandonner l'idée d'avoir une protection très efficace contre ce dernier car ça serait très contraignant sur le design et l'utilisabilité, et les cas où on en aurait vraiment besoin sont des cas particuliers où on peut faire l'effort d'utiliser une solution adaptée. + +Pour le "grand public", passer sur des solutions fédérés chiffrés c'est un très bon début et si on arrive déjà à passer des gens sur Matrix, c'est très bien. Ceci dit, il y a quand même une faille majeure dans ces systèmes, c'est l'existence de serveurs qui centralisent des quantités plus ou moins importantes de (méta)données : il suffit que n'importe lequel soit compromis pour que toutes ces données soient exfiltrées, global passive attacker ou non. En ce qui nous concerne chez Deuxfleurs, le danger est exacerbé car on veut faire de la réplication sur plusieurs noeuds chez plusieurs personnes, donc autant d'opportunités d'avoir une sécu pétée à un endroit ou un autre. + +Une marche à franchir qui pourrait être désirable pour nous, ça serait donc de faire en sorte que les serveurs aient le moins de visibilité possible sur ce qui se passe dans le réseau. Dans un système "distribué chiffré" on n'a plus de serveurs donc le problème n'existe pas, le seul danger qui reste est la possibilité de compromettre le périphérique utilisateur directement (et on sait par ailleurs que c'est possible, mais c'est pas quelque chose sur lequel on peut agir nous). Par contre les systèmes 100% distribués ne sont pas utilisables efficacement sur mobile car ils pompent la batterie, d'où l'idée de vouloir faire une approche hybride où des serveurs pourraient jouer un rôle mais avec des protocoles prévus d'une manière à ce qu'ils ne voient passer et ne stockent qu'un minimum de données en clair. + +Un autre problème, c'est que dans un modèle totalement distribué se pose la question de qui gère la résilience du service et des données ? Comment tu développes un logiciel distribué qui ne perd pas de données (bitcoin n'est pas une réponse valable) ? + +On peut globalement diviser les approches en deux : + +1. Définir des nouveaux protocoles client/serveur qui minimisent les métadonnées lisibles par les serveurs + +2. Rester dans le cadre des protocoles standards (IMAP, WebDav, ...), et faire une implem où les serveurs stockent le plus possible de données chiffrées (y compris toutes les métadonnées), et ont le moins souvent possible accès à la donnée en clair. + +La première approche est intéressante, mais elle implique de remplacer tout l'écosystème. Ça peut être un projet de recherche intéressant, mais on ne veut pas forcément en faire le projet prioritaire de Deuxfleurs. + +Concernant la seconde approche, celle-ci semble beaucoup plus à notre portée : + +- Par exemple dans une architecture de cluster à-la-Deuxfleurs, on pourrait différencier les lieux où on stocke les données en fonction du niveau de privacy : par exemple seuls les serveurs chez X seraient habilités à déchiffrer le contenu pour le servir sur des protocoles standards (S3, IMAP, Matrix), et les serveurs chez les autres seraient uniquement là pour stocker de la donnée entièrement chiffrée + +- On peut imaginer que les clefs de chiffrement ne soient jamais stockées en clair nulle part : elles pourraient être stockées avec une passphrase qui serait le mot de passe de l'utilisateur (+ éventuellement un mécanisme de secret de shamir pour répartir les morceaux de clefs sur plusieurs machines), et c'est seulement au dernier moment (en RAM) qu'elles existent en version déchiffrée + +- Enfin, on peut imaginer que Deuxfleurs fournisse à la place (ou en plus) du protocole standard un protocole entièrement chiffrée + un logiciel proxy que les utilisateurices pourraient installer sur leur machine pour avoir accès au protocole standard avec toutes leurs applications habituelles. Cette dernière option permetterait d'avoir le même niveau de sécurité que la solution consistant à définir de nouveaux protocoles, sans pour autant compromettre l'interopérabilité avec l'écosystème existant. + +## Ressources + + - https://about.psyc.eu/Federation et https://about.psyc.eu/PSYC2 + - Définition d'un mixnet : https://www.youtube.com/watch?v=dQtk0NcTseg diff --git a/content/infrastructures/logiciels/_index.md b/content/infrastructures/logiciels/_index.md deleted file mode 100644 index f2e2528..0000000 --- a/content/infrastructures/logiciels/_index.md +++ /dev/null @@ -1,8 +0,0 @@ -+++ -title = "Logiciels" -description = "Logiciels" -weight = 90 -sort_by = "weight" -+++ - -Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infra. diff --git a/content/infrastructures/logiciels/bottin.md b/content/infrastructures/logiciels/bottin.md deleted file mode 100644 index 71dc8b9..0000000 --- a/content/infrastructures/logiciels/bottin.md +++ /dev/null @@ -1,16 +0,0 @@ -+++ -title = "Bottin" -description = "" -date = 2021-11-09T12:40:01.746Z -dateCreated = 2021-11-09T12:39:59.725Z -weight = 10 -+++ - -# 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 : diff --git a/content/infrastructures/logiciels/conception/_index.md b/content/infrastructures/logiciels/conception/_index.md deleted file mode 100644 index 756e240..0000000 --- a/content/infrastructures/logiciels/conception/_index.md +++ /dev/null @@ -1,7 +0,0 @@ -+++ -title = "Conception" -description = "Conception" -weight = 90 -+++ - -Cette section recense les principes de conception que Deuxfleurs applique pour les logiciels qu'elle développe. diff --git a/content/infrastructures/logiciels/conception/vie_privee.md b/content/infrastructures/logiciels/conception/vie_privee.md deleted file mode 100644 index 76520eb..0000000 --- a/content/infrastructures/logiciels/conception/vie_privee.md +++ /dev/null @@ -1,86 +0,0 @@ -+++ -title = "Vie Privée" -description = "Comment mettre en oeuvre des systèmes prenant en compte la vie privée à leur origine ?" -date = 2021-11-18T13:57:51.695Z -dateCreated = 2021-11-18T10:42:00.744Z -+++ - -# Vie privée - -Que ce soit à l'intérieur ou l'extérieur de l'association, des demandes pour d'avantage de garanties sur la vie privée ont été formulées. - -## Propriétés recherchées - -Quelques propriétés en vrac qu'on peut, ou ne pas, désirer : - -### Messagerie instantanée - - - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles (eg. une photo que j'ai prise, mes réactions) - - Je ne veux pas que les métadonnées autour de mes messages soient accessibles (eg. les salons de discussions auxquels je prends pars, l'horodatage des messages, les personnes avec qui j'échange) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (autres personnes dans le salon de communication, horodatage, etc.) - -### Courrier électronique (de l'email au mixnet) - - - Je ne veux pas que le contenu de mes emails et pièces jointes soit lisible (eg. le doc que j'ai joint) - - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinaire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocol (destinaires, présence de pièce jointe, - -### Synchronisation et collaboration sur des fichiers - - Je ne veux pas que le contenu de mes fichiers soit accessible - - Je ne veux pas que les métadonnées de mon fichier soient accessibles (eg. nom du fichier, dossier, format, taille, hash, etc.) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (taille, collaborateurs, type, etc.) - -## Attaquants - -Quelques attaquants que l'on peut, ou ne pas, considérer : - - - Hébergeur de la machine (eg. branche un clavier et un écran sur l'ordi et récupère un accès admin) - - Administrateur Système (eg. utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé) - - Développeurs (eg. ajout d'une porte dérobée au moment de l'écriture du code) - - Chaine logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur) - - Opérateur Internet (eg. Orange) - - Regroupement d'opérateurs internet (cf "Tor netflow") - - Personne externe via internet (eg. hacker) - - Personne externe physique (eg. voleur) - - Regroupement d'acteurs (eg. opérateurs internet, externe physique ET internet) - - Utilisateurs (eg. pas de chiffrement sur son téléphone) - -## Un exemple de ce qu'on pourrait faire - -Prenons l'exemple de la messagerie instantanée. Pour l'instant, on peut définir les types de réseaux suivants : - -- centralisé, pas chiffré (Messenger) -- centralisé, chiffé de bout en bout (avec toute une gamme d'implems, la meilleure étant peut-être Signal) -- fédéré, pas chiffré (E-mail, IRC, XMPP sans omemo, Matrix sans E2EE) -- fédéré, chiffré (XMPP + Omemo, Matrix + E2EE) -- distribué, chiffré (Tox, Retroshare) -- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks, ...) - -Seule la dernière catégorie s'adresse au cas d'un "global passive attacker". On peut imaginer d'abandonner l'idée d'avoir une protection très efficace contre ce dernier car ça serait très contraignant sur le design et l'utilisabilité, et les cas où on en aurait vraiment besoin sont des cas particuliers où on peut faire l'effort d'utiliser une solution adaptée. - -Pour le "grand public", passer sur des solutions fédérés chiffrés c'est un très bon début et si on arrive déjà à passer des gens sur Matrix, c'est très bien. Ceci dit, il y a quand même une faille majeure dans ces systèmes, c'est l'existence de serveurs qui centralisent des quantités plus ou moins importantes de (méta)données : il suffit que n'importe lequel soit compromis pour que toutes ces données soient exfiltrées, global passive attacker ou non. En ce qui nous concerne chez Deuxfleurs, le danger est exacerbé car on veut faire de la réplication sur plusieurs noeuds chez plusieurs personnes, donc autant d'opportunités d'avoir une sécu pétée à un endroit ou un autre. - -Une marche à franchir qui pourrait être désirable pour nous, ça serait donc de faire en sorte que les serveurs aient le moins de visibilité possible sur ce qui se passe dans le réseau. Dans un système "distribué chiffré" on n'a plus de serveurs donc le problème n'existe pas, le seul danger qui reste est la possibilité de compromettre le périphérique utilisateur directement (et on sait par ailleurs que c'est possible, mais c'est pas quelque chose sur lequel on peut agir nous). Par contre les systèmes 100% distribués ne sont pas utilisables efficacement sur mobile car ils pompent la batterie, d'où l'idée de vouloir faire une approche hybride où des serveurs pourraient jouer un rôle mais avec des protocoles prévus d'une manière à ce qu'ils ne voient passer et ne stockent qu'un minimum de données en clair. - -Un autre problème, c'est que dans un modèle totalement distribué se pose la question de qui gère la résilience du service et des données ? Comment tu développes un logiciel distribué qui ne perd pas de données (bitcoin n'est pas une réponse valable) ? - -On peut globalement diviser les approches en deux : - -1. Définir des nouveaux protocoles client/serveur qui minimisent les métadonnées lisibles par les serveurs - -2. Rester dans le cadre des protocoles standards (IMAP, WebDav, ...), et faire une implem où les serveurs stockent le plus possible de données chiffrées (y compris toutes les métadonnées), et ont le moins souvent possible accès à la donnée en clair. - -La première approche est intéressante, mais elle implique de remplacer tout l'écosystème. Ça peut être un projet de recherche intéressant, mais on ne veut pas forcément en faire le projet prioritaire de Deuxfleurs. - -Concernant la seconde approche, celle-ci semble beaucoup plus à notre portée : - -- Par exemple dans une architecture de cluster à-la-Deuxfleurs, on pourrait différencier les lieux où on stocke les données en fonction du niveau de privacy : par exemple seuls les serveurs chez X seraient habilités à déchiffrer le contenu pour le servir sur des protocoles standards (S3, IMAP, Matrix), et les serveurs chez les autres seraient uniquement là pour stocker de la donnée entièrement chiffrée - -- On peut imaginer que les clefs de chiffrement ne soient jamais stockées en clair nulle part : elles pourraient être stockées avec une passphrase qui serait le mot de passe de l'utilisateur (+ éventuellement un mécanisme de secret de shamir pour répartir les morceaux de clefs sur plusieurs machines), et c'est seulement au dernier moment (en RAM) qu'elles existent en version déchiffrée - -- Enfin, on peut imaginer que Deuxfleurs fournisse à la place (ou en plus) du protocole standard un protocole entièrement chiffrée + un logiciel proxy que les utilisateurices pourraient installer sur leur machine pour avoir accès au protocole standard avec toutes leurs applications habituelles. Cette dernière option permetterait d'avoir le même niveau de sécurité que la solution consistant à définir de nouveaux protocoles, sans pour autant compromettre l'interopérabilité avec l'écosystème existant. - -## Ressources - - - https://about.psyc.eu/Federation et https://about.psyc.eu/PSYC2 - - Définition d'un mixnet : https://www.youtube.com/watch?v=dQtk0NcTseg \ No newline at end of file diff --git a/content/infrastructures/logiciels/diplonat.md b/content/infrastructures/logiciels/diplonat.md deleted file mode 100644 index 8db6ab2..0000000 --- a/content/infrastructures/logiciels/diplonat.md +++ /dev/null @@ -1,15 +0,0 @@ -+++ -title = "Diplonat" -description = "" -date = 2021-11-09T12:42:17.716Z -dateCreated = 2021-11-09T12:42:15.729Z -weight = 30 -+++ - -# 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 : . Il est exploité dans le cadre des activités de deuxfleurs. diff --git a/content/infrastructures/logiciels/garage.md b/content/infrastructures/logiciels/garage.md deleted file mode 100644 index 81d8e04..0000000 --- a/content/infrastructures/logiciels/garage.md +++ /dev/null @@ -1,40 +0,0 @@ -+++ -title = "Garage" -description = "" -date = 2021-11-09T12:42:59.273Z -dateCreated = 2021-11-09T12:42:57.245Z -weight = 40 -+++ - -# 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) diff --git a/content/infrastructures/logiciels/guichet.md b/content/infrastructures/logiciels/guichet.md deleted file mode 100644 index 6a1c17d..0000000 --- a/content/infrastructures/logiciels/guichet.md +++ /dev/null @@ -1,17 +0,0 @@ -+++ -title = "Guichet" -description = "" -date = 2021-11-09T12:39:27.819Z -dateCreated = 2021-11-09T12:39:25.808Z -weight = 20 -+++ - -# 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 : diff --git a/content/infrastructures/logiciels/tricot.md b/content/infrastructures/logiciels/tricot.md deleted file mode 100644 index dcb0007..0000000 --- a/content/infrastructures/logiciels/tricot.md +++ /dev/null @@ -1,16 +0,0 @@ -+++ -title = "Tricot" -description = "" -date = 2022-01-24T16:33:16.731Z -dateCreated = 2022-01-24T16:32:53.056Z -weight = 50 -+++ - -# Tricot - -Tricot est un reverse-proxy HTTP et HTTPS qui s'auto-configure à partir de [Consul](https://www.consul.io), comme le faisait Traefik, qui posait de multiples problèmes et que nous avons décidé de remplacer. Tricot s'occupe automatiquement de récupérer des certificats au près de Let's Encrypt pour rendre tous les sites accessibles en TLS. Ceux-ci sont stockés dans Consul. - -## Statut du développement - -Tricot est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif. -Le code de Tricot se trouve ici : diff --git a/content/infrastructures/machines.md b/content/infrastructures/machines.md new file mode 100644 index 0000000..d91d10b --- /dev/null +++ b/content/infrastructures/machines.md @@ -0,0 +1,53 @@ +--- +title: "Serveurs" +description: "Serveurs" +weight: 40 +sort_by: "weight" +extra: + parent: 'infrastructures/_index.md' +--- + +# Rôles + +Nous avons identifié 4 rôles pour nos serveurs, en fonction de la criticité des charges de travail +et des données qu'ils auront à gérer. + +[Production](./production/) - Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). +Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données +personnelles des usager·es. C'est donc le rôle le plus critique. + +[Support](./support/) - Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). +De par leur rôle, ils participent au bon fonctionnement de la production. +Ils n'ont pas de données personnelles brutes mais les métriques collectées peuvent refléter certains comportement des usager·es +et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même des données personnelles. + +[Développement](./developpement/) - Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, +les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour +des attaques de chaine d'approvisionnement (*supply chain attack*). À terme, ce rôle pourrait être fusionné avec la production. + +[Expérimentation](./xp/) - Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, +et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, +et donc sur la disponibilité des services. Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. +Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. + +# Zones + +En fonction des propriétés voulues, nous pouvons être amenés à répartir les serveurs d'un rôle spécifique entre plusieurs lieux géographiques, +que nous appelons des zones. + +Nous avons 3 zones pour la production : + - Orsay (Neptune) + - Lyon (Orion) + - Bruxelles (Bespin) + +Nous avons 2 zones pour le support : + - Suresnes (Mercure) + - Rennes (Jupiter) + +Nous avons 1 zones pour le développement : + - Bruxelles (Bespin) + +Nous avons plusieurs zones pour l'expérimentation : + - Orsay (Neptune) + - Rennes (Jupiter) + diff --git a/content/infrastructures/machines/_index.md b/content/infrastructures/machines/_index.md deleted file mode 100644 index 84fc012..0000000 --- a/content/infrastructures/machines/_index.md +++ /dev/null @@ -1,51 +0,0 @@ -+++ -title = "Serveurs" -description = "Serveurs" -weight = 10 -sort_by = "weight" -+++ - -# Rôles - -Nous avons identifié 4 rôles pour nos serveurs, en fonction de la criticité des charges de travail -et des données qu'ils auront à gérer. - -[Production](./production/) - Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). -Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données -personnelles des usager·es. C'est donc le rôle le plus critique. - -[Support](./support/) - Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). -De par leur rôle, ils participent au bon fonctionnement de la production. -Ils n'ont pas de données personnelles brutes mais les métriques collectées peuvent refléter certains comportement des usager·es -et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même des données personnelles. - -[Développement](./developpement/) - Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, -les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour -des attaques de chaine d'approvisionnement (*supply chain attack*). À terme, ce rôle pourrait être fusionné avec la production. - -[Expérimentation](./xp/) - Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, -et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, -et donc sur la disponibilité des services. Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. -Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. - -# Zones - -En fonction des propriétés voulues, nous pouvons être amenés à répartir les serveurs d'un rôle spécifique entre plusieurs lieux géographiques, -que nous appelons des zones. - -Nous avons 3 zones pour la production : - - Orsay (Neptune) - - Lyon (Orion) - - Bruxelles (Bespin) - -Nous avons 2 zones pour le support : - - Suresnes (Mercure) - - Rennes (Jupiter) - -Nous avons 1 zones pour le développement : - - Bruxelles (Bespin) - -Nous avons plusieurs zones pour l'expérimentation : - - Orsay (Neptune) - - Rennes (Jupiter) - diff --git a/content/infrastructures/machines/developpement.md b/content/infrastructures/machines/developpement.md deleted file mode 100644 index 2d5193f..0000000 --- a/content/infrastructures/machines/developpement.md +++ /dev/null @@ -1,32 +0,0 @@ -+++ -title = "Développement" -description = "Développement" -weight = 30 -+++ - -Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, -les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour -des attaques de chaine d'approvisionnement (*supply chain attack*). - -# Bruxelles (Bespin) - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| Forge Gitea | VM | x1 | ? | -| Runner Drone | VM | x1 | 16 cœurs, 8Go RAM, 25Go + 25Go + 50Go| -| | | | `ssh 2a02:1811:3612:b300:e99c:c591:a17f:210` | - -# Autres runners Drone - -## Rennes (Jupiter) - -(information à rajouter) - -## Lyon (Aurora) - -![Photo d'illustration du PC portable utilisé](/img/serv_easynotebg46.jpg) - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| Packard Bell EasyNote BG46 (2007) | Serveur | x1 | Intel T5750 @ 2.00Ghz (2 cœurs), 3Go RAM, HDD 500Go | -| Freebox Mini 4k | Routeur | x1 | 4 ports @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique | diff --git a/content/infrastructures/machines/production.md b/content/infrastructures/machines/production.md deleted file mode 100644 index 6f65752..0000000 --- a/content/infrastructures/machines/production.md +++ /dev/null @@ -1,64 +0,0 @@ -+++ -title = "Production" -description = "Production" -weight = 10 -+++ - -Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). -Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données -personnelles des usager·es. C'est donc le rôle le plus critique. - -**Feuille de route :** Bien que nous disposions aujourd'hui de 3 sites pour le cluster de production, -la résilience des services publiquement n'est pas assurés lorsque l'un des sites recevant du traffic -(Neptune, Orion) devient indisponible. La prochaine étape est de rendre ces deux sites mutuellement -redondants en assurant une bascule automatisée de l'un à l'autre par une mise à jour du DNS en cas -d'indisponibilité. - -# Orsay (Neptune) - -![Photo des 3 serveurs à Orsay](/img/serv_neptune.jpg) - -Les serveurs sont situés à domicile derrière une connexion FTTH SFR (la photo montre une box Free qui date d'avant le changement de FAI). -Cette grappe gère certains services de manière exclusive: Jitsi, CryptPad. -D'autres services comme Garage sont répartis entre les grappes. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| ThinkCentre M710q Tiny | Serveur | x1 | 2 cœurs, 4Go RAM, HDD 500Go | -| | | | `ssh celeri.machine.deuxfleurs.fr` | -| ThinkCentre M73 Tiny | Serveur | x2 | 2 cœurs, 8Go RAM, HDD 500Go | -| | | | `ssh concombre.machine.deuxfleurs.fr` | -| | | | `ssh courgette.machine.deuxfleurs.fr` | -| ThinkCentre M73 Tiny | Bridge IPv6 | x1 | 2 cœurs, 4Go RAM, HDD 500Go | -| D-Link DGS-108gl | Switch | x1 | 8 ports ethernet @ 1Gbit/s | -| Box SFR | Routeur | x1 | N/A | - -# Lyon (Orion) - -![Photo des 3 serveurs à Lyon](/img/serv_orion.jpg) - -Les serveurs sont situés à domicile derrière une connexion FTTH Free. -Cette grappe gère certains services de manière exclusive: E-mails, Matrix, Guichet, Plume. -D'autres services comme Garage sont répartis entre les grappes. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| ThinkCentre M710q Tiny | Serveur | x3 | 2 cœurs, 4Go RAM, SSD 500Go + HDD 500Go | -| | | | `ssh dahlia.machine.deuxfleurs.fr` | -| | | | `ssh doradille.machine.deuxfleurs.fr` | -| | | | `ssh diplotaxis.machine.deuxfleurs.fr` | -| Freebox | Routeur | x1 | N/A | - - -# Bruxelles (Bespin) - -![Photo des 3 serveurs à Bruxelles](/img/serv_bespin.jpg) - -Cette grappe ne gère aucun service accessible publiquement, mais elle fait partie intégrante du cluster Garage. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| ThinkCentre M710q Tiny | Serveur | x3 | 2 cœurs, 8Go RAM, SSD 500Go + HDD 500Go | -| | | | `ssh df-ymk.machine.deuxfleurs.fr` | -| | | | `ssh df-ymf.machine.deuxfleurs.fr` | -| | | | `ssh df-ykl.machine.deuxfleurs.fr` | diff --git a/content/infrastructures/machines/support.md b/content/infrastructures/machines/support.md deleted file mode 100644 index d816fae..0000000 --- a/content/infrastructures/machines/support.md +++ /dev/null @@ -1,48 +0,0 @@ -+++ -title = "Support" -description = "Serveurs en support" -weight = 20 -+++ - -Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). -De par leur rôle, ils participent au bon fonctionnement de la production. -Ils n'ont pas de données personnelles brutes mais les métriques collectées peuvent refléter certains comportement des usager·es -et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même des données personnelles. - -**Feuille de route :** Il est prévu de rationaliser l'usage de ces serveurs, c'est à dire voir si on peut mobiliser moins de ressources matériels tout en continuant -d'assurer le service de support. - -# Suresnes (Mercure) - -![Image d'illustration du serveur](/img/serv_dellr710.jpg) - -Ce serveur est situé à domicile derrière une connexion FTTH Free. -Il est en charge de la surveillance de la production (métrologie, etc.) et des sauvegardes des systèmes de fichier et base de données. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| [Microtik RB4011iGS+RM](https://mikrotik.com/product/rb4011igs_rm) | Routeur | x1 | Routeur et pare-feu, ports 1x10G SFP+ et 10x1G | -| Serveur Dell R710 | Hyperviseur | x3 | 2 socket, Xeon E5520 (4c8t @ 2.26Ghz)
80Go RAM, 500GB NVMe, 1TB RAID matériel, réseau LACP 2x1G | - -Seulement une partie du serveur est mise à dispsition de Deuxfleurs : - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| metro.mercure.site | LXC | x1 | 2 CPU, 2Go RAM, 25 GB NVMe | -| bkp.mercure.site (deprecated) | VM | x1 | 4 vCPU, 8Go RAM, 40 GB Block Storage | -| minio | S3 | x1 | Sert pour les sauvegardes | - -# Rennes (Jupiter) - -![Photo de la tour à Rennes](/img/serv_io.jpg) - -Le serveur est situé à domicile derrière une connexion FTTH Free. -Il est en charge des sauvegardes de Garage. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| Tour un peu vieille | Serveur | x1 | AMD Phenom II X4 955 @ 3.2 GHz (4 cœurs)
4Go RAM, SSD 250Go + HDD 2To | -| | | | `ssh io.machine.deuxfleurs.fr` | -| Freebox Mini 4k | Routeur | x1 | 4 ports ethernet @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique | - - diff --git a/content/infrastructures/machines/xp.md b/content/infrastructures/machines/xp.md deleted file mode 100644 index 853e222..0000000 --- a/content/infrastructures/machines/xp.md +++ /dev/null @@ -1,35 +0,0 @@ -+++ -title = "Expérimentation" -description = "Expérimentation" -weight = 40 -+++ - -Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, -et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, -et donc sur la disponibilité des services. Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. -Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. - -# Orsay (Neptune) - -![Photo d'illustration du Lenovo Tiny](/img/serv_m73tiny.jpg) - -Cluster staging: expérimentations avec NixOS et de nouveaux déploiements dans Nomad, avant de les mettre en service sur le cluster de production. -Cluster de test de Garage. - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| ThinkCentre M73 Tiny | Serveur | x1 | 2 cœurs, 8Go RAM, HDD 500Go | -| | | | `ssh caribou.machine.deuxfleurs.fr` | -| ThinkCentre M73 Tiny | Serveur | x2 | 4 cœurs, 8Go RAM, SSD 240Go | -| | | | `ssh carcajou.machine.deuxfleurs.fr` | -| | | | `ssh cariacou.machine.deuxfleurs.fr` | - - -# Rennes (Jupiter) - -Cluster staging (idem). - -| Désignation | Rôle | Quantité | Détails | -| -- | -- | -- | -- | -| ThinkCentre M73 Tiny | Serveur | x1 | 2 cœurs, 4Go RAM, HDD 500Go | -| | | | `ssh origan.df.trinity.fr.eu.org` | diff --git a/content/infrastructures/production.md b/content/infrastructures/production.md new file mode 100644 index 0000000..7b0ad5d --- /dev/null +++ b/content/infrastructures/production.md @@ -0,0 +1,66 @@ +--- +title: "Production" +description: "Production" +weight: 40 +extra: + parent: 'infrastructures/machines.md' +--- + +Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). +Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données +personnelles des usager·es. C'est donc le rôle le plus critique. + +**Feuille de route :** Bien que nous disposions aujourd'hui de 3 sites pour le cluster de production, +la résilience des services publiquement n'est pas assurés lorsque l'un des sites recevant du traffic +(Neptune, Orion) devient indisponible. La prochaine étape est de rendre ces deux sites mutuellement +redondants en assurant une bascule automatisée de l'un à l'autre par une mise à jour du DNS en cas +d'indisponibilité. + +# Orsay (Neptune) + +![Photo des 3 serveurs à Orsay](/img/serv_neptune.jpg) + +Les serveurs sont situés à domicile derrière une connexion FTTH SFR (la photo montre une box Free qui date d'avant le changement de FAI). +Cette grappe gère certains services de manière exclusive: Jitsi, CryptPad. +D'autres services comme Garage sont répartis entre les grappes. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| ThinkCentre M710q Tiny | Serveur | x1 | 2 cœurs, 4Go RAM, HDD 500Go | +| | | | `ssh celeri.machine.deuxfleurs.fr` | +| ThinkCentre M73 Tiny | Serveur | x2 | 2 cœurs, 8Go RAM, HDD 500Go | +| | | | `ssh concombre.machine.deuxfleurs.fr` | +| | | | `ssh courgette.machine.deuxfleurs.fr` | +| ThinkCentre M73 Tiny | Bridge IPv6 | x1 | 2 cœurs, 4Go RAM, HDD 500Go | +| D-Link DGS-108gl | Switch | x1 | 8 ports ethernet @ 1Gbit/s | +| Box SFR | Routeur | x1 | N/A | + +# Lyon (Orion) + +![Photo des 3 serveurs à Lyon](/img/serv_orion.jpg) + +Les serveurs sont situés à domicile derrière une connexion FTTH Free. +Cette grappe gère certains services de manière exclusive: E-mails, Matrix, Guichet, Plume. +D'autres services comme Garage sont répartis entre les grappes. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| ThinkCentre M710q Tiny | Serveur | x3 | 2 cœurs, 4Go RAM, SSD 500Go + HDD 500Go | +| | | | `ssh dahlia.machine.deuxfleurs.fr` | +| | | | `ssh doradille.machine.deuxfleurs.fr` | +| | | | `ssh diplotaxis.machine.deuxfleurs.fr` | +| Freebox | Routeur | x1 | N/A | + + +# Bruxelles (Bespin) + +![Photo des 3 serveurs à Bruxelles](/img/serv_bespin.jpg) + +Cette grappe ne gère aucun service accessible publiquement, mais elle fait partie intégrante du cluster Garage. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| ThinkCentre M710q Tiny | Serveur | x3 | 2 cœurs, 8Go RAM, SSD 500Go + HDD 500Go | +| | | | `ssh df-ymk.machine.deuxfleurs.fr` | +| | | | `ssh df-ymf.machine.deuxfleurs.fr` | +| | | | `ssh df-ykl.machine.deuxfleurs.fr` | diff --git a/content/infrastructures/reseau.md b/content/infrastructures/reseau.md index 8ca43a4..3e38f6f 100644 --- a/content/infrastructures/reseau.md +++ b/content/infrastructures/reseau.md @@ -1,9 +1,12 @@ -+++ -title = "Réseau" -description = "Réseau" -date = 2021-11-09T12:55:03.277Z -dateCreated = 2021-11-09T12:55:01.156Z -+++ +--- +title: "Réseau" +description: "Réseau" +date: 2021-11-09T12:55:03.277Z +dateCreated: 2021-11-09T12:55:01.156Z +weight: 30 +extra: + parent: 'infrastructures/_index.md' +--- 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". diff --git a/content/infrastructures/services.md b/content/infrastructures/services.md index c01178c..87ce29a 100644 --- a/content/infrastructures/services.md +++ b/content/infrastructures/services.md @@ -1,7 +1,10 @@ -+++ -title = "Services" -description = "Annuaire des services hébergés chez Deuxfleurs" -+++ +--- +title: "Services" +description: "Annuaire des services hébergés chez Deuxfleurs" +weight: 10 +extra: + parent: 'infrastructures/_index.md' +--- Cette page tente de recenser de façon exhaustive l'ensemble des services qui fonctionnent actuellement sur les machines de Deuxfleurs, dans les différents diff --git a/content/infrastructures/support.md b/content/infrastructures/support.md new file mode 100644 index 0000000..e31e282 --- /dev/null +++ b/content/infrastructures/support.md @@ -0,0 +1,50 @@ +--- +title: "Support" +description: "Serveurs en support" +weight: 40 +extra: + parent: 'infrastructures/machines.md' +--- + +Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). +De par leur rôle, ils participent au bon fonctionnement de la production. +Ils n'ont pas de données personnelles brutes mais les métriques collectées peuvent refléter certains comportement des usager·es +et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même des données personnelles. + +**Feuille de route :** Il est prévu de rationaliser l'usage de ces serveurs, c'est à dire voir si on peut mobiliser moins de ressources matériels tout en continuant +d'assurer le service de support. + +# Suresnes (Mercure) + +![Image d'illustration du serveur](/img/serv_dellr710.jpg) + +Ce serveur est situé à domicile derrière une connexion FTTH Free. +Il est en charge de la surveillance de la production (métrologie, etc.) et des sauvegardes des systèmes de fichier et base de données. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| [Microtik RB4011iGS+RM](https://mikrotik.com/product/rb4011igs_rm) | Routeur | x1 | Routeur et pare-feu, ports 1x10G SFP+ et 10x1G | +| Serveur Dell R710 | Hyperviseur | x3 | 2 socket, Xeon E5520 (4c8t @ 2.26Ghz)
80Go RAM, 500GB NVMe, 1TB RAID matériel, réseau LACP 2x1G | + +Seulement une partie du serveur est mise à dispsition de Deuxfleurs : + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| metro.mercure.site | LXC | x1 | 2 CPU, 2Go RAM, 25 GB NVMe | +| bkp.mercure.site (deprecated) | VM | x1 | 4 vCPU, 8Go RAM, 40 GB Block Storage | +| minio | S3 | x1 | Sert pour les sauvegardes | + +# Rennes (Jupiter) + +![Photo de la tour à Rennes](/img/serv_io.jpg) + +Le serveur est situé à domicile derrière une connexion FTTH Free. +Il est en charge des sauvegardes de Garage. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| Tour un peu vieille | Serveur | x1 | AMD Phenom II X4 955 @ 3.2 GHz (4 cœurs)
4Go RAM, SSD 250Go + HDD 2To | +| | | | `ssh io.machine.deuxfleurs.fr` | +| Freebox Mini 4k | Routeur | x1 | 4 ports ethernet @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique | + + diff --git a/content/infrastructures/tricot.md b/content/infrastructures/tricot.md new file mode 100644 index 0000000..0c83901 --- /dev/null +++ b/content/infrastructures/tricot.md @@ -0,0 +1,18 @@ +--- +title: "Tricot" +description: "" +date: 2022-01-24T16:33:16.731Z +dateCreated: 2022-01-24T16:32:53.056Z +weight: 50 +extra: + parent: 'infrastructures/logiciels.md' +--- + +# Tricot + +Tricot est un reverse-proxy HTTP et HTTPS qui s'auto-configure à partir de [Consul](https://www.consul.io), comme le faisait Traefik, qui posait de multiples problèmes et que nous avons décidé de remplacer. Tricot s'occupe automatiquement de récupérer des certificats au près de Let's Encrypt pour rendre tous les sites accessibles en TLS. Ceux-ci sont stockés dans Consul. + +## Statut du développement + +Tricot est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif. +Le code de Tricot se trouve ici : diff --git a/content/infrastructures/xp.md b/content/infrastructures/xp.md new file mode 100644 index 0000000..279f66f --- /dev/null +++ b/content/infrastructures/xp.md @@ -0,0 +1,37 @@ +--- +title: "Expérimentation" +description: "Expérimentation" +weight: 40 +extra: + parent: 'infrastructures/machines.md' +--- + +Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, +et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, +et donc sur la disponibilité des services. Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. +Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. + +# Orsay (Neptune) + +![Photo d'illustration du Lenovo Tiny](/img/serv_m73tiny.jpg) + +Cluster staging: expérimentations avec NixOS et de nouveaux déploiements dans Nomad, avant de les mettre en service sur le cluster de production. +Cluster de test de Garage. + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| ThinkCentre M73 Tiny | Serveur | x1 | 2 cœurs, 8Go RAM, HDD 500Go | +| | | | `ssh caribou.machine.deuxfleurs.fr` | +| ThinkCentre M73 Tiny | Serveur | x2 | 4 cœurs, 8Go RAM, SSD 240Go | +| | | | `ssh carcajou.machine.deuxfleurs.fr` | +| | | | `ssh cariacou.machine.deuxfleurs.fr` | + + +# Rennes (Jupiter) + +Cluster staging (idem). + +| Désignation | Rôle | Quantité | Détails | +| -- | -- | -- | -- | +| ThinkCentre M73 Tiny | Serveur | x1 | 2 cœurs, 4Go RAM, HDD 500Go | +| | | | `ssh origan.df.trinity.fr.eu.org` | diff --git a/content/operations/_index.md b/content/operations/_index.md index 7ab49f2..5ccc5a2 100644 --- a/content/operations/_index.md +++ b/content/operations/_index.md @@ -1,9 +1,9 @@ -+++ -title = "Opérations" -description = "Opérations" -weight = 100 -sort_by = "weight" -+++ +--- +title: "Opérations" +description: "Opérations" +weight: 100 +sort_by: "weight" +--- Ce manuel recense notre savoir-faire technique, il a pour but d'accompagner nos opérateur·ices dans la réalisation de leurs tâches. diff --git a/content/prise_en_main/_index.md b/content/prise_en_main/_index.md index 635e2d7..901f641 100644 --- a/content/prise_en_main/_index.md +++ b/content/prise_en_main/_index.md @@ -3,6 +3,8 @@ title: "Prise en main" description: "Prise en main" weight: 10 sort_by: "weight" +extra: + parent: 'prise_en_main/_index.md' --- Ce manuel vous accompagne dans la découverte de nos outils. diff --git a/content/vie_associative/_index.md b/content/vie_associative/_index.md index bd0a57f..718aabf 100644 --- a/content/vie_associative/_index.md +++ b/content/vie_associative/_index.md @@ -1,8 +1,10 @@ -+++ -title = "Vie associative" -description = "Vie associative" -weight = 50 -sort_by = "weight" -+++ +--- +title: "Vie associative" +description: "Vie associative" +weight: 50 +sort_by: "weight" +extra: + parent: 'vie_associative/_index.md' +--- Ce manuel traite de tout ce qui concerne l'association, comme ses aspects légaux, les délibérations, ou l'organisation des personnes. diff --git a/templates/_nav.html b/templates/_nav.html index b183a57..0ab8ac7 100644 --- a/templates/_nav.html +++ b/templates/_nav.html @@ -9,6 +9,7 @@ {{ nav::inner_nav(root=target, current=target) }} {% endmacro %} +{# -------------------------- #} {# -------------------------- #} {# (Private) Shared+root logic to build the menu #} @@ -34,7 +35,7 @@ {% endif %} {% endmacro %} -{# On small screens, like a smartphone, hide the menu behind an hamburger icon #} +{# (Private) On small screens, like a smartphone, hide the menu behind an hamburger icon #} {% macro hamburger(root) %} {% endmacro %} -{# Build a breadcrumb for the page #} +{# (Private) Build a breadcrumb for the page #} {# It's ugly because this is the hacky part of the project #} {% macro breadcrumb(corpus, root, target) %}{% if 'parent' in target.extra and target.extra.parent != root %}{% set new_target = get_page(path=target.extra.parent) %}{{ nav::breadcrumb(corpus=corpus, root=root, target=new_target) }}:{{ new_target.relative_path }}{% endif %}{% endmacro %} +{# (Private) Render a list menu (this is the simple fallback when extra.parent is not defined #} {% macro list(list, selected) %} {% for page in list %} {% set is_selected = page.relative_path == selected.relative_path %} @@ -56,26 +58,27 @@ {% endfor %} {% endmacro %} -{# Tree menu rendering #} +{# (Private) Tree menu rendering; this function is recursive #} +{# this function takes a breadcrumb to know which part of the menu must be unfolded #} {% macro tree(tree, cursor, selected, crumb) %} {% for page in tree | get(key=cursor) %} {% set is_selected = page.relative_path == selected.relative_path %}
- {# LINK WITH SUBSECTION #} + {# Link with a (possible) subsection #} {% if page.relative_path in tree %} + {# Display link as a section #} {{ nav::link(page=page, is_selected=is_selected, is_parent=true) }} + + {# Should we unroll this part of the tree? #} {% if page.relative_path in crumb or is_selected %}
- {% set ncrumb = crumb | slice(start=1) %} - {% set ncursor = page.relative_path %} - {% if ncursor in tree %} - {{ nav::tree(tree=tree, cursor=ncursor, selected=selected, crumb=ncrumb) }} - {% endif %} + {# do the recursive call #} + {{ nav::tree(tree=tree, cursor=page.relative_path, selected=selected, crumb=crumb) }}
{% endif %} - {# SIMPLE LINK #} + {# Simple link, ie. a leaf of the tree #} {% else %} {{ nav::link(page=page, is_selected=is_selected, is_parent=false) }} {% endif %} @@ -83,10 +86,7 @@ {% endfor %} {% endmacro %} -{% macro subsection() %} - -{% endmacro %} - +{# (Private) Render a single link #} {% macro link(page, is_selected, is_parent) %} {% if is_selected %}{% endif %} -- cgit v1.2.3