Are Cyrus or Courier mail users supported by Virtualmin?

Written by Joe Cooper
No, but Qmail+LDAP and VPopMail are, as of version 2.50, if you insist on not having a system user for every mailbox. Postfix can also be configured to use LDAP users rather than local users.

Note that by default Virtualmin uses system users for every email account. This was by design, as it suited our plans for using Webmin and Usermin as parts of a tightly integrated comprehensive system, rather than having Virtualmin stand alone. While there are some advantages to database-backed email systems, and mail retrieval systems with more advanced virtual hosting support, it didn't seem worth the loss of complete integration of users, domain owners, and administrators under a single family of consistent tools.

The Virtualmin Professional installer configures Maildir mail spools and Dovecot for POP and IMAP support. Maildir is known to be faster for very demanding mail workloads, and Dovecot is considered among the fastest and most secure POP/IMAP servers available. We can't be sure that this combination is fast enough for all environments, but we do have some pretty good usage data to indicate that it easily scales to hundreds of mail users without performance or reliability problems. We welcome comments on how this configuration might be improved.

It is also worth noting that in the vast majority of modern mail environments, the limiting performance factor is the spam and virus scanning that is now required for a mailbox to be useful. SpamAssassin alone on mail servers that we have observed is responsible for more than 50% of CPU and memory used for mail services. There is very little to be done about this, short of choosing a different spam preventative system. ClamAV is not quite as resource intensive, but still takes much more resources than either the delivery agent or the retrieval process.

Are there any billing systems that work with Virtualmin Professional?

Written by Joe Cooper
Yes! We actively seek out development partners in the virtual host and ISP billing market. So far, the following billing systems support Virtualmin Professional:

AWBS

Money4u is a new entry, still in development.

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 without 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:

Command Line API

Remote API

 

Are users able to create subdomains, and can users own multiple domains and manage them from the same interface?

Written by Joe Cooper
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.

Can I create accounts using my own Perl|Python|Ruby|PHP|Bash|Tcl|Expect|etc. scripts or programs?

Written by Joe Cooper
Probably. Both the Perl and command line interfaces to Virtualmin have been markedly improved in Virtualmin Professional, and a remote HTTP API has been introduced. A primary motivation for the establishment of the new Virtualmin.com community site is to foster third-party application development that leverages the features of Virtualmin. We honestly want to help you integrate Virtualmin into your environment, and if you don't find the access you need in the current APIs, we want to know about it.

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). In V irtualmin Professional there is a safe and simple HTTP-based API that mirrors the CLI interface, allowing for easy integration of other applications with Virtualmin.

As more third parties begin writing applications for Virtualmin, we expect all of the APIs to mature further.

Can I create an SSL virtual host with Virtualmin?

Written by Joe Cooper
Of course! Just make sure you have a spare IP to give it. SSL virtual hosts must have a dedicated IP address.

Can I run DNS on another machine?

Written by Joe Cooper
Yes and no.

While BIND must run on the Virtualmin server, it does not have to be publically accessible and you can use the Webmin 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).

Can I run each service on a different machine?

Written by Joe Cooper
Yes for some services, no for others.

There are a few incomplete, but possibly workable for some environments, options for running mail service on another server. 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 Virtualmin's 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's 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.

Spam and AV scanning, as we currently configure it, must run on the local host. It would be possible to set them up on a remote server and configure Postfix to use outside filters or configure procmail to process using a scanner that is capable of remote filters. This is also not ideal at this time, and running spam/AV on the same host as mail is strongly recommended.

In short, DNS and both databases are 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.

Can I uninstall Virtualmin without leaving a smoking pile of wreckage?

Written by Joe Cooper
Yes. Unlike some other virtual host administration systems, Virtualmin is predominantly non-destructive. By necessity, the installer installs several new packages and modifies the configuration of some system services. But, it is possible to uninstall Virtualmin and continue using the server without Virtualmin or Webmin installed. In fact, if you decide that you no longer need to use Virtualmin after your license expires, you can remove it from your system and continue to use all of the domains that were configured without the GUI. Try that with another virtual host administration system!

