Very Computer

by **OpenMin** » Sat, 27 Jan 2001 23:23:29

A passing remark in some Beowulf literature implied that one 'might simply
use rsh to distribute computing tasks.' I think this was a reference to
'remote shell.'

Since my application/s for distributed computing are not fine-grained, and I
am more interested in rapid deployment than ultimate efficiency, the flavor
of this notion holds some appeal.

Essentially, I will be launching remote tasks on nodes which will take from
several seconds to many minutes.

Anyone know anything about this 'rsh' and it's potential
effectiveness/simplicity for this scheme?

Is it available on the RedHat 7 disk set?

Thanks
___

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **Henry Zektse** » Sun, 28 Jan 2001 01:27:27

The reference you're referring to basically implies that you launch
processes on multiple nodes sitting at your desk. rsh is (Very loose
comparisson here, dont flame me please) for this purpose, the equivalent of
opening an xterm on your workstation, telnetting to a node, and firing up
that 6 hour compile. Then minimizing the xterm, openning a new one, and
doing the same for that other app you want to do (telnetted to another node
this time). Basically, instead of the cluster chosing the location of each
process, you do it yourself. Whereas beowulf is sometimes called the
poor-man's cluster, this would be the broke-man's cluster. *shrug* I guess
all of my linux servers are in a cluster since I have xterms to all of them
open running processes.

H

Quote:> A passing remark in some Beowulf literature implied that one 'might simply
> use rsh to distribute computing tasks.' I think this was a reference to
> 'remote shell.'

> Since my application/s for distributed computing are not fine-grained, and
I
> am more interested in rapid deployment than ultimate efficiency, the
flavor
> of this notion holds some appeal.

> Essentially, I will be launching remote tasks on nodes which will take
from
> several seconds to many minutes.

> Anyone know anything about this 'rsh' and it's potential
> effectiveness/simplicity for this scheme?

> Is it available on the RedHat 7 disk set?

> Thanks
> ___

> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **OpenMin** » Sun, 28 Jan 2001 05:29:21

Quote:> The reference you're referring to basically implies that you launch
> processes on multiple nodes sitting at your desk. rsh is (Very loose
> comparisson here, dont flame me please) for this purpose, the equivalent
of
> opening an xterm on your workstation, telnetting to a node, and firing up
> that 6 hour compile. Then minimizing the xterm, openning a new one, and
> doing the same for that other app you want to do (telnetted to another
node
> this time).

Do you mean that rsh a) only runs with xterm, b) cannot be automated?

Quote:> Basically, instead of the cluster chosing the location of each
> process, you do it yourself.

If this is ONLY possible manually, then that would be unsuitable. If,
however, this can be automated, this is PRECISELY the level of control I
want. Especially if remote processes can be monitored visually on a
central workstation.

Why? Because I want to REMOTELY manage node power-on/off, perform
load-balancing, manage data redundancy and no/low-fault computation, perform
diagnostics, dedicate certain nodes to special tasks at times. In short,
having tentatively examined the option, I do NOT want what is essentially a
32 or 64-CPU computer laced together with LAN.

Quote:> Whereas beowulf is sometimes called the
> poor-man's cluster, this would be the broke-man's cluster. *shrug* I guess
> all of my linux servers are in a cluster since I have xterms to all of
them
> open running processes.

:-) What an amazing world... where a person with a group of connected
PERSONAL computers at his fingertips-- a billion dollars of computing power
only five decades ago-- speaks (however impishly) in terms of poverty.

Yes, in a sense this IS a cluster, with YOU as the executive program. Now,
if you cannot be replaced with a computer program, or if any automated
implementation is inherently slow as molasses, then it would be a poor
cluster indeed.

In a nutshell: From a central system I want to programmatically launch apps
on computers connected by LAN. (I am willing to run a process, hopefully a
small one, on each node to facilitate communication.) I want to do this
with the simplest arrangement possible even if there is some speed
trade-off, and the shortest learning and development period.

A "script" language would be OK, especially for prototyping. Will consider
Java (despite my negative impressions of Win98 implementations and apps),
C++ or whatever, but need to keep deployment time at a minimum. Important
to get something working quickly, then hang features on it later.

Thanks
_____

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **Philip Armstro** » Sun, 28 Jan 2001 05:45:24

>The reference you're referring to basically implies that you launch
>processes on multiple nodes sitting at your desk. rsh is (Very loose
>comparisson here, dont flame me please) for this purpose, the equivalent of
>opening an xterm on your workstation, telnetting to a node, and firing up
>that 6 hour compile. Then minimizing the xterm, openning a new one, and
>doing the same for that other app you want to do (telnetted to another node
>this time). Basically, instead of the cluster chosing the location of each
>process, you do it yourself. Whereas beowulf is sometimes called the
>poor-man's cluster, this would be the broke-man's cluster. *shrug* I guess
>all of my linux servers are in a cluster since I have xterms to all of them
>open running processes.

It should be noted that rsh is horribly insecure. So don't use it
unless your cluster is on a private internal network of its
own (Like ours is).

rsh is simply a tool for running commands on remote computers (is
stands for 'remote shell' I think). It's been a standard part of most
unix distributions for years (decades?).

Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt

by **Edgar F. Hilto** » Sun, 28 Jan 2001 06:30:00

> > The reference you're referring to basically implies that you launch
> > processes on multiple nodes sitting at your desk. rsh is (Very loose
> > comparisson here, dont flame me please) for this purpose, the equivalent
> of
> > opening an xterm on your workstation, telnetting to a node, and firing up
> > that 6 hour compile. Then minimizing the xterm, openning a new one, and
> > doing the same for that other app you want to do (telnetted to another
> node
> > this time).

> Do you mean that rsh a) only runs with xterm, b) cannot be automated?

you can use rsh from within a script. Here are some examples.

rsh machine1 program1 > file1
rsh machine 2 program2 > file2

Meaning: Run program1 and then run program 2. Save their respective outputs
(from stdout) to files 1 and 2, which are local.

rsh machine1 program1 > file1 &
rsh machine2 program2 > file2 &

Meaning: Start programs1 and 2 immediately and save their outputs onto files 1
and 2, which are local

rsh machine 1 program1 | rsh machine2 program2 > file

Meaning: The output of program 1 is used as input to program2 which is then
saved into local file "file".

(Basically, shell metacharacters which are not quoted are interpreted on the
local machine, while quoted metacharacters are interpreted on the remote
machine.) All of the above are assuming that you have already set up the remote
machine with an appropriate ".rhosts" file.(so that you don't have to provide
passwords) in your remote accounts and that programs1 and programs2 are each on
their respective machines. Of course, you could always transfer both of these
programs using some "ftp" variant (such as ncftpget and ncftpput) from within
your script.

Look at the man pages for rsh and rlogin for more information on the above.

Quote:> Basically, instead of the cluster chosing the location of each
> > process, you do it yourself.

> If this is ONLY possible manually, then that would be unsuitable. If,
> however, this can be automated, this is PRECISELY the level of control I
> want. Especially if remote processes can be monitored visually on a
> central workstation.

Nope, this can be done via a script. See above.

Quote:> load-balancing, manage data redundancy and no/low-fault computation, perform
> diagnostics, dedicate certain nodes to special tasks at times. In short,
> having tentatively examined the option, I do NOT want what is essentially a
> 32 or 64-CPU computer laced together with LAN.

In other words, with rsh you can EXECUTE PROGRAMS IN REMOTE MACHINES, for
example:

RSH is not recommended for programs that require human interaction. It is
primarily designed for programs which you start and they produce some sort of
output to stdout or to some remote file.

Quote:> on computers connected by LAN. (I am willing to run a process, hopefully a
> small one, on each node to facilitate communication.) I want to do this
> with the simplest arrangement possible even if there is some speed
> trade-off, and the shortest learning and development period.

Sounds like rsh is for you.

my two cents.

--
Edgar F. Hilton FSMLabs, Inc.
voice: 850.893.0300 www.fsmlabs.com
fax: 206.350.4EFH www.rtlinux.com

by **Edgar F. Hilto** » Sun, 28 Jan 2001 06:31:01

> > The reference you're referring to basically implies that you launch
> > processes on multiple nodes sitting at your desk. rsh is (Very loose
> > comparisson here, dont flame me please) for this purpose, the equivalent
> of
> > opening an xterm on your workstation, telnetting to a node, and firing up
> > that 6 hour compile. Then minimizing the xterm, openning a new one, and
> > doing the same for that other app you want to do (telnetted to another
> node
> > this time).

> Do you mean that rsh a) only runs with xterm, b) cannot be automated?

you can use rsh from within a script. Here are some examples.

rsh machine1 program1 > file1
rsh machine 2 program2 > file2

