Date: Fri, 29 Apr 2022 12:15:16 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 263655] www/apache24: Remove automatic mpm fallback configuration Message-ID: <bug-263655-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263655 Bug ID: 263655 Summary: www/apache24: Remove automatic mpm fallback configuration Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: apache@FreeBSD.org Reporter: ports@skyforge.at Assignee: apache@FreeBSD.org Flags: maintainer-feedback?(apache@FreeBSD.org) Created attachment 233582 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D233582&action= =3Dedit 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 fo= r 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 m= ost modularized configuration schemes, which are increadibly useful and common), the script generates a fallback configuration that may cause apache to eith= er load the wrong mpm module on restart, or cause it to fail starting alltoget= her. * 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 boundar= ies: We nowadays ship with a sample configuration that includes a well-intended default LoadModule statement for mpm_prefork. Whichever way the user decide= s to modify and diverge from that default configuration should be up to them. Creating non-sample configurations in places that would be sourced by defau= lt feels like it's taking things a step too far. Judging from the commit history, I think there was once a point for this ki= nd of behaviour to help with the migration from a static to a dynamic MPM back= end. 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 e= ven 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 h= ad 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 fi= les 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263655-7788>