🐈 Bundle yunochatons

Limite d’une instance YunoHost: 500 à 1000 comptes

Rappelons dans un premier temps que YunoHost est fait au départ pour le contexte de l’auto-hébergement élargis aux proches ou dans un contexte de petite organisation.

Ceci étant dit, il y a sur internet des articles qui disent que ce n’est pas fait pour faire plus, une des raisons simple à ce discours c’est que pendant longtemps le site de YunoHost indiquait ça aussi. Mais les choses évolues et YunoHost a officiellement une dynamique pour tendre vers les communautés de petites et moyennes tailles (notamment les chatons).

La doc actuelle de YunoHost dit:

YunoHost n’est pas conçu pour « passer à l’échelle » au sens traditionnel du terme. Il est conçu pour un nombre relativement modeste de comptes et d’utilisateur⋅ice⋅s simultané⋅e⋅s. Bien qu’il n’y ait pas de limite stricte - puisque les performances dépendent fortement de votre configuration spécifique - nous estimons que des ajustements techniques peuvent s’avérer nécessaires à partir de 250 à 500 comptes, ou de ~50 utilisateur⋅ice⋅s simultanés sur des applications gourmandes. Ceci étant dit, YunoHost peut aisément héberger des sites web ou autres services légers recevant des milliers de visites quotidiennes.

Mon avis, c’est que si c’est pour faire des comptes mail+cloud+matrix, il doit être possible de monter jusqu’à ~1000 comptes. Plus exactement:

• probablement des milliers de boites mails
• compte nextcloud au moins 900 (je gère une instance avec 900 comptes internes nextcloud et elle est sous yunohost). La doc de Nextcloud indiquait 1000 comptes max pour une instance mono-serveur
• pour matrix j’ai moins de recul (mais ça dépend forcément des réglages en détails de l’instance)

Reste que structurellement, il manque certaines fonctionnalités utiles dés qu’on a plus de 5 comptes (renouvellement de mot de passe, inscriptions). Et que des réglages sont à adapter sur les webmail et nextcloud dés qu’on héberge des personnes qui ne sont pas censées se connaître.

Stratégie d’ARN

Le problème de fond c’est que plus vous avez d’usager⋅es, plus il y a de bouche à oreille, plus le nombre d’usager⋅es est susceptible d’augmenter, SI il n’y a pas de friction dans les process (lenteurs ou contraintes d’inscriptions par exemple)

L’AG a déjà validé qu’idéalement nous ne fermerons pas les inscriptions une fois la limite de sans-nuage atteinte, la solution de répliquer les services sur adhésion de sans-nuage.fr a été proposée, et même de standardiser son déploiement, d’où le concept de « Bundle yunochatons ».

A noter que les services public peuvent être aussi concerné, mais là aussi nous avons la possibilité d’opérer avec un « bundle yunochatons publique » et un système fédéré ressemblant à entraide.

Bundle services sur adhesion (mail+cloud+chat) yunochatons_ynh

Mail

roundcube (mail.domain.tld)

  * avec désactivation du partage LDAP

rspamd

API contact pour site statique

On fait une API simple avec un captcha pour créer un formulaire de contact qui envoie un mail vers le mail du compte.

Cloud

nextcloud (cloud.domain.tld)

Éviter la tentation S3 vu les soucis

onlyoffice (office.domain.tld)

(optionnel) une app de formulaire(sondage.domain.tld)

Chat

synapse (matrix.domain.tld + SRV domain.tld)

Préconfiguré pour rejoindre une fédération des serveurs yunochatons lié à Sans-nuage (ou au chatons)

synapse-admin (synadmin.domain.tld)

element (chat.domain.tld)

Bundle services en accès libre yunochatons_public_ynh

L’idée ici est de proposer des services pas trop complexes à héberger en accès libres, ceci implique que les services ne soient pas trop facilement détournables pour mener des attaques:

• pas de fonctionnalités permettant de lancer des requêtes GET sur d’autres machines (hors meta-moteur cadré)
• pas de partage par lien qui affichent des pages web (issus d’un zip par exemple) ou des images
• pas de minification d’url qui obscurcisse le lien de destination
• pas de visio / partage d’écran trop facilement détournable aussi pour créer des chaînes de tv illégales

L’idée c’est aussi de donner une priorité aux logiciels les plus accessibles, les plus sûrs et les plus ergonomiques.

Si le tout est basé sur des technos pas lourdes et qui vont bien ensemble c’est mieux.

Catégorisation à revoir

Focus sur la recherche

en utilisant le portail public yunohost ?

moteur de recherche (searxng+yacy ?)

Création collaborative

pad (etherpad ou la suite doc si accessible et léger)

calc (cryptpad calc?)

wiki sans media : le futur de libreto ?

signaturepdf

Communication

vote (pollaris test a11y todo)

chat/audio conf (jitsi ou chitchatter en audio only ?)

drop(lufi)

éventuellement étendue avec du filepizza

outils de partage de mot de passe par lien éphémère

une page qui fait installer un plugin firefox pour avoir un bouton about:translations ?

privatebin ???

Médias sociaux & contenus

des liens tout betes

Redirection vers peertube, joinmastondon & co, doc pour se dégoogliser

un portail de jeux et activités créatives web en JS

autobd

Création web

Cartographie

cdn tuiles osm

Widget calendar pour site statique

openwebcalendar ou hash calendar

captcha libre

dumbwhois

qrcode (qr)

Ajout ARN

A voir si on doit penser le bundle aussi sur ces points, notamment la question de COIN qui est utilisé pour

• redirect domain.tld → sans-nuage.fr
• connecteur coin
• monitoring
• borg
• borg__2

Fonctionnalités à part

Il est prévu que :

• le bridge arn-messager soit sur un serveur à part
• hoplagenda (en tant qu’agenda local) de toute façon c’est loin d’être prêt
• le serveur matrix pour les proches non membres tchatons.org

Changement sur le site

Pour la connexion, revoir l’authentification:

• Demander le compte utilisateur
• puis authentifier sur le bon serveur

Au niveau du menu, on a actuellement:

• Sans-nuage
  • En accès libre
  • Sur adhésion

Peut être faut-il envisager:

• Apps en ligne
  • Sans-nuage En accès libre
  • Sur adhésion

Changement dans coin

Faire choisir le serveur lors de la demande (par exemple via la question Offre ou un dev supplémentaire)

Animation, support et maintenance

Ca pose aussi des questions en termes d’animation et de maintenance.

Le but c’est à la fois qu’arn puisse déployer facilement un serveur yunochatons en plus, mais aussi que d’autres entités puissent déployer le leur.

On peut aussi imaginer un système d’antenne arn qui gère son yunochatons, voir qui se constitue plus tard en asso et prend son indépendance. Un genre d’incubateur pour chatons ?

Multiplier les serveurs posent aussi la question de l’évolution des instances les unes par rapport aux autres:

• est-ce qu’elles restent forcément fixées aux choix du meta paquet yunochatons ?
• est-ce qu’elles peuvent s’en détacher ou forker le paquet ? ou personnaliser l’instance en ajoutant une app en plus par exemple ?