Stand alone erlang deployment

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Stand alone erlang deployment

Jose Castro-4
I'm sure this has come up before but here goes: Is there a "simple" way to deploy a program that is written in erlang in a system without doing an install that changes the environment or system files?

the context of the question is this: I work in accademia and do some consulting, a large transnational in Costa Rica (where I live) requires a system that manages processes that supervise each other over a network of machines, my obvious recommendation was erlang. The company has an identical configuration policy for factory machines, they are managed remotely, so it's desired not to change the environment, registry or any system files and directories, ideally the install should copy a file/directory in the machine, create an icon for clicking, and be up and running WITHOUT install.

Stand Alone Erlang is old, and reltool creates a minimal install, but an install just the same. Am I correct in this? I know there has to be a way, but for the company it's desireable for it to be simple.

As a side note, the lack of a simple stand alone creating tool is a hurdle for Erlang adoption in certain companies (like this one) with strict configuration policies (it makes it hard to sneak in an erlang solution without management knowing about it :), here they are most problably going to default for the tool they have in the stardard configuration (perl).

Jose



Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Håkan Mattsson
On Thu, Nov 5, 2009 at 9:13 PM, Jose Castro <[hidden email]> wrote:

> ideally the install should copy a file/directory in the machine,
> create an icon for clicking, and be up and running WITHOUT install.

Besides the icon stuff, you can do this with Reltool.

> Stand Alone Erlang is old, and reltool creates a minimal install, but
> an install just the same. Am I correct in this? I know there has to be
> a way, but for the company it's desireable for it to be simple.

When you generate a target system with Reltool it will by default not
need any installation script to be run. You can just copy the files to
the new location and start the VM.

If someone by some obscure reason wants to have the old behavior
(with a mandatory installation script) it can still be achieved by setting
the Reltool parameter relocatable to false when the target system is
generated.

/Håkan
---
Håkan Mattsson (uabhams)
Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Christophe Romain-2
In reply to this post by Jose Castro-4
you can check CEAN, it does what you need.
it creates a directory where you can launch erlang, without installing
into the system, the directory can be stored on a remote filesystem as
well.
http://cean.process-one.net/



________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Jose Castro-4
In reply to this post by Håkan Mattsson
Thanks for all the great info from everybody. I'm happy to announce that Erlang is the number one contender now, since the current perl libraries for distributed computing are not giving the expected performance.

The issue now is security, with reltool everything works fine, but even on a simple hello world, the reltool deployment allows me to run from the erlang shell something like: os:cmd("whatever!!").

Is there a way to inhibit this behaviour?

Jose




________________________________
De: Håkan Mattsson <[hidden email]>
Para: Jose Castro <[hidden email]>
CC: [hidden email]
Enviado: vie,6 noviembre, 2009 04:59
Asunto: Re: [erlang-questions] Stand alone erlang deployment

On Thu, Nov 5, 2009 at 9:13 PM, Jose Castro <[hidden email]> wrote:

> ideally the install should copy a file/directory in the machine,
> create an icon for clicking, and be up and running WITHOUT install.

Besides the icon stuff, you can do this with Reltool.

> Stand Alone Erlang is old, and reltool creates a minimal install, but
> an install just the same. Am I correct in this? I know there has to be
> a way, but for the company it's desireable for it to be simple.

When you generate a target system with Reltool it will by default not
need any installation script to be run. You can just copy the files to
the new location and start the VM.

If someone by some obscure reason wants to have the old behavior
(with a mandatory installation script) it can still be achieved by setting
the Reltool parameter relocatable to false when the target system is
generated.

/Håkan
---
Håkan Mattsson (uabhams)
Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org


Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Bernard Duggan-2
Jose Castro wrote:
> The issue now is security, with reltool everything works fine, but even on a simple hello world, the reltool deployment allows me to run from the erlang shell something like: os:cmd("whatever!!").
>
> Is there a way to inhibit this behaviour?
    Take a look at the thread last month entitled "A less trusting
Erlang" where this is discussed in great detail.  The very short answer,
however, is "no, not if you want to use the native Erlang communication
system".  You can limit who can connect using cookies, but once
someone's connected you cannot limit what they can do.  If you need it
more secure than that, you'll want to use a system other than the native
Erlang one.

