The current version of the opscode chef-server and chef-client have some issues with cloud data with linode based hosts.
It basically comes down to having a lot of nil values for the node attributes even though `node.cloud` is not `nil` or `null`
This causes issues with many cookbooks which depend on these attributes being set – like nagios and mysql.
the node.cloud attribute will return something like this:
=> {“public_ips”=>[“1.2.3.4”], “private_ips”=>[nil], “public_ipv4″=>nil, “public_hostname”=>nil, “local_ipv4″=>nil, “local_hostname”=>nil, “provider”=>”linode”}
The linode ruby gem is what is not setting these attributes correctly.
The error may look like:
Compiled Resource:
——————
# Declared in /var/chef/cache/cookbooks/nagios/definitions/nagios_conf.rb:29:in `block in from_file’
Or mysql may not start
The simplest workaround that I found was to look for the `linode.rb` file, which on Ubuntu is located somewhere like:
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/ohai-6.20.0/lib/ohai/plugins/linode.rb
Next I commented out the functions to return if this is a linode node or not and instead added the false value:
# Identifies the linode cloud by preferring the hint, then
#
# Returns true or false
def looks_like_linode?
#hint?(‘linode’) || has_linode_kernel?
false
end
It is a one line change and can be removed later and/or will be removed by reinstalling the chef omnibus package again – hopefully by then this linode issue will be fixed.
Why this works:
A lot of recipes try to be smart and if a node is on a cloud platform they will try to use the internal network address instead of the external address and fancy things like that. This change tells it “hey – this is not a cloud platform” and so the public IP will be used instead of giving an hash that has nil values for internal and external addresses on linode.
Make sure to re-run chef-client after making this change.
