Même si YunoHost est multi-domaine et multi-utilisateur, il reste inapproprié pour un usage mutualisé .
Premièrement parce que le logiciel est trop jeune, donc non-testé et non-optimisé pour être mis en production pour des centaines d’utilisateurs en même temps. Et quand bien même, ce n’est pas le chemin que l’on souhaite faire suivre à YunoHost. La virtualisation se démocratise, et c’est une façon bien plus étanche et sécurisée de faire de la mutualisation.
Vous pouvez héberger vos amis, votre famille ou votre entreprise sans problème, mais vous devez avoir confiance en vos utilisateurs, et ils doivent de la même façon avoir confiance en vous. Si vous souhaitez tout de même fournir des services YunoHost à des inconnus, un VPS entier par utilisateur sera la meilleure solution.
Et je m’interroge donc (après avoir cherché sur le forum et en-dehors) :
quelles sont les risques potentiels de donner des droits d’utilisateur à quelqu’un que nous ne connaissons pas ? (Je parle bien d’une personne qui n’aurait pas d’accès à l’administration de Yunohost, simplement à ses propres applications.)
à partir de combien d’utilisateurs environ peut-on considérer que Yunohost n’est plus adapté et quelles en seraient les principales raisons (je ne parle pas de limitation matérielle, seulement logicielle) ?
Merci par avance et désolé si des ressources existent sur le sujet, je ne les ai point rencontrées !
de manière générale, au jour d’aujourd’hui, un utilisateur qui veut casser les pieds aura plusieurs moyens de le faire … Par exemple, depuis le SSO, tu peux enregistrer un nombre illimité d’alias mail, ou configurer des forwards de mail vers des adresses qui casseront les pieds, etc…
Et si il/elle a un accès ssh, alors il/elle peut lancer pleins de programme ou bien “espionner” certaines choses qui se passent dans le serveur (même si c’est normalement limité)
Bref, il y aurait pas mal de choses à voir avant de pouvoir réellement fournir un accès à des utilisateurs sans devoir leur faire un minimum confiance. Mais il n’y a pas vraiment eu d’audit sur le sujet pour étudier l’entièreté de la surface d’attaque.
Dans les discussions en Interne, on évoque le chiffre de ~100 utilisateurs après quoi ça devient un peu touchy, mais c’est vraiment à la louche et arbitraire, tu peux très bien 5 utilisateur et en avoir un qui pète un plomb et casse les pieds. Mais dans l’histoire, le chiffre de ~100 est aussi lié au fait que on a pas trop de retour d’expérience à partir de cette échelle.
Néanmoins, je crois que dans le projet il y a une volonté de pouvoir aller vers une échelle plus grande (100~1000) même si ça demande du taf d’étude et de développement pour pallier aux points de faiblesse
Petit complément: ici Aleks parle de personne ayant un compte YunoHost. Il reste la possibilité de donner des comptes d’app (quand c’est possible) qui eux sont plus restreint.
Typiquement: nextcloud permet de créer un compte d’app.
Certaines apps peuvent fonctionner publiquement sans compte : lufi, opensondage…
J’essaie en ce moment de mettre en place un serveur pour une association pour avoir des outils entre nous. J’ai enregistré 23 utilisateurs qui auront tous accès aux apps:
Etherpad/Mypads (dans un sous-domaine), Nextcloud (avec Collabora sur un sous-domaine), Flarum (dans un sous-domaine aussi) et Roundcube.
Est-ce que c’est possible ? J’ai l’impression que parfois les redirections sont parfois tronquées…
J’ai ajouté une redirection pour tous les utilisateurs vers leurs mails pour qu’ils reçoivent des notifications.
Trouvez-vous que ce soit viable ?
Le applications ne sont pas public, c’est pour un travail interne…
C’est viable.
Je dirais qu’une machine avec 2Go s’en sort. 1Go si tu fais gaffe et que t’optimise un peu (swap, swapinness …).
Selon la qualité de la connexion ce sera plus ou moins lents.
Moi je mettrais OnlyOffice à la place de Collabora car on est pas prêt d’officialiser un package Collabora chez yunohost je pense.
$ cat /proc/sys/vm/swappiness
20
$ cat /proc/sys/vm/vfs_cache_pressure
100
$ cat /proc/swaps
Filename Type Size Used Priority
/home/file.swap file 1572860 0 -1
$ free -m
total used free shared buff/cache available
Mem: 1956 640 109 69 1205 1062
Swap: 1535 0 1535
Je n’ai pas pu installer zram-config, absent des dépôts de ce Public cloud d’ovh, peut-être car il y a déjà des configurations spécifiques ?
Ah ? du coup, j’hésite à le faire, pour l’instant Collabora marche avec quelques bizarreries tout de même. Est-que pour le faire, je désinstalle Collabora avant ? en le désactivant de Nextcloud auparavant ? Il faut l’installer sur un sous-domaine ? Il s’intègre aussi à Nextcloud ?
J’ai perdu l’accès à Nextcloud depuis avec une erreur du genre ‘The server encountered an internal error and was unable to complete your request’, du coup j’ai du le désinstallé et réinstallé.
Depuis, j’ai ajouté Onlyoffice et j’hésite à ajouter en plus Collabora, de peur qu’il casse de nouveau (même si je ne suis pas certain que ce soit lui la cause) Nextcloud. Onlyoffice à l’air plus intégré à yunohost, dommage car moins libre, mais je préfère un peu de stabilité pour ce cadre en tous les cas.
OnlyOffice est en licence AGPL3, et est effectivement basé sur le format docx au niveau de ces rouages internes (même si il peut éditer des .odt).
Collabora Development Edition/Libreoffice Online :
utilise odt en interne (et peut ouvrir du docx),
est en licence MPL2 (ce qui implique qu’on peut prendre le code et ajouter d’autres bout de code proprio à côté)
utilise le droit des marques pour empêcher de distribuer le programme sous le nom LibreOffice Online ou Collabora si la limite du nombre d’utilisateurs n’est pas intégrés… Le tout de façon assez confuse.
organise un flou sur les différentes versions propriétaire et “open source” (Collabora Online vs CODE), si bien qu’on ne comprend pas si il y a des différences ou non.
est assez flou vis à vis du lead sur le projet entre The Document Foundation et Collabora… Concrètement on a posé une question à The Document Foundation et on a eu une réponse d’une personne de Collabora.
La réponse de Collabora pour le paquet yunohost a été de dire qu’il fallait que ça s’appelle YunoOffice si on proposait une option pour retirer la limite du nombre d’utilisateurs… Ce qui semble aberrant dans une logique d’OS comme YunoHost et également en terme d’expérience utilisateurs.
Et, de mémoire, de dire que c’était courant d’utiliser le droit des marques pour propriétariser un logiciel…
De ce fait, je considère de mon côté que OnlyOffice semble plus libre ou en tout cas tout autant.
