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.)
This works with both the client and the server being x86 7.1 boxes. Looks like an rmt problem on the server; reassigning
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?
BTW, /etc/rmt and /sbin/rmt exist and are executable on both machines.
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?
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
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.
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.
Everything seems to work for me now with the current rawhide release of dump.