Full compatible distro for Cloudmin?

Hello Joe, thank for your reply. So Debian 12 will not be soon supported at all?
I ve setup now a Rocky 9 system and will try tomorrow to setup vm and containers.
Is there somewhere an open bug tracker for cloudmin?
Also on Automated Cloudmin Installation – Virtualmin it should be written what systems are supported correctly and their supported versions

Er, Debian 12. I mistyped. It will be the current versions.

ok ok. about the bug tracker? there are some bugs for example on docker module

Docker support is moving into Virtualmin Pro, where it’s a better fit. It’ll keep being present in Cloudmin Pro for a while, but will likely eventually be removed completely. Cloudmin just doesn’t think about the problem in a way that makes sense for containers…it wants to deal with whole virtualized systems, not containerized applications. Virtualmin, on the other hand, is a comfortable place to talk about running containerized applications behind a frontend web server.

Cloudmin is being overhauled as we speak, including getting a public Github. That’s not done yet, but I’m working on it as fast as I can (I only have weekends and evenings available).

2 Likes

When Virtualmin pro will support Docker? I have sent you a ticket for refund of the cloudmin subscription…
LXC support will be also removed on cloudmin? if not, will it be fixed to work with cgroup v2?

The container and app server support in Virtualmin Pro (including Docker or Podman support) is working pretty well and in private testing now. It’s still getting a lot of UI polishing and bug fixing and it still needs documentation, so it’s not ready for public consumption yet, but it should be available for customer beta testing in a couple/few weeks.

And, yes, LXC is also being removed from the default Cloudmin installation. We’re cutting down to just KVM or Xen (with KVM recommended) on Linux as supported virtualization types in the installer, for a variety of reasons.

One reason is that we’re just overwhelmed. Cloudmin doesn’t make enough money to begin to support its development, certainly not enough to hire another developer to help out (or enough to justify one of us quitting our other jobs to work full-time on it), so we have to reduce the surface area dramatically.

But, also, container-based full system virtualization is kind of a dead end. KVM is now the de facto standard for that kind of virtualization and with advancements in memory sharing the advantage of containers has mostly evaporated (it used to be that KVM needed a lot more memory than something like LXC, and could be more resource hungry, but that’s not as true any more). And, KVM gets tremendously more funding than LXC/LXD has gotten, so it’s just a remarkably more mature platform. The market and the development resources have decided that containers are for running apps and KVM is for running full system virtual machines.

So, container support (Podman preferred, but Docker is also fully supported, but the default install will use Podman) is coming to Virtualmin very soon and leaving Cloudmin, at least in the default installers. Container support will remain in the Cloudmin package for some time (depending on how many customers are using it), so it’ll still be possible to keep using it and keep getting updates and bug fixes for existing deployments, but it’ll stop being part of a default installation when you run the install script.

LXC and Zones will probably remain in the package longer than Docker, since Docker has never really been useful in the ways Cloudmin uses it and I doubt there are any production users depending on it that wouldn’t be better served by Virtualmin support for it.

The side effect is we can actually focus on making the primary/recommended virtualization type (KVM) really nice to use. That’s not really the case right now. There’s so many options and so many weird interactions between virtualization types, and this is a complicated area with a lot of low-level kernel interaction, that it can be really hard to make Cloudmin work really nicely without more expertise than I think we should expect users to have. I started working on a new installer for Cloudmin ages ago, but there were so many scripts and so many targets and so many interactions that it was overwhelming. Reducing the focus of Cloudmin makes it possible to make it good given the resources we currently have.

4 Likes

Will this installer also support alma 8 ?

thank you

Surely it better to use the latest OS.

1 Like

Maturity is more important for us then cutting edge. When a distro reaches .5 we start testing it and start using at about the .5 or .6 release. Any RHEL clone has a lifespan of 10 years, at .5 there is about 6 (or more) years left. Even that is more then the 5 years an ubuntu LTS has.

Release Release date End of Full Support End of life
RHEL 8 May, 2019 May, 2024 May, 2029

end of life: may 2029

As i said: still more then 5 years.

In full support new hardware is added, but hosting companies don’t replace dozens / hundreds of servers every few years. Industry standard is to replace server hardware every 3 to 6 years, for the taxman you need 5 years to write off computer hardware.

Version General availability
9 May 18, 2022
8 May 7, 2019

rhel 9 is not even 2 years old.

Definitely not.

There are no good reasons to install a five year old OS for a new deployment. RHEL/Rocky/Alma 9 is plenty mature, whatever that means. And, if you’re using the installer, it is a new deployment on a freshly installed OS.

You can continue to use Cloudmin on whatever old OS you want, but the installer is about new installations, and new installations should be on a reasonably new operating systems.

Full support is 5 years. Plus EL mean Enterprise Linux, I never thought of RHEL as being cutting edge.

Total support for RHEL 8 is 13 years, for clones it is 10 years because they don’t have access to the ELS. Says so clearly on the page. So i have every confidence that alma 8 will be fully supported and secure until may 2029. So if Redhat still supports it for more then 5 years, why not cloudmin?

Besides that, rhel 9, actualy alma 9, that is what we would use, has some incompatibilities with the needs of our customers.

I am curious, how do you know about incompatibilities?

Are they related to SSL/TLS stuff

no, php. In alma 8 it is possible to start at php 5.6, in alma 9 the lowest possible php version is 7.4.

At this moment we still have over 15 servers that are centos 7, they will be migrated to alma 8 in the coming months. On those servers there are over 100 websites all together that still use php 5.3, 5.4 or 5.5. They will be updated to 5.6 by us at migration time. Things like database connection are the same in 5.3 and 5.6, but complete different between 5.x and 7.0+ (mysql vs mysqli). I am not knowingly loose hunderds of clients just because we need to have the latest. Alma 8 is still more then 5 years supported so it is the best option for us at the moment. We are a small company and every customer counts. It’s not that we are like aws or M$, they are not bothered by loosing a few thousand clients.
i know people should use the latest version, but a lot of people think “it works, so why pay to change it”. We provide the most php versions possible, it’s the responsibility of the customer to use the best version.

Cloudmin does not manage websites. It manages virtual machines, and those virtual machines can run any danged OS you want.

This is going wildly off-topic; PHP has nothing to do with Cloudmin.

Any update on the Debian 12 version?

I know, but all our servers are alma 8 and the cloudmin is to install test virtual machines to test new configurations and migrations. We like to keep all our server the same for configuration reasons. Thats why i asked if the new cloudmin would be also for alma 8.

I know, but Randomz asked what the incompatibilites are and i answered, that’s the polite thing to do.

Another reason we don’t use alma 9 yet is the network setup. All our servers have bonding and with ifcfg files that supper easy to install and manage. After a migration, the ip addresses are also moved, so its important that can be done swift and fast.

I know haw to revert back to ip tables, but didn’t find anything on reverting back to ifcfg. If someone knows a guide, please let me know. That is the only thing that keeps me from installing the cloudmin on alma 9. For customer servers we will keep using alma 8 as long as we can.

thank you

Any update on the progress of the new installer ??

Thanks
Michael