Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL.
D'autre part j'aime à télécharger mes logiciels et mises à jour sur
versiontracker ou autre.
Comme celles-ci sont parfois très lourdes j'aimerais pour les plus
lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC
(oui/non?).
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est
assez abscont pour moi.
Une solution intermédaire serait de pouvoir rediriger les
téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans
qu'il passe par mon ibook évidemment. Ou encore de pouvoir lancer à
distance le navigateur du G4 de bureau sur mon ibook en espérant que les
downloads iraient sur le bureau du G4 de bureau.
Lesquelles de ces solutions ou autres sont faisables ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Schmurtz
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL. D'autre part j'aime à télécharger mes logiciels et mises à jour sur versiontracker ou autre. Comme celles-ci sont parfois très lourdes j'aimerais pour les plus lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC (oui/non?).
oui (pour la lenteur).
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ¦uvre.
"ssh " pour te connecter à distance. Puis tu lances curl :
curl -O http:// curl -O ftp://
fais attention, en http, il n'affiche aucune erreur si le lien est faux : il télécharge le message d'erreur.
Tu peux aussi lancer un screen juste après la connexion ssh afin de pouvoir fermer la connexion ssh avant que le téléchargement soit fini. Lancer screen : screen Voir la liste des screens actifs : screen -list Récupérer un screen détaché : screen -r Détacher le screen courant : ctrl-A ctrl-D Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C Naviguer entre les screens ouverts : ctrl-A ctrl-N
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après, je ne sais pas quel client le gère.
-- Schmurtz
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL.
D'autre part j'aime à télécharger mes logiciels et mises à jour sur
versiontracker ou autre.
Comme celles-ci sont parfois très lourdes j'aimerais pour les plus
lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC
(oui/non?).
oui (pour la lenteur).
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est
assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ¦uvre.
"ssh tonlogin@tamachine" pour te connecter à distance. Puis tu lances
curl :
curl -O http://
curl -O ftp://
fais attention, en http, il n'affiche aucune erreur si le lien est
faux : il télécharge le message d'erreur.
Tu peux aussi lancer un screen juste après la connexion ssh afin de
pouvoir fermer la connexion ssh avant que le téléchargement soit fini.
Lancer screen : screen
Voir la liste des screens actifs : screen -list
Récupérer un screen détaché : screen -r
Détacher le screen courant : ctrl-A ctrl-D
Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C
Naviguer entre les screens ouverts : ctrl-A ctrl-N
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la
liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les
téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans
qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après,
je ne sais pas quel client le gère.
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL. D'autre part j'aime à télécharger mes logiciels et mises à jour sur versiontracker ou autre. Comme celles-ci sont parfois très lourdes j'aimerais pour les plus lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC (oui/non?).
oui (pour la lenteur).
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ¦uvre.
"ssh " pour te connecter à distance. Puis tu lances curl :
curl -O http:// curl -O ftp://
fais attention, en http, il n'affiche aucune erreur si le lien est faux : il télécharge le message d'erreur.
Tu peux aussi lancer un screen juste après la connexion ssh afin de pouvoir fermer la connexion ssh avant que le téléchargement soit fini. Lancer screen : screen Voir la liste des screens actifs : screen -list Récupérer un screen détaché : screen -r Détacher le screen courant : ctrl-A ctrl-D Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C Naviguer entre les screens ouverts : ctrl-A ctrl-N
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après, je ne sais pas quel client le gère.
-- Schmurtz
mrfra.sanspub
Schmurtz wrote:
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ½uvre.
"ssh " pour te connecter à distance. Puis tu lances curl :
curl -O http://... curl -O ftp://...
Le pb c'et pour les liens de téléchargement non visibles dans le navigateur (javascript, lien dans une base de données php).
fais attention, en http, il n'affiche aucune erreur si le lien est faux : il télécharge le message d'erreur.
tantpis
Tu peux aussi lancer un screen juste après la connexion ssh afin de pouvoir fermer la connexion ssh avant que le téléchargement soit fini.
Oui c'est un peu le but effectivement
Lancer screen : screen Voir la liste des screens actifs : screen -list Récupérer un screen détaché : screen -r Détacher le screen courant : ctrl-A ctrl-D Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C Naviguer entre les screens ouverts : ctrl-A ctrl-N
Oula c'est compliqué. Y'a moyen d'automatiser tout ça une fois pour toutes ?
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après, je ne sais pas quel client le gère.
L'intérêt est évidemment que les données se téléchargeant ne passent pas par la machine intermédiaire... -- Fra
Schmurtz <moi@ici.com> wrote:
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est
assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ½uvre.
"ssh tonlogin@tamachine" pour te connecter à distance. Puis tu lances
curl :
curl -O http://...
curl -O ftp://...
Le pb c'et pour les liens de téléchargement non visibles dans le
navigateur (javascript, lien dans une base de données php).
fais attention, en http, il n'affiche aucune erreur si le lien est
faux : il télécharge le message d'erreur.
tantpis
Tu peux aussi lancer un screen juste après la connexion ssh afin de
pouvoir fermer la connexion ssh avant que le téléchargement soit fini.
Oui c'est un peu le but effectivement
Lancer screen : screen
Voir la liste des screens actifs : screen -list
Récupérer un screen détaché : screen -r
Détacher le screen courant : ctrl-A ctrl-D
Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C
Naviguer entre les screens ouverts : ctrl-A ctrl-N
Oula c'est compliqué. Y'a moyen d'automatiser tout ça une fois pour
toutes ?
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la
liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les
téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans
qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après,
je ne sais pas quel client le gère.
L'intérêt est évidemment que les données se téléchargeant ne passent pas
par la machine intermédiaire...
--
Fra
J'ai pensé à ssh et curl (je ne sais pas si c'est possible) mais c'est assez abscont pour moi.
C'est pourtant ce qu'il y a de plus simple à mettre en ½uvre.
"ssh " pour te connecter à distance. Puis tu lances curl :
curl -O http://... curl -O ftp://...
Le pb c'et pour les liens de téléchargement non visibles dans le navigateur (javascript, lien dans une base de données php).
fais attention, en http, il n'affiche aucune erreur si le lien est faux : il télécharge le message d'erreur.
tantpis
Tu peux aussi lancer un screen juste après la connexion ssh afin de pouvoir fermer la connexion ssh avant que le téléchargement soit fini.
Oui c'est un peu le but effectivement
Lancer screen : screen Voir la liste des screens actifs : screen -list Récupérer un screen détaché : screen -r Détacher le screen courant : ctrl-A ctrl-D Créer un nouveau screen depuis un screen existant : ctrl-A ctrl-C Naviguer entre les screens ouverts : ctrl-A ctrl-N
Oula c'est compliqué. Y'a moyen d'automatiser tout ça une fois pour toutes ?
Ça permet aussi d'éviter une fermeture de shell due à une coupure de la liaison RTC.
Une solution intermédaire serait de pouvoir rediriger les téléchargements vers un serveur ftp (ou autre) sur mon G4 de bureau sans qu'il passe par mon ibook évidemment.
C'est faisable avec un serveur ftp sur la machine de destination. Après, je ne sais pas quel client le gère.
L'intérêt est évidemment que les données se téléchargeant ne passent pas par la machine intermédiaire... -- Fra
cfranco
Fra wrote:
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL. D'autre part j'aime à télécharger mes logiciels et mises à jour sur versiontracker ou autre. Comme celles-ci sont parfois très lourdes j'aimerais pour les plus lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC (oui/non?).
Ca va être affreux. Timbuktu le faisait jadis, mais sous MacOS X j'ai comme un doute.
Il y a un truc qui marche très bien pour ce genre de configurations, c'est eMule avec son interface de gestion des téléchargements à distance via web (il a un serveur web interne, il suffit de se connecter sur le port 80 de la machine sur laquelle il est installé et on peut tout contrôler sous forme de pages web, nettement plus légères à transférer)
Inconvénients : - c'est eMule... - à ma connaissance, ça ne marche que sous Windows
Mais c'est vrai que le même concept appliqué à n'importe quel téléchargement (en gros, une interface web pour piloter des wget sur une machine distante) ferait l'affaire. Je sais qu'il y a des interfaces web installables sous linux pour piloter des serveurs distants, non pas avec un truc comme VNC pour en afficher l'écran, mais avec des commandes d'administration pré-programmées pour lancer des commandes sur la machine distante. J'ai déjà utilisé celles fournies en standard sur les serveurs Cobalt, mais je sais qu'il existe des équivalents libres. Si c'est le cas, c'est pas impossible qu'ils soient installables sous MacOS X.
En tout cas, si ça n'existe pas, ça serait un truc surement utile à développer...
-- Christophe Franco
Fra <mrfra.sanspub@free.fr> wrote:
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL.
D'autre part j'aime à télécharger mes logiciels et mises à jour sur
versiontracker ou autre.
Comme celles-ci sont parfois très lourdes j'aimerais pour les plus
lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC
(oui/non?).
Ca va être affreux. Timbuktu le faisait jadis, mais sous MacOS X j'ai
comme un doute.
Il y a un truc qui marche très bien pour ce genre de configurations,
c'est eMule avec son interface de gestion des téléchargements à distance
via web (il a un serveur web interne, il suffit de se connecter sur le
port 80 de la machine sur laquelle il est installé et on peut tout
contrôler sous forme de pages web, nettement plus légères à transférer)
Inconvénients :
- c'est eMule...
- à ma connaissance, ça ne marche que sous Windows
Mais c'est vrai que le même concept appliqué à n'importe quel
téléchargement (en gros, une interface web pour piloter des wget sur une
machine distante) ferait l'affaire. Je sais qu'il y a des interfaces web
installables sous linux pour piloter des serveurs distants, non pas avec
un truc comme VNC pour en afficher l'écran, mais avec des commandes
d'administration pré-programmées pour lancer des commandes sur la
machine distante. J'ai déjà utilisé celles fournies en standard sur les
serveurs Cobalt, mais je sais qu'il existe des équivalents libres. Si
c'est le cas, c'est pas impossible qu'ils soient installables sous MacOS
X.
En tout cas, si ça n'existe pas, ça serait un truc surement utile à
développer...
Je suis les soirs de semaine dans un coin où il n'y a pas l'ADSL. D'autre part j'aime à télécharger mes logiciels et mises à jour sur versiontracker ou autre. Comme celles-ci sont parfois très lourdes j'aimerais pour les plus lourdes pouvoir plutôt les envoyer sur mon G4 de bureau sur ADSL.
J'ai pensé à VNC mais ça risque d'être rédhibitoire comme lenteur en RTC (oui/non?).
Ca va être affreux. Timbuktu le faisait jadis, mais sous MacOS X j'ai comme un doute.
Il y a un truc qui marche très bien pour ce genre de configurations, c'est eMule avec son interface de gestion des téléchargements à distance via web (il a un serveur web interne, il suffit de se connecter sur le port 80 de la machine sur laquelle il est installé et on peut tout contrôler sous forme de pages web, nettement plus légères à transférer)
Inconvénients : - c'est eMule... - à ma connaissance, ça ne marche que sous Windows
Mais c'est vrai que le même concept appliqué à n'importe quel téléchargement (en gros, une interface web pour piloter des wget sur une machine distante) ferait l'affaire. Je sais qu'il y a des interfaces web installables sous linux pour piloter des serveurs distants, non pas avec un truc comme VNC pour en afficher l'écran, mais avec des commandes d'administration pré-programmées pour lancer des commandes sur la machine distante. J'ai déjà utilisé celles fournies en standard sur les serveurs Cobalt, mais je sais qu'il existe des équivalents libres. Si c'est le cas, c'est pas impossible qu'ils soient installables sous MacOS X.
En tout cas, si ça n'existe pas, ça serait un truc surement utile à développer...
-- Christophe Franco
mrfra.sanspub
Christophe Franco wrote:
Il y a un truc qui marche très bien pour ce genre de configurations, c'est eMule avec son interface de gestion des téléchargements à distance via web (il a un serveur web interne, il suffit de se connecter sur le port 80 de la machine sur laquelle il est installé et on peut tout contrôler sous forme de pages web, nettement plus légères à transférer)
C'est que pour du P2P de toutes façons non ? Pas pour des téléchargements sur le web ? -- Fra
Christophe Franco <cfranco@pobox.com> wrote:
Il y a un truc qui marche très bien pour ce genre de configurations,
c'est eMule avec son interface de gestion des téléchargements à distance
via web (il a un serveur web interne, il suffit de se connecter sur le
port 80 de la machine sur laquelle il est installé et on peut tout
contrôler sous forme de pages web, nettement plus légères à transférer)
C'est que pour du P2P de toutes façons non ? Pas pour des
téléchargements sur le web ?
--
Fra
Il y a un truc qui marche très bien pour ce genre de configurations, c'est eMule avec son interface de gestion des téléchargements à distance via web (il a un serveur web interne, il suffit de se connecter sur le port 80 de la machine sur laquelle il est installé et on peut tout contrôler sous forme de pages web, nettement plus légères à transférer)
C'est que pour du P2P de toutes façons non ? Pas pour des téléchargements sur le web ? -- Fra
mrfra.sanspub
Xavier wrote:
En vacances en ADSL, c'est plus lent, mais ça reste faisable.
sans adsl tu veux dire? lent comment?
Et si le fichier ne se rapatrie que par un script php, c'est ça, ou bien lynx (mieux : links) dans un screen dans un ssh
Dis m'en plus. links est un browser de terminal en mode texte ? -- Fra
Xavier <xavier@groumpf.org> wrote:
En vacances en ADSL, c'est plus lent, mais ça reste faisable.
sans adsl tu veux dire? lent comment?
Et si le fichier ne se rapatrie que par un script php, c'est ça, ou bien
lynx (mieux : links) dans un screen dans un ssh
Dis m'en plus. links est un browser de terminal en mode texte ?
--
Fra
En vacances en ADSL, c'est plus lent, mais ça reste faisable.
sans adsl tu veux dire? lent comment?
Et si le fichier ne se rapatrie que par un script php, c'est ça, ou bien lynx (mieux : links) dans un screen dans un ssh
Dis m'en plus. links est un browser de terminal en mode texte ? -- Fra
mrfra.sanspub
Xavier wrote:
Ben, ça reste utilisable, mais vaut mieux un 1024*768 en face qu'un 1600*1200
C'est du 1280 en face mais le pb c'est que ibook c'est du 1024 pour le visualiser
Les scrolls de texte en particulier sont un peu pénibles.
Dis m'en plus. links est un browser de terminal en mode texte ?
Un browser tout court. Ca marche dans un terminal [...]
J'ai téléchargé et installé links mais si je tape links dans le terminal ça se lance pas (Command not found ; même si je me place dans le dossier d'install usr/local/bin). -- Fra
Xavier <xavier@groumpf.org> wrote:
Ben, ça reste utilisable, mais vaut mieux un 1024*768 en face qu'un
1600*1200
C'est du 1280 en face mais le pb c'est que ibook c'est du 1024 pour le
visualiser
Les scrolls de texte en particulier sont un peu pénibles.
Dis m'en plus. links est un browser de terminal en mode texte ?
Un browser tout court. Ca marche dans un terminal [...]
J'ai téléchargé et installé links mais si je tape links dans le terminal
ça se lance pas (Command not found ; même si je me place dans le dossier
d'install usr/local/bin).
--
Fra
Ben, ça reste utilisable, mais vaut mieux un 1024*768 en face qu'un 1600*1200
C'est du 1280 en face mais le pb c'est que ibook c'est du 1024 pour le visualiser
Les scrolls de texte en particulier sont un peu pénibles.
Dis m'en plus. links est un browser de terminal en mode texte ?
Un browser tout court. Ca marche dans un terminal [...]
J'ai téléchargé et installé links mais si je tape links dans le terminal ça se lance pas (Command not found ; même si je me place dans le dossier d'install usr/local/bin). -- Fra
