Throw away all 32bit code from the installation code ...

Arrg,

I would like to say: JUST have a 64 bit installation routine and NOTHING
should be done via Pharo 32 bit code.

We have to install Gemstone for our project on a customer computer using
SuSE ... and even the installation process fails, because pharo is using
this or that and all these libraries are not available.

That is so time consuming and for the administrators it does not look
like very professional ...

Is it possible to install 3.2.7 in a way like the old 3.1.0.6 was ?

Marten


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

GLASS mailing list wrote

Arrg,

I would like to say: JUST have a 64 bit installation routine and NOTHING
should be done via Pharo 32 bit code.

We have to install Gemstone for our project on a customer computer using
SuSE ... and even the installation process fails, because pharo is using
this or that and all these libraries are not available.

That is so time consuming and for the administrators it does not look
like very professional ...

Is it possible to install 3.2.7 in a way like the old 3.1.0.6 was ?

It's not clear what you are really asking. There are always the instructions available on this page [https://gemtalksystems.com/products/gs64/]. Just use the Installation Guide specific to your target system.

Marten


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

Am 08.09.2015 um 18:06 schrieb Richard Sargent via Glass:

>> Is it possible to install 3.2.7 in a way like the old 3.1.0.6 was ?
>
> It's not clear what you are really asking. There are always the instructions
> available on this page [https://gemtalksystems.com/products/gs64/]. Just use
> the Installation Guide specific to your target system.
>

 I use the installServer.sh script (from the glass site) and actually I
get an installed Gemstone server 3.2.7 .



 Marten


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

Marten,

The installGemStone script just installs the bits for the product. I
assume you are just looking for the product bits  when you say "like the
old 3.1.0.6 was" and you aren't interested in using the other
gsDevKitHome scripts?

Pharo is used in a number of the other gsDevKitHome scripts so that I
could avoid implementing some of the more complicated logic in bash.

If you want to use the other gsDevKitHome scripts then we need to solve
the Pharo 32 bit library installation problem ...
I've not used SuSE before but we do have a SuSE 12 machine in house and
if you give me a couple of days I can probably figure out the SuSE
incantations needed to install the necessary 32 bit library support ...

If you don't care about using the other gsDevKitHome scripts then the
installGemStone should do the trick ...

Let me know if installGEmStone solves your immediate problem ...

Dale

On 09/08/2015 09:57 AM, [hidden email] via Glass wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale,

I would like to see a clear 64 bit only (headless) installation for the
core system - like installGemStone.sh offers.

And no: I like to read the installation documentation but I would never
really like to execute it to make a manual installation of Gemstone but
its important to have this information somewhere to known what is needed
to install a running Gemstone.

The basic maintenance scripts (however this set is defined) should be
also runnable out of the box.

Then on top of all that the tODE infrastructure (or gsDevKitHome)
installation can be used - what ever someone likes to implement. The
customer can then decide if he prefers the additional tools or if he
prefers a more simple installation.

Another thing I have to solve is the Proxy problem. If the server has
only http traffic behind a proxy server the whole infrastructure of the
Gemstone world seems to break down. I'm not sure how to solve this  and
the solution posted here in the news tody: I simply do not understand
that. Perhaps I consider to change Gofer to use native external commands
like "wget" to use the build-in proxy support ....


Marten




Am 08.09.2015 um 21:41 schrieb Dale Henrichs via Glass:

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

On 09/08/2015 02:02 PM, [hidden email] wrote:
> Dale,
>
> I would like to see a clear 64 bit only (headless) installation for the
> core system - like installGemStone.sh offers.
That makes sense ...
>
> And no: I like to read the installation documentation but I would never
> really like to execute it to make a manual installation of Gemstone but
> its important to have this information somewhere to known what is needed
> to install a running Gemstone.
I think this is being provided by the osPrereqs scripts on the dev
branch. The README[1] is being rewritten with an eye towards improving
the information content. If you could read through it and give me (us)
specific examples of where we are missing information that would help to
improve the documentation for everyone.

I'm not exactly sure what point you are making here, but now is a very
good time to give us feedback...

I will mention that I will be making a fairly significant structural
change to the gsDevKitHome project structure ... I have decided split
out the todeClient structure/scripts into a separate project/download ..
The main motivation is to solve some of the problems posed by
installing/using a todeClient on Windows. By splitting out the
todeClient, I will be able to write windows-specific "shell" scripts
that have a chance of actually working:) In addition there were a few
other things that were confusing because the client and server directory
structure was shared and those should be cleaned up as well....


[1]
https://github.com/GsDevKit/gsDevKitHome/tree/dev#open-source-development-kit-for-gemstones-64-bit-
>
> The basic maintenance scripts (however this set is defined) should be
> also runnable out of the box.
All of the scripts are runnable out of the box, modulo the os -specific
prerequisites...

>
> Then on top of all that the tODE infrastructure (or gsDevKitHome)
> installation can be used - what ever someone likes to implement. The
> customer can then decide if he prefers the additional tools or if he
> prefers a more simple installation.
There are indeed multiple levels in the current gsDevKitHome
architecture and tODE is not required for all of the scripts ...  my
take away from this is that I should consider perhaps one more
segmentation of the scripts/functionality that makes it the distinction
between scripts that are based on tODE and those that are not ...
>
> Another thing I have to solve is the Proxy problem. If the server has
> only http traffic behind a proxy server the whole infrastructure of the
> Gemstone world seems to break down.
This is a very good point and I am very interested in addressing this
problem.
> I'm not sure how to solve this  and the solution posted here in the news tody: I simply do not understand
> that.
Okay ...  I don't quite understand what you don't understand:)

When we worked at VMWare I was able to get both Pharo and GemStone to
function behind a proxy, so I know that it is possible ... Could you
share with me the information that you have about the proxy and I will
tell you the Smalltalk expressions that you should execute to get
GemStone and Pharo working from behind the proxy ...

With that said, I am interested in supporting proxied environments in  
gsDevKitHome at the infrastructure level, so that each stone (and pharo
vm)  is prepared to work behind the proxy at stone (pharo image)
creation time ...

For example I seem to recall[2] that the environment variables
http_proxy and https_proxy are used by programs like wget to correctly
connect to the http proxy instead of connecting to the host/port named
in the url ...I think it is reasonable to use those same env variables
to store the proxy info in the pharo image and GemStone repository so
that going forward both Pharo and GemStone will honor the proxy
information ...

Of course there should be additional discussion on these details (I'm
vary open to alternate solutions), so I've opened a bug on github[3] to
cover any ongoing discussion/decisions for this problem.

[2] http://stackoverflow.com/questions/11211705/setting-proxy-in-wget
[3] https://github.com/GsDevKit/gsDevKitHome/issues/85

> Perhaps I consider to change Gofer to use native external commands
> like "wget" to use the build-in proxy support ....
if you volunteer to replace Gofer with wget and provide a Smalltalk
library that runs in Pharo and GemStone then I will gladly welcome your
contributions ... but I don't think that it's necessary to go that far
... we can talk in more detail in the issue

I would ask that anyone else who has experience or opions about working
with proxies and Smalltalk join us in the discussion on github.

Dale


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

On 9/8/15 5:14 PM, Dale Henrichs wrote:
Just to sketch out an idea in more detail ... please let me know if I am
on the right track from your perspective ...

So from the very top level the segmentation can be emphasized by having
a set of options for the installServer script that allow you to
determine the type of stone you want ([-b|-g|-t] options):

USAGE: installServer [-h] [-f] [-b|-g|-t] [-s <snapshot-file-path>]
<stone-name> <gemstone-version>
...
OPTIONS
   -b
      create a base GemStone stone - use $GEMSTONE/bin/extent0.dbf. No
additional
      code loaded and no tODE client created.
   -h
      display help
   -f
      force creation of stone and tode image
   -g
      create a GLASS/GsDevKit stone - use
$GEMSTONE/bin/extent0.seaside.dbf. Update
      repository using gsUpgrader and no tODE client created
   -s <snapshot-file-path>
      Path to snapshot file used to create stone. Path may be a relative
file path.
   -t
      [DEFAULT] create a tODE stone - use
$GEMSTONE/bin/extent0.seaside.dbf. Update
      repository using gsUpgrader, then install tODE and create a tODE
client.

The same set of options ([-b|-g|-t]) would be available for the
createStone script. The start* and stop* can be used for all stones .

Does this make sense?

Dale

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

Marten,

Am I off the hook for having to figure out the formula for installing
the 32 bit libs for Pharo on SuSE (sooner rather than later)?

On 9/8/15 12:41 PM, Dale Henrichs wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Am 09.09.2015 um 02:14 schrieb Dale Henrichs:

>
> When we worked at VMWare I was able to get both Pharo and GemStone to
> function behind a proxy, so I know that it is possible ... Could you
> share with me the information that you have about the proxy and I will
> tell you the Smalltalk expressions that you should execute to get
> GemStone and Pharo working from behind the proxy ...

Well, its simple. I get a proxy address with a port - and all stuff must
run via this proxy.

Marten


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

I was asking the question in the context of this comment:



On 09/10/2015 01:22 AM, [hidden email] via Glass wrote:
> Am 09.09.2015 um 02:14 schrieb Dale Henrichs:
>
>> When we worked at VMWare I was able to get both Pharo and GemStone to
>> function behind a proxy, so I know that it is possible ... Could you
>> share with me the information that you have about the proxy and I will
>> tell you the Smalltalk expressions that you should execute to get
>> GemStone and Pharo working from behind the proxy ...
> Well, its simple. I get a proxy address with a port - and all stuff must
> run via this proxy.

Okay then to turn on http proxying in your GemStone stone you would do
the following:

   HTTPSocket
     httpProxyServer: 'proxy address';
     httpProxyPort: port.
   System commitTransaction.

After executing those commands Gofer will use the http proxy for all
proxy requests .... There is a similar technique that can be applied in
a Pharo vm.

I opened the bug[1] because I would expect that gsDevKitHome could run
the above commands as part of the stone creation process based on the
settings of the http_proxy and https_proxy or ???.

In your environment are you using http_proxy and https_proxy?

Dale

[1] https://github.com/GsDevKit/gsDevKitHome/issues/85
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Both is possible, but http_proxy is the usual one.


Marten

Am 10.09.2015 um 18:59 schrieb Dale Henrichs via Glass:

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

Marten,

Thanks.

One more question .... by using the HTTPSocket trick, the proxy
credentials are persisted in the repository and if one were to change
the http_proxy the persisted state would not be automatically changed
... do you think that persisting the credentials is an acceptable
approach or do we need to have a strategy to accomodate changes in the
proxy settings?

Dale

On 09/10/2015 10:01 AM, [hidden email] wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass