[Glass] Ubuntu 14.04 ethernet static ip and GemTools login

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list


On Wed, Mar 25, 2015 at 11:30 AM, Dale Henrichs <[hidden email]> wrote:
Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

That's very cool. You can add the alias I pasted above that really improves performance (it uses a special cipher and a few other things).
The other point besides installing X in the server, is installing all libs required by Pharo, which sometimes it's a bit complicated in Linuxes of 64 bits. 

 

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional

On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
Yes a lot of my time documenting gsDevKitHome 1.0.0 has been spent on working through all of these issues ... like getting Freetype installed, ssh, the X client, etc.

The pharo launcher work is pretty cool, in terms of installing the Pharo prerequisitesm but it does not work on ubuntu 12.04 (still used by travis and others) so I still have to work out the prereqs myself ...

Speaking of which does anything additional need to be installed to get the arcfour and blowfish-cbc options working?

It looks like I've come down with another cold so I'll be working from home again ... so I'll be able to see how these additional options work ... and I will update the doc to include this information ...

Thanks!

Dale

On 3/25/15 7:36 AM, Mariano Martinez Peck wrote:


On Wed, Mar 25, 2015 at 11:30 AM, Dale Henrichs <[hidden email]> wrote:
Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

That's very cool. You can add the alias I pasted above that really improves performance (it uses a special cipher and a few other things).
The other point besides installing X in the server, is installing all libs required by Pharo, which sometimes it's a bit complicated in Linuxes of 64 bits. 

 

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional

On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--




--


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
In reply to this post by GLASS mailing list
Dale, Martin,


Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

OK i follow this different tack.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):


I submit this:

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860

i go into my  gestionale directory

# cd to your gestionale directory   

I submit this:
                                     
. defStone.env  

and submit this adding _ldi at the end.
                                                                       
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale_ldi

The use localhost in your session description, :


I update the GemTools session and the login work fine.

OK.

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

For understund:

The netstat -ltpn report:

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::55127 :::* LISTEN 1948/stoned
tcp6 0 0 :::25 :::* LISTEN -
tcp6 0 0 :::57858 :::* LISTEN 2224/netldid
tcp6 0 0 127.0.0.1:54786 :::* LISTEN 1950/shrpcmonitor
tcp6 0 0 ::1:54786 :::* LISTEN 1950/shrpcmonitor

After close the ssh connection i test the login with GemTools classic session :

OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';

It don't works the GemTools go into loop.

But the server show  netldi listening on that address  and 57858 port.

as i report in hold email with not static ip ( where netldi is into 50377 )

Dale, Martin,

i restart the system with  /etc/network/interfaces file  set to:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto p2p1
iface p2p1 inet dhcp

Now the  scandella@scandella:~$ netstat -ltpn

command report:

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:9060            0.0.0.0:*               LISTEN      830/topaz       
tcp        0      0 0.0.0.0:9061            0.0.0.0:*               LISTEN      838/topaz       
tcp        0      0 0.0.0.0:9062            0.0.0.0:*               LISTEN      833/topaz       
tcp        0      0 0.0.0.0:9063            0.0.0.0:*               LISTEN      835/topaz       
tcp        0      0 0.0.0.0:9064            0.0.0.0:*               LISTEN      832/topaz       
tcp        0      0 0.0.0.0:9065            0.0.0.0:*               LISTEN      834/topaz       
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 :::50377                :::*                    LISTEN      1479/netldid    
tcp6       0      0 :::52490                :::*                    LISTEN      1438/stoned     
tcp6       0      0 127.0.0.1:34671         :::*                    LISTEN      1440/shrpcmonitor
tcp6       0      0 ::1:34671               :::*                    LISTEN      1440/shrpcmonitor

The GemTools open on 50377  works fine.

It's not very strange?

Thanks,

Dario

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
Dario,

First, I am under the impression that you are able to successfully connect your remote GemTools using ssh port forwarding and this session description:

  OGCustomSessionDescription new
    name: 'Scandella3106 gestionale';
    stoneHost: 'localhost';
    stoneName: 'gestionale';
    gemHost: 'localhost';
    netLDI: '57858';

So you are in business again?

