[svlug] help transfering data over 1394 cable

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> On Thu, 08 May 2008 01:47:24 -0700, Rick Moen wrote:
> 
> > Damned near anything would be faster than SSH transport.
> 
> Here's something that would be slower: rsync

rsync is _not_ a transport!  {sigh}  It's a diffing and file-copying
protocol (and utility to implement it) that works _over_ a transport.
Examples of "transport" in this context are rsh and ssh -- the first of
which is a fast network transport and the second is a deliberately
compatible (slow) alternative with crypto authentication and session
encryption.

I don't suppose you've noticed that you're not helping?  

> > You _could_ go back and re-read where I already spoon-fed you the answer
> > about use of rcp.
> 
> Sure, if he can still find an rcp daemon in this day and age.

Since such a thing as an "rcp daemon" doesn't exist, that would indeed
be difficult -- and also irrelevant.  What one enables, in fact, is
rshd.  (Usually, the binary is named in.rshd , indicating that it's
intended to be run under one of the superservers.)

> I know that NFS isn't perfectly suited to this, but at least more
> current information can be found on it.

By you?  ;->

Commendably, use of the Berkeley r-utilities (rshell, rsh, rlogin, rcp,
rexec) got heavily deprecated among the Linux user community for general
usage starting a bit over a decade ago, because too many people were
lazily adopting a happy-go-lucky attitude towards exposing plaintext
passwords and session data to public networks.  That was A Good Thing,
especially since many people had to be metaphorically beaten upside the
head to finally recognise that ssh implementations exist for practically
anything that can move bits (**cough** http://linuxmafia.com/ssh/
**cough**).  However, there have always been usage scenarios where
r-command utilities have been not only a good idea but also bloody well
essential (e.g., HPC clusters[0]), and the need to move 1.5 TB of video
files over a private network segment would seem to qualify, too.

So:  Although doing handholding of someone (I'm _not_ referring to you,
here) who for years has been pleading that he's a "simple end-user"
every time someone suggests he read a couple of manpages and start
learning a few technical basics if, say, he intends to use Linux to 
assemble a feature film from 16-terabytes-and-growing of digital video,
here's an approximate recipe:

1.  Install package "rsh-server".  (Depending on distro, may of course
    be called something else.)
2.  Install the portmapper.[1]
3.  Configure inetd or xinetd to offer the rshd service.  Restart
    whichever of these superservers you elect to use.
4.  Populate /etc/hosts.equiv and /$HOME/.rhosts on both boxes.
    (Make sure they're permission 600 or such.)
5.  rcp (etc.) at will.  Mind the security exposure.
6.  In event of problems, make sure ip/port filtering or
    /etc/hosts.{allow|deny} aren't shooting you in the foot -- and 
    check /var/log/messages for clues.  (You'll need to populate
    /etc/hosts.allow.)

I believe http://rute.2038bug.com/node15.html.gz covers this matter
pretty thoroughly.

[0] Yrs. truly helped construct what at the time became the #2 cluster
on the Top 500 supercomputer list -- a 4096-CPU Itanic cluster.
("Itanium is the wave of the future.  Always has been.  Always will
be.")  The clients would have laughed heartily if we'd told them to rely
on ssh or NFS.

[1] Allegedly needed on some systems, though I've never known this
    to be the case.