rabbitmq/chef-cookbook

Development repository for Chef cookbook RabbitMQ

chef-cookbook's Issues

More chefspec test coverage

Thanks @wenchma for taking this task.

Right now we have this:

ChefSpec Coverage report generated...

  Total Resources:   51
  Touched Resources: 11
  Touch Coverage:    21.57%

Untouched Resources:

  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-149cnve/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-149cnve/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1x48hgo/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1x48hgo/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1cgllj6/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1cgllj6/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1v6kvw6/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1v6kvw6/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1l2wc8o/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1l2wc8o/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1n0b106/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1n0b106/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-iw8vjk/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-iw8vjk/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1v5mc8p/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1v5mc8p/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  template[/etc/rabbitmq/rabbitmq.config]   rabbitmq/recipes/default.rb:174
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-bu5v0s/rabbitmq-server_3.4.2-1_all.deb]   rabbitmq/recipes/default.rb:43
  dpkg_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-bu5v0s/rabbitmq-server_3.4.2-1_all.deb]   rabbitmq/recipes/default.rb:47
  dpkg_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-7nzmh7/rabbitmq-server_3.4.2-1_all.deb]   rabbitmq/recipes/default.rb:47
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-2ogfd8/rabbitmq-server_3.4.2-1_all.deb]   rabbitmq/recipes/default.rb:43
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-q836nt/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-tthe44/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1ytyxqs/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-1ytyxqs/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  rabbitmq_plugin[rabbitmq_management]   rabbitmq/recipes/mgmt_console.rb:27
  rabbitmq_plugin[rabbitmq_management_visualiser]   rabbitmq/recipes/mgmt_console.rb:27
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-17q0r74/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-17q0r74/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-12jt872/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-12jt872/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  rabbitmq_policy[ha-all]            rabbitmq/recipes/policy_management.rb:25
  rabbitmq_policy[ha-two]            rabbitmq/recipes/policy_management.rb:25
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-h3mogj/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-h3mogj/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  rabbitmq_user[guest]               rabbitmq/recipes/user_management.rb:26
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-16xoi5y/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-16xoi5y/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112
  remote_file[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-l3qugo/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:108
  rpm_package[/var/folders/hl/zf_j1bvs7_b18rj7bbsm35p00000gp/T/d20141218-7153-l3qugo/rabbitmq-server-3.4.2-1.noarch.rpm]   rabbitmq/recipes/default.rb:112

As our test coverage. I'd love to see Touch Coverage: 21.57% go to 100%.

Chef >= 11.14.0 requirement

The user provider leverages a relatively new attribute on an execute block (sensitive). This makes a ton of sense, but the challenge here is that was only introduced in 11.14.0 which has been out "all that long". At the very least I think the README needs to call out the Chef version as a requirement. It would be even more awesome, if a check was done for Chef version and only use sensitive on versions that support it.

undefined method `sensitive' for Chef::Resource::Execute

I'm getting this error running the cookbook on opsworks:

My cookbook is here:
https://github.com/elevate/elevate-opsworks-rabbitmq

I'm using:

Chef 11.10
Berkshelf 3.2.0

NoMethodError

undefined method `sensitive' for Chef::Resource::Execute

Cookbook Trace:

/var/lib/aws/opsworks/cache.stage2/cookbooks/rabbitmq/providers/user.rb:88:in block (2 levels) in class_from_file' /var/lib/aws/opsworks/cache.stage2/cookbooks/rabbitmq/providers/user.rb:87:inblock in class_from_file'

Resource Declaration:

In /var/lib/aws/opsworks/cache.stage2/cookbooks/rabbitmq_cluster/recipes/default.rb

25: rabbitmq_user node['rabbitmq_cluster']['user'] do
26: password node['rabbitmq_cluster']['password']
27: action :add
28: end
29:

Compiled Resource:

Declared in /var/lib/aws/opsworks/cache.stage2/cookbooks/rabbitmq_cluster/recipes/default.rb:25:in `from_file'

rabbitmq_user("admin") do
action [:add]
retries 0
retry_delay 2
cookbook_name "rabbitmq_cluster"
recipe_name "default"
password "adminpasssword"
user "admin"
end

The mysql cookbook seems to have handled it recently:

def sensitive_supported?
Gem::Version.new(Chef::VERSION) >= Gem::Version.new('11.14.0')
end

in this commit:
sous-chefs/mysql@28f33de#diff-38a4aeddb4e620724d3b85362cb8b939

For this issue:

sous-chefs/mysql#246

New Rabbitmq release

The latest release of RabbitMQ is 3.4.2.
http://www.rabbitmq.com/download.html

Intermittent notifies issue with plugin provider

tl;dr;

The plugin provider actions send notifications before the plugins are actually enabled/disabled. This is due to new_resource.updated_by_last_action(true) being executed within the execute resource block.

See https://github.com/kennonkwok/rabbitmq/blob/master/providers/plugin.rb#L42

details

This problem occurs when trying to download rabbitmqadmin utility from the management plugin. To download this util, one must:

1. enable plugin
2. restart rabbitmq-server
3. download the utility from the management plugin webserver on port 15672

Here is my code:

rabbitmq_plugin "rabbitmq_management" do
  action :enable
  notifies :restart, "service[#{node['rabbitmq']['service_name']}]", :immediately # must restart before we can download
end

remote_file "/usr/local/bin/rabbitmqadmin" do
  source "http://localhost:15672/cli/rabbitmqadmin"
  mode "0755"
  retries 10  # extremely large non-deterministic wait/retry for rabbitmq_management to start serving pages
  action :create
end

This code is intermittently failing, with the remote_file giving up after 10 retries. The problem is that the service restart action is occurring before the execute run action. Here is the chef-client output showing the restart happening first:

Recipe: wrapper_cookbook::rabbitmq
  * rabbitmq_plugin[rabbitmq_management] action enable

Recipe: rabbitmq::default
  * service[rabbitmq-server] action restart
    - restart service service[rabbitmq-server]

Recipe: <Dynamically Defined Resource>
  * execute[rabbitmq-plugins enable rabbitmq_management] action runThe following plugins have been enabled:
  mochiweb
  webmachine
  rabbitmq_web_dispatch
  amqp_client
  rabbitmq_management_agent
  rabbitmq_management
Plugin configuration has changed. Restart RabbitMQ for changes to take effect.

    - execute rabbitmq-plugins enable rabbitmq_management

Recipe: wrapper_cookbook::rabbitmq
  * remote_file[/usr/local/bin/rabbitmqadmin] action create
    - create new file /usr/local/bin/rabbitmqadmin
================================================================================
Error executing action `create` on resource 'remote_file[/usr/local/bin/rabbitmqadmin]'
================================================================================


Errno::ECONNREFUSED
-------------------
Connection refused - Connection refused connecting to http://localhost:15672/cli/rabbitmqadmin, giving up


Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/wrapper_cookbook/recipes/rabbitmq.rb

 44: remote_file "/usr/local/bin/rabbitmqadmin" do
 45:   source "http://localhost:15672/cli/rabbitmqadmin"
 46:   mode "0755"
 47:   retries 10  # extremely large non-deterministic wait/retry for rabbitmq_management to start serving pages
 48:   action :create
 49: end

Installation fails if you decide to install erlang from sources

Hi,

When I try to install the default erlang packages in my AWS instance (prior to install rabbitmq), the release that is downloaded is 14.04, which is quite old. To be able to work with the latest one, I need to install erlang from sources passing a couple of parameters to the cookbook

default['erlang']['install_method'] = 'source'
default['erlang']['source']['version'] = '17.4'
default['erlang']['source']['url'] = 'url'
default['erlang']['source']['checksum'] = 'xxxxx'

The problem that I face is that when rabbitmq tries to install itself (from RPM) it fails to do it because of the erlang dependencies (does not find the erlang rpm installed).

It would be nice if you could include an option to pass "--nopeds" to the RPM rabbitmq installation so that it would not fail at this point.

Add support for multiple nodes on one machine

Hello,
I need support for running multiple nodes on one machine because of high availability. This nodes will be clustered..

Best regards
André

Not able to clear a policy which was created in a vhost

#203 See this pull request. It's really simple

undefined method `path' for Chef::Resource::Execute

Getting the following error when converging. Tested on CentOS 6.4 and Ubuntu 14.04:

* rabbitmq_plugin[rabbitmq_management] action enable[2014-12-05T15:59:34+00:00] INFO:    Processing rabbitmq_plugin[rabbitmq_management] action enable (rabbitmq::mgmt_console line 27)
[2014-12-05T15:59:34+00:00] INFO: Enabling RabbitMQ plugin 'rabbitmq_management'.


    ================================================================================
 Error executing action `enable` on resource 'rabbitmq_plugin[rabbitmq_management]'
     ================================================================================

NoMethodError
-------------
undefined method `path' for Chef::Resource::Execute

Cookbook Trace:
---------------
/tmp/kitchen/cookbooks/rabbitmq/providers/plugin.rb:43:in `block (2 levels) in class_from_file'
       /tmp/kitchen/cookbooks/rabbitmq/providers/plugin.rb:41:in `block in class_from_file'


       Resource Declaration:
       ---------------------

       # In /tmp/kitchen/cookbooks/rabbitmq/recipes/mgmt_console.rb

        27:   rabbitmq_plugin plugin do
        28:     action :enable

        29:     notifies :restart, "service[#{service_name}]", :immediately
        30:   end
        31: end

       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cookbooks/rabbitmq/recipes/mgmt_console.rb:27:in `block in from_file'


       rabbitmq_plugin("rabbitmq_management") do
         action [:enable]
         retries 0
         retry_delay 2
         default_guard_interpreter :default

         cookbook_name :rabbitmq
         recipe_name "mgmt_console"
         plugin "rabbitmq_management"
       end

   [2014-12-05T15:59:34+00:00] INFO: Running queued delayed notifications before re-raising exception

version pining does not work by default with use_distro_version

There are two attributes used when trying to install the rabbitmq package from the default disto repo:
use_distro_version which defaults to False, and version which defaults to 3.4.3.

if node['rabbitmq']['use_distro_version']
package 'rabbitmq-server' do
action :install
version node['rabbitmq']['version']
end

When setting the use_distro_version to true, it will most likely always fail since the version 3.4.3 is not usually available in the distro repo's yet. So, that means to have to specific the version attribute and are forced into pinning down your distro version. I think that's the opposite of what most folks want here when using the default distro version.

I would like to propose two choices here

A. Simple remove the version attribute from the distro package install resource. That would line up better with how most other cookbook are done.

B. Add another flag to make the pinning of the distro version optional, like:
if node['rabbitmq']['use_distro_version']
package 'rabbitmq-server' do
action :install
version node['rabbitmq']['version'] if node['rabbitmq']['pin_distro_version']
end

Opinions on which approach to take here?

Add sensitive flag for resources that expose passwords in log

The user add and change_password providers expose password on the execute command in the log.
The rabbitmq.conf exposed the user password in the log. Mark these resources as sensitive to keep that password info out of the log.
All resources already support the sensitive flag. The execute command had a bug with it and is being fixed with chef/chef#2013

Readme doesn't have 3.4.0 release

Readme doesn't have 3.4.0 release

No changelog for 3.10

3.10 isn't in the changelog

Default for heartbeat is set higher then suggested

According to the docs the default is 580.
https://www.rabbitmq.com/configure.html

https://github.com/jjasghar/rabbitmq/blob/master/attributes/default.rb#L94

Breaks in Chef 10

Getting error on Chef 10.30.4 and Vagrant 1.6.5

==> default: ================================================================================
==> default: Recipe Compile Error in /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/providers/plugin.rb
==> default: ================================================================================
==> default: NameError
==> default: ---------
==> default: undefined local variable or method `use_inline_resources' for #<Class:0x00000001ad3468>
==> default: Cookbook Trace:
==> default: ---------------
==> default:   /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/providers/plugin.rb:37:in `class_from_file'
==> default:
==> default: Relevant File Content:
==> default: ----------------------
==> default: /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/providers/plugin.rb:
==> default:
==> default:  30:    cmd.run_command
==> default:  31:    Chef::Log.debug "rabbitmq_plugin_enabled?: #{cmdstr}"
==> default:  32:    Chef::Log.debug "rabbitmq_plugin_enabled?: #{cmd.stdout}"
==> default:  33:    cmd.error!
==> default:  34:    cmd.stdout =~ /\b#{name}\b/
==> default:  35:  end
==> default:  36:
==> default:  37>> use_inline_resources
==> default:  38:
==> default:  39:  action :enable do
==> default:  40:    unless plugin_enabled?(new_resource.plugin)
==> default:  41:      execute "rabbitmq-plugins enable #{new_resource.plugin}" do
==> default:  42:        Chef::Log.info "Enabling RabbitMQ plugin '#{new_resource.plugin}'."
==> default:  43:        path plugins_bin_path(true)
==> default:  44:        new_resource.updated_by_last_action(true)
==> default:  45:      end
==> default:  46:    end
==> default:

CHEF-3694 warnings

In user_management.rb, all resources related to a particular user are named with the username. This triggers a bunch of CHEF-3694 warnings about resources being cloned.

I'm happy to work up a PR to name each resource uniquely (something like "add-USER", "set-tags-USER", etc.) but wanted to check to see if that's something you'd consider accepting before doing so.

Thanks!

Restarts after vhost creation

The virtualhost_management recipe restarts the rabbitmq service using notifications after each vhost resource. However, I can find nothing in the rabbitmq documentation that suggests a restart is needed. My testing also indicates it is not needed. Is there a need that you know of for that restart to be there?

New version 3.4.3 released

Check out @rabbitmq's Tweet: https://twitter.com/RabbitMQ/status/552798282129608704?s=09

I'll start the PR asap.

Foodcritic failures

FC009: Resource attribute not recognised: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/providers/user.rb:87
FC023: Prefer conditional attributes: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/providers/plugin.rb:40
FC023: Prefer conditional attributes: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/providers/plugin.rb:50
FC023: Prefer conditional attributes: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/recipes/default.rb:78
FC023: Prefer conditional attributes: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/recipes/default.rb:133
FC031: Cookbook without metadata file: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/metadata.rb:1
FC045: Consider setting cookbook name in metadata: /tmp/cook/89e99a3df11457cdf23ad2ac/rabbitmq/metadata.rb:1

3.4.4 has been released.

Check out @rabbitmq's Tweet: https://twitter.com/RabbitMQ/status/565801157361401857?s=09

rabbitmq-server can't be started when selinux is enforcing on redhat 7

rabbitmq-server can't be started when selinux is enforcing on Rhel7. If selinux is disabled or permissive, rabbitmq-server can be started. The error log is as below:

Recipe: rabbitmq::default

• package[rabbitmq-server] action install (up to date)
• service[rabbitmq-server] action enable
  • enable service service[rabbitmq-server]

* service[rabbitmq-server] action start

Error executing action start on resource 'service[rabbitmq-server]'

Mixlib::ShellOut::ShellCommandFailed

Expected process to exit with [0], but received '1'
---- Begin output of /sbin/service rabbitmq-server start ----
STDOUT:
STDERR: Redirecting to /bin/systemctl start rabbitmq-server.service
Job for rabbitmq-server.service failed. See 'systemctl status rabbitmq-server.service' and 'journalctl -xn' for details.
---- End output of /sbin/service rabbitmq-server start ----
Ran /sbin/service rabbitmq-server start returned 1

Resource Declaration:

In /var/chef/cache/cookbooks/rabbitmq/recipes/default.rb

107: service node['rabbitmq']['service_name'] do
108: action [:enable, :start]
109: end
110:

Compiled Resource:

Declared in /var/chef/cache/cookbooks/rabbitmq/recipes/default.rb:107:in `from_file'

service("rabbitmq-server") do
action [:enable, :start]
updated true
supports {:restart=>false, :reload=>false, :status=>true}
retries 0

---

enabled_plugins file permissions issue

After installing RabbitMQ via the cookbook, the /etc/rabbitmq/enabled_plugins file is set to permissions of 640 and is owned by the root user and group. Since Rabbit runs as the rabbitmq user, it can't read this file and I get this error:

Error description:
{error,
{cannot_read_enabled_plugins_file,"/etc/rabbitmq/enabled_plugins",
eacces}}

This prevents RabbitMQ from staying up and running. I have tried modifying the /etc/rabbitmq_enabled plugins file to chmod 644, however it always reverts back to 640. I have seen numerous other articles online about this exact issue, but they all say to chmod 644 the file, but as I mentioned it always reverts to 640 when I do this.

Has anyone else run into this issue with this cookbook? If so, how do I fix this properly/permanently? Thanks.

Wrong service provider used on Linux Mint

When using the 'rabbitmq' (https://supermarket.chef.io/cookbooks/rabbitmq) cookbook, chef-solo (v11.16.4) fails with:

Error executing action `enable` on resource 'service[rabbitmq-server]'
File '/etc/init/rabbitmq-server.conf' does not exist

This is because chef assumes that Linux Mint uses upstart; for the rabbitmq package, it's still using init.d.

So the action [:enable] attribute does the wrong thing.

(Originally reported as chef/chef#2726)

Type Error with newest code

Compiling Cookbooks...

Recipe Compile Error in /var/chef/cache/cookbooks/rabbitmq/libraries/default.rb

TypeError

Chef is not a module

Cookbook Trace:

/var/chef/cache/cookbooks/rabbitmq/libraries/default.rb:19:in `<top (required)>'

Relevant File Content:

/var/chef/cache/cookbooks/rabbitmq/libraries/default.rb:

12: # Unless required by applicable law or agreed to in writing, software
13: # distributed under the License is distributed on an "AS IS" BASIS,
14: # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15: # See the License for the specific language governing permissions and
16: # limitations under the License.
17: #
18:
19>> module Chef Software
20: # module rabbit
21: module RabbitMQ
22: # This method does some of the yuckiness of formatting parameters properly
23: # for rendering into the rabbit.config template.
24: def format_kernel_parameters # rubocop:disable all
25: rendered = [] # rubocop:enable all
26: kernel = node['rabbitmq']['kernel'].dup
27:
28: # This parameter is special and needs commas instead of periods.

Failed to connect to rabbitmq many times during openstack deployemnt

After delopy openstack successfully, open neutron server log
Expected result: In neutron server.log, it should to have such log to tell user you have to connect to AMQP server. " Connected to AMQP server on 127.0.0.1:5671". It should not have errors.
Actual result: In neutron server.log, it try many times to conenct to AMQP server, 10 mintues later, it connect to AMQP server finally.
Notes: Not only neutron have such issue, same as nova.etc.

/var/log/neutron/server.log

2014-08-15 01:36:33.112 19576 WARNING neutron.agent.securitygroups_rpc [-] Driver configuration doesn't match with enable_security_group
2014-08-15 01:36:33.187 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on 127.0.0.1:5671
2014-08-15 01:36:33.198 19576 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on 127.0.0.1:5671 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 seconds.
2014-08-15 01:36:34.200 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Delaying reconnect for 1.0 seconds...
2014-08-15 01:36:35.202 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on 127.0.0.1:5671
2014-08-15 01:36:35.214 19576 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on 127.0.0.1:5671 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 3 seconds.
2014-08-15 01:36:38.214 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Delaying reconnect for 1.0 seconds...
2014-08-15 01:36:39.222 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on 127.0.0.1:5671
2014-08-15 01:36:39.228 19576 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on 127.0.0.1:5671 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 5 seconds.
2014-08-15 01:36:44.232 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Delaying reconnect for 1.0 seconds...
2014-08-15 01:36:45.234 19576 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on 127.0.0.1:5671
2014-08-15 01:36:45.240 19576 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server on 127.0.0.1:5671 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 7 seconds.

Can't successfully rerun the cookbook if set the wrong parameter the first time

If the first time I set the wrong parameter e.g node['rabbitmq']['address'] , the cookbook exited when restarting the rabbitmq.
Then second time I corrected the node['rabbitmq']['address'], and rerun the recipe, it will exited before the reconfigure the rabbitmq-env.conf file. Because the recipe will try to start the rabbtimq before reconfigure at this line: https://github.com/jjasghar/rabbitmq/blob/master/recipes/default.rb#L115-L117

Change the rabbitmq config file path via cookbook will not take effect

We have a requirement to change the rabbitmq config file to a non-default path, but seems there is a potential problem in the current cookbook which prevents us from doing this.

We know there is an attribute in the cookbook:
"rabbitmq.config" which could be used to specify a non-default path of the rabbitmq config file from our perspective. Refer to the following code:
https://github.com/kennonkwok/rabbitmq/blob/master/attributes/default.rb#L19

But the config file path generated by the template resource in recipes/default.rb and the one specified in the templates/default/rabbitmq-env.conf.erb are not consistent, which results in that the config file won't take effect when rabbitmq-server starts.
Refer to the following code:
https://github.com/kennonkwok/rabbitmq/blob/master/recipes/default.rb#L157
https://github.com/kennonkwok/rabbitmq/blob/master/templates/default/rabbitmq-env.conf.erb#L18

Let's take an example to make this clearer: We cannot override attribute of "rabbitmq.config_root", which is "/etc/rabbitmq" in RHEL 6.5 in our case, since the path of file rabbitmq-env.conf cannot be changed per Operating System distribution. We can only change the rabbitmq.config to another path, say "/etc/rabbitmq/alternative/rabbitmq".

Here comes the problem: Since the file generated by the template resource in recipes/default.rb locates at "/etc/rabbitmq/rabbitmq.confg", but the one specified in "/etc/rabbitmq/rabbitmq-env.conf" will be "/etc/rabbitmq/alternative/rabbitmq". So the rabbitmq-server cannot find the config file at "/etc/rabbitmq/alternative/rabbitmq.config" when it starts, hence all the configuration will be missed.

BTW: A quick solution could be to change the following line:
https://github.com/kennonkwok/rabbitmq/blob/master/recipes/default.rb#L157
to be:
template "#{node['rabbitmq']['config']}.config" do

Please help to evaluate this potential problem, Hope it can be fixed early once it is confirmed to be a real issue.

Add auth_backends attribute

It would be nice to have an attribute to config the auth backends.

Kernel parameters errors

==> default: Recipe Compile Error in /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/recipes/default.rb
==> default: ================================================================================
==> default:
==> default:
==> default: NoMethodError
==> default: -------------
==> default: undefined method each_pair' for []:Array ==> default: ==> default: ==> default: Cookbook Trace: ==> default: --------------- ==> default: /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/libraries/default.rb:38:informat_kernel_parameters'
==> default: /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/recipes/default.rb:163:in from_file' ==> default: /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/recipes/default.rb:157:infrom_file'
==> default:
==> default:
==> default: Relevant File Content:
==> default: ----------------------
==> default: /tmp/vagrant-chef-3/chef-solo-1/cookbooks/rabbitmq/libraries/default.rb:
==> default:
==> default: 31: kernel.delete(:inet_dist_use_interface)
==> default: 32:
==> default: 33: # Otherwise, we can just render it nicely as Erlang wants. This
==> default: 34: # theoretically opens the door for arbitrary kernel_app parameters to be
==> default: 35: # declared.
==> default: 36:
==> default: 37: puts kernel.select { |k, v| !v.nil? }
==> default: 38>> kernel.select { |k, v| !v.nil? }.each_pair do |param, val|
==> default: 39: rendered << "{#{param}, #{val}}"
==> default: 40: end
==> default: 41:
==> default: 42: rendered.each { |r| r.prepend(' ') }.join(",\n")
==> default: 43: end
==> default: 44: end
==> default: 45: end
==> default: 46:
==> default:

Trying to get Rabbit installed in vagrant CentOs using chef. Using default recipe. Any help would be appreciated.

Configuring default_user and default_pass in rabbitmq.config is insecure

rabbitmq.config template file contains default_user and default_pass which are plain text, it is going to be a security risk.

{default_user, <<"<%= node['rabbitmq']['default_user'] %>">>},
{default_pass, <<"<%= node['rabbitmq']['default_pass'] %>">>}

In my opinion, we should remove the two configuration items.

chef run fails when using upstart

I explicitly set :rabbitmq:job_control to "upstart" and afterwards I get the the following error on chef runs (error on second to last line):

[2014-08-20T17:41:58+00:00] INFO: template[/etc/rabbitmq/rabbitmq.config] not queuing delayed action restart on servicerabbitmq-server, as it's already been queued
[2014-08-20T17:41:58+00:00] INFO: template[/etc/rabbitmq/rabbitmq.config] not queuing delayed action restart on servicerabbitmq-server, as it's already been queued
[2014-08-20T17:41:58+00:00] INFO: Processing service[stop rabbitmq-server] action stop (rabbitmq::default line 186)
[2014-08-20T17:41:58+00:00] INFO: Running queued delayed notifications before re-raising exception
[2014-08-20T17:41:58+00:00] INFO: template[/etc/rabbitmq/rabbitmq-env.conf] sending restart action to servicerabbitmq-server
[2014-08-20T17:41:58+00:00] INFO: Processing service[rabbitmq-server] action restart (rabbitmq::default line 73)
[2014-08-20T17:42:01+00:00] INFO: service[rabbitmq-server] restarted
[2014-08-20T17:42:01+00:00] ERROR: Running exception handlers
[2014-08-20T17:42:01+00:00] ERROR: Exception handlers complete
[2014-08-20T17:42:01+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-08-20T17:42:01+00:00] ERROR: service[stop rabbitmq-server](rabbitmq::default line 186) had an error: Errno::ENOENT: No such file or directory - /etc/init.d/rabbitmq-server stop
[2014-08-20T17:42:01+00:00] ERROR: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Checking the default.rb, I believe the issue is because it's missing a check for upstart as done previously. I.e. near the top:

Configure job control

if node['rabbitmq']['job_control'] == 'upstart'
...
service node['rabbitmq']['service_name'] do
provider Chef::Provider::Service::Upstart
action [:enable, :start]
# restart_command "stop #{node['rabbitmq']['service_name']} && start #{node['rabbitmq']['service_name']}"
end

but line 186 has no such check before hand and chef is defaulting to initd.

RabbitMQ Auto-Clustering

Hello and thanks for this great cookbook. I only have 1 problem with it. For the first time I have tried using the auto-cluster feature and just like you said in your README to enable cluster I changed:

default['rabbitmq']['cluster'] = true
default['rabbitmq']['cluster_disk_nodes'] = [ 'rabbit@dev-aws-ae1-rabbitmq01', 'rabbit@dev-aws-ae1-rabbitmq02', 'rabbit@dev-aws-ae1-rabbitmq03' ]

All these nodes get a role called rabbitmq which includes:
"recipe[rabbitmq_cluster]",
"recipe[rabbitmq_cluster::plugin_management]"

I just renamed the cookbook because I have another cookbook called rabbitmq.

I ran chef-client on these nodes many times, stopped and started rabbitmq multiple times manually but the cluster never gets connnected. All nodes act as single nodes.

[19:48:22][root@dev-aws-ae1-rabbitmq01][/var/log/rabbitmq] # rabbitmqctl cluster_status
Cluster status of node 'rabbit@dev-aws-ae1-rabbitmq01' ...
[{nodes,[{disc,['rabbit@dev-aws-ae1-rabbitmq01']}]},
{running_nodes,['rabbit@dev-aws-ae1-rabbitmq01']},
{cluster_name,<<"rabbit@dev-aws-ae1-rabbitmq01">>},
{partitions,[]}]
[19:54:18][root@dev-aws-ae1-rabbitmq01][/var/log/rabbitmq] #

I get the same status on all the other node except the hostname is different of course.

And I verified network connectivity between these 3 nodes and I have unrestricted network access and I mean ALL TCP/UDP/ICMP is open between all of these nodes.

Am I not specifying the default['rabbitmq']['cluster_disk_nodes'] attribute correctly ?

Thanks

.erlang.cookie is ignored

I have the .erlang.cookie and mnesia dir placed on an EBS volume.

I noticed with init.d, mnesia dir was still pointing to /var/lib/rabbitmq. I switched to upstart and it works fine for that.

I noticed also that it seems rabbit views its home directory as /var/lib/rabbitmq, and generates a .erlang.cookie there even though this cookbook creates one at the path I specified. I can find no way to ensure it uses the proper cookie (it defaults to the one in its home folder). I can verify this by looking at /var/log/rabbitmq/myserver.log

As a result, I have a wrapper cookbook create the rabbitmq user (I believe you rely on the .deb to do this) and set the home folder to where I also place the .erlang.cookie.

policy provider does not support apply-to

From http://www.rabbitmq.com/man/rabbitmqctl.1.man.html :

set_policy [-p vhostpath] [--priority priority] [--apply-to apply-to] {name} {pattern} {definition}

so

rabbitmqctl set_policy expiry '.*' '{"expires":300000}' --apply-to queues

cannot be accomplished with this provider.

Working with queues

This cookbook is pretty comprehensive when it comes it configuring an RMQ cluster, vhosts, users/permissions, however it does not provide a mechanism for declaring queues, which is a very common requirement when setting up a RabbitMQ cluster. I was wondering if there are plans to enhance this cookbook to work with queues? Thanks.

cannot_read_enabled_plugins_file - eacces

I'm not sure this is specifically an issue with the cookbook, but wanted to at least throw this out here for discussion.

Some systems have restrictive umasks (such as 0077). On these systems we get the exception below.

The umask by itself isn't so much the issue, but its seems the rabbitmq-plugins actually alters the state of this file as you can see in this output. If I alter the umask to 0022 for the current shell and run the command things work well.

So a "fix" could be to set the umask on the execute resource in the provider. Based on the docs it appears this can bet set just for the context of the resource so we wouldn't need to play with the system configured umask.

[root@hostname ~]# ls -alh /etc/rabbitmq/enabled_plugins 
-rw------- 1 root root 23 Dec 13 00:12 /etc/rabbitmq/enabled_plugins
[root@hostname ~]# chmod 644 /etc/rabbitmq/enabled_plugins 
[root@hostname ~]# ls -alh /etc/rabbitmq/enabled_plugins 
-rw-r--r-- 1 root root 23 Dec 13 00:12 /etc/rabbitmq/enabled_plugins
[root@hostname ~]# rabbitmq-plugins enable rabbitmq_management
Plugin configuration unchanged.

Applying plugin configuration to rabbit@hostname... failed.
Error: {cannot_read_enabled_plugins_file,"/etc/rabbitmq/enabled_plugins",
           eacces}
[root@hostname ~]# ls -alh /etc/rabbitmq/enabled_plugins 
-rw------- 1 root root 23 Dec 13 00:14 /etc/rabbitmq/enabled_plugins

       STDERR: Error: {cannot_read_enabled_plugins_file,"/etc/rabbitmq/enabled_plugins",
           eacces}
       ---- End output of rabbitmq-plugins enable rabbitmq_management ----
       Ran rabbitmq-plugins enable rabbitmq_management returned 2


       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/rabbitmq/providers/plugin.rb

        35:     execute "rabbitmq-plugins enable #{new_resource.plugin}" do
        36:       Chef::Log.info "Enabling RabbitMQ plugin '#{new_resource.plugin}'."
        37:       environment 'PATH' => "#{ENV['PATH']}:/usr/lib/rabbitmq/bin"
        38:       new_resource.updated_by_last_action(true)
        39:     end
        40:   end



       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/rabbitmq/providers/plugin.rb:35:in `block in class_from_file'

       execute("rabbitmq-plugins enable rabbitmq_management") do
         action "run"
         retries 0
         retry_delay 2
         guard_interpreter :default
         command "rabbitmq-plugins enable rabbitmq_management"
         backup 5
         environment {"PATH"=>"/sbin:/bin:/usr/sbin:/usr/bin:/opt/chef/embedded/bin:/opt/chef/embedded/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/rabbitmq/bin"}
         returns 0
         cookbook_name "rabbitmq"
       end

Documentation Fix - Rabbitmq_policy resource definition incorrect

The rabbitmq_policy resource definition is incorrect. It would error out on the params field. This pull request fixes the readme.md to properly define params.

#132

nodes not joining cluster

Hey there,

I'm using this chef recipe with Amazon opsWorks to create a cluster there. Everything seems to work perfect except for the fact that once the nodes are provisioned and all the configuration is place none of the nodes join each other as a cluster.

I have to go on each node and join them manually using rabbitmqclt. The configuration generated by the recipe seems correct. But still I need to do the manual job of join them together.

e.g.

%%%
%% Generated by Chef
%%%

[
  {kernel, [

  ]},
  {rabbit, [
    {cluster_nodes, {['rabbit@rabbitmq1','rabbit@rabbitmq2'], disc}},
    {cluster_partition_handling,ignore},
    {tcp_listen_options, [binary, {packet,raw},
                                  {reuseaddr,true},
                                  {backlog,128},
                                  {nodelay,true},
                                  {exit_on_close,false},
                                  {keepalive,false}]},
    {default_user, <<"guest">>},
    {default_pass, <<"guest">>}
  ]}
].

What is that that I'm doing wrong? is this a know issue?

Centos 7.0 support

Welp, it seems we need to work on Centos 7.0 support:

           ================================================================================
           Error executing action `install` on resource 'yum_package[erlang]'
           ================================================================================

           Chef::Exceptions::Exec
           ----------------------
            returned 1, expected 0

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/erlang/recipes/package.rb

            46:   package 'erlang'
            47: end

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/erlang/recipes/package.rb:46:in `from_file'

           yum_package("erlang") do
             action :install
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             package_name "erlang"
             version "17.4-1.el6"
             timeout 900
             flush_cache {:before=>false, :after=>false}
             declared_type :package
             cookbook_name "erlang"
             recipe_name "package"
           end

       [2014-12-18T14:04:40-05:00] INFO: Running queued delayed notifications before re-raising exception

       Running handlers:
       [2014-12-18T14:04:40-05:00] ERROR: Running exception handlers
       Running handlers complete
       [2014-12-18T14:04:40-05:00] ERROR: Exception handlers complete
       [2014-12-18T14:04:40-05:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       Chef Client failed. 4 resources updated in 71.715606627 seconds
       [2014-12-18T14:04:41-05:00] ERROR: yum_package[erlang] (erlang::package line 46) had an error: Chef::Exceptions::Exec:  returned 1, expected 0
       [2014-12-18T14:04:42-05:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

erlang broken

Can't use a recent version of erlang on RHEL because of the hardcoded compat rpm. Can't say I understand why that is needed, but it should either be removed or at least turned into an attribute.

['rabbitmq']['config'] should not be hard coding again

This line: https://github.com/jjasghar/rabbitmq/blob/master/attributes/default.rb#L19
default['rabbitmq']['config'] = '/etc/rabbitmq/rabbitmq'
I think it should use config_root attribute like this: default['rabbitmq']['config'] = "#{node['rabbitmq']['config_root']}/rabbitmq"

so we only need to configure the attribute ['rabbitmq']['config_root'] .

The same as line https://github.com/jjasghar/rabbitmq/blob/master/attributes/default.rb#L89

rabbitmq doesn't support package upgrade

If there exists a rabbitmq package installed, and we want to upgrade it to higher version, the current recipe will do nothing.
https://github.com/kennonkwok/rabbitmq/blob/master/recipes/default.rb#L95

loopback_users cannot be configured

Currently I'm using your excellent cookbook to install RabbitMQ.

We monitor RabbitMQ using Nagios and I want to use RabbitMQ's admin API to do certain checks using a read-only user that can only be used on localhost (similar to the default guest user in RabbitMQ).

RabbitMQ supports a feature called "loopback_users" that restricts user access to localhost only: https://www.rabbitmq.com/access-control.html

Unfortunately this configuration setting is not available in the cookbook. Is this intentional?

When updating the user attributes or the policy attributes they are not taken into consideration if the resource already exists

In the provider for user or policy there is an unless in the set action, so if I want to update some attribute for a user, this won't happen. I probably have to clear that user or that policy first, but it would be more natural to have an update action.

Add Gemfile.lock to Repository

As i have problems with some gem dependencies which did not occur yesterday i would like to ask, why there is no Gemfile.lock in the repository?
This would help to keep track of the specific gem versions and would allow us
to develop with the 'right' gem versions.

Greeting @it_supertramp

Replace the hard links for package sources with attributes

Replace the hard links for package sources with attributes

Use default version not working in CentOS

While yum-epel has packages for centos 6.5, 6.6, and 7.0- these packages are out of date and therefore will not likely align with the default 3.4.3. I think that the only way that it would, is if someone is replicating these to their own personal server. As such the "default-use-distro-version" test suite will always fail with our default values.

I have come up with a few solutions that I can submit a PR for.

1. Edit the test-suite "default-use-distro-version" with versions that we know are available in YUM epel. (probably the easiest and most clean)
2. Create a new test-suite in mini-test fashion and import a repo that might have up to date versions.
3. Deprecate this feature in CentOS since the packages from yum-epel are several x.Y.z behind.

Chef restarts RabbitMQ because it always set the permissions to all the users when it runs

Hi,

I was checking the code and I found that the cookbook use this command to detect user the policies:

cmd = "rabbitmqctl -q list_user_permissions #{name} | grep \"^#{vhost}\\b\""

When vhost is /, the grep command doesn't match and the function user_has_permissions? returns false (permissions found but do not match).

I tested the command manually:

#  rabbitmqctl -q list_user_permissions bell-rw
/       bell|q-.+@.+    bell|q-.+@.+    bell|q-.+@.+
# rabbitmqctl -q list_user_permissions bell-rw | grep "/\b"

And I tested the command grep by using the command echo to emulate the rabbitmqctl output:

# echo "/       bell|q-.+@.+    bell|q-.+@.+    bell|q-.+@.+"  | grep "/\b"
# echo "/lala       bell|q-.+@.+    bell|q-.+@.+    bell|q-.+@.+"  | grep "/lala\b"
/lala       bell|q-.+@.+    bell|q-.+@.+    bell|q-.+@.+

Regards.

RabbitMQ should get pinned on Debian based systems

A version pin for apt should be created on Debian based systems. This prevents the user from upgrading the package and then Chef downgrading the package on the next chef run. A lot of cookbooks use this pattern and it provides a nice gate to version upgrades / prevents downgrade problems.

Add missing attribute `rabbitmq.hipe_compile`

There is currently no way to set the hipe_compile RabbitMQ option.
The default should be "false" as it is experimental, but the performance boost is quite useful so the option should be exposed.