rabbitmq / chef-cookbook Goto Github PK
View Code? Open in Web Editor NEWDevelopment repository for Chef cookbook RabbitMQ
Home Page: https://supermarket.chef.io/cookbooks/rabbitmq
License: Apache License 2.0
Development repository for Chef cookbook RabbitMQ
Home Page: https://supermarket.chef.io/cookbooks/rabbitmq
License: Apache License 2.0
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.
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?
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
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.
Readme doesn't have 3.4.0 release
Replace the hard links for package sources with attributes
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
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:
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.
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
3.10 isn't in the changelog
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
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.
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 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.
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?
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.
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.
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.
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
undefined method `sensitive' for Chef::Resource::Execute
/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:in
block in class_from_file'
25: rabbitmq_user node['rabbitmq_cluster']['user'] do
26: password node['rabbitmq_cluster']['password']
27: action :add
28: end
29:
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:
==> 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:in
format_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:in
from_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.
Hello,
I need support for running multiple nodes on one machine because of high availability. This nodes will be clustered..
Best regards
Andrรฉ
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?
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.
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.
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)
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
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.
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
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.
Check out @rabbitmq's Tweet: https://twitter.com/RabbitMQ/status/552798282129608704?s=09
I'll start the PR asap.
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.
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
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
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!
Check out @rabbitmq's Tweet: https://twitter.com/RabbitMQ/status/565801157361401857?s=09
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
Compiling Cookbooks...
Chef is not a module
/var/chef/cache/cookbooks/rabbitmq/libraries/default.rb:19:in `<top (required)>'
/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.
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:
#203 See this pull request. It's really simple
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%.
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?
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.
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)
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
This problem occurs when trying to download rabbitmqadmin
utility from the management plugin. To download this util, one must:
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
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.
The latest release of RabbitMQ is 3.4.2.
http://www.rabbitmq.com/download.html
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
start
on resource 'service[rabbitmq-server]'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
107: service node['rabbitmq']['service_name'] do
108: action [:enable, :start]
109: end
110:
service("rabbitmq-server") do
action [:enable, :start]
updated true
supports {:restart=>false, :reload=>false, :status=>true}
retries 0
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
It would be nice to have an attribute to config the auth backends.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.