1

My Nodes have no internet access at all. We have no permission to set up a local gems mirror. All gems install needs to be from the chef server.

When chef runs, now, it invokes 'bundler install' (chef/lib/chef/cookbook/gem_installer.rb -- L51) with no options.

How do we kill the bundler run or force it into a local or standalone setup so that it will not initiate a connection out? (installing from local directory is okay, as long as we can force it per-gem to a different location)

Anyone else run this in a strict enterprise setting with strong firewalls and rules around software promotion? I worry that this is challenging for chef.

  1. This didn't seem to help, but I may have the dir contents (just a gem) wrong:

    /opt/chef/embedded/bin/bundle \ config \ local.chef-vault /var/chef/cache/cookbooks/gem-chef-vault/files/default/

  2. okay. So a submodule checkout in files can work:

    cd ~/chef-repo git submodule add \ https://github.com/chef/chef-vault.git \ local-cookbooks/gem-chef-vault/files/default/chef-vault

    note above that since chef will join all the cookbook dirs, your reference in bundler is still .../cookbooks/... .

  3. Hmm. Difficult to change /root/.bundle/config before the gem download starts. This, for instance, isn't winning the race:

    template /root/.bundle/config do action :nothing end.run_action(:create)

  4. bobbitting the routine at [Line 49] (https://github.com/chef/chef/blob/master/lib/chef/cookbook/gem_installer.rb#L49) (||true) shuts off the gem grab, but then we're back to a failure when the included third-party cookbook 'requires' the (not yet installed) gem during compilation -- and the r=/r.run_action(:install) bit can't seem to run yet ... right where I think it was supposed-to.

  5. even if I could light up a cheap empty gem repo on the chef box:

    mkdir -p /var/opt/opscode/nginx/html/repo/gems /opt/opscode/embedded/bin/gem \ generate_index \ -d /var/opt/opscode/nginx/html/repo/

    :::::::::::::: /var/opt/opscode/nginx/etc/addon.d/99-gem-mirror_external.conf :::::::::::::: location "/repo/" { } (restart with chef-server-ctl restart)

    .... and point the nodes at that location

    knife ssh 'name:victim2' -- \ chef-client --config-option 'rubygems_url=http://chef/repo/'

    it still dies - at 'requires' so I'm thinking the URL isn't relevant.

  6. our current strategy, if we're still going with chef in the enterprise, is code like the following:

    ##3p_something::default.rb: chef_gem 'something' do # install in compile source '/some/local/file.gem' clear_sources true compile_time true include_default_source false action :nothing end.run__action (:install) # include_recipe 'something'

    Ideally we want to pre-seed the required gem in before the included recipe blindly grabs something off the web, so we get something verifiable, consistent and repeatable (of course; and updating file.gem is another effort we accept in that regard).

It seems to look like chef issues 3456 but not completely, or docker issue 682 or chef-vault issue 61 and 63: our issue is that this all happens autocraptically when the 'gem' line in metadata.rb is read.

user2066657
  • 348

2 Answers2

0

You can use the rubygems_url config setting to aim at a local mirror, or just don't use any cookbooks that make use of the feature and it shouldn't activate at all.

coderanger
  • 878
-1

The winningest answer seems to be something matching #5. You'll need to create and manage a gems mirror, and feed in the local URL via one of two methods.

MAYBE bootstrapping the location in a .gemrc and .bundle/config will work (not directly confirmed), as in #3, but don't try to use a run_action postamble on it because the gem statement is first. it would eliminate the need to supply the override bit on the increasing and pernicious command line (do it soon, as automation can reduce the risk of typos). As to a valid but empty gem 'repo' for a URL to stop that process, I was unable to confirm the question was understood.

#6 will probably not work. MAYBE even if you kill the code in the chef package or disable it with a valid but empty gem repo.

Yes, this threatens the Single Source of Truth. Yes, you need to set up more gear. Yes, you need to maintain it. Yes, it may work. No other ideas presented.

Remember, ultimately, that "it's on you." I'd like to thank Sean Spicer for the help in saving us $137/node/year. :-/

user2066657
  • 348