Forum Astuces.divers Comment créer une nteraction entre bureau local et {ssh+tmux|screen+app persistante}

Posté par  . Licence CC By‑SA.
Étiquettes :
0
8
fév.
2013

Bonjour faux rhum,

aujourd'hui, le web a évolué, et le monde de la console, s'il avance doucement, se fait distancer en terme d'utilisabilité.
Il reste toutefois à mes yeux nettement plus confortable d'utiliser mon tmux persistant, mais pour combien de temps ?

De façon générale, je crois que le besoin se fait sentir -en tout cas pour moi- d'un moyen de communication entre les applis persistantes et le terminal graphique depuis lequel je m'y connecte.

Mails 

Usage

Je lis mes mails avec ssh (ou mosh)+tmux+mutt depuis n'importe où — j'utilise rarement imaps.

Problème

Je me suis récemment abonné à des listes de diffusion généralistes dont je lis avec intérêt de nombreuses contributions, mais malheureusement, nombreuses sont les pièces jointes indispensables à la compréhension des courriels (parfois des documents word, ou simplement un message formatté en HTML sans aucune raison valable, ou encore un PDF officiel fuité).
Je me vois bien jouer un rôle "éducatif" de temps en temps, mais je ne suis pas là pour rappeler la nétiquette sans arrêt non plus.
Pour lire ces pièces jointes, c'est toujours la croix et la bannière : un clic ne suffit pas, je dois télécharger le fichier sur la machine où je me trouve pour le visionner correctement (évidemment, le HTML est en général illisible avec w3m).

Souhait de solution

Je voudrais, lorsque je fais mon ssh depuis certaines machines bien configurées pour ça, que mutt se débrouille pour lancer la visionneuse PDF de mon ordinateur de bureau. Ou ouvre le fichier html avec tous ses jpg dans un navigateur…

Notifications

Je fais de l'IRC, avec ssh+tmux+irssi depuis n'importe où.

Là, ça serait simplement un petit confort supplémentaire que d'avoir des notifications. J'ai vu que cela existait, à l'aide de sockets locaux, ou de fichiers temporaires "pollés" depuis la machine qui affiche les notifications, mais ça ne me satisfait qu'à moitié : c'est un gros hack ☺

Une solution générale ?

De même que le "long polling" a permis de saturer les serveurs web et d'éviter un passage à un protocole plus intelligemment conçu que HTTP (par exemple XMPP), mosh permet aujourd'hui, sur certains réseaux IP qui se comportent bien, d'améliorer élégament l'expérience utilisateur en établissant une communication UDP entre le client et le serveur. Est-ce que ce genre d'extensions au protocole SSH est une piste à suivre ? Avez-vous d'autres idées ?

Merci d'avoir lu !

  • # ii

    Posté par  (site web personnel) . Évalué à 1.

    Je fais de l'IRC […] Là, ça serait simplement un petit confort supplémentaire que d'avoir des notifications

    ii ne serait-il pas pratique ? Un faux fichier dans ton systeme de fichier, mis a jour en live avec les messages du chan actuellement utilise.

    Sans avoir teste,

    $ tail -f irc/my.irc.server/#mychan/out | xargs dzen
    
    

    devrait être intéressant.

    De même que le "long polling" a permis de saturer les serveurs web et d'éviter un passage à un protocole plus intelligemment conçu que HTTP

    A mon avis, HTTP est très bien conçu. Il est juste très mal utilisé. Quand tu utilises un protocole d’accès sans état a des documents pour échanger des messages dynamiquement entre deux machines dont le rôle de client ou de serveur est indépendant du protocole de transport, tu fais n'importe quoi. Ça marche, mais c'est n'importe quoi. Pour le coup, STOMP aurait au moins été plus simple pour faire une transition douce vers de l’échange de messages

    • [^] # Re: ii

      Posté par  . Évalué à 1.

      Merci de cette proposition de solution pour IRC. Il y en a d'autres, mais à chaque fois, on invente une solution ad-hoc pour le besoin.

      Je voudrais un système plus général, extensible à des applications tierces.

      • [^] # Re: ii

        Posté par  . Évalué à 1.

        Hm, j'ai une idée : il y a une communication entre les applications console et le terminal qui les affiche (par exemple pour mettre en place le titre…). Ce canal de communication doit pouvoir être détourné !

  • # export DISPLAY

    Posté par  . Évalué à 1.

    ssh -X ...
    
    

    Aprés faut avoir un serveur X sur le poste client, et tu peux lancer sur le serveur des applis graphiques avec affichage déporté (xpdf, xbiff, …)

    • [^] # Re: export DISPLAY

      Posté par  . Évalué à 2.

      Ah et si tu veux tunneler d'autres protocoles, ssh le fait aussi ( cf options -L et -R ). Mais là il te faut évidemment avoir les clients graphiques sur ta machine.

    • [^] # Re: export DISPLAY

      Posté par  . Évalué à 2.

      Ça reste vraiment suboptimal de faire passer le protocole X dans du ssh, question latence. Et mon serveur ne devrait pas lancer d'applis graphique, il n'a pas la RAM pour ça.
      Je trouverais bien plus jolie une solution qui transfèrerait le fichier dans /tmp sur la machine cible (dans le temps, zmodem faisait ça bien) avant de lancer l'application correspondante sur la machine cible toujours -ou alors, si c'est un fichier "seekeable", d'utiliser un système de fichiers type sshfs pour accéder à la donnée.
      Ce qui m'intéresse, c'est surtout que ça soit simple à utiliser.

  • # dbus

    Posté par  (site web personnel) . Évalué à 2.

    Je pense que la bonne manière de faire est de le faire avec dbus. Une recherche rapide m'a amené gabriel (un vieux prototype) : http://www.eldemonionegro.com/blog/archivos/2008/05/22/howto-to-intercomunicate-processes-in-differentremote-machines-through-dbus

    Une autre implémentation avec un protocole simple inventé pour l'occasion : http://sanpi.homecomputing.fr/content/notification-irssi-over-ssh

    A adapter pour mutt avec la commande à configurer sur arrivée d'un nouveau courriel.

    • [^] # Re: dbus

      Posté par  . Évalué à 2.

      Ça me semble propre aussi, merci du lien

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.