Secondly, I understand that the when using the following session description:

  OGCustomSessionDescription new
    name: 'Scandella3106 gestionale';
    stoneHost: 'scandella';
    stoneName: 'gestionale';
    gemHost: 'scandella';
    netLDI: '57858';

an attempt to connect GemTools _from the local host_, you have trouble, correct?

If the above assumptions are correct, then I will guess that the problem is that the netldi is not listening on the interface associated with the host scandello ... but I am not an expert.

However, I do know that if you want to connect GemTools running on the local host and using X11 forwarding, that you should use the exact same session description that works for ssh port forwarding:

  OGCustomSessionDescription new
    name: 'Scandella3106 gestionale';
    stoneHost: 'localhost';
    stoneName: 'gestionale';
    gemHost: 'localhost';
    netLDI: '57858';

When you use port forwarding you fool the netldi and stone into thinking that the GemTools session is running on the local host, so the same session description should work when you are ACTUALLY running on the local host ...

Dale

On 3/25/15 10:55 AM, Dario Trussardi via Glass wrote:
Dale, Martin,


Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

OK i follow this different tack.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):


I submit this:

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860

i go into my  gestionale directory

# cd to your gestionale directory   

I submit this:
                                     
. defStone.env  

and submit this adding _ldi at the end.
                                                                       
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale_ldi

The use localhost in your session description, :


I update the GemTools session and the login work fine.

OK.

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

For understund:

The netstat -ltpn report:

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato PID/Program name
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::55127 :::* LISTEN 1948/stoned
tcp6 0 0 :::25 :::* LISTEN -
tcp6 0 0 :::57858 :::* LISTEN 2224/netldid
tcp6 0 0 127.0.0.1:54786 :::* LISTEN 1950/shrpcmonitor
tcp6 0 0 ::1:54786 :::* LISTEN 1950/shrpcmonitor

After close the ssh connection i test the login with GemTools classic session :

OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';

It don't works the GemTools go into loop.

But the server show  netldi listening on that address  and 57858 port.

as i report in hold email with not static ip ( where netldi is into 50377 )

Dale, Martin,

i restart the system with  /etc/network/interfaces file  set to:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto p2p1
iface p2p1 inet dhcp

Now the  scandella@scandella:~$ netstat -ltpn

command report:

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:9060            0.0.0.0:*               LISTEN      830/topaz       
tcp        0      0 0.0.0.0:9061            0.0.0.0:*               LISTEN      838/topaz       
tcp        0      0 0.0.0.0:9062            0.0.0.0:*               LISTEN      833/topaz       
tcp        0      0 0.0.0.0:9063            0.0.0.0:*               LISTEN      835/topaz       
tcp        0      0 0.0.0.0:9064            0.0.0.0:*               LISTEN      832/topaz       
tcp        0      0 0.0.0.0:9065            0.0.0.0:*               LISTEN      834/topaz       
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 :::50377                :::*                    LISTEN      1479/netldid    
tcp6       0      0 :::52490                :::*                    LISTEN      1438/stoned     
tcp6       0      0 127.0.0.1:34671         :::*                    LISTEN      1440/shrpcmonitor
tcp6       0      0 ::1:34671               :::*                    LISTEN      1440/shrpcmonitor

The GemTools open on 50377  works fine.

It's not very strange?

Thanks,

Dario

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

[Glass] GemTools on remote server

GLASS mailing list
In reply to this post by GLASS mailing list
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Ubuntu 14.04 ethernet static ip and GemTools login

GLASS mailing list
In reply to this post by GLASS mailing list
On 03/25/2015 11:29 AM, Dale Henrichs via Glass wrote:

> Dario,
>
> First, I am under the impression that you are able to successfully
> connect your remote GemTools using ssh port forwarding and this session
> description:
>
>   OGCustomSessionDescription new
>     name: 'Scandella3106 gestionale';
>     stoneHost: 'localhost';
>     stoneName: 'gestionale';
>     gemHost: 'localhost';
>     netLDI: '57858';
>
> So you are in business again?
>
> Secondly, I understand that the when using the following session
> description:
>
>   OGCustomSessionDescription new
>     name: 'Scandella3106 gestionale';
>     stoneHost: 'scandella';
>     stoneName: 'gestionale';
>     gemHost: 'scandella';
>     netLDI: '57858';
>
> an attempt to connect GemTools _from the local host_, you have trouble,
> correct?
>
> If the above assumptions are correct, then I will guess that the problem
> is that the netldi is not listening on the interface associated with the
> host scandello ... but I am not an expert.

