Between Apache 2.2 and 2.4 access directives changed: http://httpd.apache.org/docs/current/upgrading.html
Apache has provided mod_access_compat for backwards compatibility and it's currently used via the default $legacy_compat options of the httpd class.
Apache 2.4 is universally used since quite a while, we should
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T258686 Stop using mod_access_compat | |||
| Resolved | Jelto | T338071 Stop using mod_access_compat in sre-collab services |
@Muehlenhoff Grepping through the puppet repo I dont see any "mod_access_compat" nowadays.
The httpd class still has the legacy_compat option but nobody uses it anymore:
modules/httpd/spec/classes/httpd_spec.rb: context 'with_no_legacy_compat' do
modules/httpd/spec/classes/httpd_spec.rb: let(:params) { {'legacy_compat' => 'absent' }}
modules/httpd/manifests/init.pp:# @param legacy_compat Use Apache 2.2 compatible syntax.
modules/httpd/manifests/init.pp: Wmflib::Ensure $legacy_compat = present,
modules/httpd/manifests/init.pp: ensure => $legacy_compat,So either it's resolved now or it's resolved after we remove even the option to use 2.2 compat. What do you think?
Change 923615 had a related patch set uploaded (by Jbond; author: jbond):
[operations/puppet@production] httpd: set legacy_compat to absent
Change 923616 had a related patch set uploaded (by Jbond; author: jbond):
[operations/puppet@production] httpd: remove legacy_compat option
The httpd class still has the legacy_compat option but nobody uses it anymore:
This is not exactly true. The default value is $legacy_compat = present as such its currently deployed everywhere. i have created a change set to first set the value to absent and then remove the option
Can I ask what's the motivation for wanting to remove the old-style access rules besides keeping up with apache, while apache themselves have basically acknowledged it's not always easy to translate old style rules in new-style ones, so access_compat is going to stay around for the forseeable future.
Case in point, MediaWiki uses old-style rules because it wasn't really straightforward to translate rules from one model to the other precisely 1:1 and at the time we decided it wasn't worth the risk.
We currently use old-style access control in many places in our apache configurations.
Unless someone wants to take on the project of changing every one of our configurations, I would decline this task or at least stall the work for now.
Specifically: changing apache configurations is always thorny. Changing access rules which don't always match 1:1 in subtle ways is something I'm personally always not inclined to do unless there is a very good reason to do so.
Change 923615 abandoned by Jbond:
[operations/puppet@production] httpd: set legacy_compat to absent
Reason:
more work needed before this can be merged see comments and task
Change 923616 abandoned by Jbond:
[operations/puppet@production] httpd: remove legacy_compat option
Reason:
more work needed before this can be merged see comments and task
The old-style syntax is used all over the place and it would be a significant effort to change. Since it wil be continue to supported by Apache in the foreeseable future, marking as declined for now
I am breaking out the ones that sre-collab can fix into a subtask. After that there are a handful for observability (thanos, prometheus, graphite, icinga), webperf, ircd and the single apache2.conf.erb for Mediawiki and that would be it. It doesn't seem _that_ much to me, actually.
Change 932441 had a related patch set uploaded (by Dzahn; author: Dzahn):
[operations/puppet@production] webperf: replace Apache 2.2 with modern syntax for access control
I don't really see what we are solving by denying things when we know we still want and have to fix them in the future. With "it would be a lot of work" as the only reason the appropriate way would be to set priority to low, move it to some "backlog" column or simply ignore it. Declining says "nobody should work on this" but if we don't have time for things that means we want even more that others could work on it.
Separately I would argue it's not as many or hard patches as it sounds.
Change 932443 had a related patch set uploaded (by Dzahn; author: Dzahn):
[operations/puppet@production] prometheus: replace Apache 2.2 access control syntax
Change 932444 had a related patch set uploaded (by Dzahn; author: Dzahn):
[operations/puppet@production] thanos: replace Apache 2.2 with modern syntax for access control
Change 932445 had a related patch set uploaded (by Dzahn; author: Dzahn):
[operations/puppet@production] graphite: replace Apache 2.2 access control syntax
Change 932445 merged by Dzahn:
[operations/puppet@production] graphite: replace Apache 2.2 access control syntax
Change 932441 merged by Dzahn:
[operations/puppet@production] webperf: replace Apache 2.2 with modern syntax for access control
Change 932444 merged by Dzahn:
[operations/puppet@production] thanos: replace Apache 2.2 with modern syntax for access control
Change 932443 merged by Dzahn:
[operations/puppet@production] prometheus: replace Apache 2.2 access control syntax
Mentioned in SAL (#wikimedia-operations) [2023-06-27T21:50:21Z] <mutante> prometheus4002 - sudo a2dismod access_compat ; sudo systemctl restart apach2 ; sudo apachectl configtest -> Syntax OK :) - to proof it works without the access_compat module T258686
So.. meanwhile the number of services still using 2.2 syntax has been reduced.
And the one that actually affects appservers/mediawiki.. I had a patch for that too. It's here:
https://gerrit.wikimedia.org/r/c/operations/puppet/+/932447
But I also thought it would be hard to get that reviewed and deployed and this ticket was already declined and not sure if still relevant on k8s. So I abandoned that.
But please feel free to restore/review/merge that if there is any interest. The point is.. not as many changes needed as it seemed in the past now.. to get to state where nothing uses 2.2 syntax. Cheers