Backup and Restoration

• Backups and Restoration
  • Introduction to Domain Level Backups
  • Backup Destinations
  • Scheduling Backups
  • One-Off Backups
  • Restoring Virtual Servers
  • Backups By Domain Owners
  • Incremental Backups
  • Date-based Backups
  • Purging Old Backups
  • Using Backups to Transfer Virtual Servers
  • Backing Up Global Settings
  • Restoring Global Settings
  • Command Line Backup Tools
  • One Example Use Case

Backups and Restoration

Virtualmin provides multiple tools to help you keep good backups automatically. The first step after any installation of Virtualmin should probably be thinking about your backup procedures and setting up Virtualmin to automate those procedures for you.

Introduction to Domain Level Backups

The simplest way to backup your virtual servers is to use the backup feature built into the Virtualmin UI, which can save them to local or remote files domain by domain. This allows you to restore the state of an entire virtual server (including all databases, users and aliases), without effecting other parts of the system.

Each virtual server's backup is typically a single file in tar.gz format. This contains one or more files per Virtualmin feature that is included in the backup, such as the contents of databases, DNS records, Apache directives or the virtual server's home directory. It is also possible for a single backup file to contain multiple servers, although this format is generally not as easy to work with.

By default, only the master administrator (typically root or admin) can perform backups, but it is possible to grant backup and restore rights to resellers and domain owners too. Only the master admin can restore all virtual server settings though, as some (such as the Apache configuration) could harm other system functions if a corrupt or malicious backup was restored.

Backup Destinations

Before you can backup anything, you need to decide where your backups are going to be stored. The simplest destination is a directory on the system running Virtualmin, such as /backup, but clearly this isn't going to be useful if the whole system dies. If you do want to backup to local files, at least make sure they are on a different hard drive than the home containing your /home directory.

A better alternative is to backup to another system, perhaps owned by your or maybe provided by your colocation company. The backup files can be transferred either via FTP or SSH, depending on which protocol the destination system supports. Almost all Unix systems will allow SSH logins, but some network attached storage devices will only support FTP.

The final option is to use Amazon's S3 storage service, which charges you by the megabyte for data stored on their systems. This is probably the safest option as S3 presumably uses RAID and has backups of their own, but is more costly and slower to transfer backups to over the Internet. For more information about signing up for S3, see http://aws.amazon.com/s3 .

S3 uses slightly odd terminology to refer to files that they store - instead of directories, they have 'buckets', whose names must be unique across all S3 users. A backup can contain multiple files, such as individual domain backups, but cannot have sub-directories.

Scheduling Backups

The best way to have your system backed up is to have Virtualmin do it automatically on a regular schedule, such as once per day. The steps to set this up are :

1. Login to Virtualmin as the master administrator, typically root
2. Open the Backup and Restore category on the left menu, and click on Scheduled Backups
3. Click on the Add a new backup schedule link to open the backup creation form.
4. From the Servers to save menu, choose the domains that you want to backup. Selecting them all is generally the best bet.
5. In the Features and settings section, make sure Backup all features is selected.
6. In the Backup destination box, choose if you want to backup to a local file or a remote SSH or FTP server. For remote systems, you must enter the login details for the destination system.
7. If you want to save each domain to a separate file (recommended), the destination path must be an existing directory like /backup. For the Backup format, select One file per server.
8. In the Schedule and reporting section, enter your email address in the Email backup report to field.
9. Unless you want to get email every time a backup is done, check the Only send email on failure box.
10. In the Scheduled backup time section, select a schedule. I would recommend just choosing Daily (at midnight), but more complex times and dates can be chosen with the Complex schedule option.
11. Click the Create Schedule button.

Once this is done, your virtual servers will be safely backed up every night. To force an immediate backup for testing purposes, go to the Scheduled Backups page and click on the Backup link next to your new schedule.

One-Off Backups

Sometimes you just want to backup a few virtual servers to a different destination a single time, rather than one a regular schedule. To do this, click on the Backup Virtual Servers link on the left menu, and fill in the backup form as described above. When you click the Backup Now button then selected domains will be immediately backed up, and their progress displayed in your browser.

Restoring Virtual Servers

If a virtual server has been accidentally deleted, or lost files, database content or users, you can restore some or all of it's data from a backup. In the case where the whole domain is gone, Virtualmin will re-create it for you as part of the restore process.

The steps to restore a domain are :

