|
|
# 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.
Adrien 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.
|
