Bug 263655 - www/apache24: Remove automatic mpm fallback configuration
Summary: www/apache24: Remove automatic mpm fallback configuration
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-apache (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-29 12:15 UTC by Sascha Biberhofer
Modified: 2022-04-29 12:15 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (apache)


Attachments
www/apache24: Remove automatic mpm fallback configuration (3.97 KB, patch)
2022-04-29 12:15 UTC, Sascha Biberhofer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Biberhofer 2022-04-29 12:15:16 UTC
Created attachment 233582 [details]
www/apache24: Remove automatic mpm fallback configuration

I'd like to propose a patch to remove the automatic fallback generation with mpm_prefork for www/apache24. Currently the apache24 package greps for a present MPM configuration in http.conf and creates a fallback configuration in modules.d, which is included by default. I feel that this is problematic for a variety of reasons:


* It doesn't account for modular configurations: If the loading of an MPM module takes place in an included configuration (as would be the case for most modularized configuration schemes, which are increadibly useful and common), the script generates a fallback configuration that may cause apache to either load the wrong mpm module on restart, or cause it to fail starting alltogether.

* It doesn't preserve changes to the file: Even if I keep the 000_mpm_prefork_fallback.conf configuration but uncomment the LoadModule statement, the configuration is simply overwritten on the next update/reinstallation of the package.

* From a philosophical perspective, it feels like it's overstepping boundaries: We nowadays ship with a sample configuration that includes a well-intended default LoadModule statement for mpm_prefork. Whichever way the user decides to modify and diverge from that default configuration should be up to them. Creating non-sample configurations in places that would be sourced by default feels like it's taking things a step too far.

Judging from the commit history, I think there was once a point for this kind of behaviour to help with the migration from a static to a dynamic MPM backend. But this was in 2015, so I think it's time to reevaluate this and, perhaps, move on.

As a minor note: I think the configuration as it stands right now doesn't even work properly anymore. At least my apache complains with the following:

Syntax error on line 21 of /usr/local/etc/apache24/modules.d/000_mpm_prefork_fallback.conf: Cannot load libexec/apache24/mod_mpm_prefork.so into server: Cannot open "/usr/local/etc/apache24/libexec/apache24/mod_mpm_prefork.so"

I've attached a patch that (I think?) removes this functionality in its entirety, as it really shouldn't be necessary anymore. All configurations had ample time migrating and new installations come with a sane default anyway. We could still preserve a warning on install, but I'm really not sure that's necessary anymore.

In any case it would make my own personal use case a bit nicer to deal with, as I have split the individual modules and their configurations in seperate files in modules.d and currently need to pay attention to this everytime I update apache24, but I'd love to hear feedback and different opinions on this. :)


Cheers,
Sascha