From the netstat output, netldi is only listening on the loopback
address, which is localhost. If 'scandella' resolves to the machine's
external address (192.168.1.10) then you won't be able to contact a
netldi under that name.

Regards,

-Martin
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
In reply to this post by GLASS mailing list
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

scandella@scandella:/opt/GemTools/GemTools-1.0-beta.8.7-3101x.app$ ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Dario,

Use `sudo netstat -p` to find out process is using that port ...

Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
In reply to this post by GLASS mailing list

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

`sudo apt-get install ia32-libs` on 12.04 did the trick for me ... but ia32-libs does not appear to be supported on 14.04 .... more research needed ...

Dale


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
In reply to this post by GLASS mailing list

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
On mac, apparently `netstat -p` doesn't list the process associated with port ...  so try `/usr/sbin/lsof -i :58199` ... just guessing because I don't have my mac in the office and just going by what google is telling me ...

Dale

On 03/27/2015 10:42 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
In reply to this post by GLASS mailing list
Dario,

I think I have stumbled across the magic for getting GemTools to run on 14.04. Try this:

  sudo apt-get install libx11-6:i386 libsm6:i386

I had done some other installs along the way, but with no success ... Since I've pretty much trashed my ubuntu vms during this excercise, I will have to start with fresh ubuntu installs to verify exactly what is needed and that will be a little while ...

When I'm done I will verify and include the GemTools information in the soon to be released gsDevKitHome 1.0.0 documentation:)

Dale
On 03/27/2015 10:42 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Okay in addition to the published 14.04 prereqs[1] (including X11 client prereqs[2]), the following two packages need to be loaded for GemTools to work on Ubuntu14.04:

  sudo apt-get install sane:i386
  sudo apt-get install libsm6:i386

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-x11-client-optional
On 03/27/2015 11:51 AM, Dale Henrichs wrote:
Dario,

I think I have stumbled across the magic for getting GemTools to run on 14.04. Try this:

  sudo apt-get install libx11-6:i386 libsm6:i386

I had done some other installs along the way, but with no success ... Since I've pretty much trashed my ubuntu vms during this excercise, I will have to start with fresh ubuntu installs to verify exactly what is needed and that will be a little while ...

When I'm done I will verify and include the GemTools information in the soon to be released gsDevKitHome 1.0.0 documentation:)

Dale
On 03/27/2015 10:42 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Dale,

i think to update the ubuntu server to:

sudo apt-get -y update
sudo apt-get -y install curl
sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so
sudo apt-get -y install gdb
sudo apt-get -y install libfreetype6:i386
sudo apt-get -y install pstack
sudo /bin/su -c "echo 'kernel.yama.ptrace_scope = 0' >>/etc/sysctl.d/10-ptrace.conf"


sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

sudo apt-get install sane:i386
  sudo apt-get install libsm6:i386

But when i do the command:

scandella@scandella:/opt/GemTools/GemTools-1.0-beta.8.7-3101x.app$ ./GemTools-1.0-beta.8.7-3101x.sh

the system answer the same error:
could not find module vm-display-X11
Annullato (core dump creato)

Considerations ?

Thanks,

Dario

Okay in addition to the published 14.04 prereqs[1] (including X11 client prereqs[2]), the following two packages need to be loaded for GemTools to work on Ubuntu14.04:

  sudo apt-get install sane:i386
  sudo apt-get install libsm6:i386

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-x11-client-optional
On 03/27/2015 11:51 AM, Dale Henrichs wrote:
Dario,

I think I have stumbled across the magic for getting GemTools to run on 14.04. Try this:

  sudo apt-get install libx11-6:i386 libsm6:i386

I had done some other installs along the way, but with no success ... Since I've pretty much trashed my ubuntu vms during this excercise, I will have to start with fresh ubuntu installs to verify exactly what is needed and that will be a little while ...

When I'm done I will verify and include the GemTools information in the soon to be released gsDevKitHome 1.0.0 documentation:)

Dale
On 03/27/2015 10:42 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] GemTools on remote server

GLASS mailing list
Dario,

