Remote.pm (File::Remote) problem

D

Dayton Jones

I've got a very simple script (see below) that uses the File::Remote
module. I've set up the script to use ssh/scp and there is no problem
for the user to ssh to the hosts - but the script fails with a
"permission denied" error on the copy command.

-- begin script

#!/usr/bin/perl
use File::Remote qw:)replace);

setrsh('/usr/bin/ssh');
serrcp('/usr/bin/scp');
settmp('/tmp');

copy("host1:/tmp/file","host1:/tmp/file2") or die ":: $!\n";

-- end script

On "host1" I can see the connection coming in:
Feb 28 18:46:48 host1 sshd(pam_unix)[20211]: session opened for user
XXXX by (uid=XXX)
Feb 28 18:46:49 host1 sshd(pam_unix)[20211]: session closed for user XXXX


So I don't know what is causing the permissions issue... Any ideas or
suggestions? What do I need to look at, what could be the cause?

Thanks is advance for any help...
 
A

A. Sinan Unur

I've got a very simple script (see below) that uses the File::Remote
module. I've set up the script to use ssh/scp and there is no problem
for the user to ssh to the hosts - but the script fails with a
"permission denied" error on the copy command.

-- begin script

#!/usr/bin/perl

use strict;
use warnings;

missing.
use File::Remote qw:)replace);

setrsh('/usr/bin/ssh');
serrcp('/usr/bin/scp');

*Ah-em*. Have you read the posting guidelines for this group?

....
Thanks is advance for any help...

You can learn how to help others help you, and also how to help yourself
by following the posting guidelines.

Sinan
 
D

Dayton Jones

Sorry, no I hadn't read the guidelines but I will now.

I added the strict/warnings but had the same result -- with no extra
information.
 
A

A. Sinan Unur

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....

I added the strict/warnings but had the same result -- with no extra
information.

Well, did you fix the typo above?

I don't have File-Remote installed, by I doubt serrcp is correct.

Sinan
 
D

Dayton Jones

Yes, I noticed that when reading your original response -- changed it to
"setrcp="
 
A

A. Sinan Unur

Dayton, *please* do not top-post.
Yes, I noticed that when reading your original response -- changed it
to "setrcp="

Well, apologoies, I misdiagnosed the problem. I looked at the source
code of File::Remote, and the problem simply is that /dev/null has a
different name on Windows, i.e. NUL.

The dirty fix would involve replacing File::Remote::_system.

You could also just go in and edit out the 1 > /dev/null out of the
backticked string. But then, you'd be modifiying a module, and it might
get overwritten when you upgrade to a new version etc.

#!/usr/bin/perl

use strict;
use warnings;

use File::Remote qw:)replace);
use File::Spec::Functions qw( canonpath );

setrsh(canonpath 'C:/opt/cygwin/bin/ssh.exe');
setrcp(canonpath 'C:/opt/cygwin/bin/scp.exe');
settmp(canonpath $ENV{TEMP});

{
no warnings 'redefine';
*File::Remote::_system = sub {
my($self, @cmd) = File::Remote::_self_or_default(@_);

# return "Broken pipe" if cmd invalid
# chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
chomp(my $return = `@cmd 2>&1 1>NUL || echo 32`);
File::Remote::_debug("_system(@cmd) = $return");

if ($return) {
# if echo'ed an int (internal tests), use it,
# else use "Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;
return undef;
}
return 1;
};
}

copy('localfile', 'remotefile')
or die "\$\@ = $@\n\$! = $!\n";

__END__

Sinan
 
H

harryfmudd [AT] comcast [DOT] net

A. Sinan Unur said:
Well, apologoies, I misdiagnosed the problem. I looked at the source
code of File::Remote, and the problem simply is that /dev/null has a
different name on Windows, i.e. NUL.

Yeah, Perl is eminently portable - until someone sticks in an
OS-specific construct. Maybe this is the Unix programmers' revenge for
all those stupid question marks in web pages made by windows users.
The dirty fix would involve replacing File::Remote::_system.

You could also just go in and edit out the 1 > /dev/null out of the
backticked string. But then, you'd be modifiying a module, and it might
get overwritten when you upgrade to a new version etc.

Another alternative is to contact the creater of the module. If he's
willing to have his module dependent on File::Spec, he can get the
correct device name from File::Spec->devnull(), and not have to worry
about what to call the null device. The File::Spec solution also covers
VMS, which calls it NLA0:.

