A safe yum.conf would not break Xenforo 2.2

xml

Active member
I am on Almalinux8 KVM VPS and trying to configure yum.conf in a way that would not break my xenforo 2.2 forums.
currently my yum.config of new OS install with Apache2.4, php8.1, MariaDB 10.6:
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

and my repolist is:
repo id repo name
MariaDB106 MariaDB106
appstream AlmaLinux 8 - AppStream
baseos AlmaLinux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
extras AlmaLinux 8 - Extras
remi-modular Remi's Modular repository for Enterprise Linux 8 - x86_64
remi-safe Safe Remi's RPM repository for Enterprise Linux 8 - x86_64


Any suggestion would be appreciated.
 
I am on Almalinux8 KVM VPS and trying to configure yum.conf in a way that would not break my xenforo 2.2 forums.
So why do you think yum would break your Xenforo? And what from yum would tend to do that?
Basic settings seem good.
However I don't know for sure if it's wise to combine remi and epel and wonder why you did that or why you used a seperate mariadb repo.

Edit: yes Centminmod, but that was already discussed in your other thread.
 
If you want to stick with Apache:
The Remi repositories are a great choice for PHP as part of your overall setup - just use them for PHP. The settings at first glance looks good. My recommendation for Apache is using fcgi and php-fpm. If needed, you can use php-fpm to run multiple versions of PHP at once by giving each version a different port number in Apache config files, and in each PHP config.

The Maria repo is also a good choice. You can run newer versions, from a stable and tested source. :-)

Apache gets a lot of flack, and it deserves much of it. But it does have some positives for a small market segment. Nginx and Litespeed can't touch many of the features its has via a large number of add-on modules. If someone wanted a jack of all trades HTTP server, Apache is it.

If you're open to alternatives:
A beta product as the entire LAMP framework on a production server would make me nervous. That's a pass for me. If you do go with Centminmod, if it were my choice I'd not run the beta version.

Consider Cyberpanel with Openlitespeed (supports Enterprise Litespeed too). It supports .htaccess files (Nginx lacks this), and with with LSPHP and LSCache. Then the Xenforo LSCache add-on for the fastest Xenforo PHP performance there is, using less system resources than Nginx and Apache.
 
  • Like
Reactions: xml
So why do you think yum would break your Xenforo? And what from yum would tend to do that?
Basic settings seem good.
However I don't know for sure if it's wise to combine remi and epel and wonder why you did that or why you used a seperate mariadb repo.

Edit: yes Centminmod, but that was already discussed in your other thread.
Thank you for your direct reply to the subject.
On 2020 cPanel servers running automated yum update and this incident happen
This is yum.conf for cPanel server
[main]
exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* nsd* p0f php* proftpd* pure-ftpd* spamassassin* squirrelmail*
tolerant=1
errorlevel=1
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=5
bugtracker_url=http://bugs.centos.org/set_project....s.centos.org/bug_report_page.php?category=yum
distroverpkg=centos-release

I know this kind of incidents is rare, but I would like to avoid it, if possible, by a safe yum.conf configuration. is the basic setting is enough to avoid a similar incident?

remi and epel repos are for newer versions php and as for mariadb.repo because I did not find mariadb10.6 in the default repos almalinux installation.
 
On 2020 cPanel servers running automated yum update and this incident happen
Correct, but one has to look at the cause:
This was a bug in mysqlnd as in PHP 7.2:
So an update to MariaDB 10.3.27 fixed this issue.

I presume you want to update MariaDB too. You're using the direct MariaDB repo, but that most likely would have caused the same issue on an update. If the application itself has an issue, then you are always at risk encountering something like that.

If you want to prevent it, you should stick at the current version and don't update anymore, which would mean disable the MariaDB repo.
However, disable other repo's too in that case, because also PHP or Apache might encounter a bug causing the forum to go down. So on every update there is always a slight risk.
And this is independent of the fact if you are or are not running some panel.

Normallly the basic yum configuration should be enough, but also yum can't protect you from bugs within the applications.

remi and epel repos are for newer versions php and as for mariadb.repo because I did not find mariadb10.6 in the default repos almalinux installation.
Just take care that no older php or mariadb versions are installed then from the base repo's.
You might want to see (just to be sure) to disable certain packages by the exclude line in the repo.
For example in the base repo add:
exclude=php
however you have to look this up or test this, I never used it this way, so I'm not 100% sure.

Question: How is using separate MariaDB repo an issue but an alternative beta stack not?
You might want to read again. I never said it was an issue. ;)
 
  • Like
