Journal Lancer un logiciel distant depuis sa machine

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
12
22
mar.
2021

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  (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  . Évalué à 8.

      Dans l'exemple c'est sqlplus d'oracle mais c'est valable aussi pour mysql et certainement beaucoup d'autres.

      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.

      # tar
      time tar -cf - linux-5.12-rc4/ | ssh remote 'tar -xf -'
      real    2m7.831s
      user    0m11.867s
      sys     0m5.186s
      
      # tar + gzip
      time tar -czf - linux-5.12-rc4/ | ssh remote 'tar -xzf -'
      real    1m49.364s
      user    0m44.098s
      sys     0m2.950s
      
      # tar + zstd    
      time tar --zstd -cf - linux-5.12-rc4/ | ssh remote 'tar --zstd -xf -'
      real    2m3.291s
      user    0m10.835s
      sys     0m3.075s
      
      # scp    
      time scp -qr linux-5.12-rc4/ remote:~/
      real    7m16.495s
      user    0m25.576s
      sys     0m33.962s
      
      
      # scp compressé
      time scp -qrC linux-5.12-rc4/ remote:~/
      real    7m33.949s
      user    1m43.966s
      sys     0m28.784s
      
      # rsync
      time rsync -a linux-5.12-rc4/ remote:~/linux-5.12-rc4/
      real    1m56.337s
      user    0m18.617s
      sys     0m5.389s
      
      # rsync compressé
      time rsync -az linux-5.12-rc4/ remote:~/linux-5.12-rc4/
      real    1m56.317s
      user    0m41.096s
      sys     0m1.871s
      

      Bref, tout ça pour dire que le pipe over SSH, dans plein de situations, c'est le bien. :)

      • [^] # Re: Pipe ?

        Posté par  . Évalué à 5.

        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.

        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 ssh ne permettent pas d'accepter du scp —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ème sftp qui ressemble plus à du ftp classique 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.)

        tar -czf - linux-5.12-rc4/ | ssh remote 'tar -xzf -'

        cet exemple est en fait comparable à ceci :

        # il faut helas preparer le fichier avant car scp ne lit pas stdin
        tar -czf foo.tgz linux-5.12-rc4/ 
        # puis l'envoyer separement 
        scp foo.tgz remote:./ ; rm foo.tgz
        # et en face l'extraire car il n'exploite pas stdout
        tar -xzf foo.tgz ; rm foo.tgz

        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  . É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  . É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  . Évalué à 3.

              C'est pas vraiment une migration puisque les deux ont toujours existé et ne font pas vraiment la même chose.

              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 -).

              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.

              Ç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  . É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  . É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  . Évalué à 3. Dernière modification le 23/03/21 à 12:31.

        Je suis étonné de ton résultat. J'ai donc voulu tester.

        jben@germaine /tmp $ time tar c linux-5.12-rc4 | ssh remote 'tar x' 
        0.30user 1.18system 1:31.22elapsed 1%CPU (0avgtext+0avgdata 3696maxresident)k
        880inputs+0outputs (7major+264minor)pagefaults 0swaps
        
        jben@germaine /tmp $ time tar cz linux-5.12-rc4 | ssh remote 'tar xz'
        22.69user 1.07system 0:22.73elapsed 104%CPU (0avgtext+0avgdata 3532maxresident)k
        0inputs+0outputs (0major+550minor)pagefaults 0swaps
        
        jben@germaine /tmp $ time rsync -a linux-5.12-rc4 remote:
        1.96user 1.50system 1:26.94elapsed 3%CPU (0avgtext+0avgdata 34996maxresident)k
        1043928inputs+0outputs (1major+10494minor)pagefaults 0swaps
        
        jben@germaine /tmp $ time rsync -az linux-5.12-rc4 remote:
        18.92user 0.55system 0:20.28elapsed 96%CPU (0avgtext+0avgdata 38012maxresident)k
        5128inputs+0outputs (1major+9494minor)pagefaults 0swaps
        

        Bref, moi je trouve (en triant par vitesse) rsync -z > ssh+tar+gz >> rsync > ssh+tar.

        Le fait que rsync et ssh+tar soient 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  . Évalué à 2. Dernière modification le 23/03/21 à 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  . É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  (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  . É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  . Évalué à 1. Dernière modification le 24/03/21 à 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).

        $ time echo put linux-5.12-rc4 | sftp -qr remote > /dev/null

        real 9m52.997s
        user 0m37.008s
        sys 1m2.285s

        $ time echo put linux-5.12-rc4 | sftp -Cqr remote > /dev/null

        real 9m44.989s
        user 1m59.671s
        sys 0m49.170s

        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  . É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  . Évalué à 5.

            Au vu temps affiché, je doute fortement. C'est une différence de comportement entre le binaire time et le builtin time (en tout cas dans bash). Ce dernier prends bien tout le pipeline et donc tient bien compte du sftp. Exemple (sous bash donc):

            $ time echo test | sleep 10
            
            real    0m10.007s
            user    0m0.002s
            sys     0m0.000s
            
            $ /bin/time echo test | sleep 10
            0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 1808maxresident)k
            80inputs+0outputs (2major+83minor)pagefaults 0swaps
            

            (Ce n'est d'ailleurs pas le même echo pour les mêmes raisons)

            $ time echo --version
            --version
            
            real    0m0.000s
            user    0m0.000s
            sys     0m0.000s
            
            $ /bin/time echo --version
            echo (GNU coreutils) 8.30
            Copyright (C) 2018 Free Software Foundation, Inc.
            License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
            This is free software: you are free to change and redistribute it.
            There is NO WARRANTY, to the extent permitted by law.
            
            Written by Brian Fox and Chet Ramey.
            0.00user 0.00system 0:00.00elapsed ?%CPU (0avgtext+0avgdata 1948maxresident)k
            0inputs+0outputs (0major+86minor)pagefaults 0swaps
            

            « 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  . É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  . Évalué à 7. Dernière modification le 23/03/21 à 08:48.

    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 ?

    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  . Évalué à 4. Dernière modification le 23/03/21 à 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 elsewhere sur lequel je lui mets ffmpeg/youtube-dl, elle pourrait faire ses manips depuis son Mac sans que je lui installe autre chose que mon script elsewhere. 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  . É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  . Évalué à -1.

        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.»

        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  . Évalué à 5. Dernière modification le 23/03/21 à 17:09.

          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

          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  . É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  (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  . É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 outrun présenté, je me demandais si il existait qqchose faisant l'opération inverse.

      • [^] # Re: entrée et sortie standard

        Posté par  . É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  . Évalué à 3.

        Ce que je veux faire nécessiterait sûrement un script dédié à chaque commande pour remettre les arguments à la bonne place donc.

        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  (site Web personnel) . Évalué à 2.

    Si tu ne veux pas "installer" le cli, mais que cela peut tourner en local, tu peux utiliser nix:

    $ nix run nixpkgs.ffmpeg -c ffmpeg --help
    ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
    [...]
    

    Cela n'impacte pas ton système (enfin si, un peu de place disque, les programmes étant gardés en cache), et ffmpeg ne 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  (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.