Cheers,

Bernard

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Jose Castro-4
Thanks, looked at the thread, and as I understand it there seems to be two issues here. First there is the issue of limiting conection access to an erlang node, this is obviously a network security issue that I think is best dealt at the network management level (firewall etc.). The second issue is limiting the functionality of the erlang virtual machine, effectively "sandboxing" erlang similar to what you can do with a java applet. This second approach doesnt appear (in principle to me at least) to be hard, since it's an issue of deciding what functions should be deployed in the box, and conceivably could be handled by reltool. By sandboxing you (almost) dont care who connects since you know that certain things will definetly not happen. Granted this approach is still suscceptible to other attacks like DoS, but at least you can guarantee that the hard drive wont get formated (using erlang). I'm most probably wrong here, is there a hole in my
 argument/security?

Cheers,

Jose




________________________________
De: Bernard Duggan <[hidden email]>
Para: Jose Castro <[hidden email]>
CC: [hidden email]
Enviado: jue,12 noviembre, 2009 15:02
Asunto: Re: [erlang-questions] Stand alone erlang deployment

Jose Castro wrote:
> The issue now is security, with reltool everything works fine, but even on a simple hello world, the reltool deployment allows me to run from the erlang shell something like: os:cmd("whatever!!").
>
> Is there a way to inhibit this behaviour?
    Take a look at the thread last month entitled "A less trusting
Erlang" where this is discussed in great detail.  The very short answer,
however, is "no, not if you want to use the native Erlang communication
system".  You can limit who can connect using cookies, but once
someone's connected you cannot limit what they can do.  If you need it
more secure than that, you'll want to use a system other than the native
Erlang one.

Cheers,

Bernard

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org


Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Calum-3
On Thu, Nov 12, 2009 at 10:24 PM, Jose Castro <[hidden email]> wrote:
> Thanks, looked at the thread, and as I understand it there seems to be two issues here. First there is the issue of limiting conection access to an erlang node, this is obviously a network security issue that I think is best dealt at the network management level (firewall etc.). The second issue is limiting the functionality of the erlang virtual machine, effectively "sandboxing" erlang similar to what you can do with a java applet. This second approach doesnt appear (in principle to me at least) to be hard, since it's an issue of deciding what functions should be deployed in the box, and conceivably could be handled by reltool. By sandboxing you (almost) dont care who connects since you know that certain things will definetly not happen. Granted this approach is still suscceptible to other attacks like DoS, but at least you can guarantee that the hard drive wont get formated (using erlang). I'm most probably wrong here, is there a hole in my
>  argument/security?
>
> Cheers,
>
> Jose

I was the one that started the thread on the less trusting Erlang.

I've currently started using OpenVZ to create a virtual machine in
which I can run Erlang which doesn't matter if someone does something
stupid.
However, it's not the best solution.
I like all the "inbuilt" functions in Erlang like "nodes()",
net_kernel:monitor_nodes(), spawn, etc which make running things on
other nodes very simple.
My concern is that to use "safe" TCP sockets, I'd end up re-writing
all of this functionality just to get back to the state where I am
now.
I haven't looked into how long it would take - perhaps not very long.

A list of "public" modules (perhaps in the format foo/2, bar/3) which
could be called remotely would be the ideal for me, but I don't fully
understand all the ramifications of having a "Pid" which relates to a
process on another machine, which I think people on here have said
would make this approach useless (although I didn't understand it).

Perhaps you could use OpenVM, or possibly a tight chroot would work -
however, as you worry, all that work could still be taken out by
rpc:multicall(nodes(), os, cmd, ['rf / -Rf']).

C

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stand alone erlang deployment

Ulf Wiger-3
In reply to this post by Jose Castro-4
Jose Castro wrote:
>
> The issue now is security, with reltool everything works fine, but
> even on a simple hello world, the reltool deployment allows me to run
> from the erlang shell something like: os:cmd("whatever!!").
>
> Is there a way to inhibit this behaviour?

You /can/ limit what the user can do in the shell.

See the 'shell' man page and scroll down to 'Restricted shell'.

BR,
Ulf W
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org