Re: Fedora 33 Self-Contained Change proposal: Drop mod_php

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote:
> On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxx>
> > > > > 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@xxxxxxxxxxxxx>
> > > > > > > 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.

Because of FastCGI, php-fpm adds ~1ms to every request, and I'm not the only 
one that's measured similar results. Most systems running a web server only 
run one webserver, generally either just apache or just nginx, so I don't see 
the benefit to that either.

> > 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.

Why should I have to switch the system that's being used, and potentially 
break these servers, just because a package isn't being compiled anymore? It 
still works, and it works very well. It has less overhead than php-fpm, even!

> > 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.

I'm sorry, but I don't see that in the email I'm responding to, the email you 
send just before that, or the root of this thread. What are the actual 
problems with shipping mod_php? I'm not talking about "benefits" of using php-
fpm, but the problems with shipping mod_php? I'd be happy to help solve them, 
so that users such as myself and the others using mod_php can continue to do 
so.

-- 
John M. Harris, Jr.

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux