[Puppet Users] Re: Passenger with Puppet 3.0, problems running under

2015-05-18 Thread 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.

On Saturday, July 27, 2013 at 2:14:36 AM UTC+2, GregC wrote:
>
> 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
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7c8d5a8f-4968-43ea-9d5b-f479332fde1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: Passenger with Puppet 3.0, problems running under

2014-03-05 Thread jaredmacleod
Thank you.  I just ran into this also, and your post had the info I needed.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a7fd705b-3011-46bc-9e01-46cfae4a2116%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Puppet Users] Re: Passenger with Puppet 3.0, problems running under

2013-07-27 Thread 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


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.




[Puppet Users] Re: Passenger with Puppet 3.0, problems running under

2013-07-26 Thread 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

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.




[Puppet Users] Re: Passenger with Puppet 3.0, problems running under

2013-07-25 Thread 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://: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).


On Wednesday, July 24, 2013 5:26:26 PM UTC-4, Forrie wrote:
>
> 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 id="site_header">
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011 class="corporate_identity">
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011#011 class="logo">https://www.phusionpassenger.com"; 
> >Phusion
> Passenger
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011 id="site_body">
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011 class="error_title">Web application could not be started
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]: #011#011#011 id="content">
> Jul 24 14:51:14 de-prod-archive puppet-agent[28391]:
> #011#011#011#011exit (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:518:in
> `exit'
> 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:518:in
> `exit_on_fail'
> 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:362:in
> `run'
> 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:132:in
> `run'
>
>
>
> 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.   Bu