<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 10:55 AM, Yolanda Robla Mota <span dir="ltr"><<a href="mailto:yolanda.robla-mota@hpe.com" target="_blank">yolanda.robla-mota@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Infra<br>
<br>
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<br>
The are two different ways now:<br>
<br>
1. rely on apache mod_version , and add a check inside apache vhosts:<br>
<br>
    <IfVersion >= 2.4><br>
      Require all granted<br>
    </IfVersion><br>
<br>
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<br>
mod_version apache module, so every manifest using that needs to ensure that mod_version is installed.<br>
<br>
2. Rely on satisfy any:<br>
<br>
    Allow from all<br>
    Satisfy Any<br>
<br>
It doesn't need an extra  check for version, but it is deprecated as shown on: <a href="https://httpd.apache.org/docs/2.4/howto/auth.html" rel="noreferrer" target="_blank">https://httpd.apache.org/docs/2.4/howto/auth.html</a> . It also needs module mod_access_compat to be present<br>
in newer apache versions. We currently have this on puppet-zuul.<br>
<br>
3. Another alternatives should be:<br>
- add a parameter to puppet-httpd module, so we can pass the apache version we are expected to have<br>
- 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<br>
- use osfamily/operatingsystem/lsbrelease facts to decide about apache version, and apply proper directives there<br>
<br>
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.<br>
<br>
Best<span class="HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div>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.</div><div><br></div><div>Colleen</div></div><br></div></div>