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