Tom Wyant
 
D

Dayton Jones

A. Sinan Unur said:
Dayton, *please* do not top-post.




Well, apologoies, I misdiagnosed the problem. I looked at the source
code of File::Remote, and the problem simply is that /dev/null has a
different name on Windows, i.e. NUL.

The dirty fix would involve replacing File::Remote::_system.

You could also just go in and edit out the 1 > /dev/null out of the
backticked string. But then, you'd be modifiying a module, and it might
get overwritten when you upgrade to a new version etc.

#!/usr/bin/perl

use strict;
use warnings;

use File::Remote qw:)replace);
use File::Spec::Functions qw( canonpath );

setrsh(canonpath 'C:/opt/cygwin/bin/ssh.exe');
setrcp(canonpath 'C:/opt/cygwin/bin/scp.exe');
settmp(canonpath $ENV{TEMP});

{
no warnings 'redefine';
*File::Remote::_system = sub {
my($self, @cmd) = File::Remote::_self_or_default(@_);

# return "Broken pipe" if cmd invalid
# chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
chomp(my $return = `@cmd 2>&1 1>NUL || echo 32`);
File::Remote::_debug("_system(@cmd) = $return");

if ($return) {
# if echo'ed an int (internal tests), use it,
# else use "Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;
return undef;
}
return 1;
};
}

copy('localfile', 'remotefile')
or die "\$\@ = $@\n\$! = $!\n";

__END__

Sinan

OK, now I'm confused -- I'm not running on a windows platform so the
/dev/null reference is correct. I'm running RedHat EL3 and EL4 -- my
apologies for not specifying that earlier.
 
A

A. Sinan Unur

A. Sinan Unur wrote: ....

....

....

....

OK, now I'm confused -- I'm not running on a windows platform so the
/dev/null reference is correct. I'm running RedHat EL3 and EL4 -- my
apologies for not specifying that earlier.

Please trim your replies a bit. I don't think I did a good job after so
many repeated full quotes.

Upon looking at File::Remote again, I noticed that there is another
potential bug in File::Remote::_system:

sub _system {
my($self, @cmd) = _self_or_default(@_);

# return "Broken pipe" if cmd invalid
chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
_debug("_system(@cmd) = $return");

if ($return) {
# if echo'ed an int (internal tests), use it,
# else use "Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;

Notice how $! is set without checking if the match above succeeded? That
might cause this routine to report an error when there was none if $1
had been set earlier.

Are you sure the file was not copied?

Another idea is to temporarily enable debugging by setting $DEBUG = 1
aorund line 114 of the module:

# Simple debugging function
my $DEBUG = 1;
sub _debug { warn "debug: ", @_ if $DEBUG };

See what you get in the actual trace.


Sinan
 
D

Dayton Jones

A. Sinan Unur said:
Upon looking at File::Remote again, I noticed that there is another
potential bug in File::Remote::_system:

sub _system {
my($self, @cmd) = _self_or_default(@_);

# return "Broken pipe" if cmd invalid
chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
_debug("_system(@cmd) = $return");

if ($return) {
# if echo'ed an int (internal tests), use it,
# else use "Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;

Notice how $! is set without checking if the match above succeeded? That
might cause this routine to report an error when there was none if $1
had been set earlier.

Are you sure the file was not copied?

Another idea is to temporarily enable debugging by setting $DEBUG = 1
aorund line 114 of the module:

# Simple debugging function
my $DEBUG = 1;
sub _debug { warn "debug: ", @_ if $DEBUG };

See what you get in the actual trace.


Sinan



Well, enabling debug basically looks like it's pointing the finger at
ssh/scp :

debug: copy -- system(File::Remote=HASH(0x9bd55b4)->setrcp,
host1:/tmp/file, host1:/tmp/file2) at
/usr/lib/perl5/site_perl/5.8.5/File/Remote.pm line 115.
debug: _system(/usr/bin/scp host1:/tmp/file host1:/tmp/file2) = Host key
verification failed.
lost connection
32 at /usr/lib/perl5/site_perl/5.8.5/File/Remote.pm line 115.
host1 :: Permission denied


So even though, as that user I can ssh/scp to host1 with no problems,
the module can't pass the host verification stage...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top