My Puppet master is using Passenger to serve. After upgrading to Puppet 3.0.0 I am getting the following error:
[ pid=17576 thr=70231398486460 file=utils.rb:176 time=2012-10-01 17:37:12.892 ]: *** Exception NoMethodError in PhusionPassenger::Rack::ApplicationSpawner (undefined method `-@' for "master":String) (process 17576, thread #): from config.ru:7 from /usr/lib/ruby/gems/1.8/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval' from /usr/lib/ruby/gems/1.8/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize' from config.ru:1:in `new' from config.ru:1
My config.ru is as follows:
# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.
# if puppet is not in your RUBYLIB:
# $LOAD_PATH.unshift('/opt/puppet/lib')
$0 = "master"
# if you want debugging:
# ARGV << "--debug"
ARGV << "--rack"
# Rack applications typically don't start as root. Set --confdir to prevent
# reading configuration from ~/.puppet/puppet.conf
ARGV << "--confdir" << "/etc/puppet"
# NOTE: it's unfortunate that we have to use the "CommandLine" class
# here to launch the app, but it contains some initialization logic
# (such as triggering the parsing of the config file) that is very
# important. We should do something less nasty here when we've
# gotten our API and settings initialization logic cleaned up.
#
# Also note that the "$0 = master" line up near the top here is
# the magic that allows the CommandLine class to know that it's
# supposed to be running master.
#
# --cprice 2012-05-22
require 'puppet/util/command_line'
# we're usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Util::CommandLine.new.execute
Any idea what may be happening?
I'm going to answer this as 'Works for me' now after I fixed up the Puppet module that was handling the server rack configuration and upgraded Puppet. I believe I may have been running into a situation where I modified the config.ru to the supplied version and Puppet would overwrite the version causing this to fail.
After updating my Puppet module and Puppet version to 3.0.1 (which could have been the culprit, but I never saw a bug report), this is now working fine.