Question about Cloudmin and Virtualmin. Also suggestions for alternatives.

I am still unclear as to how Cloudmin differs from Virtualmin. I am happy with Virtualmin but would like to know compelling reasons to use Cloudmin. The information I have found on the product sales page is very vague. Could you please elaborate?

Virtualmin is a great product, but it need to support NSD as DNS and Lighttpd or NINGX and webservers as the alternative to BIND and Apache. Having these other alternatives would definitely help Virtualmin or Cloudmin become the best beyond the best. BIND is just too slow to load up 48,000 domains.

Status: 
Active

Comments

I am still unclear as to how Cloudmin differs from Virtualmin. I am happy with Virtualmin but would like to know compelling reasons to use Cloudmin. The information I have found on the product sales page is very vague. Could you please elaborate?

Virtualmin is a great product, but it need to support NSD as DNS and Lighttpd or NINGX and webservers as the alternative to BIND and Apache. Having these other alternatives would definitely help Virtualmin or Cloudmin become the best beyond the best. BIND is just too slow to load up 48,000 domains.

Basically, Cloudmin is for managing virtual machines , such as Xen, KVM and OpenVZ instances. Each virtual machine appears to its user like a real system, and can have Virtualmin installed to host multiple websites. Cloudmin is basically a level above Virtualmin or Webmin, as it deals with entire systems instead of websites, users and databases.

To learn more about Cloudmin, see http://www.virtualmin.com/documentation/cloudmin

Basically, Cloudmin is for managing virtual machines , such as Xen, KVM and OpenVZ instances. Each virtual machine appears to its user like a real system, and can have Virtualmin installed to host multiple websites. Cloudmin is basically a level above Virtualmin or Webmin, as it deals with entire systems instead of websites, users and databases.

To learn more about Cloudmin, see http://www.virtualmin.com/documentation/cloudmin

So we will still need Virtualmin regardless?

How does Cloudmin licensing work? Is is server based or per application based? How does this licensing pricing fit in with Amazon EC2?

Is there a way to test drive Cloudmin to see what the management interface looks like in action?

"Basically, Cloudmin is for managing virtual machines , such as Xen, KVM and OpenVZ instances. Each virtual machine appears to its user like a real system, and can have Virtualmin installed to host multiple websites. Cloudmin is basically a level above Virtualmin or Webmin, as it deals with entire systems instead of websites, users and databases."

I think you should add the above comment to the front page where the section "Cloudmin". This will clear it up in plain site and prevent more questions like mine.

On another note. Is Cloudmin a hypervisor of some sort (like proxmox)? If so, can it run on 32 bit machines as opposed to just 64 bit?

On unrelated note, CENTOS 6 seems to be in an uphill battle with RHEL 6. We are thinking of using Debian 6 for Virtualmin. Would you recommend Debian over CENTOS 6? Which one would you personally use, CENTOS or Debian?

Hi Jamie, I have asked you this before. Virtualmin have a serious problem with BIND when loading up 48,000 domains. It takes hours. Does Virtualmin have support for NSD as an alternative DNS server? How about Lighttpd as an alternative webserver to Apache?

So we will still need Virtualmin regardless?

The functionality of Virtualmin and Cloudmin doesn't overlap. Cloudmin is for provisioning Virtual Machines. If you then want a Virtualmin management interface on those Virtual machines, you may indeed want to install Virtualmin. You can choose between Virtualmin GPL and Virtualmin Pro, depending on your needs,

Is there a way to test drive Cloudmin to see what the management interface looks like in action?

You may want to take a peek at Cloudmin GPL:

http://www.virtualmin.com/documentation/cloudmin/gpl

How does Cloudmin licensing work?

Licensing for the Pro version is based on how many Virtual Machines Cloudmin manages. The GPL version is, of course, free, but doesn't manage as many types of Virtual Machines (at the moment, it offers support for Xen and KVM).

On another note. Is Cloudmin a hypervisor of some sort

Cloudmin takes existing Virtual Machine tools, and provides a web interface to make them easy to manage.

On unrelated note, CENTOS 6 seems to be in an uphill battle with RHEL 6. We are thinking of using Debian 6 for Virtualmin. Would you recommend Debian over CENTOS 6?

Any of the supported distros should work -- I'd recommend using the one you're most comfortable with. CentOS is the most common distro for running the various Virtualmin/Cloudmin products, and as such, tends to get a bit more testing. However, there's plenty Debian and Ubuntu users as well, and if that's your preferred distro, it should work for you. If you do happen to run into an issue, let us know and we'll get it fixed :-)

Does Virtualmin have support for NSD as an alternative DNS server? How about Lighttpd as an alternative webserver to Apache?

