[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 33 Self-Contained Change proposal: Drop mod_php
From:       Neal Gompa <ngompa13 () gmail ! com>
Date:       2020-07-11 1:43:59
Message-ID: CAEg-Je9wPgd7=Dd_K4eOVwfi9a=dtY_ZYDBDg9hBGtFZM36_7A () mail ! gmail ! com
[Download RAW message or body]

On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr <johnmh@splentity.com> wrote:
>
> On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
> > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr <johnmh@splentity.com>
> > wrote:
> > >
> > >
> > > On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote:
> > >
> > > > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr
> > > > <johnmh@splentity.com>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote:
> > > > >
> > > > >
> > > > >
> > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr
> > > > > > <johnmh@splentity.com>
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Summary ==
> > > > > > > > mod_php (apache2handler) is an optional httpd module to execute
> > > > > > > > PHP
> > > > > > > > scripts, not used.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Owner ==
> > > > > > > > * Name: [[User:Remi| Remi Collet]]
> > > > > > > > * Email: remi at fedoraproject dot org
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Detailed Description ==
> > > > > > > > By default php-fpm is used for a few versions. mod_php is not
> > > > > > > > supported for threaded modules. mod_php usage also increases
> > > > > > > > security
> > > > > > > > risk, sharing the same process than httpd.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Drop mod_php from php build. This will only affect user of httpd
> > > > > > > > in
> > > > > > > > "prefork" mode, which will also use php-fpm.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > php-fpm is already used but most users of httpd and nginx
> > > > > > > > without
> > > > > > > > any
> > > > > > > > issue.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > The "php" package will be kept as a metapackage, installing
> > > > > > > > (weak
> > > > > > > > dependencies) most commonly used extension, thus reducing the
> > > > > > > > difference between "yum install php" (flat repository) and "yum
> > > > > > > > module
> > > > > > > > install php" (modular repository).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Benefit to Fedora ==
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Only provide the modern way to execute PHP in a web server.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Scope ==
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > PHP rebuild (mod_php build is already conditional)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > * Other developers: N/A (not a System Wide Change)
> > > > > > > > * Release engineering:  N/A
> > > > > > > > * Policies and guidelines: N/A (not a System Wide Change)
> > > > > > > > * Trademark approval: N/A (not needed for this Change)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Upgrade/compatibility impact ==
> > > > > > > > N/A (not a System Wide Change)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == How To Test ==
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > * install and play with your web applications
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == User Experience ==
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > No change.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Dependencies ==
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > None (dependency on "php" is already forbidden by Guidelines)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Contingency Plan ==
> > > > > > > > * revert
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > * Contingency deadline: N/A (not a System Wide Change)
> > > > > > > > * Blocks release? N/A (not a System Wide Change), Yes/No
> > > > > > > > * Blocks product? product
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > == Documentation ==
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Now that this has been accepted, I take it that the current
> > > > > > > maintainer
> > > > > > > of
> > > > > > > mod_php no longer wants to maintain it? I'd like to offer to take
> > > > > > > over
> > > > > > > the
> > > > > > > package if that's the case, so that Fedora will continue to work
> > > > > > > for
> > > > > > > those
> > > > > > > using mod_php.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > mod_php is built from the php source tree, so no, you can't really
> > > > > > do
> > > > > > that.
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > In that case, is it possible that it can just be kept in the build,
> > > > > so
> > > > > that we can continue to support it? There's really not a whole lot of
> > > > > reason to kill off something as useful and widely used as mod_php
> > > > > while
> > > > > it's still working well for thousands, if not hundreds of thousands,
> > > > > of
> > > > > servers, and is still the preferred backend for Apache, which even
> > > > > defaults to prefork upstream.>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > Fedora has not defaulted to prefork for Apache httpd since Fedora 27,
> > > > upstream Apache httpd has not defaulted to it for even *longer*.
> > > >
> > > >
> > > >
> > > > Apache httpd switched to event mpm by default more than a decade ago
> > > > (at least 12 years ago, from what I can tell, most likely longer!).
> > > > Fedora finally followed upstream on this in Fedora 27, and mod_php has
> > > > been broken in the default configuration since then.
> > > >
> > > >
> > > >
> > > > But even with that, we've had PHP-FPM as the default with Apache httpd
> > > > for five years now. Out of the box, that's what is set up. Nobody
> > > > noticed that mod_php was broken for the past two years, and nobody has
> > > > had any real issues with the default PHP SAPI being switched five
> > > > years ago.
> > > >
> > > >
> > > >
> > > > At this point, the only reason to keep it is if there's something that
> > > > somehow absolutely cannot run with PHP-FPM but can with mod_php. If
> > > > something like that is the case, we *could* restore it as a
> > > > subpackage. But it'd have to be a pretty compelling case...
> > >
> > >
> > >
> > > Changing the defaults isn't a problem, people who have running systems
> > > won't be effected. This will actively break peoples' systems upon
> > > update, if mod_php is dropped. It wasn't ever broken, and it's not broken
> > > now.
> > >
> > >
> >
> >
> > Sorry, no. You need to be more convincing than that.
> >
> > Unless you went out of your way to change the apache configuration
> > snippet we ship for apache httpd, then you would seamlessly switch to
> > FPM as soon as you installed it and activated the service. And if you
> > *did* go out of your way to change it, then you can go change it again
> > to work with PHP-FPM.
>
> My systems never had php-fpm, and certainly didn't get it upon upgrading.
> They've been running just fine for years. I don't see any reason to lose
> performance to php-fpm's overhead, and lose the stability of mod_php.
>

What are you talking about? In almost every case I've ever seen or
used, PHP-FPM is *more performant* than mod_php. I work for a company
that writes an absurd amount of complex PHP software. We switched from
mod_php to PHP-FPM everywhere *four years ago* for *performance* and
*stability*. Decoupling the interpreter from the web server improves
the reliability of the stack and makes it easier for code execution
and presentation to perform at optimum levels. Moreover, it becomes
possible to reuse the same FPM instance for multiple applications
across multiple web servers, which is incredibly useful.

> The only system I have running with php-fpm is one where I installed a PHP app
> which is packaged in Fedora.
>

Then just switch everything else. It's not that hard.

> Again, there's no technical debt kept by just continuing to build and ship
> mod_php. I'm not asking you to provide support for it, and I'm happy to tackle
> any bugs found with it, not that I suspect there will be any.  I'm far from
> the only user that has systems still running on mod_php. If this goes through,
> upon upgrade to Fedora 33, these users' systems will cease to function
> properly.
>

I *just* outlined the problems with shipping mod_php. You can continue
to blithely ignore them at your own peril.



-- 
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]