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:
- Install CentOS 8 minimal
- Update
- Install Virtualmin
- Configure the system for its mission
- Create or migrate the domains
- Run the AlmaLinux migration
- Install KernelCare
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
1 Like
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.