Wiki à compléter pour présenter et poser les contours « charte » du VPS de colocation.
Pourquoi ?
On constate que :
- Les services proposés actuellement par ARN ne répondent pas à tous les besoins de sa communauté.
- En particulier, des bénévoles actifs d’ARN continuent à héberger des services de manière autonome pour leurs propres besoins.
- Cela peut mener à des doublons de services, à la multiplication des serveurs et à l’augmentation de la charge de maintenance. Cela augmente la consommation d’électricité et nuit à l’environnement.
- Quelques exemples concrets : 4 serveurs Matrix qui copient toutes les données des salons de la communauté (totor, opto, seb, sans-nuage)
- Des bénévoles actifs ou membres de la communauté administrent des services pour des projets qui leur tiennent à coeur. Souvent ils font ça à leurs frais et de manière isolée, ce qui introduit un « Bus Factor » (Le « bus factor » est le nombre de membres de l’équipe qui devraient être absents (par exemple en raison d’une maladie - ou, pour le dire de manière plus radicale, « être écrasés par un bus ») pour qu’un projet s’arrête ou souffre massivement en raison du manque de connaissances et d’expérience de personnes disponibles.)
- Cela participe à la montée en compétences de certaines personnes mais ne facilite pas l’intégration d’énergie bénévole technique sur la maintenance des services et de l’infra d’ARN
- Les services et surtout l’infrastructure de ARN fonctionnent largement par le bénévolat qui n’est pas compensé. [que veux-tu dire par « compensé » ? « remunéré symboliquement »?]
Pour qui ?
- Pour des projets engagés, ayant du sens pour un ou plusieurs bénévoles de l’association, et respectant dans les grandes lignes le règlement intérieur de Alsace Réseau Neutre
- Le VPS de coloc n’est pas à proprement parler un projet ARN mais un projet de certains de ses membres et potentiellement des copain.es non-membres. Il n’est donc pas nécessairement soumis à toutes les chartes auxquelles sont par exemple soumis les services sans-nuage (charte chatons) et les services de FAI (charte FFDN). TODO : Préciser les éventuels relâchements de contrainte.
- A priori les projets hébergés sur le VPS de coloc sont portés par des personnes situées à Strasbourg et alentours, ou a minima à proximité d’un membre active d’ARN, afin de permettre des rencontres physiques pour des échanges productifs qui augmentent les compétences techniques globales de ARN.
Quoi ?
- Un serveur et des applications mutualisées, gérés « comme une colocation » par une communauté d’administrateurs système pour partager les ressources, les compétences, la maintenance, etc.
- Un serveur virtuel sous YunoHost pour standardiser le déploiement des Apps
- Limiter au maximum les configurations exotiques pour permettre à d’autres bénévoles de reprendre la maintenance en cas de pépin.
- Un second serveur éventuel pour séparer les CMS (services publics, ex. wordpress) très sujets aux attaques, des services cloud (services privés, ex. nextcloud) contenant des données personnelles
- Un fil sur le forum pour déclarer les opérations de maintenance et éventuellement un salon Matrix d’entraide (a priori alsace-entraide-numérique)
- Une discussion en réunion ARN pour présenter tout nouveau service et tout nouveau administrateur de la VM coloc.
- TODO: décider si pour chaque nouveau service/application une validation par le CA est nécessaire, ou simple cooptation d’un bénévole actif ?
- Des backup communautaires comme pour les machines de l’infra.
Par qui ?
- Membre de l’association et/ou personne bien connue de la communauté.
- Dans l’idéal membre actif qui aide à la maintenance de l’infrastructure nécessaire au fonctionnement de la VM de coloc (cluster proxmox, etc.)
- A déjà administré un serveur sur une longue période, en gérant les accès admin, les backups, dans l’idéal sous Debian ou YunoHost
- Respectant le règlement intérieur de ARN, en particulier la charte des adminsys ARN.
- TODO : préciser les éventuels relâchements quant aux contraintes de la charte.
Pour quoi ?
- services et applications complémentaires à ceux de l’offre sans-nuage (perso et asso, boite mail et site statique sur nom de domaine perso)
- pas de boites mails, ni d’envoi de mail en masse, seul l’envoi de mail nécessaire au fonctionnement des services/apps sera géré, cf. https://forum.arn-fai.net/t/discussion-technique-vps-coloc-et-personnalisation-ndd-sans-nuage/9505
- Essentiellement des CMS et
- Des services cloud mutualisés tels qu’un mattermost, un matrix, un nextcloud (Pourquoi un nouveau Matrix ou service Nextcloud? Le système de tchat de sans-nuage.fr est Matrix et nécessite un compte sans-nuage. Il se peut que des gens aient besoin d’un autre système de tchat ou de créer des comptes pour des gens sans adhésion individuelle chez ARN.)
- préférer les fonctionnalités de cloisonnement des utilisateurs au sein d’une app à l’installation d’une app supplémentaire
A quel coût ?
L’esprit est de sortir d’un modèle de tarification purement monétaire. On cherche à prendre en compte :
- Le coût des services du VPS de coloc sur l’infra d’ARN
- Le temps bénévole consacré à la maintenance du VPS de coloc et de l’infra d’ARN sous-jacente
- Le temps bénévole pour maintenir l’application en fonction de sa complexité : CMS ou service cloud, niveau de service nécessaire, support et nombre des utilisateurs
- La valeur sociale du projet soutenu
Quelques exemples :
- Des services persos d’un bénévole actif qui donne 1H par semaine à ARN → gratuit
- Des services pour un collectif informel avec un budget annuel d’une centaine d’€ → gratuit (?)/à voir au cas par cas
- Des services pour une association au budget annuel de plusieurs milliers d’€ → gratuit (?)/à voir au cas par cas
- Des services pour une entreprise éthique → gratuit (?)/à voir au cas par cas