Autohébergeons nos systèmes d’assistance à distance

Bonjour la communauté Yunohost.

Je viens vous faire part de la publication de ce tuto sur le forum de Normandie Libre qui explique comment auto-héberger (et rien qu’avec du Libre bien sûr) sa solution d’assistance à distance (avec une subtile association d’OpenVPN, de VNC et de Netfilter).

Il est idéal pour tout(e) libriste, individuel(le) associatif(ve) ou entrepreneur(se), qui se résigne à utiliser des solutions privatrices (Teamviewer) ou seulement à moitié libre (DWservice).

Pour avoir donné des cours (d’informatique libre) à distance chaque semaine durant des années avec un système réalisé à partir de ce tutoriel, je confirme que cette solution est très efficace, légère (peu de délai — pour ne pas dire aucun — malgré les connexions moisies de la campagne ornaise) et très facile d’utilisation pour la personne aidée. Enfin, uniquement basée sur des logiciels libres, on peut l’utiliser en toute confiance !

Mon rêve serait qu’une communauté, telle que Yunohost, s’en empare pour le peaufiner, le scripter (voire lui faire une interface web) et le distribuer afin de le rendre accessible à tous…

7 Likes

Ca serait une super idée !

1 Like

Oui je confirme,
De mon côté j’ai mis en place uniquement un lien uvnc -> serveur, à la manière d’un Teamviewer où le client est connecté au serveur (uvnc repeater)
http://forum.ultravnc.info/viewtopic.php?p=80701

1 Like

Merci.

Voici un schéma présentant le principe de base de cette solution, temporairement nommée Yunolink pour ce fil de discussion. J’espère que c’est suffisament compréhensible :

Pour l’avoir personnellement éprouvée avec des élèves débutant dans l’utilisation d’un ordinateur, je confirme qu’une connexion VNC au sein d’un VPN est une méthode aussi souple d’utilisation que légère.

1 Like

Je viens de me souvenir qu’à l’occasion d’une remise à plat de nos services réseaux, nous avions hébergé plusieurs semaines cette solution (connexion VNC dans un VPN avec quelques règles Netfilter) :

  • sur une carte « OpenHardware » Olinuxino Lime2 de chez Olimex que nous avions achetée (via une commande groupée organisée par Grifon si vous voulez tout savoir :wink: ) en suivant les recommandations de la page du projet La Brique Internet, lui-même basé sur Yunohost.
  • Cette carte était située derrière une toute bête FreeBox ADSL avec un débit pas très folichon (je n’ai plus les chiffres sous la main.).

Cette précision est là pour illustrer la légéreté de la proposition décrite plus haut.

1 Like

Bonjour la communauté Yunohost.

Je poursuis la description de cette fameuse solution d’assistance à distance auto-hébergeable. Passons maintenant en revue l’usage de la solution par l’utilisateur aidé, dont le niveau en informatique est potentiellement très bas :

Cet usage par l’utilisateur aidé :

  • se doit d’être hypersimple,
  • ne doit être permis qu’avec son consentement expresse (il ne faut pas lancer le système dès le démarrage de l’ordinateur par exemple).

Hé bien, je pense que c’est le cas (en tout cas sous GNU/Linux) :

  • Pour autoriser l’accès à distance de l’utilisateur aidant : clic sur la ligne correspondant au VPN d’assistance à distance servi par votre instance de Yunolink dans le menu des connexions réseau. C’est plus facile que de se connecter à une wifi !!!
  • Pour couper cet accès : reclic sur la même ligne.

V’la tout ! :wink:

Explication technique

La connexion au VPN repose sur une clef privée (unique par utilisateur) et un certificat préalablement présents sur le poste aidé, plutôt que sur un mot de passe. Ainsi, l’utilisateur aidé « n’a plus qu’à » cliquer.

De plus, NetworkManager permet l’exécution de scripts maison consécutive à la connexion ou à la déconnexion à un VPN (pour en savoir plus : $ man NetworkManager section DISPATCHER SCRIPTS ).

« Il suffit » ainsi de placer un script qui lance le serveur VNC à la connexion au VPN et qui supprime ce processus à la déconnexion.

Voici le script en question (rédigé par un autre membre de Normandie Libre ) que nous avions utilisé il y a deux ans, il faudrait le rafraichir car nous ne pensons pas que x11vnvc soit utilisable sur nos distros fonctionnant désormais sous Wayland plutôt que sous X.Org :

#!/bin/sh

## Lance automatiquement le serveur x11vnc lors de sa connexion
## OpenVPN pour l'assistance à distance.

## Le serveur VNC est configuré pour n'autoriser que les connexions
## entrantes sur l'interface du VPN, supporte le transfert de fichiers
## UltraVNC et est lancé avec les droit de l'utilisateur connecté sur
## l'interface graphique pour que le transfert de fichier s'opère avec
## des droits restreints.

test "$1" != "tun0" && exit

