What to do when VAST x64 (and Seaside) on Linux need a little help finding libcrypto.so

[update: I just updated the title of the post, because on other Linux machines,  like our test and production servers, there is a link named libcrypto.so in the 64 bits libraries path, so the change to the ini file is not necessary there…

20591215 0 lrwxrwxrwx 1 root root 16 Jun 20 13:29 /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1



My dilemma these days is that I have very little time besides my work on Kontolino. At the sime time, I’d like to re-start blogging and hopefully provide some helpful information to the Smalltalk world. So all I can do at this moment is use my blog as a little notebook of findings that I feel will either be helpful to myself in the future or – even better – to others as well.

We’re currently attempting to port or Application from 32 to 64 bits. so far, the process was quite smooth on our development environment (Windows), but needs a little tweaking on Linux.

First, let me say something so surprisingly positive that I could hardly believe it: we are using an external library on Linux which is available in a 32 bit as well as a 64 bit variant. And what can I say: our code needed absolutely no change! It just ran on 64 bits in both Windows and Linux. Fantastic!

Some other things I found so far:

  • With Environments, you can easily have 32 bits and 64 bit versions of VAST coexist on one machine, both on Windows and Linux. I don’t know if I ever mentioned it, but Environments is an excellent addition to VA Smalltalk!!!
  • You must not mix .ini files between 32 and 64 bit images. This can lead to strange effects. As a long time VA Smalltalker, I should of course know that. I just keep forgetting it.
  • On my play/test machine for dirty experiments, a used Dell Laptop with Xubuntu 18.04 on it, I had a strange effect with Seaside: The session object would be nil and never be initialized, even though all seemed well. The error messages were somewhat useless for finding the problem. It turned out that trying to visit http://localhost:800 shows a much more helpful error message: WANoSecureKeyGeneratorAvailable.
    The strange thing here is that the 32 bit version of the same app is running on that machine quite nicely. So I was sure this must be a library problem.
    And it is: there is a libcrypto.so in /usr/lib/i386-linux-gnu/, but obviously there is no 64 bit version of it on my machine. I checked that openssl (without :i386) is installed.
    But there is /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 on the machine. So at least on this machine I have to change the CRYPTO_LIB parameter to point to /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 or set a link to it. Now the session runs perfectly.

The process is not finished yet, so there may be new findings over the next few days. For now, I’ll stop here…

10 thoughts on “What to do when VAST x64 (and Seaside) on Linux need a little help finding libcrypto.so

  1. Hi Joachim – well I’ve just had exactly the same issue with VW8.3 on unbuntu 18. The afflicted socket code worked perfectly well on ubuntu 16 but not 18. Damn them for not making that link by default!

    1. Tim,,
      then link is there on several of our machines which had been installed with Ubuntu 18.04 – both Server and Kubuntu.
      The laptop in question, however, had been upgraded from 16.04 – maybe that#s the reason…?
      So all in all, the issue doesn’t exist on cleanly installed machines, but I decided to keep this article online anyways, just to keep a hint of what might be going on and what could be done about it…

  2. Hi Joachim,
    Thanks for sharing this. And please, do keep posting! These are very useful posts.
    With the topics in particular, I don’t think there is much we can do about other than keep documenting and remember this. The only possible spot to improve is #installFailing. Do we want to throw an exception in `WASecureKeyGenerator >> #startUp` if we were not able to seed? Would that be better compared to receiving the error response in the browser?

    1. What I mean is why we can’t implement this:

      WASecureKeyGenerator class >> startUp

      self canSeed
      ifTrue: [
      self seed.
      self install]
      ifFalse: [self error: ‘no secure key generator available because seeding failed’]

      Do you see any disadvantage with that approach?

      1. The only negative thing here is not your suggestion, it is the fact that the SSL is needed here. But I am not sure I really like the idea of having a silent fallback (some non-secure random generator if ssl doesn’t work).
        Looking at this from the perspective that we don’t use any https: in the Smalltalk image but have this handled by Apache, this while thing seems a bit odd.
        OTOH We need openSSL and encryption for other purposeses (e.g. securely storing passwords), so we have to make this run anyways.
        So, after wembling around a little: I like your suggestion.

        1. Hi Joachim,

          The need of OpenSSL is expected because this is a particular subclass called WASecureKeyGenerator which belongs to the app SeasideVASTSecurity. Obviously, OpenSSL is a prereq for it so we are fine. That app is included in “Seaside Core” map so it is always loaded. The WASecureKeyGenerator >> initializeOnLoad makes it sure we use it upon load it.

          Finally, the dependency on SeasideVASTSecurity doesn’t seem mandatory (even if included by default in “Seaside Core”). In this case, if that app wouldn’t have been present, we would be using WAKeyGenerator and that just works right in VA:

          WAKeyGenerator new keyOfLength: 10 —> ‘XHoZE9QeEL’

          And even with the app present, if you won’t have OpenSSL installed or whatever and you would like to keep it simple, then as part of your Seaside app registration code you can force “WAKeyGenerator initializeOnLoad” and use that one instead of the secure… right?

          Anyway, if you have your linux at hand and wanna give a try to above code with a wrong CRYPTO_LIB and see if the exception is correctly triggered, that would help!

          We may be able to include this change.


      2. Mariano,

        I haven’t found the time to test your suggestion yet. But I have an idea for the error message to throw. What about adding ‘please check if openSSL is installed and correctly configured (library path) on this machine’
        This could even be a good hint for what to look at.
        You know, I am a bit radical about error messages. Most of the times I find myself thinking: what could I have told myself about the problem in order to find it faster? in retrospective. I try to improve my error messages every time I learn something new. A good error message can save tons of time, especially when the error leads to an urgent situation, where every minute spent is a minute where users wait for a solution…

        1. Hi Joachim,

          I kept thinking about the change in `WASecureKeyGenerator class >> startUp` to throw error if it can’t seed and now I don’t think this is a good idea. Why? Because that is called from #startUp and then from #initializeOnLoad. So you may be getting an ERROR when trying to load the code..Very bad idea:
          1) what happens with ENVY/VA when there are errors during #initializeOnLoad?
          2) what if you don’t want to use OpenSSL but just WAKeyGenerator?

          So…throwing error on load is a bad idea to me. Now, what other places we could hook on into Seaside so that it’s before getting an actual session?

          I first thought upon application registration… so that the error could be triggered when you are registering your Seaside app. But once again, many people use to do this in #initializeOnLoad… same situation as before.

          So…..I can’t see any place where we could hook in different from what it is. Do you see it? Do you agree with me?

          At the very least, I agree with you that we should change the error and make it more explicit. What about the following?
          “No secure key generator available because seeding failed. Please check that OpenSSL is intalled and that CRYPTO_LIB and SSL_LIB are correctly specified”

          Do you have something better?

          1. Mariano,

            I agree that keeping the code from loading into the image by throwing an exception at load time is not an excellent idea. OTOH, when you deploy your application to a machine which is not configured properly, you probably want to know as early as possible. So maybe just keeping things as they are – but improving the error message – is probably the best thing we can do.

            As for your message suggestion: it still doesn’t tell exactly what is wrong or what might not work. It doesnt say that Seaside cannot assign random IDs to sessions. BUT, extending the message even more makes it far too long, nobody is probably going to read it…

            One thing that remains unsolved if we don’t get a debugger is that you probably will never see this error message anyways. You may ask “WHAT the freaking cream is this guy talking about”?
            Well, usually, your application will not be reachable at http://address:80, but in some subdirectory, like http://address:port/MyApp. And that will probably send some setters to the session quite early in processing the requests (like in self session loggedInUser isNil). Seaside will seem to work, but the session object will be nil. So what you see in your web browser is not the error message you suggested, but you will get an “UndefinedObject does not unterstand #loggedInUser). I guess we agree that this will cost you loads of time to find out why the friggin times your session might be nil.

    2. Mariano, thanks for your nice comment. I plan to keep on posting these little things, if only to have a place where I can look those up in the future.

      Yes, I would prefer a debugger. Especially if it tells me about the root cause (no seeding possible) rather than the fact that there is no Seaside Session… 😉

Comments are closed.