5

I have inherited a Ubuntu 14.04 production server which needs to be upgraded to 20.04, and I would like a sandboxed version to experiment with first, hence I want to dump and restore the filesystems over the network from either a MacOS or another 14.04 virtualbox instance. An earlier version of this question is at https://askubuntu.com/q/1314747/963.

The server cannot "see" my machines so I cannot easily run dump and push the result remotely to my machine, but need to invoke ssh from my machine to run dump.

ssh -t me@there "echo MYPASSWORD | sudo -S dump -y -f - /boot 2>/dev/null " > boot.dump

Problem is that I've found that running this command inserts a lot of \r characters in front of \n characters which ruins the dump file so restore cannot use it. I understand that this is probably due to a driver translating linefeeds to the characters needed for printing, but I do not see where this is triggered.

How should I do this to get the correct binary dump file?

Thorbjørn Ravn Andersen
  • 1,031
  • 11
  • 19
  • 2
    Drop the `-t` from `ssh`. –  Feb 09 '21 at 16:09
  • @user414777 I found the -t to be necessary to allow me to pass in the password to sudo. – Thorbjørn Ravn Andersen Feb 09 '21 at 16:10
  • @ThorbjørnRavnAndersen if you're sufficiently privileged (well, you can `sudo`, so you probably are), it might be easier to configure sudo with `!requiretty` and `NOPASSWD`? – Ulrich Schwarz Feb 09 '21 at 19:13
  • 7
    Rather than ssh and echo your password to `sudo` on the other machine ( which exposed your password to other users on the machine who can run `ps` ), you might have an easier time adding your ssh key to /root/.ssh/authorized_keys on the remote machine and sshing in directly as root. – psusi Feb 09 '21 at 19:29
  • 1
    Does this answer your question? [Why is this binary file transferred over "ssh -t" being changed?](https://unix.stackexchange.com/questions/151916/why-is-this-binary-file-transferred-over-ssh-t-being-changed) – Stéphane Chazelas Sep 13 '21 at 13:08

2 Answers2

12

It's the ONLCR .c_oflag termios setting which is causing the newline (\n) to be turned into carriage-return/newline (\r\n) by the pseudo-terminal allocated by ssh on the remote machine (because of ssh's -t option).

Turn it off with stty -onlcr:

ssh -t me@there 'stty -onlcr; ...' > output
2

The official ASCII line ending is CR LF (i.e., return to line start and go to next line, \r\n in C-ish). To shave off a byte for each line (very important when yor memory is measured in KiB and disks are a few hundred MiB), Unix just uses \n to mark line end. Some systems (notably Microsoft) did go with the standard, so when moving text files among systems you have sometimes a translation task at hand.

AdminBee
  • 21,637
  • 21
  • 47
  • 71
vonbrand
  • 18,156
  • 2
  • 37
  • 59
  • Thank you. I understand the mechanism and the history behind it (seen it since the CP/M days) but not how it applied in my scenario. – Thorbjørn Ravn Andersen Feb 09 '21 at 16:52
  • 1
    @vonbrand ASCII defines the control characters Carriage Return and Line Feed. Unix *does* use these when talking to a device that requires them. However, internally Unix uses a newline character a a separator between lines in files and in memory. The Line Feed character was chosen for this, because one is enough. Internally, Unix handles line breaks at a higher level of abstraction than the characters controlling the movement of a mechanical print head. – Johan Myréen Feb 09 '21 at 19:20
  • 2
    Not the "ASCII" line ending, the "Internet" one. – Paŭlo Ebermann Feb 10 '21 at 01:40
  • 2
    *The official ASCII line ending is CR LF* But this is just false. LF is also known as "newline", and its use as a single-character line ending is well established. See https://en.wikipedia.org/wiki/Newline, in particular the History section. – Steve Summit Feb 10 '21 at 13:23