I think I know why the passenger-apache2 cookbook is failing. I think
the problem is with the apache2 cookbook. Here is the module in
question https://github.com/opscode/cookbooks/blob/master/apache2/definitions/apache_module.rb
Notice that it does not create the load file if the OS is
debian/ubuntu. I changed the recipe to add debian and ubuntu and it
seems to run OK.
Seems like a simple fix but I thought I’d run it by you guys first in
case I am missing something.
Hey Tim,
I believe that bit of code is part of an effort by the author of the
cookbook to make all of the flavors of Linux have a Debian-like Apache
configuration setup. Any time I've installed an Apache module on Ubuntu,
the .load file has always come with it. Have you found this not to be the
case?
-Matt Moretti
On Sun, Jan 8, 2012 at 5:51 AM, Tim Uckun timuckun@gmail.com wrote:
I think I know why the passenger-apache2 cookbook is failing. I think
the problem is with the apache2 cookbook. Here is the module in
question
https://github.com/opscode/cookbooks/blob/master/apache2/definitions/apache_module.rbNotice that it does not create the load file if the OS is
debian/ubuntu. I changed the recipe to add debian and ubuntu and it
seems to run OK.Seems like a simple fix but I thought I'd run it by you guys first in
case I am missing something.
I believe that bit of code is part of an effort by the author of the
cookbook to make all of the flavors of Linux have a Debian-like Apache
configuration setup. Any time I've installed an Apache module on Ubuntu,
the .load file has always come with it. Have you found this not to be the
case?
If the .load file and the .conf file are both in the mods-enabled
directory then a2enmod will handle both of them properly. In this
case the recipe was not creating the .load file if the OS is
ubuntu/debian so I think that's clearly not right.
Right, the 'a2enmod' / 'a2dismod' script manages the symlinks. On
non-ubuntu/debian systems, this has to be managed by robot.
Hope this helps!
Cheers,
AJ
On 10 January 2012 09:42, Tim Uckun timuckun@gmail.com wrote:
I believe that bit of code is part of an effort by the author of the
cookbook to make all of the flavors of Linux have a Debian-like Apache
configuration setup. Any time I've installed an Apache module on Ubuntu,
the .load file has always come with it. Have you found this not to be the
case?If the .load file and the .conf file are both in the mods-enabled
directory then a2enmod will handle both of them properly. In this
case the recipe was not creating the .load file if the OS is
ubuntu/debian so I think that's clearly not right.
On Tue, Jan 10, 2012 at 10:13 AM, AJ Christensen aj@junglist.gen.nz wrote:
Right, the 'a2enmod' / 'a2dismod' script manages the symlinks. On
non-ubuntu/debian systems, this has to be managed by robot.
Again the issue is not the management of the files the issue is the
creation of the files. The apache2 recipe does not create the .load
file for ubuntu/debian based systems (at least not for the passenger
module).
Maybe the fault is with the passenger_apache2 recipe I don't know but
in order to install passenger on ubuntu I had to add ubuntu to the
list like this...
if platform?("redhat", "centos", "scientific", "fedora", "arch",
"suse" , "debian", "ubuntu")
file "#{node['apache']['dir']}/mods-available/#{params[:name]}.load" do
content "LoadModule #{params[:name]}_module #{params[:module_path]}\n"
mode 0644
end
end
On 10 January 2012 10:16, Tim Uckun timuckun@gmail.com wrote:
On Tue, Jan 10, 2012 at 10:13 AM, AJ Christensen aj@junglist.gen.nz wrote:
Right, the 'a2enmod' / 'a2dismod' script manages the symlinks. On
non-ubuntu/debian systems, this has to be managed by robot.Again the issue is not the management of the files the issue is the
creation of the files. The apache2 recipe does not create the .load
file for ubuntu/debian based systems (at least not for the passenger
module).Maybe the fault is with the passenger_apache2 recipe I don't know but
in order to install passenger on ubuntu I had to add ubuntu to the
list like this...
Yes, the fault is with the passenger_apache2 recipe.
Brutalizing the apache2 module definition (used by all of the
apache2::mod_* recipes) will mean that your system is generating .load
files where it is not necessary to do so -- the .load files are
provided by the system with the libapache2-foo-bar packages.
I'd suggest rendering the passenger .load module configuration file to
the "mods-available" directory for Apache2 then using the standard
a2enmod/a2dismod / apache2_mod definition code, without modification.
Cheers,
AJ
if platform?("redhat", "centos", "scientific", "fedora", "arch",
"suse" , "debian", "ubuntu")
file "#{node['apache']['dir']}/mods-available/#{params[:name]}.load" do
content "LoadModule #{params[:name]}_module #{params[:module_path]}\n"
mode 0644
end
end
Yes, the fault is with the passenger_apache2 recipe.
Brutalizing the apache2 module definition (used by all of the
apache2::mod_* recipes) will mean that your system is generating .load
files where it is not necessary to do so -- the .load files are
provided by the system with the libapache2-foo-bar packages.I'd suggest rendering the passenger .load module configuration file to
the "mods-available" directory for Apache2 then using the standard
a2enmod/a2dismod / apache2_mod definition code, without modification.
Thanks AJ. I guess I will see where the passenger_apache2 recipe is
failing and see if I can fix that instead.
On Tue, Jan 10, 2012 at 10:36 AM, Tim Uckun timuckun@gmail.com wrote:
Yes, the fault is with the passenger_apache2 recipe.
I have just been looking at this and I really think this is a problem
with the apache2 recipe and not the passenger recipe. Here is the
flow.
The passenger recipe creates the module and does the following.
include_recipe "passenger_apache2"
template "#{node[:apache][:dir]}/mods-available/passenger.conf" do
cookbook "passenger_apache2"
source "passenger.conf.erb"
owner "root"
group "root"
mode "644"
end
apache_module "passenger" do
module_path node[:passenger][:module_path]
end
As you can see from above it is asking the apache_module provider
(defined in the apache2 recipe) to create a module for it. The
apache_module recipe looks like this.
if params[:conf]
apache_conf params[:name]
end
if platform?("redhat", "centos", "scientific", "fedora", "arch", "suse" )
file "#{node['apache']['dir']}/mods-available/#{params[:name]}.load" do
content "LoadModule #{params[:name]}_module #{params[:module_path]}\n"
mode 0644
end
end
So it refuses to create the .load file unless the platform matches the
ones listed.
I can see no rational reason for this. How is apache supposed to load
the module without a LoadModule directive?
It seems to me that the passenger recipe is doing the right thing. In
fact from the looks of it it could just pass the config params to
apache_module too instead of creating it's own .conf file.
So at this stage I have the following options.
The Apache cookbook doesn't need to create .load files for nearly all
modules because the Debian-based distros package one with the module.
Typically, you would install -- for example -- mod_perl with a "package"
resource. This ends up being more-or-less equivalent to running "apt-get
install libapache2-mod-perl2" on the host. For every Apache module I've
ever installed (on Ubuntu), that results in the creation of .load file and,
sometimes, a .conf file in /etc/apache2/mods-available/
Now, because the .conf file contains configuration, you'll probably want to
manage its contents with Chef, but we can rely on the .load file being
there on any Debian-based distro (hence why it's only explicitly created on
the non-Debian-based ones).
Passenger is a little different, as it is built from source by a rubygem.
In my opinion, there is a bug with the current version of the
passenger_apache2 cookbook. It tries to rely on the .load file creating
ability of the apache_module definition which (as you've found) won't work
on Ubuntu or Debian. This looks to be a recent
changehttps://github.com/cookbooks/passenger_apache2/commit/679784f96898c9221d670630ebf32c6cf8a0a292in
the cookbook.
Of course, the apache2 cookbook could just always create the .load file
regardless of distribution. However, for all cases except passenger it
would be redundant and might introduce other issues.
In any case, if you believe you've found a bug in an Opscode cookbook, you
should report it http://tickets.opscode.com/browse/COOK.
Good luck
-Matt Moretti
On Mon, Jan 9, 2012 at 9:49 PM, Tim Uckun timuckun@gmail.com wrote:
On Tue, Jan 10, 2012 at 10:36 AM, Tim Uckun timuckun@gmail.com wrote:
Yes, the fault is with the passenger_apache2 recipe.
I have just been looking at this and I really think this is a problem
with the apache2 recipe and not the passenger recipe. Here is the
flow.The passenger recipe creates the module and does the following.
include_recipe "passenger_apache2"
template "#{node[:apache][:dir]}/mods-available/passenger.conf" do
cookbook "passenger_apache2"
source "passenger.conf.erb"
owner "root"
group "root"
mode "644"
endapache_module "passenger" do
module_path node[:passenger][:module_path]
endAs you can see from above it is asking the apache_module provider
(defined in the apache2 recipe) to create a module for it. The
apache_module recipe looks like this.if params[:conf]
apache_conf params[:name]
endif platform?("redhat", "centos", "scientific", "fedora", "arch", "suse" )
file "#{node['apache']['dir']}/mods-available/#{params[:name]}.load" do
content "LoadModule #{params[:name]}_module #{params[:module_path]}\n"
mode 0644
end
endSo it refuses to create the .load file unless the platform matches the
ones listed.I can see no rational reason for this. How is apache supposed to load
the module without a LoadModule directive?It seems to me that the passenger recipe is doing the right thing. In
fact from the looks of it it could just pass the config params to
apache_module too instead of creating it's own .conf file.So at this stage I have the following options.
- Change the apache recipe and add ubuntu and debian to the list.
- Change the passenger recipe to create the load file
- create the load file outside of either one of these recipes.
Of course, the apache2 cookbook could just always create the .load file
regardless of distribution. However, for all cases except passenger it
would be redundant and might introduce other issues.In any case, if you believe you've found a bug in an Opscode cookbook, you
should report it.
I have filed a bug http://tickets.opscode.com/browse/COOK-967
I have filed the bug against the passenger cookbook but I still think
the behaviour of the apache2 recipe should be changed. In my opinion
the apache_module call is an imperative and the end result should be a
.load file. Of course the call should be idempotent so it would not
trigger a reload if is already correct.
One other thing I noticed is that the following sequence of calls will
cause unexpected behavior.
apache_module "passenger" do
module_path "/usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.7/ext/apache2/mod_passenger.so"
end
...later on....
apache_module "passenger" do
enable true (or false)
end
Causes the run to crash. It crashes because the second call overwrote
the .load file to read "LoadModule passenger_module
mod_pasenger.so\n". Unless you specify the load path every time the
call is made it gets reset to the default. In this case the default
.so file does not exist and apache exits with an error.
IMHO this behaviour is unexpected and the implementation should be
done differently. One possible approach might be to use an action so
you could have action :create action :enable action :disable.
Anyway the bug has been filed. I have gotten around the problem by
rewriting the passenger_apache2 recipe to read like this.
template "#{node[:apache][:dir]}/mods-available/passenger.conf" do
cookbook "passenger_apache2"
source "passenger.conf.erb"
owner "root"
group "root"
mode "644"
end
file "#{node[:apache][:dir]}/mods-available/passenger.load" do
cookbook "passenger_apache2"
content "LoadModule passenger_module #{node[:passenger][:module_path]}\n"
owner "root"
group "root"
mode 0644
end
apache_module "passenger" do
module_path node[:passenger][:module_path]
enable true
end
All three stanzas are needed in order to enable the module.