How to remove PHP7.2 modules to install modules 7.1.33
If someone can help me, I need to install php7.1 in rocky linux but since it is not compatible, I read that you can remove the modules, yum module remove php:7.2/devel but how do I install only the php 7.1 modules in php7. two?
All PHP version <= 7.3 are EOL, so you need a provider which also takes care of backporting security fixes. And I heartily recommend to fix your app to be compatible with supported versions.
In RHEL and Rocky, only versions 7.4 and 8.0 are supported for now.
My repository is the only one I know which provides old versions with security backports. But only versions 7.2 to 8.1 are available as modules, and versions 5.6 to 8.2 are available as Software Collections (designed to be installed beside the system default version).
See the Wizard for proper instructions.
Thanks for answering, but I have files and classes that force me to use 7.1, please help me, I’m desperate,
Have you read my previous answer ?
yes thanks, but I need that php 7.1 installation version because of the configuration that was made in the client application, it is very large, the .jar and everything that it entails, it is not something to change two classes.
@sory If a distribution doesn’t have the PHP version, then you cannot install it. What you want, and what is available is a totally different matter. Remi explained the situation quite clearly, and by default in RHEL 8.x and Rocky 8.x being 1:1 copy of RHEL means that it’s also not available. The module streams only have as old as 7.2.
You can go to Remis wizard page (he provided the link), and choose EL8, 7.1.33 and then multiple versions as per this screenshot, and it gives you commands on how to achieve this:
You would need to install the php71* packages.
Failing that not working for you, it looks like if you really must use Rocky 8, then you are going to have to download PHP 7.1.33 from here: PHP: Releases and compile it yourself for all the modules you need, etc.
However, as Remi also said, PHP 7.1 is EOL for quite some time now, and therefore if you are using an application that is publicly available, you most definitely should be updating it to work with PHP versions that are supported, so at least PHP 7.4.
The other alternative, is for you to find an older Linux distribution that had PHP 7.1 and use that but this will also likely have zero updates for the operating system or any other packages that run on it meaning that it is a security risk. Just like your application can be when still using PHP 7.1.
If you need PHP 7.1 ( although its already EOL ) you can go for Centos 7 and install php through software collection. For this on centos 7 you need to install centos-release-scl.noarch .
Then you cloud search and install.
yum search rh-php71
Yes, but you havn’t made any effort to explain why you need 7.1 as opposed to 7.2. Which exact function call is failing on 7.2?
Yes, that uninstalls some packages. However, you probably want to also:
yum module disable php:7.2
After that the packages that belong to the php:7.2 stream should be excluded.
The PHP 7.1 is EoL and unsupported, unmaintained. That means that whatever security vulnerabilities it had, will not be fixed. Considering that it has been unsupported for quite a while, there probably are known vulnerabilities. Not only the ones that were discovered while 7.1 was still in use somewhere, but also some discovered in later versions of PHP and already present in 7.1.
The safest bet is to assume that 7.1 has vulnerabilities that allow attacker to take over the server, get all user data from it, and compromise users that connect to the server. That risk is on one cup. Cleaning up, should someone break in, probably has a substantial cost. On the other cup is the cost of porting your application to use a supported version of PHP. While the choice is yours, it can affect other people too.
@jlehtone as I said in a previous answer:
My repository is the only one I know which provides old versions with security backports.
For example, read PHP 7.1 is dead
But of course, using a supported release is still the recommended way.
P.S. also notice that disabling the 7.2 stream won’t really help as this is the default one, so will be au-enabled by dnf if needed.