Meaning: Run program1 and then run program 2. Save their respective outputs
(from stdout) to files 1 and 2, which are local.

rsh machine1 program1 > file1 &
rsh machine2 program2 > file2 &

Meaning: Start programs1 and 2 immediately and save their outputs onto files 1
and 2, which are local

rsh machine 1 program1 | rsh machine2 program2 > file

Meaning: The output of program 1 is used as input to program2 which is then
saved into local file "file".

(Basically, shell metacharacters which are not quoted are interpreted on the
local machine, while quoted metacharacters are interpreted on the remote
machine.) All of the above are assuming that you have already set up the remote
machine with an appropriate ".rhosts" file.(so that you don't have to provide
passwords) in your remote accounts and that programs1 and programs2 are each on
their respective machines. Of course, you could always transfer both of these
programs using some "ftp" variant (such as ncftpget and ncftpput) from within
your script.

Look at the man pages for rsh and rlogin for more information on the above.

Quote:> Basically, instead of the cluster chosing the location of each
> > process, you do it yourself.

> If this is ONLY possible manually, then that would be unsuitable. If,
> however, this can be automated, this is PRECISELY the level of control I
> want. Especially if remote processes can be monitored visually on a
> central workstation.

Nope, this can be done via a script. See above.

Quote:> load-balancing, manage data redundancy and no/low-fault computation, perform
> diagnostics, dedicate certain nodes to special tasks at times. In short,
> having tentatively examined the option, I do NOT want what is essentially a
> 32 or 64-CPU computer laced together with LAN.

In other words, with rsh you can EXECUTE PROGRAMS IN REMOTE MACHINES, for
example:

RSH is not recommended for programs that require human interaction. It is
primarily designed for programs which you start and they produce some sort of
output to stdout or to some remote file.

Quote:> on computers connected by LAN. (I am willing to run a process, hopefully a
> small one, on each node to facilitate communication.) I want to do this
> with the simplest arrangement possible even if there is some speed
> trade-off, and the shortest learning and development period.

Sounds like rsh is for you.

my two cents.

--
Edgar F. Hilton FSMLabs, Inc.
voice: 850.893.0300 www.fsmlabs.com
fax: 206.350.4EFH www.rtlinux.com

by **Colin Smi** » Sun, 28 Jan 2001 07:50:23

>> The reference you're referring to basically implies that you launch
>> processes on multiple nodes sitting at your desk. rsh is (Very loose
>> comparisson here, dont flame me please) for this purpose, the equivalent
>of
>> opening an xterm on your workstation, telnetting to a node, and firing up
>> that 6 hour compile. Then minimizing the xterm, openning a new one, and
>> doing the same for that other app you want to do (telnetted to another
>node
>> this time).

>Do you mean that rsh a) only runs with xterm, b) cannot be automated?

No and no.

"man rsh"

Quote:>> Basically, instead of the cluster chosing the location of each
>> process, you do it yourself.

>If this is ONLY possible manually, then that would be unsuitable. If,
>however, this can be automated, this is PRECISELY the level of control I
>want. Especially if remote processes can be monitored visually on a
>central workstation.

Pretty much everything on Unix/Linux is automatable.

[snip]

All rsh does is connect to the destination system and launch commandX.
Stdin, stdout and stderr are connected to the terminal which launched the
rsh.

example:
rsh remotesystem commandX

It can be scripted just as easily as any other command.

by **OpenMin** » Sun, 28 Jan 2001 08:34:48

Quote:> Sounds like rsh is for you.

Thanks, Edgar. Looking forward to trying this out. The remote tasks tasks
I'll be launching will require specification of parameters. Presumably rsh
can handle this in it's command line. As you say, time for further reading.
Phlegm at 11. :-)

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **Larry Zimmerm** » Sun, 28 Jan 2001 13:34:13

"OpenMind" <**Mail Free America**> writes:

Quote:> A passing remark in some Beowulf literature implied that one 'might simply
> use rsh to distribute computing tasks.' I think this was a reference to
> 'remote shell.'