A few of the things that we modify during installation:

Apache is replaced with a custom version that includes SuExec support for home directory files.

ProFTPD is installed, replacing any other FTP server that may be installed.

Dovecot is installed, replacing any other POP/IMAP server that may be installed.

Postfix is installed. On systems that support alternatives, it will not replace any existing mail server, but it will disable other mail servers.

SpamAssassin is installed.

ClamAV is installed.

Webalizer is installed.

MySQL and PostgreSQL are installed and configured.

A few configuration changes are made to the Postfix main.cf, Apache httpd.conf, Webalizer webalizer.conf, and the databases are initialized. Several perl modules are also installed to enable SSL connections to Webmin and Usermin, and make the database modules more powerful and efficient.

Most of the software is installed from OS standard packages, and the installer simply sets them up appropriately for virtual hosting on a large scale. The things the installer does are likely things you would have done anyway on a hosting box, so the differences are non-intrusive.

To sum up and repeat: It is safe to uninstall (and reinstall, if you regret your decision, though you'd better have a backup of the Webmin configuration files handy) Virtualmin and keep using the system without it. Whether you can install another virtual host administration system on top of a Virtualmin configured system is unknown to us, but it is not recommended until someone tries it on a non-production system and reports the results. Like Webmin, Virtualmin strives to be friendly to other administration tools, including the command line and your favorite text editor. Whether other tools are friendly to Virtualmin and Webmin is wholly unknown, but not expected.

Can my users automatically install CGI scripts using Virtualmin, like Fantastico for cPanel?

Written by Joe Cooper
Yes. This was one of the things that kept coming up in our discussions with hosting providers who use cPanel: they love Fantastico. So we replicated the functionality. Even better, it has the ability for users and third parties to provide their own installers. So, if you have a script you'd like to provide to your users, you can write or have us or another third party write an installer for you and you then just drop it into your Virtualmin instance. It will show up just like the rest of the installers. It's very cool. You can also disable some scripts for for whatever reason...i.e. if it is a resource hog, or you don't like getting questions about a particularly buggy script. The Script Installer is all new in Virtualmin Professional, and included at no extra cost. The installer API is available for third parties to provide additional script installers, and we encourage others to do so, either for sale or for free use by others, or as a means to improve the ease of use of your own commercial or Open Source CGI scripts.

Can Virtualmin be secured with SSL?

Written by Joe Cooper
Of course! Virtualmin runs under Webmin, which supports a wide range of security features, including SSL encrypted connections. For a rundown of Webmin security features, have a look at the security section in either of the Webmin books (both can be read here at Virtualmin.com for free).

Does Virtualmin notify the administrator of necessary updates, for security or enhancement reasons?

Written by Joe Cooper
On systems that support it, Virtualmin includes a Security Updates module that will display a list of available updates on the system information page, whenever such updates are available.  Virtualmin also includes the Webmin Software Packages module, which offers a GUI for yum, up2date, urpmi, and apt-get.

Does Virtualmin take care of the installation of all necessary software or give you the option to do so? i.e. Postfix, Spamassassin, an IMAP/POP3 server, Apache, PHP, etc.

Written by Joe Cooper
Yes. The Virtualmin Professional installer installs all of the necessary components and pre-configures them for use. After a Virtualmin Professional installation every feature in Virtualmin should Just Work. If you find that it does not on your system, please report it in the Bug Tracker here at Virtualmin.com.

How do I make domains available before the DNS changes are made at the registrar? Or, how do I make a users website available at "http://www.mydomain.tld/customerdomain"?

Written by Joe Cooper
Virtualmin supports a couple of methods of "previewing" a site before the DNS stuff it 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:

http://httpd.apache.org/docs/1.3/mod/mod_vhost_alias.html

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.

How do I move a license to a new system?

Written by Joe Cooper
It's easy: There are no special steps. Just install the product onto the new machine, and shut down (or remove Virtualmin 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.

How do I setup SMTP authentication for sending mail through my hosting server?

Written by Joe Cooper
As of the beginning of March, this is enabled during installation. If you installed prior to that, you can enable it with the following steps:

You need the cyrus-sasl package, so run:

yum install cyrus-sasl

Or, on SUSE:

yast -i cyrus-sasl

You can also install software using the Software Packages module, but it's quicker to use commands when we know exactly what we're doing.

Set it up to run on boot:

chkconfig --level 345 saslauthd on

This step can also be done in the Bootup and Shutdown module.

And then you need to setup Postfix to use it:

Browse to Servers:Postfix:Server Processes

Click the "smtp" process to edit it.

In the "Process command" field set it to:

smtpd -o smtpd_sasl_auth_enable=yes

Save it.

Browse to Servers:Postfix:SMTP Options

Edit the field labeled "Restrictions on recipient addresses"

Somewhere in the list of options (depending on what other stuff you're using, but before reject_unauth_destination and after permit_mynetwork) insert "permit_sasl_authenticated". The list of options should be "permit_mynetworks permit_sasl_authenticated reject_unauth_destination"

Save it.

Finally, we have to add three lines to /etc/postfix/main.cf (I'm having a hard time believing this isn't in Webmin, but I can't find it--this'll definitely get a bug filed):

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

This can probably come anywhere in the file (I believe the Postfix configuration is stateless). I always put it near the spam-filtering related stuff, like header_checks and such, as that seems the intuitive place for it to me.

Finally, run this on the command line or in the Command Shell module:

echo "mech_list: PLAIN LOGIN" >> /usr/lib/sasl2/smtpd.conf

This just adds a list of available authentication methods to the sasl configuration.

Save it, and restart postfix and start saslauthd.

service postfix restart
service saslauthd start

Test it with telnet (what you type is in bold):

[virtualmin@www ~]$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 www.virtualmin.com ESMTP Postfix
ehlo localhost
250-www.virtualmin.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 8BITMIME
quit

The two AUTH lines tell you it's working (there are two because we specified "broken_sasl_auth_clients=yes"). If you don't see'em then I forgot to mention a step.

How do I uninstall Virtualmin Professional?

Written by Joe Cooper
There is a simple and stupid script to remove all of the Virtualmin packages located here:

http://software.virtualmin.com/lib/virtualmin-uninstall.sh

It isn't terribly smart, and generates some errors on all systems (because it calls commands that only exist on some--these are harmless), but it does remove everything that we install during installation. It should not impact most domain services, so websites will continue to operate, and if you disable spam/AV filtering before uninstallation and remove all references to procmail-wrapper in the mail server configuration (replacing them with "procmail") mail will continue to work, but all Virtualmin data will be deleted!

This script should almost certainly not be used on production systems that you wish to keep in production. You can revert to the old Virtualmin GPL virtual-server module just by installing it over the Professional module, if you don't want to continue paying renewal fees each year. You'll lose all of the Virtualmin Professional features and support, but you'll be able to safely continue operation of your system and most services will continue to operate normally. Now that Virtualmin GPL and Professional share merged codebase, the two are mostly compatible.

How do I update using yast on SUSE 9.3?

Written by Joe Cooper
The package management features of yast on SUSE version 9.3 leave quite a lot to be desired (and version 10.0 is recommended, if you are deploying SUSE for this and a few other reasons). The most annoying of them is that yast does not auto-refresh its package sources, and so it will never find new versions of software in the Virtualmin repositories. The solution is to use y2pmsh to update the sources. The following simple script can be installed into your /etc/cron.daily directory to perform the refresh every day.

#!/bin/sh
y2pmsh source -s | grep -E '^[0-9]+:' | cut -f 1 -d : | while read n; do
    y2pmsh source --update "$n"
done

I setup a virtual domain under Virtualmin, and now it appears when I go to the "real" address of my webserver. What happened to my default website?

Written by Joe Cooper
This is just the way Apache does things (nothing to do with Virtualmin, in particular). An Apache either has VirtualHost style configuration, and the default is the first one configured, or you have just the default. If you don't want your "default" domain to be a Virtualmin domain, you can create it manually or using the Apache module and then move it into position in the configuration file manually (Webmin's Apache module probably also has a way to make it the default).

So, it's not really a "problem", just an aspect of the way Apache does virtual hosting. Either Apache serves one website no matter how it is contacted, or it serves up an unlimited number of domains based on the name being requested with the first one being a catch-all for anything that doesn't match.

Don't forget that you can also use ServerName and ServerAlias directives to make any VirtualHost appear pretty much anywhere you want.

I've read all of the FAQs, the warnings, and the forums discussions about how painful an upgrade from Virtualmin GPL to Virtualmin Professional using install.sh can be. I still want to upgrade my Virtualmin GPL system. How do I do it?

Written by Joe Cooper
Without install.sh! Just use the Upgrade to Virtualmin Professional feature in Virtualmin GPL. It will safely (usually, but you still need backups!) and quickly upgrade your system from GPL to Professional.

Is it possible to upgrade my GPL Virtualmin installation to Virtualmin Professional?

Written by Joe Cooper
Yes! Virtualmin GPL includes an Upgrade to Virtualmin Professional feature, allowing you to safely (mostly) upgrade your system quickly and easily. Running the install.sh to upgrade from Virtualmin GPL to Professional is deprecated and no longer recommended.

Is the GPL version still being maintained?

Written by Joe Cooper
Of course. Jamie and I (Joe) have been developing Open Source software for longer than most folks have known it existed. We enjoy it and will continue to do so. In fact, features found in Virtualmin Professional will often trickle down into Virtualmin GPL over time. Virtualmin GPL is by far the leading Open Source virtual host administration system, and we plan to keep it that way.

Is there an alternative to upgrading via install.sh and the steps in the previous FAQ and is it safer, better, faster, cleaner, more recommended?

Written by Joe Cooper
Yes, there is an alternative but it isn't well-documented yet, and whether it is better for you is hard to guess. There are just too many variables (the same reason the install.sh doesn't work well for every upgrade).

