Giter VIP home page Giter VIP logo

chef-cookbook's Introduction

RabbitMQ Chef Cookbook

Build Status Cookbook Version

This is a cookbook for managing RabbitMQ with Chef.

Supported Chef Versions

This cookbook targets Chef 14.0 and later.

Supported RabbitMQ Versions

5.x release series targets RabbitMQ 3.8.x releases.

For any series used, a supported Erlang version must be provisioned.

Supported Distributions

The cookbook generally targets the same Debian-based distribution versions that RabbitMQ core team supports:

  • Recent and community supported versions of Ubuntu, e.g. 22.04 and later
  • Debian 11 (Bullseye) and 12 (
  • RHEL 8+
  • CentOS Stream 9
  • Fedora 35 or later
  • Amazon Linux 2023
  • Rocky Linux 9
  • Alma Linux 9

Newer Versions

Newer Debian, Ubuntu and RHEL/Fedora/CentOS Stream versions should work.

Dependencies

This cookbook depends on the Erlang cookbook and assumes that the user can configure it to provision a supported Erlang/OTP version.

Two more recipes are provided by this cookbook:rabbitmq::erlang_package and rabbitmq::esl_erlang_package. The latter is an alias to the erlang::esl recipe in the Erlang cookbook.

The former uses Debian Erlang packages and zero dependency Erlang RPM package produced and published by Team RabbitMQ. Those packages provide the latest patch releases of Erlang/OTP.

Both options are covered below.

Provisioning RabbitMQ 3.9.x and 3.8.x (both out of support)

Ensure Your Cookbook Version is Compatible

To provision RabbitMQ 3.9.x or 3.8.x, you must use version 5.8.5 of this cookbook or later.

Provision Erlang/OTP 23.2 or Later

Before provisioning a 3.9.x or 3.8.x release, please learn about the minimum required Erlang/OTP version and Erlang/OTP version recommendations.

Most distributions provide older versions, so Erlang must be provisioned either using RabbitMQ's zero dependency Erlang RPM, Debian Erlang packages, or from Erlang Solutions

Installing Erlang Using Packages by Team RabbitMQ

rabbitmq::erlang_package is a recipe that provisions latest Erlang packages from team RabbitMQ. The packages support

  • Debian 10 and 11
  • Ubuntu 18.04 through 20.04
  • RHEL 8
  • CentOS Stream 8
  • Fedora 32 or later
  • Amazon Linux 2022
  • Scientific Linux 7

The packages are cannot be installed alongside with other Erlang packages, for example, those from standard Debian repositories or Erlang Solutions.

To make sure that the Erlang cookbook is not used by rabbitmq::default, rabbitmq::cluster, and other recipes, set node['rabbitmq']['erlang']['enabled'] to true:

node['rabbitmq']['erlang']['enabled'] = true

By default rabbitmq::erlang_package will install the latest Erlang version available. To override package version, use node['rabbitmq']['erlang']['version']:

# Debian
node['rabbitmq']['erlang']['version'] = '1:24.3.3-1'

# RPM
node['rabbitmq']['erlang']['version'] = '24.3.3'

On Ubuntu and Debian the distribution will be picked from node attributes.

Most of the time there is no need to override other attributes. Below is a list of defaults used on Ubuntu and Debian:

# RabbitMQ Erlang packages
deb_distro = value_for_platform(
  'debian' => {
    'default' => 'debian'
  },
  'ubuntu' => {
    'default' => 'ubuntu'
  }
)

default['rabbitmq']['erlang']['apt']['uri'] = "https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/deb/#{deb_distro}"
default['rabbitmq']['erlang']['apt']['lsb_codename'] = node['lsb']['codename']
default['rabbitmq']['erlang']['apt']['components'] = ["main"]
default['rabbitmq']['erlang']['apt']['key'] = 'https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/gpg.E495BB49CC4BBE5B.key'

default['rabbitmq']['erlang']['apt']['install_options'] = %w(--fix-missing)

On CentOS Stream 8, base Yum repository URL will be picked based on distribution versions. On Fedora, a suitable CentOS package will be used. Erlang package version is set the same way as for Debian (see above).

Below are the defaults used by the Yum repository (assuming RHEL or CentOS Stream 8):

# CentOS 8, RHEL 8, Fedora
default['rabbitmq']['erlang']['yum']['baseurl'] = 'https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/rpm/el/8/$basearch'
default['rabbitmq']['erlang']['yum']['gpgkey'] = 'https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/gpg.E495BB49CC4BBE5B.key'
default['rabbitmq']['erlang']['yum']['gpgcheck'] = true
default['rabbitmq']['erlang']['yum']['repo_gpgcheck'] = false

Installing Erlang with the Erlang Cookbook

The Erlang cookbook will provision packages from Erlang Solutions if node['erlang']['install_method'] is set to esl. Note that Erlang Solutions repositories can be behind the latest Erlang/OTP patch releases.

# will install the latest release, please
# consult with https://www.rabbitmq.com/which-erlang.html first
node['erlang']['install_method'] = "esl"

to provision a specific version, e.g. 24.3.3:

node['erlang']['install_method'] = "esl"
# Ubuntu and Debian
# note the "1:" package epoch prefix
node['erlang']['esl']['version'] = "1:24.3.3"
node['erlang']['install_method'] = "esl"
# CentOS, RHEL, Fedora
node['erlang']['esl']['version'] = "24.3.3-1"

Seting RabbitMQ Version

Set node['rabbitmq']['version'] to specify a version:

node['rabbitmq']['version'] = "3.9.14"

If you have node['rabbitmq']['deb_package_url'] or node['rabbitmq']['rpm_package_url'] overridden from earlier versions, consider omitting those attributes. Otherwise see a section on download location customization below.

RabbitMQ packages will be downloaded from Cloudsmith.

Recipes

default

Installs rabbitmq-server via direct download (from Bintray or GitHub, depending on the version) of the installation package or using the distribution version. Depending on your distribution, the provided version may be quite old so direct download is the default option.

Clustering Essentials

Set the ['rabbitmq']['clustering']['enable'] attribute to true, ['rabbitmq']['clustering']['cluster_disk_nodes'] array of node@host strings that describe cluster members, and a alphanumeric string for the erlang_cookie.

TLS

To enable TLS for client connections, set the ssl to true and set the paths to your cacert, cert and key files.

node['rabbitmq']['ssl'] = true
# path to the CA bundle file
node['rabbitmq']['ssl_cacert'] = '/path/to/cacert.pem'
# path to the server certificate (pubic key) PEM file
node['rabbitmq']['ssl_cert'] = '/path/to/cert.pem'
# path to the server private key file
node['rabbitmq']['ssl_key'] = '/path/to/key.pem'

Client Connection Listeners

TCP connection listeners may be limited to a specific interface using the node['rabbitmq']['tcp_listen_interface'] attribute.

Its TLS connection listener counterpart is node['rabbitmq']['ssl_listen_interface'].

Custom Package Download Locations

node['rabbitmq']['deb_package_url'] and node['rabbitmq']['rpm_package_url'] can be used to override the package download location. They configure a prefix without a version. Set them to a download location without a version if you want to provision from a custom endpoint such as a local mirror.

The default recipe will append a version suffix that matches RabbitMQ tag naming scheme. For 3.7.x or later, it is just the version (the value is used as is).

Lastly, a package name will be appended to form a full download URL. They rarely need changing but can also be overridden using the node['rabbitmq']['deb_package'] and node['rabbitmq']['rpm_package'] attributes.

Attributes

A full list of attributes related to TLS in RabbitMQ can be found in attributes/default.rb.

Default values and usage information of important attributes are shown below. More attributes are documented in metadata.rb.

Username and Password

The default username and password are guest/guest, with access limited to localhost connections:

['rabbitmq']['default_user'] = 'guest'
['rabbitmq']['default_pass'] = 'guest'

It is highly recommended that a different default user name is used with a reasonably long (say, 30-40 characters) generated password.

Loopback Users

By default, the guest user can only connect from localhost. This prevents remote access for installations that use the well-known default credentials. It is highly recommended that remote access for the default user is not enabled but if security is of absolutely no importance in a certain environment, this can be done:

['rabbitmq']['loopback_users'] = []

Learn more in the RabbitMQ Access Control guide.

Definitions Import

It is possible to to load a definitions (schema) file on node boot. Consult RabbitMQ's Definitions and Backup doc guides to learn more.

To configure definition loading, set the following attribute:

['rabbitmq']['management']['load_definitions'] = true

By default, the node will be configured to load a JSON at /etc/rabbitmq/load_definitions.json; however, you can define another path if you'd prefer using the following attribute:

['rabbitmq']['management']['definitions_file'] = '/path/to/your/definitions.json'

In order to use this functionality, you will need to provision a file referenced by the above attribute before you execute any recipes in the RabbitMQ cookbook (in other words, before the node starts). For example, this can be done using a remote file resource.

management_ui

Installs the RabbitMQ management plugin.

To enable HTTPS for the management UI and HTTP API, set ['rabbitmq']['web_console_ssl'] attribute to true. The HTTPS port for the management UI can be configured by setting attribute ['rabbitmq']['web_console_ssl_port'], whose default value is 15671.

plugins

Enables any plugins listed in the node['rabbitmq']['enabled_plugins'] and disables any listed in node['rabbitmq']['disabled_plugins'] attributes.

LDAP Configuration

To enable the LDAP plugin, a few attributes have to be used in combination:

  1. Set node['rabbitmq']['ldap']['enabled'] = true
  2. Enable auth_backends: node['rabbitmq']['auth_backends'] = 'rabbit_auth_backend_internal,rabbit_auth_backend_ldap'
  3. Enable the rabbitmq_auth_backend_ldap plugin
  4. Configure LDAP servers and queries via the node['rabbitmq']['ldap']['conf'] variable
Example configuration
# this is just an example
node['rabbitmq']['ldap']['conf'] = {
  :servers => ["ldap-host1", "ldap-host2"],
  :user_bind_pattern => "${username}@<domain>",
  :dn_lookup_attribute => "sAMAccountName",
  :dn_lookup_base => "DC=<CHANGEME>,DC=<CHANGEME>",
  :port => <CHANGEME (number)>,
  :log => <CHANGEME (boolean)>,
  :vhost_access_query => '{constant, true}',
  :topic_access_query => '{constant, true}',
  :resource_access_query => '{constant, true}',
  :tag_queries => "[{administrator, {constant, false}}]"
  }

users

Enables any RabbitMQ users listed in the node['rabbitmq']['enabled_users'] and disables any listed in node['rabbitmq']['disabled_users'] attributes. You can provide user credentials, the vhosts that they need to have access to and the permissions that should be allocated to each user.

node['rabbitmq']['enabled_users'] = [
    {
        :name => 'kitten',
        :password => 'kitten',
        :tag => 'leader',
        :rights => [
            {
                :vhost => 'nova',
                :conf => '.*',
                :write => '.*',
                :read => '.*'
            }
        ]
    }
]

Note that with this approach user credentials will be stored in the attribute file. Using encrypted data bags is therefore highly recommended.

Alternatively definitions export and import (see above) can be used. Definition files contain password hashes since clear text values are not stored.

vhosts

Enables any virtual hosts listed in the node['rabbitmq']['virtualhosts'] and disables any listed in node['rabbitmq']['disabled_virtualhosts'] attributes.

cluster

Forms a cluster RabbitMQ of nodes.

It supports two clustering modes: auto or manual.

  • Auto clustering: lists cluster members in the RabbitMQ config file. Those are taken from lists the nodes node['rabbitmq']['clustering']['cluster_nodes'].
  • Manual clustering : joins cluter members using rabbitmqctl join_cluster.

Attributes

  • node['rabbitmq']['clustering']['enable'] : Default decision flag of clustering
  • node['rabbitmq']['erlang_cookie'] : Same erlang cookie is required for the cluster
  • node['rabbitmq']['clustering']['use_auto_clustering'] : Default is false. (manual clustering is default)
  • node['rabbitmq']['clustering']['cluster_name'] : Name of cluster. default value is nil. In case of nil or '' is set for cluster_name, first node name in node['rabbitmq']['clustering']['cluster_nodes'] attribute will be set for manual clustering. for the auto clustering, one of the node name will be set.
  • node['rabbitmq']['clustering']['cluster_nodes'] : List of cluster nodes. it required node name and cluster node type. please refer to example in below.

Example

node['rabbitmq']['clustering']['enable'] = true
node['rabbitmq']['erlang_cookie'] = 'AnyAlphaNumericStringWillDo'
node['rabbitmq']['clustering']['cluster_partition_handling'] = 'pause_minority'
node['rabbitmq']['clustering']['use_auto_clustering'] = false
node['rabbitmq']['clustering']['cluster_name'] = 'qa_env'
node['rabbitmq']['clustering']['cluster_nodes'] = [
    {
        :name => 'rabbit@rabbit1'
    },
    {
        :name => 'rabbit@rabbit2'
    },
    {
        :name => 'rabbit@rabbit3'
    }
]

policies

Enables any policies listed in the node['rabbitmq']['policies'] and disables any listed in node['rabbitmq']['disabled_policies'] attributes.

See examples in attributes file.

community_plugins

Downloads, installs and enables pre-built community plugins binaries.

To specify a plugin, set the attribute node['rabbitmq']['community_plugins']['PLUGIN_NAME'] to '{DOWNLOAD_URL}'.

Available Resources/Providers

There are several LWRPs for interacting with RabbitMQ and a few setting up Erlang repositories and package.

erlang_apt_repository_on_cloudsmith

erlang_apt_repository_on_cloudsmith sets up a Debian package repository from Cloudsmith. It is a wrapper around the standard apt_repository resource provider.

See also RabbitMQ Erlang Compatibility guide.

rabbitmq_erlang_apt_repository_on_cloudsmith 'rabbitmq_erlang_repo_on_cloudsmith' do
  distribution node['lsb']['codename'] unless node['lsb'].nil?

  action :add
end

erlang_yum_repository_on_cloudsmith

erlang_apt_repository_on_cloudsmith sets up an RPM package repository from Bintray. It is a wrapper around the standard apt_repository resource provider.

See also RabbitMQ Erlang Compatibility guide.

rabbitmq_erlang_yum_repository_on_cloudsmith 'rabbitmq_erlang' do
  # for RHEL/CentOS 8+, Fedora. See https://www.rabbitmq.com/install-rpm.html.
  baseurl 'https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/rpm/el/8/$basearch'

  action :add
end

erlang_package_from_cloudsmith

Install the package. Here's an example for Debian-based systems:

rabbitmq_erlang_package_from_cloudsmith 'rabbitmq_erlang' do
  # This package version assumes a Debian-based distribution.
  version '1:24.3.3-1'

  action :install
end

Here's another one for RPM-based ones:

rabbitmq_erlang_package_from_cloudsmith 'rabbitmq_erlang' do
  version '24.3.3'

  action :install
end

plugin

Enables or disables a rabbitmq plugin. Plugins are not supported for releases prior to 2.7.0.

  • :enable enables a plugin
  • :disable disables a plugin

Examples

rabbitmq_plugin "rabbitmq_stomp" do
  action :enable
end
rabbitmq_plugin "rabbitmq_shovel" do
  action :disable
end

policy

Sets or clears a RabbitMQ policy.

  • :set sets a policy
  • :clear clears a policy

Examples

rabbitmq_policy "queue-length-limit" do
  pattern "^limited\\.*"
  definition ({"max-length" => "3000"})
  priority 1
  action :set
end

user

Adds and deletes users:

  • :add adds a user with a password
  • :delete deletes a user
  • :set_permissions sets the permissions for a user, vhost is optional
  • :clear_permissions clears the permissions for a user
  • :set_tags set the tags on a user
  • :clear_tags clear any tags on a user
  • :change_password set the password for a user

Examples

rabbitmq_user "guest" do
  action :delete
end
rabbitmq_user "nova" do
  password "sekret"
  action :add
end
rabbitmq_user "nova" do
  vhost "/nova"
  permissions ".* .* .*"
  action :set_permissions
end
rabbitmq_user "rmq" do
  vhost ["/", "/rmq", "/nova"]
  permissions ".* .* .*"
  action :set_permissions
end
rabbitmq_user "joe" do
  tag "admin,lead"
  action :set_tags
end

vhost

Adds and deletes virtual hosts.

  • :add adds a vhost
  • :delete deletes a vhost

Examples

rabbitmq_vhost "/nova" do
  action :add
end

cluster

Forms a cluster and controls cluster name. This is an imperative version of classic config peer discovery in modern RabbitMQ versions.

  • :join join in cluster as a manual clustering. node will join in first node of json string data.

  • cluster nodes as JSON: all cluster nodes should be listed.

[
    {
        "name" : "rabbit@rabbit1",
        "type" : "disc"
    },
    {
        "name" : "rabbit@rabbit2",
        "type":  "disc"
    },
    {
        "name" "rabbit@rabbit3",
        "type" : "disc"
    }
]
  • :set_cluster_name set the cluster name

Examples

rabbitmq_cluster '[{"name":"rabbit@rabbit1", "type":"disc"},{"name":"rabbit@rabbit2", "type":"disc"},{"name":"rabbit@rabbit3", "type":"disc"}]' do
  action :join
end
rabbitmq_cluster '[{"name":"rabbit@rabbit1","type":"disc"},{"name":"rabbit@rabbit2", ,"type":"disc"},{"name":"rabbit@rabbit3","type":"disc"}]' do
  cluster_name 'seoul_tokyo_newyork'
  action :set_cluster_name
end
rabbitmq_cluster '[{"name":"rabbit@rabbit1","type":"disc"},{"name":"rabbit@rabbit2", ,"type":"disc"},{"name":"rabbit@rabbit3","type":"disc"}]' do
  action :change_cluster_node_type
end

Removing Nodes from an Existing Cluster

This cookbook provides the primitives to remove a node from a cluster via helper functions but do not include these in any recipes. This is something that is potentially very dangerous and different deployments will have different needs and IF you decide you need this it should be implemented in your wrapper with EXTREME caution. There are 2 helper methods for 2 different scenario:

  • removing self from cluster. This should likely only be considered for machines on a normal decommission. This is accomplished by using the helper fucntion reset_current_node.
  • removing another node from cluster. This should only be done once you are sure the machine is gone and won't come back. This can be accomplished via remove_remote_node_from_cluster.

Limitations

For an already running cluster, these actions still require manual intervention:

  • changing the shared cluster secret using the :erlang_cookie attribute
  • disabling clutering entirely by setting :cluster from true to false

License & Authors

  • Author:: Benjamin Black
  • Author:: Daniel DeLeo
  • Author:: Matt Ray
  • Author:: Seth Thomas
  • Author:: JJ Asghar
  • Author:: Team RabbitMQ
Copyright (c) 2009-2018, Chef Software, Inc.
Copyright (c) 2018-2021, VMware, Inc. or its affiliates.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

chef-cookbook's People

Contributors

amulyas avatar bdwyertech avatar bphinney avatar cheeseplus avatar dependabot[bot] avatar farshidce avatar flah00 avatar harlanbarnes avatar jessedavis avatar jgarnett-zynga avatar jjasghar avatar jschneiderhan avatar kamaradclimber avatar kramvan1 avatar lukebakken avatar mattray avatar michaelklishin avatar mmiller1 avatar portertech avatar refaelyehuda avatar rmoriz avatar ruizink avatar sethcall avatar sethvargo avatar shortdudey123 avatar stefansundin avatar sunggun-yu avatar tas50 avatar theseubert avatar wing924 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

chef-cookbook's Issues

.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.

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%.

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


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.

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

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)

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

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.

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:

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

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.

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.

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.

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

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?

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?

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

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.

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.

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

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.

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

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!

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.

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.

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.

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.

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.

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.

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

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.

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 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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.