You can do distributed processing using rsh. A few things to keep in mind
are: as stated in another post, it's easier if you have the same login
and password on all hosts.
rsh does not pass environment variables or current directory.
When you rsh to a host, you will be in your home diretory, and the
environment is set as though you did a regular login.
So: You have to pass full path names of commands.
The command has to 'cd' to the appropriate directory if it should
not be run in your home directory.
You should use the "-n" option so the remote process releases "stdin".
(I think that's essentially what it does).

I have a script that I've used on a network of SUNs running Solaris
( but the script is pretty generic sh, so should run on Linux).
I hesitate to post it here as I would have to post ~200 lines to
demonstrate how the setup and the use of rsh.
I'll put it on my website at:
<http://www.gonefishing.sk.ca/laz/rsh/rshexample.html>
You can copy the scripts from there if they look useful.

Give me a few minutes, I'm just creating the page now.

Larry Z.
--

by **Philip Armstro** » Sun, 28 Jan 2001 07:53:56

Quote:>In a nutshell: From a central system I want to programmatically launch apps
>on computers connected by LAN. (I am willing to run a process, hopefully a
>small one, on each node to facilitate communication.) I want to do this
>with the simplest arrangement possible even if there is some speed
>trade-off, and the shortest learning and development period.

So go read the man page for rsh.

sheesh. Its not *that* hard you know.

Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt

by **Richard Hecto** » Sun, 28 Jan 2001 20:47:30

> It should be noted that rsh is horribly insecure. So don't use it
> unless your cluster is on a private internal network of its
> own (Like ours is).

If that's a problem, you can replace rsh with ssh.

Richard

by **OpenMin** » Mon, 29 Jan 2001 02:38:52

Quote:
> So go read the man page for rsh.

> sheesh. Its not *that* hard you know.

Uhhh... because I had my answer if 5 minutes instead of 10? :-)

A condescending "read the man page" is probably the least helpful piece of
"advice" one can offer.

True, I have not yet looked at Linux docs on rsh.

Why not?

Because 25 years of experience with so-called "documentation" is that it is
largely comprehensible- at first reading- only to those who already
understand it. In short, it's usable as reference, but lousy as tutorial.
I'd be surprised if this were any exception.

Because asking questions of those who HAVE read the books and have
experience elicits not only the fundamentals (i.e., commands and options)
which one can read in documents, but also COROLLARY conclusions and
experiences, examples, ideas and concerns. Try to find THESE on "man
pages."

So, I'll keep asking questions. And occasional helpful souls will keep
says "read the man pages."

Life goes on. :-)

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **Philip Armstro** » Mon, 29 Jan 2001 04:16:47

Quote:>> So go read the man page for rsh.

>> sheesh. Its not *that* hard you know.

>Uhhh... because I had my answer if 5 minutes instead of 10? :-)

It's not our job to do yours for you. You'll learn a lot more if you
do it yourself. Trust me on this one. You asked what tool you could
use, and were given a few possible answers. The rest is up to you.

Quote:>A condescending "read the man page" is probably the least helpful piece of
>"advice" one can offer.

Bleating in newsgroups without bothering to do *any* reading of your
own first, even when pointed in the right direction invites
condescension.

Quote:>True, I have not yet looked at Linux docs on rsh.

sigh.

Quote:>Why not?

>Because 25 years of experience with so-called "documentation" is that it is
>largely comprehensible- at first reading- only to those who already
>understand it. In short, it's usable as reference, but lousy as tutorial.
>I'd be surprised if this were any exception.

Here you go:

RSH(1) System Reference Manual RSH(1)

NAME
rsh - remote shell

SYNOPSIS
rsh [-Kdnx] [-k realm] [-l username] host [command]

DESCRIPTION
Rsh executes command on host.

Rsh copies its standard input to the remote command, the standard output
of the remote command to its standard output, and the standard error of
the remote command to its standard error. Interrupt, quit and terminate
signals are propagated to the remote command; rsh normally terminates
when the remote command does. The options are as follows:

Looks pretty clear to me. Yes, some man pages can be clear as mud. The
man page for rsh isn't one of them.

Quote:>So, I'll keep asking questions. And occasional helpful souls will keep
>says "read the man pages."

Funny that. Perhaps you should listen to them from time to time.

Phil

--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt

by **OpenMin** » Mon, 29 Jan 2001 12:33:38

I'm looking for answers to questions, not contention- so if you need the
last word, go for it.

Some responses were helpful, some were not. If you don't feel like
answering-- don't. It's not your job to tell others what their "job" should
be.

Thanks to all those who responded without an "attitude."

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

by **OpenMin** » Mon, 29 Jan 2001 16:05:24

My thanks for the helpful responses- especially the examples of working code
and strategies. Cuts many hours off the still-enormous task I have ahead.

You folks are terrific!

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Very Computer

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?

Cluster/Distributed Computing with rsh?