I don't have a clue at this point, since that was the formula that worked for me ...

Below is  the script that I used to install all of the prerequisites using the `-G -X -o ubuntu14.04` options...

Dale


#! /bin/bash
#=========================================================================
# Copyright (c) 2015 GemTalk Systems, LLC [hidden email].
#=========================================================================

echo "================="
echo "   GsDevKit script: $(basename $0) $*"
echo "================="

set -e # exit on error

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] -o [ubuntu12.04|ubuntu14.04] [-X] [-G]

Install os-specific required packages:
  - 32 bit libraries
  - git
  - curl
  - unzip
  - ssl
  - PAM

and os-specific optional packages:
  - X11

OPTIONS
  -h
     display help
  -o
     select os
  -G
     install GemTools and the GemTools prerequisites
  -X
     if present, X11 client installed
 

EXAMPLES
  ./$(basename $0) -h
  ./$(basename $0) -o ubuntu12.04
  ./$(basename $0) -X -o ubuntu12.04
  ./$(basename $0) -G -X -o ubuntu12.04

HELP
}

installUbuntuPackages(){
    sudo apt-get -y update
    sudo apt-get -y install curl
    sudo apt-get -y install git
    sudo apt-get -y install zip
    sudo apt-get -y install unzip
    sudo apt-get -y install libpam0g:i386
    sudo apt-get -y install libssl1.0.0:i386
    sudo apt-get -y install gcc-multilib libstdc++6:i386
    sudo apt-get -y install gdb
    sudo apt-get -y install libfreetype6:i386
    sudo apt-get -y install pstack
    sudo /bin/su -c "echo 'kernel.yama.ptrace_scope = 0' >>/etc/sysctl.d/10-ptrace.conf"
    if [ "${X11client}x" = "1x" ] ; then
      sudo apt-get -y install libgl1-mesa-dev:i386
      sudo apt-get -y install libxcb-dri2-0:i386
    fi
    if [ "${gemtools}" = "true" ] ; then
      sudo apt-get -y install sane:i386
      sudo apt-get -y install libsm6:i386
      if [ ! -d "GemTools-1.0-beta.8.7-31x.app" ] ; then
        wget http://seaside.gemtalksystems.com/squeak/GemTools-1.0-beta.8.7-310x.zip
        unzip GemTools-1.0-beta.8.7-31x.zip
      fi
    fi
}

os=""
X11client=""
gemtools=""

while getopts "ho:GX" OPT ; do
  case "$OPT" in
    G) gemtools="true";;
    h) usage; exit 0 ;;
    o) os="${OPTARG}" ;;
    X) X11client="1";;
    *) usage; exit 1 ;;
  esac
done
shift $(($OPTIND - 1))

case "$os" in
  ubuntu12.04)
    installUbuntuPackages
    sudo ln -f -s /lib/i386-linux-gnu/libpam.so.0 /lib/libpam.so.0
    sudo ln -f -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so
  ;;
  ubuntu14.04)
    installUbuntuPackages
    sudo ln -f -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so
    ;;
  *) usage; exit 1;;
esac

On 03/28/2015 04:12 AM, Dario Trussardi via Glass wrote:
Dale,

i think to update the ubuntu server to:

sudo apt-get -y update
sudo apt-get -y install curl
sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so
sudo apt-get -y install gdb
sudo apt-get -y install libfreetype6:i386
sudo apt-get -y install pstack
sudo /bin/su -c "echo 'kernel.yama.ptrace_scope = 0' >>/etc/sysctl.d/10-ptrace.conf"


sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

sudo apt-get install sane:i386
  sudo apt-get install libsm6:i386

But when i do the command:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer the same error:
could not find module vm-display-X11
Annullato (core dump creato)

Considerations ?

Thanks,

Dario

Okay in addition to the published 14.04 prereqs[1] (including X11 client prereqs[2]), the following two packages need to be loaded for GemTools to work on Ubuntu14.04:

  sudo apt-get install sane:i386
  sudo apt-get install libsm6:i386

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-x11-client-optional
On 03/27/2015 11:51 AM, Dale Henrichs wrote:
Dario,

I think I have stumbled across the magic for getting GemTools to run on 14.04. Try this:

  sudo apt-get install libx11-6:i386 libsm6:i386

I had done some other installs along the way, but with no success ... Since I've pretty much trashed my ubuntu vms during this excercise, I will have to start with fresh ubuntu installs to verify exactly what is needed and that will be a little while ...

When I'm done I will verify and include the GemTools information in the soon to be released gsDevKitHome 1.0.0 documentation:)

Dale
On 03/27/2015 10:42 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Use `sudo netstat -p` to find out process is using that port ...

On the Ubuntu server into  ssh    the  sudo netstat -p

seems not occupy  the 57858 port.

Can the problem is into mackBook ?

The macBook command  netstat   report:

tcp4 14 0 localhost.57858 localhost.51370 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51361 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51323 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51234 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51187 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51177 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51167 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51142 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51123 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51120 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51109 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51065 CLOSE_WAIT tcp4 14 0 localhost.57858 localhost.51063 CLOSE_WAIT

What i need do ?

Thanks,

Dario


Dale

On 03/27/2015 09:52 AM, Dario Trussardi via Glass wrote:

Dale,

Dario,

Not sure right now ... Pharo1.1 must have a different set of prerequisites ... it will take a bit of time for me to figure that out, I suppose you could try running GemTools over the lan using the ssh port forwarding until I figure out the missing prerequisites ...

No after reboot the Ubuntu system server,  the GemTools  on macBook don't work,

 because when i open the ssh session with :

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the 57858 i already in use.

See the point:

----------------------------------------------
Another questions about macBook GemTools problem.

Thanks,

Dario

Dale

On 03/27/2015 09:24 AM, Dario Trussardi via Glass wrote:
Dale,

Dario,

Good questions.

As part of my work for the soon to be released gsDevKitHome 1.0.0, I have taken a pretty close look at the prerequisites[2] and I've got a detailed list of the prerequisites for Ubuntu14.04[2]. I think I've added a couple of prereqs since you've done an install ... mainly in the areas of support for ptrace (C stack straces) and freetype fonts for pharo.  Check you list against the required prereqs[5].

I don't verify the prerequisite for now.


It looks like you have the X11 Client already installed on the server, so you will need to install GemTools on the server. You should just be able to scp the GemTools zip file over to the server and go ...

I open ssh session with:

ssh -X scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:57860

And submit:

export GS_HOME=/opt/oodb/gsDevKitHome
export PATH=$GS_HOME/bin:$PATH

$GS_HOME/bin/todeClient

It work fine and i can submit tODE command on: gestionale    environment


When i  submit:

[hidden email] ./GemTools-1.0-beta.8.7-3101x.sh

the system answer:
could not find module vm-display-X11 Annullato (core dump creato)

Any idea about it? 

-------------------------------------------------------------------------------------------------

Another questions about macBook GemTools problem.

after reboot the server Ubuntu system now when i open a ssh on my macBook with:

meetingto:~ dtr$ ssh  scandella -l scandella -L 57858:localhost:57858 -L 57860:localhost:5786

the system answer:


bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57858
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 57860
Could not request local forwarding.
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-24-generic x86_64)

A this point when i open the GemTools on my macBook and open the session the system answer:

Error: Unable to create a GemStone session.
NetLDI service '57858' not found on node 'localhost' port 57858 :
 For further information about login failures, check the gem log file

I don't understund because 57858 i already in use after reboot the system.

Before use the ssh -X ..................  all worked well,  at the login the 57858 is free  and GemTools session work fine.


Any considerations?

Thanks,
Dario


For the best performance using GemTools, I think that X11 forwarding[3] (instructions included) is probably the best option. In my limited experience using X11 forwarding (with compression) with tODE, the update delays are not nearly as annoying as the pretty long round trip induced delays seen when using GemTools over the WAN.

On the other hand, I think that SSH port forwarding[4] is the best option for tODE. tODE does a pretty good job of limiting the number of round trips so having snappier window updates is appreciated.

Does that clarify things for you?

Dale 

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/osPrereqs.md
[2] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md
[3] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/x11ForwardingForRemoteDisplays.md
[4] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md
[5] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#install-basic-prerequisites-required

On 03/26/2015 05:11 AM, Dario Trussardi via Glass wrote:
Dale, Mariano,

for now my server tODE environment is installed into my office and i don't have performance problem with GemTools.

But the next week the server will installed on remote office of my client and i'm interested to work on it from my home office on WAN.

But i don't have clear that i need to install on the server.

The server is based on Ubuntu 14.04 server  and for now i installed:

sudo apt-get -y install git
sudo apt-get -y install unzip
sudo apt-get -y install curl
sudo apt-get -y install libpam0g:i386
sudo apt-get -y install libssl1.0.0:386
sudo apt-get -y install libssl1.0.0:i386
sudo apt-get -y install -qq gcc-multilib libstdc++6:i386
sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so

sudo apt-get -y install libx11-6:i386
sudo apt-get -y install libgl1-mesa-dev:i386
sudo apt-get -y install libxcb-dri2-0:i386

What other i need to load ? 

What i need to load for GemTools on the server ( and relative prerequisite ) ?

After installed all, how i can test the GemTools load on the server with X11 forwarding ?

Into another e-mail Dale write: 

Things are a bit snappier if I use port forwarding, but the advantage of XLL forwarding is that you don't have to install GemTools on the remote system...

But relative performance are good?

What is the best solutions, i'm confusing?

Thanks for any help, considerations.

Dario

Mariano,

You have a point that ssh tunneling for X may be a better option ...

Dario, When we get the port forwarding option working, you can give X11 forwarding a go.

You'd need to install the X client on your server and I have another little writeup (that's part of the soon to be release gsDevKitHome 1.0.0) that details the X packages that need to be installed for X11 client [1], since you don't need the full blown X server for X11 forwarding.

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/osPrereqs/ubuntu14.04.md#x11-client-optional
On 3/25/15 7:14 AM, Mariano Martinez Peck wrote:
Dario, 

I did not read the full email.... but If you allow me a quick recommendation (maybe offtopic here), I would not use remote GemTools. It is really too slow and becomes unusable. It is far easier and faster to use SSH with X forward and run GemTools locally in your server. So in GemTools you simply put localhost etc... and then do ssh -X etc..

And you can even improve performance of SSH with X by doing:

alias ssh-x='ssh -c arcfour,blowfish-cbc -XC'

then ssh-x myserver...

Best, 



On Wed, Mar 25, 2015 at 11:02 AM, Dale Henrichs via Glass <[hidden email]> wrote:
Dario,

I'll have to wait for Martin to chime in with what he thinks may be going on now ...

but, I'm inclined to take a different tack to address your GemTools remote login problem.

You have ssh installed and you can log into the remote machine using ssh, so you should be able to setup ssh port forwarding for GemTools.

I've done a writeup on this as part of the soon to be released gsDevKitHome 1.0.0[1].

In a nutshell you do the following (after setting up the static ip address):

ssh scandella -l scandella -L 57858:localhost:57858  -L 57860:localhost:57860
# cd to your gestionale directory                                        
. defStone.env                                                                    
$GEMSTONE/bin/startnetldi -a scandella -g -p 57860:57860 -P 57858 gestionale

The use localhost in your session description, :

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'localhost';
stoneName: 'gestionale';
gemHost: 'localhost';
netLDI: '57858';

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/portForwardingForRemoteLogins.md

On 3/25/15 3:07 AM, Dario Trussardi via Glass wrote:
Dale,
 
Dario,

Replace the line:

  $GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

with a direct call to the startnetldi as described in my last email:

  $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                              $GEMSTONE_LOGDIR/${stoneName}_ldi.log \
                                              ${stoneName}_ldi

BUUUUUUT,


OK i do this test, i report what i do:


before we get to the point where we are trying to debug the startNetldi script, let's verify that you can start a netldi that works with your remote GemTools. So:

  1. login in as the user that is running your stone processes
I login as  scandella
  2. cd $GS_HOME/gemstone/stones/<stone-name>
i go to my  gestionale  stone   directory
  3. execute the following bash script:
      .  defStone.env
i do the command:     . defStone.env ( with a blank after the. )

  4. then manually start the netldi:
      $GEMSTONE/bin/startnetldi -g -a $USER -A192.168.1.10 -l \
                                                  $GEMSTONE_LOGDIR/${GEMSTONE_NAME}_ldi.log \
                                                   ${GEMSTONE_NAME}_ldi
