AlmaLinux Beta Download Link

Figured I should post this as a new topic for more visibility.

More information can be found at

This is a replacement for CentOS 8 that Igor Seletskiy is working on. He’s the CEO of CloudLinux, for those who don’t know. Scary smart dude.


1 Like


[root@almalinux ~]# cat /etc/redhat-release
AlmaLinux release 8.3 Beta (Purple Manul)
[root@almalinux ~]# cat /etc/os-release
VERSION="8.3 (Purple Manul)"
ID_LIKE="rhel centos fedora"
PRETTY_NAME="AlmaLinux 8.3 Beta (Purple Manul)"


I’m going to paste the values for CentOS in there and try installing Virtualmin. But those are the native entries for AlmaLinux beta if you’re interested.


So far, so good.


1 Like

And all done. Install and configuration of both AlmaLinux (beta) and Virtualmin (GPL) completed without so much as a hiccup.

All I did was edit /etc/redhat-release and /etc/os-release with the CentOS values, essentially impersonating CentOS 8. That’s not a solution, of course, but just a test.

In a nutshell: When fooled into believing that AlmaLinux is CentOS, the Virtualmin installer worked perfectly.

We may just have a winner here.



Apache, the file manager, the upload function, and the built-in editor all work.

I’m stoked. Well, at least hopeful.


1 Like

PHP works.


1 Like

Lovely! I’m convinced. We’ll add support for AlmaLinux to the next major release (Virtualmin 7, which is…I don’t know how far away, but hopefully not too far). Possibly Virtualmin 6, as well, which could come sooner, as it would apparently only need updated OS detection to treat it like CentOS 8.


Probably a few repos, as well. I haven’t delved that deeply into the installer.

Of note, AlmaLinux does have a PowerTools repo. That’s helpful.

I have to do some revenue work, but I’m going to keep testing this when I’m done. It looks really good to me so far. Everything I’ve poked through looks fine, and everything I’ve tested works.


Installed upgraded / multiple versions of PHP. Works.


More things that worked “out of the box” with no drama:

Updates happened on schedule.

phpMyAdmin installed with no errors.

CSF installed with no errors.

Restore From Backup succeeded with no errors. As a combined test of Restore from Backup, PHP 7.4, Apache, and MySQL, I “restored” a backup of a database-driven site that compiles blocklists of malicious IP addresses. It succeeded without errors.

I haven’t done anything with the mail yet because it’s a local server on a self-signed SSL and I can’t get PTR to this IP. I guess I can set it up and telnet to it from the LAN to get some idea whether it’s working or not. Or maybe I’ll spin up a VPS at Turnkey to play with.

Long story short: Everything about AlmaLinux that I have tested has worked. I haven’t had much time between work and the almost two feet of snow; but so far, this still looks very promising.

If anyone has an extra computer and extra time on their hands, maybe consider spinning it up and playing around. The more eyeballs looking for bugs and the more feet stomping them, the better.


1 Like

As RPM Borat would say… I am very enjoyful of this glorious system operations for make benefit CentOS castaways.

1 Like

So I’ve had the first hiccup since starting this test. I’m not sure it had anything to do with the OS per se, but it’s worth mentioning because it may have broader application.

When “restoring” a WordPress site from a Virtualmin backup, the needed PHP extensions were not enabled. I knew how to manually enable the extensions; but just as an experiment, I decided to create another WordPress site on another domain using the Script Installer to see if that enabled them. It did. However…

The testing server has PHP 7.2, 7.3, and 7.4 installed, with 7.4 being the template default. But when the installer couldn’t install the gd extension on 7.4, it enabled it on 7.3 for the temporary WordPress site. I changed the PHP version on the restored site to 7.3, as well, which fixed the extensions problem.

I haven’t had a chance to figure out why gd wouldn’t enable on 7.4 yet. It appears to be installed. I’ll poke around some more later on today.

The site that I used as a test had originally been created on a cPanel server on CentOS 7, then migrated to a Virtualmin server also running CentOS 7; and restored to a testing server running Virtualmin on AlmaLinux 8 (but which has been slightly hacked to impersonate CentOS 8) from a backup made on Virtualmin on CentOS 7. So it could have been worse. I’m mainly curious about why it couldn’t enable gd on PHP 7.4.

That is all. Carry on.


This sounds like the kind of hiccup lots of us might run into with multiple PHP installations. Do other 7.4 extensions install and enable as expected?

If you mean ‘global’ PHP (Virtualmin lingo) how was it changed to 7.4?

I’m assuming, like CentOS 8, AlmaLinux ships PHP 7.2 by default.

I really haven’t had time to play with it since last night. (I pulled an all-nighter to do some work on my production servers, did a few more hours of public-facing work this morning, and took a nap until a few minutes ago.)

Wordpress complained about the following not being enabled in 7.4:

  • dom
  • mbstring
  • imagick
  • zip
  • gd

Of the five, only gd is actually required. The rest are recommended. All are installed on 7.4, but apparently not enabled.

The Virtualmin WP install script started by trying to enable gd on 7.4, and when that didn’t work, tried it on 7.3. It then enabled the rest as well, again on 7.3, not globally.

Yeah, that too. :yawning_face: I changed it to 7.4.

Yes. I installed 7.3 and 7.4.

I really don’t know if this is typical of WordPress because I almost never use it. I did make a mental note to check it when I move my one production WP site over to a new production server. I also should add that the restored site did work. It just complained. I suppose it would have kept working until the day I tried to use its built-in uploader to upload some images (which I don’t think I’ve ever actually done anyway).

I’m going to be installing this system locally at least once more before installing it on a production server. I’ll be looking the logs and php.ini for 7.3 on this server to figure out exactly what the Virtualmin WP installer did, and replicating the state on 7.4. Then I’ll switch the WP site over to 7.4 and see what happens. If that works, I’ll tack those steps on to my setup procedure to follow installing PHP.


For your next round I wonder if those extensions enable like they should if you do everything the same with PHP except without anything migrated – no Wordpress and nothing inherited from CentOS 7 – just to see if a migrated setting somewhere is the hiccup.

That’s basically what I did. I did all the installations before I migrated anything over. That’s why I’m thinking I have to shim another step in there to enable the PHP extensions. Or at least I would if I actually used WordPress more often than once every ten years or so…

On the bright side, that’s the first actual configuration step I’ve come across. Everything else has been pretty much automatic or accepting defaults.

I should also mention that I had no problems at all using Oracle Linux 8, either. But I didn’t migrate the WP site to Oracle, or I probably would have run into the same problem. For those who trust Oracle as a company more than I ever will (or who purchase the paid support for it), I think it also should be considered as a candidate for Virtualmin support. I didn’t come across any technical reasons why it wouldn’t work.

I, however, trust Igor more than I’ll ever trust Oracle. There’s no functional difference between the two distros that I noticed. It’s a matter of my opinion of the companies and how much I trust them.

If Gregory Kurtzer’s Rocky Linux becomes a reality before AlmaLinux comes out of beta, I’ll give that a whirl, too.


Gzip is used a lot for auto-updating not just in Wordpress but other software as well. Xenforo uses it as well. You can’t auto-update to new releases without it.

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.