Hello,
I need mod_php and got it working on RL8. I understand mod_php was removed since RL9. However, the following document seems to suggest mod_php still works on RL10. Is the document wrong, or am I misreading it? I tried to follow the document, but apache just serves up the source code in php files and there’s nothing to render them. Anyone has better clues? I am not looking for php-fpm. If it was viable, I would have used it. Thanks.
EL-8 use php-fpm by default, but indeed mod_php is still there and can be used switching apache to “prefork” mode.
mod_php is terrible for httpd perf (prefork vs event mode) and for security
EL-9 and EL-10 only have php-fpm
With the default configuration, httpd + php-fpm (or nginx + php-fpm) works out of the box.
Why do you think you need mod_php ?
1 Like
Other people’s code won’t run with fpm. I don’t want the effort of fixing them. I am happy with the performance and security of mod_php, or I wouldn’t be using it.
Other people’s code won’t run with fpm. I don’t want the effort of fixing them.
I don’t know any code which doesn’t run on php_fpm
I am happy with the performance and security of mod_php, or I wouldn’t be using it.
So you have to stay on EL-8 and php 7.4 or 8.2
Or switch to another PHP stack provider
My repository still provide mod_php, but I still recommend php-fpm.
P.S. only php-fpm issue is with badly written app using URI to pass very long data (GET method instead of PUT)
1 Like
If I have to stay on EL8, then I might as well stay on EL7 where the php code currently sits. The original reason for moving out was because the database used unencrypted connections. I have just found information that allow me to use later versions of the database. If this works, I have less reason to move out. Although if later versions of linux would work, it would be a useful option because server rentals tend to exclude EOL distros. Debien does mod_php, although I haven’t tested it yet.
The question remains why rocky’s doc imply mod_php is possible on EL10? I could see the apache prefork-blah-blah is still on EL10. The only thing missing is mod_php.
If php-fpm has no compatibility then I would put the fault on that :). Does your repository work with EL10?
The back up plan of staying with EL7 worked. PHP 5.4.16 will keep going for many years to come!
Good luck with that then including all the security risks involved with using outdated system, outdated PHP and the lack of patches to fix any of it. Let’s just hope your server is not publicly accessible on the internet.
This is just laughable. Blaming php-fpm for not supporting crappy code written by a crappy programmer is a joke. The problem is clearly the crappy programmer who has no clue how to write code in the first place. But if you want to blame someone else, other than the crappy programmer who wrote the code that you are using then all I can do is laugh at such a statement of attempted blame 
1 Like
My servers have been on the internet for 10 years. Script kiddies have yet to break in. Currently my servers are eating a DDoS for breakfast. The only programmers I consider crappy are those who can’t do compatibility. I consider the php app I am using to be excellent, never crashed or corrupted once. Hence I do everything I can to keep using it.
Well then that proves the argument, if your programmer(s) can’t do compatibility to make it work when using php module or php-fpm, then it is them that needs to fix it and not the other way around like you suggested. Which is the whole point of my argument 
had they done it properly in the first place, then it would have worked with both. They basically coded it to only work with php module which is their mistake.
Considering the fact EL7 has not long gone EOL then it’s hardly surprising because it was receiving updates. Now not, so the risk is there that they eventually will compromise your server. So good luck with that if you don’t want to fix your app and get it working on EL8 or higher.
1 Like
They are not my programmers, and I am a programmer myself. I know good quality work when I see it. This is why I am sticking with it and disregarding poorly made non-compatible linux. Although I haven’t tried it, I am fairly certain Debian will work. There is no longer urgency for me to move off EL7 now that everything is working how I want. I have blocked off some backdoors associated with ukrainian IP’s, and IP’s of some “security entities”. They are out of options. It may or may not be the same people DDoS’ing me. But that’s going nowhere.
Some attacks that look like DDoS, are actually coming from one machine using many spoofed IP addresses. Those attacks won’t even get as far the web server and won’t show in the web server request logs. In this case, trying to reply to a packet will end up going to the spoofed address instead of the source.
A second class of DDoS attack is where they are using real IP addresses, but deliberately pause the request half way through. This should show up in the http status page, but might not show up in the web server logs (subject to timeout).
A third class of DDoS attack is where they are using real IP addresses and are sending real requests at high speed, this will instantly show up in the web server logs.
In the first two cases, the type of php interface (SAPI) doesn’t really matter as it’s not used, but in the third case it suddenly becomes important, and considerations like multi-process vs multi-threading become important.
LOL, just LOL. Sorry but poorly made application from your side. Your arguments are lame. You are using the PHP framework so you have to use the rules that apply to it. The PHP framework doesn’t have to conform to you - you have to conform and use the framework properly. Your application has failed to do that.
But blame the OS, everyone who reads this will know that the problem is your application and to say otherwise makes you look silly.
1 Like
@ gerry666uk
All my php traffic are filtered. Nobody is starting a process or execution thread without permission. In other words, DDoS is irrelevant.
@ iwalker
Not my app. Someone wrote a great app and I am using it. Then rocky couldn’t handle it, so I will take my business to Debian if it comes down to that. Right now, I am happy where I am.
It may be great in what it does, but that does not ensure that how it does that is best possible.
Remi seems to imply that any PHP app should be able to use php_fpm and that only badly written code fails to do so:
It is “correct” to choose a platform that supports the applications that you need to run. If app runs only in Windows 95, then one does use Windows 95.
However, that does not mean that such app-OS combo is optimal or recommendable. There are usually alternatives. Furthermore, applications are built for target platform – distros are not built for application (except in very special cases).
It should not take a huge effort to port a well written code to use new framework?
1 Like
Even staying within the same framework requires changes. The app was written for PHP 5.4 which has been EOL since 2015. Also, the changes in PHP for 7.x were huge and thus requires the app to be rewritten for it to work. The amount of changes will depend on how it was written in the first place. However, they seem to think, that their app is great, and that PHP fpm is the problem or the OS is the problem because it doesn’t conform to their old application written for an old PHP version. They seem to think that they do not need to make changes for their app to work. They should realise that all frameworks change as they are developed, updated, and therefore they should ensure that their app works with it. Everyone knows this and everyone accepts it, at least except this person who thinks it should be the other way around.
No distro now has PHP 5.4 so unless they are going to compile it manually yourself, then they will probably also blame Debian for not working, or some other distro as being the source of the problem, rather than their old application being the problem.
Also, using something that has been EOL for 10+ years is pretty shocking really, but there we go. Again, they have a different viewpoint on that from everyone else’s.
So in reality, nobody here can help them, or nobody anywhere can help them until they realise any of this.
1 Like
And we still don’t know what is the compatibility problem…
The only info we have from the 1st post is “apache just serves up the source code”
So not a compatibility issue, but rather a configuration one.
Default configuration works out of the box.
The only explanation I can see in the code is the usage of old, deprecated short tag (<? instead of <?php), which is a single configuration line (short_open_tag = on), but again this is deprecated for so much years….
Only missing in php-fpm was the lack of the getallheaders function, which I added in 7.3 about 7 years ago…
3 Likes
@ jlehtone
Does great in rocky 8. Doesn’t do it in RL9, RL10. Haven’t tried it, but pretty sure does great in all versions of Debian. You can deduce from that it isn’t the app that is the problem.
@ remi
Don’t need to know what is the compatibility problem. We only need to know there is no mod_php in RL 10. So, the php files are served up as plain untagged and unstructured html text.
@iwalker
The code must have been extremely well written, because it worked perfectly fine with the PHP version in RL8. The only thing needed changing was calls to count(). The behavior of that function changed.