X_CONNECTED="$(w | grep " :0 " | cut -d " " -f 1 | head -n 1)"

case $2 in
	       vpn-up )
			      su -c "x11vnc -display :0 -nopw -allow 172.20. -ultrafilexfer -forever -env FD_XDM=1 -auth /home/$X_CONNECTED/.Xauthority" $X_CONNECTED &
	       ;;
	       vpn-down )
			       killall x11vnc
	       ;;
esac

Il s’agira encore de scripter :

  • la génération de clef par utilisateur de la solution sur le serveur Yunolink ,
  • l’installation du script ci-dessus et de la clef personnelle sur le poste aidé (il s’agira probablement d’une collection de tels scripts afin de prendre en compte les différences de comportement de nos différentes distros*, et c’est l’une des raisons pour lesquelles cette solution Yunolink devrait être prise en main par une communauté suffisamment large ).

C’est ce que j’aborderai plus tard. :wink:

*Note: je précise que je parle ici des différentes distros installées sur les postes aidés et aidants , et pas de celle du serveur Yunolink qui reste une Debian typique.

Oh ! Je viens de retrouver l’un de nos mémos dans lequel est décrit les ressources matérielles alors allouées à notre solution d’assistance à distance :

« Le serveur est une machine paravirtualisée à l'aide de Xen sur laquelle est installée Debian Jessie.
Elle n'a pas besoin de beaucoup de ressources, voici ce qui lui est alloué :
 - **256M** de mémoire centrale,
 - **1 vcpu**,
 - **512M** de swap,
 - **5G** d'espace de stockage pour le système et les données. »

Ce qui signifie qu’on était en fait confortable quand on l’avait installé sur l’Olinuxino Lime 2 pour maintenance du serveur principal ! Je n’avais pas conscience de cela à l’époque… :wink:

Salut \o

Ça ressemble beaucoup à Gitso ce que vous mentionnez : https://github.com/stephdl/gitso

Le projet indique qu’il n’est plus maintenu, mais chez moi ça marche toujours :slight_smile:

Le principe: l’aidant démarre le serveur, et se démmerde pour que le port soit NATé comme il faut (normalement pas trop dur pour l’aidant), puis il file son adresse ip à l’aidé, et c’est tout ce qu’il a à rentrer dans son interface ! En fait c’est une sorte de reverse VNC.

Pour moi pas besoin de VPN ici.

Bonsoir à tous,
Ce projet m’intéresse car actuellement pour dépanner les amis et la famille j’utilise justement Teamviewer. Eux sont sur Mac ou Windows principalement. Quant à moi, je suis sur une distro avec Gnome sur Wayland, en l’occurrence Arch Linux.
Par contre j’ai une question, est-ce qu’une solution basée sur WebRTC et le partage d’écran, comme sur https://meet.jit.si/, mais auto-hébergée (et peut-être simplifiée, en ne gardant que le partage d’écran) ne serait pas plus simple à mettre en place ?

Bravo en tout cas pour cette initiative ! :clap:

1 Like

Merci de l’indication. Je contacterai le(s) développeur(se)s de Gitso pour voir si on ne peut pas faire quelque chose ensemble.