Here's the bits of documentation that exist:

Manual Installation

I will update it soon with more details, and install.sh will also get a minimal mode soon that will automate this type of installation.

To get back to the better/faster/whatever query: If you know your system is vastly different than what install.sh and virtualmin-base is going to configure, then don't run install.sh! Use the minimal installation and don't run the virtualmin-base-standalone.pl script either. If you just install the modules, you won't be touching any of the rest of your configuration--you'll just get the new features of Virtualmin Professional (minus per-user/per-domain spam/AV, and possibly a few other bits, though you can manually set them up later).

Is there some way to import existing virtual domains into Virtualmin?

Written by Joe Cooper
Yes, there is a quite nice mechanism in Virtualmin to import existing domains from Apache virtual host configuration (plus various other configurations), though it won't necessarily be able to recognize all of your decisions--there are so many possible ways to setup accounts, permissions, groups, mailboxes, etc. that figuring them all out in software is darned near impossible, though Virtualmin does a pretty good job in most environments. If your domains were setup similarly to the way Virtualmin sets them up, most everything will just work. The import form accepts a number of arguments when you are performing the import, as well, so if you know all of the specifics of the way your domains are configured you'll likely be able to get a complete import without much trouble. The import feature won't cause any changes to occur on your system, until you make changes using Virtualmin, so it is safe to try it on a single domain to see how well your accounts get imported. And if you run into problems, bring them up on the forums and we'll try to help. One thing you'll definitely want to do is be sure that all of your services are correctly configured in Webmin. If you have installed Apache, for example, in a different location than is the default for your OS, or if you have multiple instances, Virtualmin may not know where to go for information. Incorrect locations will probably get caught by the Virtualmin Check Configuration stage, but multiple instances might not. The button that does all of this is right on the front page and is labeled "Import Virtual Server". This feature exists in both Virtualmin GPL and Virtualmin Professional.

Script Installers keep saying I need PHP4 on my Fedora Core 4 or 5 system, what can I do?

Written by Joe Cooper
There will soon be a general method for resolving PHP version requirements on all platforms. When that is complete, Virtualmin will be able to select between PHP4 and PHP5 depending on the version needed.

In the meantime, it is possible to simply install PHP4 and disable PHP5. Scripts needing PHP5 features won't work, but those are extremely rare at this time, so it shouldn't be a major concern. Even after this change, you can still call PHP5 scripts using the CGI interface and they should work fine.

To install PHP4, use yum:

yum install php4 php4-pgsql php4-mysql

You may also choose to install some of the other php4 software. To see a list:

yum list php4*

You'll then need to disable PHP 5 by commenting out the directives that load the module and setup types and such, as well as uncommenting the same directives in the PHP 4 configuration file for Apache. The files are /etc/httpd/conf.d/php.conf, which should look like:

#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#

#LoadModule php5_module modules/libphp5.so

#
# Cause the PHP interpreter to handle files with a .php extension.
#
#AddHandler php5-script .php
#AddType text/html .php

#
# Add index.php to the list of files that will be served as directory
# indexes.
#
#DirectoryIndex index.php

#
# Uncomment the following line to allow PHP to pretty-print .phps
# files as PHP source code:
#
#AddType application/x-httpd-php-source .phps

