Dit comme ça on dirait SSH mais attendez je veux un truc en plus. Ted nous a présenté "outrun" : «un programme Python qui permet d'exécuter une commande locale sur un ordinateur distant» (merci ted). Suite à ce lien je me suis demandé si il était possible de faire l'inverse. Je m'explique.
Outrun permet, si on a ffmpeg en local, de faire
outrun user@host ffmpeg -i input.mp4 -vcodec libx265 -crf 28 output.mp4
et d'utiliser le processeur du host pour exécuter la commande (même si le host n'a pas la commande en question)
Est-ce qu'il existe un service/programme "elsewhere" qui permettrait d'exécuter une commande que je n'ai pas en local mais qui est disponible sur un serveur. Un peu comme les lambda de AWS mais bien plus simple. Si je n'ai pas ffmpeg en local je ferais juste
elsewhere ffmpeg -i ~/mavideo.mp4 -vcodec libx265 -crf 28 ~/output.mp4
ou même
elsewhere vim monscriptlocal.sh
Mon programme elsewhere aurait bien sûr déjà été paramétré dans .local ou etc pour lui dire à quel serveur se connecter. Un genre de VNC pour la cli en fait. Du "CLI as a service" (me suis fait des ennemis là). Ça permettrait par exemple d'exécuter des commandes sur un RPi sans avoir à les installer ni faire voyager "manuellement" mon fichier vers le serveur, SSH dessus, bosser, copier le résultat dans l'autre sens.
PS1 : Oui je vois bien que ça ressemble à du SSH mais je parle de quelque chose de plus "intégré", de plus intuitif. D'ailleurs, en SSH comment je fais pour modifier simplement un fichier local avec un ffmpeg qui se trouve sur une autre machine ? (simplement = sans sftp puis SSH ou tunnel, ou alors avec tout ça empaqueté en une commande)
PS2 : Ce journal pourrait trouver sa place dans le forum "général.cherche-logiciel" mais je ne sais pas si ce dont je parle existe, ni même si c'est une bonne idée. C'est juste une idée qui m'est venue, si ça s'trouve ça n'a aucun intérêt donc je me suis dit que les journaux étaient plus adaptés.
# Pipe ?
Posté par Christophe B. (site web personnel) . Évalué à 9.
ssh fonctionne avec le pipe |
Exemple :
cat un_fichier | ssh user@machine_distante 'cat > /tmp/un_fichier'
Cela permet de faire plein de choses … des sauvegardes, des copies de disques sur une autre machine …
Mais les données ne transitent qu'une seule fois sur le réseau.
Par contre dans ce que tu cherches, le gain n'est pas forcément évident car pour traiter des données présentent sur une machine il faut bien les transférer dans un sens puis les rapatrier après traitement.
Bref tu va ajouter a ton temps de traitement, le temps du transfert dans les 2 sens.
Autant installer la commande sur la machine en question … surtout si il ya du volume
Même si il m'est arrivé de faire des trucs limites, mais cela venait du fait que les machines étaient très très vieille et je ne voulais rapatrier que le résultat de la commande.
un truc du style :
cat requete.sql | ssh user@serveur "sqlplus user/password@BDD 2>&1" >fichier_log
En gros cela me permet d'executer un fichier de requete sql, à travers SSH et de récuperer en local le log d'execution.
Dans l'exemple c'est sqlplus d'oracle mais c'est valable aussi pour mysql et certainement beaucoup d'autres.
[^] # Re: Pipe ?
Posté par George_abitbol . Évalué à 8.
En fait ça fonctionne avec n'importe quelle commande pipable.
C'est d'ailleurs quelque chose qui m'a sauvé des heures (et des points de santé mentale) dans le passé en transférant des fichiers via tar+ssh au lieu de scp. Aujourd'hui, avec le binaire rsync disponible de manière standard sur la plupart des serveurs, l'intérêt serait plus limité. Ça peut rester pertinent quand la source et la destination sont distantes par exemple.
J'allais écrire que c'est dû à la compression et que ça fonctionne bien notamment pour des données faiblement compressées et/ou les connexions lentes, mais finalement après avoir fait des tests, il se trouve que le fait de compresser ou pas n'a pas une incidence majeure. Mais utiliser tar+ssh ou rsync est infiniment plus efficace que scp.
ssh+tar+gz > rsync > rsync -z > ssh+tar+zstd > ssh+tar > scp > scp -C
Je ne m'explique pas pourquoi scp (même compressé) est à ce point si lent par rapport à la concurrence (bien pire que dans ma mémoire) alors que c'est justement son job de faire transiter des données potentiellement volumiques.
Grosse déception pour zstd, mon nouveau jouet préféré qui met généralement une patée à tous les autres algorithmes de compression dans la majorité des situations.
Après, peut-être que le cas du kernel n'est pas très représentatif de ce que j'ai rencontré dans la vie.
Bref, tout ça pour dire que le pipe over SSH, dans plein de situations, c'est le bien. :)
[^] # Re: Pipe ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Je n'ai pas vraiment ressenti cette lenteur, mais SCp et SSh ne fonctionnent absolument pas de la même façon… Je ne me rappelle pas bien les détails d'implémentation, mais quand tu fais un tube avec SSh, tu ouvres un pseudo-terminal dont tu connectes l'entrée standard (donc tu envois ton flux exactement comme tu le balancerais si tu le tapais au clavier…) Par contre quand tu fais un SCp, en dessous tu établies un liaison client-serveur (si, si, et toutes les bécanes ayant un serveur
sshne permettent pas d'accepter duscp—comme c'est paquetagé dans OpenSSH utilisé par défaut dans beaucoup d'Unix, des BSD à Linux en passant par AIX— bah on s'en rend pas compte) comparable àcurl/lftp -c/ftpget/ftpput(c'est encore différent du sous-systèmesftpqui ressemble plus à duftpclassique et utilise un tout autre protocole) Ça fait un certain nombre d'opérations (vérifier et se positionner dans le répertoire cible, vraiment recréer les arborescence quand utilisé en mode récursif, afficher la progression, etc.)cet exemple est en fait comparable à ceci :
et là on voit que la plus grande rapidité apparente, en supposant qu'on ait eu les même protocoles et que les deux outils ne se partagent pas que le mode de transport, est due au fait que dans le premier cas on parallélise presque (la gestion des tubes fait qu'on n'attend pas que tout se fasse séquentiellement)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pipe ?
Posté par barmic 🦦 . Évalué à 5.
À noter d'ailleurs que scp est en cours de déprécation au profit de sftp (la commande scp elle est entrain de migrer vers sftp).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pipe ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
C'est pas vraiment une migration puisque les deux ont toujours existé et ne font pas vraiment la même chose. Mais il y a bien une déprécation pour des raisons techniques qui se résume en gros à : scp n'a aucun lien avec ssh (si ce n'est d'utiliser son tuyau, alors que sftp par contre utilise les mêmes bibliothèques) et cette implémentation bâtarde pose des soucis de sécurité et plus personne n'a la force de maintenir ça avec ce risque.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pipe ?
Posté par barmic 🦦 . Évalué à 3.
Je parle du fait que la commande scp ne va plus utiliser le protocole scp, mais sftp (parce que les gens sont habitué à la commande scp et que la commande sftp est affreuse - perso ça fait quelques temps que je proscrit scp au profit de rsync -).
Ça explique surtout pourquoi ils ne veulent pas le corriger. Le problème est bien décrit dans l'article tu peux exécuter une commande au travers de scp ce qui n'est pas possible avec sftp.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pipe ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah oui, j'avais pas tout suivi en effet. Au départ il était vraiment question de purement et simplement abandonner la commande scp (sauf si j'ai mal compris) ; ce qui a fait pas mal râler sur la toile (des gens qui ont du mal comprendre aussi).
Mais effectivement si la commande est préservée mais le protocole sous-jacent (scp) est remplacé par l'autre (sftp) ; alors t'as entièrement raison de parler de migration et c'est vraiment pas plus mal (on n'aura pas la compatibilité totale mais c'est beaucoup moins de casse et de changement d'outillage.) Tout à fait d'accord que c'est quasiment impossible de sanitizer le fonctionnement car on ne sait pas aisément distinguer une commande dangereuse d'un nom/chemin tordu mais légitime.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pipe ?
Posté par Big Pete . Évalué à 3.
scp est réputé bridé au niveau de ses buffers mémoire, ce qui l'empêcherai d'utiliser des fenêtre de transmission TCP suffisamment grande pour exploiter toute la bande passante disponible, ceci étant particulièrement sensible sur des latences enlevés (hors lan). peut-être que le fait d'utiliser un pipe sur ssh permetrai de contourner cette limitation ?
Il y a un patch assez connu d'openssh qui adresse ce probléme : hpn-ssh
Tout ceci commence à dater, il est bien possible que ça ne soit plus a l'ordre du jour. Mais au cas où …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Pipe ?
Posté par jben . Évalué à 3. Dernière modification le 23 mars 2021 à 12:31.
Je suis étonné de ton résultat. J'ai donc voulu tester.
Bref, moi je trouve (en triant par vitesse)
rsync -z>ssh+tar+gz>>rsync>ssh+tar.Le fait que
rsyncetssh+tarsoient dans un mouchoir de poche est normal (de même avec les versions compressées), et le fait que je trouve l'un avant l'autre ne me gène pas. Ce qui me gène c'est que tu trouve que la compression ne change rien pour rsync (ce qui peut être le cas si c'est le CPU qui est limitant), mais change beaucoup pour tar (donc le cpu n'est pas limitant).[^] # Re: Pipe ?
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 23 mars 2021 à 13:28.
Tout dépend de l'usage cpu des deux machines à l'instant t, la vitesse du lien entre les deux et la possibilité de compression offerte par le fichier d'origine. Ton test a été fait à partir d'un code source (compressable facilement) et aucune information n'est donnée sur le lien entre les deux machines, leur puissance et occupation.
Si tu envoies un tar dont l'essentiel du contenu en terme de volume est déjà fait de contenu compressé (fichier audio/video/image) entre deux serveurs bien chargés en terme de cpu via un lien 10GBit, il y a de fortes chances que la compression est un impact très léger voire nulle.
Si tu envoies du contenu facilement compressible entre deux machines dont le cpu n'est pas chargé via un wifi + adsl/fibre capée à quelques dizaines de MB/s c'est une autre histoire tu vas avoir un bénéfice important lié à la compression.
[^] # Re: Pipe ?
Posté par jben . Évalué à 2.
Tout à fait, mais tu ne réponds pas à la question initiale.
Le problème, c'est que pour George_abitbol la compression est très efficace pour tar, et ne l'est pas pour rsync, c'est incohérent. C'est le même source, la même machine de départ, la même machine de destination entre les différents essais, et à moins que la charge CPU change violement, les rapports de performance devraient être les mêmes. Et si la charge externe CPU change violement entre les tests, alors le test est mal conduit. C'est cette incohérence là qui me dérange.
[^] # Re: Pipe ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Concernant le
scp -C, on peut mentionner que le serveur peut refuser de faire la compression, même si le client le demande (option Compression de ssh_config/sshd_config).[^] # Re: Pipe ?
Posté par George_abitbol . Évalué à 1.
Après vérification, remote n'a pas d'option Compress définie dans le sshd_config. Et le man dit que c'est yes par défaut.
Dans le doute j'ai regardé aussi sur le serveur source (même si ça ne devrait rien changer à priori) et c'est la même chose.
[^] # Re: Pipe ?
Posté par George_abitbol . Évalué à 1. Dernière modification le 24 mars 2021 à 02:09.
Suite aux commentaires suggérant d'utiliser sftp plutôt que scp, j'ai lancé le même test avec la commande scp. Et, encore une fois, les résultats vont à l'encontre de ce que j'attendais. :)
(ça prend encore plus de temps que toutes les autres commandes).
Bref, je ne suis pas près d'arrêter rsync (en plus on peut reprendre au milieu d'un transfert).
[^] # Re: Pipe ?
Posté par wismerhill . Évalué à 2.
Attention, ton time tel que tu l'utilise ici mesure l'exécution de la commande echo, pas de sftp ou scp.
[^] # Re: Pipe ?
Posté par claudex . Évalué à 5.
Au vu temps affiché, je doute fortement. C'est une différence de comportement entre le binaire
timeet le builtintime(en tout cas dans bash). Ce dernier prends bien tout le pipeline et donc tient bien compte du sftp. Exemple (sous bash donc):(Ce n'est d'ailleurs pas le même
echopour les mêmes raisons)« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pipe ?
Posté par wismerhill . Évalué à 3.
Ah, effectivement, je ne savais pas que le time inclus dans bash prend en compte tout le pipeline, merci de l'info.
Au passage, la doc de bash indique qu'il s'agit d'un mot réservé, ce qui est encore un peu différent d'une buitin command.
# entrée et sortie standard
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 23 mars 2021 à 08:48.
Je t'invites à étudier le principe des pipes et des redirections vers l'entrée et la sortie standard avec les symboles '<' et '>'
Honnêtement il n'y a rien à faire de plus. Je ne vois pas ce que tu peux faire de plus que:
ssh mon_user@serveur_distant "ma_commande" <mon_fichier_entrée >mon_fichier_sortie
[^] # Re: entrée et sortie standard
Posté par Faya . Évalué à 4. Dernière modification le 23 mars 2021 à 15:06.
Je ne sais pas si ta commande fonctionnerait avec ffmpeg ou youtube-dl ou autres commandes qui ne lisent pas depuis l'entrée standard et n'écrivent pas non plus sur stdout. Il m'arrive d'utiliser les pipes et redirections oui, mais ça ne rentre pas vraiment pour moi dans la catégorie «plus "intégré", de plus intuitif.»
Par contre en cherchant un peu plus je vois que ffmpeg propose un flag dédié à l'utilisation des io standards (https://ffmpeg.org/ffmpeg-protocols.html#pipe). Ce que je veux faire nécessiterait sûrement un script dédié à chaque commande pour remettre les arguments à la bonne place donc.
Pourquoi je cherche ça ?
(me suis dit que j'étais ptêt dans un cas de http://xyproblem.info/)
L'entreprise de ma femme lui a fourni un Mac. Elle a régulièrement besoin de récupérer une vidéo youtube, compresser une vidéo, extraire le son d'une vidéo, convertir un ogg en mp3,… Sauf que je n'utilise pas de Mac et ne les connaît que très peu. En cherchant rapidement je trouverais sûrement comment lui fournir les outils que je connais mais je n'ai pas envie de les installer sur la machine de son entreprise (oui logiquement ils devraient s'en occuper pour elle mais ce n'est pas le cas). Donc je me disais qu'avec un VPS
elsewheresur lequel je lui mets ffmpeg/youtube-dl, elle pourrait faire ses manips depuis son Mac sans que je lui installe autre chose que mon scriptelsewhere. Et que ça pourrait également me servir pour monter automatiquement mes timelapses avec les prises de vue réalisées par mon Raspberry sans mettre ffmpeg dessus. Et que si j'ai trouvé 2 besoins dans mon foyer, je n'étais peut-être pas le seul.Mais je veux bien entendre que c'est quelque chose d'assez spécifique donc pas d'outil existant.
[^] # Re: entrée et sortie standard
Posté par George_abitbol . Évalué à 2.
Dans le cas de youtube-dl, il n'y a pas d'installation à proprement parler (à moins de passer par le système de packages de ta distrib).
Il suffit de faire un curl pour télécharger un binaire exécutable qui contient tout le code. Et l'éxécuter « sur place ».
https://ytdl-org.github.io/youtube-dl/download.html
[^] # Re: entrée et sortie standard
Posté par Psychofox (Mastodon) . Évalué à -1.
HORRIBLE DE COMPLEXITE :
ssh user@remote "dd of=/tmp/input.avi && ffmpeg -i /tmp/input.avi /tmp/output.avi && dd if=/tmp/output.avi" localoutput.avi
Et si tu veux un truc plus user friendly, ben tu écrits un petit script bash qui va prendre pour argument le user et la machine distante, le chemin temporaire distant, le fichier d'entrée et sortie locaux et qui possiblement vérifie la taille disponible sur la machine distante.
Ce n'est pas bien compliqué.
[^] # Re: entrée et sortie standard
Posté par Faya . Évalué à 5. Dernière modification le 23 mars 2021 à 17:09.
What the !? On est arrivés bien vite aux sarcasmes, pourtant si tu lis le commentaire tu verras que je conclus comme toi qu'il me faudrait un script adapté à chaque commande et qu'il est sûrement normal que ça n'existe pas déjà. (Sans compter que oui pour la personne à qui je la destine cette commande est horrible de complexité). Bon ben merci et bonne journée…
[^] # Re: entrée et sortie standard
Posté par Psychofox (Mastodon) . Évalué à 2.
nan mais t'emballes ça dans un script et zou la personne de destination ne voit rien. Il n'y a pas moyen de faire des trucs façon nautilus script sur un mac?
De toutes façon t'as pas vraiment besoin d'outil distant pour ça, ffmpeg doit bien être dispo sur mac (via brew?). Tu lui fais juste un script bash simple qui fait ce que tu veux et pas besoin de machine distante.
Et si tu avais vraiment besoin de puissance via un vps c'est surement plus facile que tu aies un démon qui check un répertoire d'entrée (via lsyncd ou un cron), qui encode/decode/extrait automatiquement et pose ça dans un répertoire de destination. Et là ta femme via un point de montage pose son fichier et a juste à attendre que le fichier extrait apparaisse.
[^] # Re: entrée et sortie standard
Posté par Christophe B. (site web personnel) . Évalué à 2.
Oui je croyais qu'un mac c'était aussi un Unix ?
ya plus de shell ni de terminal ?
[^] # Re: entrée et sortie standard
Posté par Faya . Évalué à 4.
Oui il y a. Mais j'ai précisé que
- je ne connais pas particulièrement
- c'est une machine professionnelle, qui n'est pas à moi et ne m'a pas été confiée, pas envie de me lancer dans des bidouilles et installations dessus
À l'origine je demandais si il y avait quelque chose d'existant. Si je scripte moi même j'y arriverai c'est sûr (cradement peut-être mais je saurai trouver). Comme j'ai vu l'outil
outrunprésenté, je me demandais si il existait qqchose faisant l'opération inverse.[^] # Re: entrée et sortie standard
Posté par groumly . Évalué à 3.
Si c’est juste pour compresser, transcoder ou extraire le son d’une vidéo, QuickTime fait ça pas trop mal, et vient de base sur un mac. Je m’en sert pour convertir des DJ set récuperés sur YouTube en aac. C’est pas bien compliqué à utiliser, ouvre le fichier, file > export.
je suis pas sur que QuickTime supporte l’ogg par contre.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: entrée et sortie standard
Posté par barmic 🦦 . Évalué à 3.
Tu le ferrais probablement. Le passage sur la machine distante ne sera pas gratuit et faire des expérimentations autour de ffmpeg seront plutôt relou. Au final tu convergera probablement vers quelques cas d'utilisation (éventuellement paramétré) et passer par un script pour chacun est une manière de simplifier.
Sinon comme tu n'aura de toute manière pas d'autocomplétion, tu peux faire un script générique qui prend la commande ffmpeg et remplace les input/ouput.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Nix, partiellement
Posté par Guillaum (site web personnel) . Évalué à 2.
Si tu ne veux pas "installer" le cli, mais que cela peut tourner en local, tu peux utiliser
nix:Cela n'impacte pas ton système (enfin si, un peu de place disque, les programmes étant gardés en cache), et
ffmpegne sera plus disponible à la fin de la commande.À partir de ce moment tu dois pouvoir le combiner avec
outrun, même si je n'ai aucune idée de comment celui-ci fonctionne et que j'ai peur des cas particuliers.# Docker ?
Posté par Yves (site web personnel) . Évalué à 1.
Bon, ma réponse ne me satisfait que partiellement… mais voici le raisonnement :
Tu n'as pas la commande localement, mais pour l'exécuter sur ton CPU, pas de miracle : il faut que son code machine soit lisible localement (donc rapatrié) et linkable/exécutable (c'est à dire disposant de ses dépendances).
En théorie, un conteneur dédié audit programme devrait convenir, et correspond très exactement à ce besoin s'il se limite à avoir la commande et ses dépendances, s'appuyant sur le kernel local.
En pratique, les conteneurs ont malheureusement tendance à embarquer quasiment un OS complet 😞
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.