For the new website the Virtualmin FAQ has been divided into categories:
[Virtualmin Installation FAQ](/documentation/installation/faq)
[Virtualmin Email FAQ](/documentation/email/faq)
[Virtualmin Web Service FAQ](/documentation/web/faq)
[Virtualmin DNS FAQ](/documentation/dns/faq)
[Virtualmin Accounts and Users FAQ](/documentation/users/faq)
Webmin also has a FAQ:
It's easy: There are no special steps. Just install the product onto the new machine, and shut down (or remove Virtualmin Professional from) the old system within 30 days. We try very hard to keep our license management out of your way, and if you ever see it or find that it prevents you from doing something you want to do while using our products in good faith, it's probably a bug and we'll fix it.
Are users able to create subdomains, and can users own multiple domains and manage them from the same interface?
Yes. When creating a new domain, you may choose for the domain to be owned by any existing domain user. If an existing user is selected, they will then see the new domain alongside their original domain when logged in as that domain owner. There is no limit (outside of the domain limits imposed by your licensing terms) to the number of domains that may be owned by a user.
Virtualmin also supports reseller accounts, which have a "root-like" Virtualmin interface and they can manage all of the domains that they create using the Virtualmin module. This type of user is special in that they can see all of the domains they create, and they can create domains that are owned by the domain owner accounts they have already created. It is very flexible and powerful. It integrates cleanly with the Webmin ACL system, so if you have particularly complicated requirements you may find that Virtualmin is the only tool of its kind that allows you the flexibility you need.
Yes. Virtualmin provides both a local command-line based API and a remote HTTP request based API. Both Virtualmin Professional and Virtualmin GPL offer create, list, update, delete functionality for virtual servers and users, while Virtualmin Professional includes access to every function within the UI via both APIs.
It is also worth noting that Virtualmin inherits the extensive RPC capabilities of Webmin, so someone with experience programming Webmin modules and using the RPC interface could create a master-slave system to drive any number of Virtualmin servers from a single machine (for example, your billing and accounting server).
As more third parties begin writing applications for Virtualmin, we expect all of the APIs to mature further.
Certainly. When creating a virtual server, simply check the box labeled "Setup SSL website too?" in the "Enabled Features" section of the form, and in the "IP address and forwarding" section provide a new IP address for this virtual server to reside on.
A virtual server with SSL requires a dedicated IP address, as the HTTPS protocol does not support name-based hosts and serves the certificate and negotiates the encryption before the hostname is known, based entirely on the IP address being connected on.
While BIND must run on the Virtualmin server, it does not have to be publically accessible and you can use the Webmin:Servers:BIND DNS Server:Cluster Slave Servers feature to sync up any number of slave servers to your master Virtualmin server automatically. You can then firewall your Virtualmin servers name server port from all clients except the slaves, and your Virtualmin name server will be lightweight (because it doesn't work very hard) and extremely secure (because no one can talk to it except your slave name servers).
Yes for some services, no for others.
It is possible to use LDAP for mail user configuration, though this is not a comprehensive solution. Many of the features of Virtualmin can be re-implemented manually on the mail server, using Webmin and Usermin, but per-domain spam/AV configuration is not possible in this setup. The other option is to use Virtualmins ability to run commands before or after creation/update/delete of user accounts. One could write a custom command that makes use of ssh to perform actions on a remote mail server. Finally, a combination of Webmin user synchronization and a shared Postfix configuration directory would allow for configuration to occur on both servers. In this last case, a wrapper script would have to be written to allow Postfix to be stopped/started/restarted on the remote machine. Distributed mail support is high on our todo list, and should be available in the near future. So, if you don't need this capability urgently, waiting until it is fully supported by Virtualmin is strongly recommended.
Virtualmin does provide excellent support for automatic secondary mail server configuration, which sets up and manages a secondary mail relay that can step in and hold mail in the event the primary is unavailable. This is often the best method of provided redundancy for mail services, though it does not provide mail retrieval or MTA services for your users while the primary MTA is unavailable.
Database servers can be run on other hosts, and Virtualmin supports this fully. To make use of this feature, use the relevant Webmin module (MySQL and/or PostgreSQL) Module Config to configure it to connect to a remote database instead of a local one. All functions, except starting and stopping, are supported on remote database servers.
Web service must currently be on the Virtualmin server, and this is unlikely to change in the very near future. Replication of web content for use on a "hot spare" is relatively trivial using the remote virtual server backup feature, though restoring the backup periodically would need to be implemented using the command line API on the receiving server.
Spam and AV scanning can be run on the local machine or on a remote machine. Setting up the daemons on other hosts is not automated, though it can mostly be done within Webmin, if you like having a UI. Some customers choose to run a single dedicated mail proxy for spam and AV scanning, and then relay mail to the specific Virtualmin servers for the correct domains. This would be relatively easy to automate, using the pre/post commands feature in Virtualmin.
In short, DNS and both databases are very easy to setup on other hosts and well-supported by Virtualmin and Webmin, while everything else is either unsupported, incomplete, or not easy to setup. As the popularity of Virtualmin in larger hosting providers has increased, the demand for these kinds of features has increased remarkably, and we've begun focusing on this aspect of the system. Almost all major new features for the foreseeable future will be related to addressing scalability issues.
Central management of many Virtualmin servers is available in our VM2 (Virtualmin Machine Manager) product, which also provides management of virtualized systems.
See also: Combining Virtualmin and LDAP
Choose the domain name of your server from the pull-down menu
Click "Edit Mail Aliases"
Click "Add an alias to this domain"
Set "Name" to "All mailboxes"
Fill in the delivery settings as usual (a local mailbox, usually).
Click "Bounce mail?" if you want to use this catch-all email account to bounce inbound emails with invalid email addresses.
To "turn off" the automatic email bouncing, simply delete this catch-all email alias.
It's a bad idea, according to Wietse Venema in this post on the Postfix mailing list: http://archives.neohapsis.com/archives/postfix/2000-02/0892.html
Virtualmin has several clever hacks to workaround this particular feature of Postfix, revolving around the creation of a second user with the same UID and paths, which Postfix can deliver to. This has many potential problems and might confuse other software that isn't smart enough to deal with multiple usernames with the same UID (this is perfectly legitimate, and ought to work, but it is a common failing and even some of our stuff has had some bugs uncovered, but now fixed, by this hack).
On recent operating systems (Fedora Core 5+, CentOS 5, and Debian 4.0 are all confirmed to have this issue) the Cyrus saslauthd version defaults to dropping the "@domain.tld" portion of the username before attempting authentication. This, obviously, won't work. The solution is to add the "-r" flag to the saslauthd command. On Red Hat based systems, additional flags can be added in the "FLAGS=" section of the file /etc/sysconfig/saslauthd. On Debian-based systems, the file to edit is /etc/default/saslauthd and the directive to modify is "PARAMS=". This is an orthogonal issue to the Postfix issues, and will occur whether you use Sendmail or Postfix as your mail server.
We don't recommend using @ in the username for mailbox users (for the same reasons that Wietse removed support for them in Postfix), but if you must it can be done. Any problems you run into should be brought up in the Bug Tracker, so we can get them resolved. Just because it's a hack doesn't mean we won't make it work as well as any othe naming convention.
Also note that this trick is incompatible with mbox style mail spools (because mail will be delivered to the "wrong" mailbox: user-domain.tld, instead of email@example.com). Maildir format mail spools are not subject to this problem, and are the default in Virtualmin if you have used our automated installation script.
If you really do want to use this type of username, edit the Server Template(s) for which you'd like this type of username. Browse to the "Mail for domain" section (select it in the dropdown, if using the Virtualmin theme, or scroll to this section if using any non-menu-ized theme). Find the option labeled "Format for usernames that include domain", and select "user@domain", and save your changes.
Virtualmin supports a couple of methods of "previewing" a site before the DNS stuff is pointing to the right place, though only one is available by default.
There is also the universal method within Apache (which is probably what you're used to seeing if you've used other virtual host administration tools), which is discouraged by the Apache developers as it is potentially a security issue. How large a security issue is debatable and depends on the environment, but we trust the Apache folks to know their own software and what is and isn't a good default, so we don't enable it by default. Those issues are increased exponentially by allowing CGI/PHP scripts to run in this way, and I would strongly discourage allowing executables at all in this way.
To switch your Virtualmin server to behaving the way you're used to, you just need to turn it on in Apache (but read to the end of this entry before turning it on, we provide better options). Here's how:
Browse to the Apache Webmin module.
Click on the Default virtual server (just be sure you know what your default Domain is so you can point folks to the right place).
Click on the Automatic Virtual Hosts icon.
Switch the radio button by Automatic virtual host root to the one beside the empty field, and fill in the field with, /home/%0/public_html. Note that if you've configured Virtualmin to create domains with a different path convention (e.g. "/home/a/abc") things get more complicated and you'll need to construct a path using the variables documented here:
There are other, better, methods of providing preview access and Virtualmin provides easy ways to do them.
The default method is simply to allow access through Webmin as a proxy. In Virtualmin Professional there is always a link labelled "View Website via Webmin" in the left menu pane. Clicking this will allow you to see the front page of your site (and if you use relative links, all other bits of your site), but only to authenticated users. Obviously, this is extremely secure compared to the automatic virtual hosts method, and allows you to test your site before switching DNS. If you just need your domain owner to be able to see their site working before switching DNS, use this option. Note that this has the requirement of the local machine being its own DNS server, as otherwise Webmin itself will get the old DNS information.
Another way, which I believe is the best option (saving the best for last!) and most closely matches what you're currently used to without the security implications, is the Automatically create alias domain option (found in every Server Template, though to keep it simple you can just edit the Default template). Just select the radio button beside "Create under" and fill in the domain under which you'd like all of your customer domains to appear.
This option will cause Virtualmin to create a subdomain under your domain for every new domain you create--this will be immediately accessible with a name like "newdomain.mydomain.tld". Easy to remember for the user (because it's their domain name, plus the name of the company they're hosting with), and it isn't a path-based automatic thing, so non-virtual host home directories won't be potentially exposed in any way, as with the Automatic virtual hosts method above (as used by Ensim, cPanel, and others, I reckon). If you need public access to sites, this is the method you really want. Note that this method also does not break SuExec, as the automatic hosts option does, so CGI scripts (and PHP once we get FastCGI+SuExec working) will run as the user that owns the domain...this is safer.
When I installed Virtualmin Professional, an old version of MySQL|PHP|Apache|dovecot|etc. was installed. What's going on?
We respect your OS decision. When you chose an OS, you also chose a set of packages that has been tested by a reasonably large company or set of volunteers to work well together. It can be expected, with reasonable confidence, to perform as it should with minimal stability issues and minimal compatibility issues during upgrades. More importantly, you can expect that security issues with your software will be resolved quickly and in a form that can be installed without disrupting the services provided by your system.
It would be the height of presumption for us to assume we know your requirements better than you do, and so we do not randomly upgrade components of your system with our preferred versions. In a few cases, we are forced to replace packages with our own (like Apache), or provide packages that are not provided by the OS (Dovecot and ProFTPd fall into this category on a few platforms), but when we do, we try to make our package compliant to the packaging guidelines of your OS. When replacing an OS-provided package, we base ours on the OS-provided package, so that it is a drop-in replacement with only the changes we need.
This policy is firmly held, because to do anything else is to invite serious compatibility, stability, and security issues in the near and distant future.
Occasionally, there is a package that is so strongly desired by our customers in a different version and it is possible to provide it in a form that can exist peacefully along-side the one provided by the OS, that we will provide the extra version. The only current example of this is PHP. As of EA2 of the installer, Virtualmin Professional will install PHP4 and PHP5 side by side on all supported operating systems, and will provide a simple mechanism for users and administrators and Script Installers to choose the PHP version needed for each specific application. This will be a rare instance, but it will happen occasionally.
In short, if you want very new versions of components, choose a bleeding edge OS distribution (like Fedora Core). Or, alternately, you may install the updated packages yourself from other sources. MySQL 5, for example, is reported to work fine with Virtualmin when installed from the packages provided by the MySQL folks, as long as the configuration of the Webmin MySQL module is updated to reflect the new locations. We are happy to help you get the configuration right in the forums or in the customer issue tracker, if you have any problems making it work. Virtualmin itself is version agnostic, as is Webmin, and so you may generally assume that if you install a newer version of some component that Virtualmin will have no major problems configuring it. If you do find problems, please file a bug, and we'll correct them as quickly as possible.
Some operating systems offer alternative software repositories that break version conventions in order to provide packages that change frequently, like clamav and spamassassin. Debian, in particular, has a well-maintained repository called "volatile" for the latest versions of these packages. Note, however, that clamav has a rather difficult history when it comes to compatibility between versions. Upgrading through major revisions of clamav is likely to require configuration file updates that may or may not be automatically handled by the package.
Yes! We actively seek out development partners in the virtual host and ISP billing market. So far, the following billing systems support Virtualmin Professional:
Note that we haven't tested any of these systems with Virtualmin yet. Please try them out before making major deployment decisions.
If your favorite billing system is not supported, have the developers contact us. We'll work with them to get their system working with ours. We provide a full-featured command-line and remote API to make integration with any billing system that supports provisioning reasonably easy (but it's generally best if the billing app provider does the development, since it will be their application calling ours). If you happen to be a billing systems developer, here's the API docs you'll need: