Open Stack

On Wed, Nov 4, 2015 at 10:55 AM, Yolanda Robla Mota <
yolanda.robla-mota at hpe.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20151105/d9ad6497/attachment-0001.html>