I had no issue at all dumping Centos 7 and going to Ubuntu 20. Archived all the domains, installed OS, Webmin/Virtualmin… set all the basic stuff up, dumped all the sites back in and was back up in no time. Only difference was some basic relearning of a few variances from a redhat base to a deb base but pretty basic stuff. Yes I could easily just ‘upgrade’ to some variance of a RedHat OS but decided to just make the break and head to Debian which is bigger and has even wider support. Totally worth it.
I’ve never had any problems with remi-safe. They seem as stable as the OS repos, if not more so.
I can’t vouch for the rest.
Richard
YUP also a lot of backported security in older versions from REMI.
OFF ON topic for the part yes no using official REPO’s then also check if they backport CVE’s as this one
This is very important, while official REPO don’t do this ( sometime if … yup but way less), even worse if not high CVE then no update for almost ending security support on PHP 7.3.x where there are though the Security updates for PHP 7.4x and php8x PHP: News Archive - 2021
“Also I decided to target only 7.4+ as 7.3 will be soon out of security support”
This UHUM:
Once again, I believe you’re underestimating the impact of this bug. Most distros make the PHP-FPM service as root straight up when you install it through package managers. This means that in most cases, remote code execution vulnerabilities on PHP-FPM (NGINX, IIS) will now yield a root shell instead of the standard www-data. I’ve been a pentester for a long time, and I can tell you this greatly improves the attack surface for an attacker.
I know I’m insisting a lot – this is the last time I interject, but this bug is scary, and damage will be done if people cannot patch their PHP-FPM easily.
Therefore, I really think this needs a proper fix for all supported PHP versions.
Partly if you read the changelog and comments under it:
[2021-05-18 09:14 UTC] c dot fol at ambionics dot io
Hello, A small update. The bug has been present since the first fpm_scoreboard implementation (PHP 5.3.7). I now have a reliable exploit for PHP 8+, which I can provide if needed.
I love the discussion that has been generated about this post, frankly these are the posts I like to read because I learn from different points of view.
This weekend I have installed a new server, these are the versions of the packages I have installed, I followed the howto of RJM_Web_Design and I find it curious not to have installed the latest versions of the packages, we talk about in some packages 3-6 months of delay, is it normal?
Which Packages do you mean exact, while some are backported by for example ( centos / alma) in older version nr as apache , only thing is lack of some supported newer things then.
Also, I think it is important if shared hosting or other PHP-FPM setups that could be affected by CVE i did write above to follow the discussions and yes or no your version is updated / backported for that …
if no need for php 7.3x then don’t install this on new boxes.
@jotst
For example, spamassassin the last version its 3.4.6 ( 2021-04-12) , 3.4.4 version installed its from 2020-01-28
A hmm spamassassin is a not so funny thing, could be depending on other versions related, some updates / upgrades are for example only higher versions of php i don’t know this here
Also Don’t know if they backported the cve 3.4.5 update…?
http://svn.apache.org/repos/asf/spamassassin/branches/3.4/build/announcements/3.4.5.txt
Another delay for example…
Mariadb last version its 10.6.4 August 2021, and i have installed 10.3.28 from February 2021
I don’t understand this 
No that is not a update but upgrade mainversion ( don’t know the word in english)
The Repo OS package Alma CentOS have for now max version 10.3.x there.
READ and do forumsearch @Joe why it is not so good idea to upgrade / change that kind of OS packages, and yes you can, but is really not so easy as on the HOWTO pages at MARIADB for example.
I don’t know what i did, but on live productions BOXES nonononono i strongly advice against doing that kind of upgrades whitout being 100% sure that you can and go back and have enough time to test all you apps and websites thouroly…
Chances you break websites / apps are very high while default configuration settings defer a lot , and you have to prepare.
Better start if you realy need with only fresh installed box then, virtualmin, after that you have to find out what to remove before the Mariadb repo package itself is possible to install, that cost time… and even then are you sure you can handle more thing not from virtualmin panel but on command line.
And and and and and…
So MariaDB yes it can is working here, but started with fresh box, and not so important to test box, where websites then could be transfered if going wrong to other boxes. ( i want to knwo /test if cms is working with that version and is fast or slow… )
1 Like
This is a new install, only for test, the last 10.3 mariadb version its 10.3.31 6 August 2021
I am only search understand because i have installed this old versions, i am not a linux expert and my native language its Spanish 
No. It is not an old version. It is the current version provided by your OS. Don’t go trying to “fix” what is a feature of your OS. RHEL (and thus CentOS and all other RHEL rebuilds) commit to a version at the time the OS is released, and they support that version for the life of the OS, backporting security and some bug fixes, as needed to keep it secure.
This is a feature, not a bug. You can know with an extremely high level of confidence that what anything you build on that OS today will continue to work throughout the life of the OS. If there were changes to the versions of the underlying software, you could no longer have that confidence. Every update could break your apps or your configuration, possibly in subtle ways.
Please don’t start breaking your system by immediately going and upgrading a bunch of stuff with random stuff you found on the internet. You’re not improving your system by doing so, you’re just making you life harder and your system less reliable (and possibly less secure, though in the case of getting packages directly from the upstream provider that’s probably less of an issue).
My recommendation is always, and I mean this emphatically: Do not use third party repos unless you really must have some specific version of something, and you have done the research necessary to understand how the packages from that repo interact with the OS you’re using (i.e. do they replace system packages? do they install in a different path like /opt? do they conflict?). And, be sure you understand that no third party repo will ever have the lifecycle guarantees of the OS itself. If you pick a RHEL rebuild as your OS (CentOS, Alma, Rocky, etc.), presumably the long term stability is a big reason for it. Why screw that up?
2 Likes
Thank you all for your opinions, it is very enriching to read your opinions.
I am a Linux user looking to change a small hosting server with centos7, I’ve been working with linux for more than 20 years but I have never considered myself an expert, I’m more of microsoft, really the only thing I’m looking for is a server that can have an antispam that works well and at web level is safe and stable to install for example latest versions of wordpress and nextcloud with sufficient speed, so http2 would be an interesting option.
My idea is to install a new server, migrate one or two domains that I have test and then after a few months start migrating centos7 servers to the new one.
I understand that the safest thing is not to touch the repositories that come from origin, but it is also true that if I didn’t do it I could not even install virtualmin, with the experience of the current centos7 server I have to say that I reached a point that I could not even install nextcloud because the mysql version was very old, I had to migrate to mariadb if I remember correctly putting some more repository, spamassasin I had to update it by hand because it had a version of more than 4 years, etc. etc… etc…
Luckily the server is virtualized and every time I have to touch something, snapshot before, apart from backups …
But, I insist, I find it very curious from my ignorance, that for example mariadb or spamassassin take 4 or 5 security revisions and have installed an old version just updated the system daily, I do not know if this is normal or is a question of the different distros, from my ignorance advanced linux seems curious, so I ask… what its the reason???
Agree.
But my personal problem with OS packages where to find yes no security update, as for my example php7.3 when no cve update there as writen , then does the os package does and backport or look to remi version.
Is only one example to if needed version yes no breaking partly system package.
UNDER THE LINE if you know version has CVE how to find know yes or no the OS package it in which subversion updated. While as sysadmin you have to documentate risks and measure to prevent…
EVEN if a known security problem but no updates from OS for it, you have to react and take some measurements.
I just explained the reason in the comment immediately before yours.
Be specific. Which package and which security problem do you mean?
@Joe as hypotetic i did mean that text.
So if
And yes i had for years one with to late updates Plesk… 
For now OS packages with < PHP 7.3 fpm could be problem in shared … so no centos…
Or older then i am not sure if backported this one
PHP :: Sec Bug #81026 :: PHP-FPM oob R/W in root process leading to privilege escalation
Read bottom there :
For PHP 7.3 (and older) that won’t be patched, is there any workaround available? A setting in the config that when set prevents the required conditions for exploiting this?
As for older versions, since they’re out of support, your only options would be either to try and port the patch by yourself, or have somebody - like a distro if any support older versions, or a commercial company offering long-term old versions support -
But where to find if Distro has or do that patch?
What is best OS is superlative and personal preference. The latter most down to own experience. Personally, I chose to move from CentOS 7 to 8 due to newer packages, updates etc. In addition, I have always used CentOS and didn’t fancy the switch to Ubuntu/Debian. Happy with stability and when EOL is near will most likely switch to RHEL.
With all the forks of CentOS - they may or may not be good but in 2 years time who knows what will still be available. Or perhaps we will see more forks of the forks. I just want things to work and not keen on doing a 360 migration every 12 months.
I use REMI for php74 and some standard repos but I do limit what I install to keep things stable. I also check update(s) to reduce or mitigate package clash, corruption or other errors (try to). I don’t always get it right as it is a learning curve but by keeping things simple - stability is rewarded. CentOS 7 may be supported till 2024 but I would update to 8 and deal with EOL later. Just what I would do. Your needs may differ hence a complete switch may be the direction to take.
There is no such thing as a CentOS/RHEL PHP 7.3 package. CentOS 7 ships with PHP 5.4, with a variety of patches. CentOS 8 ships with PHP 7.2.
If you have PHP 7.3 on your CentOS system, you installed it from a third party source, which is what I’ve just said you probably should not do. (We do install a third party PHP version on CentOS 7.2 from Software Collections Library, just because of extreme customer demand for a newer PHP and people were doing risky/dumb stuff to get it, but we still don’t recommend it…we recommend that if you need new packages you use a new CentOS version. Nobody should be installing fresh on CentOS 7 today.)
Srry i did write there meaning the 7.3 (so no centos) and < 7.3 yes centos 8 or centos 7
I only want to know With that example how you can know or find whatever distro’s doing then such patches as mentioned in that link ( backporting) so info versions and cve patches backporting…