Smalltalk › Pharo › Pharo Smalltalk Developers

[Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

34 messages Options

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

2017-01-30 13:14 GMT+01:00 Norbert Hartl <[hidden email]>:

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

I am working on it. It happens when server starts from command line. Probably I do something wrong in my TCPServer implementation.

Zinc server works fine. So I have example where there is no problems.

philippeback

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by NorbertHartl

How can we start PharmIDE server so that it binds to localhost only on the server?

Phil

On Mon, Jan 30, 2017 at 1:14 PM, Norbert Hartl <[hidden email]> wrote:

Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <[hidden email]>:

On 30 Jan 2017, at 11:43, Norbert Hartl <[hidden email]> wrote:

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <[hidden email]>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <[hidden email]>:
Have you considered security at all yet? Leaving a port open which allows
arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary.
Currently there is two important issues which must be handled manually:
- security. You can manage it by VPN or SSH
- distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones.
Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would).

Right. To make it a bit more concrete. If we use the example of Denis on port 40423 then a simple

$ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com

will open a forwarding tunnel so you can connect with the PharmIDE client using

PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423)

and you'll end up connecting to your remote image.

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

Norbert

thanks again for doing that.

Norbert

Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process".
Just want to share these thoughts with you :).

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

2017-01-30 14:16 GMT+01:00 [hidden email] <[hidden email]>:

How can we start PharmIDE server so that it binds to localhost only on the server?

I do not know if it is possible from Pharo. Anybody know example with "Socket newTCP"?

With "external OS tools" you can always hide port from outside world. Try to google it.

Sven Van Caekenberghe-2

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

> On 30 Jan 2017, at 15:39, Denis Kudriashov <[hidden email]> wrote:
>
>
> 2017-01-30 14:16 GMT+01:00 [hidden email] <[hidden email]>:
> How can we start PharmIDE server so that it binds to localhost only on the server?
>
> I do not know if it is possible from Pharo. Anybody know example with "Socket newTCP"?
> With "external OS tools" you can always hide port from outside world. Try to google it.

It is in your image already !

See ZnServer>>#bindingAddress: and ZnSingleThrededServer>>#initializeServerSocket

In use in ZnServerTests>>#testEchoLocalInterface

You will understand immediately, it is quite easy.

Remember that once you start like that, you will only be able to connect locally.

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

2017-01-30 15:45 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:

> 2017-01-30 14:16 GMT+01:00 [hidden email] <[hidden email]>:
> How can we start PharmIDE server so that it binds to localhost only on the server?
>
> I do not know if it is possible from Pharo. Anybody know example with "Socket newTCP"?
> With "external OS tools" you can always hide port from outside world. Try to google it.

It is in your image already !

See ZnServer>>#bindingAddress: and ZnSingleThrededServer>>#initializeServerSocket

In use in ZnServerTests>>#testEchoLocalInterface

You will understand immediately, it is quite easy.

Remember that once you start like that, you will only be able to connect locally.

Thank's Sven. I will add suitable method to start Pharm server

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by Denis Kudriashov

2017-01-30 13:36 GMT+01:00 Denis Kudriashov <[hidden email]>:

2017-01-30 13:14 GMT+01:00 Norbert Hartl <[hidden email]>:
Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

I am working on it. It happens when server starts from command line. Probably I do something wrong in my TCPServer implementation.
Zinc server works fine. So I have example where there is no problems.

Ok. It is fixed now. Just load stable version.

Reason was related to my post about two listener sockets.

TCPServer is registered on startup list and it recreates listener socket when image resumes.

From command line it happens twice. First instance is created from command line handler which registers it on startup list. But when command line is evaluated Pharo start process startup list which lead to duplicated socket creation.

Now TCPServer handles it properly.

NorbertHartl

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by NorbertHartl

Am 30.01.2017 um 13:14 schrieb Norbert Hartl <[hidden email]>:

Am 30.01.2017 um 11:49 schrieb Sven Van Caekenberghe <[hidden email]>:

On 30 Jan 2017, at 11:43, Norbert Hartl <[hidden email]> wrote:

Am 30.01.2017 um 11:36 schrieb Denis Kudriashov <[hidden email]>:

Hi Sean.

2017-01-28 19:06 GMT+01:00 Sean P. DeNigris <[hidden email]>:
Have you considered security at all yet? Leaving a port open which allows
arbitrary code to be executed reomotely seems very dangerous...

Norbert already answer you. I just put little summary.
Currently there is two important issues which must be handled manually:
- security. You can manage it by VPN or SSH
- distributed garbage collection. You need perform "remotePharo disconnect" (or "PrmRemotePharo disconnectAll") at the end of your working session. It cleans server and client from distributed objects.

