forked from Deuxfleurs/site
Lint text, remove trailing space, order headers and lists
This commit is contained in:
mricher
parent
99d50325f5
commit
d27f2f837f
GPG Key ID:
CA73C61E72CB3E61
|
|
@ -1,3 +1,5 @@
|
|||
# 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,
|
||||
|
|
@ -12,11 +14,11 @@ 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.
|
||||
- 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.
|
||||
|
|
@ -25,21 +27,21 @@ 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
|
||||
## 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
|
||||
## 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
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## Première réunion de travail
|
||||
## Première réunion de travail
|
||||
|
||||
Date : Février 2020
|
||||
|
||||
|
|
@ -31,9 +31,9 @@ Quentin (anime la réunion) :
|
|||
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)
|
||||
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
|
||||
|
|
@ -45,32 +45,32 @@ Continuer sans ? (mais c'est dans les statuts)
|
|||
|
||||
### 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 ?
|
||||
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.
|
||||
|
||||
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 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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
|
@ -81,14 +81,14 @@ 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 ?
|
||||
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)
|
||||
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
|
||||
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
|
||||
|
|
@ -98,7 +98,7 @@ Trois niveaux :
|
|||
> 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)
|
||||
**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
|
||||
|
|
@ -129,7 +129,7 @@ Quentin : les PV en PDF sont stockés dans un repos
|
|||
Retex de Toms
|
||||
-------------
|
||||
|
||||
Toms est intéressé pour rejoindre l'association.
|
||||
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,4 +1,4 @@
|
|||
## Deuxième réunion de travail
|
||||
## Deuxième réunion de travail
|
||||
|
||||
Date : 10h le samedi 16 mai 2020
|
||||
|
||||
|
|
@ -14,10 +14,10 @@ Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
|||
- éthiques:
|
||||
- protection vie privée:
|
||||
- on ne partage pas - dans les limites de la loi - ce que vous voulez garder pour vous
|
||||
- on utilise le plus possible la cryptographie de bout en bout (e2ee) (*expliquer pourquoi c'est mieux que la confiance*)
|
||||
- on utilise le plus possible la cryptographie de bout en bout (e2ee) (*expliquer pourquoi c'est mieux que la confiance*)
|
||||
- protection libertés:
|
||||
- on ne censure pas - dans les limites de la loi - ce que vous voulez partager
|
||||
- ne vous manipule pas
|
||||
- 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
|
||||
|
|
@ -26,15 +26,15 @@ Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
|||
- 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.
|
||||
- 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
|
||||
- mettre en commun les infrastructures
|
||||
- backups chez Maximilien
|
||||
- git chez Adrien
|
||||
- matrix chez Quentin
|
||||
|
|
@ -43,7 +43,7 @@ Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
|||
- Temps de discussion avec les nouveaux / invités
|
||||
- Debrief des deux mois
|
||||
- Déploiement du site web
|
||||
- Déploiement et debug du Jitsi
|
||||
- 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
|
||||
|
|
@ -60,7 +60,7 @@ Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
|||
- 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
|
||||
- Le site web
|
||||
- Problèmes :
|
||||
- UI pas responsive (ça reste lisible néanmoins)
|
||||
- Quentin : Problème réglé
|
||||
|
|
@ -73,7 +73,7 @@ Lieu : [jitsi.deuxfleurs.fr/asso](https://jitsi.deuxfleurs.fr/asso)
|
|||
- 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
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -12,13 +12,12 @@ au-delà du cadre légal et de
|
|||
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.
|
||||
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
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ prepend root
|
|||
block content
|
||||
.spacing
|
||||
h2 Accès rapides
|
||||
|
||||
|
||||
section
|
||||
a.service-box.left(href='https://riot.deuxfleurs.fr')
|
||||
div(style='font-size: 80px; height: 120px') 🌐
|
||||
|
|
@ -20,7 +20,7 @@ block content
|
|||
h5 Application iOS
|
||||
|
||||
h2 Premiers pas sur Android
|
||||
|
||||
|
||||
.screenlist
|
||||
img(src="Assets/riot_install4.png", height="400")
|
||||
img(src="Assets/riot_install5.png", height="400")
|
||||
|
|
@ -29,7 +29,7 @@ block content
|
|||
img(src="Assets/riot_connect3.png", height="400")
|
||||
img(src="Assets/riot_connect4.png", height="400")
|
||||
img(src="Assets/riot_connect5.png", height="400")
|
||||
|
||||
|
||||
style.
|
||||
.screenlist > img {
|
||||
padding: 20px;
|
||||
|
|
|
|||
|
|
@ -18,14 +18,14 @@ block content
|
|||
|
||||
|
||||
|
||||
.spacing2
|
||||
.spacing2
|
||||
h2 Guide de préparation d'une réunion
|
||||
|
||||
h3.spacing Étape 1 : Choisissez un nom de réunion (par exemple : "karaté-lyon")
|
||||
h3 Étape 2 : Informez vos participants de la date de votre réunion et du nom de la réunion
|
||||
h3
|
||||
| Étape 3 : Au moment voulu, pour rejoindre la conversation, les participants devront se rendre sur le site
|
||||
|
|
||||
h3
|
||||
| Étape 3 : Au moment voulu, pour rejoindre la conversation, les participants devront se rendre sur le site
|
||||
|
|
||||
a(href="https://deuxfleurs.fr") deuxfleurs.fr
|
||||
h3 Étape 4 : Puis, une fois sur la page d'accueil, cliquer sur le bouton "📞 visioconférence" (pour arriver sur cette page)
|
||||
h3 Étape 5 : Enfin, les participants doivent entrer le nom de la réunion (par exemple : "karaté-lyon") et cliquer sur "rejoindre"
|
||||
|
|
@ -48,10 +48,10 @@ block content
|
|||
|
|
||||
| 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
|
||||
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.
|
||||
| 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 :
|
||||
|
|
@ -72,7 +72,7 @@ block content
|
|||
window.addEventListener('pageshow', e => {
|
||||
joinbtn.text = "rejoindre"
|
||||
})
|
||||
|
||||
|
||||
joinbtn.onclick = _ => {
|
||||
const meetingid = joinname.value
|
||||
if (!meetingid) return // meetingid is empty
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
|
||||
Store pile of bytes in your garage.
|
||||
|
||||
|
||||
## Context
|
||||
|
||||
Data storage is critical: it can lead to data loss if done badly and/or on hardware failure.
|
||||
|
|
@ -11,13 +10,13 @@ Moreover, it put a hard limit on scalability. Often this limit can be pushed bac
|
|||
But here we consider non specialized off the shelf machines that can be as low powered and subject to failures as a raspberry pi.
|
||||
|
||||
Distributed storage may help to solve both availability and scalability problems on these machines.
|
||||
Many solutions were proposed, they can be categorized as block storage, file storage and object storage depending on the abstraction they provide.
|
||||
Many solutions were proposed, they can be categorized as block storage, file storage and object storage depending on the abstraction they provide.
|
||||
|
||||
## Related work
|
||||
|
||||
Block storage is the most low level one, it's like exposing your raw hard drive over the network.
|
||||
It requires very low latencies and stable network, that are often dedicated.
|
||||
However it provides disk devices that can be manipulated by the operating system with the less constraints: it can be partitioned with any filesystem, meaning that it supports even the most exotic features.
|
||||
Block storage is the most low level one, it's like exposing your raw hard drive over the network.
|
||||
It requires very low latencies and stable network, that are often dedicated.
|
||||
However it provides disk devices that can be manipulated by the operating system with the less constraints: it can be partitioned with any filesystem, meaning that it supports even the most exotic features.
|
||||
We can cite [iSCSI](https://en.wikipedia.org/wiki/ISCSI) or [Fibre Channel](https://en.wikipedia.org/wiki/Fibre_Channel).
|
||||
Openstack Cinder proxy previous solution to provide an uniform API.
|
||||
|
||||
|
|
@ -28,7 +27,7 @@ We can also mention CephFS (read [RADOS](https://ceph.com/wp-content/uploads/201
|
|||
OpenStack Manila proxy previous solutions to provide an uniform API.
|
||||
|
||||
Finally object storages provide the highest level abstraction.
|
||||
They are the testimony that the POSIX filesystem API is not adapted to distributed filesystems.
|
||||
They are the testimony that the POSIX filesystem API is not adapted to distributed filesystems.
|
||||
Especially, the strong concistency has been dropped in favor of eventual consistency which is way more convenient and powerful in presence of high latencies and unreliability.
|
||||
We often read about S3 that pioneered the concept that it's a filesystem for the WAN.
|
||||
Applications must be adapted to work for the desired object storage service.
|
||||
|
|
@ -43,7 +42,6 @@ There was many attempts in research too. I am only thinking to [LBFS](https://pd
|
|||
- Cassandra (ScyllaDB) for metadata
|
||||
- Own system using consistent hashing for data chunks
|
||||
|
||||
|
||||
**Quentin:**
|
||||
|
||||
- pas d'erasure coding mais des checksums à côté des fichiers (ou dans les meta données)
|
||||
|
|
@ -67,14 +65,9 @@ _Remark 2_ Seafile idea has been stolen from this article: https://pdos.csail.mi
|
|||
|
||||
### Questions à résoudre
|
||||
|
||||
|
||||
1. est-ce que cassandra support de mettre certaines tables sur un SSD et d'autres sur un disque rotatif ?
|
||||
2. est-ce que cassandra/scylladb a un format de table on disk qui ne s'écroule pas complètement losque tu as des gros blobs ? (les devs de sqlite ont écrit tout un article pour dire que même avec leur lib qui est quand même sacrément optimisés, ils considèrent qu'à partir de je crois 4ko c'est plus efficace de mettre les blobs dans des fichiers séparés) - https://www.sqlite.org/intern-v-extern-blob.html
|
||||
3. Quelle taille de blocs ? L'idée c'est qu'on a quand même des liens en WAN avec des débits pas forcéments incroyables. Et ça serait bien que le temps de répliquer un bloc soit de l'ordre de la seconde maxi. En cas de retry, pour pouvoir mieux monitorer la progression, etc. Exoscale utilise 16Mo. LX propose 1Mo.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Quelle taille de blocs ? L'idée c'est qu'on a quand même des liens en WAN avec des débits pas forcéments incroyables. Et ça serait bien que le temps de répliquer un bloc soit de l'ordre de la seconde maxi. En cas de retry, pour pouvoir mieux monitorer la progression, etc. Exoscale utilise 16Mo. LX propose 1Mo.
|
||||
|
||||
#### Modules
|
||||
|
||||
|
|
@ -85,7 +78,6 @@ _Remark 2_ Seafile idea has been stolen from this article: https://pdos.csail.mi
|
|||
- `api/`: S3 API
|
||||
- `web/`: web management interface
|
||||
|
||||
|
||||
#### Metadata tables
|
||||
|
||||
**Objects:**
|
||||
|
|
@ -133,7 +125,6 @@ Workflow for PUT:
|
|||
6. Return success to the user
|
||||
7. Launch a background job to check and delete older versions
|
||||
|
||||
|
||||
Workflow for DELETE:
|
||||
|
||||
1. Check write permission (LDAP)
|
||||
|
|
@ -148,12 +139,10 @@ To delete a version:
|
|||
3. Delete all of the blocks from the blocks table
|
||||
4. Finally, delete the version from the objects table
|
||||
|
||||
|
||||
Known issue: if someone is reading from a version that we want to delete and the object is big, the read might be interrupted. I think it is ok to leave it like this, we just cut the connection if data disappears during a read.
|
||||
|
||||
("Soit P un problème, on s'en fout est une solution à ce problème")
|
||||
|
||||
|
||||
#### Block storage on disk
|
||||
|
||||
**Blocks themselves:**
|
||||
|
|
@ -161,7 +150,7 @@ Known issue: if someone is reading from a version that we want to delete and the
|
|||
- file path = /blobs/(first 3 hex digits of hash)/(rest of hash)
|
||||
|
||||
**Reverse index for GC & other block-level metadata:**
|
||||
|
||||
|
||||
- file path = /meta/(first 3 hex digits of hash)/(rest of hash)
|
||||
- map block hash -> set of version UUIDs where it is referenced
|
||||
|
||||
|
|
@ -194,7 +183,6 @@ Rebalancing: takes as argument the list of newly added nodes.
|
|||
|
||||
Only one balancing can be running at a same time. It can be restarted at the beginning with new parameters.
|
||||
|
||||
|
||||
#### Membership management
|
||||
|
||||
Two sets of nodes:
|
||||
|
|
@ -231,11 +219,9 @@ Number K of tokens per node: decided by the operator & stored in the operator's
|
|||
- Ping interval: 10 seconds
|
||||
- ??
|
||||
|
||||
|
||||
#### Links
|
||||
|
||||
- CDC: <https://www.usenix.org/system/files/conference/atc16/atc16-paper-xia.pdf>
|
||||
- Erasure coding: <http://web.eecs.utk.edu/~jplank/plank/papers/CS-08-627.html>
|
||||
- [Openstack Storage Concepts](https://docs.openstack.org/arch-design/design-storage/design-storage-concepts.html)
|
||||
- [RADOS](https://ceph.com/wp-content/uploads/2016/08/weil-rados-pdsw07.pdf)
|
||||
|
||||
- CDC: <https://www.usenix.org/system/files/conference/atc16/atc16-paper-xia.pdf>
|
||||
- Erasure coding: <http://web.eecs.utk.edu/~jplank/plank/papers/CS-08-627.html>
|
||||
- [Openstack Storage Concepts](https://docs.openstack.org/arch-design/design-storage/design-storage-concepts.html)
|
||||
- [RADOS](https://ceph.com/wp-content/uploads/2016/08/weil-rados-pdsw07.pdf)
|
||||
|
|
|
|||
|
|
@ -30,38 +30,38 @@ Exemple : Ora/Viti en Polynésie française
|
|||
|
||||
FAI connus pour ne pas proposer d'IPv6 :
|
||||
|
||||
* SFR/FTTH
|
||||
* SFR/FTTH
|
||||
|
||||
#### IPv6 de mauvaisee qualité
|
||||
|
||||
*Ajouté explications à propos du tunneling*
|
||||
*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)
|
||||
* 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/\*
|
||||
* 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)
|
||||
* 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
|
||||
|
||||
|
|
@ -75,15 +75,14 @@ Vous avez besoin du NAT hairpinning pour accéder aux services publics que vous
|
|||
|
||||
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
|
||||
* 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*
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
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
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ Ce n'est pas (trop) problématique, car le réseau interne n'est pas (supposé)
|
|||
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.
|
||||
* 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
|
||||
|
||||
|
|
@ -32,20 +32,20 @@ C'est particulièrement critique si on commence à faire du transfert de donnée
|
|||
|
||||
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
|
||||
- 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é
|
||||
- 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
|
||||
- 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 :
|
||||
|
||||
|
|
@ -71,13 +71,12 @@ On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le fi
|
|||
|
||||
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.
|
||||
|
|
@ -99,7 +98,7 @@ Solutions possibles: Wireguard/[Wesher](https://github.com/costela/wesher), `tin
|
|||
|
||||
### 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.
|
||||
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:**
|
||||
|
||||
|
|
|
|||
|
|
@ -13,16 +13,16 @@ Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de gr
|
|||
|
||||
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.
|
||||
- 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
|
||||
1. Mener nos propres tests
|
||||
2. Chercher d'autres retours
|
||||
|
||||
#### Mener nos propres tests
|
||||
|
||||
|
|
@ -31,9 +31,9 @@ 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)
|
||||
- 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 :
|
||||
|
||||
|
|
@ -69,8 +69,8 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr
|
|||
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
|
||||
- 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
|
||||
|
||||
|
|
@ -81,13 +81,13 @@ On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-intern
|
|||
|
||||
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.
|
||||
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`
|
||||
- `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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue