ssh-sftp-perl-users — For users and developers of the Perl SSH and SFTP modules

[Ssh-sftp-perl-users] $ssh->cmd With multiple commands

[Eric L. S. <esa...@vt...>]

I have seen a couple of postings regarding this question; however, I could not 
find a clear answer or a working example in any of the postings.

I am using Net::SSH::Perl with identity keys.  I have validated connectivity 
and the successful execution of a command:

my (@sshout) = $ssh->cmd("ls");
foreach (@sshout) {
   print "$_";
}

What I would like to be able to do is open a connection to a given server and 
execute a series of commands, rather than open / close open / close etc. . .

Can this be done and if so is there a working example?

Thank you!
Eric

[Ssh-sftp-perl-users] Re: Problem with IO::Handle

[Larry F. <lf...@go...>]

Doh, I see now that there has already been a bug opened on this problem:
http://rt.cpan.org/NoAuth/Bug.html?id=3D11674

Anyone know a workaround for it? If not, I will continue to watch the bug.

Thanks,
Larry

On 4/15/05, Larry Fine <lf...@go...> wrote:
>=20
> Hello all,
>=20
> I am a new user of Net::SSH::Perl. I have installed it on some servers fo=
r=20
> the first time, and I am trying to get it up and running. Here's some=20
> basics:
>=20
> OS: RedHat Linux 9
> Perl: Summary of my perl5 (revision 5.0 version 8 subversion 0)=20
> configuration:
> Platform: osname=3Dlinux, osvers=3D2.4.22, archname=3Di386-linux-thread-m=
ulti
> Net::SSH::Perl version 1.27
> IO::Handle version 1.21_00
>=20
> Essentially, I am having the same problem as described here:
> http://www.codecomments.com/message404300.html
>=20
> I am using the 4-line demo program from the POD to test:
> #!/usr/bin/perl -w
> use Net::SSH::Perl;
> my $ssh =3D Net::SSH::Perl->new('rastaman');
> $ssh->login('theuser');
> my($stdout, $stderr, $exit) =3D $ssh->cmd('ls');
>=20
> The output is:
> Can't locate object method "blocking" via package "IO::Handle" at=20
> /usr/lib/perl5/site_perl/5.8.0/Net/SSH/Perl.pm line 212, <GEN0> line 1
>=20
> The line is is talking about is:
> defined($sock->blocking(0)) or die "Can't set socket non-blocking: $!";
>=20
> The version of IO::Handle I am using does in fact define blocking(), but =
I=20
> am unfamiliar with its proper usage and syntax.
>=20
> Anyone else run into this before? Any ideas?
>=20
> Thanks,
> Larry
>=20



--=20
"'Teenage Neofacist Skinheads Suffering From Progeria (That Rare Premature=
=20
Aging Disease) Play Mah-Jongg at a Swim Club in Lake Hayden, Idaho' ... is =
a=20
work that actually depicts, in delicate flecks of color, several peonies in=
=20
a vase." - Mark Leyner

[Ssh-sftp-perl-users] Problem with IO::Handle

[Larry F. <lf...@go...>]

Hello all,

I am a new user of Net::SSH::Perl. I have installed it on some servers for=
=20
the first time, and I am trying to get it up and running. Here's some=20
basics:

OS: RedHat Linux 9
Perl: Summary of my perl5 (revision 5.0 version 8 subversion 0)=20
configuration:
Platform: osname=3Dlinux, osvers=3D2.4.22, archname=3Di386-linux-thread-mul=
ti
Net::SSH::Perl version 1.27
IO::Handle version 1.21_00

Essentially, I am having the same problem as described here:
http://www.codecomments.com/message404300.html

I am using the 4-line demo program from the POD to test:
#!/usr/bin/perl -w
use Net::SSH::Perl;
my $ssh =3D Net::SSH::Perl->new('rastaman');
$ssh->login('theuser');
my($stdout, $stderr, $exit) =3D $ssh->cmd('ls');

The output is:
Can't locate object method "blocking" via package "IO::Handle" at=20
/usr/lib/perl5/site_perl/5.8.0/Net/SSH/Perl.pm line 212, <GEN0> line 1

The line is is talking about is:
defined($sock->blocking(0)) or die "Can't set socket non-blocking: $!";

The version of IO::Handle I am using does in fact define blocking(), but I=
=20
am unfamiliar with its proper usage and syntax.

Anyone else run into this before? Any ideas?

Thanks,
Larry

Re: [Ssh-sftp-perl-users] bind socket problem

[<gd...@te...>]

Robert Landrum wrote:

> > my question is, how can I unbind the socket used by
> > Net::SSH::Perl ?
>
>
>  Don't bother... Use fork. When the child process exits, the
>  socket will (err... should) unbind. You might have to figure out
>  how you're going to handle saving stdout, err, etc. I'd probably
>  just write them to a log...
>
I made a stripped version of my script, so that it reflects the
problem. I added your suggestions there, but the problem remain, I
still have a

Net::SSH: Can't bind socket to port 1023: Adresse déjà utilisée at
./test_ssh.pl line 46

message after the second run in the loop
here is the full script :

use strict;
use Net::Ping;
use Net::SSH::Perl;

my ($p,$stout,$sterr,$exit,$cmd);
my (@errping);

open HOSTS, "hosts" or die "je n'ai pas réussi à ouvrir le fichier
hosts!";

$p = Net::Ping->new("icmp");

my @ids = "$ENV{HOME}/.ssh/id_rsa";

my %params = (
        'protocol' => 2,
        'identity_files' => \@ids,
        'port' => 22,
        'debug' => 1,

);

while(<HOSTS>){

        next if(/^(#|\s+#|\n)/);
        chomp;

        # ping test

        unless ($p->ping($_)) {
                print "ip : $_ \nerreur : pas de ping \n\n";
                next;
                }


        #ssh connexion + wget

        print "téléchargement du fichier \n";
              
                 if (fork){
                        wait;
                }
                else{
                        my $ssh = Net::SSH::Perl->new($_, %params);
                        $ssh->login("root");
                        ($stout,$sterr,$exit) = $ssh->cmd("wget -q
http://www.google.com ");

                }
        }

        print "mise à jours des ipcops terminé\n";

Re: [Ssh-sftp-perl-users] bind socket problem

[Robert L. <rla...@ao...>]

On Thu, Apr 07, 2005 at 02:39:05PM +0200, guillaume dout=E9 wrote:
> Things work fine for the first host of the list. But can never get=20
> beyong that. I get a "Net::SSH: Can't bind socket to port 1023: Adresse=
=20
> d=E9j=E0 utilis=E9e at ./test_ssh.pl line 46" message.

I had a similar problem with apache and net::sftp.  I solved it by
forcing the connection closed in SFTP.pm.

> my question is, how can I unbind the socket used by Net::SSH::Perl ?

Don't bother...  Use fork.  When the child process exits, the socket
will (err...  should)  unbind.  You might have to figure out how you're
going to handle saving stdout, err, etc.  I'd probably just write them to=
=20
a log...

>=20
> here's part of my code:
>=20
> use strict;
> use Net::SSH::Perl;
>=20
> my ($patchurl,$stout,$sterr,$exit,$ssh);
> my @ids =3D "$ENV{HOME}/.ssh/id_rsa";
>=20
> my %params =3D (
>         'protocol' =3D> 2,
>         'identity_files' =3D> \@ids,
> );
>=20
> $patchurl =3D push @ARGV
>=20
> open HOSTS, "hosts" or die "je n'ai pas r=E9ussi =E0 ouvrir le fichier =
hosts=20
> : $!";
>=20
> while(<HOSTS>){
>=20
>         (...)

      if(fork) {
        # parent
        wait;
      }
      else {
        # child
>=20
>      $ssh =3D Net::SSH::Perl->new($_, %params);
>         $ssh->login("root");
>         ($stout,$sterr,$exit) =3D $ssh->cmd("wget -q $patchurl");
      }
>=20
>     (...)
> }

Good luck,

Rob
--=20
Robert Landrum
Systems Programmer

[Ssh-sftp-perl-users] bind socket problem

[<gd...@te...>]

hello,

I've been posting on nntp.perl.org in perl.beginners about a socket 
binding problem when trying to make several ssh connections on remote 
hosts, somebody told me about this list and suggested I should ask for 
your help. I'll copy&paste the discussion we had there

my original post :

I'm making a simple script that's supposed to update a certain number of 
boxes, spread around the area.
my script is supposed to to connect to every hosts (via a file named 
"hosts") using ssh, launch wget to retrieve the patch update, and 
install it.
Things work fine for the first host of the list. But can never get 
beyong that. I get a "Net::SSH: Can't bind socket to port 1023: Adresse 
déjà utilisée at ./test_ssh.pl line 46" message.

my question is, how can I unbind the socket used by Net::SSH::Perl ?

here's part of my code:

use strict;
use Net::SSH::Perl;

my ($patchurl,$stout,$sterr,$exit,$ssh);
my @ids = "$ENV{HOME}/.ssh/id_rsa";

my %params = (
        'protocol' => 2,
        'identity_files' => \@ids,
);

$patchurl = push @ARGV

open HOSTS, "hosts" or die "je n'ai pas réussi à ouvrir le fichier hosts 
: $!";

while(<HOSTS>){

        (...)

     $ssh = Net::SSH::Perl->new($_, %params);
        $ssh->login("root");
        ($stout,$sterr,$exit) = $ssh->cmd("wget -q $patchurl");

    (...)
}

responses :

John Doe wrote:

>> > I don't see the exact reason. But after having a look in the code
>> > (Perl.pm, sub _create_socket, which tries ports from 1023 down to 512 to
>> > bind to), maybe the ssh object is not destroyed between the loops. You
>> > could try:
>> >
>> > ** define $ssh as my variable within the loop (not outside as currently)
>> > ** put the code within the loop in a separate block, containing the
>> > my-Definition of $ssh
>> > ** use "undef $ssh" at the end of the loop (still within it of course)
>> > ** Insert some diagnostic code at the beginning of the loop that
>> > a) examines the $ssh object before the second "loop run" and/or
>> > b) sleeps for e.g. a minute, so that you can look whats happening with
>> > the bound port (netstat -neat from cmdline)
>> >
>> > I don't have the Modules installed, so I didn't made tests, sorry.
>> >
>> > joe
>  
>
>
> I tried some of your recommendations, like declaring $ssh in the loop
> and use "undef $ssh" at the end, but didn't solve the problem.
> I did use netstat -neat during, and after the script launch. I didn't
> see anything weird during the script running, I did see something
> bizarre after :
>
> tcp        0      0 192.168.0.3:1023        192.168.0.1:22
> TIME_WAIT  0          0
>
> that line, stayed there for at least a full minute before disappearing.
> So I decided to add a 2min sleep at the end of the loop... and to my
> surprise : IT WORKED!
> I used netstat during the 2min sleep, it seems that the connection to
> the 1023 socket lasts something between 1-2 minutes.
>
> It's weird, I wish there were another way around it. If anybody got an
> explanation or a better solution about this "socket bind for more than a
> minute, than just disappears" enigma, I'd be glad.


This phenomen with the TIME_WAIT was my other thought to explain the behavior 
of your script, but then I decided not to mention it because I thought that 
the sub _create_socket code in Perl.pm will handle this:

*---- code ----*
sub _create_socket {
    my $ssh = shift;
    my $sock = gensym;

 my ($p,$end,$delta) = (0,1,1); # normally we use whatever port we can get
       ($p,$end,$delta) = (1023,512,-1) if $ssh->{config}->get('privileged');

 # allow an explicit bind address
    my $addr = $ssh->{config}->get('bind_address');
 $addr = inet_aton($addr) if $addr;
 ($p,$end,$delta) = (10000,65535,1) if $addr and not $p;
 $addr ||= INADDR_ANY;

    for(; $p != $end; $p += $delta) {
        socket($sock, AF_INET, SOCK_STREAM, getprotobyname('tcp') || 0) ||
            croak "Net::SSH: Can't create socket: $!";
        last if not $p or bind($sock, sockaddr_in($p,$addr));
        if ($! =~ /Address already in use/i) {
            close($sock);
            next;
        }
        croak "Net::SSH: Can't bind socket to port $p: $!";
    }
 if($p) {
  $ssh->debug("Allocated local port $p.");
  $ssh->{config}->set('localport', $p);
 }

    $sock;
}

*--- code ---*

The code tries to bind to several ports (1023 down to 512).

But now, when I look again - but still not deeply enough!... (and use the hint 
the port 1023 was also tried in the _second_ "loop run")... the code seems 
only to handle the "port already in use" case...

Please look at the above code deeper... the croak code could be the problem, 
and a possibility could be not to croak so fast, but try port after port 
until binding has been done or the port range has fully be tested.

I could have a deeper look myself tomorrow ...äh... après-midi, if you wish 
(we're located in the same time zone I think).

btw - where are all the cracks who have the 
instant-shortestpossible-100%solution for all ???

greetings joe




Thanks for your help

[Ssh-sftp-perl-users] net::sftp (disconnect/channel open failure)

[<eri...@wa...>]

Hi!

I searched the Archives of this list and found a couple of similar items 
but no resolution so I thought I might post it myself.  I'm getting the 
below output when trying to connect to an OpenSSH box listening on port 
10022 using net::sftp.  What is happening when its trying to open channel 
1?

Any ideas??

Output
##########################

Starting
linux.local: Reading configuration data 
/home/#######/.ssh/config
linux.local: Reading configuration data /etc/ssh_config
linux.local: Connecting to xxxxxx.xxxxxxxx.com, port 10022.
linux.local: Remote protocol version 2.0, remote software version 
OpenSSH_3.7p1
linux.local: Net::SSH::Perl Version 1.27, protocol version 2.0.
linux.local: No compat match: OpenSSH_3.7p1.
linux.local: Connection established.
linux.local: Sent key-exchange init (KEXINIT), wait response.
linux.local: Algorithms, c->s: 3des-cbc hmac-sha1 none
linux.local: Algorithms, s->c: 3des-cbc hmac-sha1 none
linux.local: Entering Diffie-Hellman Group 1 key exchange.
linux.local: Sent DH public key, waiting for reply.
linux.local: Received host key, type 'ssh-dss'.
linux.local: Host 'xxxxxx.xxxxxxxx.com' is known and matches the host key.
linux.local: Computing shared secret key.
linux.local: Verifying server signature.
linux.local: Waiting for NEWKEYS message.
linux.local: Enabling incoming encryption/MAC/compression.
linux.local: Send NEWKEYS, enable outgoing encryption/MAC/compression.
linux.local: Sending request for user-authentication service.
linux.local: Service accepted: ssh-userauth.
linux.local: Trying empty user-authentication request.
linux.local: Authentication methods that can continue: 
publickey,password,keyboard-interactive.
linux.local: Next method to try is publickey.
linux.local: Trying pubkey authentication with key file 
'/home/#######/.ssh/id_dsa'
linux.local: Authentication methods that can continue: 
publickey,password,keyboard-interactive.
linux.local: Next method to try is publickey.
linux.local: Next method to try is password.
linux.local: Trying password authentication.
linux.local: Login completed, opening dummy shell channel.
linux.local: channel 0: new [client-session]
linux.local: Requesting channel_open for channel 0.
linux.local: channel 0: open confirm rwindow 0 rmax 32768
linux.local: Got channel open confirmation, requesting shell.
linux.local: Requesting service shell on channel 0.
linux.local: channel 1: new [client-session]
linux.local: Requesting channel_open for channel 1.
Received disconnect message: Unsupported request (shell).
  at /usr/lib/perl5/site_perl/5.8.5/Net/SSH/Perl/SSH2.pm line 281


Code
##########################

!/usr/bin/perl

use Net::SFTP;

print "Starting\n";

my %args = 
(user=>"########",password=>"########",debug=>"1",ssh_args=>[port=>10022]);

my $sftp = Net::SFTP->new("xxxxxx.xxxxxxxx.com", %args);

print $sftp->ls();

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

Mark Fuller wrote:

>From: "Ofer Nave" <on...@sh...>
>  
>
>>Yes, but perl code works well with other perl code.  If I have to use
>>the system function, it's the equivalent of building a model airplane
>>using a pair of salad tongs instead of your hands.  You can get some
>>stuff done, but it's a pain in the ass, and you're tactile feedback is
>>astonishingly limited.
>>    
>>
>
>I guess I still don't understand the significance of this as applied to
>Expect.pm driving an open-ssh sftp compiled executable. Expect.pm is Perl.
>So, it's my Perl code working well with another Perl code (which itself
>abstracts all the details about system calls and trapping the output). Why
>should I care that all this is happening beneath the covers (except for
>perhaps the performace issues of forking and pipe creation for interprocess
>communication)?
>
>To me that's a strength. I'm not interfacing directly to the sftp command.
>I'm interfacing to Expect.pm. I do Perl like I normally would. I don't have
>to think too much about what's happening. And, once I learn the Expect.pm
>heuristics, I can do the same thing with *anything*.
>  
>
How does Expect work?  It works by capturing the output of a command, 
and giving you useful mechanisms for parsing it and responding to it, 
right?  But you're still parsing the human readable output of a command 
line.  How can that be consider more reliable than depending on the 
documented behavior of a perl function or module?  The output can change 
at any time.  There are differences in system utiltities from OS to OS 
(the 'ps' command is a classic example).  If you get new mail you might 
get a "new mail arrived" line thrown in unexpectedly.  Expect is 
powerful and useful, but it is a hack.

-ofer

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Mark F. <mar...@ea...>]

From: "Ofer Nave" <on...@sh...>
> Yes, but perl code works well with other perl code.  If I have to use
> the system function, it's the equivalent of building a model airplane
> using a pair of salad tongs instead of your hands.  You can get some
> stuff done, but it's a pain in the ass, and you're tactile feedback is
> astonishingly limited.

I guess I still don't understand the significance of this as applied to
Expect.pm driving an open-ssh sftp compiled executable. Expect.pm is Perl.
So, it's my Perl code working well with another Perl code (which itself
abstracts all the details about system calls and trapping the output). Why
should I care that all this is happening beneath the covers (except for
perhaps the performace issues of forking and pipe creation for interprocess
communication)?

To me that's a strength. I'm not interfacing directly to the sftp command.
I'm interfacing to Expect.pm. I do Perl like I normally would. I don't have
to think too much about what's happening. And, once I learn the Expect.pm
heuristics, I can do the same thing with *anything*.

> >>returning complex data structures, like a native function can?
> >
> >I haven't needed that (yet). Can you give me an example of when returned
> >complex data structures would be useful?
> >
> Sure.  DBI.  Imagine having to use system() to call the 'isql' utility
> to run queries against Sybase and parse the output instead of using the
> DBI library.

Yes, I understand in the case of DBI (and it's rows and columns). But, in
the case of protocols like SFTP, FTP, Telnet, etc., when would this be of
value? That's what I was trying to ask.

> Does anyone else want to jump in and field these?  Or am I in the
> minority?  If I am, I'll shut up.

Sorry. I wasn't trying to challenge you. I just didn't understand why
Expect.pm would be a last resort (undesireable). I can see positives and
negatives involved with either way.

Mark

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

Mark Fuller wrote:

>From: "Ofer Nave" <on...@sh...>
>  
>
>>goes out the window the minute I have to
>>call system() and use a seperate executable (not to mention the fact
>>that you fork several times needlessly in the process).
>>    
>>
>
>Wouldn't the fact that you're executing a binary cancel out the overhead of
>the system call to use it (and the forks)? I haven't noticed a performance
>problem using Expect.pm to drive an sftp executable.
>
>  
>
You're right that the binary will be faster than a pure-perl 
implementation like Net::SSH::Perl once the code has started running.  
It doesn't "cancel" anything out cleanly, because the cost of forking is 
one constant, while the cost of a slower implementation is proportional 
to the amount of data you transfer.  But the cost of forking, and 
perhaps even the cost of a slower perl implementation, are both likely 
negligble relative to the latency of network communication.

However, the fork still does have a time cost that can add up, and it's 
harder on the OS (more task switching), and pollutes the process table, 
and is just plain ugly.  I have scripts that fork all over the place, 
but I do it when I have to, not when I have a choice. [1]

The best of both world would be a Net::SSH::XS module that wraps a C 
library - preferably whatever C library is already used by the ssh 
command (openssl?) so the same code doesn't have to be written twice.  
Native perl calls, C speed.  XSellent!

>>And what is my feedback?  An 8-bit integer, and maybe some STDOUT/STDERR
>>    
>>
>output that I
>  
>
>>have to capture and parse?
>>    
>>
>
>I was interrogating results in N::S::P too. Also, capturing all results
>(eval, die signal and accumulating messages in an array) wasn't exactly
>graceful either. :) I don't see the difference. Either way a person is
>probably going to want to test the results and make decisions, right?
>
>  
>
Yes, but perl code works well with other perl code.  If I have to use 
the system function, it's the equivalent of building a model airplane 
using a pair of salad tongs instead of your hands.  You can get some 
stuff done, but it's a pain in the ass, and you're tactile feedback is 
astonishingly limited.

>>returning complex data structures, like a native function can?
>>    
>>
>
>I haven't needed that (yet). Can you give me an example of when returned
>complex data structures would be useful?
>
>  
>
Sure.  DBI.  Imagine having to use system() to call the 'isql' utility 
to run queries against Sybase and parse the output instead of using the 
DBI library.

Oh god, I wish I hadn't said that.  I think I'm breaking out in hives now.

>>Or being able to throw execptions that are captured?
>>    
>>
>
>I'm not sure what you mean. If the open-ssh sftp binary encounters an error,
>Expect.pm captures this. It's available to me. Are there other exceptions?
>
>To me, the greatest benefits using Expect.pm are these three:
>
>1. I can drive any binary in *exactly* the same manner. I'm not forced to
>learn the peculiarities of every pure-perl interface. I'm probably going to
>learn the binary's peculiarities since that's how I would first develop the
>steps to connect and test every operation of the connection. Wrapping it
>with Expect.PM is just implementing what I learned executing the binary
>manually. That's seems simpler. It's like "what you see is what you get."
>
>2. Because I'm using the binary, if anything begins failing (in the distant
>future), it's relatively easy to execute the binary manually in order to
>discover what (in the process of connecting and navigating) has changed. The
>binary becomes an accessible reference point.
>
>3. The binary is probably better vetted, having seen greater usage. There's
>less chance of stumbling upon a bug or security risk.
>
>Off hand, the only thing I can think of for when a pure-perl interface would
>be better is if the client will execute on a variety of platforms. Then
>you'd only have to learn one peculiar interface rather than each vendor's
>binary. (FTP is an example of how different each vendor's binary could be).
>
>  
>
Does anyone else want to jump in and field these?  Or am I in the 
minority?  If I am, I'll shut up.

-ofer

[1] I lied.  I don't *have* to fork all the times that I do, but I'm too 
scared to learn multi-threaded programming.  :)

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Mark F. <mar...@ea...>]

