I sort of answered my own question, here’s a monkey patch to remove the hardcoded gem source: # Monkey patch to fix hardcoded gem source require 'chef/provider/package/rubygems' Chef::Provider::Package::Rubygems.class_eval do def install_via_gem_command(name, version) if @new_resource.source =~ /\.gem$/i name = @new_resource.source else src = "@new_resource.source" && "
" end if version shell_out!("#{gem_binary_path} install #{name} -q --no-rdoc --no-ri -v \"#{version}\"#{src}#{opts}", :env=>nil) else shell_out!("#{gem_binary_path} install \"#{name}\" -q --no-rdoc --no-ri #{src}#{opts}", :env=>nil) end end end Bernie From: Durfee, Bernie (GE Corporate)
So the gem_package provider hardcodes ‘rubygems.org’ as a gem source. That’s great, if you can or want to always get gems from there, but if you’re behind a corporate firewall, this is not a good thing because it breaks even if you have
the gem in a local repo… > gem list stickler -r --source=http://mylocalrepo.com/gemrepo/ *** REMOTE GEMS *** stickler (2.4.0) > gem list stickler -r --source=http://mylocalrepo.com/gemrepo/ --source=http://rubygems.org *** REMOTE GEMS *** ERROR:
http://rubygems.org/ does not appear to be a repository ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) SocketError: getaddrinfo: No address associated with hostname (http://rubygems.org/yaml) There were several issues opened regarding this, which now seem to have been rolled up into an enhancement (CHEF-4539). That’s fine, except for me, it’s still a bug. Does anyone know of any workarounds for the hardcoded ‘rubygems.org’? Bernie |
Archive powered by MHonArc 2.6.16.