I used a template resource to write out the `/etc/gemrc`file, then had that notify the following block:
ruby_block “refresh gem config” do block do Gem.configuration = Gem::ConfigFile.new [] end end
The benefit of this was I could specify `—no-ri —no-rdoc` in the `/etc/gemrc` file in addition to custom sources, and my gem installs went much faster.
-T
On Oct 27, 2014, at 12:12 AM, Lamont Granquist <
" class="">
> wrote:
You're going to need to update the rubygems sources in the running ruby VM, something like:Gem.sources = [ "https://rubygems.org" ]OrGem.sources << "https://rubygems.org"You may also need to reset some of the cached internal stateOn Sun Oct 26 23:30:17 2014, DV wrote:Hey all,
Just a quick follow-up to the issue discussed in this thread - unfortunately compile-time "gem sources --add" statement didn't influence Chef's decision to use the gem repo that I'm trying to get rid of.
What I have first in the recipe is:
execute 'add_rubygems.org_gemrepo' do action :nothing command '/usr/bin/gem sources --add https://rubygems.org/' end.run_action(:run)
But, the recipe fails because later on I have a Ruby application defined, and the following line:
* execute[passenger_module] action run
fails with:
Error executing action `install` on resource 'gem_package[passenger]' ================================================================================ NoMethodError ------------- undefined method `full_name' for nil:NilClass
.. which is Chef's advanced terminology for "can't find this gem."
If you have any other ideas on what needs to be changed to get Chef to update gem repository so that it's in effect on first run, please share!
On Thu, Oct 9, 2014 at 1:34 PM, DV <
" class="">
<
" class="">mailto:
>> wrote:
Thanks guys, I'll test this solution out and let you know if it worked.
On Wed, Oct 8, 2014 at 3:41 PM, Jake Plimack <
" class="">
<
" class="">mailto:
>> wrote:
I would recommend that first off, you run your own gem mirror, as rubygems goes down all the time. It will provide security, stability, and speed boosts. second, make it run during the compile phase.
execute 'set-gem-repos' do command '/usr/bin/gem sources --add https://rubygems.org/' action :nothing end.ru <http://end.ru>n_action(:run)
my solution is that every node gets the base cookbook (formerly a role) first, which a. makes hints and runs ohai. b. sets up apt/gem/etc. and then the node gets additional run_list items. Since chef executes in order, the node's environment will be prepped during this base phase for anything it might be destined for.
On Wed, Oct 8, 2014 at 4:27 PM, DV <
" class="">
<
" class="">mailto:
>> wrote:
Hi guys,
Thought I'd get your advice on the following:
I have chef-client run fail on the initial (only) run due to host's default gem sources not having the version of gem chef-client is trying to install. To be more specific, it's passenger gem from passenger_apache2::source cookbook here:
gem_package "passenger" do version node['passenger']['version'] end
The default gem sources on the host simply don't have passenger gem and/or its dependencies so of course it fails.
My goal is to make chef-client aware of an additional gem source at first run. So far I've tried the following:
execute 'add_rubygems.org_gemrepo' do action :run command '/usr/bin/gem sources --add https://rubygems.org/' end
I see the code being executed on chef-client run, nevertheless, first chef-client run fails to find passenger gem. So there must be some caching going on that I need to override.
All further chef-client runs succeed, though.
So my question is, how can I make chef-cilent aware of additional gem sources on its very first run?
-- Best regards, Dmitriy V.
-- Best regards, Dmitriy V.
-- Best regards, Dmitriy V.
|