On Wed, Nov 4, 2015 at 10:55 AM, Yolanda Robla Mota < [email protected]> wrote:
> Hello Infra > > I want to start a thread about the best way to reconcile the apache fixes > that we put on place for upgrade to apache >= 2.4 > The are two different ways now: > > 1. rely on apache mod_version , and add a check inside apache vhosts: > > <IfVersion >= 2.4> > Require all granted > </IfVersion> > > That is the fix currently on place for puppet-httpd, puppet-cgit, and some > other modules. It is quite simple, but has the disadvantage of depending on > mod_version apache module, so every manifest using that needs to ensure > that mod_version is installed. > > 2. Rely on satisfy any: > > Allow from all > Satisfy Any > > It doesn't need an extra check for version, but it is deprecated as shown > on: https://httpd.apache.org/docs/2.4/howto/auth.html . It also needs > module mod_access_compat to be present > in newer apache versions. We currently have this on puppet-zuul. > > 3. Another alternatives should be: > - add a parameter to puppet-httpd module, so we can pass the apache > version we are expected to have > - create a custom fact to give us the current apache version in puppet, > and do the apache check using that fact instead of relying in mod_version > - use osfamily/operatingsystem/lsbrelease facts to decide about apache > version, and apply proper directives there > > I'd like to get more opinions about how to better proceed with that, and > ensure that all infra puppet modules are following the same criteria. > > Best > > I kind of like the idea of offloading this kind of logic into the service and out of config management, especially since mod_version makes it easy to do so. If on some terrible day we decide to switch config management tools, this kind of mindset will make the switchover a tiny bit easier. So I'm a fan of option 1. I don't know enough about Apache to comment on option 2. Options in 3 are more puppetty but I don't see a big advantage to any of them. Colleen
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
