[erlang-questions] Quick connect to another node with erl

[Tomas Morstein]

----- Original Message -----
> Od: "Loïc Hoguin" <essen@REDACTED>
> Komu: "Tomas Morstein" <tmr@REDACTED>
> Kopie: erlang-questions@REDACTED
> Odeslané: Úterý, 22. Leden 2013 23:05:33
> Předmět: Re: [erlang-questions] Quick connect to another node with erl
> 
> On 01/22/2013 11:02 PM, Tomas Morstein wrote:
> > Dne neděle, 20. ledna 2013 21:16:20 UTC+1 Jachym Holecek napsal(a):
> >
> >     # Ward Bekker (TTY) 2013-01-20:
> >      > I want to connect to the shell on node bar@REDACTED My
> >      > current
> >     solution
> >      > (see below) needs some user switch commands. Is there a way
> >      > using CL
> >      > arguments? Couldn't find a mention in the erl man page.
> >
> >     Yes, using -remsh, like this:
> >
> >        Terminal 1:
> >              # erl -sname foo -setcookie abc
> >              Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4]
> >     [rq:4] [async-threads:0] [kernel-poll:false]
> >
> >              Eshell V5.8.5  (abort with ^G)
> >
> >
> > It's worth to note that `remsh' should be used with extra care,
> > especially
> > when it comes to connecting live production systems.
> > Time by time, it happens (at least to me) that someone accidentally
> > issues `q().' instead of ^G-q. The result is remote node shutdown
> > what
> > is usually not what we wanted to do, although `q().' is good habit
> > otherwise :)
> >
> > That's why I would recommend you to use extra VM options to
> > restrict
> > the shell and block at least `q()' and friends (well, I've never
> > seen
> > anybody who accidentally typed `init:stop()' yet :-) ).
> 
> init:stop() seems to stop the local node, not the remote node.

Are you sure? Depends on what you define as remote and local.
Everything you write is executed on the remote node which is
local from the point of view of the (remote) shell.

The way I think it works is that `remsh' creates just a new
shell on the remote node which is redirected to another
console, and should deliver the very same behaviour as if
you're directly on the remote machine's console and start
another shell job via ^G followed by `s' command.

At the other hand, if you make ^G and `s' on the "local"
node (that one which was started with -remsh), you can
get shell which is truly local to that secondary node.

If you know about any tricks how to detect the original
node which is just remsh'd somewhere, let me know, because
it may be useful for improving the restricted_shell module.

[I would like to have ability to issue `q().' only on
the master console and block it on all the others.
Now we have it that `q().' is disabled at all unless
you issue something like `shell_restriction_policy:unlock ()'
and then the `q()' becomes allowed.]


A little example at the end:

tmr@REDACTED:~$ erl -sname foo -setcookie abc
Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9  (abort with ^G)
(foo@REDACTED)1> 
(foo@REDACTED)1> 
(foo@REDACTED)1> node ().
foo@REDACTED
(foo@REDACTED)2> 

tmr@REDACTED:~$ erl -sname boo -setcookie abc -remsh foo@REDACTED
Erlang R15B (erts-5.9) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9  (abort with ^G)
(foo@REDACTED)1> 
(foo@REDACTED)1> node ().
foo@REDACTED
(foo@REDACTED)2> 
User switch command
 --> j
   1* {foo@REDACTED,shell,start,[]}
 --> s
 --> j
   1  {foo@REDACTED,shell,start,[]}
   2* {shell,start,[]}
 --> c 2
Eshell V5.9  (abort with ^G)
(boo@REDACTED)1> 
User switch command
 --> c 1

(foo@REDACTED)2>