[Glass] Newbie on GLASS - Hello world fail

[Mariano Martinez Peck via Glass]

On Tue, Sep 22, 2015 at 10:59 PM, Jupiter Jones <jupiter.jones at mail.com>
wrote:

> Hi Mariano,
>
> I’m not sure if I understand you exactly, so here’s what I’m doing...
>
> devKit_ldi      50378/tcp               # DevKit GemStone Network Long
>> Distance Information (LDI)
>>
>> I typically don’t need to add this entry in development - ie. dev and
>> stone on the same machine. The only time I add this entry is when I want my
>> local tODE to connect to a remote stone. I add the stoneName_ldi to both
>> the local and remote /etc/services to ensure they both lookup the same port
>> number
>>
>
> mmmmm I how do you connect via tODE to such a remote stone? I guess
> todeClient running in the server and doing X forward?
> Of netldi port forwarding? If the later...then I don't understand…
>
>
> I think I’m just using the standard GemStone behaviour of specifying the
> stone and gem hosts in the connection profile.
>
> I don’t typically run todeClient on deployed servers although it is
> installed for running tODE scripts.
>
> I have Pharo / tODEClient running locally on my Mac on the dev network,
> and a number of headless deployment hosts, each with identical tODE
> install, and identical /opt/git/<project> directories for local loading of
> source. One group of virtualised hosts typically has one stone host and a
> number of gem hosts (which can also be the same host on small installs)
>
> Also, my development network can open any port at the data centre so I
> don’t actually know what ports are being used between local and remote
> networks.
>
>
Hi Jupiter,

Thanks for your answer. That's clearly the difference. I assumed you were
going via  SSH tunneling for the port forwarding.
But you are saying ports are open.

Ok, forget what I asked.


> Because when I run todeClient in my client machine , connecting to a
> remote stone, I had to specify the rest of the ports to netldi, that is not
> only the one you specify in argument -P but also the range of ports of
> argument -p. And of course I have to port forward those as well.
>
>
> The only difference for me was using fully qualified host names for
> connecting to the remote server, rather than “localhost” for connecting to
> my dev stone.
>
> TDSessionDescription {
> #name : ‘production - Project 1',
> #stoneHost : ‘stone.project.example.co’, <——— SPECIFY THE NAME/ADDRESS OF
> THE REMOTE STONE HOST
> #stoneName : ‘devKit',
> #gemHost : ‘gems.project.example.co’, <——— SPECIFY THE NAME/ADDRESS OF
> THE HOST ON WHICH TO LAUNCH THE GEM
> #netLDI : ‘devKit_ldi',
> #gemTask : 'gemnetobject',
> #userId : 'DataCurator',
> #password : 'swordfish',
> #osUserId : nil,
> #osPassword : nil,
> #dataDirectory : nil,
> #backupDirectory : '/opt/git/gsDevKitHome/gemstone/stones/devKit/backups/',
> #gemstoneVersion : '3.2.4',
> #gciLibraryName : nil,
> #adornmentColor : nil,
> #serverGitRoot : '/opt/git/gsDevKitHome/gemstone/stones/devKit/git',
> #serverTodeRoot : '/opt/git/gsDevKitHome/tode'
> }
>
> as long as all the machines have the /etc/services entry, this seems to
> work as expected.
>
> That’s it.
>
> Is that how you’re doing it?
>
> Cheers,
>
> J
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150923/a8cd8386/attachment.html>