On Tue, Jan 31, 2012 at 4:01 PM, m.roth@5-cent.us wrote:
On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
On 01/31/2012 09:47 PM, Les Mikesell wrote:
No, I'm trying to have rsync make an outbound connection over ssh from the rescue environment and getting what looks like an argument error from ssh. Ssh itself works and I can connect to the same target if I run it directly, and the exact same rsync command lines work from a normal host. Either rsync isn't setting up the remote command right, or ssh isn't allowing it and giving a bad error message.
<snip> > I'm going the other direction (originating the command from the rescue > host), but yes, tar works over ssh, and and ssh works by itself. The > part that doesn't work is ssh when invoked by rsync, either by default > or with an explicit '-essh' argument, and the error message looks like > an ssh argument error so it doesn't even prompt for the password.
AUGH! I think I have it: are the versions of rsync on the rescue instance and the other server the same?
It's not getting that far. I'm getting an error trying to start the local ssh. And at this point I have working VM from the tar copy, _except_ that it isn't matching a driver to the virtual NIC. I'm glad I'm not restoring a real backup with a dead machine here...
Since I don't need this today, I think I'll try ReaR to see if it gets it right. It builds a bootable iso that is supposed to re-install on bare metal.
On 31 January 2012 22:14, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jan 31, 2012 at 4:01 PM, m.roth@5-cent.us wrote:
On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
On 01/31/2012 09:47 PM, Les Mikesell wrote:
No, I'm trying to have rsync make an outbound connection over ssh from the rescue environment and getting what looks like an argument error from ssh. Ssh itself works and I can connect to the same target if I run it directly, and the exact same rsync command lines work from a normal host. Either rsync isn't setting up the remote command right, or ssh isn't allowing it and giving a bad error message.
There was a buggy version of rsync that did this. It wasn't initialising the ssh session properly from my email a while ago:
On Tue, 23 Aug 2011, Ned Slider wrote:
On 23/08/11 12:35, Michael Simpson wrote:
Hello
Is anyone else having problems on 5.6 using the new rsync from the CR repo I have only managed to get rsync (called from the cli) working again after downgrading it to the previous 2.x release as the newer version was just spitting out the ssh usage information and failing. This server is stock i386 with just the CR as an extra repo.
regards
mike
Known issue I'm guessing:
https://bugzilla.redhat.com/show_bug.cgi?id=724041
which was fixed nearly a month ago.
So instead of saying nearly a month ago how about we we say it was only released 20 days ago. BZ says it was released 03 Aug 11.
If this is your issue, try appending username@host like so:
rsync user@host:/
as a workaround, but I'm not sure why CentOS is still shipping an old broken version?
Umm, maybe because upstream shipped rsync-3.0.6-4.el5.i386.rpm with 5.7 and the rsync-3.0.6-4.el5_7.1.i386.rpm has not made it to CentOS yet.
Remember that bug for bug compatibility thing. :-)
Patience is a virtue.
Regards,
On Tue, Feb 7, 2012 at 5:22 AM, Michael Simpson mikie.simpson@gmail.com wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=724041
which was fixed nearly a month ago.
So instead of saying nearly a month ago how about we we say it was only released 20 days ago. BZ says it was released 03 Aug 11.
If this is your issue, try appending username@host like so:
rsync user@host:/
as a workaround, but I'm not sure why CentOS is still shipping an old broken version?
Yes, that's it. Thanks!
Umm, maybe because upstream shipped rsync-3.0.6-4.el5.i386.rpm with 5.7 and the rsync-3.0.6-4.el5_7.1.i386.rpm has not made it to CentOS yet.
Remember that bug for bug compatibility thing. :-)
Patience is a virtue.
Well, it is burned on the CentOS 5.7 install/rescue DVD. No amount of patience is going to change that, so remembering the workaround will be the only choice when using that iso in rescue mode... Is that something that QA testing in CentOS should have caught or would it have automatically passed as a match for upstream?
-
Les Mikesell -
Michael Simpson