Question about Cloudmin and Virtualmin. Also suggestions for alternatives.

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?

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.

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.

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:

• http://www.curvve.com/blog/guides/2013/guide-to-setup-virtualmin-with-ng...
• http://lowendtalk.com/discussion/9659/centos-openvz-with-apache-nginx-my...
• http://88plug.com/perfect-server-in-5-minutes-virtualmin-nginx-profitbricks