🏠 PrĂ©sentation du projet de VPS de colocation

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

Pour faire suite Ă  :

Comme convenu sur le chat, voici un petit résumé de la discussion le 28.06.2025 à Strasbourg.

Lors du goĂ»ter en clĂŽture de l’AG 2025, quelques personnes ont discutĂ© briĂšvement le thĂšme des VPS de colocation dâ€șARN.

Il en est ressorti:

  • une dĂ©finition simple du terme «VPS de colocation » est un serveur VPS ARN administrĂ© par plusieurs personnes sur lequel fonctionnent des services/applis de diffĂ©rentes associations membres d’ARN. Ces personnes sont appelĂ©es co-administrateurs et peuvent ĂȘtre des membres actifs d’ARN ou bien un membre dĂ©signĂ© de l’association, qui est bien connu par ARN et qui a participĂ© au ARN camp pour la formation des co-administrateurs

  • Raison d‘ĂȘtre du VPS de coloc: les associations ont des besoins spĂ©cifiques pour leurs propres membres. Ouvrir un compte Yunohost/Sans-nuage pour chaque membre de l’association n’est pas praticable et pas judicieux.

  • il est prĂ©vu d’avoir une instance de service (par exemple un Nextcloud) par association, afin d’avoir une sĂ©paration bien nette au niveau des donnĂ©es utilisateurs et au niveau des accĂšs.

  • le fait d’avoir plusieurs administrateurs permet de mieux repartir les charges de travail, d’utiliser les synergies et de transfĂ©rer le savoir-faire entre les co-administrateurs.

2 « J'aime »