1. Open the Backup and Restore category on the left menu, and click on Restore Backup
2. In the Restore source section, enter the local or remote path to restore from. If you are just restoring one server, it is best to enter the full path to it's backup file, like /backup/example.com.tar.gz
3. Under Features and settings, you can control if all attributes of the virtual server are restored (overwriting any that it currently has), or just some. For example, if you wanted to restore just the domain's databases, you could select Only those selected below and then check the box next to the MySQL feature. By default, everything will be restored.
4. Click the Show What Will Be Restored button at the bottom of the page.

After this step, the backup will be downloaded from it's source FTP or SSH server and a confirmation page displayed showing which domains and features will be restored. Be careful when restoring existing domains, as any aliases, databases or mailboxes that they have will be removed and replaced with those in the backup.

If everything looks OK, click the Restore Now to begin the restore process. As it runs, the progress of each domain and feature will be displayed by Virtualmin.

Backups By Domain Owners

Individual virtual server owners can backup their own top-level domains and sub-servers, if granted permission on the Edit Owner Limits page in the Allowed capabilities and features section. They can even be given the rights to run scheduled backups, although that right should not be granted to users you don't trust not to abuse it, as a large number of scheduled backups could overwhelm the system.

The UI for server owner backups is almost identical to that for the master administrator, with the exception that local backups can only be made to the .virtualmin-backup directory under their top-level server's home directory. There are no limits on remote FTP, SSH and S3 backups though.

When allowed, restored by domain owners are even more limited - to prevent configuration file corruption or hacking attempts by corrupt backups, only home directory and database contents can be restored. And local restores can only be from the .virtualmin-backup directory, not any file on the system.

Incremental Backups

If your system hosts virtual servers that contain a large amount of content in their home directories which does not change often (such as images, PDFs or video files), backing them up daily will be both slow and wasteful. Almost all the contents of each backup will be identical to the previous run, so most of the data transferred is not really necessary.

Fortunately, Virtualmin has a solution - incremental backups. These contain only files that have changed or been added since the last full (non-incremental) backup, and are thus much faster. Typically you should schedule a full backup for once a week, and an incremental backup for the same domains every night - but to a different directory.

Enabling incremental mode for a scheduled backup is as simple as changing the Backup level option to Incremental. This will only apply to home directory contents - Virtualmin does not support detection of incremental changes to databases, so if your virtual servers have a large amount of data in MySQL, the saving will probably be minimal.

When restoring, the latest full backup must be restored first, followed by the latest incremental. This ensures that all files are returned to their state at the time the incremental backup was made.

Date-based Backups

If you have enough disk space, keeping backups made over several days or months is a good idea, as it allows you to return virtual servers to their state before some disaster occurred, which may not have been immediately noticed. The standard way to do this in Virtualmin is to use a backup path that contains special tokens that vary based on the current date and time.

For example, the path /backup/%d-%m-%Y would be converted to /backup/16-09-2008 on 16th Semptember 2008. All tokens supported by the Unix strftime function can be used in backup paths, but the most useful are :

• %d - Day of the month, padded to 2 digits
• %m - Month of the year, padded to 2 digits
• %Y - Year, as a 4 digit number
• %H - Hour of the day, padded to 2 digits
• %M - Minute of the hour, 2 digits
• %a - The short weekday name, like Sat

To use these tokens in backup paths, you must check both the Do strftime-style time substitutions on file or directory name and Create destination directory boxes on the backup form.

Purging Old Backups

The only problem with keeping old backups around using date-based paths is the amount of disk space consumed. However, removing those older than some number of days is relatively easy to setup in Virtualmin. When creating or editing a scheduled backup, use the Delete old backups field to enter a maximum age in days before backups are removed.

This can only be used if your backup path contains date substitution tokens, like /backup/virtualmin-%d-%m-%Y. If not, Virtualmin will not be able to work out which files and directories are backups that it made in order to safely delete them.

In addition, I recommend against using the same directory to store backups made using other programs, as if their filenames are similar to Virtualmin backups they may be deleted as well if too old.

Using Backups to Transfer Virtual Servers

If you have more than one system running Virtualmin, backups and restores can be used to transfer domains between them easily. The restore process will even re-create the virtual servers on the target system, and adjust the backups to match the target's mailbox format, mail server, home directory base and other system-specific settings.

The steps to transfer a virtual server between systems are :

1. Create a backup on the source system containg the top-level server you want to transfer, and all sub-servers. The Include sub-servers checkbox on the backup form makes this easy.
2. Copy the backup file(s) across to the target system, if they weren't already transferred directly as part of the backup process.
3. Use the restore form to re-create the domains from the backup files. If you select them all at once, any top-level servers will be restored before sub-servers, and their heirarchy correctly preserved.
4. Update DNS entries or change nameservers at your registrar so that they new system serves the domains.
5. Verify that everything is working on the new system, paying particular attention to PHP applications that may have un-expected dependencies on the old system.
6. Delete the virtual servers from the source system.

While every effort is made in Virtualmin to convert backups as necessary when restoring on a system with a different configuration to the original, in some cases this cannot be done 100% correctly. For example, if the new system uses a different base for home directories (like /virtualmin instead of /home), paths in PHP, Python or Ruby application configuration files may no longer be correct.

For this reason, I recommend moving domains between systems running identical operating systems where possible, such as CentOS 5.2. However, the underlying CPU architecture, disk partitioning scheme or amount of RAM does not matter, so it is perfectly save to move domains between old and new hardware running the same OS.

Backing Up Global Settings

In addition to virtual servers, backups made by the master administrator can also contain Virtualmin settings that apply to the whole system, such as templates and custom fields. If you have created your own templates or heavily customized the module configuration, you should back these settings up too as follows :

1. Create a new scheduled backup, as described above.
2. In the Servers to save, choose the Only selected option but do not select any domains.
3. Under Features and settings, check all the boxes in the Virtualmin settings to also backup section. Or if you only want to save some global settings, just check the ones you want.
4. Select a backup destination as normal. This can either be a single tar.gz file which will contain all the global settings, or a directory. In the latter case, a file named virtualmin.tar.gz will be created in the target directory to store the global configuration backup.
5. Select a schedule, and click the Create Schedule button.

It is also possible to include global Virtualmin settings in your backups of virtual servers, by selecting the ones to include in the Virtualmin settings to also backup field.

Restoring Global Settings

The various global Virtualmin configuration settings can be restored in exactly the same way as you would restore domains. Just select the virtualmin.tar.gz file as the source to restore from, and in the Virtualmin settings to restore section check the types of global settings to include.

This can even be used to migrate templates, custom fields, script installers, content styles , resellers and email messages to a new system. Be careful when migrating the Module configuration though, as it may not be compatible with the new system if running a different operating system or Linux distribution. Instead, it is safer to configure the target the way you want it, then restore domains and possibly other global settings.

Command Line Backup Tools

If you prefer to work at the command line, backups and restores can be done using the tools listed on the Backup and Restore API page. These allow you to create your own scripts for backing up on complex schedules, emailing backups to somewhere, using rsync to transfer home directory contents, or whatever you can come up with.

One Example Use Case

Here's what we do at Virtualmin.com:

Weekly full backup, and daily incremental backup, using the Webmin:System:Filesystem Backup module. This insures we have a copy of everything on the system, in the event of a problem. Keep in mind that this is a filesystem dump, using the dump command by default (though tar is also an option), so it won't jump file systems. If you have multiple partitions, you'll need to make a backup of each. It takes two scheduled backups to get weekly full and daily incremental backups.

Daily backups of all virtual servers on the system using Virtualmin's Backup feature. We do a full backup, including Virtualmin meta-data and Webmin stuff, but if the data will be moving over a slow pipe, you may consider using the incremental backup feature.

If we had a problem that required a restoration, here's what I'd do, assuming it is one of my remote systems, rather than in a local data center:

Get a new system running whatever OS I had before (though I might be tempted to upgrade during the process...I'd have to assume that would take longer to get back in service).

Install Virtualmin.

Restore the virtual server backups from the Virtualmin backups. Test. If something is broken (because of customizations I did outside of Virtualmin to non-Virtualmin related services), install the necessary packages (assuming I installed everything from packages, as I generally do), and restore the configuration (if necessary) by selectively pulling stuff out of the filesystem dump...or creating a whole new filesystem and restoring the dump completely into it, if I thought I'd be doing a lot of this (since restoring single files from a dump is somewhat time-consuming).

If it were a local system, and I'd replaced the disk, or something, I would do something pretty dramatically different:

Boot from a rescue disk for the OS in question (don't go newer, as you might get slightly incompatible Ext3 filesystem versions--Fedora, in particular, makes use of new attributes that confuse older kernels).

Create the necessary filesystems (swap and /, probably, though you might also have /home), and restore the dump directly into /. This will completely restore your machine exactly as it was before the catastrophe. This is probably faster than the above method--unless you happen to have a machine laying around with a fresh OS install of exactly the right kind and version you can start with--and will get you a system identical to the previous one.

There is one quirk to be aware of in this latter case:

Backups of databases in a dumped filesystem are almost certainly not trustworthy, unless you shut down your database during the dump. So, you'll still need to plan to restore databases from the dumps found in your Virtualmin backups, which use the database dump feature to dump a safe and sane text file that can reproduce the database exactly as it was at the time of the backup.

Obviously, you want to test your backups occasionally to be sure they are working correctly and can be restored.

Bleeding Edge Package Repositories

Virtualmin Bleeding Edge Packages

Virtualmin, Inc. provides a set of yum repositories for CentOS/RHEL 5 that includes bleeding edge versions of several common web service related packages, including PHP.

We do not recommend using third party packages, including ours, unless you must have the bleeding edge versions of the provided packages. They are very likely not as stable or reliable as packages provided by the RHEL OS repository.

We get a lot of support queries, several per week, about third party repositories that are incompatible with the OS-standard packages, causing breakage in various ways. Thus, we're providing these packages which are known not to cause those kinds of issues. While we test and support these packages as best we can, and we use them on our own servers, they are still bleeding edge packages with dramatically less testing than standard CentOS/RHEL packages, however, and should be treated accordingly.

In short, if you don't need a newer version than what comes with CentOS, we recommend you stick with the standard package. If you do need a newer version, we recommend you use our packages rather than those from other third party repositories. We are not suggesting that any specific third party repository is poor quality, or poorly maintained. Merely that there are many subtle differences in the way various maintainers package things, and those small differences can cause hard to diagnose issues. We, obviously, also cannot support packages not provided by us. We have no control over them, and thus cannot fix bugs, and we don't use them and so we don't know anything about them. Issues relating to third party packages will generally be closed with little to no comment, as there's nothing we can do to help.

You can use the yum includepkgs options to select which packages you wish to use from these repositories. We recommend you do this to only use the packages you really need to be bleeding edge versions. New packages will be rolled into this repository occasionally, and it could potentially be a rude surprise to have your MySQL or Ruby or other major package upgraded without proper planning. I cannot stress this strongly enough. Use only the packages you must have from the bleeding edge repository, and choose those packages explicitly in your virtualmin-bleed.repo file.

For example, if you are simply looking to use the PHP packages from this repository, you can edit /etc/yum.repos.d/virtualmin-bleed.repo, and add a line which looks like this:

includepkgs=php*

That tells yum to only pull down the PHP packages from that particular repository.

That repository URLs are:

i386: http://software.virtualmin.com/bleed/centos/5/i386/

x86_64: http://software.virtualmin.com/bleed/centos/5/x86_64/

There is also a release package to automatically configure yum to use these repositories, which can be installed with the following command:

rpm -ivh http://software.virtualmin.com/bleed/centos/5/i386/virtualmin-bleed-release-1.0-1.rhel.noarch.rpm

Mobile Devices and Virtualmin

Mobile Devices and Virtualmin

For the purposes of Virtualmin, a mobile device is one that has a small screen and a limited web browser. Some examples would be a Treo, Sidekick, some cellphones, PDA or the iPhone. Because the browsers on these devices typically do not support Javascript, DHTML or complex CSS, the standard Virtualmin user interface does not work well. For this reason, a separate theme has been developed that optimized the UI for use from such devices.

Unlike most Webmin themes, this one is not typically selected by the user explicitly. Instead it is used either when Virtualmin is accessed via a browser on a mobile device (identified by the user agent), or when the URL starts with a specific suffix like m or mobile.

Managing Virtualmin Via A Mobile Device

The mobile device theme for Virtualmin allows you to access all the same features that you could via a regular browser, including all Webmin modules. However, some modules that are not part of Webmin have not been fully converted to a mobile-friendly UI, and so will not be as usable. But core Virtualmin operations like creating domains, managing users and installing scripts are fully supported.

Installing The Theme

To install the theme package on a Redhat, Fedora or CentOS system, use the command :

yum install wbt-virtual-server-mobile

or on Debian or CentOS, use :

apt-get install webmin-virtual-server-mobile

Alternately, you can install it using the Virtualmin Package Updates module.

Once the theme is installed, you probably want to enable it for mobile browsers. This can be done as follows :

1. Go to the Webmin Configuration module, and click on Mobile Device Options.
2. From the Theme for mobile browsers module, select Virtualmin Mobile Theme.
3. Since the normal Webmin login page is not particularly friendly for mobile devices, you should change Force use of HTTP authentication? to Yes.
4. Finally, click Save.

Using The Theme

Once the theme is enabled, just go to the Virtualmin administration URL (like <a href="https://yourserver:10000/" class="urlextern" title="https://yourserver:10000/"  rel="nofollow">https://yourserver:10000/</a>) using your mobile browser. As long as the browser's user agent is detected correctly, you should see a text-only page with links to list all servers, edit a specific server, manage system settings and so on.

Unlike the regular framed theme, to manage a server you must first either select it from the List virtual servers page, or enter the domain name into the Edit server box. This will bring up a page with links for all the possible actions for that server, such as editing features, users, aliases, scripts and databases.

Reading Mail Via A Mobile Device

The same theme that lets you access Virtualmin can also be used with the Usermin webmail interface on port 20000. However, this requires at least version 1.310 of Usermin and the 1.5 version of the mobile theme.

Again, all webmail and Usermin functions are available, except for the HTML editor for composing rich-text email. Also, all popup windows for selecting things like email addresses are disabled, as both the Javascript needed to invoke them and the ability to actually open a new window are unlikely to work.

Installing The Theme

The installation procedure is the same as the theme for Webmin, but the package is named ubt-virtual-server-mobile on Redhat-based systems, and usermin-virtual-server-mobile on Debian and Ubuntu. To enable it, use the Mobile Device Options page in the Usermin Configuration module, with the same selections.

If that page is missing on your system (because you have an older Webmin release), you can instead run the following commands :

echo mobile_preroot=virtual-server-mobile >>/etc/usermin/miniserv.conf echo mobile_prefixes=m. >>/etc/usermin/miniserv.conf echo mobile_theme=virtual-server-mobile >>/etc/usermin/config /etc/usermin/restart

Using The Theme

To use the new mobile theme, just login to Usermin at the regular URL using a mobile device like a Treo or cellphone. Instead of the regular UI, you should see a text-only page with links for your mail folders, a search form and links for folder management, editing your addressbook and other mail-related settings.

When viewing the contents of a folder a slightly different text-only layout is used, which avoids wide tables that don't render well on mobile browsers. Also, the design of the address book page has been changed to make it more mobile-friendly. However, almost all mail reading functionality has been preserved - although some features are not supported, such as uploading attachments and the HTML editor when composing mail.

OS Notes

OS Notes

Every Operating System is a little bit different, even when Virtualmin puts a common UI on top of it. This is a collection of observations about various operating systems, and common pitfalls.

CentOS

Bleeding edge package repositories for CentOS 5. If you need a newer PHP version than the default CentOS version, enabling this repository may be a solution.

A common cause of installation/update errors on CentOS is due to having third party repositories installed. If the installer is having trouble installing packages, verify that there aren't any third party repositories conflicting with your primary repositories.

Debian

Upgrading Debian etch to lenny with distupgrade

Upgrading Debian Lenny to Squeeze with distupgrade

Ubuntu

Upgrading Ubuntu 8.04 LTS to 10.04 LTS with distupgrade

On Ubuntu 10.04, "hostname -f" needs to resolve to your full hostname, or the installation may not work correctly.

FreeBSD

FreeBSD Username and Group Limits

Support Requests and Remote Login Access

Support Requests and Remote Login Access

Virtualmin has an optional module that can be used to easily file support requests or grant remote login access to developers from within the Virtualmin UI. Before you can use it, you must install it on your system as follows :

1. Login to Virtualmin as root
2. On the System Information page, click on the optional Virtualmin packages link.
3. Check the box next to the virtualmin-support package, then click the Install Selected Packages button.

Alternately, it can be installed from the command line on CentOS, Redhat or Fedora systems with the command :

yum install wbm-virtualmin-support

On Debian or Ubuntu, the command to install is :

apt-get install webmin-virtualmin-support

Submitting A Support Request

If you run into a bug in Virtualmin and want to report it, this is best done using the support feature within Virtualmin. It ensures that the bug is properly associated with your license, and that it contains important information like the OS, version and system configuration.

The steps to submit a bug are :

1. Login to Virtualmin as root
2. Open the System Settings link on the left menu, and click on Submit Support Ticket.
3. Fill in the Issue summary and Issue details fields with a description of the problem.
4. To allow us to more easily debug the problem, you should leave the Include Virtualmin domain validation report and Include detailed system information boxes checked. However, if you don't want details of your hosted domains or system configuration send to the Virtualmin developers, you might want to un-check them.
5. Click the Submit Ticket button.

Assuming all the needed fields have been filled in, a page will be displayed containing a link to the newly submitted bug report at http://www.virtualmin.com/bugs/ . All future followup will be done via the bug tracker, and you will receive email updates when additional questions or solutions are posted to the bug.

Granting Remote Login Access

In some cases, resolving a problem on your system may require the Virtualmin developers to login via SSH as root to run debugging commands or examine configuration files. However, you probably don't want to give out your root password or grant access to us forever.

To avoid this, the Virtualmin support module can grant limited time access using SSH keys added to the root user's authorized_keys file. To enable this, the steps to follow are :

1. Login to Virtualmin as root
2. Open the System Settings link on the left menu, and click on Support Login Privileges.
3. Select the Allow logins until option, and enter a date on which you want the login grant to end.
4. Click the Enable Remote Logins button.
5. SSH will be configured to grant access, and email sent to the Virtualmin developers with your system's IP address and SSH port.

If you entered an end date, access will be automatically removed at the end of that day. However, you can turn if off early by clicking on the Support Login Privileges link and then hitting the Disable Remote Logins button.

System Configuration and Maintenance Frequently Asked Questions

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

Virtualmin for cPanel Users

• Virtualmin for cPanel Users
• Domains vs. Virtual Servers
  • Creating a "Sub-domain"
  • Creating a "Parked Domain"
• Migrating Existing cPanel Domains to Virtualmin
  • Making the cPanel Backup
  • Copying the cPanel Backup to Your Virtualmin Server
  • Using the Migration Form
• MySQL

Virtualmin for cPanel Users

Domains vs. Virtual Servers

Creating a "Sub-domain"

Creating a "Parked Domain"

Migrating Existing cPanel Domains to Virtualmin

Making the cPanel Backup

Copying the cPanel Backup to Your Virtualmin Server

Using the Migration Form

MySQL

Virtualmin on Low Memory Systems

Virtualmin on Low Memory Systems

A default installation of Virtualmin is configured to maximize performance, rather than minimize memory usage. Thus, on a system with 512MB of RAM and less, or systems running on a VPS with no swap available, problems can arise if steps aren't taken to reduce usage. These steps will not hurt performance on a low memory system, as running out of memory is a far greater performance problem than having to load a few libraries on each pageview in Virtualmin. Note also that Virtualmin, even at 100MB, is not the largest process on a full-featured webserver. Apache will be about 150-250MB once all of the modules are loaded, depending on which modules you use and whether everything runs under mod_fcgid or you use the individual mod_php, mod_perl, mod_ruby, etc. BIND can also grow to 100MB or much more, depending on the number of zones you're hosting and whether it is providing recursive DNS service. Postfix always stays pretty small, but the spam and anti-virus tools are unavoidably quite memory and CPU intensive.

32 bit vs 64 bit systems

If you have less than 3GB of RAM, we'd recommend using a 32bit operating system. And this is especially true if you have 1GB or less of RAM. Processes take up twice as much RAM on a 64 bit architecture, and if you have any RAM constraints, any performance benefits that one might gain from a 64 bit operating system would be undone if a server ran out of RAM.

To disable preloading of Webmin libraries, follow these steps :

1. Login to Virtualmin as root.
2. Open the System Settings category on the left menu, then click on Virtualmin Config.
3. Change Preload Virtualmin libraries at startup? to No
4. Click Save. You will then be prompted to re-check the Virtualmin configuration.
5. Click the Re-Check button. Once this process is complete, the Webmin server process will reduce RAM use to about 10M.

Alternately, you can do the same thing from the command line by editing /etc/webmin/miniserv.conf

Find this line:

preload=virtual-server=virtual-server/virtual-server-lib-funcs.pl virtual-server=virtual-server/feature-dir.pl virtual-server=virtual-server/feature-unix.pl...  

This line is much longer than this on most systems. Insert a # mark at the beginning of the line (before "preload"), to comment it out, and then restart Webmin with the following command:

/etc/webmin/restart

Then edit /etc/webmin/virtual-server/config, and change the preload_mode line to :

preload_mode=0

This will reduce Virtualmin memory usage from ~90MB to ~10MB. This option determines which Webmin libraries are preloaded on Webmin startup. It makes it faster, if there's plenty of memory, but on low memory systems avoiding swapping is far more important to performance of all components.

Reduce SpamAssassin and ClamAV memory usage

SpamAssassin and ClamAV combine to use a lot of memory. You can reduce their memory usage by going into System Settings - Spam and Virus Scanning, set these two options:

Reduce Apache memory usage

• Browse to the Webmin Apache Webserver module
• Click on "Processes and Limits"
• Change the following to the values shown:
  • Maximum spare server processes 3
  • Minimum spare server processes 2
  • Initial server processes 3

Optionally, remove any modules you aren't using. This actually will reduce memory usage more than anything else--but it's hard to guess what modules you'll want/need to do your job. mod_perl is needed for the new Analytics module in Virtualmin, but otherwise everything can be run under cgi or fcgid...and if memory is a real problem, you may have to give up on Analytics (or set it up manually without our mod_perl filter). So, disabling mod_php4 or mod_php5 is cool (but if you've been using it for PHP scripts, you'll need to make the switch to fcgid first, and reset permissions and ownership up your PHP scripts in domain homes) and will shave quite a bit off the process size. Other possibilities for disabling: auth_dbm, disk_cache, proxy (but this removes quite a bit of functionality), include (removes Server Side Include functionality), status.

Because Apache is probably the biggest process on any hosting system...if you're dealing with a VERY small memory system (under 256M), then you'll have to cut it down a lot. This isn't really optional in that case.

Reduce mail processing memory usage

The actual mail services are tiny. The spam and anti-virus filtering services are not. You may want to consider simply forwarding mail on to a free Gmail account or something that has good spam/AV filtering. This is limiting...but it means your mail service can be provided in a few MB. In such a case, you'd turn off dovecot, and would never have to spawn SpamAssassin or clamav. If you do have to deliver mail locally, don't use clamd or spamc, as those have processes that always run...unless you get enough mail to keep them respawning every minute or more (because the memory is effectively made unavailable anyway--might as well get the mail processed faster and give away a little memory).

Reduce unnecessary services

Shut down postgresql or mysql or both. If you're not using databases, don't run them.

You can often get away without running Mailman. If you need to send out newsletters, look into something like phplist, which is more lightweight.

Shut down proftpd, if you can convince yourself and/or your users to use the Webmin Upload/Download and File Manager modules or ssh/scp for file transfers.

Don't even think about running X. You probably don't want to run X on any server, but this is particularly true for low-memory systems.

Enable swap

Make sure you have a swap file or swap partition configured. Swapping out infrequently used processes and data leaves more memory for active processes.

Community-Provided Sample Config Settings (CentOS 5.2)

I use these configs on my 256MB CentOs 5.2 VPS Server. It works good for me, but mileage may vary for you. This is in no way a replacement to a larger server.

Optimize LDAP for low memory Server

Note: Don't use LDAP on a low-memory system. Flat-files are dramatically less resource intensive and much faster than LDAP under pretty much all circumstances and especially in low-memory systems. But, if you must use LDAP, this may be helpful in reducing some of the resources required.

/etc/openldap/DB_CONFIG

set_cachesize 0 26843545 1
cachesize 1000
set_lg_regionmax 26214
set_lg_bsize 209715

Optimize Apache for Low memory Server

/etc/httpd/conf/httpd.conf (on CentOS) /etc/apache2/apache2.conf (on Debian/Ubuntu)

KeepAlive On
KeepAliveTimeout 3
<IfModule prefork.c>

StartServers       2
MinSpareServers    2
MaxSpareServers    5
ServerLimit      100
MaxClients       100
MaxRequestsPerChild  500
</IfModule>
<IfModule worker.c>
StartServers         2
MaxClients         150
MinSpareThreads     15
MaxSpareThreads     50
ThreadsPerChild     15
MaxRequestsPerChild  0
</IfModule>

Optimize MySQL for Low Memory Server

/etc/my.cnf

[mysqld]
port               = 3306
socket             = /var/lib/mysql/mysql.sock
skip-locking
key_buffer         = 16K
max_allowed_packet = 1M
table_cache        = 4
sort_buffer_size   = 64K
read_buffer_size   = 256K
read_rnd_buffer_size = 256K
net_buffer_length  = 2K
thread_stack       = 64K