|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
|
|
Stand alone erlang deploymentI'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 |
|
|
Re: Stand alone erlang deploymentOn Thu, Nov 5, 2009 at 9:13 PM, Jose Castro <idiay_tuanis@...> 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 |
|
|
Re: Stand alone erlang deploymentyou 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 |
|
|
Re: Stand alone erlang deploymentThanks 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 <hawk.mattsson@...> Para: Jose Castro <idiay_tuanis@...> CC: erlang-questions@... 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 <idiay_tuanis@...> 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 |
|
|
Re: Stand alone erlang deploymentJose 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 |
|
|
Re: Stand alone erlang deploymentThanks, 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 <bernie@...> Para: Jose Castro <idiay_tuanis@...> CC: erlang-questions@... 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 |
|
|
Re: Stand alone erlang deploymentOn Thu, Nov 12, 2009 at 10:24 PM, Jose Castro <idiay_tuanis@...> 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 |
|
|
Re: Stand alone erlang deploymentJose 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 |
| Free embeddable forum powered by Nabble | Forum Help |