From: "Ofer Nave" <on...@sh...>
> goes out the window the minute I have to
> call system() and use a seperate executable (not to mention the fact
> that you fork several times needlessly in the process).

Wouldn't the fact that you're executing a binary cancel out the overhead of
the system call to use it (and the forks)? I haven't noticed a performance
problem using Expect.pm to drive an sftp executable.

>And what is my feedback?  An 8-bit integer, and maybe some STDOUT/STDERR
output that I
> have to capture and parse?

I was interrogating results in N::S::P too. Also, capturing all results
(eval, die signal and accumulating messages in an array) wasn't exactly
graceful either. :) I don't see the difference. Either way a person is
probably going to want to test the results and make decisions, right?

> returning complex data structures, like a native function can?

I haven't needed that (yet). Can you give me an example of when returned
complex data structures would be useful?

>Or being able to throw execptions that are captured?

I'm not sure what you mean. If the open-ssh sftp binary encounters an error,
Expect.pm captures this. It's available to me. Are there other exceptions?

To me, the greatest benefits using Expect.pm are these three:

1. I can drive any binary in *exactly* the same manner. I'm not forced to
learn the peculiarities of every pure-perl interface. I'm probably going to
learn the binary's peculiarities since that's how I would first develop the
steps to connect and test every operation of the connection. Wrapping it
with Expect.PM is just implementing what I learned executing the binary
manually. That's seems simpler. It's like "what you see is what you get."

2. Because I'm using the binary, if anything begins failing (in the distant
future), it's relatively easy to execute the binary manually in order to
discover what (in the process of connecting and navigating) has changed. The
binary becomes an accessible reference point.

3. The binary is probably better vetted, having seen greater usage. There's
less chance of stumbling upon a bug or security risk.

Off hand, the only thing I can think of for when a pure-perl interface would
be better is if the client will execute on a variety of platforms. Then
you'd only have to learn one peculiar interface rather than each vendor's
binary. (FTP is an example of how different each vendor's binary could be).

Mark

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

Mark A. Fuller wrote:

>BTW: Earlier you said it was too bad that I had to do something outside of Perl. Why's that bad? What is the downside of using Expect.pm (a Perl module) to drive an executable module (like an open-ssh sftp module)? 
>
>  
>
Well, Expect is wonderful because in that it helps you when you're 
forced to drive an external app.  But it is a last line of defense.  
It's a hack.  I use perl because it is a powerful and expressive 
programming language.  All that goes out the window the minute I have to 
call system() and use a seperate executable (not to mention the fact 
that you fork several times needlessly in the process).  And what is my 
feedback?  An 8-bit integer, and maybe some STDOUT/STDERR output that I 
have to capture and parse?  How can you possibly compare that to the 
richness and elegance of returning complex data structures, like a 
native function can?  Or being able to throw execptions that are captured?

I only go outside perl when I have no choice.  And that is why I love 
Net::SSH::Perl. Native, pure-perl implementation of SSH.  Much needed 
and much appreciated.

-ofer

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Mark A. F. <mar...@ea...>]

