Différences

Ci-dessous, les différences entre deux révisions de la page.

--- blog:hentou [2023/05/02 14:24] – [Un début de cahier des charges] jeff
+++ blog:hentou [2024/02/08 17:20] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 34: / Ligne 34: @@
 ==== Vers?: ====
-**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 de Nextcloud mais 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.\\
+**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:
@@ Ligne 123: / Ligne 123: @@
 Sans reprendre les buts exposés ci-dessus, le chemin pris semble être le suivant:\\
 Dans le cadre d'installations expérimentales nous devrions:
-  - mettre en place une infrastructure visant à être reproductible de petits serveurs locaux interconnectés, placé dans différentes structures volontaires
+  - mettre en place une infrastructure visant à être reproductible de petits serveurs locaux interconnectables, placés dans différentes structures volontaires
     - devant servir à chaque fois au maximum une dizaine de personne, plus ou moins, localement ou non, en connexion simultanée ou pas
     - de machines consommant peu (TDP<20W)
-    - économiques
+    - économiques, favorisant la récup et l'occasion.
-  - mettre en place des réseaux de communications indépendant des fournisseurs d'accès à Internet
+  - mettre en place des réseaux de communications relativement indépendant des fournisseurs d'accès à Internet
     - supportant l’agrégation (plusieurs ADSL ou ADSL+4G, fibre, autre)  afin de faire face aux manques de connectivité sur le territoire
+    - utilisant ses propres DNS
   - bâtir un ensemble de services autour d'une machine hyperviseur et de machines virtuelles afin d'avoir
     - une facilité de mise en place, de gestion et de sauvegarde
     - une topologie reproductible (à l'identique?)pour une bonne compréhension
-    - commencer par des services de partage de fichier,agenda (Nextcloud) et de site internet simple
+    - commencer par des services de partage de fichier,agenda (genre Nextcloud ?) et de site internet simple
   - former/accompagner des référant qui pourront suivre le prototype et le reproduire
-**Solutions envisagées**
+===== Solutions envisagées =====
 Partie de préconisations acquises:
-  - utiliser des machines sur base Intel/AMD pour des soucis de compatibilité (dans un premier temps), seconde main (i3,Gx)
+  - utiliser des machines sur base Intel/AMD pour des soucis de compatibilité (dans un premier temps), seconde main (i3,GX)
   - commencer par une mise en place sur une simple liaison ADSL (sélectionner FAI) à moins de trouver des lieux fibrés.
     - aller ensuite vers un couplage ADSL/4G  facilement reproductible
@@ Ligne 150: / Ligne 152: @@
   * Yuna accompagne les mises en places avec les recettes qu'elle fourni
-Questions à Yuna en suspend(nécessaire pour la proposition de réalisation!):
+===== Solutions 2me réflexions =====
-  - ? techniques de conteneurisation (? nethserver 7/8, docker etc )
+  * 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.
-  - ? OS et images systèmes
+  * 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.
-  - ? topologie des bases de données, accès, répartition, reproduction
-  - ? système d'identification
+Cela nous amène :
-  - ? service de suivi, console, préventive et alarme
+  * à penser une solutions intermédiaire dans l'administration des services et des serveurs(ou des machines):
-  - ? dans un futur envisager une répartition de certain service (synchronisation/redondance/ P2P ?)
+    * 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 allons suivre:
+Chemins global que nous pourrions suivre:
-  - déployer une simple machine pilote par système de recettes (trouver méthode la plus simple)
+  - déployer une simple machine pilote par système de recettes (trouver méthode la plus simple) sur un Git
     - utiliser une ressource git pour le pilotage du déploiement d’infrastructure ou offrant ces fonctionnalités (libre)
     - poser les communications chiffrées, DNS, authentification, suivi,

Outils du site

Différences

Outils de la page

Outils pour utilisateurs