[GemStone-Smalltalk] How to configure GS/S 6.1.2 through a firewall (blast from the past)

[Normand Mongeau]

Yes that makes perfect sense. And what just enlightened me was the “from the
perspective of the Gem”. That’s what was missing in the equation here.

 

Many thanks for your help, now if I point to the WAN address for
gemnetobject, and the local address for the server, I can log on remotely.

 

Normand 

 

 

From: James Foster [mailto:james.foster at gemtalksystems.com] 
Sent: mardi, 25 février 2014 15:14
To: Normand Mongeau
Cc: gemstone-smalltalk at lists.gemtalksystems.com
Subject: Re: [GemStone-Smalltalk] How to configure GS/S 6.1.2 through a
firewall (blast from the past)

 

On Feb 25, 2014, at 11:30 AM, Normand Mongeau <
<mailto:nmongeau at videotron.ca> nmongeau at videotron.ca> wrote:





I need to give access to our database to someone who is offsite.

 

So in essence you’re saying that this is not possible, unless I open all
ports on my firewall?

 

This is certainly possible, and in fact is the most common use case for an
enterprise client/server application. The confusion rests in selecting the
hostname (or IP address) for the Gem vs. for the Stone. The connection from
the GCI client to the Gem can be over the WAN (even the Internet). In that
case you need to have two well-known ports open on your Gem host (as we have
discussed). Once you have a Gem then you tell the Gem how to connect to the
Stone.

 

The tricky part (that makes sense when you understand it but is initially
quite confusing) is that the address you give for the Stone is from the
perspective of the Gem, not from the perspective of the GCI client. So, in
the following screenshot (taken from the Jade login window for 6.1.x), the
Gem is addressed externally (“ <http://myGemHost.gemtalksystems.com>
myGemHost.gemtalksystems.com") while the Stone is addressed internally
(“localhost"). If you are going to run the Gem and the Stone on the same
machine, then localhost is just the right thing to use! This will be the Gem
host, not the GCI client host.

 

Note that the name lookup done by the Gem need not make sense to the GCI
client. So if I had multiple machines in my data center, I could have a
public hostname mapped to the Gem host, and a private hostname mapped to the
Stone host. So the Gem could be at  <http://seaside.gemtalksystems.com>
seaside.gemtalksystems.com (with the name lookup done by the GCI client OS),
while the Stone could be at myStone.local (and the Gem host will do a name
lookup on ‘myStone.local’). Also, you could use a local address range (e.g.,
192.168.1.x for the Stone). 

 

Just remember that the GCI client is not responsible for connecting to the
Stone, it just tells the Gem where to find the Stone—and the most common
location is localhost.

 

Does that make sense?

 

James

 

cid:image001.png at 01CF323C.FA7C2420

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20140225/102243da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30546 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20140225/102243da/attachment-0001.png>