I'd suggest opening up a different request when you have questions of a different topic, we get all confused when the topics of a support request get mixed up :-) But as a quick answer -- No, at the moment, Virtualmin only supports BIND and Apache. Most folks using Virtualmin don't have 48,000 domains on one server, so this issue hasn't come up much :-)

Also, honestly, I wouldn't even begin imagining to operate 48.000 domains (BIND-wise) on one server using Virtualmin. (I suppose you're not hosting web space or databases for those as well? 48.000 web sites on one machine... I'd like to see the web server that can handle that :) ) I don't think it's in any way feasible to use Vmin just for BIND but for that huge amount of zones.

The traffic is medium for these domains. From a hardware perspective, there's no doubt the hardware can possibly handle the load (8 sockets x 4 cores = 32 cores).

As for software, NSD loaded up 67,000+ domains in less than 1 minute. BIND never made it there on many boots. Sometimes it just hang around for about 1-2 hours before I could even access the Virtualmin interface. I've attempted to work with Jamie in the past about this matter, but I pretty much gave up on the idea of trying to run that many domain on BIND.

It has been two years since I brought this up about how BIND could not handle the load.. Also, BIND has too many security issues. It is also bloated when compare to other DNS servers. Even TinyDNS (DJDNS) is more secured than BIND. This is not based not only on my opinions (which could be considered as subjective), but also on facts and performance tests done by others. There are facts everywhere surrounding how poorly BIND is when comparing to others. Try searching Google and you will see what I mean.

For some intended purpose, lighttpd can be a much better choice for web serving than Apache. Major sites that use it are: YouTube, wikipedia, and meebo

NGINX is used by all the major sites like: WordPress, Hulu, Github, Ohloh, SourceForge. Mahalo, and TorrentReactor.

In summary, I would love to see Webmin and Virtualmin continue to be the best. By having the options for users to choose between different DNS server (NSD would be the ultimate) and Web servers, it would be the ultimate choice for web hosting control panel. Time has changed and sites are finding way to be more innovative to handle the growing traffics (Hadoop, Ruby On Rails, Nghix, MemCache, Lighttpd, etc.).

It looks like the competition is already on it. Just check out the features. They have option for lighttpd and DJDNS:

http://www.lxcenter.org/

This company also make a virtualization interface that allow replication between servers a breeze (seamless clustering and replication). I know Cloudmin now has this capability, but not sure how difficult it is to setup.

Bottom line, I am a loyal and die hard fan of Webmin/Virtualmin. Come on now Jamie and Joe, can we get some of these integrations moving forward? LOL :-)

I know the Virtualmin team is always busy as heck, but just thought I ran these thoughts and hope we can get something going. Thank you for your time reading this.

I also would like to add that NSD as the DNS server is the only one that I know of which can survive a DoS attack, yet keep serving queries. Here's one example:

http://www.secure64.com/secure-DNS

This should be an excellent reason for webmasters to consider NSD as their prime choice for DNS server.

Deploying 48,000-67,000 domains incorrectly would cost much time, effort, and money to correct it later. I am hoping to do it right the first time with Webmin/Virtualmin's help.

For commercial webserver. LiteSpeed seems to be the way to go. They also integrate with most of the other control panel (except for Virtualmin):

http://www.litespeedtech.com/

And how do you intend to be handling this incredibly huge amount of domains with Virtualmin?

Check the license numbers, "unlimited license" starts after "250 domains". Gives you an idea for how many domains it is suppose to scale. I think it is simply not meant to be handling 48.000+ domains. Not even the domain selection screen/boxes will support anything close to these figures.


In summary, I would love to see Webmin and Virtualmin continue to be the best.
By having the options for users to choose between different DNS server (NSD would be the ultimate) and Web servers, it would be the ultimate choice for web hosting control panel.
Time has changed and sites are finding way to be more innovative to handle the growing traffics (Hadoop, Ruby On Rails, Nghix, MemCache, Lighttpd, etc.).

Technically I am inclined to agree, but I recently had a chance to look into some of the code and was surprised by its strictly procedural nature - typically, such challenges (i.e. supporting multiple implementations/backends via a single frontend) are handled by coming up with a common subset of features found in all supported implementations and using a shared wrapper for those, while delegating backend-specific stuff to a corresponding backend-specific module (i.e. "delegate in the programming sense")

So each supported back-end module (apache, lighthttpd, nginx etc) would implement the generic "interface" (in the OO sense) of the high-level wrapper to provide its own implementation of the generic functionality that's found and supported in all back-ends.

This would in turn also allow migrations from one back-end to another (i.e. from apache to nginx) - as long as none of the custom/non-common features are used.

