System Configuration and Maintenance Frequently Asked Questions

Posted 2010-07-03 16:39 by Joe

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:

  1. Your system has 32 bit packages on it already that are generating dependencies for other 32 bit packages.

  2. 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 does PHP / ProFTPd no longer work after performing updates? (I'm using CentOS, and enabled third party repositories)

Many of the third party repositories for CentOS are known to have packages that cause problems on Virtualmin systems.

We highly recommend against using any third party repositories, as you are very likely to run into problems that are unusual, and in some cases, difficult to resolve.

If you must use a package from a third party repository, we recommend just using the package that you need, rather than globally enabling that repository. By enabling a third party repository, your system will begin pulling in packages from it during system updates, and that can cause mysterious things to occur.

One way to pull in just the packages you need is to use the includepkgs line in the repository's .repo file, which allows you to specify which packages to use from that repository. How to use that is documented in the yum.conf manpage.

If you choose to use one or more packages from a third party repository, please fully test it on a test server, before installing it on your live server.

If you've enabled a third party repository, and have a ProFTPd version installed from that repository -- we've seen many cases where FTP logins stop working.

If you're seeing that issue -- the simplest fix is to first disable that third party repository, remove the current proftpd package that's installed, and then to install the ProFTPd version from the Virtualmin repository (which, once the third party repository is disabled, can be done by simply running yum install proftpd).

If you've enabled a third party repository, and PHP has stopped functioning -- that's because many third party PHP versions install a config file that conflicts with the Apache/PHP setup you have.

The issue is typically the result of a SetHandler line being added into one of the .conf files in /etc/httpd/conf.d -- often in the file php.conf.

What you'd want to do is find the SetHandler line in that file which defines what to do with ".php" files... it would look something like this:

SetHandler application/x-httpd-php

And then comment that out, and restart Apache using the command "/etc/init.d/httpd restart".