[toc]
Can I run each service on a different machine?
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. Cloudmin also has the ability to automate this process across Virtualmin servers.
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, and replication, of Virtualmin servers is available in our Cloudmin product, which also provides management of virtualized systems.
See also: Combining Virtualmin and LDAP
When using Install Scripts in Virtualmin Pro, and there is a security update for a web application, how can I update to that newer version before the next Virtualmin version is released?
Each Virtualmin Pro version contains the most recent of all the Install Scripts. But if there is a security update for a web application, it's not always desirable to wait for a Virtualmin Pro release to update to perform the security update for your web application.
To obtain the current version of Install Scripts, before they're released in Virtualmin Pro, you can go to System Settings -> Script Installers -> Installer Updates, and set "Download script updates" to "Yes".
Should I use a 32 bit or 64 bit Operating System?
It depends :-)
Processes running on a 64 bit system require more RAM; in many cases it may be twice as much RAM as on a 32 bit server.
If your server is at all memory constrained, you may really want to use a 32 bit operating system. We certainly wouldn't recommend going 64 bit with less than 3-4GB of RAM.
The benefit of a 64 bit operating system is that many tasks do run faster.
In December of 2009, the folks over at Phoronix put together some benchmarks using Ubuntu, comparing 32 bit, 32 bit PAE, and 64 bit architectures. You can see their results here:
http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
Their summary is:
By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel.
If RAM is plentiful, then running a 64 bit operating system on your server may be worthwhile.
Why Is 32bit Perl installed on my 64bit CentOS System?
We've seen some folks receive errors such as these when performing a yum update:
Transaction Check Error:
file /usr/lib/perl5/5.8.8/CGI.pm from install of perl-5.8.8-32.el5_7.6.x86_64 conflicts with file from package perl-5.8.8-32.el5_6.3.i386
The problem is that the distribution is 64 bit, but the version of Perl installed is 32 bit. However, some package is asking yum to pull down the 64 bit version of Perl, and that's causing the conflict seen here.
Karanbir Singh, one of the CentOS developers, describes the issue in this blog post:
http://www.karan.org/blog/index.php/2010/06/17/why-is-there-a-perl-i386-...
The fix is simple though -- you can run these two commands:
yum remove perl.i386
yum install perl
That will remove the 32 bit Perl version, and install the correct 64 bit version.
If you continue to see a problem with 64 bit CentOS trying to pull in 32 bit packages, it means one of two things:
Your system has 32 bit packages on it already that are generating dependencies for other 32 bit packages.
The CentOS mirrors you are using have a mix of 32 bit and 64 bit packages in the repository.
To test whether you have 32 bit packages installed, you can use this command:
rpm -qa --qf "%{n}-%{arch}\n" | grep -v noarch | grep -v x86_64
Why do my PHP pages download or display the source, rather than executing the PHP code?
If you're seeing this issue, it's likely that a newly installed PHP version setup some Apache configuration options that's overriding your Virtualmin PHP settings.
It's a simple fix though, you just need to find the offending configuration and comment it out. The configuration to look for are "SetHandler" lines -- those can be found using the following:
On CentOSfind /etc/httpd -type f | xargs grep -i sethandler
find /etc/apache2 -type f | xargs grep -i sethandler
Look for any lines like the following:
SetHandler application/x-httpd-php
There could be more than one -- comment them all out, and then restart Apache.
And then comment that out, and restart Apache using the command service httpd restart on CentOS or service apache2 restart on Ubuntu/Debian.