VAST Seaside problem at startup

334 views
Skip to first unread message

Totally Objects

unread,
May 11, 2016, 3:33:51 PM5/11/16
to VA Smalltalk
I have recently installed 8.6 as a clean install. I have loaded the Seaside feature and run up my code that was working under earlier versions of 8. When I try to log into the main Seaside control web page I get the following come up.


I know nothing about the Seaside internals. Can anyone tell me how to get this sorted please?


Seth Berman

unread,
May 11, 2016, 5:03:53 PM5/11/16
to VA Smalltalk
Hello,

Just to make sure I understand, when you say 8.6...do you mean the latest release 8.6.2 or the actual 8.6 release?
I ask because 8.6.2 will have the OpenSSL key generation ability for https connections. 
If VA OpenSSL connectivity isn't setup properly (meaning you don't have openssl libraries available or the version of OpenSSL < 1.0.0), then Seaside will be unable to generate secure keys.

-- Seth

I would debug the method WASecureKeyGenerator

Seth Berman

unread,
May 11, 2016, 6:16:34 PM5/11/16
to VA Smalltalk
Sorry...posted too soon.
I would debug the method WASecureKeyGenerator class>>startUp and verify #canSeed is failing

Totally Objects

unread,
May 12, 2016, 4:58:34 AM5/12/16
to VA Smalltalk
I have 8.6.2 installed. It makes no difference if I put a break in WASecureKeyGenerator startup because this never fires. I still get the same error. Are you saying that there is no simple way to install and run Seaside in 8.6.2 without going through other security processes? If that is so then it is a shame because Seaside was easy and good to use in my previous version.

Totally Objects

unread,
May 12, 2016, 6:51:16 AM5/12/16
to VA Smalltalk
Well something is badly wrong. I run Windows under Parallels on my Mac. I have just installed Windows 10 on a clean install and then loaded 8.6.2.  I get the same starting error. Surely this can't be right?


On Wednesday, May 11, 2016 at 8:33:51 PM UTC+1, Totally Objects wrote:

Totally Objects

unread,
May 12, 2016, 7:34:26 AM5/12/16
to VA Smalltalk
I have now tested this on Windows 7, Windows 10 and Windows Server 2012 and I get the same error. What am I doing wrong as it can't be your Seaside implementation, can it?

David

Louis LaBrunda

unread,
May 12, 2016, 8:35:37 AM5/12/16
to VA Smalltalk
Hi David,

I haven't been following this problem very closely so, allow me to just throw an idea out there that could be very off base.  It sounds like it could be a packaging problem.  I haven't used Seaside for a while but as I remember things it was very hard to package in that lots of classes would get packaged out.  That is complicated by the fact that Seaside catches lots of errors and ignores them because it doesn't want to blow up it is get bad user input.  I don't remember how but you should be able to turn on some debugging option that will at least report more of what is going on.

Lou

Totally Objects

unread,
May 12, 2016, 9:57:46 AM5/12/16
to VA Smalltalk
Lou. This is just starting up Seaside in a clean image. I haven't done any packaging or anything.  I installed a new Windows 10 and then installed 8.6.2. I start up an adaptor and then point a browser at http://localhost:8080. I then get this error so I can't even see the main Seaside page. This can't be right so either I am doing something stupid or forgetting something.

David

Seth Berman

unread,
May 12, 2016, 11:08:16 AM5/12/16
to VA Smalltalk
Hello,

I can reproduce this.
Looks like Seaside wants to generate random numbers to use as keys for session caches.  If a secure RNG (via OpenSSL) is not available in Vast then it produces this walkback...even for http.
If it's not found at startup, then it installs a 'WANoSecureKeyGeneratorAvailable' which produces an error when asked for a key.

To get around this, try changing the key generator method to the following below.  This will force it to fallback to using EsRandom as the RNG.
In the meantime, we will revisit this internally to see if we can disconnect the OpenSSL requirement from the session cache keys.
Thanks for bringing this up....please let me know if the change described below solves your issue.

WANoSecureKeyGeneratorAvailable>>keyOfLength: anInteger
^super keyOfLength: anInteger

-- Seth

John O'Keefe

unread,
May 12, 2016, 11:14:35 AM5/12/16
to VA Smalltalk
David -

Beginning in VAST 8.6.2 Seaside prereqs the new Smalltalk Crypto support. The Crypto support requires OpenSSL DLLs (see Where do I get OpenSSL Libraries from and how do I set them up for VA Smalltalk 8.6.2 and above?). If these libraries are not available, this is the error you will get.

John


On Wednesday, May 11, 2016 at 3:33:51 PM UTC-4, Totally Objects wrote:

Seth Berman

unread,
May 12, 2016, 11:43:12 AM5/12/16
to VA Smalltalk
Hello all,

I believe I described how to "work around" the issue in my previous post and this is adequate for playing around with Seaside in the absence of OpenSSL.
However, I would NOT recommend this solution in any sort of deployment or usage as an internet web server for http (and obviously https).
EsRandom is not, and was never really intended to be, a secure RNG which means that reverse engineering its algorithm, by folks with the skills in this area, would probably not be too terribly difficult.

-- Seth

Totally Objects

unread,
May 12, 2016, 11:53:38 AM5/12/16
to VA Smalltalk
That fix worked. Thanks. I am staggered that no one has brought this up! As I am using this with a Riak NoSQL database at the back which just answers anything on a certain port then security wouldn't seem to be my biggest concern - grin.

At the grand old age of 71 I am working towards a project for my last year at the Open University so, I would hope that you would sort this before I get there next year :-)

Thanks again.

David

Totally Objects

unread,
Oct 11, 2017, 3:26:10 PM10/11/17
to VA Smalltalk
Just to let you know. This is still in 9.0. Wast it supposed to be fixed? Or should were going down the route described by John?

David

Seth Berman

unread,
Oct 11, 2017, 3:43:53 PM10/11/17
to VA Smalltalk
Hello David,

The preferred route is the one that John described.

-- Seth 

Totally Objects

unread,
Oct 12, 2017, 7:08:33 AM10/12/17
to VA Smalltalk
OK. I have installed the dlls and everything seems to be fine. Thanks for the prompt to do that.

It does seem that the 64bit DLLs are still called 32 though as in
CRYPTO_LIB=libeay32
SSL_LIB=ssleay32

Part from that, I have taken out the patch and I am OK. My Seaside is running fine.

Thanks to you and John for your help.

David

Seth Berman

unread,
Oct 12, 2017, 9:22:08 AM10/12/17
to VA Smalltalk
Hi David,

Great, glad to hear. Yes, for OpenSSL binaries <= 1.0.2, they retained the ‘32’ at the end. Even many of the build flags for compiling the project still have 32 in them even though it’s a 64-bit compile. In >= 1.1.0, they changed the names, so it’s libcrypto and libssl instead of libeay32 and ssleay32.
Our bindings are compatible with 1.0.x and 1.1.0, so we left the abt ini reference alone.
Once the last of the 1.0.x branch (1.0.2) goes out of support end of year 2019, the ini file will be changed.

- Seth


Totally Objects

unread,
Nov 23, 2019, 3:53:05 PM11/23/19
to VA Smalltalk
Hi Seth. Just to mention that I have had to install libeay32.dll and ssleay32.dll into the dll directory when running Seaside under 9.2

Are there any updated instructions that we should be following?

David

Mariano Martinez Peck

unread,
Nov 23, 2019, 4:06:01 PM11/23/19
to VA Smalltalk


On Sat, Nov 23, 2019, 5:53 PM Totally Objects <da...@totallyobjects.com> wrote:
Hi Seth. Just to mention that I have had to install libeay32.dll and ssleay32.dll into the dll directory when running Seaside under 9.2

Are there any updated instructions that we should be following?


David

On Thursday, October 12, 2017 at 2:22:08 PM UTC+1, Seth Berman wrote:
Hi David,

Great, glad to hear.  Yes, for OpenSSL binaries <= 1.0.2, they retained the ‘32’ at the end.  Even many of the build flags for compiling the project still have 32 in them even though it’s a 64-bit compile.  In >= 1.1.0, they changed the names, so it’s libcrypto and libssl instead of libeay32 and ssleay32.
Our bindings are compatible with 1.0.x and 1.1.0, so we left the abt ini reference alone.
Once the last of the 1.0.x branch (1.0.2) goes out of support end of year 2019, the ini file will be changed.

- Seth


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/48d5ba5b-b3e6-4784-94f8-631bb19dfe77%40googlegroups.com.

Totally Objects

unread,
Nov 24, 2019, 2:28:59 PM11/24/19
to VA Smalltalk
Yes, I found that but thought it was worth checking in case that was an old issue (as it mentions 8.6.2 and above!). Also, I wanted to publicise the need to other Seaside users in case they didn't know as I didn't find it easy to sort this out, until Seth helped.


On Saturday, November 23, 2019 at 9:06:01 PM UTC, Mariano Martinez Peck wrote:


On Sat, Nov 23, 2019, 5:53 PM Totally Objects <da...@totallyobjects.com> wrote:
Hi Seth. Just to mention that I have had to install libeay32.dll and ssleay32.dll into the dll directory when running Seaside under 9.2

Are there any updated instructions that we should be following?

Hi David, 


Does that help? 

Best, 



David

On Thursday, October 12, 2017 at 2:22:08 PM UTC+1, Seth Berman wrote:
Hi David,

Great, glad to hear.  Yes, for OpenSSL binaries <= 1.0.2, they retained the ‘32’ at the end.  Even many of the build flags for compiling the project still have 32 in them even though it’s a 64-bit compile.  In >= 1.1.0, they changed the names, so it’s libcrypto and libssl instead of libeay32 and ssleay32.
Our bindings are compatible with 1.0.x and 1.1.0, so we left the abt ini reference alone.
Once the last of the 1.0.x branch (1.0.2) goes out of support end of year 2019, the ini file will be changed.

- Seth


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-sma...@googlegroups.com.

Mariano Martinez Peck

unread,
Nov 25, 2019, 8:24:22 AM11/25/19
to VA Smalltalk
On Sun, Nov 24, 2019 at 4:29 PM Totally Objects <da...@totallyobjects.com> wrote:
Yes, I found that but thought it was worth checking in case that was an old issue (as it mentions 8.6.2 and above!). Also, I wanted to publicise the need to other Seaside users in case they didn't know as I didn't find it easy to sort this out, until Seth helped.


Hi David,

Thanks for your concern, very much appreciated. As of 9.2, we ship two Seaside examples, one called "Hello World" with some basic setup and one called "Traffic Light" with advanced maps organization, packaging, and stack dumping and remote debugger examples. Both examples are shipped with in the manager of the product and they have also been documented. 


In those you can see that it's explained the dependency of Seaside on OpenSSL. 

Hope this helps too. 

Best,

--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Seth Berman

unread,
May 14, 2020, 10:17:42 AM5/14/20
to VA Smalltalk
Hi All,

Resurrecting this old thread since there is a new feature coming in VAST 2021 that will resolve this.
The original issue is that Seaside out-of-the-box requires OpenSSL to be setup and configured.
This is because we need the secure random number generator to provide good quality and safe session ids.

We now have developed EsSecureRandom which is included in the base Kernel.
EsSecureRandom has the same interface as EsRandom but uses the cryptographically strong RNG of the native platform.

- Seth


On Monday, November 25, 2019 at 8:24:22 AM UTC-5, Mariano Martinez Peck wrote:


On Sun, Nov 24, 2019 at 4:29 PM Totally Objects <da...@totallyobjects.com> wrote:
Yes, I found that but thought it was worth checking in case that was an old issue (as it mentions 8.6.2 and above!). Also, I wanted to publicise the need to other Seaside users in case they didn't know as I didn't find it easy to sort this out, until Seth helped.


Hi David,

Thanks for your concern, very much appreciated. As of 9.2, we ship two Seaside examples, one called "Hello World" with some basic setup and one called "Traffic Light" with advanced maps organization, packaging, and stack dumping and remote debugger examples. Both examples are shipped with in the manager of the product and they have also been documented. 


In those you can see that it's explained the dependency of Seaside on OpenSSL. 

Hope this helps too. 

Best,

--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Totally Objects

unread,
Jul 8, 2020, 11:34:31 AM7/8/20
to VA Smalltalk
So, I am just a very dense 75 year old finding that my30 years of Smalltalk doesn't help me one bit with this. I have just loaded Seaside into 9.2.2 and got the following error. This is outside my comfort zone so can you please explain my next steps. I thought that I had this sorted in previous 9.0 versions.smalltalk.pngsmalltalk2.png

Louis LaBrunda

unread,
Jul 8, 2020, 1:27:19 PM7/8/20
to VA Smalltalk
Hi Dave,

Someone from Instantiations will probably give you a definitive answer but till then I think you need openssl or its equivalent.  If you have the package there maybe a problem with the .ini file you are using in that it may not be pointing to the correct DLL or so file.  Check the CRYPTO_LIB= entry.
 
Lou

Totally Objects

unread,
Jul 8, 2020, 3:03:45 PM7/8/20
to VA Smalltalk
I know that Lou. I thought that they had removed the need for any extra work. Maybe, as usual, I misunderstood. I know how to sort it if nothing has changed as I have been doing it for the last few versions.
David

Totally Objects

unread,
Jul 8, 2020, 3:04:43 PM7/8/20
to VA Smalltalk
Ah - "coming in 2021". In my enthusiasm, I missed that. Do'h! I am off to sort it out.

Mariano Martinez Peck

unread,
Jul 8, 2020, 3:23:45 PM7/8/20
to VA Smalltalk
Greeting all,

Yes, as pointed out, you are missing OpenSSL configuration: 

The reason is that Seaside for VAST uses OpenSSL to general secure randoms for the session cache. However, this is changing for VAST 2021. In fact, in the build being done today, we are introducing a really good Random generator class completely decoupled from OpenSSL and that will be included in a lower level app. So.... Seaside itself won't need OpenSSL anymore for generating randoms as it can now use that new class. Of course, if you want to serve HTTPS with Sst, then of course you still need OpenSSL ;)

Cheers,   

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/ade7689c-8ef8-4862-9626-3b0812844cfdn%40googlegroups.com.

Richard Sargent

unread,
Jul 8, 2020, 3:31:11 PM7/8/20
to VA Smalltalk
Hopefully, 2021 will also see SstShaEngine decoupled from the continent of corequisite code that it's been packaged with. :-(


On Wednesday, July 8, 2020 at 12:23:45 PM UTC-7, Mariano Martinez Peck wrote:
Greeting all,

Yes, as pointed out, you are missing OpenSSL configuration: 

The reason is that Seaside for VAST uses OpenSSL to general secure randoms for the session cache. However, this is changing for VAST 2021. In fact, in the build being done today, we are introducing a really good Random generator class completely decoupled from OpenSSL and that will be included in a lower level app. So.... Seaside itself won't need OpenSSL anymore for generating randoms as it can now use that new class. Of course, if you want to serve HTTPS with Sst, then of course you still need OpenSSL ;)

Cheers,   

On Wed, Jul 8, 2020 at 4:04 PM Totally Objects <da...@totallyobjects.com> wrote:
Ah - "coming in 2021". In my enthusiasm, I missed that. Do'h! I am off to sort it out.

On Wednesday, July 8, 2020 at 8:03:45 PM UTC+1 Totally Objects wrote:
I know that Lou. I thought that they had removed the need for any extra work. Maybe, as usual, I misunderstood. I know how to sort it if nothing has changed as I have been doing it for the last few versions.
David
On Wednesday, July 8, 2020 at 6:27:19 PM UTC+1 L...@Keystone-Software.com wrote:
Hi Dave,

Someone from Instantiations will probably give you a definitive answer but till then I think you need openssl or its equivalent.  If you have the package there maybe a problem with the .ini file you are using in that it may not be pointing to the correct DLL or so file.  Check the CRYPTO_LIB= entry.
 
Lou



On Wednesday, May 11, 2016 at 3:33:51 PM UTC-4, Totally Objects wrote:
I have recently installed 8.6 as a clean install. I have loaded the Seaside feature and run up my code that was working under earlier versions of 8. When I try to log into the main Seaside control web page I get the following come up.


I know nothing about the Seaside internals. Can anyone tell me how to get this sorted please?


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-sma...@googlegroups.com.

Joachim Tuchel

unread,
Jul 31, 2020, 5:33:08 AM7/31/20
to VA Smalltalk
Hi John,

the link doesn't work any more for version 9.2 (HTTP 404) for this link: https://www.instantiations.com/docs/FAQ/wwhelp/wwhimpl/js/html/wwhelp.htm#href=va09002.html

BTW: Shouldn't this info be in the installation guide under some "Extra preparations for Seaside and other SSL related stuff" headline?

Joachim

Mariano Martinez Peck

unread,
Jul 31, 2020, 9:39:31 AM7/31/20
to VA Smalltalk
Hi Joachim, 

The new link is this one: https://www.instantiations.com/docs/FAQ/#page/FAQ/va09002.html  You can always get to it by searching "OpenSSL" in https://www.instantiations.com/docs/FAQ/

It might not be in the most findable place, but if you look here: https://www.instantiations.com/docs/922/wwhelp/wwhimpl/js/html/wwhelp.htm#href=sv/serve104-run-snglex2.html  it says:



I agree it could be put in a place easier to find....but, honestly, this dependency on OpenSSL is going away in 10.x so I am not sure its worth.... 


Kind regards,


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/270ea345-aebf-4e6a-8284-e582a4245023n%40googlegroups.com.

Joachim Tuchel

unread,
Jul 15, 2021, 3:32:19 AM7/15/21
to VAST Community Forum
Hi Mariano,


Getting open SSL to run with VAST 10.0.2 on Windows is more irritating than ever. Maybe this is only me, but I find this whole thing very complicated.

First things first:

I am getting

SstSendError('SSL initialization failed:
OpenSSLFailureToInitializeLibraryError
    Error Code: -1
    Error Object: (SciSslOpenSSLLibraryDispatcher)
    Error String: ''Error Initializing SSL_LIB (OpenSSL SSL/TLS Library).  Check this library is installed and referenced in the ini file''
    Error Hint: ''Evaluate [OSSslVersion printSslStatusCheck] and check the Transcript for additional information''
    AuxiliaryData: nil')

On Windows 10x64  when I true a SstHttpClient>>#get:using:withHeaders although I copied the libraries libeay32.dll  and ssleay32 from the VA 9.2.2 path on the same machine to the 10.0.2 directory.

When I evaluate OSSslVersion printSslStatusCheck in the image, nothing gets printed to the Transcript.

The link in your last post leads to a 404 page...

I get there was some name changes from the migration guide, but somehow my brain refuses to understand what exactly I have to do now.
There is this FAQ article (https://www.instantiations.com/vast-support/documentation/FAQ/#page/FAQ/va09002.html#) , but it seems not to cover any changes for 10.x.. So I am lost.

Which dlls do I need exactly? Do I have to change the abt.ini or not? This is all more confusing than ever. The fact that the FAQ article still hasn't been moved to the installation guide doesnt actually help, because if you go to teh dosumentation and search fro "ssl" or "openSSL", you get a few hits, but nothing about the installation of openSSL with VAST. It's logical if you know that article is in the FAQ and not in the docs.

You wrote



I agree it could be put in a place easier to find....but, honestly, this dependency on OpenSSL is going away in 10.x so I am not sure its worth.... 



Is this true? That would mean I don't have to copy anything or download openSSL? So I am looking for the problem at the completely wrong place, ain't I?
If so, what else do I have to do now to send out https requests in 10.0.2 ?

Can you provide me with a link to some "getting 10.0.x to run with openSSL on Windows x64 for dummies"?

Sorry if this sounds a bit aggressive. Maybe that is because I am frustrated and have no idea what else to do and which guide to follow or not. To me it seems like FAQ and Migration Guide contradict each other -maybe because the FAQ was not updated for 10.0.x?


Joachim



Wayne Johnston

unread,
Jul 15, 2021, 6:49:44 AM7/15/21
to VAST Community Forum
From the error, it sounds like the DLLs haven't been named to match your abt.ini's CRYPTO_LIB and SSL_LIB settings.  Or better yet, change the settings to match the file names.

Mariano Martinez Peck

unread,
Jul 15, 2021, 7:31:41 AM7/15/21
to VA Smalltalk
As Wayne said, your ini is probably not matching the libraries you are providing.
In 9.2.2 the defaults were:

CRYPTO_LIB=libeay32
SSL_LIB=ssleay32

But on 10.0.x the defaults are:

CRYPTO_LIB=libcrypto
SSL_LIB=libssl

The reason is because newer versions of OpenSSL changed the name of their libraries and we prefer you to stay with newer versions of OpenSSL than olders.
So you have to options:

1) Option 1 (better in my opinion): download latest OpenSSL version and that will include those newer libraries
2) Option 2 (simpler): change the .ini to point to the old library names and keep using the libraries you have now

Let me know if this helps, 




On Thu, Jul 15, 2021 at 7:49 AM Wayne Johnston <wa...@thejohnstons.com> wrote:
From the error, it sounds like the DLLs haven't been named to match your abt.ini's CRYPTO_LIB and SSL_LIB settings.  Or better yet, change the settings to match the file names.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/284f6172-75fe-4bed-b1c0-7860fbde9788n%40googlegroups.com.


--

Mariano Martinez Peck

Senior Software Engineer

 mp...@instantiations.com
 @MartinezPeck
 /mariano-martinez-peck
 instantiations.com
TwitterLinkedInVAST Community ForumGitHubYouTubepub.dev

Mariano Martinez Peck

unread,
Jul 15, 2021, 7:38:53 AM7/15/21
to VA Smalltalk



I agree it could be put in a place easier to find....but, honestly, this dependency on OpenSSL is going away in 10.x so I am not sure its worth.... 



Is this true? That would mean I don't have to copy anything or download openSSL? So I am looking for the problem at the completely wrong place, ain't I?
If so, what else do I have to do now to send out https requests in 10.0.2 ?

Can you provide me with a link to some "getting 10.0.x to run with openSSL on Windows x64 for dummies"?

Sorry if this sounds a bit aggressive. Maybe that is because I am frustrated and have no idea what else to do and which guide to follow or not. To me it seems like FAQ and Migration Guide contradict each other -maybe because the FAQ was not updated for 10.0.x?




Maybe I wasn't clear... the first email of this thread was from David and his problem was because Seaside USED/NEEDED OpenSSL to generate the random keys of the session _s argument. So... Seaside needed OpenSSL for sure to do everything. With 10.0.x that is not true anymore as now we use our own Es-level random provider and we do not use OpenSSL at all. See GRVASTRandomProvider class. 

But that's just Seaside. If you are using the SstHttpClient or any other thing that uses OpenSSL, then of course you still need it. 

Is it clearer now?

Best, 

Noschvie

unread,
Jul 15, 2021, 7:39:08 AM7/15/21
to VAST Community Forum
Hi Joachim
we have this settings "up and running" with VAST 10.x / x64:
CRYPTO_LIB=libcrypto-1_1-x64.dll
SSL_LIB=libssl-1_1-x64.dll

VAST 10.x / x86 :
CRYPTO_LIB=libcrypto-1_1.dll
SSL_LIB=libssl-1_1.dll

both libraries have to be copied to the ./bin directory of VAST
br
Norbert

Joachim Tuchel

unread,
Jul 15, 2021, 7:40:19 AM7/15/21
to VAST Community Forum
Mariano, Wayne,

thanks fro your help.
So I ended up using the old DLLs and the old names in the abt.ini and it is working for now. I'll take a look at downloading a newer version of openSSL, because that's what one should be doing anyways.

Joachim

Mariano Martinez Peck

unread,
Jul 15, 2021, 7:45:47 AM7/15/21
to VA Smalltalk
Hi Joachim,

I am glad it's working now. Hopefully it was not irritating or very complicated.

Best, 


To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f2e8201d-4fda-4b0e-80b8-d4b6666d4149n%40googlegroups.com.

Seth Berman

unread,
Jul 15, 2021, 7:57:21 AM7/15/21
to VAST Community Forum
Hi All,

For additional information, there is a migration guide entry related to this issue here:
https://www.instantiations.com/vast-support/documentation/1002/#page/mi/migr9222.html#

- Seth

Mariano Martinez Peck

unread,
Jul 15, 2021, 10:51:45 AM7/15/21
to VA Smalltalk
BTW, the 404 have also been resolved Joachim. Thanks for reporting them. 

To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/633487b6-d2d6-4c09-a47c-4c74acb79136n%40googlegroups.com.

Joachim Tuchel

unread,
Jul 16, 2021, 3:59:54 AM7/16/21
to VAST Community Forum
Hi Seth,

thanks for the link. I think that page sent me on the wrong path, because I obviously didn't umderstand it... This may well be due to my English knowledge, but I think the page misses some context in order to explain what needs to be done. Now that I understand the issue, the page is clear, however... ;-)

I think it would be good if the info provided by Mariano here in this thread was added and the thing about SSL versions would be explained better.

In 9.2.2 the defaults were:

CRYPTO_LIB=libeay32
SSL_LIB=ssleay32

But on 10.0.x the defaults are:

CRYPTO_LIB=libcrypto
SSL_LIB=libssl

And that is not because VAST changed, but because openSSL changed the library names in the newer version. So the defaults alone make only sense in conjunction with the openSSL version you want to use. For people familiar with openSSL, this sure is absolutely clear.

Joachim

Joachim Tuchel

unread,
Jul 16, 2021, 4:01:17 AM7/16/21
to VAST Community Forum
Mariano,

the fact itself was not complicated. I just took the most possible complicated path through FAQ, Inst guide and migration guide and somehow managed to completely mess thing up in my brain...

Joachim

Joachim Tuchel

unread,
Jul 16, 2021, 4:45:34 AM7/16/21
to VAST Community Forum
Hi Norbert,

thanks for your tip. Fortunately, we got it to work with the old dlls and without version numbers of the DLLs. All we had to do was change the entries to libeay32 and ssleay and copy the DLLs from the 9.2.2 directory.
We don't care too much about the SSL version for these windows environments, because we deploy on Linux. There this whole thing just works out of the box. We'd love to get rid of Windows anyways, but that's another story...

Joachim
Reply all
Reply to author
Forward
0 new messages