I just talked with Greg (Rocky Linux) a couple of days ago. He has the same passion as he did with CentOS. He said that 8.4 was their goal, and they have that up now (they even had an 8.3RC up before that).
But RJM is right. If Rocky Linux is not supported, the same “takeover/shutdown” will happen again.
I agree. Even if you don’t need Pro, if you’re using it to make money, I think you should pay for the Pro version.
Actually, I believe that people should pay something, in keeping with their ability to do so, to the maintainers of all FOSS software that they use, assuming it’s also good software. Being FOSS isn’t enough to get money out of me. It also has to be good (or at least have the promise of becoming good in the case of new projects).
As an aside, the most recent addition to my list is OpenMediaVault. I installed it as a stopgap a while ago when an expensive NAS I ordered turned out to be faulty. In the process of installing an additional 8TB Exos drive on OMV a few days ago, I realized that it was so good that I was no longer looking for a retail NAS. So I sent them money.
It’s not generosity. It’s self-interest. If you want good software to stay around, you need to support it. We’ve lost a lot of good projects (including CentOS) due to lack of financial support.
Richard
Yes I’m with you man. Rest is palava.
Joe:
As you know we are communicating on UBUNTU, but the Centos install does not allow cgi-bin to work either.
I just did a quick install for development purpose, hoping to find a solution to the suexec issue, bringing up a CENTOS install, but cannot even get a simple Hello World working under normal conditions. ie: http://wwwc.netstores.com/cgi-bin/test.pl
System hostname
upgrade21.netstores.com (155.138.148.99)Operating system
CentOS Linux 8.4.2105Time on system
Friday, July 9, 2021 6:36 AMKernel and CPU
Linux 4.18.0-305.3.1.el8.x86_64 on x86_64System uptime
It is not expected to. I’ve explained the situation with CentOS 8 in one of your other threads. If you want CGI on CentOS with Virtualmin, you’ll need to run CentOS 7. But, CentOS 7 will also not work the way you seem to want it to (running suexec apps outside of the suexec docroot).
Edit: Ubuntu and Debian allow you to configure the suexec docroot at run-time via suexec-custom, but that docroot still can’t be /. CentOS does not have suexec-custom; the docroot is compiled in.
I have set up an AlmaLinux 8 Xen 4.15 host and it works extremely well. I also just created an AlmaLinux 8, Debian 11, Ubuntu Server 20 and almost done with a Fedora 34 Server VM for Xen/Cloudmin to share if anyone needs them.
I have a test server setup which was original CentOS 8 with Virtualmin installed. I migrated it to Rocky Linux 8.4 with their migration script. Virtualmin detected the OS change and continued to work smoothly. All seems good so far.
That just answered my question. Thanks.
Have you noticed how many “redhat clones” are now popping up? IBM will eventually regret their decision. I just hope we end up with one that doesn’t “go away” again.
I’ll be honest… I almost want to thank them for doing it. For one it pushed a few new distros into creation and likely ran some of the people who used to contribute code away as well and left RedHat/IBM with a big black eye. As I was just about to upgrade to 8 I was ready and able to switch over to Ubuntu and absolutely love it. I have less if any problems installing or running things and only a slight learning curve but worth it. I won’t be going to redhat or any of their clones because they all still feed off of Redhat. Their move said ‘we don’t want you’ and I really didn’t need them. People will remember what they did for a long time.
It just seems that all distros are based off a few main ones like Debian, RH, Suse minus the one like Gentoo and FreeBSD. I guess it all depends on the look and feel of each distro (desktop version) and where it puts things and which packages it installs and how it installs apt, rpm, yum. Maybe I’m over simplifying it but I have installed a variety of distros through virtualbox or VM and they all seem to generally be the same.
Meanwhile, Ubuntu still going as strong as ever 
@lulatsch66, here’s my “dovecot-fix” script info:
make a backup of your entire /etc/dovecot directory
create a work folder (i.e. /root/work/dovecot) for the following files
create a “dovecot.conf” template (you’ll only need the “local example” section for special domains)
dict {
}
!include_try conf.d/*.conf
!include_try local.conf
local 74.208.144.147 {
protocol imap {
ssl_cert = </home/example.com/ssl.cert
ssl_key = </home/example.com/ssl.newkey
}
protocol pop3 {
ssl_cert = </home/example.com/ssl.cert
ssl_key = </home/example.com/ssl.newkey
}
}
#!/bin/bash
/usr/sbin/virtualmin list-domains --name-only --toplevel > /root/work/dovecot/dovecot.conf.dat
/usr/bin/perl /root/work/dovecot/dovecot.conf.pl > /root/work/dovecot/local.conf
/bin/cat /root/work/dovecot/dovecot.conf > /etc/dovecot/dovecot.conf
/bin/cat /root/work/dovecot/local.conf > /etc/dovecot/local.conf
/bin/chown -R root:dovecot /etc/dovecot/
/bin/chmod -R ug+rw,o-rwx /etc/dovecot/
/etc/init.d/dovecot restart
use strict;
use warnings;
my $filename = '/root/work/dovecot/dovecot.conf.dat';
if (open(my $fh, '<:encoding(UTF-8)', $filename)) {
while (my $row = <$fh>) {
chomp $row;
my $key = "";
my $cert = "";
if (-e "/home/$row/ssl.key" ) { $key = "ssl.key" ; }
if (-e "/home/$row/ssl.newkey") { $key = "ssl.newkey"; }
if (-e "/home/$row/ssl.cert" ) { $cert = "ssl.cert" ; }
if (length($key) && length($cert)) {
print "local_name $row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name www.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name mail.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name smtp.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name pop.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name pop3.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
print "local_name imap.$row {\n";
print " ssl_cert = </home/$row/ssl.cert\n";
print " ssl_key = </home/$row/$key\n";
print "}\n";
} else {
warn "Could not find ssl.key/newkey/cert in '$row' $!";
}
}
} else {
warn "Could not open file '$filename' $!";
}
Where is this dev version? I’d like to see if it will resolve the dovecot issue on Oracle Linux.
It’s in our github virtualmin-install repo. But, Oracle detection isn’t something that was added. I wouldn’t expect it to do anything good on Oracle.
I was hoping for a url. 
I actually made some progress and it doesn’t seem too bad. I’ll post back here what I get figured out and then send you the changes I made for your consideration. My most serious hanging point at this time is the dovecot. I think I have the changes to the slib.sh and install.sh nearly figured out.
I think it was for upcoming Webmin 1.980.
Is Oracle much different than RHEL itself?
What didn’t work exactly? I think you could clone the latest Webmin source code and run setup.sh and see if things get detected correctly and if the right configs are used for the basic services, like MariaDB, Bind, Apache and etc.
No, it’s basically the same except by default it includes their UEK kernel which seems to be based on kernel-ml which supports all sorts of environments such as dom0, domU, Xen and KVM whereas RHEL has gone out of their way to remove all support for Xen.
I’ve taken care of most issues and will test then share my fixes with you guys. Dovecot is the only one that I haven’t had a chance to revisit yet. See the other thread I have CentOS 8 Hosting Alternatives
Yes and no. It’s binary-compatible in the sense that anything that will run on RHEL should run on Oracle Linux, but it also supports some Oracle stuff that RHEL doesn’t. I forget the specifics offhand. I’m not a fan of the company, so that information never made it from my brain’s RAM to storage.
The distro, however, worked okay with Virtualmin when I used the method of starting with CentOS 8, installing Virtualmin, configuring the system, and running the Oracle Linux migration script. I guess I tried it half a dozen different ways before that, but doing the migration after Virtualmin was installed and the server configured was the easiest and best.
That’s also the same method that worked best for AlmaLinux. The testing server I set up that way using AlmaLinux is still running flawlessly right here in my office for more than four months. The only times it’s been rebooted have been for kernel updates, which wouldn’t be an issue with KernelCare.
If I had to set up a production server tonight, I would do this:
But as I don’t have to build a server tonight, I’ll wait for official support.
I would do Rocky Linux the same way if I had more confidence that it will still be around in a few years. I trust Greg completely. I just don’t trust the tightwads in our industry to support him. That really pisses me off, by the way. I believe that anyone who uses FOSS commercially should contribute something to the project.
I’ll bet the vast majority of CentOS users who made their livings with the OS never contributed a dime to the project. That’s how it wound up in RH’s hands, which was the first step in our losing it.
In Igor’s case, he’s a profit-making business with a commercial interest in supporting a free project; so I can kind of forgive people if they choose not to contribute money to AlmaLinux. But at least buy a KernelCare license. It’s a no-brainer anyway as it avoids the vast majority of reboots.
KernelCare is not technically supported in Virtualmin, but it still works. Just defer all non-security kernel updates until Igor has a chance to patch them in KernelCare, which typically is a few hours to a few days. I suspect it will be seamless enough in AlmaLinux that even that won’t be necessary, since the same house is producing the OS.
Richard
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.