Norbert Hartl

mostly brackets and pipes

Easy Remote Gemstone

Gemstone does not come with a graphical user interface. But it provides installable tools for smalltalks that have one. I use pharo for connecting to my local installed gemstone in order to develop applications. The finished application is deployed on a dedicated remote server. Even the deployment I do by connecting to the production image and updating the software (I like to use something from the commandline that uses topaz but didn’t find time).

The remote server has an active firewall like the most machines out there. I don’t really like to put holes in the firewall just for the connection with the client. If you like to do than you have to know that the netldi process of gemstone dynamically chooses a port number for connections. You need to pin it to a certain port. You can do this by starting the process this way

startnetldi -g -p50331:50331 50330

The -p parameter tells the netldi to only use the port number 50331 for connections. The last parameter (50330) is optional and configures the port for the netldi itself. If omitted the default is chosen (50337). I change the port to be able to have two sessions open at once. My installation on the laptop has a default configuration and uses the default port. To use the changed port you have to alter your session configuration and add the netLDI call.

OGApplianceSessionDescription newname: 'remote';
    stoneHost: '';
    stoneName: 'seaside';
    netLDI: '50330';

using the firewall option

Now that the port are pinned you can open two ports 50330 and 50331 on the firewall and should be able to connect to the remote gemstone.

using a ssh tunnel

You don’t need to alter your firewall settings in order to be able to connect. The ssh programme has everything you need: ssh tunnel.

ssh -C 
    -o CompressionLevel=9 
    -L 50330: 
    -L 50331: 
    -L 9090: 
    -R 8080:  

The -C option is for compressing the data that is transmitted. An easy way to speed up the connection. I’m not sure if the -o parameter brings any benefit but I’m sure it does not harm, so…The important switch is the -L. You can read it this way (taking the first -L line). Open a socket on port 50330 on my site (laptop) and when someone connects send the data over the existing ssh connection. On the other end of this connection send everything to the host on port 50330 (that is the remote host itself and it is send to the remote gemstone).

The first -L is because I reconfigured the netldi. The second one is the port range we configured the netldi process at the beginning. Your session config in the gemtools has now to look like this

OGApplianceSessionDescription newname: 'remote';
    stoneHost: 'localhost';
    stoneName: 'seaside';
    netLDI: '50330';

The stone host has changed to localhost. The -L 9090:localhost:9090 enables me to use the admin tools of seaside on the remote side. By opening a browser on http://localhost:9090/seaside/config I have access to admin tools quite easy.

The -R 8080:localhost:8080 I use for deployment. -L stands for “forward” tunnel and -R stands for “reversed” tunnel. It works like this. With this switch it opens a socket on the remote side on port 8080. Everything that connects to this socket is forwarded over the existing ssh connection. On my end (laptop) of the connection every data is send to localhost on port 8080. On my laptop on port 8080 there listens an apache that is configured for WebDAV. The configured directory of the WebDAV is the same that is configured in Monticello on my local image. Whenever I save a new version it is available on this WebDAV server. On the remote side the Monticello is configured for http://localhost:8080/. The connects from Monticello or routed over the ssh tunnel to my local WebDAV server.

The round trips of saving a version and updating on the remote side is drastically reduced. With the ssh line put into a shell script and attached to a clickable icon in my menu I can start everything with just two clicks: on for the image and one for the tunnel