Avec la solution d’un VPN, l’aidé à encore moins de manipulation à réaliser, et notamment pas d’adresse IP à retaper (ce qui intimide… si si ! En tout cas la première fois que j’ai vu une IP il y a plus de 20 ans… je n’en menais pas large ! ^^

Il faut également penser au cas où l’aidant, lui non plus, n’est pas versé en informatique. En effet, Yunolink pourrait s’adresser à des formateurs en n’importe quel logiciel libre (graphisme, comptabilité et autre bureautique par exemple…).

Ces usages de Yunolink pourraient se faire dans le cadre d’un GULL où tous les membres s’échangeraient leurs compétences, tuyaux et coups de main grâce à cette plateforme déployée par leur propre association.

Et je ne parle pas des cas de micro-entrepreneurs du Libre, qui disposeraient ainsi d’un sacré outil pour développer leur offre de formation à distance, ou pour pouvoir dépanner au besoin les bénéficiaires de leurs propres installations GNU/Linux.

(Vécu : c’est vraiment cool de ne pas avoir à se déplacer pour, par exemple, réafficher la barre personnelle de Firefox, escamotée suite à une mauvaise manipulation du client totalement novice !!!)

Cependant, je ne dis pas qu’une solution est meilleure qu’une autre ! Au contraire, Yunolink devrait pouvoir offrir le choix de la technique d’assistance à distance mise en place : VNC/VPN ? VNC/SSH ? Autre méthode ? Selon moi, il faudrait tout inclure, tout scripter, développer une interface web belle et pratique ! (tant que ça reste libre bien sûr)

C’est pourquoi je vais contacter Gitso

Pour ma part, je n’ai pas cette impression. La solution-maison à la base de cette idée dite Yunolink reposait sur des script Bash ce qui me fait moins peur que des technologies web… chacun son truc ! :wink:

Il y a aussi la question du signal de la souris… est-ce que le déplacement de pointeurs est pris en charge dans Jitsi ou pas ?

Dans tous les cas, toujours dans cet esprit de proposer un maximum de choix techniques, j’explorerai quand même cette idée basée sur Jitsi afin de voir si on peut l’intégrer.

Damned Je viens de lire ça… Waouh :


Je suis ce fil :slight_smile:

1 Like

Moi aussi :slight_smile:

Bonjour,
Je sujet m’intéresse aussi.
Il existe Remotely (https://remotely.one/) et DWService (https://www.dwservice.net).
J’ai testé le premier rapidement et je l’ai trouvé lent.
Je compte tester le deuxième quand j’aurais un peu temps.

1 Like

J’ai testé avec satisfaction DWService qui propose des clients dispo pour tout OS avec le même principe ue Teamviewer, malheureusement, leur système ne propose pas d’auto-hébergement. Il faut obligatoirement passer par un de leurs noeuds : https://www.dwservice.net/fr/contribute-nodes.html
Seul le client est open-source.
On m’a aussi parlé d’un autre service d’assistance : https://github.com/Ylianst/MeshCentral . Dans ce cas, pas de client à installer pour l’“aidé”, un navigateur web suffit. Mais je n’ai pas testé ce serveur.

1 Like

Bonjour, est-ce que certains d’entre vous seraient motivés pour m’aider à packager MeshCentral ?

1 Like

Peut-être… En tout cas, j’ai trouvé un tuto d’install

En ce moment, je suis déjà pris par de trop nombreux projets… tous libres bien entendu ! Je suis désolé de devoir décliner.

Ce serait peut-être une bonne idée, @nath5394, de solliciter de l’aide via Contribulle. C’est tout nouveau, mais j’ai déjà testé pour un projet, et j’ai eu 1 réponse !

Hey ! Merci pour vos aimables réponses. J’ai commencé doucement à faire un paquet pour Yunohost. Actuellement il ne fonctionne pas encore (:warning: ne pas tester sur un serveur en production !! :warning: ) Voici le lien vers le dépôt : https://github.com/nathanael-h/meshcentral_ynh

Au passage j’en profite pour dire que je suis d’accord pour le transférer sur l’oga yunohost-apps sur github, je crois que je n’ai simplement pas les droits pour le faire.
Sinon merci pour le lien vers contribulle, je ne connaissais pas j’irai voir.

2 Likes

je prends ce fil en cours… depuis un moment je suis à la recherche d’un système idéal…
où ma sauvegarde soit automatique, où je puisse ouvrir un tunnel et pousser un port dedans… Qui soit facile à déployer et à maintenir…

En même temps que ces problème d’architecte système, je me rends compte qu’ouvrir toutes les vannes du numérique entre nous crée une énorme cacophonie. Non seulement, les données se retrouvent dupliquées dans tout les coins, mais l’information devient de plus en plus difficile à extraire…

C’est avec l’association de IPFS et du protocole de réplication distribué Scutlebutt que j’ai pu répondre à ces soucis… Avec Astroport/KODI, voilà en démonstration le principe appliqué à un stockage partagé entre amis de leurs vidéos au travers de l’interface Kodi.

Une fois “astroport” (automate programmable en bash) installé, en quelques lignes (ex: ipfs p2p pour “forwarder” un port) tous les soucis du début s’envolent. Mes amis de niveau 5 peuvent assurer mes sauvegardes, on peut associer un “wallet” à un pointeur IPNS qui contient des data pour les monétiser (en G1 bientot). Créer une “blockchain” revient à nommer un répertoire puis à utiliser natools pour y dialoguer… Bref, un espace numérique qui fait exister le Web des gens (façon A B C), et fait naître des réseaux de réseaux d’amis.

La structure réseau p2p en émerge selon les niveaux de confiance établies entres les identités de chaque station sur Gchange. IPFS dédoublonne, réparti, partage, des clefs crypto permettent de sécuriser l’ensemble, en plus de l’usage de fail2ban.

En activant les passerelles http avec un round robin dynDNS, on peut s’en servir pour monter un datacenter virtuel (non censurable). Le streaming video a été testé

Si l’exploration vous motive, parcourez le code du TestNet et commençons à auto héberger le web en entier :wink:

1 Like

Au lieu d’obtenir un permis émis par une autorité, nous obtenons des certificats d’aptitude émis par les pairs ayant acquis un certain niveau d’aptitude certifié eux même… Voila comment le P2P et ses « WoT » redéfinissent les choses.

L’Euro n’a aucun référentiel cohérent, ainsi que tout ce qui le prend comme référence… Une Monnaie Libre (comme le DU(G1)) est une UNITE DE MESURE.

Pour comprendre l’antidote p2p qu’Astroport construit pour offrir une alternative à la cacophonie Internet et la prison qui s’y construit. Contactez moi en MP pour participer au prochain stage (visio) sur la programmation de Astroport.