Last issue is at high priority in my todo. When I implement it unused distributed objects will be collected automatically like local ones.
Security option can be added too. Seamless design allows to it. Probably It can be simple switch to SecureSocketStream instead of SocketStream.

My advize for security is two-fold. The first reason not to apply security features to seamless is that it complicates the code base with a feature that is done better elsewhere. The second reason is that one big reason why this can be unusable is latency. A high latency makes it very hard to use the toolkit. So removing everything adding latency should be avoided. Security is from the image perspective one of those things.

Explicit/manual SSH port forwarding is easy & safe. Doing it deliberately makes you more aware of what you are doing, which is very necessary in this case because of the huge danger involved (giving away full image control). But it will add its own latency (just like TLS would).

Right. To make it a bit more concrete. If we use the example of Denis on port 40423 then a simple

$ ssh -L 40423:localhost:40423 pharmide-server.anydomain.com

will open a forwarding tunnel so you can connect with the PharmIDE client using

PrmRemoteIDE connectTo: (TCPAddress ip: #[127 0 0 1] port: 40423)

and you'll end up connecting to your remote image.

Unfortunately I couldn't test it because I installed the PharmIDE on my linux machine and it does not work. When starting the image a listening port is opened but 5 seconds later the port closes automatically. Has anyone tested it on a linux machine?

As a followup I need to say that it works now and it works like a charm. I installed one PharmIDE image on my server and did the SSL tunneling. Latency was very good or to say it was only that high that you can notice working on a remote image. I did only small tests but everything was working as expected. I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful.

Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.

Bravo!

Norbert

Norbert

thanks again for doing that.

Norbert

Important thing here that I am really satisfied with Seamless design which I made. It was driven by tests which means that it only addresses existing features but allow stable evolution to new functionality. And I thing it is most important property of any system: provide stable way how to evolve. System can be broken and very buggy at some point but if design and tests are stable then system will move. By stable I mean "do not require big changes for any new bug or feature", "always iterative process".
Just want to share these thoughts with you :).

EstebanLM

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

On 1 Feb 2017, at 09:41, Norbert Hartl <[hidden email]> wrote:

Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.

there is not reason why it shouldn’t work… backend is reported to be working… but well, you are free to test it :)

Esteban

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by NorbertHartl

2017-02-01 9:41 GMT+01:00 Norbert Hartl <[hidden email]>:

Great job!!! A dream comes true. If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.

Thank's. UFFI works in my simple tests like "LibC system: 'ls'"

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by NorbertHartl

2017-02-01 9:41 GMT+01:00 Norbert Hartl <[hidden email]>:

I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful.

I know what needs to be done from my point of view. But what exactly missing from your perspective?

Torsten Bergmann

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by Denis Kudriashov

>>Great job!!! A dream comes true.
>>If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.
>Thank's. UFFI works in my simple tests like "LibC system: 'ls'"

Did you check out my OSRaspbian project loadable from the catalog? It uses
UFFI and is working on Pi.

Bye
T.

Denis Kudriashov

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

2017-02-01 13:44 GMT+01:00 Torsten Bergmann <[hidden email]>:

Did you check out my OSRaspbian project loadable from the catalog? It uses
UFFI and is working on Pi.

I have it in mind but not try it yet :)

NorbertHartl

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by Torsten Bergmann

> Am 01.02.2017 um 13:44 schrieb Torsten Bergmann <[hidden email]>:
>
>>> Great job!!! A dream comes true.
>>> If there is a working UFFI for ARM then we have a pretty decent stack for IoT times.
>> Thank's. UFFI works in my simple tests like "LibC system: 'ls'"
>
> Did you check out my OSRaspbian project loadable from the catalog? It uses
> UFFI and is working on Pi.
>
Ok, thanks. As the next attempt is using an Raspberry pi it seems to be a perfect fit

Norbert

NorbertHartl

Re: [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

In reply to this post by Denis Kudriashov

Am 01.02.2017 um 11:56 schrieb Denis Kudriashov <[hidden email]>:

2017-02-01 9:41 GMT+01:00 Norbert Hartl <[hidden email]>:
I think in the future we need to work out how we can inspect a remote object while using GT features. A lot of stuff in GT inspector is pretty useful. But then I assume it is really chatty at the same time making the remote usage less useful.

I know what needs to be done from my point of view. But what exactly missing from your perspective?

I'm not sure, yet. But what I do is inspecting SeamlessProxy objects which won't enable extra tabs and views for the object. And if it does I don't know if the communication overhead is not too hardcore. In my dreams there is a remote image without GTTools and a GTenabled image on my laptop and still I can use GT features on remote objects. I know but … hey you asked! ;)

Norbert