[chef] Rubygems Issue affecting some ChefDK Users


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: " " < >
  • Subject: [chef] Rubygems Issue affecting some ChefDK Users
  • Date: Fri, 29 Aug 2014 11:46:51 -0700

Hi Chefs,  

I’d like to alert those of you that use ChefDK to an issue we discovered 
after yesterday’s release of ChefDK 0.2.1. If you don’t use ChefDK, you might 
still want to pay attention since the root of the problem is caused by a 
change in rubygems 2.2.

This issue will affect any users who’ve installed gems with C extensions into 
ChefDK’s ruby, but will be most severe for those who started using ChefDK 
before 0.1.0.

The issue is that rubygems, starting with 2.2, has changed the on-disk layout 
of gems so that gems can be shared between multiple ruby versions to save 
disk space. As a consequence, the place where compiled C extensions are 
located had to change since compiled extensions cannot be shared between 
different Ruby versions (based on ABI level). To account for this, rubygems 
2.2.0 attempts to lazily rebuild gem extensions in the new location after 
rubygems is upgraded. This causes two problems for ChefDK users:

1. If you used ChefDK prior to 0.1.0, and you installed gems with C 
extensions, you will have root-owned gems installed to ChefDK’s ruby. 
Rubygems will not be able to rebuild the gem without root permissions, so it 
will emit an error like Error loading RubyGems plugin 
"/opt/chefdk/embedded/etc…” Permission denied @ dir_s_mkdir
2. If you have only used ChefDK 0.1.0 and above, and you installed gems with 
C extensions, those gems’ files will be owned by your user and located in 
~/.chefdk/gem. Rubygems should be able to auto-update these gems, but some 
users have reported errors with the process.

If you’re affected by case #1, your best bet is to completely uninstall 
ChefDK, remove any leftovers from /opt/chefdk, and re-install. You’ll need to 
re-run `chef gem install` for any gems that were installed to the embedded 
ruby’s gem directory. You may also be able to `sudo gem pristine GEM_NAME` 
these gems, but the changes that sudo typically makes to your environment 
variables means this might not work without some troubleshooting.

If you’re affected by case #2, and the auto-update process fails for some 
reason, the best way to go is to remove the ~/.chefdk/gem directory and 
re-install any gems you had installed previously. You can also try to `chef 
gem pristine GEM_NAME` these gems if you don’t want to re-install.

I’ve closed the ChefDK issue related to this change since there isn’t really 
any way for us to make this easier, unfortunately. But feel free to comment 
on the issue if you’re having trouble with any of the fixes/workarounds.

Finally, I will note that I believe the Rubygems developers made a reasonable 
effort to maintain compatibility and were caught unaware by some of the edge 
cases (like ours) that surfaced after the feature was released, even though 
the outcome is frustrating. Let’s not spew vitriol at them, okay?

Thanks,  

--  
Daniel DeLeo

References:

ChefDK bug report: https://github.com/opscode/chef-dk/issues/146

Rubygems layout change PR for 2.2: 
https://github.com/rubygems/rubygems/pull/596
Rubygems bug when attempting to update root-owned gems: 
https://github.com/rubygems/rubygems/issues/796
Bundler bug report related to repo layout change: 
https://github.com/bundler/bundler/issues/2847
Rubygems bug report for things being broken by the 2.2 update: 
https://github.com/rubygems/rubygems/issues/874





Archive powered by MHonArc 2.6.16.

§