From an architectural point of view introducing abstraction wrappers and identifying shared features would seem like a worthwhile effort - generic "modules" (httpd, dns, mail, IDS) would define interfaces that would be sub-classed by for a particular piece of software such as bind9, nsd, TinyDNS etc.

While this discussion has become pretty sizable and probably isn't very representative of the typpical webmin user (who else's got 48k domains here...), the input is actually pretty valid and valuable - as could be seen by the rise of nginx during the last few years - and it is foreseeable that less-scalable packages like apache or bind9 are going to lose market share and relevance, while software like nginx or NSD is gaining more and more ground over time -- and supporting such optional packages would also ensure that webmin keeps an edge and doesn't fall behind due to a "technology lock-in", i.e. lots of hard-coded assumptions about the underlying software stack used in webmin/virtualmin.

Perl isn't the typical language for OOP, but it's obviously possible to also come up with abstraction layers in Perl as well, to help ensure that implementation specifics are well-encapsulated, while shared features are handled via common building blocks.

Who knows what webserver/DNS/mail server or IDS is going to be popular in 5 years from now - it would seem like a good idea to prepare the webmin architecture such that building blocks have interfaces that only need to be implemented for new modules/packages.

in the sense of having something like this in pseudo code:


class CGIAccessible;
class RPCProvider;
class CLIAccessible;

class WebminModule: CGIAccessible, RPCProvider, CLIAccessible;
class ConfigurableModule: WebminModule;

# having a daemon class that exposes config options, RPC and CLI support
class Daemon : ConfigurableModule;

class HTTPServer: Daemon;
class Apache: HTTPServer;
class nginx: HTTPServer;
class lighthttpd: HTTPServer;

class DNSServer: Daemon;
class Bind9DNS: DNSServer;
class NSD: DNSServer;

At the moment, there also seems to be a certain disparity between the features available via RPC and those available via the virtualmin CLI tools - enforcing a design where features are added by implementing interfaces could help clean up things a bit.

This would probably involve introducing 2-3 dozen helper "classes", to increasingly identify requirements and port certain modules step by step - but it would open the doors to better support future technologies, while decoupling design assumptions that are currently hardcoded in various places.

PS: Sorry for the thread resurrection :-)

We do support this kind of generic webserver interface already, which is how the Nginx support in Virtualmin is implemented. Most of the code doesn't need to care what kind of webserver is in use, as long as its implementation provides a way to setup a virtual host, an alias, PHP, etc. In theory anyone could write a new VIrtualmin plugin that adds support for another web server type.

However, we don't yet support migration from Nginx to Apache and vice-versa, as there is no way to preserve any custom config directives that each server might have for a domain.

okay, I see - thanks for clarifying. What could be done then would be checking if the vhosts are making use of custom/unsupported directives, and only support migrations if that's not the case ?

I suppose one thing we could do when restoring a backup onto a system that uses a different web server type is to just use the default Nginx/Apache configuration. I suspect that this would work in 99% of cases.

is there some form of boolean lookup matrix/table to determine enabled/disabled features in a server agnostic fashion, so that vmin could detect required/missing features and suggest to enable those if required ?

Either way, sounds like a good idea - I would just add a big bold note saying that this is a generic feature and that it doesn't handle any highly customized setups that may require special attention.

For the sake of simplicity I would also suggest to add a list of sanity checking callbacks that are executed first, so that features that are known to to be problematic could be detected that way.

Yeah, some "generic" features like the PHP version or webserver aliases could be converted.

I have never seen an error message by sites running under Apache. On the contrary, I have seen a handful of sites running under NGINX servers spitting out web server messages. So it's not as great as advertised.

Can Cloudmin host MS Windows virtual machines?

Yes, you can run Windows on a Virtual Machine managed by Cloudmin.

There are a few limitations that you would see, that you wouldn't have with Linux. For example -- there aren't existing Cloudmin images for Windows.

And there's some management functions that can be performed on Linux that won't work on Windows.

But it will certainly work -- you can install Windows into the Virtual Machine, and Cloudmin can manage that VM.

Yeah, some "generic" features like the PHP version or webserver aliases could be converted.

The docs specifically say not to migrate a running apache/vhost configuration, so how about making this more eplicit and adding an option to the "first time setup" to allow the user to decide between using apache/nginx for virtualmin hosting?

Also, prior to creating even just a single vhost in virtualmin, there should be a big red warning pointing out that migrating things between nginx/apache is going to be tricky and require lots of expertise, as it isn't currently automated.

http://www.virtualmin.com/documentation/web/nginx

This says it's been updated in 2011, but there are some more recent tutorials on installing nginx and virtualmin, it may be worthwhile to review those or at least link to them on that page: