Full compatible distro for Cloudmin?

Cloudmin
1

I always use Debian for my servers for many reasons like stability.
I installed Cloudmin Pro on a server that i am building for a customer
Enabling XEN, KVM and LXC from cloudmin don’t work, docker integration also doesn’t seem to work as cloudmin never manages to use the dockers i create, neither creation of new from inside cloudmin works.
I am not a newbie on linux at all, and i can’t understand what i am missing here.
Is Debian really compatible with Cloudmin or i am losing my time?
What disto will work out of the box with Cloudmin Pro?
I want just to install it and create the vms, not spending hours to make things work (i have already lose two days)

More details for what doesn’t work if matters
Docker wasn’t working. after installing manually it, i tried to download and install docker image from cloudmin search_dimages, and downloads nothing (no disk usage at all)
Tried connecting manually created docker image and nothing. Creating new docker from cloudmin, gives Failed to create system error without any clue. I have installed official docker package, not docker.io or else.
LXC fails on creation, as bridging network that documentation says to add on network interfaces, breaks the networking of the server and gets unreachable. Also cloudmin seams to use cgroups v1, while debian of course uses cgroups v2, and gives error: The cgroup filesystem is not mounted
KVM installation via cloudmin fails for missing packages
XEN installation via cloudmin breaks again the networking like LXC guide. Even by using other network bridge, adding host to XEN fails without mentioning reason

2

In a few days the new installer will be out for Rocky/Alma/RHEL 9. Debian 11 will follow a few days after that, probably.

3

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

4

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

5

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

6

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
7

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?

8

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
9

Will this installer also support alma 8 ?

thank you

10

Surely it better to use the latest OS.

1 Like
11

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.

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

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.

14

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.

15

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

16

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.

17

I am curious, how do you know about incompatibilities?

Are they related to SSL/TLS stuff

18

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.

19

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.

20

Any update on the Debian 12 version?