i do the command :
    $GEMSTONE/bin/startnetldi -g -a scandella -A192.168.1.10 -l $GEMSTONE_LOGDIR/gestionale_ldi.log \gestionale_ldi 
It Report: 

GemStone version '3.1.0.6'
startnetldi[Info]: Starting GemStone network server 'gestionale_ldi'.
startnetldi[Info]: GEMSTONE is: '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/product'.
startnetldi[Info]: GEMSTONE_NRS_ALL is: '#dir:$GEMSTONE_LOGDIR#log:%N%P.log'.
startnetldi[Info]: Log file is '/opt/oodb/gsDevKitHome/gemstone/stones/gestionale/logs/gestionale_ldi.log'.
startnetldi[Info]: GemStone server 'gestionale_ldi' has been started, process 4336 .


Now the scandella@scandella:~$ netstat -ltpn

command report :

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non propri
 non saranno mostrate, per visualizzarle tutte bisogna avere privilegi di root.)
Connessioni Internet attive (solo server)
Proto CodaRic CodaInv Indirizzo locale        Indirizzo remoto       Stato       PID/Program name
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::25                   :::*                    LISTEN      -               
tcp6       0      0 127.0.0.1:57858         :::*                    LISTEN      4336/netldid    
tcp6       0      0 ::1:57858               :::*                    LISTEN      4336/netldid    
tcp6       0      0 192.168.1.10:57858      :::*                    LISTEN      4336/netldid    
tcp6       0      0 127.0.0.1:54660         :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 ::1:54660               :::*                    LISTEN      4248/shrpcmonitor
tcp6       0      0 :::57323                :::*                    LISTEN      4246/stoned  

  5. test your remote GemTools

I update the GemTools session:

  OGCustomSessionDescription new
name: 'Scandella3106 gestionale';
stoneHost: 'scandella';
stoneName: 'gestionale';
gemHost: 'scandella';
netLDI: '57858';
.............
...........

It don't work, when i do the GemTools login the system go into loop

 until i stoped the: gestionale_ldi 4336 process

Thanks,

Dario

When we get GemTools working with a manually started netldi, then you can try changing the startNetldi script.

Dale

On 03/24/2015 04:02 PM, Dario Trussardi via Glass wrote:
Dale, Martin,

On 03/24/2015 01:02 PM, Dario Trussardi via Glass wrote:

What do you intend with:  did this fix it for you?

For now i don't resolve the problem.

OK, thanks. From your previous message I wasn't sure whether you were
still seeing the problem.


Considerations?

The netldi is only listening on the IPv6 localhost address. If you want
to use GemTools from another machine, it must also listen on the
192.168.1.10 address. I'm not sure why it isn't already listening on
that address, but you should be able to fix it by adding -A192.168.1.10
to your startnetldi command line (see the man page for startnetldi).

Once you've started netldi with that option, netstat -ltpn should show
netldi listening on that address.

First: my environment is based on tODE and i think to change the file  startNetldi

adding some parameter to the last line.

#! /bin/bash
#=========================================================================
# Copyright (c) 2014 GemTalk Systems, LLC <[hidden email]>.
#=========================================================================

usage() {
  cat <<HELP
USAGE: $(basename $0) [-h] <stone-name>
 Start the netldi process for the given stone.

OPTIONS
  -h display help

EXAMPLES
  $(basename $0) -h
  $(basename $0) kit

HELP
}

set -e # exit on error
if [ "${GS_HOME}x" = "x" ] ; then
  echo "the GS_HOME environment variable needs to be defined"; exit 1
fi
source ${GS_HOME}/bin/shFunctions
getOpts_help $@

if [ $# -ne 1 ]; then
  usage; exit 1
fi
stoneName=$1

echo "starting netldi $stoneName"

# set up stone environment
stonePath=$GS_HOME/gemstone/stones/$stoneName
pushd $stonePath >& /dev/null
source $stonePath/stone.env
popd >& /dev/null

$GS_HOME/bin/tode startnetldi $stoneName -A192.168.1.10

But with this information when i do the command :   startNetlidi gestionale   i don't solve the problem.

The  netstat -ltpn    don't report  netldi listening on that address.


Second: in addition  the service are  started with Daemontools Gemstone service and  i don't know where i need add the -A parameter.

Anyone know informations about it ?

Thanks,

Dario



Regards,

-Martin



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
123