2

I'm using the following to try and install a Rubygem with Puppet.

package { 'reaper':
  ensure           => 'installed',
  provider         => 'gem',
  source           => 'http://192.168.1.101:9292/',
  install_options  => ['--no-ri', '--no-rdoc']
}

When I run puppet agent --test I get the following error.

Error: Execution of '/usr/bin/gem install --source http://192.168.1.101:9292/ reaper' returned 1: ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::RemoteFetcher::OpenSSL

Error: /Package[reaper]/ensure: change from absent to present failed: Execution of '/usr/bin/gem install --source http://192.168.1.101:9292/ reaper' returned 1: ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::RemoteFetcher::OpenSSL

However, when I run gem install --source http://192.168.1.101:9292/ reaper as root from the command line the gem installs just fine.

Anyone have an idea of what's going on? Does the Puppet agent get executed with some different environment variables that could be causing this error?

===== EDIT =====

Here's some additional information about the environment:

#output from `grep libssl /proc/{irb pid}/maps`
b70e0000-b7131000 r-xp 00000000 08:01 393357     /lib/i386-linux-gnu/libssl.so.1.0.0
b7131000-b7133000 r--p 00050000 08:01 393357     /lib/i386-linux-gnu/libssl.so.1.0.0
b7133000-b7137000 rw-p 00052000 08:01 393357     /lib/i386-linux-gnu/libssl.so.1.0.0

Ruby and RubyGems (installed via aptitude install rubygems):

# ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]

# gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.15
  - RUBY VERSION: 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]
  - INSTALLATION DIRECTORY: /var/lib/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - /var/lib/gems/1.8
     - /root/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

SSL (installed automatically):

# aptitude search ~i | grep ssl
i A libssl-dev                      - SSL development libraries, header files an
i A libssl-doc                      - SSL development documentation documentatio
i   libssl1.0.0                     - SSL shared libraries                      
i A openssl                         - Secure Socket Layer (SSL) binary and relat

# aptitude show libssl1.0.0
Package: libssl1.0.0                     
State: installed
Automatically installed: no
Multi-Arch: same
Version: 1.0.1-4ubuntu5.9
Priority: required
Section: libs
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: i386
Uncompressed Size: 2,748 k
Depends: libc6 (>= 2.7), zlib1g (>= 1:1.1.4), debconf (>= 0.5) | debconf-2.0
PreDepends: multiarch-support
Breaks: openssh-client (< 1:5.9p1-4), openssh-server (< 1:5.9p1-4)
Description: SSL shared libraries

===== EDIT #2 =====

I'm wondering why I'm even encountering an OpenSSL error... the source I'm using is http, not https. Thoughts?!

Bryan
  • 205
  • 1
  • 4
  • 13
  • is there supposed to be spaces between `:9292/` and `reaper` ? – Zypher Jun 11 '13 at 23:06
  • The `uninitialized constant Gem::RemoteFetcher::OpenSSL` looks suspicious. I wonder if you install some ruby SSL libraries. – Zoredache Jun 11 '13 at 23:24
  • @Zypher - yes, there should be a space between the source address and the name of the gem I want to install. – Bryan Jun 11 '13 at 23:46
  • @Zoredache - I agree, the OpenSSL error looks suspect. However, I confirmed that all required libraries were installed and verified this by the fact that the gem installs just fine when I do it manually (i.e. I execute the gem install command myself as root from the command line). – Bryan Jun 11 '13 at 23:47

2 Answers2

2

I've run into similar issues before, and I'm about 99% sure your Ruby runtime is trying to load a version of OpenSSL other than the one it was built against, most likely due to the presence of a custom libssl in /usr/local. Can you do the following:

  1. Start an irb session with the Ruby runtime used to run Puppet, then require 'openssl' and leave the session running
  2. In another terminal, run grep libssl /proc/$(pidof irb)/maps and copy the output
  3. Update your post with the output you captured above

Other information on what version of Ruby/OpenSSL you're running and how they were installed would also be tremendously helpful in diagnosing this issue.

jgoldschrafe
  • 4,385
  • 17
  • 18
  • Thanks for your willingness to help me out with this. I've edited the OP to reflect the additional detail you asked for. – Bryan Jun 13 '13 at 16:24
1

Alright, so I think I figured out what the deal was...

It seems as though I was getting the uninitialized constant Gem::RemoteFetcher::OpenSSL error not because of an SSL issue, but because the source server could not be found. I was under the impression that the --source option was getting used, but I don't think it was (see below).

As root on the Puppet client box, I changed the gem source location to be my custom gem server. Running gem env as root confirmed the change. I then updated my Puppet manifest to output the result of gem env when the Puppet agent ran, and the source was still http://rubygems.org/ when the gem command was executed by the Puppet agent. Upon further inspection, I got the impression that the HOME environment variable was being changed to / before the gem command was being executed (mainly because /.gem/ruby/1.8 was listed as a GEM PATH when gem env was executed by the Puppet agent instead of /root/.gem/ruby/1.8 or /var/lib/puppet/.gem/ruby/1.8).

To test, I copied my /root/.gemrc file (which specified my custom gem source) to /.gemrc and ran the Puppet agent again. This time, no error occurred and the gem I wanted was successfully installed. Puppet's home directory, per /etc/passwd, is set to /var/lib/puppet, so the Puppet agent must be configured to point its home directory to / prior to executing manifests.

Bryan
  • 205
  • 1
  • 4
  • 13