And /etc/httpd/conf.d/php4.conf, which should looke like:

#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#

LoadModule php4_module modules/libphp4.so

#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddType application/x-httpd-php .php
# AddType application/x-httpd-php-source .phps

#
# Add index.php to the list of files that will be served as directory
# indexes.
#
DirectoryIndex index.php

And restart Apache:

service httpd restart

Should I install Webmin and Virtualmin GPL on my system before I install Virtualmin Professional?

Written by Joe Cooper
No! We'd strongly prefer you didn't, and we believe you'll have a better installation experience if you don't. The Virtualmin Professional installer will install and configure all of the necessary components for a virtual hosting system, including Webmin, Usermin and Virtualmin.

Upgrading an existing Virtualmin GPL system is supported, but things are bound to go wrong. Virtualmin GPL can be configured in so many different ways, with so many different components, that it is simply impossible for our installation script to get the upgrade to the Virtualmin Professional components right. We're working on ways to deal with this issue, but as long as Virtualmin supports so many possible configurations, upgrades from one set of components to another is going to be a major pain. If your Virtualmin GPL system looks identical to a default Virtualmin Professional system, then the upgrade will go relatively smoothly. Otherwise, something will probably break, and you'll probably have to get some help from us to help resolve the issues (we don't mind helping, but if you've got a system with no domains and you were just playing with GPL, save yourself some time and re-install the OS so you don't have to fix the upgrade).

A clean OS install is what the Virtualmin Professional install script likes to see. Anything else is just going to confuse the poor thing.

Virtualmin doesn't seem to be creating a group when I create a new domain account, but everything else looks right. What's going on?

Written by Joe Cooper
On some systems with nscd (SUSE, in particular) group information is cached and so it doesn't show up immediately. Since it doesn't make sense to have nscd running on a system with local user and group accounts, it is harmless to turn it off. This is the recommended solution to this problem. Use the Webmin System:Bootup and Shutdown module to disable nscd on boot and stop it immediately, and Virtualmin will begin to work correctly.

What is the difference between the Virtualmin GPL project and the Virtualmin commercial product?

Written by Joe Cooper
The differences between the Free and Open Source version and the proprietary version varies, as the Open Source project trails the development of the commercial product. Most features and improvements find their way back to the GPL Virtualmin eventually.

At any given time there are a few extra features, usually quite large ones, in the commercial product. Just as importantly, the commercial variant is supported, which has several important side effects: for the commercial version there are easy to install bundles that will pre-configure most of your system to work appropriately, documentation targets the commercial version, quality control is more stringent, support incidents can be opened regarding any problems you might have (only bugs are addressed in the Open Source version, questions must be directed to the forums or the mailing lists, where there is no guarantee of a complete or correct answer).

Another important difference is trademark usage rights. The Virtualmin mark is a registered trademark of Virtualmin, Inc. and can only be used by commercial users to refer to the commercial version of the software and according to our trademark usage guidelines.

What is the license of Virtualmin?

Written by Joe Cooper
There are two versions of Virtualmin, one of which is licensed under the GPL and the other which is under Copyright and subject to licensing terms. Virtualmin, Inc. is the developer of both versions (i.e. there is no fork or anything silly like that). Virtualmin Professional is not free or Open Source.

What's the deal with @ in mailbox usernames?

Written by Joe Cooper
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 very new operating systems (Fedora Core 5 is 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. 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.

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.

When I installed Virtualmin Professional, an old version of MySQL|PHP|Apache|dovecot|etc. was installed. What's going on?

Written by Joe Cooper
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.

When I try to run install.sh it bails after a short while with an error about missing package keys, what's going on?

Written by Joe Cooper
You've probably got one or more software repositories configured in yum other than ours and the OS standard repositories, one or more of those repositories provides a package that we need that has a higher version number than ours, and you don't have a key installed for the packages from those repositories. The possible solutions, in order of sanity, are:

• Disable all additional repositories, beyond the OS standard repositories. We've got no idea what repositories you're using or the quality of the packages within them. We also can't possibly test with packages from every repository under the sun. If you end up with a package different from ours for any of the components we rely on, you're increasing your risk of troubles remarkably, in addition to causing this particular install error. If you don't want to disable them permanently, that's fine too...just beware of potential conflicts between our packages and the packages from alternate sources. To reiterate: install.sh runs best on a fresh OS install (i.e. you haven't configured anything other than networking). This is one of those areas where there are too many possibilities for conflict for us to try to anticipate them all.
• Install the key for the offending package. You'll have to consult with the documentation or the maintainer of the repository in question to find out where to get the key, since we don't know. Our two keys are installed early in the install.sh run when the virtualmin-base package is installed. You should never need to manually install our keys.

Where can I download Virtualmin GPL? It's free, right?

Written by Joe Cooper
There are multiple ways to obtain Virtualmin GPL.

The easiest, if you will be installing onto a supported platform, is to use our automated install script downloadable from Virtualmin.com/download.html

You can also get Virtualmin, and all of its related modules and themes, from Webmin.com. Installation via this method can be time-consuming because there are many configuration steps needed in order to configure your system for virtual hosting use. The install script automates all of those steps.

Virtualmin GPL is free and usable under the terms of the GNU General Public License version 2.

Why can't I create a name-based FTP virtual host? Or, why do I need a dedicated IP for the domain to create an FTP virtual host?

Written by Joe Cooper
Because there is no room in the protocol for name-based FTP hosts. You almost certainly don't need one, anyway. You just think you do, and you're not alone in thinking so (it really is a frequently asked question). Virtual hosting FTP means that an anonymous user, i.e. one that has not logged in, can browse a specific directory based on the address they have connected to. Logged in users can login to any address they like (including the name of the virtual host that you're creating) and they will see their own home directory. The only time you need an FTP virtual host (which requires an IP) is when you must provide anonymous FTP access for a domain. In this web-ruled world we live in, almost nobody needs that.

Note that this is not a limitation of Virtualmin or Webmin. It is a limitation of the FTP protocol. There is nothing we can do about it, and there is no "fix" for it.

Why don't you add billing features to Virtualmin? I just need feature X, Y and Z. It would be easy!

Written by Joe Cooper
Billing is a much larger set of problems than it appears at first glance. To devote ourselves to billing would be to let the virtual host administration aspects of our product suffer.

Even a very simple PayPal-based billing system is a dramatically different set of problems from the ones we have set out to solve, and there are a dozen or more really good billing systems on the market, including a few Open Source ones. Our goal is to provide clean integration with all of them (or as many are willing to work with us to create that integration), so that users have a choice about which billing features they need. Billing is at least as large a problem set as the virtual host administration realm, and it is our belief that the products that try to do both (and there are a couple such products, if you really want to go that route) turn out vastly inferior in both areas when compared to the leading products in either space.

It's also worth noting that this is a very frequently asked question and the features X, Y and Z are different from one questioner to the next. By the time we addressed all of the "I just need" simple features, we would be developing and maintaining a full-featured billing system. We'd rather do one thing better than any other product on the market than do two things in a mediocre manner.