I'm a non-Ruby developer using Chef 11.10 on Amazon Linux AMI 2018.03, OpsWorks Agent v.3451.
My Route53 cookbook requires fog which requires fog-brightbox which requires an unspecified version of dry-inflector whose most recent version requires Ruby version 2.4 in its gemspec.
fog is installed via chef_gem which uses a separate version of Ruby reserved for use by the Chef client only, and it is not recommended to update this Ruby version as it may disable the Opsworks Agent.
Is the only way to get around this issue to fork and host each dependency in the chain, then force an earlier version of the deep dependency?
Version 0.1.2 of the dry-inflector gem doesn't require a specific version of Ruby.
Just install the gem with that specific version as soon as possible on your machine.
Related
When trying to install a ruby app via bundler, how does your system decide which version of Ruby to use?
Will I run into problems if i use a version of Ruby installed in a directory I do not have access to? If so, how do I ensure I use a version of Ruby installed in the correct directory.
For those voting to close, I am not looking for debugging help. I am looking for an understanding of how bundler decides which version of Ruby to use.
If your app has a Gemfile (most will) you can specify ruby version on Gemfile.
See this question Set ruby version in Gemfile
I'm trying to build a server on rackspace using chef 10.28.0, building the exact same configuration that I've built three times before without any changes. The only difference is that chef installed ohai 7.4.0 on the previous runs and this time it is installing ohai 8.0.1.
The problem is that chef 10.28.0 installs ruby 1.9.3, whereas ohai 8.0.1 requires ruby 2.0.0 or greater. From my googling I have found that chef 10 supports ruby 2.0 but installs ruby 1.9 by default. Is there any way to get chef 10 to install ruby 2.0 instead? Barring that, is there any way to get chef 10 to install ohai 7.4 instead of 8.0?
Thanks in advance.
Please use the omnibus installer packages. These include Ruby, Chef, Ohai, and all the other dependencies in a working configuration. You can download older versions of the omnibus installers from the download page:
Or you can use the -v option to the bootstrap scripts.
The answer was in the bootstrap scripts. We are using custom bootstrap scripts and the versions for ruby, chef and ohai are all in there.
I am using Puppet together with Librarian Puppet. Puppet is installed via the system's package manager, Librarian Puppet via Ruby gem. It only works when I install Ruby (1.9.3) via Debian's package manager. When I use RVM with the identical or another version (>= 1.9.3), I get an error from Librarian, saying that it cannot find puppet. Line 4 require 'puppet' in local.rbcauses the problem in Librarian. The puppet gem-based installation is not recommended and I don't want to do it that way. After some hours debugging, I found out that Ruby's search path differs when you use the package manager or RVM. Using RVM with Ruby 2.1.2, I get:
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/site_ruby/2.1.0
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/site_ruby/2.1.0/x86_64-linux
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/site_ruby
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/vendor_ruby/2.1.0
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/vendor_ruby/2.1.0/x86_64-linux
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/vendor_ruby
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/x86_64-linux
The puppet.rbis located at /usr/lib/ruby/vendor_ruby. This path is part of the search path if I install Ruby via Debian's package manager!
/usr/local/lib/site_ruby
...
/usr/lib/ruby/vendor_ruby
Is there any solution without installing puppet via gem?
librarian-puppet needs the puppet gem to parse the dependencies' Modulefile when using git and path modules. Not for Forge modules though
https://github.com/rodjek/librarian-puppet/blob/master/lib/librarian/puppet/source/local.rb#L8
https://github.com/rodjek/librarian-puppet/pull/62
I'm running chef-client on Windows, and as it happens, the Ruby distribution (1.9.3) embedded in Chef-Client is available system-wide. I believe this is necessary in order to have chef-client function properly? I have tried installing another Ruby distribution (namely, v2.0) but that seems to break Chef-Client.
What I was hoping to achieve is to have chef-client install & configure a Ruby app written against v2.0, so that I can run that app with v2 but have chef-client continue to use the embedded Ruby distribution.
Would that not be possible?
Sure, that's why Opscode is using their Omnibus packages, which ships everything required to run Chef.
Use the "gem_binary" attribute to specify the ruby distro:
gem_package "somegem" do
gem_binary "/usr/bin/gem"
action :install
end
The documentation describe the parameter as follows:
gem_binary: An attribute for the gem_package provider that is used to specify a gems binary. This attribute is useful when installing Ruby 1.9 gems while running in Ruby 1.8. By default, the same version of Ruby that is used by the chef-client will be installed.
I am running RHEL 6.2 on a VM (I have no control over it). I would like to use Ruby along with Mysql to do the work I need to do. But right now the server does not have the mysql gem installed. It doesn't even have ruby gems installed. So I can't simply do gem install mysql. The people maintaining the server suggested I do local install of ruby gems. Is there a benefit to this? What if the server is hosting a web application that consists of code depending on a gem? Will this effect anything?
Either in ~/.gem (local) or in /usr/lib/ruby (system). Locally installed gems are accessible by you only, system gems everyone can use.