From: "Mark A. Fuller" <mar...@ea...>
>I trapped the die signal in the eval and accumulated the messages in an array. 

I should have also said that I found it useful to accumulate messages in an array because it seemed like multiple die signals might be trapped within an eval of one method call. I found that I could end up with more than one message after the eval, when I detected that the die signal handler had been called. Sometimes the first message was more meaningful than the last.

BTW: Earlier you said it was too bad that I had to do something outside of Perl. Why's that bad? What is the downside of using Expect.pm (a Perl module) to drive an executable module (like an open-ssh sftp module)? 

It's slightly more complicated to code. A larger memory footprint?

The upside to me was that it was more "WYSIWYG." What I mean is, if I put something into production and it stopped working for some bizarre reason a year or two down the road, it was relatively straightforward to exercise the executable and verify what the driving process was encountering. With N:S:P, I found myself making a number of invalid assumptions about how my experience with the executable should be the expected experience with the Perl binding. Things got simpler for me when there was a one-to-one correlation between what I could do at the command line and via my script to automate the same connection.

I suppose psftp (the command-line emulator tool implementing N:S:P) might have alleviated my problem.

Another benefit, however is that once I went through the learning curve for Expect.pm I could apply it to *any* executable. I didn't have to learn the ins-and-outs of every Perl binding I might want to use. Or, trip over various shortcomings. The executables tend to see more widespread use and therefore the bugs are worked out. Using a single binding (Expect.pm) to drive all of them seemed like a more stable proposition *to me*. 

I'm not trying to evangelize anyone away from N:S:P. Just offering my own experience.

Mark

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Mark A. F. <mar...@ea...>]

From: Ofer Nave <on...@sh...>
>there isn't the slightest mention of error handling in the docs.  How do you tell when something didn't work, 
and how do you find out what went wrong?

I don't know if we're talking about the same thing, but I put all my method calls inside an eval. I trapped the die signal in the eval and accumulated the messages in an array. After the method call (more precisely, after the eval), I detected whether the die signal handler had been invoked, and I logged the collected messages, took remedial action (like retrying the operation), etc.

I posted samples of this a year or more ago. They should be in the archive.

Mark

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

I'm fine with wrapping all calls in eval.  I'm just confused why it 
doesn't mention that in the docs.  If it were a wiki, I'd add it myself.  :)

-ofer

Jacob Steinberger wrote:

> I subscribed to the list with the same question, which I managed to 
> figure out. Basically, wrap every single SSH::Perl command with eval 
> {}. It's worked out very well for me.
>
> Jacob
>
> Ofer Nave wrote:
>
>> As long as I'm here, I just wanted to say that while Net::SSH::Perl 
>> is a remarkable achievement that I will be eternally grateful fur, I 
>> continue to be baffled by the fact that there isn't the slightest 
>> mention of error handling in the docs.  How do you tell when 
>> something didn't work, and how do you find out what went wrong?
>>
>> If it was right in front of my nose and I missed it, tell me and I 
>> will stutter and apologize and embarassingly walk backwards out of 
>> the room.
>>
>> -ofer
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Ssh-sftp-perl-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/ssh-sftp-perl-users
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Ssh-sftp-perl-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/ssh-sftp-perl-users

Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Jacob S. <tre...@re...>]

I subscribed to the list with the same question, which I managed to 
figure out. Basically, wrap every single SSH::Perl command with eval {}. 
It's worked out very well for me.

Jacob

Ofer Nave wrote:
> As long as I'm here, I just wanted to say that while Net::SSH::Perl is a 
> remarkable achievement that I will be eternally grateful fur, I continue 
> to be baffled by the fact that there isn't the slightest mention of 
> error handling in the docs.  How do you tell when something didn't work, 
> and how do you find out what went wrong?
> 
> If it was right in front of my nose and I missed it, tell me and I will 
> stutter and apologize and embarassingly walk backwards out of the room.
> 
> -ofer
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Ssh-sftp-perl-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/ssh-sftp-perl-users
> 
> 

[Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

As long as I'm here, I just wanted to say that while Net::SSH::Perl is a 
remarkable achievement that I will be eternally grateful fur, I continue 
to be baffled by the fact that there isn't the slightest mention of 
error handling in the docs.  How do you tell when something didn't work, 
and how do you find out what went wrong?

If it was right in front of my nose and I missed it, tell me and I will 
stutter and apologize and embarassingly walk backwards out of the room.

-ofer

Re: [Ssh-sftp-perl-users] RE: Net::SFTP copying in 8192-byte chunks?

[Ofer N. <on...@sh...>]

Mark A. Fuller wrote:

>From: Daniel Werner <dan...@ds...>
>  
>
>>Is it possible that Net::SFTP (or possibly the underlying Net::SSH::Perl) just isn't good for transferring large files?  
>>    
>>
>
>I've not transferred large files. But, I remember someone posted a long time ago similar speed problems with large files.
>
>If it's a showstopper for you, you can also use Expect.pm to drive an sftp binary (compiled, openssh.org module) interactively. I posted an example a few months ago about how to get started with this.  It's a little more complicated. But, one benefit is that you're driving the same executable you can execute from the command line. If something doesn't work as expected, you can test directly with the module. 
>  
>
You can also try using SCP, which is yet another secure filte transfer 
protocol.  There is an Net::SCP module, but unfortunately, it's just a 
wrapper around a system call to the scp utility.  It worked when I use 
it.  It's a shame we have to go outside perl for this stuff, though.  If 
Net::SSH::Perl is not the speed bottleneck you're suggesting it might 
be, then I can imagine it would be easy to rewrite Net::SCP using 
Net::SSH::Perl.

-ofer

Re: [Ssh-sftp-perl-users] RE: Net::SFTP copying in 8192-byte chunks?

[Mark A. F. <mar...@ea...>]

From: Daniel Werner <dan...@ds...>
>Is it possible that Net::SFTP (or possibly the underlying Net::SSH::Perl) just isn't good for transferring large files?  

I've not transferred large files. But, I remember someone posted a long time ago similar speed problems with large files.

If it's a showstopper for you, you can also use Expect.pm to drive an sftp binary (compiled, openssh.org module) interactively. I posted an example a few months ago about how to get started with this.  It's a little more complicated. But, one benefit is that you're driving the same executable you can execute from the command line. If something doesn't work as expected, you can test directly with the module. 

Mark

[Ssh-sftp-perl-users] RE: Net::SFTP copying in 8192-byte chunks?

[Daniel W. <dan...@ds...>]

Well, I figured out how to change the buffer size (using do_read instead =
of
get), but it didn't really affect the transfer time much.  Is it =
possible
that Net::SFTP (or possibly the underlying Net::SSH::Perl) just isn't =
good
for transferring large files?  Please let me know if anyone has had
experience that would indicate otherwise; I'd truly love to be wrong =
about
this...




> From: Daniel Werner <daniel@ds...>
> Net::SFTP copying in 8192-byte chunks?  =20
> 2005-03-08 08:40 =20
>
> Hi, I"m trying to use Net::SFTP to set up an automated sftp of about =
35 GB
> (yes, that"s GB) worth of data to run once a week between 2 Solaris
> machines.  I tried a bare bones test of a 1 GB file using the "get"
method,
> but it was incredibly slow.  It might have finished after a few days,
where
> the openssh version of the (interactive) sftp command took only a few
> minutes to copy the entire thing.
>=20
> I turned on the verbose option for Net::SFTP and saw that it was =
copying
> only 8192-byte chunks at a time, and I think that"s why it was slow.  =
How
> does one raise this value?  I looked in the CPAN docs but couldn"t =
figure
it
> out.
>=20
> Thanks for any help,
> Dan
>
=20

[Ssh-sftp-perl-users] Net::SFTP copying in 8192-byte chunks?

[Daniel W. <dan...@ds...>]

Hi, I'm trying to use Net::SFTP to set up an automated sftp of about 35 =
GB
(yes, that's GB) worth of data to run once a week between 2 Solaris
machines.  I tried a bare bones test of a 1 GB file using the 'get' =
method,
but it was incredibly slow.  It might have finished after a few days, =
where
the openssh version of the (interactive) sftp command took only a few
minutes to copy the entire thing.

I turned on the verbose option for Net::SFTP and saw that it was copying
only 8192-byte chunks at a time, and I think that's why it was slow.  =
How
does one raise this value?  I looked in the CPAN docs but couldn't =
figure it
out.

Thanks for any help,
Dan

[Ssh-sftp-perl-users] provided password does not work with Net::SSH::Perl

[Rob V. <rob...@br...>]

Hi there,

I've trying out the Net::SSH::Perl module.

I've installed it with the cpan shell.

And it works fine when I use pubkey authentication.
But when I provide a password with login it fails to authenticate.

If I add the interactive -> "true", option it gives me a prompt for a
password after which it executes the rest of the script flawlessly.
(ie, gives a directory listing from the remote machine)

I've tried this with the demo script that came with the package, 
(cmd.pl in the eg dir from the distribution)

I've used all the defaults (except for host,login and password ...doh)
And then I get the following output:

pc: Reading configuration data /root/.ssh/config
pc: Reading configuration data /etc/ssh_config
pc: Allocated local port 1023.
pc: Connecting to 1.2.3.4, port 22.
pc: Remote protocol version 2.0, remote software version OpenSSH_3.8p1
pc: Net::SSH::Perl Version 1.27, protocol version 2.0.
pc: No compat match: OpenSSH_3.8p1.
pc: Connection established.
Enter your username on that host: [root]
And your password:
pc: Sent key-exchange init (KEXINIT), wait response.
pc: Algorithms, c->s: 3des-cbc hmac-sha1 none
pc: Algorithms, s->c: 3des-cbc hmac-sha1 none
pc: Entering Diffie-Hellman Group 1 key exchange.
pc: Sent DH public key, waiting for reply.
pc: Received host key, type 'ssh-dss'.
pc: Host '10.31.1.201' is known and matches the host key.
pc: Computing shared secret key.
pc: Verifying server signature.
pc: Waiting for NEWKEYS message.
pc: Enabling incoming encryption/MAC/compression.
pc: Send NEWKEYS, enable outgoing encryption/MAC/compression.
pc: Sending request for user-authentication service.
pc: Service accepted: ssh-userauth.
pc: Trying empty user-authentication request.
pc: Authentication methods that can continue:
publickey,keyboard-interactive.
pc: Next method to try is publickey.
Permission denied at ./cmd.pl line 43

I'm trying this on suse9.2

anybody who can tell me where to look ?

RE: [Ssh-sftp-perl-users] Problem with Net::SFTP

[David R. <dr...@at...>]

The error is from Net::SSH::Perl, and I'm not sure why you're getting =
it; according to CPAN the IO::Handle::blocking method is certainly =
present in perl 5.8.0 and 5.8.1 (and earlier; IIRC I checked it for 5.6 =
since the module requires 5.6).

Could you try adding 'use IO::Handle;' before 'use Fcntl;' in the =
Net::SSH::Perl module (your /Library/Perl/5.8.1/Net/SSH/Perl.pm) =
temporarily and seeing if the error goes away?  I can do a login without =
needing that so I'm not sure how your environment's different, but that =
may be what's lacking.

My test code (which will definitely hit the blocking() call):

perl -MNet::SSH::Perl -we =
'$a=3DNet::SSH::Perl->new(<host>);$a->login(<user>,<password>);print =
$a->cmd("ls")'

(which warns about printing the undef value but otherwise works as =
expected).

Thanks,


-----Original Message-----
From:	ssh...@li... on behalf of Matt =
Adams
Sent:	Mon 2/28/2005 2:06 PM
To:	ssh...@li...
Cc:=09
Subject:	[Ssh-sftp-perl-users] Problem with Net::SFTP
Hi there:

This might be a Net::SSH::Perl question but I'm getting this error when=20
I use Net::SFTP so I'll try here and see if anyone has any suggestions.

I wrote a small script to transfer files between two drop locations=20
using Net::SFTP but get the following error when trying to connect to=20
the remote host:

Can't locate object method "blocking" via package "IO::Handle" at=20
/Library/Perl/5.8.1/Net/SSH/Perl.pm line 212.

FWIW, I'm using Perl v5.8.1-RC3 on Mac OS X 10.3.8.

Any suggestions as to how I might go about resolving this would be=20
greatly appreciated.


Thanks in advance,

Matt


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Ssh-sftp-perl-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/ssh-sftp-perl-users

[Ssh-sftp-perl-users] Problem with Net::SFTP

[Matt A. <mat...@mo...>]

Hi there:

This might be a Net::SSH::Perl question but I'm getting this error when 
I use Net::SFTP so I'll try here and see if anyone has any suggestions.

I wrote a small script to transfer files between two drop locations 
using Net::SFTP but get the following error when trying to connect to 
the remote host:

Can't locate object method "blocking" via package "IO::Handle" at 
/Library/Perl/5.8.1/Net/SSH/Perl.pm line 212.

FWIW, I'm using Perl v5.8.1-RC3 on Mac OS X 10.3.8.

Any suggestions as to how I might go about resolving this would be 
greatly appreciated.


Thanks in advance,

Matt

RE: [Ssh-sftp-perl-users] Net::SSH::Perl hanging

[David R. <dr...@at...>]

Please log this as a bug on rt.cpan.org, with as much detail as you =
think necessary, including information about which systems it works on =
and which it doesn't (e.g. OS, server and version, any nonstandard =
configuration options).  This will make it more visible, and I or =
another developer are more likely to resolve it, either with a fix (if =
possible) or some documentation as to why it doesn't work as expected.

One workaround might be to have the command itself do the forking, =
perhaps using something like nohup so the program that's started doesn't =
get killed when the shell/terminal session close.

I'm moving shortly so don't be able to get to it myself until after the =
move., and logging the bug in RT helps the problem stay visible.

As always patches are welcome :).


-----Original Message-----
From:	ssh...@li... on behalf of Chris =
r
Sent:	Tue 2/22/2005 6:07 PM
To:	ssh...@li...
Cc:=09
Subject:	[Ssh-sftp-perl-users] Net::SSH::Perl hanging
I've got a script that connects to various servers to
run some admin commands. It works for the most part,
but upon hitting certain servers it seems to hang
waiting for the command to finish.
im just using the standard syntax...=20

$ssh =3D Net::SSH::Perl->new($BACKSERVER, port =3D> '22');
$ssh->login("$user", "$pass");
($out, $err, $exit) =3D $ssh->cmd("somecommand");

I've tried piping and sending the command output to
the background and null, it helps on one server but
not another and my script hangs unable to finish.

($out, $err, $exit) =3D $ssh->cmd("somecommand &");
($out, $err, $exit) =3D $ssh->cmd("somecommand >
/dev/null &");

Any workarounds on how to get the command to return
and continue on with execution would help.
Thanks.