Bug 32809 - problems with opening remote tar files
problems with opening remote tar files
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
7.0
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-23 04:52 EST by Michal Jaegermann
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-02 13:14:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2001-03-23 04:52:01 EST
With tar-1.13.19-4 I see the following (long lines broken for posting)

# ssh toaster "rm -f /tmp/out.tar"
# tar --totals --rsh-command=/usr/bin/ssh -cvf toaster:/tmp/out.tar
     cyrus-sasl-devel-1.5.24-17.i386.rpm
tar: toaster\:/tmp/out.tar: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

where 'toaster' is an Alpha running Red Hat 7.0 installation
(openssh-2.3.0p1-4).  But if a target file already exists then
things are ok.

# ssh toaster "touch /tmp/out.tar"
# tar --totals --rsh-command=/usr/bin/ssh -cvf toaster:/tmp/out.tar
    cyrus-sasl-devel-1.5.24-17.i386.rpm
cyrus-sasl-devel-1.5.24-17.i386.rpm
Total bytes written: 317440 (310kB, 155kB/s)

There is no such problem when a target is an x86 box also with RH7
and the same version of openssh.

# ssh smok "rm -f /tmp/out.tar"
# tar --totals --rsh-command=/usr/bin/ssh -cvf smok:/tmp/out.tar
    cyrus-sasl-devel-1.5.24-17.i386.rpm
cyrus-sasl-devel-1.5.24-17.i386.rpm
Total bytes written: 317440 (310kB, 155kB/s)

(But see also #32808.)
Comment 1 Bernhard Rosenkraenzer 2001-05-22 15:10:15 EDT
This works with both the client and the server being x86 7.1 boxes.

Looks like an rmt problem on the server; reassigning
Comment 2 Mike A. Harris 2001-06-26 06:37:34 EDT
It appears that for some reason alpha does not put /sbin in the path for
a user, but x86 does.

pts/23 mharris@devserv:~$ ssh porky echo \$PATH
/usr/bin:/bin:/usr/sbin:/sbin
pts/23 mharris@devserv:~$ ssh george echo \$PATH
/usr/local/bin:/bin:/usr/bin

Any idea why the paths are different for x86 and alpha?  This is not an 
rmt problem IMHO.  tar perhaps calling "rmt" instead of "/sbin/rmt"?  If
that is not correct, then IMHO the problem lies with whatever is setting
the default path incorrectly.

I just added "/sbin" to my path explicitly in ~/.bashrc and the problem
seems to go away for me.


pts/23 mharris@devserv:~$ ssh george rmt
 
pts/23 mharris@devserv:~$ ssh porky rmt

(Hit enter on each one).  Without /sbin in the path I get:

pts/23 mharris@devserv:~$ ssh porky rmt
 
pts/23 mharris@devserv:~$ ssh george rmt
bash: rmt: command not found

I do not think this is rmt related.  Can you comment on it bero?

Comment 3 Mike A. Harris 2001-06-26 07:03:12 EDT
BTW, /etc/rmt and /sbin/rmt exist and are executable on both machines.
Comment 4 Michal Jaegermann 2001-06-26 22:22:05 EDT
This was reported in March.  I am not sure what changed in the meantime
but it seems to be gone.  Can you reproduce that on your machines?

Comment 5 Mike A. Harris 2001-06-26 22:27:01 EDT
I reproduced it on george for lack of access to another alpha box. George
is running 7.0 I believe.  I believe it was not dump/rmt related after stracing
and ltracing.  I didn't do exhaustive debugging though.  If it is fixed in 7.1
for you, can you confirm and close the report? 
TIA
Comment 6 Michal Jaegermann 2001-06-26 23:04:40 EDT
Alpha was most likely coincidental here.  If you reproduced it then I will try
again.  The trouble is that this was happening only with some files.

I rather suspect a bug in ssh than in rmt but that particular ssh version
is long gone.  If that would be PATH problem then why an existence/non-existence
of a target would be relevant?  I am afraid that I failed to get a better
handle on the problem.
Comment 7 Michal Jaegermann 2001-07-02 13:14:26 EDT
I am afraid that with my current setup (different ssh versions, other changes)
I failed to reproduce the problem.  OTOH, as it was happenning only with some
files, maybe I did not strike the right combination. :-(

The only weird thing is that on some remote I managed to create 'out.tar' file
with 010 permissions.  For an existing 'out.tar', which was overwritten by
a new output, permission were not modified.  Also nothing like that happened
when writing to another remote where results were consistent with an existing
umask.  Still scratching my head on that one.
Comment 8 Mike A. Harris 2001-07-16 04:18:34 EDT
Everything seems to work for me now with the current rawhide release of dump.

Note You need to log in before you can comment on or make changes to this bug.