Eseguire un downloader via SSH ed eseguire un downloader locale tramite un proxy remoto collocano il download in luoghi diversi:

DisposizioneChi recupera il sito web?Dove viene scritto il file
Downloader locale tramite un proxy remotoIl client HTTP locale possiede la richiesta; il proxy la trasportaIl percorso di output del downloader locale
Downloader avviato via SSHUn programma sulla macchina remotaIl suo percorso remoto, a meno che i dati non vengano riportati esplicitamente

Con un account SSH autorizzato e curl installato in remoto, potete riportare l'artefatto sull'output standard:

ssh -T [email protected] 'curl --fail --silent --show-error https://downloads.example/file.bin' > file.part

Sostituite l'account e l'URL dell'esempio. La redirezione è fuori dal comando remoto tra virgolette, quindi la shell locale apre file.part. Se la mettete dentro il comando remoto, il percorso appartiene invece all'ambiente remoto.

Usate un percorso temporaneo nuovo: la shell locale può creare o troncare quel file prima che l'operazione remota riesca. Controllate il risultato di uscita di SSH e l'artefatto prima di dargli il nome definitivo.

L'output standard deve contenere solo i byte dell'artefatto. Saluti, banner di avanzamento o messaggi di wrapper possono corromperlo; la diagnostica appartiene all'errore standard. Un comando remoto che salva con il proprio nome di file potrebbe non restituire affatto byte. Preservate il risultato di uscita del downloader attraverso qualsiasi wrapper.

Potete invece salvare in remoto e trasferire il file con SFTP. Se SSH usa già un assistente proxy, riutilizzate quella voce host SSH per il trasferimento. Se l'obiettivo è un flusso di lavoro con proxy locale, tenete il downloader in locale e configurate la sua interfaccia proxy supportata.

In ogni caso, un file che deve raggiungere il vostro portatile deve ancora attraversare la sua connessione di rete. La scelta cambia la connessione verso il sito web e il processo che esegue il download.

Articoli correlati