Bug 32809 - problems with opening remote tar files
Summary: problems with opening remote tar files
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dump
Version: 7.0
Hardware: alpha
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-23 09:52 UTC by Michal Jaegermann
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-07-02 17:14:30 UTC

Attachments (Terms of Use)

Description Michal Jaegermann 2001-03-23 09:52:01 UTC
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
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
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
Total bytes written: 317440 (310kB, 155kB/s)

(But see also #32808.)

Comment 1 Bernhard Rosenkraenzer 2001-05-22 19:10:15 UTC
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 10:37:34 UTC
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
pts/23 mharris@devserv:~$ ssh george echo \$PATH

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 11:03:12 UTC
BTW, /etc/rmt and /sbin/rmt exist and are executable on both machines.

Comment 4 Michal Jaegermann 2001-06-27 02:22:05 UTC
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-27 02:27:01 UTC
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? 

Comment 6 Michal Jaegermann 2001-06-27 03:04:40 UTC
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 17:14:26 UTC
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 08:18:34 UTC
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.