> 
> I would like to use SSH to login to a remote system, then using FTP,
> upload a file from the remote machine to another machine which will
> display the data. If I can automate this process, I think I'll be in
> great shape, tell me does this code seem like it would work for this?
> >use Net::SSH::Perl; 
> >my $ssh = Net::SSH::Perl->new($host);        #Logging into the remote machine
> 
> >$ssh->login; 
> >my($READ, $WRITE) = $ssh->open2($cmd); 
> >print $WRITE "cd /var/log\n";
> >print $WRITE "ftp\n";
> >print $WRITE "open $mainhost\n";             #FTP connecting to main
> web host to display the files.
> >print $WRITE "username\n";
> >print $WRITE "password\n"; 
> >print $WRITE "cd /central/storage/location\n";
> >print $WRITE "put filenamea\n";
> >print $WRITE "put filenameb\n";
> >print $WRITE "put filenamec\n";
> >print $WRITE "bye\n";                        #Disconnecting from the main web
> host
> >close($ssh);                                 #Disconnecting from the
> SSH host
> 

Does it work?  Best way to find out is to try it and see. 

'open2' isn't exactly well documented (read: not at all) which may or
may not be a reason to use or not to use it in the Net::SSH::Perl docs,
a cursory look at the source, assuming I understand (like you), that the
filehandles returned are actually attached to the STDOUT/STDIN of the
remote process rather than the SSH connection then it *should* work. Of
course you may run into nightmares with all kinds of things such as
whether or not the FTP client buffers input/output, whether or not it
will keep track of input thrown its way when it may not be ready, for
instance your SSH pipe is going to throw the username at the FTP client
regardless of whether your client has asked for it, same with the
password, commands, etc. So if your FTP client is stuck blocking waiting
for a response to connect to the remote location and you shove a
password down its throat I am not entirely sure how it will handle it,
it may work, it may cough up a fur ball.  Then there is the question of
catching and handling return codes and signals from the remote client,
aka what happens when the connection times out?

There are other options to explore as well, but most often the best way
to answer a question such as yours is to find a development environment
where you won't blow away anyone's production data and just give it a
shot.  I assume you can't 'scp' from remote server A to remote server B?
Can local server A connect directly to remote server B? 

Depending on your purposes and if this is production quality code I
would either a) test *a lot* b) look at other options...

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to