5.3 is the current version, and it's recommended that you upgrade to that.
http://centosk3.centos.org/centos/5.2/readme
This directory (and version of CentOS) is depreciated. For normal users,
you should use /5/ and not /5.2/ in your path. Please see this FAQ
concerning the CentOS release scheme:
http://www.centos.org/modules/smartfaq/faq.php?faqid=34
If you know what you are doing, and absolutely want to remain at the 5.2
level, go to http://vault.centos.org/ for packages.
You can modify the repo locations in /etc/yum.repos.d/
From what I understand /5/ should be a link to the latest 5.x version
Edit: Just saw the repo file you posted now.
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=5.2&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
I don't have a centos machine around to check (don't use it anymore), but I believe that the mirrorlist line there has been modified, it should contain a variable for the version, not an actual number, like in the commented baseurl option.
Replace the 5.2 in the mirrorlist lines like:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
With that done you should be able to yum upgrade
to the next version. This is what the system should have done by default.
phpMyAdmin releases won't correspond 1-to-1 to yum package releases. You have to wait for the CentOS repositories to release a new version of the package, or you can manually upgrade phpMyAdmin yourself.
Best Answer
I wouldn't touch Amazon Linux 2 for anything requiring stability, or for any other reason, in fact. Amazon Linux (both 1 and 2) were built primarily for Amazon's needs and to run Amazon's services and they only share it publicly as a convenience. It gets upgraded on Amazon's schedule, not yours. AL2 was forked from CentOS 7 and then Amazon diverges from that distro, often so much that many packages built for CentOS 7 (like EPEL) do not work any more. So compatibility is gone too.
With that out of the way:
A time when you are switching distros for your public facing (or at least intranet facing) web site is the second best time to get your distro up to the latest major release available. (The first being when that distro is released.) At the moment that means RHEL 8.4 or CentOS 8.4. But as CentOS seems to be going away at the end of the year, probably best to switch to Rocky Linux if you don't qualify for free RHEL subscriptions (up to 16 physical or virtual machines, and production is allowed); that appears to be what most people are choosing instead of Alma Linux.
Finally, as for automatic updates, I run a few dozen public facing web sites and their servers are all on automatic updates. (They are activated a bit differently on RHEL 8 though, as yum-cron is gone, using the
dnf-automatic
package.) I have been doing so for a few years, and I cannot remember the last time there was a problem related to updates.As for security updates on CentOS: They have never tagged their updates as security updates, so the
yum --security ...
commands have never really worked. Rocky Linux has begun doing this, so equivalent commands in <distro> 8 (e.g. `dnf --security ...) work as expected on RHEL or Rocky Linux. (Though I don't install just security updates, but everything available, and it runs daily.)That said, I do have monitoring on all of the servers, so if something did break I would be notified and could wake up and fix it. For public facing sites I have analyzed the sites and their purpose and I believe the risk of external compromise, especially on day 0 or earlier, is far higher than the risk of a site breaking due to a bug in an update. Which is why I also have SELinux configured and enforcing.
So my recommendation for you would be to go to RHEL 8.4 if you qualify for the free subscription and Rocky Linux 8.4 if you do not. (And choose the correct region; you don't want to be serving from us-east-* if all your visitors are in Europe, for instance.)
Remember to take an AWS snapshot before the upgrade. In case something does go wrong, you can either fix it quickly or roll back to the AWS snapshot.