Petits cheminement pour le groupe autour des outils numériques.

https://hentou.cc/

Hypothèses, qu'a t'on?

Structures participantes/utilisatrices

se rendre compte de l'existant et du possible

• fibre?
• serveurs locaux?
• nombre d'utilisateurs? en détaille, répartition etc
• présence d'une personne ressource possible par groupe
• type de données, dimensionnement des ressources nécessaires
• données particulières, GIS,météo,… locales
• matériels en tout genre

Services localisés et partageables à l'extérieur

• données textes,images,photos , vidéo? et autres sites 'Internet' intranet
• agendas
• outils compta,économique et financier
• autres spécifiques (radio,carto,capteurs,…)
• matériels en tout genre

Services plutot extérieurs

• messagerie, mail
• discussions, chats,forums
• réseaux sociaux
• organisationnels (formulaire,mobilizon,financiers)

Ce qui définit nos buts. L'usage d'outils ici informatiques étant la conséquence de besoins, nous partons de l'idée que l'approche informatique est la solution adoptée…On a pas besoin dans un sens de Nextcloud mais des fonctions de stocker ou partager des fichiers. Ce qui place les buts réels comme ceux d'une problématique sous-jacente dont on ne parle pas ici (pourquoi stocker localement?).
Ainsi les outils informatiques semblent/sont ici nécessaires,cela pose un cadre et a des conséquences:

• résilience des connaissances, des données
  • solidité, résister aux pannes d'accès, pannes de serveurs ou de coupure Internet, aux pertes de données, aux usages inconnues.
  • reproductibilité, pouvoir maintenir, sauvegarder et refaire l'infrastructure matérielle et logicielle soi même, localement (à vélo)
  • ⇒vers l'usage de ressources locales, machines et réseaux à domicile ou à porté
• résilience des savoirs faire
  • pouvoir apprendre et enseigner le fonctionnement et la fabrication des infrastructures (LL + doc)
  • pouvoir expérimenter, sans dommage, infrastructures et structures, tant matérielles que logicielles pour construire ensemble notre/son propre futur
  • prévoir un partage des savoirs à plus de un: il ne faut jamais être indispensable.
  • ⇒ vers le regroupement des usagers et le partage des connaissances
• indépendance, impacte écologique
  • tendre vers le moindre besoin technicien, moins de matériel, de matière ou d'énergie
  • pouvoir expérimenter un évolution frugale vers une frugalité maximale
• une société d'inter-dépendance et d'échange, qui nous rapproche

* pour la plupart,

• un smartphone? ou pas, non libre, sans possibilité d'évolution
• une connexion internet par une box adsl, 4G, rarement fibre
• connexions à des réseaux sociaux non fédérés et non structurant
• un PC?, des outils non libres, pas de sauvegarde, pas de moyen d'indépendance
• des outils individualisant et financés par sa propre économie
• des outils collectif presque inexistant et peu organisés
• ?des accès à des outils et des données obligeant une consommation non négligeable
• des accès à des outils peu sécurisés
• des accès dépendant de matériels et de services Internet extérieurs.
• des accès sans maitrise économique collective

Si nous prenons du recul sur une organisation d'un point de vue locale, il faut éviter dès le départ de tenter d'adopter les outils dénigrés. Utiliser un data-center éloigné, ses services, ses organisations extérieures qui n'ont pas les même buts que nous ne peut pas nous aider à trouver ou même fabriquer la route que nous cherchons.
Il peut sembler même contre-productif de prôner l'apprentissage et l'utilisation d'un service qui va aliéner ceux que nous voulons aider et les détourner durablement des buts voir nous aliéner nous même.

Il faut partir de ce que l'on a, de nos savoirs et possibilités pour bâtir des choses que l'on pourra appréhender et suivre nous-même, ne pas miser sur ce qui pourrait nous dépasser. Et emmener au fur et à mesure des groupes autonomes sur le même chemin.
Ne pas se faire adopter par des superstructures qui nous éloignent de l'autonomie et suivent leurs propres buts avec lesquels souvent nous ne sommes pas d'accord. Toujours participer activement aux mouvements communs.

En reprenant nos buts et en respectant toujours ce sens, de ce qu'on a vers ce qu'on veut, nous pouvons tenter de définir une stratégie qui respectera cet ordre. C'est un précepte lowtech!

1 localement

• reprendre la main sur nos propre matériels, PC,smartphone,box,réseaux internes,outils internes
  • en faire un inventaire !
• organiser leur pérennité, la formation à leur construction et usage
  • ou même leur achat , groupements d'achats , SEL
• organiser les groupes par proximité (lieux,intérêts,…)
  • cartographier (pas forcement graphique) pour relier les gens, les possibilités ,…
