Module does not correctly handle multiple RHEL based OS versions.

[tmclaugh]

As the module is written now it cannot handle both RHEL 5 and RHEL 5 based OSes. (This includes the latest Amazon image which appears to be RHEL 6 based.) The issues are:

• On a RHEL 6 based host Apache cannot start because apache::mod::default references modules that are not present in the Apache package that ships with this OS version.
• On RHEL based hosts files created by Apache module packages are installed into /etc/httpd/conf.d but are then deleted by this puppet module.
• The httpd.conf file for RHEL is not usable in a large environment with multiple Apache setups where some hosts may require individualized setup and tweaking.

I think the root of this issue is the module is attempting to manage the contents of httpd.conf unlike it does on Debian. (I understand the reason for this is in the differences between how Debian and RHEL manage Apache setup.) For RHEL what I would propose is the following:

• Have the module stop managing the contents of httpd.conf. If a consumer needs to manage it's settings they should do it from their infrastructure module.
• Change $vdir for RHEL to point to ${httpd_dir}/vhosts.d
  • A file can then be dropped into ${httpd_dir}/conf.d to include the config files in ${httpd_dir}/vhosts.d
• Introduce $confd for both RHEL and Debian and set to ${httpd_dir}/conf.d.
  • Modules that were dropping config files into $vdir should be updated to use $confd
• Stop using ${httpd_dir}/mod.d on RHEL.
  • RHEL does not have the concept of modules-{available, enabled}. A module is enabled when it is installed on RHEL
• Stop managing the default modules on RHEL hosts.
  • If httpd.conf is not having its contents managed by the module then it's no longer necessary to do this on RHEL.

Thoughts on these ideas?

[tmclaugh]

As an ademdum to "Stop using ${httpd_dir}/mod.d on RHEL", the a2mod type should become a NOOP for RHEL and Amazon hosts. The a2mod type mimics the Debian a2enmod and a2dismod functionality. But as pointed out there is no analogous behavior on RHEL hosts as when a module is installed via package on RHEL it is enabled.

[hunner]

Thanks for your input @tmclaugh.

Have the module stop managing the contents of httpd.conf. If a consumer needs to manage it's settings they should do it from their infrastructure module.

I merged #200 to cover this functionality. A module managing the configuration should provide an interface to do so, or not manage it at all. Previously the module managed very little and thus wasn't very helpful. I hope this is a step in the right direction.

Change $vdir for RHEL to point to ${httpd_dir}/vhosts.d

I specifically have this pointing at ${httpd_dir}/conf.d (https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/params.pp#L37) to preserve the RedHat way of doing things, but allow vhosts.d to be used instead via https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/init.pp#L32

A file can then be dropped into ${httpd_dir}/conf.d to include the config files in ${httpd_dir}/vhosts.d

Done, kind of. The templated httpd.conf will include vhost configs via https://github.com/puppetlabs/puppetlabs-apache/blob/master/templates/httpd.conf.erb#L49

Introduce $confd for both RHEL and Debian and set to ${httpd_dir}/conf.d.

Done.

Modules that were dropping config files into $vdir should be updated to use $confd

This is the case on redhat, though Debian's available/enabled symlink setup is preserved for debian platforms

Stop using ${httpd_dir}/mod.d on RHEL.

Done, similar to the vhost.d method above.

RHEL does not have the concept of modules-{available, enabled}. A module is enabled when it is installed on RHEL
Stop managing the default modules on RHEL hosts.
If httpd.conf is not having its contents managed by the module then it's no longer necessary to do this on RHEL.

This bit is actually pretty hard to do. Configuration files on many platforms could cause apache to fail to start if not managed, or create enormous overhead for the apache module maintainers (if there were any :P). I hoped to simplify this by taking the gamut of apache mods available on all covered platforms and templatizing them. I hope that taking this route was acceptable.