Brand new to Rocky Linux, coming here to get RockyLinux 8.5 up and running as a replacement of CentOS 7.5 in our web hosting production environment.
Been running on CentOS 7 for the last several years and went with the software collections to get up to apache 2.4.34 and php 7.3.29.
Just now installed the httpd and php packges to see what versions I get.
I am happy to see that I get Apache 2.4.37.
But I am wondering why I get php 7.2.24?
I was expecting php 7.4.19 as mentioned in the 8.5 Release Notes.
Do I have to edit something about the repositories?
I built from the minimal iso and added the epel-release repository.
I have spent the better part of two days reading up on repositories, looking at what is in the base install I have and trying to determine where I can count on getting decently current versions of PHP and Apache. How is this going to work in Rocky Linux? I’m hoping to see PHP 8 in a repository soon.
Mariadb and BIND are other two packages I use. I recently hooked into the Mariadb project’s repositories to solve the problem with keeping up with their current stable release. I’m not too dependent on bind, but would use the ISC repositories if they stated they were production quality.
php, like various other applications, is provided as a module, and various streams are available
# dnf module list PHP
Name Stream Profiles Summary
php 7.2 [d] common [d], devel, minimal PHP scripting language
php 7.3 common [d], devel, minimal PHP scripting language
php 7.4 common [d], devel, minimal PHP scripting language
The 7.4 version will be maintained for the whole distribution life cycle.
New versions (PHP 8.0, 8.1…) will probably appear in the future (Rocky 8.6, 8.7…)
The 3rd party Remi’s repository provides additional streams (7.2 to 8.1) and additional extensions:
Name Stream Profiles Summary
php remi-7.2 common [d], devel, minimal PHP scripting language
php remi-7.3 common [d], devel, minimal PHP scripting language
php remi-7.4 [e] common [d], devel, minimal PHP scripting language
php remi-8.0 common [d], devel, minimal PHP scripting language
php remi-8.1 common [d], devel, minimal PHP scripting language
This does not install php 7.4 though. Now the php:74 stream is enabled, but this does not update or install packages from that stream. You could dnf distrosync or at least dnf update after that. But, if a profile was installed with the php:7.2 stream, now it is not (if this is considered important). Another option when another stream is already enabled is
true, no 3rd party repo needed for 7.3 and 7.4, but without doing module-foo only the packages from the default stream, i.e. php:7.2 is visible to dnf, and that was the point Remi has made: you can’t simply dnf install php-7.4.19
Ideally I want to be on PHP 7.4.
Down the road, say in a year, I will want to switch the server to PHP 7.5 or 8.x.
Coming from CentOS 7, I was used to running yum update monthly and seeing PHP updates for 7.3 come in. If I wanted to move from 7.2 to 7.3, I had to shift the system in a fashion similar to what Remi is describing now by switching between modules. I’m okay with one vm providing one version of PHP and moving up between minor versions of PHP 7. To date, doing this hasn’t bothered the installed Apache or Wordpress. I should note that Wordpress is maintained monthly on the current release.
The driving forces are mitigations for (client) PEN test findings. As this is “production” and “web hosting”, I want to maintain PHP, apache and wordpress within their currently supported and stable releases. I’m used to relying on the repository and the update process to provide this and keep me current.
Is what is in the main appstream and switching switching between 7.4 module and whatever the future (7.5?) still going to work for me as well as what I got used to in CentOS 7?
Have been introduced with different point updates; not all already with the release of RHEL 8.0
Red Hat has committed to provide (security) patches for PHP 7.4 for the rest of RHEL 8’s lifetime
There is a (sligth) possibility that later PHP versions will appear with future point updates, but they are unlikely to have support all the way to May 2029. There are still five planned RHEL point updates (8.6–8.10)
With RHEL 6 and 7 there was/is Software Collections. Packages have unique names, so can be installed simultaneously. The scl enable adjusts PATH, etc to select one of the installed SCL versions.
If one chose third-party repo that had same package names as the base, then there were a risk that packaging differed or dependencies among other base packages broke.
With streams one can install only one version at a time, it is automatically on the path, packaging is similar and naming identical in related streams. Switching streams basically means uninstall of one set of packages and install of different version same set. It is totally fine to have different stream in different VMs.
Red Hat supports all its streams (as long as they promise), so regular updates are a fact (if necessary).
I just had Rocky Linux installed.
So, from your note, Apache is 2.4.37 for Rocky Linux 8.5, correct?
Why I asked is that my IT department kept asking me to update Apache to the latest version (i.e. 2.4.52), and I tried for a few days and couldn’t get this done.
Just wanna confirm with the community that latest version of Apache for Rocky Linux 8.5 is really 2.4.37. Yes?
Speaking as a community user with a production network the httpd currently reports its version as 2.4.37.
Eventually it will be a larger number.
I explain to those who want me to be on the latest available, that we are running the latest version that is available and regularly maintain the server with monthly updates. I am leveraging the value of the community and distribution vetting to get the best version.
Stepping out of that and downloading the latest version from the project site means that I have struck out on my own to get that version going with the rest of the details and dependencies in place. I am quite capable of doing this on my own, but I don’t want to because I now own all the future issues that are come about my independent detour. This means support and time cost that isn’t wanted.
Also, be aware that the version number given doesn’t necessarily mean that everything in later releases hasn’t been brought over. Important fixes and security things often are assessed and brought in. The version number changing really means to me that all fixes up to and including that version are here and have been vetted by the community processes as the new base.
Rocky’s httpd-2.4.37-43.module+el8.5.0+727+743c5577.1.x86_64 was built in January 2022.
It is quite different from the upstream “2.4.37” that did live in 2019?
