Description of problem: Request for mod_perl to be included in EPEL 8. Our product depends on mod_perl. We completed testing with RHEL 8.0 beta which included mod_perl. However, mod_perl was removed from the official RHEL 8.0 release. It is still not included in RHEL 8.1 beta. Thus we have been postponing RHEL8 support. mod_perl in EPEL 8 will be greatly appreciated. This post is in response to the announcement below. https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/
I could add mod_perl into EPEL, but there are two issues you should be aware about: (1) The mod_perl tests fail randomly. I believe this is some race condition corrupting internal mod_perl/perl/httpd state. I was not able to locate the cause. (2) mod_perl development is dead. There are many open bugs and mod_perl maintainer claimed he would like to stop maintaining it. All of that means that building your product on mod_perl is not wise and I won't be able to provide any support except for security fixes. In the the light of this information, do you still insist on packaging it into EPEL?
Thank you for status updates on mod_perl. Now I think I should look for some viable alternatives. Do you have any advice on using mod_fcgid as an alternative, mainly from perspectives of product quality & project status? (set aside our porting efforts...) In fact, I tried a light prototype of mod_fcgid few years ago when RHEL7.0 came out without mod_perl, kind of prepared to some extent.
If you don't need long-running server jobs or preserving a state between HTTP requests, I would go with classical CGI scripts. If you want to have a server spanning across multiple HTTP requests, mod_fcgid is probably the right way to go. Plenty of other languages like PHP or Python actually prefer FastCGI interface. mod_fcgi itself also suffers from some issues, e.g. I know about bug #1651746, that's pretty annoying when using PSGI applications. But mod_fcgid is still supported by Apache, last upstream commit <http://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk> was at the beginning of this year and Red Hat actively fixes bugs there. The code base is smaller and does not embed any interpreter in contrast to mod_perl thus it's easier for maintenance and more secure. Although mod_fcgid is far from vibrant development (partially because FastCGI interface is provided by various other HTTP servers like Nginx and thus FastCGI users are more spread), it's definily maintained and maintainable.
(In reply to yoshida.ryuichi from comment #2) > > Now I think I should look for some viable alternatives. I would recommend looking at Plack/PSGI (https://plackperl.org/) and starman as a server.
Plack as it is packaged in Fedora requires (at least for building) mod_perl. I have locally tried to drop the dependency and I was successful. I was even successful with packaging the Plack stack into RHEL-8. However, I've never sent the patches to the Fedora maintainer as he dislikes all my proposals. Is starman really usable as a standalone HTTP server? Does it support TLS and IPv6? Or does one at the end have to run it behind a reverse HTTP proxy?
(In reply to Petr Pisar from comment #5) > Plack as it is packaged in Fedora requires (at least for building) mod_perl. Yes, there's a Plack::Handler::Apache2 to run PSGI apps using mod_perl2 and it will need to be dropped for any Fedora downstream where mod_perl2 is not available but this shouldn't be that difficult to do. > However, I've never > sent the patches to the Fedora maintainer as he dislikes all my proposals. I had forgotten who the maintainer of perl-Plack is. This is a bigger problem than the dependency on mod_perl2 and means that I'll have to maintain more packages if I want to maintain bugzilla for EPEL 8. :-( > Is starman really usable as a standalone HTTP server? Does it support TLS > and IPv6? Or does one at the end have to run it behind a reverse HTTP proxy? The recommended way to run starman is to run it behind a reverse HTTP proxy and use it to handle only the perl part of your application (static files, IPv[4|6] and TLS would be handled by the reverse proxy). That said, Starman uses Net::Server and should be able to handle both TLS and IPv6.
Thanks for the suggestions. I'll continue to look into each of the suggested alternatives(including Plack/PSGI). Now for FastCGI/RHEL8.1 beta, I cannot find CGI::Fast module in RHEL8.1 rpm perl-CGI-3.63-4.el7.noarch contains CGI/Fast.pm rpm perl-CGI-4.38-2.el8.noarch does not. Should I request perl-CGI-Fast rpm for EPEL 8?
CGI::Fast is for running CGI scripts through FastCGI protocol. There is no need for that. Instead you should execute the CGI scripts as a normal CGI script directly by the httpd. You only need to configure httpd to load mod_cgid or mod_cgi module (depending on active MPM implementation) and hook .cgi file names to that module (using "SetHandler cgi-script"). This is nothing new to RHEL-8. It was like that even in RHEL-7. For the long-running state-preserving jobs, you can use FCGI Perl module in the job scripts (already packaged in RHEL-8). In my opinion CGI::Fast does not provide many benefits comparing to FCGI module. In both cases you need to change the scripts to contain the FastCGI loop. There is mod_fcgid for for spawning the scripts from httpd. mod_fcgid has the nice feature that it nicely reuses httpd MPM configuration (spawning multiple instances, load balancing, limiting resources, restarting and watching scripts). If you want to get rid of the FastCGI loop boilerplate code in your scripts I recommend rewriting them to the PSGI interface and using Plack as a midleware between FastCGI protocol and your script. We can package perl-CGI-Fast in EPEL 8 if you find a use for that. I only recommend you testing it first whether it fits your needs and works for you. My haze recollections are I had some issues with it. But I cannot remember what they were.
The reason we used mod_perl was, simply because we did not want our 10K+ lines of perl codes (stateless API) compiled at each request. Now my prototype (full coverage) is running on FCGI and CGI::Fast. I don't see major difference between these two. I think I can proceed with FCGI.
I'll confess interest in mod_perl in order to support OCS Inventory Server.
https://pagure.io/releng/fedora-scm-requests/issue/16312
perl-Apache-Reload <https://pagure.io/releng/fedora-scm-requests/issue/16314> is also needed.
perl-Apache-Reload is not strictly needed but handy.
> (1) The mod_perl tests fail randomly. Just a thought. (although you may be already aware and have tested this...) httpd versions and default MPM settings are: RHEL6 - httpd 2.2 - prefork MPM RHEL7 - httpd 2.4 - prefork MPM RHEL8 - httpd 2.4 - event MPM Even with high traffic pressure tests, I never experienced random failures (invalid results) with mod_perl on (at least) prefork MPMs on RHEL 6 & 7. If your tests are failing under event MPM on RHEL8, any possibility of improved stability by changing the MPM from event to prefork ?
FEDORA-EPEL-2019-8a40115999 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8a40115999
mod_perl-2.0.10-17.el8, perl-Apache-Reload-0.13-12.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8a40115999
mod_perl-2.0.10-17.el8, perl-Apache-Reload-0.13-12.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report.