Admins

Actuellement, l'application web Mumble-web est installée en mode santalone. Le mode proxied permettrait d'être plus homogène avec l'archi du SI April.

Dans le README.md du projet (https://github.com/johni0702/mumble-web), on peut lire que Mumble-web est utilisable soit en mode standalone , soit en mode proxied .

Le mode standalone (méthode actuelle sur SI April) consiste à confier à websockify la gestion du flux vers mumble et aussi celle les pages web statiques.
Au premier abord, ça semble plus simple mais en fait :

• nécessite de gérer un certificat sur la vm mumble et donc :
  • déplace la gestion du certificat de la vm bastion vers la vm mumble,
  • nécessite le déploiement d'un nginx sur la vm mumble uniquement pour gérer la génération letsencrypt,
  • impose un aiguillage via un try_files dans nginx sur la vm bastion,
  • introduit un cas particulier par rapport aux autres vm (en plus de l'usage de dehydrated à la place de certbot),
• empêche d'avoir des logs http de fréquentation de la page d'accueil.

Le mode proxied (méthode sur SI Chapril), consiste à confier au nginx de la vm allo la gestion des pages statiques et à lui demander de relayer le flux webrtc vers websockify. Les avantages :

• websockify n'a pas besoin de certificat sur la vm allo donc :
  • on peut garder la gestion de certificat sur la vm bastion de façon homogène à tout le SI April,
• le nginx de la vm mumble permet de générer localement des logs http,
• évitement de try_files en configurant l'URL foo.bar.org/ws comme aiguillage du flux webrtc.

Vu la simplification et l'homogénéisation, préconisation de migrer la conf en mode proxied .
Comme actuellement, ça fonctionne, pas d'urgence, attendre le moment où ça gêne le moins.