Passenger with Puppet 3.0, problems running under

[Forrie]

Since upgrading to 3.x I've had some problems running Puppet under Passenger.   I've spent several /days/ debugging this.

The first symptoms included a new agent could not get a CA cert from the Puppet Master.   I checked my configs, permissions, etc.

When I run puppet master in stand-alone mode, it works fine.  

I wrote to the Phusion Passenger folks, but they are not familiar with Puppet and so I'm still trying to figure out what is wrong. 

We don't have selinux enabled.  "sestatus" confirms this.

SELinux status:                 disabled


Of the errors I see in the puppet logs relevant to this:

puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Could not prepare for execution: Got 3 failure(s) while initializing: Could not set 'file' on ensure:
 Permission denied - /var/log/puppet/masterhttp.log; Could not set 'file' on ensure: Permission denied - /var/log/puppet/masterhttp.log
puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Wrapped exception:
puppet.log:Jul 24 14:51:19 central puppet-master[30657]: Permission denied - /var/log/puppet/masterhttp.log; change from absent to file failed: Could not set
'file' on ensure: Permission denied - /var/log/puppet/masterhttp.log

I tried setting the "ownership" of the files in that directory to the same as the apache User, no difference.   Again, under regular Puppet there's no problem.

This is all I have in my config.ru:

$0 = "master"
ARGV << "--rack"
ARGV << "--confdir" << "/etc/puppet"
ARGV << "--vardir"  << "/var/lib/puppet"
require 'puppet/util/command_line'
run Puppet::Util::CommandLine.new.execute

More logs:

Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011<div
id="site_header">
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011<ul
class="corporate_identity">
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011#011<li
class="logo"><a href="https://www.phusionpassenger.com"><span>Phusion
Passenger</span></a></li>
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011</ul>
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011</div>
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011<div
id="site_body">
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011<h1
class="error_title">Web application could not be started</h1>
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011<div
id="content">
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
#011#011#011#011<pre>exit (SystemExit)
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb:<wbr>518:<wbr>in
`exit&apos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb:<wbr>518:<wbr>in
`exit_on_fail&apos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/application.rb:<wbr>362:<wbr>in
`run&apos;
Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
/usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util/command_line.rb:<wbr>132:<wbr>in
`run&apos;

It spits out a lot of HTML, CSS... and things I don't think should ever happen, on the client side.

Looks like it it exiting, mentioning line 518 of /usr/local/lib/ruby/gems/1.8/gems/puppet-3.2.3/lib/puppet/util.rb, the code of which 

is:

  # Now we need to catch *any* other kind of exception, because we may 
be calling third-party
  #  code (e.g. webrick), and we have no idea what they might throw.
  rescue Exception => err
    ## NOTE: when debugging spec failures, these two lines can be very 
useful
    #puts err.inspect
    #puts Puppet::Util.pretty_backtrace(err.backtrace)
    Puppet.log_exception(err, "Could not #{message}: #{err}")
    Puppet::Util::Log.force_flushqueue()
    exit(code)
  end

Anyway, I'm pretty stumped.   I am running Puppet 3.x on its own now.  We only have 40 nodes, so it works.   But I'd like to figure out what the heck is wrong with Passenger :-)

Anyone else encounter this problem?

Thanks.

[Jim Toth]

As I recall, if the config.ru itself isn't owned by the puppet user, we'll get similar errors from Passenger (spewing out an HTML error page, which the agents then unhelpfully log).

It might be something else -- given that it's HTML, you might want to just go to https://<your puppet server>:8140 in a browser and see what it's saying -- if all's well, then puppet will just say something like

The environment must be purely alphanumeric, not ''

And if that doesn't fix it, you could try uncommenting the debugging lines you quoted from puppet/util.rb.


I just took my own advice -- we're in the process of rebuilding a test puppet master, and in the process of writing this post I noticed that it was spewing HTML, and fairly clearly told me that I needed to do a "bundle install" since its Gemfile had changed (and the Gemfile.lock, which it was complaining about, is not owned by the puppet user by design).

[GregC]

i just went through same issue.

1. /etc/puppet/rack/puppetmaster/config.ru should be puppet:puppet
2. /var/log/puppet/masterhttp.log neexds to have permission set, not at my computer but i think its 644.

youWill see error message in /var/log/messages. hope this helps

[Forrie]

I found that.  And I was royally peeved, as nowhere in the logs was there any indication there was an issue.   The developers of Passenger pointed out that I can set options in the httpd.conf to specify a user and group -- but these products should be logging better data.

I literally spent days, going down avenues that I didn't need to go in order to solve this problem, which I randomly found by continuing to Google around.  SMH

[jaredm...@gmail.com]

Thank you.  I just ran into this also, and your post had the info I needed.

[Drew Boswell]

Saved us as well... had the same problem and ours was in group: http:www in stead of puppet:puppet. Changing it made everything work once again.

Thanks a bunch!

Andrew.