Reactions: xml
I thought control panels like cPanel and Cyberpanel install LAMP stack with their installation process. I am I right?

Yes. And they aren't beta. "Beta" is the key part that makes me nervous about a production server.
 
exclude=courier* dovecot* exim* filesystem httpd* mod_ssl* mydns* nsd* p0f php* proftpd* pure-ftpd* spamassassin* squirrelmail*
Oh just seen this again. Be aware that a yum.conf including this means that it will not update these things from any package.
So like this, your httpd, php, ftp program and exim etc. will not be updated at all.
 
I presume you want to update MariaDB too. You're using the direct MariaDB repo, but that most likely would have caused the same issue on an update. If the application itself has an issue, then you are always at risk encountering something like that.

Agreed. It wasn't the yum.conf at fault, it was a package bug. I was surprised it got by Mariadb's team, given how many PHP installs are using it.
 
How I would know if the LAMP I am installing is beta or stable?

In the case of this topic:
1. When it says it's beta, like Centminmod says about it's version for Alma/Rocky 8.
2. When requires purposefully changing to a beta channel to use beta packages, like WHM/cPanel does.
3. When it requires you seek out and install the test release line, versus the standard install, like CyberPanel/Litespeed does.
4. When you install a release version of a repository, like Remi release, it's not beta. Versus one of their release candidate repositories.

EPEL is sort of a grey area, but it has such a huge audience that it's generally extremely well tested, and has an an advanced announcement discussion to let people know of issues.

EPEL works fine with Remi, so long as you set Remi to be the source of PHP packages. I've yet to run into conflicts on an older server that's been running that combination for years.
 
Yes. And they aren't beta. "Beta" is the key part that makes me nervous about a production server.
While I can't comment on the current state of Centminmod, I seem to recall the previous version was in beta for a long time simply because the documentation needed to be updated. And at the end of the day, its simply a word. GMail was in beta for many years, as an example.
 
While I can't comment on the current state of Centminmod, I seem to recall the previous version was in beta for a long time simply because the documentation needed to be updated. And at the end of the day, its simply a word. GMail was in beta for many years, as an example.

Words have meaning. That's why Google, when they finally took off the "beta" label, acknowledged it wasn't a good thing to have left it there so long.

For me, I would not feel comfortable installing it on a client's system because telling them "beta is just a word" isn't an option for me.
 
When it says it's beta, like Centminmod says about it's version for Alma/Rocky 8.

Yeah it's beta because I need to properly test stuff. I've almost automated all the testing for AlmaLinux, Rocky Linux and Oracle Linux EL8/EL9, which will save a lot of testing hours https://community.centminmod.com/th...malinux-vs-rocky-linux-vs-oracle-linux.24179/ :D Though Centmmin Mod beta sort of follows Nginx's definition of Nginx mainline vs Nginx stable - latest features and changes and more rapid bug/security fixes go into Nginx mainline while Nginx stable branch waits a full year until Nginx promotes Nginx mainline to the next Nginx stable release.

Anyway, regardless of whether it's labeled stable or beta, if you don't know what you're doing, either can be dangerous! So it's best to always test on a test server before using in production whichever web stack you decide on using :) @xml I'd setup a duplicate test server of your Xenforo server and use that as staging for testing and documenting your experiments with changing configurations and settings. You don't want to be learning the ropes in production if you're not that familiar with it all.

I am on Almalinux8 KVM VPS and trying to configure yum.conf in a way that would not break my xenforo 2.2 forums.
currently my yum.config of new OS install with Apache2.4, php8.1, MariaDB 10.6:

I haven't need to manual configure YUM in years but that is because I automate all of it.
remi and epel repos are for newer versions php and as for mariadb.repo because I did not find mariadb10.6 in the default repos almalinux installation.
If you're using Cpanel, I wouldn't go using a MariaDB YUM repo beyond the one Cpanel provides though.
 
Last edited:
If you're using Cpanel, I wouldn't go using a MariaDB beyond the one Cpanel provides though.

I am going to dump cPanel and will not use any kind of control panels and run my server manually by terminal command line.
 
One note about cPanel for anyone choosing it.

You can no longer use the easy WHM ability to switch between MySQL and MariaDB, not since they mainlined MySQL 8.

If someone wants to go with MariaDB, a config file needs to be manually created and edited before the install WHM. WHM will then install with MariaDB. If you don't do this, switching requires manually switching them, and changing WHM's configuration by hand.
 
Top Bottom