Apache2 cookbook on CentOS?


#1

Folks,

So, looking at the systems we have deployed with the standard Chef apache2 cookbook, it has become clear to me that this was cargo-culted straight from Debian – lock, stock, and two smoking barrels (named a2ensite and a2dissite).

However, what is not obvious to me is how to take this configuration on a CentOS 5.6 box and turn it into a proper working apache configuration, especially one that does name-based virtual hosting on https only (with a wildcard cert) and completely skips port 80 altogether.

Does anyone have any favourite resources on the subject of “Debian Apache for Dummies who are not running Debian”, or something related?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#2

Sure - you set the listen_ports attribute to only 443, drop off a
virtual host using the included definition, disable all the default
sites, and enable only that vhost. The vhost has the SSL config
inside.

Best,
Adam

On Tue, Oct 11, 2011 at 7:59 AM, Brad Knowles bknowles@ihiji.com wrote:

Folks,

So, looking at the systems we have deployed with the standard Chef apache2 cookbook, it has become clear to me that this was cargo-culted straight from Debian – lock, stock, and two smoking barrels (named a2ensite and a2dissite).

However, what is not obvious to me is how to take this configuration on a CentOS 5.6 box and turn it into a proper working apache configuration, especially one that does name-based virtual hosting on https only (with a wildcard cert) and completely skips port 80 altogether.

Does anyone have any favourite resources on the subject of “Debian Apache for Dummies who are not running Debian”, or something related?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#3

Brad,
the cookbook should work as it is. As adam has already said, change the
default[:apache][:listen_ports] = [“80”],
we are using the same cookbook to run our infrastructure (centos 5.5)

On Wed, Oct 12, 2011 at 12:49 AM, Adam Jacob adam@opscode.com wrote:

Sure - you set the listen_ports attribute to only 443, drop off a
virtual host using the included definition, disable all the default
sites, and enable only that vhost. The vhost has the SSL config
inside.

Best,
Adam

On Tue, Oct 11, 2011 at 7:59 AM, Brad Knowles bknowles@ihiji.com wrote:

Folks,

So, looking at the systems we have deployed with the standard Chef
apache2 cookbook, it has become clear to me that this was cargo-culted
straight from Debian – lock, stock, and two smoking barrels (named a2ensite
and a2dissite).

However, what is not obvious to me is how to take this configuration on a
CentOS 5.6 box and turn it into a proper working apache configuration,
especially one that does name-based virtual hosting on https only (with a
wildcard cert) and completely skips port 80 altogether.

Does anyone have any favourite resources on the subject of “Debian Apache
for Dummies who are not running Debian”, or something related?

Thanks!


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com


#4

On Oct 11, 2011, at 3:04 PM, Ranjib Dey wrote:

the cookbook should work as it is. As adam has already said, change the default[:apache][:listen_ports] = [“80”],
we are using the same cookbook to run our infrastructure (centos 5.5)

It took me a while to warp my brain around the debian-style configuration, and to understand it well enough to be able to figure out whether or not I wanted to drink the kool-aid and how to do so.

Now that I’ve figured out how to manually create a working skeleton prototype of a name-based virtual host SSL-only server, I’m popping back up the stack a few levels so that I can get Chef to create that for me based on the configuration information I provide.

At the moment, the stumbling block in front of me is figuring out how to provide the SSLCertificateFile and SSLCertificateKeyFile configuration lines, as well as the corresponding self-signed wildcard cert & key that I am testing with.


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#5

model the site specific configs as a template and drop it inside
node[:apache][:dir]}/sites-available/default, and then use the apache_site
definition to enable this site specific config.

Look ate the last lines of the default recipe inside apache cookbook, the
way default site is enabled (the [template
"#{node[:apache][:dir]}/sites-available/default" ] directive and the
[apache_site “default”] directive)

On Wed, Oct 12, 2011 at 2:42 AM, Brad Knowles bknowles@ihiji.com wrote:

On Oct 11, 2011, at 3:04 PM, Ranjib Dey wrote:

the cookbook should work as it is. As adam has already said, change the
default[:apache][:listen_ports] = [“80”],
we are using the same cookbook to run our infrastructure (centos 5.5)

It took me a while to warp my brain around the debian-style configuration,
and to understand it well enough to be able to figure out whether or not I
wanted to drink the kool-aid and how to do so.

Now that I’ve figured out how to manually create a working skeleton
prototype of a name-based virtual host SSL-only server, I’m popping back up
the stack a few levels so that I can get Chef to create that for me based on
the configuration information I provide.

At the moment, the stumbling block in front of me is figuring out how to
provide the SSLCertificateFile and SSLCertificateKeyFile configuration
lines, as well as the corresponding self-signed wildcard cert & key that I
am testing with.


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#6

On Oct 11, 2011, at 4:28 PM, Ranjib Dey wrote:

model the site specific configs as a template and drop it inside node[:apache][:dir]}/sites-available/default, and then use the apache_site definition to enable this site specific config.

Look ate the last lines of the default recipe inside apache cookbook, the way default site is enabled (the [template “#{node[:apache][:dir]}/sites-available/default” ] directive and the [apache_site “default”] directive)

I’m actually thinking that I want to use the web_app definition instead and let it call apache_site with the appropriate parameters.

As I understand it, I can tell web_app what template file I want to use, as well as the server name and the docroot, and have it do the rest of the work for me. Then all I should have to do is to create the appropriate template file that gets put into cookbooks/apache2/templates/default next to web_app.conf.erb, with all the other definitions that I want like the SSL self-signed certificate file, the SSL key, etc…

At least, this is the solution that I’m going to try and see if I can get it working.


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


#7

Yep, that should work.

ADam

On Tue, Oct 11, 2011 at 2:44 PM, Brad Knowles bknowles@ihiji.com wrote:

On Oct 11, 2011, at 4:28 PM, Ranjib Dey wrote:

model the site specific configs as a template and drop it inside node[:apache][:dir]}/sites-available/default, and then use the apache_site definition to enable this site specific config.

Look ate the last lines of the default recipe inside apache cookbook, the way default site is enabled (the [template “#{node[:apache][:dir]}/sites-available/default” ] directive and the [apache_site “default”] directive)

I’m actually thinking that I want to use the web_app definition instead and let it call apache_site with the appropriate parameters.

As I understand it, I can tell web_app what template file I want to use, as well as the server name and the docroot, and have it do the rest of the work for me. Then all I should have to do is to create the appropriate template file that gets put into cookbooks/apache2/templates/default next to web_app.conf.erb, with all the other definitions that I want like the SSL self-signed certificate file, the SSL key, etc…

At least, this is the solution that I’m going to try and see if I can get it working.


Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1


Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com