Ruby installation/build failed on provisioning

[twerthmueller]

We have the problem that when we enable the mailcatcher or ruby only, we get always a compile error:

It seems a problem with a missing ssl methods:

---

make[2]: Leaving directory /tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/nkf' make[2]: Entering directory/tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/objspace'
compiling object_tracing.c
compiling objspace.c
compiling callback-4.c
compiling objspace_dump.c
installing default objspace libraries
linking shared-object objspace.so
make[2]: Leaving directory /tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/objspace' make[2]: Entering directory/tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/openssl'
compiling ossl_rand.c
compiling ossl_x509attr.c
compiling ossl_ssl_session.c
compiling ossl_asn1.c
compiling callback-5.c
compiling ossl_digest.c
compiling ossl_x509revoked.c
compiling ossl_ssl.c
ossl_ssl.c:137:27: error: ‘SSLv3_method’ undeclared here (not in a function)
OSSL_SSL_METHOD_ENTRY(SSLv3),
^
ossl_ssl.c:115:69: note: in definition of macro ‘OSSL_SSL_METHOD_ENTRY’
#define OSSL_SSL_METHOD_ENTRY(name) { #name, (SSL_METHOD ()(void))name##_method }
^
ossl_ssl.c:138:27: error: ‘SSLv3_server_method’ undeclared here (not in a function)
OSSL_SSL_METHOD_ENTRY(SSLv3_server),
^
ossl_ssl.c:115:69: note: in definition of macro ‘OSSL_SSL_METHOD_ENTRY’
#define OSSL_SSL_METHOD_ENTRY(name) { #name, (SSL_METHOD ()(void))name##_method }
^
ossl_ssl.c:139:27: error: ‘SSLv3_client_method’ undeclared here (not in a function)
OSSL_SSL_METHOD_ENTRY(SSLv3_client),
^
ossl_ssl.c:115:69: note: in definition of macro ‘OSSL_SSL_METHOD_ENTRY’
#define OSSL_SSL_METHOD_ENTRY(name) { #name, (SSL_METHOD ()(void))name##_method }
^
make[2]: *** [ossl_ssl.o] Error 1
make[2]: Leaving directory /tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/openssl' make[1]: *** [ext/openssl/all] Error 2 make[1]: *** Waiting for unfinished jobs.... compiling callback-6.c compiling callback-7.c compiling callback-8.c installing default callback libraries linking shared-object dl/callback.so make[2]: Leaving directory/tmp/ruby-build.20151028113016.3957/ruby-2.1.2/ext/dl/callback'
make[1]: Leaving directory `/tmp/ruby-build.20151028113016.3957/ruby-2.1.2'
make: *** [build-ext] Error 2

---

Is there a dependency missing?

[philipnorton42]

Look like there is an ssl library missing... If you are able to find out what it is (and can confirm it works with that library installed) we'll get it added to the repo asap.

[devdrops]

HI! Just to check, does anybody could find which SSL library is exactly missing?

[twerthmueller]

Not yet. I tested some other libraries with no luck.

Does anybody have this problem with the current release?

[dixhuit]

Can I just check if you guys are enabling the ruby role just to run mailcatcher or whether you need ruby for something else?

The reason I ask is that there is a pending notion to replace mailcatcher with mailhog (#170). I that's of interest then please add your voice.

[Oliboy50]

I had the same kind of issues before, it's due to missing packages.

Here is how I install Ruby 2.2.3 on Ubuntu 14.04 now:

apt-get install -y --force-yes \
    libreadline-dev \
    libssl-dev \
    libxml2-dev \
    libxslt1-dev \
    libyaml-dev \
    zlib1g-dev \
    libncurses5-dev \
    libffi-dev \
    libgdbm-dev \
    build-essential \
    software-properties-common \
    python-software-properties \
    nano \
    vim \
    curl \
    libcurl4-openssl-dev \
    git \
    wget \
    tar

# Install Ruby 2.2.3 and globally install some packages (bundler, capistrano, sass, less)
curl -O http://ftp.ruby-lang.org/pub/ruby/2.2/ruby-2.2.3.tar.gz && \
  tar -zxvf ruby-2.2.3.tar.gz && \
  cd ruby-2.2.3 && ./configure --enable-shared && make && make install && \
  cd .. && rm -r ruby-2.2.3 ruby-2.2.3.tar.gz && \
  gem install -n /usr/bin/ \
    bundler \
    sass \
    less \
    capistrano

I install other stuff along Ruby, so I think there are some useless packages here...

[twerthmueller]

@danbohea we need it only for mailcatcher.

[dixhuit]

@twerthmueller Would you be up for switching to mailhog?

[twerthmueller]

@danbohea I have no experience with it but it looks good/nice and it's a valid replacement for mailcatcher. :-)

[philipnorton42]

I think the time has come to ditch the ruby and mailcatcher combo and use Mailhog instead. We had a pull request for this functionality a while ago, but it wasn't compatible with our incoming galaxy changes. Should be pretty easy to add it back in though.

What does everyone else think about ditching ruby support? What else is it used for besides mailcatcher?

[dixhuit]

Sounds good to me.

[zxaos]

I've used it before to run compass/sass inside of a VM for devs running on windows.

Having said that, it's definitely something that could be just handled through custom plays if someone really wants it.

[devdrops]

Just in case you people are still looking for a solution related to ruby installation and openssl troubleshooting (I've tried what @Oliboy50 said but no success), that's how I fixed things for me (as a short notice, I'm using RVM for ruby/packages management):

As described here, first I've fixed the openssl dependency for Ruby:

rvm pkg install openssl

So then I could finally install Ruby 2.2.3:

rvm install 2.2.3 --with-openssl-dir=$HOME/.rvm/usr
rvm list
rvm --default use 2.2.3

[mvance]

I'm getting the same error.

For what it's worth, we've been using Ruby primarily for running Compass/SASS inside of the VM. Ruby turns out to be enough of a headache though that I'm now starting to look for alternatives.

[dixhuit]

@mvance So long as you can ditch Compass, running Sass via Node is a really good (in many ways better) alternative. I've now completely shifted to this approach (NB, I still run all this stuff from the host rather than the guest though). Turns out I found myself using Compass less & less over time and many of the "convenience" mixins & functions are easily replaceable - depends on your dependence though I guess. From what I understand, Compass is heading in the Node direction anyway (though struggling to find a source for you here) but obviously that's of no use in the present.

[mvance]

I've opened a pull request for a small change that seems to have fixed the problem for me. It amounts to just running the Ruby installation process earlier in the site.yml file. I'd be interested if anyone else in this thread could take a few minutes to verify that the fix addresses the problem for them too.

As I mentioned in the pull request, it would be nice to know why that works, but for the time being, I'm happy to just have the install process working cleanly again.

[christopher-hopper]

@mvance I think I've found out why the problem is happening. It may relate to the dropping of SSLv3 support from the latest experimental Debian OpenSSL package. For more insight read the thread here:

• Debian Bug Reports - transition: openssl: remove SSLv3 methods

If one of the ansible roles playbooks adds a Debian experimental repo, then this OpenSSL update is surely being pulled in, with its associated package breaks. A fix might be to peg the OpenSSL library at a version prior to this experimental version, rather than grabbing the latest, or somehow ensuring that only stable OpenSSL packages are available for install.

Until they've finished transitioning all affected packages (python, curl, etc) this may continue to be an issue for Ubuntu / Debian builds.

[christopher-hopper]

As a way of finding the source of the broken or experimental OpenSSL libraries, I'd move the the inclusion of

 - { role: ruby, tags: ["ruby"], when: "ruby_install" }

progressively lower in the execution order until it breaks. The problem is obviously somewhere between samba

    - { role: samba, tags: ["windows"], when: "is_windows" }

and mailcatcher

    - { role: mailcatcher, tags: ["mailcatcher"], when: "mailcatcher_install" }

in the site.yml install order. Start by moving it half way between the two until it breaks or doesn't, then half the gap again until it breaks or doesn't. Keep doing that with a fresh vagrant destroy && vagrant up until you find the "role" line that causes the ruby install to fail (a-la the git bisect method).

The culprit is bound to use an experimental or unstable Debian package repository. I'd almost bet my house on it. The question is, does it need the OpenSSL library to be at the latest experimental or unstable version. If not, limit the packages that will be fetched from this unstable repository to only those that are absolutely necessary.

[cjac]

It looks to me as if Debian disables deprecated methods in the OpenSSL library:
http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/debian/rules?annotate=748&pathrev=760#l29

CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 no-zlib enable-tlsext no-ssl2 no-ssl3 enable-unit-test no-ssl3-method enable-rfc3779 enable-cms

The SSLv3_* methods are all deprecated according to the OpenSSL man pages:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html

SSLv3_method(), SSLv3_server_method(), SSLv3_client_method()
A TLS/SSL connection established with these methods will only understand the SSLv3 protocol. The SSLv3 protocol is deprecated and should not be used.

This begs the question: Why is Ruby depending on deprecated OpenSSL methods in the latest release?