FAQ
If I boot a 5.7 install disk with 'linux rescue selinux=0', let it
start the network and detect the installed system, ssh seems to work,
but rsync fails with "rsync: connection unexpectedly closed (0 bytes
received so far) [receiver]). Shouldn't it work as long as the
underlying ssh connection works? It doesn't prompt for the ssh
password and using -essh doesn't change it.

--
Les Mikesell
lesmikesell at gmail.com

Search Discussions

  • Nux at Jan 31, 2012 at 1:29 pm

    Les Mikesell writes:

    If I boot a 5.7 install disk with 'linux rescue selinux=0', let it
    start the network and detect the installed system, ssh seems to work,
    but rsync fails with "rsync: connection unexpectedly closed (0 bytes
    received so far) [receiver]). Shouldn't it work as long as the
    underlying ssh connection works? It doesn't prompt for the ssh
    password and using -essh doesn't change it.
    Les,

    What commands are you using exactly? To or from the rescued host? Also, are
    you using ssh non-standard ports?

    --
    Nux!
    www.nux.ro
  • Les Mikesell at Jan 31, 2012 at 1:34 pm

    On Tue, Jan 31, 2012 at 12:29 PM, wrote:
    Les Mikesell writes:
    If I boot a 5.7 install disk with 'linux rescue selinux=0', let it
    start the network and detect the installed system, ssh seems to work,
    but rsync fails with "rsync: ?connection unexpectedly closed (0 bytes
    received so far) [receiver]). ? Shouldn't it work as long as the
    underlying ssh connection works? ?It doesn't prompt for the ssh
    password and using -essh doesn't change it.
    What commands are you using exactly? To or from the rescued host? Also, are
    you using ssh non-standard ports?
    It is from the rescued host - basically a:
    rsync -essh otherhost:/path .

    ssh otherhost 'cd /path && tar -cf - ' | tar -xvf -
    seems to be working, so it is not related to network connectivity or ssh.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Nux at Jan 31, 2012 at 2:07 pm

    Les Mikesell writes:
    On Tue, Jan 31, 2012 at 12:29 PM, wrote:
    Les Mikesell writes:
    If I boot a 5.7 install disk with 'linux rescue selinux=0', let it
    start the network and detect the installed system, ssh seems to work,
    but rsync fails with "rsync: ?connection unexpectedly closed (0 bytes
    received so far) [receiver]). ? Shouldn't it work as long as the
    underlying ssh connection works? ?It doesn't prompt for the ssh
    password and using -essh doesn't change it.
    What commands are you using exactly? To or from the rescued host? Also, are
    you using ssh non-standard ports?
    It is from the rescued host - basically a:
    rsync -essh otherhost:/path .

    ssh otherhost 'cd /path && tar -cf - ' | tar -xvf -
    seems to be working, so it is not related to network connectivity or ssh.
    That's odd, try rsync -e 'ssh -v' to get some more details.
    Also you will want to use some parameters to rsync (like -av or maybe even
    -z for compression etc).

    --
    Nux!
    www.nux.ro
  • Les Mikesell at Jan 31, 2012 at 2:47 pm

    On Tue, Jan 31, 2012 at 1:07 PM, wrote:


    What commands are you using exactly? To or from the rescued host? Also, are
    you using ssh non-standard ports?
    It is from the rescued host - basically a:
    rsync -essh otherhost:/path .

    ssh otherhost 'cd /path && tar -cf - ' | tar -xvf -
    seems to be working, so it is not related to network connectivity or ssh.
    That's odd, try rsync -e 'ssh -v' to get some more details.
    Also you will want to use some parameters to rsync (like -av or maybe even
    -z for compression etc).
    I'm getting a
    usage: ssh [bunch of ssh options]
    like it is giving the wrong command line to ssh. Or maybe the lack of
    an /etc/ssh/ssh_config in this environment is breaking it, although my
    own ssh commands and connections seem to work. I haven't done the
    chroot into the installed mount since I was planning to overwrite it.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Les Mikesell at Jan 31, 2012 at 3:47 pm

    On Tue, Jan 31, 2012 at 1:50 PM, wrote:
    <snip>
    That's odd, try rsync -e 'ssh -v' to get some more details.
    Also you will want to use some parameters to rsync (like -av or maybe
    even
    -z for compression etc).
    I'm getting a
    usage: ssh ?[bunch of ssh options]
    like it is giving the wrong command line to ssh. Or maybe the lack of
    an /etc/ssh/ssh_config in this environment is breaking it, although my
    own ssh commands and connections seem to work. ?I haven't done the
    chroot into the installed mount since I was planning to overwrite it.
    Any chance that either your system, or the rescued system, are blocking
    it, because it doesn't know who your host, or your host doesn't know the
    rescued host?

    I'd try chrooting and restarting sshd.
    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.

    The goal here was basically to clone a running machine into a new
    VMware image booted into rescue mode. Maybe there's a better way to
    do that anyway. The source is using RAID1 drives in a layout that the
    VMware converter won't handle. The tar | tar copy seems to be mostly
    OK with a little tweaking of fstab, etc. I'm going to give 'ReaR'
    (from EPEL) a try too - it is supposed to do most of the grunge work
    for you but you have to intervene manually if you want to change the
    disk layout.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ljubomir Ljubojevic at Jan 31, 2012 at 4:14 pm

    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.
    How about something like

    tar cvf - . | gzip -c -1 | ssh user at host cat ">" remotefile.gz

    to get the filesystem across the ssh?


    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Les Mikesell at Jan 31, 2012 at 4:58 pm

    On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevic 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.
    How about something like

    tar cvf - . | gzip -c -1 | ssh user at host cat ">" remotefile.gz

    to get the filesystem across the ssh?
    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.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ljubomir Ljubojevic at Jan 31, 2012 at 5:11 pm

    On 01/31/2012 10:58 PM, Les Mikesell wrote:
    On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevicwrote:
    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.
    How about something like

    tar cvf - . | gzip -c -1 | ssh user at host cat ">" remotefile.gz

    to get the filesystem across the ssh?
    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.
    I meant to suggest that you pipe your data over the ssh tunnel. I know
    you are smart enough to use your tool of choice instead of tar
    specifically.

    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Les Mikesell at Jan 31, 2012 at 5:14 pm

    On Tue, Jan 31, 2012 at 4:01 PM, wrote:
    On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevic <office at 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.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Michael Simpson at Feb 7, 2012 at 6:22 am

    On 31 January 2012 22:14, Les Mikesell wrote:
    On Tue, Jan 31, 2012 at 4:01 PM, ?wrote:
    On Tue, Jan 31, 2012 at 3:14 PM, Ljubomir Ljubojevic <office at 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?idr4041

    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 at host like so:

    rsync user at 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,
  • Les Mikesell at Feb 7, 2012 at 12:22 pm

    On Tue, Feb 7, 2012 at 5:22 AM, Michael Simpson wrote:
    https://bugzilla.redhat.com/show_bug.cgi?idr4041

    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 at host like so:

    rsync user at 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
    lesmikesell at gmail.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJan 31, '12 at 1:19p
activeFeb 7, '12 at 12:22p
posts12
users4
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase