Quick notes on how I got chef-server 11 to work against rabbitmq server (3.1.1-1) so I don’t forget.
Chef-server 11 uses embedded services, unlike chef-server 10 where the services are externally managed. This is a very nice feature of chef-server 11 and the fact that it uses cookbooks to manage itself is pure genius on the Opscode part.
But I wanted to try some stuff with the message bus chef-server uses and to make those things easier I wanted to have the ability to add plugins and use other tools for ease of management and debugging.
While I could probably mod/hack the embedded rabbitmq, I would rather shut it off and use an external one so there’s less risk of my changes disappearing when I run a reconfigure on the chef-server, remember the cookbook thingy mentioned above.
Right off the bat I ran into issues, now this is most likely due to me using a newer version of rabbitmq than the chef-server 11 has in the embedded stack, but I wanted the newer shiny stuff.
Error I was seeing:
=ERROR REPORT==== 23-Jun-2013::06:36:54 ===
closing AMQP connection (127.0.0.1:44641 -> 127.0.0.1:5672):
"AMQPLAIN login refused: user 'chef' - invalid credentials",
Now, my first instinct was, oh the password was wrong, since the user is shown and is right.
Checking the commands I used to add the user it looked good, chefrocks, the default password.
So, quick test time.
I installed the amqp gem, did a quick google search for test code and fired it off:
#!/usr/bin/env ruby require 'rubygems' require 'amqp' event_loop = Thread.new do EM.run do EM.add_timer(1) do EM.stop end end end AMQP.start(:host => '127.0.0.1', :user => 'chef', :password => 'chefrocks', :vhost => '/chef') event_loop.join
Connected just fine, I have the rabbitmq_management plugin running so I could see the connections.
Well, that’s not the issue.
After a bit of spinning in circles, I decided to see which PID the failed connections where coming from, turns out to be erchef, which makes sense, and in the process list it shows the config file:
which is a symlink to, /var/opt/chef-server/erchef/etc/app.config
Looking at that I can see a crypted password string, figuring that string might be getting passed as plain text to the rabbitmq, I changed it to chefrocks and restarted the chef-server. It connected right up, though there was still an error about the invalid credentials along with the successful connections. Both chef-client and knife worked, but still something is failing to authenticate and that’s probably bad.
Looking at, Chef Server Components, you can see where rabbitmq fits in.
So on a hunch, I took at look at chef-expander.
There’s that crypted string again, so I changed it to chefrocks.
Restarted chef-server and not more errors showed up in the rabbitmq log.
Good deal, I will now have to test the different functions in chef, like search, but hopefully things will be good.
NOTE: I did a another test before finding the crypted strings on if bunny would connect, since chef-expander uses it.
I did have an issue with bunny 0.8.0 authenticating. After updating to bunny 0.9.0.rc1 I didn’t have the issue anymore.
Since chef-expander has bunny 0.6.0, I did try updating to 0.9.0.rc1. This didn’t fix the issue, it wasn’t until I changed the cryted string that things started working. I redid my setup to verify that was the case, and the two password changes seemed to have fixed my issues.