• se regrouper autour de serveur(s) locaux , chez nous, sur nos réseaux internes
  • définir un début avec au moins deux sites pilotes de taille raisonnable au vue des ressources matérielles accessibles (et donc en fonction des services/logiciels/'requierments') et logiciels, nombre de visites par jour, taille des fichiers échangeables …
  • pour partages fichiers,sauvegardes en commençant par le simple et stable, genre Nextcloud,mail,sites (wiki,wordpress ou trucs du genre visible de l'Internet)
  • communications,organisation,gestions, outils internes en fonction des lieux/groupes/besoins réels
• organiser des parties expérimentales, de recherches, et des parties différentes en production
  • et partie plus légère de com (acces reseaux sociaux)
• organiser leur fonctionnement, usage et formation
• voir tout ceci de façon collective, collectif,collaboratif
  • install-party,GUL,SEL et groupes d'entraides
• économie et budgets nécessaires?
  • forme de prestations à une des structures participante, qui gérera un temps salarié ou autre
  • organisation de cellule, associations autonomes de gestion par groupe/lieux?
  • montage d'une sorte d'AMAP informatique, association d'un CHATON et d'un groupement d'achat

2 fabriquer nos réseaux de territoire
par le maillage de nos ressources et l'usage d'Internet (le réseau des réseaux)

• réseaux informatiques taillés pour une résilience sur le territoire
  • réseaux de com inter-groupe, porter par les meilleurs accès
  • partage/délégation de gestion
• réseaux humain d'entraides, de partage et d'économie autour du matériel et de la formation
• penser et mettre en place les parties communications inter-sites/groupes et les partie communications Internet

3 fabriquer et unir nos réseaux Internet

• cogérer nos moyens
• partager nos solutions et nos expérimentations
• partager les moyens, outils de communications et de gestion
  • pour notre propre développement
  • pour une autonomisation des autres
• s'agréger aux réseaux Internet en phase, réseaux sociaux, partages de données, partage de sécurité

• PUCES
• teste de protocole de communication résilient ,mesh etc
  • https://cwtch.im/
  • https://www.frandroid.com/android/applications/634291_les-trois-meilleures-applications-de-messagerie-sans-internet
    • https://code.briarproject.org/briar/briar
    • https://briarproject.org/
  • https://getsession.org/
• refaire un tour sur FREAK

Sans reprendre les buts exposés ci-dessus, le chemin pris semble être le suivant:
Dans le cadre d'installations expérimentales nous devrions:

1. mettre en place une infrastructure visant à être reproductible de petits serveurs locaux interconnectables, placés dans différentes structures volontaires
   1. devant servir à chaque fois au maximum une dizaine de personne, plus ou moins, localement ou non, en connexion simultanée ou pas
   2. de machines consommant peu (TDP<20W)
   3. économiques, favorisant la récup et l'occasion.
2. mettre en place des réseaux de communications relativement indépendant des fournisseurs d'accès à Internet
   1. supportant l’agrégation (plusieurs ADSL ou ADSL+4G, fibre, autre) afin de faire face aux manques de connectivité sur le territoire
   2. utilisant ses propres DNS
3. bâtir un ensemble de services autour d'une machine hyperviseur et de machines virtuelles afin d'avoir
   1. une facilité de mise en place, de gestion et de sauvegarde
   2. une topologie reproductible (à l'identique?)pour une bonne compréhension
   3. commencer par des services de partage de fichier,agenda (genre Nextcloud ?) et de site internet simple
4. former/accompagner des référant qui pourront suivre le prototype et le reproduire

Partie de préconisations acquises:

1. utiliser des machines sur base Intel/AMD pour des soucis de compatibilité (dans un premier temps), seconde main (i3,GX)
2. commencer par une mise en place sur une simple liaison ADSL (sélectionner FAI) à moins de trouver des lieux fibrés.
   1. aller ensuite vers un couplage ADSL/4G facilement reproductible
   2. puis ensuite évolutions selon l'usage
3. utiliser un outil d'automatisation pour le déploiement (Ansible?) dès le départ

• nous avons une machine
• nous pourrions faire un premier montage soit a Kerminy soit au Konkarlab, soit ?
  • pour Kerminy nous n'avons qu'une 4G
• Yuna guide sur une éventuelle première phase d'installation (matériel,hyperviseur,backup)
• et fournit les préconisations (montage de ce cahier des charges la concernant)
• Yuna accompagne les mises en places avec les recettes qu'elle fourni

• il semble difficile de mobiliser des personnes avec une connaissance technique suffisante pour faire le choix de serveur autonome par site, il faudrait une personne par site ou allonger le temps de réaction et de remise a disposition en cas de problème d’interruption d'un service… de fait des compétences d'administration système plutot GitOps que DevOps voir de base actuelle sont rares! Nous laissons de coté cette idée d'autonomie plus grande car elle ne semble plus possible vu les choix techniques qui ont été fait ces dernières années par les développeurs et les entreprises du numérique.
• il semble aussi difficile de trouver des sites fibrés, ou des structures ayant une conscience de leur possibilité de partage de leur ressource de connexion.

Cela nous amène :

• à penser une solutions intermédiaire dans l'administration des services et des serveurs(ou des machines):
  • si il ne faut pas remettre en question le choix d'une répartition des services au plus près des utilisateurs donc des structures: auto-hébergement de serveurs/services, leur administration ne peut être locale (auto-hébergée). Ainsi nous devons prévoir une administration plus centralisée ne demandant la surveillance que d'une seule personne pour plusieurs sites/structures
  • on abandonnerait ainsi l'idée d'instruire suffisamment les usagers à une autonomie technique totale en collectivisant un peu le savoir/pouvoir technique à certain spécialiste mais qui seraient toujours locaux et collectifs.
  • Mais il faudra inclure la possibilité de rattachement de machine plus autonome (à la Yunohost/Nethserver/proxmox etc) au réseau de communication collectif, pour l'expérimentation ou des services non supportés.
• à avoir besoin d'une architecture qui permette l'administration centralisée mais 'débraillable'/dé-synchronisable
  • ⇒ un serveur maitre (par ex VPS) accessible par tous gérant à distance les serveurs présent dans les structures
  • ⇒ une possibilité de fonctionner pour chacun même avec la perte de la connexion au serveur maitre
• à devoir calculer aussi les coûts d'un équilibre nombres de structures/serveurs autonomes(locaux) (en grappe) et serveur/services centralisés
  • il y a un coût du services VPS de gestion collective et du temps de travail de l'administrateur des systèmes.(puisque localement nous n'avons plus de savoir/pouvoir au sein des structures)
    • un VPS couterait une 100 € par an
  • la nécessité d'utiliser du matériel homogène à le coût de l'achat pour chaque structure: (PC:250€,DD:150, …?)
• le temps d'administration/suivi/formation etc … est a prévoir et sera indispensable!

Cela reviendrait donc plutôt à organiser la possibilité de montage en quelque sorte de CHATONS éclaté (cf https://chatons.org),exploding chatons, qui regrouperait plusieurs structures à chaque fois. CHATONS dont l’administration serait centralisée pour le déploiement et le suivi mais pas pour leur fonctionnement, l'accès à un serveur maitre de gestion peut être rompue et les différents machines des structures fonctionnent en pair à pair. Nous somme sur la mise en réseau de PUCES du CHATON ;)…Cela permet aussi de mutualiser l’administration système, coût/technicité!

Le curseur liberté/pouvoir numérique est toujours difficile à placer.

encore nécessités:

• il ne faut plus qu'une intervention sur une box Internet soit nécessaire: la mise en place d'un petit serveur sur un réseau local doit être transparente, au réseau local et à ses utilisateurs.
  • l'éloignement de l'administration oblige à cette 'facilité'
  • la structure reçoit une boite noire qu'elle branche sur son réseau et c'est tout…
• le routage/nommage (la possibilité d'accès par de simple url) doit être simple à la fois sur le réseau local, l'intranet ou l'Internet
  • d'où la présence de DNS locaux et collectif
• Nous restons toujours dans l'usage de techniques Libres (et opensource)
• Toutes les connexions doivent être chiffrées
• les données restent locales mais on pourra prévoir une partie en réseau chiffrée répartie (peut être que Nextcloud évoluera dans ce sens?)
• un failover au cas ou la connexion box-internet tombe peut se faire normalement en déclarant une deuxième passerelle, 4G_smartphone-USB/ouWifi par ex

Chemins global que nous pourrions suivre:

1. déployer une simple machine pilote par système de recettes (trouver méthode la plus simple) sur un Git
   1. utiliser une ressource git pour le pilotage du déploiement d’infrastructure ou offrant ces fonctionnalités (libre)
   2. poser les communications chiffrées, DNS, authentification, suivi,
   3. documenter au fur et à mesure, dimensionner les capacités possibles
2. puis mettre en place plusieurs (2?) machines physiquement sur différent lieux en simple ADSL
   1. on peut envisager un minimum de préparation en amont
   2. la reproduction peut être clonage à ce niveau
3. y déployer ensuite les services: partages de données (identification,Nextcloud), simples sites (Hugo/wiki)
4. augmenter les ressources de connexions, bande passante (VPS/OpenMPTCP)
5. ajouter d'autres services (base docker)