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
  • 336
  • 2
  • 13

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
  • 836
  • 4
  • 13
  • Not 'using any cookbooks that make use of the feature' is, well, 'using no third-party cookbooks.' When the rest of the enterprise world moves from 11 to 12, we'll need a better plan in place. – user2066657 Aug 22 '17 at 04:02
  • Air gapped networks are sufficiently non standard that you should not expect the majority of community cookbooks to support that. Cost of doing business in a niche way. (Yes I know it's common at big companies, but that's not who writes most of the community cookbooks) – coderanger Aug 22 '17 at 04:04
  • Sorry; I worried that the piece added to gem_installer.rb -- L51 was from someone not familiar with enterprise networks or anything even observing security best-practice from a vast distance. I'm disheartened to learn it may be true. Does that confirm that #3 above is also useless? I had thought that setting the rubygems url as per my #5 above was STILL making pointless calls to the world - how does one shut that OFF?!? - so the damage if so could be larger. – user2066657 Aug 22 '17 at 04:39
  • `chef_gem` is entirely unrelated to the gem dependency feature. You cannot specifically disable gem dependencies because they declared dependencies of a cookbook, you can either remove the dependency (i.e. fork the cookbook and rewrite it to not require that gem) or point the install process at a local gem mirror server using the `rubygems_url` config option as I mentioned. – coderanger Aug 22 '17 at 05:44
  • (re: #3, if pointing at a mirror, you do need to actually mirror the gems, aiming it a blank server will produce nonsense as you noted) – coderanger Aug 22 '17 at 05:45
  • So given #5 (valid but empty), even something like #6 would not be enough to properly seed a gem from source (single source of truth) and ensure a repeatable, consistent and verifiable config run without requiring out-of-band repo management on the proxy (breaking SSoT)? Just to be clear, there's no way to firmly ensure gems are pulled in time from blobs in source (costly SSoT) if they appear as 'gem' statements in an included cookbook's metadata, and chef_gem is useless for this? – user2066657 Aug 22 '17 at 15:33
  • That is correct, the `gem` metadata install process happens very early in the load order, before any of your cookbook code (let alone recipes) gets a chance to run. The only way to prevent it from trying to run the install is for the that list of gems to install to be empty. i.e. fix your cookbooks, as I keep saying. – coderanger Aug 22 '17 at 18:15
  • so, one of the major benefits of Chef is lost with this 'gem' statement killing it on the Enterprise, and anyone interested in consistency and security should rebuild everything -- of course, but the brochure is ever different. Is chef_gem still useful otherwise, or will it go away? – user2066657 Aug 22 '17 at 20:11
  • chef_gem will not go away as it is unrelated and for a different purpose (we would like to see it used a lot less though), and I'm not sure how much more clearly I can say that we _did_ consider non-traditional network designs and gave you an option to totally substitute a local mirror server for installs. Use it or don't, up to you, but that's on you not us. – coderanger Aug 22 '17 at 21:18
  • Thanks for strongly defending your position, and also answering the questions I had. I'll update with a post-mortem if we can make it work in our enterprise. – user2066657 Aug 22 '17 at 22:52
-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
  • 336
  • 2
  • 13