Enlève tout et lie vers le wiki à la place
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
c00a998eb5
commit
f209548474
|
|
@ -1,51 +0,0 @@
|
|||
# Assemblée Générale Constitutive
|
||||
|
||||
Le 13 janvier 2020 à 19 heures, les fondateurs de l'association
|
||||
Deuxfleurs se sont réunis en assemblée générale constitutive au 24 rue
|
||||
des Tanneurs à Rennes. Sont présents Adrien, Alex, Anaïs, Axelle,
|
||||
Louison, Maximilien, Quentin, Rémi et Vincent.
|
||||
|
||||
L'assemblée générale désigne Adrien en qualité de président de
|
||||
séance et Quentin en qualité de secrétaire de séance. Le
|
||||
président de séance met à la disposition des présents le projet de
|
||||
statuts de l'association et l'état des actes passés pour le compte de
|
||||
l'association en formation.
|
||||
|
||||
Puis il rappelle que l'assemblée générale constitutive est appelée à
|
||||
statuer sur l'ordre du jour suivant :
|
||||
|
||||
- présentation du projet de constitution de l'association ;
|
||||
- présentation du projet de statuts ;
|
||||
- adoption des statuts ;
|
||||
- désignation des premiers membres du conseil ;
|
||||
- pouvoirs en vue des formalités de déclaration et publication.
|
||||
|
||||
Enfin, le président de séance expose les motifs du projet de création de
|
||||
l'association et commente le projet de statuts. Il ouvre la discussion.
|
||||
Un débat s'instaure entre les membres de l'assemblée.
|
||||
|
||||
Après quoi, personne ne demandant plus la parole, le président met
|
||||
successivement aux voix les délibérations suivantes.
|
||||
|
||||
## 1e délibération
|
||||
|
||||
L'assemblée générale adopte les statuts dont le projet lui a été soumis.
|
||||
Cette délibération est adoptée à l'unanimité.
|
||||
|
||||
## 2e délibération
|
||||
|
||||
L'assemblée générale constitutive désigne en qualité de premiers membres
|
||||
du conseil d'administration :
|
||||
|
||||
- Adrien
|
||||
- Alex
|
||||
- Maximilien
|
||||
- Quentin
|
||||
- Vincent
|
||||
|
||||
Conformément aux statuts, cette désignation est faite pour une durée
|
||||
expirant lors de l'assemblée générale qui sera appelée à statuer sur les
|
||||
comptes de l'exercice clos le 13 janvier 2021. Les membres du conseil
|
||||
ainsi désignés acceptent leurs fonctions
|
||||
|
||||
Nom, prénom et signature du président et du secrétaire de séance
|
||||
|
|
@ -1,110 +0,0 @@
|
|||
# Seconde Assemblée Générale
|
||||
|
||||
Le 7 février 2021 se tenait la deuxième Assemblée Générale (AG) de Deuxfleurs.
|
||||
Nous avons fêté nos un an d'existence !
|
||||
|
||||
Les choses étant ce qu'elles sont, l'AG s'est tenue virtuellement sur notre [Jitsi](https://jitsi.deuxfleurs.fr). Pour rendre les choses intéressantes, nous nous sommes fendus d'une présentation liminaire (*keynote* en anglais).
|
||||
Au final, nous avons réélu le même bureau qu'en 2020, à savoir : Maximilien, Alex, Adrien, Vincent et Quentin.
|
||||
|
||||
La retransmission de l'AG, accessible sur [le PeerTube de l'association TeDomum](https://video.tedomum.net/videos/watch/1df11eb4-b9d6-4c39-bbe3-2247dc577725) (qu'on remercie de nous héberger !) :
|
||||
|
||||
<iframe width="560" height="315" sandbox="allow-same-origin allow-scripts allow-popups" src="https://video.tedomum.net/videos/embed/1df11eb4-b9d6-4c39-bbe3-2247dc577725" frameborder="0" allowfullscreen></iframe>
|
||||
|
||||
Les transparents de la réunion sont accessibles ici : https://deuxfleurs.fr/_ag2021/
|
||||
|
||||
## Rapport de l'AG
|
||||
|
||||
### Bilan moral 2020
|
||||
|
||||
Deuxfleurs, constitué en association loi 1901, rappelle ses valeurs :
|
||||
|
||||
> Défendre et promouvoir les libertés individuelles et collectives à travers la mise en place d'infrastructures numériques libres.
|
||||
|
||||
#### Héberger des services informatiques de manière économique et responsable
|
||||
|
||||
Avec du matériel d'occasion :
|
||||
|
||||
- PC de bureau d'entreprise reclassés (5 ans+)
|
||||
- Vieux serveurs de datacenter (10 ans+)
|
||||
- Ancien matériel personnel (ordinateurs fixes ou portables)
|
||||
|
||||
Objectif : pas de matériel neuf quand on peut s'en passer.
|
||||
|
||||
Hébergé majoritairement chez des particuliers :
|
||||
|
||||
- Hébergement principal en Bretagne sur une fibre Free
|
||||
- Backups en région parisienne et à Bruxelles
|
||||
- Un serveur chez Gandi, et un second chez OVHCloud
|
||||
|
||||
Un ordinateur portable et une connexion internet classiques suffisent à la plupart des besoins.
|
||||
|
||||
Organisé en _sites_ géographiques (5 sites actuellement, bientôt 6 !). L'inventaire du matériel est par ailleurs public.
|
||||
|
||||
#### Services proposées
|
||||
|
||||
E-mail ; discussions instantanées ; visio-conférences ; édition collaborative ; stockage de fichiers ; hébergement de code source, de blogs texte, et de sites web.
|
||||
|
||||
Engagement de qualité : sauvegarde automatique, surveillance des ressources.
|
||||
|
||||
#### Développement logiciel
|
||||
|
||||
- Authentification unique : [bottin](https://git.deuxfleurs.fr/Deuxfleurs/bottin), [guichet](https://git.deuxfleurs.fr/Deuxfleurs/guichet)
|
||||
- Stockage distribué entre ordinateurs domestiques :
|
||||
- [Garage](https://git.deuxfleurs.fr/Deuxfleurs/garage) : Stockage objet distribué (_à la_ S3) et hébergement de sites statiques
|
||||
- [Diplonat](https://git.deuxfleurs.fr/Deuxfleurs/diplonat) : Ouverture de ports automatique pour les services sur les box grand public
|
||||
|
||||
#### « Think tank » : Éducation populaire, médiation, diffusion
|
||||
|
||||
Conversion des ami⋅e⋅s aux services libres :
|
||||
|
||||
- Matrix : Salons associatifs, d'amis, de familles...
|
||||
- Jitsi : vocapéros, réunions de boulot, de famille...
|
||||
|
||||
Peu mesurable mais très satisfaits !
|
||||
|
||||
Réflexion en cours pour refondre le site web de deuxfleurs.fr (réflexion sur le design, mandat d'une artiste pour réaliser une illustration).
|
||||
|
||||
Utilisation de _Plume_ (plateforme de blogs texte distribuée) pour écrire des articles d'opinion par certains membres.
|
||||
|
||||
L'association a par ailleurs réalisé une prestation de service rémunérée pour le collectif [Mouton Numérique](https://mouton-numerique.org/). Il s'agit d'une opération stratégique car elle nous permet de rendre service, et de créer des liens dans l'écosystème associatif et militant tout en apportant des fonds à l'association.
|
||||
|
||||
Contribution à Heylo (avec TeDomum notamment) : il s'agit d'une future passerelle pour aider à rejoindre les « réseaux sociaux fédérés ». Penser à un annuaire.
|
||||
|
||||
#### Programme moral 2021
|
||||
|
||||
- Hébergement et développements
|
||||
- mise en pratique de l'hébergement décentralisé basé sur Garage, avec un déploiement facilité
|
||||
- travailler sur la labélisation CHATON et une ouverture plus large au public
|
||||
- Diffusion
|
||||
- Avancer sur le nouveau site web (design et ensuite contenu)
|
||||
- Accueillir les nouveaux bénévoles qui souhaitent s'impliquer
|
||||
- Présence dans les lieux de rencontre militants
|
||||
|
||||
### Bilan financier 2020
|
||||
|
||||
La comptabilité de l'association est gérée sous forme de fichier plat dans un dépôt Git interne.
|
||||
Il n'y a pas de compte en banque pour le moment, en raison du coût récurrent associé.
|
||||
Les fonds sont gérés par Alex et Quentin, deux membres du bureau.
|
||||
|
||||
> État initial en janvier 2020 : 0€
|
||||
> État final au 31 décembre 2020 : 130€ (+345€,-215€)
|
||||
|
||||
#### Détails des opérations
|
||||
|
||||
- Cotisations des membres : +90€
|
||||
- Prestations facturées : +100€
|
||||
- Contributions cagnotte illustration : +155€
|
||||
- Commande illustration pour le site web : -215€ (dont 60€ pris sur fonds de l'asso, le reste issu de la cagnotte)
|
||||
|
||||
Le bilan de l'année 2020 est donc positif.
|
||||
|
||||
### Élection du bureau 2021
|
||||
|
||||
Conformément aux statuts, le scrutin est un Condorcet randomisé.
|
||||
Il y a 6 sièges à pourvoir, et il y a actuellement 10 électeurs.
|
||||
|
||||
Les candidats se présentent oralement : Adrien, Alex, Maximilien, Quentin, Vincent. Le scrutin à bulletin secret se déroule. Son résultat est disponible [ici](https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce46d726de6c615a).
|
||||
|
||||
Tous les membres du bureau sortant sont donc réélus pour 2021.
|
||||
|
||||
Merci à l'ensemble des membres du bureau, ainsi qu'à toutes celles et ceux ayant donné un coup de main à l'association en cette première année d'existence !
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
# Install Party Garage
|
||||
|
||||
Date: Samedi 29 Mai 2021 de 15h à 19h (passez quand vous pouvez/voulez)
|
||||
|
||||
Lieu : En ligne, sur Jitsi, https://jitsi.deuxfleurs.fr/garage
|
||||
|
||||
Points de contact :
|
||||
|
||||
- Sur le salon Matrix #tech:deuxfleurs.fr
|
||||
- Par email à Quentin - quentin (arobase) deuxfleurs (point) fr
|
||||
|
||||
|
||||
## Présentation de Garage
|
||||
|
||||
<p style="text-align: center">
|
||||
<a href="https://garagehq.deuxfleurs.fr">
|
||||
<img alt="Garage logo" src="https://garagehq.deuxfleurs.fr/img/logo.svg" height="150" style="box-shadow: 0px 0px"/>
|
||||
</a>
|
||||
</p>
|
||||
|
||||
Pour gérer de grands volumes de données de manière sûres, des solutions comme Ceph, Openstack Swift, ou encore Minio proposent de distribuer ces dernières sur plusieurs serveurs. Ces logiciels ont actuellement une limite importante : le matériel et le réseau doivent s'adapter à leurs contraintes.
|
||||
|
||||
Avec Garage, nous inversons cette logique : c'est **Garage qui s'adapte à votre matériel**.
|
||||
L'idée c'est de pouvoir ajouter ou enlever à peu près n'importe quelle machine, comme une vieille tour qui dort dans une armoire, depuis n'importe où à un cluster.
|
||||
|
||||
<!-- Pour comprendre les raisons qui nous ont poussé à développer Garage, on peut se référer à la définition du *hacking* de [Shoshana Zuboff](https://cryptome.org/2015/07/big-other.pdf) :
|
||||
|
||||
*[Le hacking consiste] à libérer les affordances [càd capacité d'agir, d'avoir un impact] des logiques insititutionnelles dans lesquelles elles sont bloquées et de les redistribuer dans des configurations alternatives pour des nouveaux objectifs*
|
||||
|
||||
C'est à notre avis ce qui différencie Garage des autres solutions de stockage de données,
|
||||
nous voulons aborder le stockage de données en dehors de la vision industrielle.
|
||||
|
||||
Cela fait maintenant un an que nous développons ce logiciel et le logiciel commence à prendre forme.
|
||||
Nous l'utilisons en production, et pour preuve, le site que vous voyez est directement servi par Garage.-->
|
||||
|
||||
Intéressé·e ? [Accédez à notre documentation technique](https://garagehq.deuxfleurs.fr)
|
||||
|
||||
## Comment va se dérouler l'évènement ?
|
||||
|
||||
<p align="center" style="text-align:center;">
|
||||
<img src="img/hack.webp" />
|
||||
</p>
|
||||
|
||||
|
||||
|
||||
L'évènement se déroulera en ligne sur un après-midi.
|
||||
Des développeur·euses de Garage seront présents pour vous aider, répondre à vos questions et collecter des pistes d'amélioration.
|
||||
Plus exactement, nous vous guiderons dans les étapes suivantes :
|
||||
- Télécharger et installer Garage sur votre machine
|
||||
- Le configurer pour qu'il puisse communiquer avec les instances des autres participants
|
||||
- Configurer les outils pour pouvoir intéragir avec Garage
|
||||
|
||||
Si le temps le permet, on pourra pousser plus loin comme :
|
||||
- Configurer Nextcloud pour utiliser Garage
|
||||
- Comment héberger un site web sur Garage
|
||||
- etc.
|
||||
|
||||
|
||||
## Pré-requis
|
||||
|
||||
<p align="center" style="text-align:center;">
|
||||
<img src="img/check.webp" />
|
||||
</p>
|
||||
|
||||
Pour que l'expérience se déroule dans des conditions optimales pour vous, nous vous recommandons d'avoir :
|
||||
- Une machine (virtuelle ou physique) sous Linux dédiée comme un Raspberry Pi.
|
||||
- Au moins 10Go d'espace disque de libre pour être large.
|
||||
- Une connexion Internet ADSL/LTE/Coaxial/Fibre correcte (pas trop de perte de paquets, min 1 Mbit/s up, min 8 Mbit/s down). Pas besoin d'avoir la main sur le NAT, nous utiliserons [yggdrasil](https://yggdrasil-network.github.io/)
|
||||
|
||||
*Note : Si vous voulez tester Garage sur un autre OS que Linux, votre contribution sera bienvenue mais nous ne pourrons peut-être pas vous dépanner.*
|
||||
|
||||
## Autre
|
||||
|
||||
Nous ne publions pas encore de binaire officiellement.
|
||||
Pour cette session, afin d'éviter la compilation, nous mettons à disposition les binaires pour les architectures suivantes :
|
||||
- [aarch64](https://garagehq.deuxfleurs.fr/_releases/v0.3.0/aarch64-unknown-linux-gnu/garage) - (exemple Helios64)
|
||||
- [x86\_64](https://garagehq.deuxfleurs.fr/_releases/v0.3.0/x86_64-unknown-linux-gnu/garage) - (exemple votre PC fixe ou portable)
|
||||
- [armv7](https://garagehq.deuxfleurs.fr/_releases/v0.3.0/armv7-unknown-linux-gnueabihf/garage) - (exemple Raspberry Pi 3)
|
||||
- [arm](https://garagehq.deuxfleurs.fr/_releases/v0.3.0/arm-unknown-linux-gnueabi/garage) - (pas d'exemple pour le moment)
|
||||
|
||||
Pour Yggdrasil, nous utiliserons la dernière version publiée soit la 0.3.16 dont les [binaires sont sur Github](https://github.com/yggdrasil-network/yggdrasil-go/releases/tag/v0.3.16).
|
||||
|
||||
Nous vous aiderons pour la configuration d'Yggdrasil ! Des infos sont trouvables sur le pad dont le lien vous sera communiqué sur le salon Matrix ou lorsque vous rejoindrez Jitsi.
|
||||
|
|
@ -1,135 +0,0 @@
|
|||
## Première réunion de travail
|
||||
|
||||
Date : Février 2020
|
||||
|
||||
Présent : Quentin, Alex, Maximilien, Vincent
|
||||
Remote : Simon
|
||||
Invité : Tom
|
||||
|
||||
> Maximilien prends des notes.
|
||||
|
||||
https://p.adnab.me/pad/#/2/pad/edit/VOqs46ZeH7iR2EnL63xeXxHP/
|
||||
|
||||
Depuis l'AG 1
|
||||
-------------
|
||||
|
||||
Quentin (anime la réunion) :
|
||||
|
||||
- Migration DNS (depuis Cloudflare vers Online)
|
||||
- Ajout domaine deuxfleurs.org (acheté par Maximilien)
|
||||
- Quentin explique la partie technique
|
||||
- Alex explique les avancées sur la partie LDAP/authentification basée sur consul (bottin + guichet)
|
||||
- Ajout de l'invitation dans guichet (lien à usage unique)
|
||||
- Nettoyage des comptes LDAP
|
||||
- Mettre une étiquette deuxfleurs sur la boite de Quentin
|
||||
- Discussion avec Jaxom & Almet sur l'hébergement
|
||||
- Le site web c'est important, tout le monde en parle
|
||||
- Refondre la partie graphique pour la rendre plus attrayante et moins RFC-like
|
||||
- Alex s'est lancé dans du dev de bridge matrix qui fonctionne pour mattermost et XMPP
|
||||
- Le bridge mattermost focntionne pas mal
|
||||
|
||||
Ce que l'on n'a pas encore fait
|
||||
-------------------------------
|
||||
|
||||
Banque : la moitié des cotisations part dans une banque
|
||||
Décision de faire un pot commun ?
|
||||
Continuer sans ? (mais c'est dans les statuts)
|
||||
|
||||
> Vote : trésorerie en liquide jusqu'à 200€
|
||||
> Sinon on dépense ou bien on ouvre un compte
|
||||
|
||||
- 200€ : contre 0, neutre 0, unanimité pour
|
||||
- Fonctionner en pot commun : contre 0, neutre 0, unanimité pour
|
||||
|
||||
**Motion voté.**
|
||||
|
||||
### Gestion de la comptabilité
|
||||
|
||||
Quentin a un compte courant vide. Mais à son avis pas une bonne idéee.
|
||||
Gestion de la comptabilité sur un logiciel (lequel ?)
|
||||
Trésorier ?
|
||||
|
||||
Alex a trouvé une boite.
|
||||
|
||||
> Vote : Alex est le gardien de la boite qui contient les cotisations dans la limite de 200€
|
||||
> Contre : 0, Neutre 0, Unanimité
|
||||
|
||||
Pour le choix du logiciel, Maximilien enverra un mail avec des solutions. L'idée de base est de mettre le fichier dans un repo git (facilement backupé et consultable), avec des commit signés.
|
||||
|
||||
Pour les présents, les cotisations sont payables à la fin de l'AG.
|
||||
|
||||
### Charte
|
||||
|
||||
Trouver pour la prochaine AG (voire avant) une base. Maximilien doit envoyer des idées sur la base de ce qui est fait en conférence. Quentin envoie des idées pour les projets Open-Source.
|
||||
|
||||
### Site web
|
||||
|
||||
Intégrer la documentation au site web, afin qu'elle soit consultable et plus transparent par rapport aux infrastructures.
|
||||
|
||||
Outil pour build du Markdown avec un blog statique.
|
||||
Utiliser les outils de templating des trucs web.
|
||||
|
||||
Quentin fera une proposition.
|
||||
Simon : Les gens qui font des choses se doivent de les documenter.
|
||||
|
||||
À qui s'adresse la documentation :
|
||||
- tout ce qui tourne autour de l'administration
|
||||
- de l'accessibilité
|
||||
- la partie technique
|
||||
|
||||
Répliquer le gitea d'Adrien (Maximilien va leur faire sur le sien).
|
||||
|
||||
### Lieux de réunion
|
||||
|
||||
Vincent propose le salon de thé (on peut commander un café), mais on est trop bruyant ?
|
||||
|
||||
Pas de souci tant que l'on rentre dans un salon de chez quelqu'un (jusqu'à 10-12 personnes)
|
||||
|
||||
Les objectifs
|
||||
-------------
|
||||
|
||||
Quentin : but original du CHATON, documenter l'auto-hébergement distribué, fournir des services que tu gères toi-même, sans manipulation ni tracking
|
||||
|
||||
Trois niveaux :
|
||||
- petits services
|
||||
- backups et disaster-recovery
|
||||
- CHATON (candidature chez framasoft et référencement) : l'objectif est-il d'obtenir le label ou bien simplement de s'inspirer de leur idéal ?
|
||||
|
||||
> Simon : pour la partie non technique, sauf si cela présente un effort technique trop important.
|
||||
> Quentin : leur cahier des charges n'est pas aberrant et pourrait être un guide sur le développement de l'infra
|
||||
|
||||
**TODO** : faire un document de travail (Quentin a fait une milestone dans le gitea)
|
||||
- géo-distribué (résilient à la perte d'une machine/d'un site - penser datacenter)
|
||||
|
||||
**TARGET** soumettre une candidature _CHATON_ dans 6 mois
|
||||
|
||||
Pour la géo-distribution, Quentin préconise le backend S3-compatible
|
||||
Approche totalement différente des ressources.
|
||||
|
||||
Débat à suivre.
|
||||
|
||||
### Recommandations
|
||||
|
||||
Quentin : si jamais on embarque des gens et que l'on leur fait faux bond, on dessert la cause de l'hébergement participatif.
|
||||
|
||||
Alex : il est de la responsabilité des personnes qui créent un compte de s'informer des limites
|
||||
|
||||
Simon : par cooptation : chacun voit midi à sa porte.
|
||||
|
||||
> Vote : Maximilie propose l'ajout d'un avertissement sur le formulaire d'inscription de guichet. La rédaction du bloc de text est laissé à Maximilien, et soumise à l'approbation du prochain conseil d'afministration.
|
||||
> Contre : 0, Neutre 0, Unanimité
|
||||
|
||||
Repasser sur le document de travail
|
||||
-----------------------------------
|
||||
|
||||
Alex : priorité de faire le site web et d'avoir une solution facilement éditable pour les PV d'AG & co (pas tout le temps dépendre des pads)
|
||||
|
||||
Quentin : les PV en PDF sont stockés dans un repos
|
||||
|
||||
Retex de Toms
|
||||
-------------
|
||||
|
||||
Toms est intéressé pour rejoindre l'association.
|
||||
Pas assez de vison pour savoir si c'est réalisable.
|
||||
|
||||
Quentin montre la nouvelle maquette du site web.
|
||||
|
|
@ -1,233 +0,0 @@
|
|||
# Deuxième réunion de travail
|
||||
|
||||
## Lieu et date
|
||||
|
||||
Date : 10h le samedi 16 mai 2020
|
||||
|
||||
Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
||||
|
||||
## Compte rendu
|
||||
|
||||
Alex, Max, Adrien, Vincent, Quentin
|
||||
|
||||
On s'accorde sur le temps accordé aux 3 grandes parties
|
||||
|
||||
- 15 min les valeurs
|
||||
- 30 min le debrief
|
||||
- 30 min les objectifs
|
||||
|
||||
### Discussion sur les valeurs
|
||||
|
||||
Pour les valeurs, Quentin présente une liste d'objectifs qui lui semble importants.
|
||||
Réorganisation de la structure sous forme des valeurs (cf page d'accueil du site web).
|
||||
Essaye de donner des éléments précis.
|
||||
C'est aussi une sorte de note d'intention pour plus tard pour nous aider à faire des choix.
|
||||
|
||||
Proposition d'Adrien :
|
||||
- notre -> la pour les valeurs
|
||||
|
||||
### Point sur les droits
|
||||
|
||||
Clarifier le process d'ajout de nouveaux membres administrateurs de l'infrastructure.
|
||||
|
||||
Est identifié comme relatif à l'infrastructure :
|
||||
- L'accès à l'organisation Deuxfleurs de git (infrastructure, etc.)
|
||||
- L'accès à la solution d'interconnexion des services (Consul Connect, VPN)
|
||||
|
||||
### Points sur les documents dits "internes"
|
||||
|
||||
Sont concernés:
|
||||
|
||||
- Liste des membres
|
||||
- Comptabilité de l'asso
|
||||
- Notes interne au CA concernant les procédures de gestion etc.
|
||||
|
||||
Créer un repo git privé dans l'orga Deuxfleurs du gitea.
|
||||
|
||||
### Debrief des deux mois
|
||||
|
||||
|
||||
#### Site web
|
||||
|
||||
Sur ces deux derniers mois, on a déployé notre site web.
|
||||
Le système est simple (pour une personne connaissant git) : on push des fichiers Markdown et le site se met à jour tout seul (generateur statique + webhook)
|
||||
|
||||
Design graphique perfectible : on pourrait engager un designer graphique. Mais probablement le payer.
|
||||
Pour le contenu fouilli : ça évolue beaucoup et vite, Adrien trouve que ça commence à s'organiser.
|
||||
|
||||
**Plateforme d'hébergement de site ?** Adrien a une plateforme Wordpress en place.
|
||||
Quentin préfère l'hébergement de fichiers statique.
|
||||
Quentin aimerait proposer un système basé sur l'API S3 de Garage.
|
||||
- Les utilisateur créer un bucket depuis Guichet
|
||||
- Ensuite, ils construisent leur site en local via le logiciel libre [Publii](https://getpublii.com/).
|
||||
- Ils configurent les identifiants S3 de deuxfleurs dans ce logiciel et cliquent sur "Déployer"
|
||||
|
||||
Les avantages de ce système :
|
||||
- Ultra léger (sobriété numérique)
|
||||
- Sécurisé (on ne manipuler que des fichiers de notre côté)
|
||||
|
||||
Par contre, on est très loin de pouvoir le mettre en place.
|
||||
Le système d'Adrien plus conventionnel et ne nécessitant pas d'installer de logiciel particulier est déjà disponible.
|
||||
|
||||
**Est ce qu'on pourrait faire un blog / aggrégateur de contenu ?**
|
||||
Pour l'instant le plus simple serait de mettre un planet.
|
||||
Vincent, Adrien et moi aurions des choses à dire pour un planet.
|
||||
Quelques idées d'articles :
|
||||
|
||||
- J'en ai marre de Google, aidez-moi !
|
||||
- Je hais mon smartphone
|
||||
- Sobriété numérique : nos réflexions (à bas les petits gestes)
|
||||
|
||||
|
||||
#### Jitsi
|
||||
|
||||
Focus sur quelques points :
|
||||
- Voix aigues (femmes) qui ne passent pas (Codec low bitrate ? Firmware ? Micro)
|
||||
- Configuration du videobridge qui change (hack routing nginx)
|
||||
- Point sur l'avancement Firefox à faire à la prochaine réunion
|
||||
|
||||
Rémi a mis en place son jitsi également.
|
||||
Alex a utilisé le Jitsi avec 15 personnes.
|
||||
|
||||
#### Garage
|
||||
|
||||
Objectif : remplacer GlusterFS trop lent / trop buggé.
|
||||
Veut se faire passer pour un "vrai" système de fichiers qui pourrait être une raison des lenteurs.
|
||||
À la place on voudrait cibler plus simple : un object storage.
|
||||
State of the art : le plus prometteur est Minio mais restrictions bizarres.
|
||||
|
||||
Alex a fait de Garage son projet de confinement.
|
||||
On a une version "beta" qui fonctionne avec Nextcloud.
|
||||
|
||||
Question qui reste en suspens : la fiabilité ?
|
||||
Le modèle : les données sont répliquées 3 fois.
|
||||
|
||||
Si tu as des machines sur des sites/datacenters différents, tu peux les dispatcher sur différents datacenters.
|
||||
À quel point la solution est fiable ?
|
||||
Il faudrait faire des tests : analyser plus le code.
|
||||
|
||||
Soucis techniques : congestion entre datacenters.
|
||||
Controler le nombre de requetes que tu envoies.
|
||||
|
||||
On ne voudrait pas détruire l'information directement.
|
||||
Backup vs suppression de données.
|
||||
|
||||
Vincent pense à la suppression scabreuse de Facebook qui ne faisait que déréférancer les fichiers de l'interface mais ces derniers étaient toujours accessible publiquement via leur URL [référence](https://arstechnica.com/information-technology/2010/10/facebook-may-be-making-strides/).
|
||||
|
||||
Préciser la politique (30 jours, un admin peut y accéder, elles peuvent être restaurées en cas d'accident majeur).
|
||||
|
||||
#### [Garage Kids](https://codelyoko.fandom.com/fr/wiki/Garage_Kids) : foire à l'espace disque
|
||||
|
||||
Commencer les expérimentations sur Garage.
|
||||
|
||||
Liste de l'espace disque :
|
||||
- Quentin : 3 x 1To
|
||||
- Adrien (un NAS plus tard ?! Ses parents ?! Synology ouvert ?! [docker](https://www.synology.com/fr-fr/dsm/packages/Docker)) - rien de précis pour l'instant
|
||||
- Maximilien : 1To
|
||||
- Alex : peut libérer >1To sur serveur Kimsufi (donc en datacenter et non en auto-hébergé)
|
||||
|
||||
Stockage des backups :
|
||||
- Offsite ?
|
||||
- Dans Garage ?
|
||||
|
||||
Adrien pensait du backup avec des rsync/tar.
|
||||
Adrien a commencé à faire du backup.
|
||||
|
||||
Maximilien met à disposition un VM pour le backup de la stack chez Quentin
|
||||
|
||||
#### Interconnexion
|
||||
|
||||
Battle Royal : VPN (supporter : Alex) vs Service Mesh (supporter : Quentin)
|
||||
|
||||
Contexte/But : Essayer d'avoir des machines dans différents datacenters. On voudrait les interconnecter entre elles.
|
||||
Le cas d'usage c'est le LDAP, pour le consommer depuis des machines.
|
||||
Wireguard est un module noyau, bonne efficacité.
|
||||
|
||||
Trouver comment on va expérimenter l'interconnexion.
|
||||
On aurait besoin de VM derrière des NAT -> réalisme du déploiement.
|
||||
|
||||
La réunion se termine sur ces belles paroles :-)
|
||||
|
||||
---
|
||||
|
||||
## (Archives) Ordre du jour
|
||||
|
||||
- Nos valeurs :
|
||||
- protèger notre vie privée
|
||||
- économie de la surveillance
|
||||
- défendre notre liberté d'expression
|
||||
- économie de la surveillance
|
||||
- ne pas se laisser manipuler
|
||||
- économie de l'attention
|
||||
- choisir la sobriété numérique
|
||||
- prendre les décisions ensemble
|
||||
- mettre en commun nos connaissances et nos infrastructures
|
||||
- consommation excessive (obsolescence, incompatibilités, gadgets)
|
||||
- protection libertés:
|
||||
- on ne censure pas - dans les limites de la loi - ce que vous voulez partager
|
||||
- ne vous manipule pas
|
||||
- on répond à un besoin, on fournit des outils
|
||||
- on n'essaye pas d'augmenter le temps passé sur nos services
|
||||
- on ne propose pas de recommandations automatisées ou d'algorithmes "boite noire" dont le fonctionnement serait inconnu ou inexplicable
|
||||
- on valorise la transparence, tout est public par défaut (comme nos compte-rendus d'AG ou notre documentation technique)
|
||||
- promeut la sobriété numérique:
|
||||
- on réutilise du vieux matériel tant qu'on peut
|
||||
- on optimise le logiciel
|
||||
- solidaires ([définition 2 du CNRTL](https://www.cnrtl.fr/definition/solidaire), peut etre pas le bon mot)
|
||||
- choix de services grand public (jitsi plutôt que mumble, matrix plutot que IRC, etc.)
|
||||
- documentation / aide pour l'utilisation de ces services
|
||||
- valoriser et légitimer l'accompagnement humain dans l'usage des services, mis en valeur par le choix du parrainage.
|
||||
- participatif
|
||||
- mettre en commun le savoir
|
||||
- Déploiement de Jitsi
|
||||
- mettre en commun le code
|
||||
- Code publié sous license libre
|
||||
- mettre en commun les infrastructures
|
||||
- backups chez Maximilien
|
||||
- git chez Adrien
|
||||
- matrix chez Quentin
|
||||
- faire les choix collectivement, diluer le pouvoir
|
||||
- association collégiale
|
||||
- Temps de discussion avec les nouveaux / invités
|
||||
- Debrief des deux mois
|
||||
- Déploiement du site web
|
||||
- Déploiement et debug du Jitsi
|
||||
- Manque de doc : gestion du TURN
|
||||
- User and Developer Experience pretty bad
|
||||
- Problème avec le traitement de l'audio : voix féminines coupées
|
||||
- Succès dans mon entourage
|
||||
- Échec sur l'ADSL
|
||||
- Conclusion : la pire solution de VoIP à l'exception de toutes les autres !
|
||||
- Développement de Garage
|
||||
- Soucis de congestion entre datacenters: gestion des connexions sortantes à améliorer
|
||||
- Opérations de suppression: TODO garder les vieilles versions pour un certain temps (30 jours) pour éviter toute fausse manip
|
||||
- Ça semble fonctionner bien avec NextCloud
|
||||
- Est-on prêts à se lancer dans un test grandeur nature ?
|
||||
- Interconnectons nos infrastructures. [Plus d'informations par ici](/Technique/Jalon/Interconnexion.html)
|
||||
- La foire à l'espace disque : échangeons nos backups !
|
||||
- Quels espaces sont déjà disponibles ?
|
||||
- Quels projets de développement ? (Adrien se paiera un NAS, un jour. Max a fourni un serveur à installer.)
|
||||
- Mes parents (Adrien) ont un Synology. Ca sert à autre chose que le chauffage ? Ya moyen de l'exploiter ?
|
||||
- Le site web
|
||||
- Problèmes :
|
||||
- UI pas responsive (ça reste lisible néanmoins)
|
||||
- Quentin : Problème réglé
|
||||
- Esthétique à améliorer : je veux des roses cyberpunk.
|
||||
- On connaît des designers motivés ?
|
||||
- Contenu fouillis, manque de contexte
|
||||
- Réfléchir à une structure
|
||||
- Quels sont les objectifs et contraintes du site ?
|
||||
- Quentin mentionnait un besoin de fonctionner sans JS, une page légère... On pourrait en discuter et mettre ça au propre ?
|
||||
- Quentin : [Comment créer un site web basse technologie](https://solar.lowtechmagazine.com/fr/2018/09/how-to-build-a-lowtech-website.html) : ici ce n'est pas l'économie d'énergie du serveur qui nous intéresse mais une compatibilité fluide avec les vieux terminaux et les mauvaises connectivités mobiles. Je sais de quoi je parle, mes parents ont un ADSL de piètre qualité.
|
||||
- Quentin : C'est d'autant plus important qu'en favorisant de vieille machines derrière des connexions domestique, on a une contrainte de départ plus forte sur le matériel et on a pas de CDN pour masquer le manque d'opti/lourdeur du site web traditionnel
|
||||
- Adrien dit : "Fuck SCSS/SASS, vive CSS"
|
||||
- Framework HTML/CSS
|
||||
- "cross-browser consistency" au minimum ([normalize.css](http://nicolasgallagher.com/about-normalize-css/))
|
||||
- responsive design & utilities ([Foundation](https://get.foundation/sites/docs/), [Pure](https://purecss.io/), Bootstrap... Adrien connaît bien Foundation, un truc comme Pure serait plus léger)
|
||||
- Quentin : À voir ce que les frameworks apportent de plus une fois un reset CSS + flexbox + media queries en place. Qui plus est, tout n'est pas configurable dans bootstrap et on se retrouve vite à empiler des hacks.
|
||||
- On fait un blog ?
|
||||
- J'ai (Adrien) quelques projets de guides et d'articles sur les libertés numériques - j'imagine que vous aussi. On pourrait proposer des articles sur blog.deuxfleurs.fr, et/ou faire un agrégateur de nos propres blogs (si vous en avez tous un, moi pas).
|
||||
- Quentin : Dans l'absolu si on peut faire le blog sur la meme plateforme que le site web, je trouverais ça bien. Sinon, un truc à penser ce serait ActivityPub pour que les gens puissent suivre le blog dans leur Mastodon par exemple, aka le Fediverse.
|
||||
- Quentin : Voir si blog peut être sur Mobilizon et déployer une instance de ce dernier donc si on veut de l'ActivityPub et qu'on peut pas l'intégrer sur le site statique.
|
||||
|
||||
*N'hésitez pas à compléter ce document en modifiant le fichier `src/Association/Réunion_2.md` du [dépôt du site Deuxfleurs](https://git.deuxfleurs.fr/Deuxfleurs/site)*
|
||||
|
|
@ -1,145 +0,0 @@
|
|||
# 3ème réunion de travail
|
||||
|
||||
**Date :** Samedi ou Dimanche 18-19 septembre, heure à définir [ici](https://p.adnab.me/poll/#/2/poll/edit/fITPAFijw60mEk5Hxw9Q3UC5/)
|
||||
|
||||
**Lieu :** [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
||||
|
||||
|
||||
## Compte Rendu
|
||||
|
||||
**Budget & Dépenses**
|
||||
On a parlé budget.
|
||||
Il y a 70€ dans la caisse, les cotiz sont à renouveler en janvier.
|
||||
Pour le moment l'hébergement des serveurs et les noms de domaine sont à notre charge personnelle. Il serait assez logique qu'on paye les noms de domaines deuxfleurs.fr et deuxfleurs.org via la thune de l'asso.
|
||||
Quentin plutôt pour taper dans la caisse pour payer Ronce.
|
||||
On décide ensemble ce qu'on sort de la caisse, et on fournit en donation par membre "à la discrétion de chacun".
|
||||
Florian (et Vincent) il a pas payé la cotiz !!! Ils vont donc allonger leurs 10 balles komtoulmonde.
|
||||
|
||||
**Charte Graphique**
|
||||
Qu'est ce qu'on priorise ? On veut qu'elle nous aide à quoi ? Charte graphique ? Juste le site ? Logo ?
|
||||
Charte graphique = logo, déclinaisons en couleur/n&b/simplifié, palette de couleurs (<= 5), une police de titre, police de corps, quelques indications supplémentaires (dit Max, en se basant sur Tedomum dont il participé à la charte graphique)
|
||||
Charte graphique, c'est relativement standard, elle devrait comprendre sans qu'on ait à discuter avec elle.
|
||||
Quentin trouve qu'on aurait besoin de discuter avec elle du projet.
|
||||
Adrien ajoute que notre site est pas aussi clair que celui de Tedomum et que ça servirait.
|
||||
Max dit qu'on peut pas être 12 à lui parler, ça mettrait plus de bruit qu'autre chose.
|
||||
On a créé un groupe dédié pour le graphisme.
|
||||
|
||||
On a finit avec une cagnotte graphisme de 215 euros (dont 60 euros de la caisse).
|
||||
On a voté pour sortir les 60€ de la caisse pour Ronce à l'unanimité.
|
||||
Ainsi que pour demander une charte graphique ?
|
||||
Pour savoir qui est dans le groupe projet, on a testé un vote avec pourcentage d'intérêt.
|
||||
Adrien: 100%, Quentin 40%, Alex 10%, Max 30%, Florian 20%, Vincent 25%
|
||||
Vu qu'on a pas tout le monde on demandera aux absents (Louison, on pense à Louison parce qu'il est fortiche en intégration)
|
||||
|
||||
Pour la création d'une cagnotte pour les donations individuelles, on fait les virements avec motif à Adrien (voté à l'unanimité). On aura besoin d'un devis et une facture (au nom de Deuxfleurs) pour rester dans les clous.
|
||||
|
||||
**Tech**
|
||||
Florian il veut sysadmin avec nous ! YES !
|
||||
Est-on d'acc pour lui donner les accès root sur deuxfleurs ?
|
||||
On a pas de process bien défini pour ajouter des admins, à part commencer par la présenter.
|
||||
Une PR sur un des repos deuxfleurs ?
|
||||
Il a participé à l'InsaLan, tout comme Quentin mais pas en même temps.
|
||||
Il semblerait qu'on ait bien besoin d'un admin supplémentaire au vu de la gueule de la boite mail.
|
||||
Vote à l'unanimité pour que Florian nous rejoigne comme sysadmin.
|
||||
|
||||
**Aide d'une asso en besoin**
|
||||
Ils ont un site web, un Wordpress <3 Pas à jour avec des plugins troués. Ont un virus avec redirection (Quentin le sait, il a Fedora).
|
||||
Appel téléphonique : vous n'allez pas vous en sortir en ajoutant un plugin de sécu vu qu'ils sont déjà pwn.
|
||||
Mais ils vont pas filer les IDs à Quentin pour qu'il s'en occupe, ça ressemble à l'attaque de social engineering de base. Plutôt, ils seraient assez chauds pour qu'on les héberge.
|
||||
Adrien propose une approche par conteneur qui ne sécurise pas l'install, mais évite les effets de bord et est facilement réparable.
|
||||
Quentin veut un site full read-only.
|
||||
Max fait remarquer que tout l'intérêt du Wordpress est l'administration pousse-bouton back-office.
|
||||
Aspects légaux, DDoS et tout : on sait y répondre et on gèrera si les problèmes se produisent.
|
||||
|
||||
**Et nous, on fait quoi niveau hébergement ?**
|
||||
On a écrit sur https://deuxfleurs.fr/Guide/Sites%20web.html que l'hébergement était gratos, on reste dessus ou pas ? Non, on réécrit "contactez-nous on en discutera".
|
||||
Quentin dit qu'ils pourront bien payer quelques euros.
|
||||
On est ok pour héberge l'asso en détresse !
|
||||
|
||||
**Matériel pour nos infras**
|
||||
Où choper des serveurs ? Brokers, ou circuit pro récupéré par des particuliers. Les brokers peuvent livrer les serveurs et tout, c'est pas mal !
|
||||
On peut argumenter que c'est mieux que des Raspi vu que c'est du recyclage ! Ca consomme plus, certes (15W au lieu de 5W), mais c'est modulable (on peut rajouter de la RAM, etc).
|
||||
R710 = 300€ pièce, 18 slots pour la RAM. Par contre ça consomme 100W en idle et ça fait balle de bruit.
|
||||
|
||||
**Garage et Nextcloud**
|
||||
Maintenant on parle de comment on pourrait faire du Nextcloud bien robuste grâce à Garage.
|
||||
Quentin et l'hébergement NextCloud. Déjà live mais caché sur nextcloud.deuxfleurs.fr
|
||||
Avec de l'HA (high avail).
|
||||
Nécessite de connecter Consul et Nomad en IPv6
|
||||
Quelle est la quantité de stockage qui est ajoutée au cluster si je contribue X Go au cluster ?
|
||||
Il y a trois copies, donc on contribue X/3
|
||||
C'est assez sexy : Adrien serait bien content de pouvoir arrêter d'héberger son propre NextCloud et payer plutôt un disque dur à Deuxfleurs.
|
||||
C'est tout l'idée de l'asso ! Mutualiser le travail de sysadmin : qu'on ne passe pas chacun notre vie à gérer.
|
||||
Si les parents d'Adrien contribuaient leur Synology (e.g. 5 To) via garage, ils pourraient aussi profiter du NextCloud de Deuxfleurs (HA full sécure) ou de toute app nécessitant du stockage.
|
||||
|
||||
Comment ça marche l'adressage sur Garage ? IPv4 ? Port Forwarding nécessaire. IPv6 ? Possibilité d'ouvrir des ports dans le firewall de la box. Pas besoin de DNS dynamique. Pas besoin d'IP fixe. LX est le maitre des clés, il te fournit un certificat (ou plutôt signe ton certficat) pour accéder AU GARAGE.
|
||||
Tu installes et configure GARAGE et tu contribues du stockage pour LA COMMU <3
|
||||
|
||||
**Un NAS est il Deuxfleurs compatible ?**
|
||||
Adrien aurait un Synology chez ses darons qui chôme.
|
||||
Pas une bonne idée de flasher un Debian dessus - drivers spécifiques et parents qui peuvent plus gérer.
|
||||
Profiter plutôt du système de conteneurs.
|
||||
Pas ajoutable au cluster Deuxfleurs.
|
||||
Vérifier les specs.
|
||||
Une tour à côté qui fait compute pendant que le NAS fait storage.
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Une asso souhaiterait qu'on les héberge.
|
||||
* Au cas où : tout le monde est d'accord ?
|
||||
* Définir un cadre « légal » à l'hébergement ? Les hébergés ont tendance à apprécier les garanties...
|
||||
* Discuter l'aspect financier. On a marqué ça à la page [Hébergement de site web de Deuxfleurs](https://deuxfleurs.fr/Guide/Sites%20web.html) : « À terme, on demandera (sans doute) de s'inscrire à l'association pour être hébergé, mais pour le moment c'est gratuit et ouvert à tou.te.s, profitez-en ! »
|
||||
Ça convient à tout le monde ?
|
||||
* Identité visuelle :
|
||||
* Définir nos besoins/attentes/envies pour la communication visuelle de Deuxfleurs (dans le dépôt : https://git.deuxfleurs.fr/Deuxfleurs/design)
|
||||
* Tout le monde est d'accord pour demander son aide à Ronce ([site web](http://www.roseluxey.com/), [Insta](https://www.instagram.com/rose_luxey/), [ArtStation](https://www.artstation.com/ronce)), illustratrice/dessinatrice et soeur d'Adrien ? Si oui planifier un conf-call avec elle pour discuter de nos idées.
|
||||
* Quels besoins administratifs pour la rémunérer proprement si on emploie ses services ? (Pour rappel, elle accepte d'être payée en nature pour du petit boulot, ou pour démarrer.)
|
||||
* Comment lever ce genre de fonds ? Appel à donation au sein de l'asso par ex. Discuter des pour et contre. On ne veut pas que les adhérents se sentent forcés de contribuer financièrement. Mais on veut bien payer nos prestataires extérieurs.
|
||||
* Retour Planet : est ce que c'est utile ? on peut référencer nos articles à la main dans un premier temps ?
|
||||
|
||||
## Qui fait quoi d'ici là ?
|
||||
|
||||
Quentin :
|
||||
|
||||
* ✅ Référencer l'article StopCovid
|
||||
* ✅ Finir une v1 de Diplonat.
|
||||
* ✅ Déployer une V1 de Platoo
|
||||
* ⌛ Faire des backups sur la machine de Max.
|
||||
* ✅ Penser à vérifier avant la réunion l'état du support de Jitsi par Firefox
|
||||
* ✅ Semblerait OK via @Vincent : https://linuxfr.org/news/firefox-76-dites-septantesix#toc-prise-en-charge-de-jitsi
|
||||
* ✅ J'ai mis à jour Jitsi vers la dernière version et réautorisé Firefox
|
||||
* ⌛ Email
|
||||
* ✅ Ajouter une doc pour expliquer comment rajouter un nouveau domaine
|
||||
* ✅ Chercher des pistes pour réparer IMAP qui est lent ?
|
||||
* Cyrus IMAP -> pas d'abstraction du stockage, Cyrus Murder pour de la replication ad hoc
|
||||
* [DarkMail](https://darkmail.info/downloads/dark-internet-mail-environment-june-2018.pdf) - ex Lavabit. Abandonné
|
||||
* [Maddy](https://foxcpp.dev/maddy/) - Caddy de l'email, pas d'abstraction sur le stockage non plus
|
||||
* Rien de probant de manière générale.
|
||||
* Propositions :
|
||||
1. Utiliser la réplication d'IMAP plutot que GlusterFS dans un premier temps
|
||||
2. Écrire un backend S3/Garage pour plus tard maybe en Go/OCaml/Rust (qui peuvent tous compiler en bibliothèque dynamique C)
|
||||
* Tester quelque chose
|
||||
* ✅ Accepter la PR#1 d'Alex (lol)
|
||||
* ✅ Mettre à jour Consul+Nomad
|
||||
* ✅ Fix le boot du cluster
|
||||
* ✅ fstab lu avant le boot de GlusterFS
|
||||
* ✅ nomad+consul démarrés avant le réseau
|
||||
* Améliorer l'image Nextcloud
|
||||
* Début du chantier IPv6
|
||||
* Ajouter le support d'IPv6 à diplonat
|
||||
* Faire communiquer Nomad+Consul en IPv6
|
||||
|
||||
Alex :
|
||||
|
||||
* ✅ Repo git "interne" avec la compta
|
||||
* PoC infra à base de VPN
|
||||
* Garage:
|
||||
- À coder: garder les données 30 jours lors d'une suppression
|
||||
- Tests de fiabilité
|
||||
- Déploiement beta sur le cluster, peut se configurer en TLS direct entre les datacenters (sans VPN ou Consul Connect)
|
||||
- Interface web de gestion: dans Guichet (mieux) ou à part (plus simple)
|
||||
|
|
@ -1,107 +0,0 @@
|
|||
# 4ème réunion de travail
|
||||
|
||||
Le Dimanche 15 novembre à 16h, sur [jitsi.deuxfleurs.fr/](https://jitsi.deuxfleurs.fr/)
|
||||
Étaient présents : A., L., V., M., Q., T. (pseudonymisation pour la condidentialité)
|
||||
|
||||
**Vie associative** Nous avons discuté de l'AG qui allait arriver très vite, de la nécessité de faire un bilan comptable mais aussi de la refonte de notre site web, notre outil de communication principal.
|
||||
|
||||
*Format de la réunion*
|
||||
On a essayé un format différent, sans ordre du jour détaillé à l'avance.
|
||||
A. a proposé de faire un tour de table. De comment ça va, on s'est vite étendu... :P
|
||||
Les échanges contenant des infos personnelles, je n'ai gardé que les infos publiables et les ait réorganisées par thématiques.
|
||||
|
||||
*Planifier la prochaine AG*
|
||||
Il va falloir penser à planifier l'AG.
|
||||
Savoir si on prévoit un bilan comptable.
|
||||
Préparer un bilan moral probablement.
|
||||
Choisir une date, convoquer les gens et tout !
|
||||
Ce sera très probablement notre prochaine réunion.
|
||||
|
||||
*Projets pour le site*
|
||||
R. nous fait une illus, doit nous envoyer un devis bientôt.
|
||||
Pas de deadline pour la livraison vu le prix qu'elle nous fait.
|
||||
Q. et A. s'occupent de refondre le site web en se basant sur cette illus.
|
||||
|
||||
Avec l'hébergement de sites sur Garage, on aurait
|
||||
1. une présentation qui pète et
|
||||
2. de la fiabilité,
|
||||
3. d'où la possibilité de postuler pour devenir un CHATON
|
||||
|
||||
Q. est motivé pour avancé sur cette partie.
|
||||
|
||||
*Trésorerie*
|
||||
La trésorerie et le bilan comptable : on est censés générer une facture par adhésion and co. Il voudrait rendre ça plus propre, streamlined. Éviter le moment dans plusieurs mois ou on se rendra compte qu'on a plein de retard sur la compta.
|
||||
Format tableur git-able. Donc CSV, actuellement texte.
|
||||
V. dit que pas besoin de compta publique dans notre cas mais recommandé.
|
||||
V. créer un canal "administratif" sur matrix pour discuter de tout ça et nous aider à bien faire les choses.
|
||||
|
||||
**Logiciels** Actuellement nous sommes dans une phase de développement de Garage et réfléchissons à comment interconnecter nos clusters sur internet car nous voulons protéger la confidentialité des échanges.
|
||||
|
||||
*Garage*
|
||||
L. aide Q. sur Garage, il relit des PR et donne des conseils, répond aux questions, etc.
|
||||
On peut rajouter nos noeuds au cluster de Q., nos plages IPv6 sont whitelistées donc les noeuds sont accessibles pour nous.
|
||||
|
||||
Mettre de la CI/CD sur garage.
|
||||
Ca l'ennuie de devoir build en local, il préfererait un build automatique avec tests and co.
|
||||
Sur Plume, il y avait un DroneCI avec le gitea de Plume.
|
||||
L. et Q. avait pensé que Nomad pourrait être utilisé comme CI/CD grâce à ses batch jobs (il faudrait juste un *thin wrapper* pour empêcher n'importe qui de submit des jobs).
|
||||
|
||||
*Consul & Bottin*
|
||||
Question du LDAP sur Gitea and co.
|
||||
LDAP accessible que sur le LAN de Q.
|
||||
Pas possible aujourd'hui sur le WAN car pas de chiffrement TLS.
|
||||
Deux options :
|
||||
1. Fédérer Consul sur le WAN (compliqué mais désirable sur le long terme)
|
||||
2. Exposer LDAP en TLS (plus simple)
|
||||
1. En TLS auto-signé (simple)
|
||||
2. Avec une CA trusted type Let's Encrypt (compliqué avec Traefik)
|
||||
Q. peut donner un coup de main pour ouvrir le LDAP sur internet/des plages IP.
|
||||
|
||||
*Traefik*
|
||||
Doit-on garder Traefik ? Très embedded, s'intègre mal, etc. Discutable ici [#22](https://git.deuxfleurs.fr/Deuxfleurs/deuxfleurs.fr/issues/22).
|
||||
|
||||
*Nextcloud*
|
||||
A. a dit qu'il était intéressé par la maintenance/logiciel : son Nextcloud est toujours down.
|
||||
Q. peut aussi travailler sur le NextCloud si besoin (on en parlait beaucoup à la réu précédente).
|
||||
|
||||
*Métrologie*
|
||||
M. a une idée, mais c'est pas implémenté. Il pense monter une VM, chez lui. 3 tunnels depuis cette VM jusqu'à chacun des noeuds. Telegraf en local qui ramène les données.
|
||||
|
||||
*Tor*
|
||||
T. a travaillé sur Tor avec Isis sur les parties crypto rust.
|
||||
Elle est intéressée par la crypto de Tor.
|
||||
Q. a un relai Tor également mais sur un VPS.
|
||||
Q. a travaillé sur les perfs réseaux de Tor : latence et bande passante.
|
||||
T dit que si on multiplexe pas les connexions Tor, on dépasserait le nombre de ports : T. a dans les 9 000 connexions simultanées sur son relai.
|
||||
|
||||
**Opérations** Étant en auto-hébergement, nous devons gérer nos propres machines, leur système d'exploitation et leurs pannes...
|
||||
|
||||
*Cluster Géo Distribué*
|
||||
V. aimerait ajouter un noeud, mais ça a pas l'air novice-friendly. Il est toujours avec ses déboires ADSL, et il a du taff, donc c'est pas pour tout de suite.
|
||||
|
||||
T. un serv Ryzen 3600 32GB et 6TB de disque pas monté. De quoi faire une belle VM si on veut faire des trucs dessus. Mais il faut mettre un hyperviseur et monter les disques, cest pas pour tout de suite. Voudrait chiffrer intégralement le disque avec un TPM pour donner la clé automatiquement.
|
||||
|
||||
*Système*
|
||||
T. veut faire du zfs RAIDz1 (RAID5).
|
||||
M.: Si tu prends une version de zfs > 8 tu peux avoir le chiffrement direct.
|
||||
T. préfère luks parce qu'elle connait.
|
||||
Il parait que le chiffrement zfs chiffre pas toutes les méta-données.
|
||||
|
||||
Le TPM c'est chouette mais si une personne débarque chez toi, il lance le PC sans souci.
|
||||
T. utilise CLEVIS, un système de chiffrement cloud qui empêche le PC de boot si il a pas le bonne IP.
|
||||
|
||||
*Sauvegardes*
|
||||
M. a deployé une VM pour stocker les backups de Deuxfleurs, ya 50 GB dessus mais étendable.
|
||||
Port forward un port, zone réseau dédiée.
|
||||
La VM est backup en elle-même, chaque semaine, chez M.
|
||||
Si bien que si la backup fout tout en l'air, on a encore les anciennes versions.
|
||||
Ça intéresse A pour la backup du git.
|
||||
Il suffit d'envoyer une clé SSH à M.
|
||||
L. pourrait s'intéresser à la création régulières des backups postgres et consul.
|
||||
Les données ne sont pas chiffrées sur le serv de backup. Il vaudrait mieux les chiffrer avant envoi.
|
||||
M. va prendre toutes les clés du repo (cluster) dans les scripts ansible pour les mettre dans la VM de backup.
|
||||
La DB de Synapse pèse plusieurs Go (compressée). C'est chiant. Mais mieux vaut garder du `.sql.gz` que d'avoir des chunks, parce que si un chunk est corrompu c'est foutu. Les chunks c'est sympa au fil de l'eau, mais il faut un snapshot complet de temps en temps.
|
||||
Stolon a un système de Point in Time recovery.
|
||||
La VM n'a pas accès au monde extérieur sauf via 443.
|
||||
L. créer une clé pour le cluster, il l'envoie à M., qui créer un utilisateur.
|
||||
La clé SSH sera dans le consul.
|
||||
|
|
@ -1,111 +0,0 @@
|
|||
# 5e réunion de travail
|
||||
|
||||
Le Dimanche 21 mars 2021, sur [jitsi.deuxfleurs.fr/](https://jitsi.deuxfleurs.fr/)
|
||||
Étaient présents : M., A., Al., Q., V., L., T. (pseudonymisation pour la condidentialité)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Rapport de l'AG
|
||||
* Appel à projets NGI Pointer
|
||||
* Avancement du site web/commission design
|
||||
* Garage - explication aux autres membres qui part en discussion techniue
|
||||
* Boîte à idées : membres, que désirez-vous ?
|
||||
* Infrastructure : des nouvelles de la salle des machines
|
||||
|
||||
## Compte rendu
|
||||
|
||||
### Rapport de l'AG
|
||||
|
||||
Mettre sur deuxfleurs.fr les rapports moral & financier, élection du bureau 2021.
|
||||
|
||||
M. se propose de le faire cet aprem. À pousser sur deuxfleurs.fr après validation.
|
||||
|
||||
### NGI Pointer
|
||||
|
||||
Appel à projet de la comission européenne, pour petites équipes (en solo ou via un organisme de recherche). Dealine 1er avril pour les soumissions. On cherche à avoir de l'argent pour 2 personnes pour bosser sur garage durant 1 an. Améliorer le backend et mettre en place un stockage IMAP. Validation des projets en mai/juin, début en septembre. A. dit que l'on a intéret à bosser avec INRIA, mais on ne veut pas qu'ils chapeautent tout. C'est même le partenaire à l'INRIA qui a dit qu'il serait mieux pour le projet que Deuxfleurs porte le projet.
|
||||
|
||||
Sans doute payer un comptable pour que Deuxfleurs embauche des salariés.
|
||||
|
||||
L. a regardé comment une asso peut embaucher. Les mairies peuvent donner de l'aide sur ce sujet.
|
||||
|
||||
Ca implique de créer un compte bancaire, faire un bilan comptable carré, validé par un commissaire au compte.
|
||||
|
||||
Le but, c'est de pouvoir dédier tout notre temps à Deuxfleurs, sans trop nous comprommettre.
|
||||
|
||||
On ne prévoit pas de breveter !
|
||||
|
||||
**Application form** : claim qui envoie du gros genre "... is broken", à étayer dans le texte. Par ex : on réplique des données, mais pourquoi ? Le problèème c'est que les données sont un « critical asset ». Ya pas de logiciel qui permette de gérer des backups de façon intégrée. On passe notre temps à se battre avec nos softs. Nous on veut du all-in-one.
|
||||
|
||||
Recrutement de T. au moins dans le consortium - parce qu'elle a de solides contribs à l'informatique libre dont on pourra se vanter.
|
||||
|
||||
### Commission design
|
||||
|
||||
Utilisent Penpot, une app « cloud » qui permet de faire des maquettes rapidement (demandez pour y avoir accès). N'ont pu bosser que 2h dessus, car E. est très occupée. Espèrent un peu sortir le site pour le 1er avril, mais pas sûr que ça soit nécessaire. Q. veut bien essayer de le faire, incrémentalement. E. viendra seulement retravailler les schémas.
|
||||
|
||||
M. dit qu'on a pas besoin d'un nouveau site pour le 1er avril, mais que le site n'a pas de version anglaise. Peut-être que ça vaudrait le coup d'essayer d'avoir une version anglaise, sur deuxfleurs.org peut-être ? Mauvais pour le référencement mais bon.
|
||||
|
||||
**Conclusion** : pas essayer à produire un résultat pour le 1er avril, mais réfléchir à l'internationalisation.
|
||||
|
||||
### Retour sur Garage
|
||||
|
||||
explication : brique qui n'est pas directement visible par les utilisateurs, mais qui nous sert (dans l'infrastructure) à stocker les données des services de façon résiliente. Possibilité d'héberger les medias de zinz.dev sur Garage.
|
||||
|
||||
*Discuter l'aspect multi-tenant ?* -> À faire plus tard. Pour le moment tout noeud qui stocke des données sur garage a les pleins pouvoirs. Avoir des quotas de bande passante, stockage, buckets...
|
||||
|
||||
Notez vos idées pour Garage dans les issues du dépôt Gitea !
|
||||
|
||||
Déviation sur les différents jobs dont les membres ont entendu parler. Eh oui, chez Deuxfleurs on est aussi chasseurs de têtes - nos propres têtes !
|
||||
|
||||
### Boîte à idées
|
||||
|
||||
* V. : essayer d'humaniser l'équipe derrière Deuxfleurs. E. proposait des portraits avec fleurs en avant-plan pour garder l'anonymat : encarts sur le site pour les personnes qui le veulent.
|
||||
|
||||
Réfléxion d'Al. : n'aime pas trop l'aspect trombinoscope / service de renseignements.
|
||||
|
||||
Q. aurait préféré une belle photo de groupe, mais c'est pas pour demain. D'ailleurs on habite vachement loin les uns des autres.
|
||||
|
||||
* Q. : dans 3-5ans+, héberger les serveurs dans des tiers-lieux, type hackerspace, où on signerait un partenariat. Faciliterait l'accès par divers membres.
|
||||
|
||||
* Garage-party : déployer des instances de Garage ensemble.
|
||||
|
||||
V. cherche et galère à trouver des ordis de seconde main. Il y a une pénurie de composants informatiques dûe à la crise sanitaire, qui se répercute sur le marché de l'occasion. M. a du matos qui dort chez lui.
|
||||
|
||||
### Infrastructure
|
||||
|
||||
* Les serveurs principaux sont susceptibles d'être déplacés dans les deux semaines car Q. déménage. Ils partiraient chez son frère, avec une bonne fibre.
|
||||
|
||||
* CryptPad mis à jour en v4.2.1 ! Résout un bug et bannit les utilisateurs Chrome (à fix - ooooof, nous ça nous convenait !).
|
||||
|
||||
* Synapse(s) à jour
|
||||
|
||||
* Gitea & Drone pas contents - à migrer sur le kimsufi d'A. ?
|
||||
|
||||
* Ping-pong avec M. si besoin un soir pour avancer sur l'install
|
||||
* Voir ce que l'on peut réutiliser dans le repo infra (common, docker, utilisateurs)
|
||||
* Refaire un repo infra à côté ou bien faire un seul repo? -> Intérêt à mettre mon infra sur le repo de Deuxfleurs = les autres peuvent voir et évaluer mes process. Chemin de migration.
|
||||
|
||||
* Métrologie
|
||||
|
||||
* on a des bonnes métriques
|
||||
* et même les métriques des serveurs maintenant (via le node-exporter)
|
||||
* mettre le grafana sur le LDAP
|
||||
* récupérer les métriques de IO et de HAMMERHEAD sur le Grafana du cluster.
|
||||
|
||||
* Alerting ?
|
||||
|
||||
* prom-alert-manager
|
||||
|
||||
* disque
|
||||
* RAM
|
||||
* latence
|
||||
|
||||
* chan #tech de matrix ?
|
||||
|
||||
* avec un bot ?
|
||||
* https://github.com/turt2live/matrix-appservice-webhooks <- avec un wrapper webhook vers bot
|
||||
|
||||
* Alertes de dispo - à envoyer sur des adresses mail non-deuxfleurs, et sans spam
|
||||
|
||||
---
|
||||
|
||||
Dormez bien !
|
||||
|
|
@ -1,122 +0,0 @@
|
|||
### Article 1. Constitution et dénomination
|
||||
|
||||
Il est fondé entre les adhérents aux présents statuts une association
|
||||
régie par la loi 1901, ayant pour titre Deuxfleurs.
|
||||
|
||||
### Article 2. Buts
|
||||
|
||||
Cette association a pour but de défendre et promouvoir les libertés
|
||||
individuelles et collectives à travers la mise en place d'infrastuctures
|
||||
numériques libres.
|
||||
|
||||
### Article 3. Siège social
|
||||
|
||||
Le siège social est fixé au 10A, Allée de Lanvaux, 35700 Rennes. Il
|
||||
pourra être transféré suite à un vote par l'assemblée générale.
|
||||
|
||||
### Article 4. Durée de l'association
|
||||
|
||||
L'association perdure tant qu'elle possède au moins un membre, ou
|
||||
jusqu'à sa dissolution décidée en assemblée générale.
|
||||
|
||||
### Article 5. Admission et adhésion
|
||||
|
||||
Pour faire partie de l'association, il faut être coopté par un membre de
|
||||
l'association, adhérer aux présents statuts et s'acquitter de la
|
||||
cotisation annuelle dont le montant est de 10 euros.
|
||||
|
||||
### Article 6. Composition de l'association
|
||||
|
||||
L'association se compose exclusivement de membres admis selon les dispositions
|
||||
de l'Article 5 et à jour de leur cotisation. Tout membre
|
||||
actif possède une voix lors des votes en assemblée générale. Est considéré
|
||||
actif tout membre présent à l'assemblée générale (physiquement, par
|
||||
visioconférence ou par procuration écrite donnée à un autre membre de
|
||||
l'association).
|
||||
|
||||
### Article 7. Perte de la qualité de membre
|
||||
|
||||
La qualité de membre se perd par :
|
||||
|
||||
- la démission,
|
||||
- le non-renouvelement de la cotisation dans un délai de deux mois
|
||||
après le 1er Janvier de l'année courante,
|
||||
- le décès,
|
||||
- la radiation prononcée aux deux tiers des votes exprimés, lors d'un
|
||||
vote extraordinaire ou de l'assemblée générale.
|
||||
|
||||
### Article 8. L'assemblée générale
|
||||
|
||||
L'assemblée générale ordinaire se réunit au moins une fois par an, convoquée
|
||||
par le conseil d'administration. L'assemblée générale extraordinaire est
|
||||
convoquée par le conseil d'administration, à la demande de celui-ci ou à la
|
||||
demande du quart au moins des membres de l'association.
|
||||
|
||||
L'assemblée générale (ordinaire ou extraordinaire) comprend tous les
|
||||
membres de l'association à jour de leur cotisation. Quinze jours au
|
||||
moins avant la date fixée, les membres de l'association sont convoqués
|
||||
via la liste de diffusion de l'association et l'ordre du jour est
|
||||
inscrit sur les convocations.
|
||||
|
||||
Le conseil d'administration anime l'assemblée générale. L'assemblée
|
||||
générale, après avoir délibéré, se prononce sur le rapport moral et/ou
|
||||
d'activités. Le conseil d'administration rend compte de l'exercice
|
||||
financier clos et soumet le bilan de l'exercice clos à l'approbation de
|
||||
l'assemblée dans un délai de six mois après la clôture des comptes.
|
||||
L'assemblée générale délibère sur les orientations à venir et se
|
||||
prononce sur le budget prévisionnel de l'année en cours.
|
||||
|
||||
Elle pourvoit, au scrutin secret, à la nomination ou au renouvellement
|
||||
des membres du conseil d'administration via un scrutin de Condorcet
|
||||
Randomisé. Elle fixe le montant de la cotisation annuelle. Les décisions
|
||||
de l'assemblée sont prises à la majorité des membres présents ou
|
||||
représentés. Chaque membre présent ne peut détenir plus d'une
|
||||
procuration.
|
||||
|
||||
### Article 9. Membres mineurs
|
||||
|
||||
Les mineurs peuvent adhérer à l'association sous réserve d'un accord
|
||||
tacite ou d'une autorisation écrite de leurs parents ou tuteurs légaux.
|
||||
Ils sont membres à part entière de l'association. Seuls les membres âgés
|
||||
de 16 ans au moins au jour d'une élection sont autorisés à y voter,
|
||||
notamment au cours d'une assemblée générale. Pour les autres, leur droit
|
||||
de vote est transmis à leur représentant légal.
|
||||
|
||||
### Article 10. Le conseil d'administration
|
||||
|
||||
L'association est administrée par un conseil d'administration composé de
|
||||
3 à 6 membres, élus pour 1 an dans les conditions fixées à
|
||||
l'Article 8. Tous les membres de l'association à jour de
|
||||
leur cotisation sont éligibles. En cas de vacance de poste, le conseil
|
||||
d'administration peut pourvoir provisoirement au remplacement de ses
|
||||
membres. Ce remplacement est obligatoire quand le conseil
|
||||
d'administration compte moins de 3 membres. Il est procédé à leur
|
||||
remplacement définitif à la plus prochaine assemblée générale. Les
|
||||
pouvoirs des membres ainsi élus prennent fin à l'époque où devrait
|
||||
normalement expirer le mandat des membres remplacés.
|
||||
|
||||
Le conseil d'administration met en œuvre les décisions de l'assemblée
|
||||
générale, organise et anime la vie de l'association, dans le cadre fixé
|
||||
par les statuts. Chacun de ses membres peut être habilité par le conseil
|
||||
à remplir toutes les formalités de déclaration et de publication
|
||||
prescrites par la législation et tout autre acte nécessaire au
|
||||
fonctionnement de l'association et décidé par le conseil
|
||||
d'administration. Tous les membres du conseil d'administration sont
|
||||
responsables des engagements contractés par l'association. Tout contrat
|
||||
ou convention passé entre l'association d'une part, et un membre du
|
||||
conseil d'administration, son conjoint ou un proche, d'autre part, est
|
||||
soumis pour autorisation au conseil d'administration et présenté pour
|
||||
information à la plus prochaine assemblée générale. Le conseil
|
||||
d'administration se réunit au moins 4 fois par an et toutes les fois
|
||||
qu'il est convoqué par le tiers de ses membres. La présence de la moitié
|
||||
au moins des membres du conseil est nécessaire pour que le conseil
|
||||
d'administration puisse délibérer valablement. Les décisions sont prises
|
||||
au consensus et, à défaut, à la majorité des voix des présents. Le vote
|
||||
par procuration n'est pas autorisé.
|
||||
|
||||
### Article 11. Modification des statuts de l'association
|
||||
|
||||
Sur demande d'un tiers des membres actifs, ou sur demande du conseil
|
||||
d'administration, des amendements aux statuts de l'association peuvent
|
||||
être discutés et soumis au vote lors d'une assemblée générale, selon les
|
||||
modalités de l'Article 8.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 141 KiB |
|
|
@ -1,51 +0,0 @@
|
|||
### Notre raison d'être
|
||||
|
||||
Aujourd'hui, de grandes entreprises conçoivent des services numériques qui ont
|
||||
pour objectif de
|
||||
<a href="https://fr.wikipedia.org/wiki/%C3%89conomie_de_l%27attention">maximiser le temps</a>
|
||||
que nous passons dessus, de
|
||||
<a href="https://fr.wikipedia.org/wiki/%C3%89conomie_de_la_surveillance">collecter et recouper des données</a>
|
||||
à notre insu pour nous influencer, de
|
||||
<a href="https://www.april.org/le-parlement-europeen-valide-la-generalisation-de-la-censure-automatisee">limiter nos possibilités d'expression</a>
|
||||
au-delà du cadre légal et de
|
||||
<a href="https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish">créer de nouveaux monopoles</a>.
|
||||
Ces effets nous montrent que la technologie n'est pas
|
||||
neutre et a un réel impact sur nos vies. En choisissant et en hébergeant nos
|
||||
propres outils de communication, sans but lucratif ni hégémonique, nous
|
||||
espérons nous affranchir de ces nuisances et préserver nos libertés.
|
||||
|
||||
Pour en savoir plus, rendez-vous sur
|
||||
<a href="https://www.laquadrature.net/">La Quadrature du Net</a>
|
||||
et allez lire le manifeste <a href="https://chatons.org/fr/manifeste">des CHATONS</a>.
|
||||
|
||||
### Nos objectifs
|
||||
|
||||
#### Des utilisateurs impliqués
|
||||
|
||||
Que ce soit à l'école, par l'expérimentation, via un forum d'échange, lors d'un
|
||||
atelier, via une publicité à la télévision, un tutoriel, lors d'une discussion
|
||||
avec un ami, il y a toujours une phase d'apprentissage en informatique.
|
||||
Malheureusement, dans ces conditions, dur de lutter pour des services libres
|
||||
face à la puissance de frappe d'une entreprise et des logiciels ayant une base
|
||||
d'utilisateurs immense. Nous pensons donc qu'une personne souhaitant s'héberger
|
||||
chez un hébergeur indépendant a besoin d'un accompagnement. C'est pourquoi les
|
||||
inscriptions se font par cooptation. La cooptation permet aussi un lien de
|
||||
confiance et ainsi de se prémunir de bon nombres d'attaques que subissent les
|
||||
hébergeurs.
|
||||
|
||||
#### Une architecture résiliente
|
||||
|
||||
Les sites webs, les réseaux sociaux, les emails ne peuvent fonctionner que
|
||||
grâce à des ordinateurs qui restent allumés 24/24h et qui n'attendent que vous.
|
||||
Cependant, ces derniers sont faillibles. Une coupure d'électricité, un disque
|
||||
dur cassé, une mise à jour ratée, un bug dans le logiciel, les raisons ne
|
||||
manquent pas. Heureusement, il est possible de masquer ces pannes avec du
|
||||
logiciel astucieusement conçu. C'est pourquoi vous avez l'impression que Google
|
||||
est toujours disponible, que Dropbox ne perd pas vos données, etc. La gestion
|
||||
de ces pannes, c'est aussi ce qui rend la vie compliquée aux hébergeurs
|
||||
indépendants. Entre incompréhension des utilisateurs quand un service est hors
|
||||
ligne et sueurs froides pour les administrateurs, ça n'a rien de marrant. Et
|
||||
c'est très chronophage. Notre objectif est donc de construire des solutions
|
||||
d'hébergements qui peuvent résister à ces pannes.
|
||||
|
||||
<p class="center"><a href="/Technique/">En savoir plus sur l'aspect technique</a></p>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 491 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 565 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1013 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 116 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 523 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 392 KiB |
|
|
@ -1,23 +0,0 @@
|
|||
extends ../_layout.pug
|
||||
|
||||
prepend root
|
||||
- title = "Discussions"
|
||||
|
||||
|
||||
block content
|
||||
h2 Discussions
|
||||
|
||||
section
|
||||
a.service-box.left(href='https://riot.deuxfleurs.fr')
|
||||
div(style='font-size: 80px; height: 120px') 🌐
|
||||
h5 Accéder via le navigateur
|
||||
a.service-box.left(href='https://play.google.com/store/apps/details?id=im.vector.app&hl=fr')
|
||||
div(style='font-size: 80px; height: 120px') 📥
|
||||
h5 Application Android
|
||||
a.service-box.left(href='https://apps.apple.com/fr/app/riot-im/id1083446067')
|
||||
div(style='font-size: 80px; height: 120px') 📥
|
||||
h5 Application iOS
|
||||
|
||||
h2 Guide d'utilisation sur ordinateur
|
||||
|
||||
p Adrien a écrit un <a href="https://zinz.dev">guide d'installation/utilisation du résau Matrix</a> qui devrait vous aider à vous lancer. À l'inscription, remplacez <code>zinz.dev</code> par <code>im.deuxfleurs.fr</code> si vous souhaitez vous inscrire sur le serveur de l'asso.
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
# Emails
|
||||
|
||||
<section>
|
||||
<a class="service-box left" href='https://sogo.deuxfleurs.fr'>
|
||||
<div style='font-size: 80px; height: 120px'> 🌐</div>
|
||||
<h5> Accéder via le navigateur</h5>
|
||||
</a>
|
||||
<a class="service-box left" href='https://www.thunderbird.net/fr/'>
|
||||
<div style='font-size: 80px; height: 120px'> 📥</div>
|
||||
<h5> Thunderbird (PC/Mac)</h5>
|
||||
</a>
|
||||
<a class="service-box left" href='https://k9mail.app/'>
|
||||
<div style='font-size: 80px; height: 120px'> 📥</div>
|
||||
<h5> K9 (Android)</h5>
|
||||
</a>
|
||||
</section>
|
||||
|
||||
|
||||
## Configurer ses emails dans une application
|
||||
|
||||
| Protocole | Rôle | Hôte | Port | Chiffrement | Authentification | Certificat |
|
||||
| -- | -- | -- | -- | -- | -- | -- |
|
||||
| IMAP | Réception des emails | `imap.deuxfleurs.fr` | `993` | SSL/TLS | email+mdp | invalide |
|
||||
| SMTP | Envoi des emails | `smtp.deuxfleurs.fr` | `465` | SSL/TLS | email+mdp | invalide |
|
||||
| Exchange ActiveSync | Tous | `https://sogo.deuxfleurs.fr` | `443` | SSL/TLS | email+mdp | valide |
|
||||
|
||||
Vous êtes intéressés par le support de JMAP ? Venez-nous en parler.
|
||||
|
||||
## Utiliser un nom de domaine personnalisé (autre que @deuxfleurs.fr)
|
||||
|
||||
1. Demandez à un administrateur de préconfigurer votre nom de domaine :
|
||||
1. Communiquez lui votre nom de domaine pour qu'il l'ajoute dans `ou=domains,ou=groups,dc=deuxfleurs,dc=fr`
|
||||
2. Communiquez lui l'adresse email que vous souhaitez pour qu'il change l'entrée `mail` dans votre profil utilisateur
|
||||
3. Si vous souhaitez avoir une boite mais plusieurs alias, demandez un champs `uid` dans votre profil utilisateur
|
||||
|
||||
2. Vous devez ensuite rajouter les entrées pour votre nom de domaine en éditant votre zone :
|
||||
1. L'entrée MX pour recevoir les emails
|
||||
```bind
|
||||
@ MX 10 email-in.deuxfleurs.fr
|
||||
```
|
||||
2. L'entrée SPF pour autoriser notre IP à délivrer des emails en votre nom :
|
||||
```bind
|
||||
@ TXT "v=spf1 mx:out.deuxfleurs.fr -all"
|
||||
```
|
||||
3. L'entrée DKIM pour autoriser notre postfix+opendkim à délivrer des emails en votre nom :
|
||||
```
|
||||
smtp._domainkey TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdZp4qrgZR+6R7HeAkuLGJ/3L/6Ungvf5zwrMq6T8Tu931j2G4lYuPtsxyn9fZkT4y7DlX0waktLDBOCwf7X78nLEWjAFWiJTeWGRGhRdYRUFpscs9NUN0P+46jKlabibG3XTKd1DeAmywTu6o1oO03yiolrgKD1zgyDRFeUTfSwZIdPrdbcBSA1arda4WFtcBIrSygM9b4jtlqfQwGDrsMLbCBfVHDn4WfmDWyNg0gDAkuLrYClNETk6aqIyj9fC8srKri0Qp3cRagCn+fjBvuxP35qWWJH7Rnnh/tuEDr1ufuNYO2KgJZ7JdMidUotxXE8cfU+OrEWQf4mIYeJ4wIDAQAB"
|
||||
```
|
||||
4. L'entrée DMARC pour indiquer le comportement à adopter si les contraintes précédentes ne sont pas satisfaites :
|
||||
```
|
||||
_dmarc TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:contact@deuxfleurs.fr!10m; ruf=mailto:contact@deuxfleurs.fr!10m; rf=afrf; pct=100; ri=86400"
|
||||
```
|
||||
3. C'est tout ! Vous devrez probablement attendre 24/48h que les changements se propagent.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
# Hébergement de sites web
|
||||
|
||||
Vous en avez marre de faire toute votre communication associative via Facebook ? Vous voulez créer votre propre site pour raconter votre dernier road-trip ou publier vos poèmes ? Vous ne savez pas vous y prendre ? Deuxfleurs est là pour vous !
|
||||
|
||||
Nous vous prodiguerons conseil, guidance, et hébergement pour que vos plus belles lignes soient disponibles en ligne dans les meilleures conditions. **Vous n'avez qu'à nous contacter à coucou<img class="simple" src="/img/arobase.png" height="15"/>deuxfleurs.fr**.
|
||||
|
||||
## Plus en détail
|
||||
|
||||
Nous avons de l'expérience en hébergement de sites fonctionnant avec [Wordpress](https://fr.wordpress.org/). C'est un système de gestion de contenu ([CMS](https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_contenu) en anglais) qui permet de construire et d'administrer un site Internet *facilement et sans connaissances préalables*. Si Wordpress ne vous convient pas, on peut trouver ensemble une autre solution adaptée à vos besoins et envies.
|
||||
|
||||
Nous assurons aussi la gestion de **sauvegardes de données** : en hébergeant vos données chez nous, vous avez la certitude de ne pas tout perdre en cas de pépin (tel que le décès prématuré d'un disque dur).
|
||||
|
||||
## En conclusion
|
||||
|
||||
Venez chez nous ! On vous fera un havre numérique aux petits oignons. Aider Internet à retrouver sa diversité d'antan, c'est important pour nous. On veut voir des blogs en pagaille, des réseaux sociaux délaissés, des thèmes loufoques et la mort de l'uniformisation graphique.
|
||||
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
extends ../_layout.pug
|
||||
|
||||
prepend root
|
||||
- title = "Visioconférence"
|
||||
|
||||
|
||||
block content
|
||||
h2 Visioconférence
|
||||
|
||||
section
|
||||
a.service-box.left(href='https://jitsi.deuxfleurs.fr')
|
||||
div(style='font-size: 80px; height: 120px') 🌐
|
||||
h5 Accéder via le navigateur
|
||||
a.service-box.left(href='https://play.google.com/store/apps/details?id=org.jitsi.meet&hl=fr')
|
||||
div(style='font-size: 80px; height: 120px') 📥
|
||||
h5 Application Android
|
||||
a.service-box.left(href='https://apps.apple.com/fr/app/jitsi-meet/id1165103905')
|
||||
div(style='font-size: 80px; height: 120px') 📥
|
||||
h5 Application iOS
|
||||
|
||||
h3.spacing Bien s'entendre pendant la réunion
|
||||
|
||||
p "Tu m'entends ? Non pas très bien ! Qu'est ce que tu viens de dire ?" : quelques conseils pour bien s'entendre pour éviter ça et passer un bon moment.
|
||||
|
||||
p
|
||||
strong Améliorez le son :
|
||||
|
|
||||
| l'idéal est d'avoir un casque avec microphone ou des écouteurs avec microphone pour capter le son au plus près de votre bouche et empêcher l'écho (que votre microphone capte ce qui sort sur les hauts parleurs). Si vous n'avez pas de casques ou d'écouteurs ou que vous êtes plusieurs, les ordinateurs portables récents captent mieux le son que les anciens, et généralement votre téléphone captera mieux le son que votre ordinateur. De plus, si vous êtes plusieurs, vous devez savoir que les microphones sont directifs : si vous êtes proches et bien en face de l'ordinateur, on vous entendra bien, sinon on ne vous entendra pas du tout ! En groupe, tournez l'ordinateur vers la personne qui parle ou mettez-vous bien en face pour parler !
|
||||
|
||||
p
|
||||
strong Améliorez votre connexion :
|
||||
|
|
||||
| la visioconférence est très sensible à la qualité de votre connexion internet. Si vous le pouvez, connectez votre ordinateur en filaire (cable ethernet) à votre <em>box</em> (routeur internet). Si vous souhaitez rester en sans-fil (wifi), essayez de vous rapprocher de votre <em>box</em>. Le type de connexion internet influencera également la qualité de votre visioconférence : la fibre est idéale, l'ADSL ou les réseaux mobiles (4G et 3G) sont plus incertains.
|
||||
|
||||
p
|
||||
strong Réduisez vos usages :
|
||||
|
|
||||
| Activer la vidéo peut causer des interruptions ou dégrader la qualité du son. Si vous n'avez pas besoin de la vidéo, désactivez là ou garder là seulement pour certains participants. Si vous ne parlez pas, vous pouvez également couper votre microphone. Il est possible de passer en mode "talkie walkie" sur ordinateur avec la touche espace. Vous maintenez la touche espace, votre micro est activé. Vous arrêtez d'appuyer sur la touche espace, votre micro est coupé.
|
||||
|
||||
p Si vous appliquez ces conseils, vous devriez arriver à communiquer sans peine. Bonnes communications !
|
||||
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
|
@ -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...
|
||||
|
||||
|
||||
|
|
@ -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*
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 158 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.4 KiB |
|
|
@ -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 | 
|
||||
| Freebox Mini 4k | Routeur | x1 | 4 ports @ 1Gbit/s, WAN Fibre 1 Gbit/s symétrique |
|
||||
|
||||
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
|
||||
|
|
@ -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
|
||||
|
|
@ -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".
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
|
|
@ -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 :
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
|
@ -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>`
|
||||
|
||||
|
|
@ -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/).
|
||||
|
|
@ -23,6 +23,13 @@ block root
|
|||
img(src="/img/flower.svg", width="40")
|
||||
|
|
||||
img(src="/img/flower.svg", width="40")
|
||||
ul
|
||||
li
|
||||
a(href="https://plume.deuxfleurs.fr/timeline/1") Actualités
|
||||
li
|
||||
a(href="https://wikijs.deuxfleurs.fr") Wiki
|
||||
li
|
||||
a(href="https://guichet.deuxfleurs.fr") Mon compte
|
||||
+menu(root, element)
|
||||
|
||||
main
|
||||
|
|
|
|||
|
|
@ -10,19 +10,16 @@ block content
|
|||
section
|
||||
h2 # nos services
|
||||
section
|
||||
a.service-box.left(href='/Guide/Discussion.html')
|
||||
a.service-box.left(href='https://wikijs.deuxfleurs.fr/fr/Guide/Discussion')
|
||||
div(style='font-size: 80px; height: 120px') 💬
|
||||
h5 discussion
|
||||
a.service-box.left(href='/Guide/Visioconférence.html')
|
||||
a.service-box.left(href='https://wikijs.deuxfleurs.fr/fr/Guide/Visioconf%C3%A9rence')
|
||||
div(style='font-size: 80px; height: 120px') 📞
|
||||
h5 visioconférence
|
||||
a.service-box.left(href='/Guide/Sites web.html')
|
||||
a.service-box.left(href='https://wikijs.deuxfleurs.fr/fr/Guide/SiteWeb')
|
||||
div(style='font-size: 80px; height: 120px') 🌐
|
||||
h5 sites web
|
||||
a.service-box.left(href='https://cloud.deuxfleurs.fr')
|
||||
div(style='font-size: 80px; height: 120px') 🔒
|
||||
h5 sauvegarde de documents
|
||||
a.service-box.left(href='/Guide/Email.html')
|
||||
a.service-box.left(href='https://wikijs.deuxfleurs.fr/fr/Guide/Email')
|
||||
div(style='font-size: 80px; height: 120px') 📨
|
||||
h5 emails
|
||||
a.service-box.left(href='https://p.adnab.me')
|
||||
|
|
@ -45,19 +42,6 @@ block content
|
|||
h3 ⇨ prendre les décisions ensemble
|
||||
h3 ⇨ mettre en commun nos connaissances et nos infrastructures
|
||||
|
||||
section
|
||||
h2 # nos articles
|
||||
|
||||
article.frame
|
||||
p.right
|
||||
em Par Tom, le 20 avril 2020
|
||||
h4
|
||||
a(href="https://plume.deuxfleurs.fr/~/PiedDeVent/stop-covid-anonymat-et-autorit%C3%A9s") StopCovid : anonymat et autorités
|
||||
p
|
||||
| "StopCovid sera totalement anonyme. L'État ne pourra rien savoir sur vous." Non, c'est FAUX, l'État connaitra votre identité et pourrait vous assigner à résidence sans recours possible. Nous vous expliquons pourquoi en nous basant sur le document technique de l'application.
|
||||
|
|
||||
a(href="https://plume.deuxfleurs.fr/~/PiedDeVent/stop-covid-anonymat-et-autorit%C3%A9s") Lire la suite.
|
||||
|
||||
section
|
||||
h2 # faisons connaissance
|
||||
p.spacing Nous fonctionnons actuellement selon un mode de cooptation qui nous permet d'une part de mieux contrôler l'utilisation des ressources et éviter les abus, et d'autre part de créer et garder un contact humain avec nos utilisateurs.
|
||||
|
|
|
|||
Loading…
Reference in New Issue