Installation

There are two methods for installing Virtualmin: a fully automated shell script and package-based install, as documented here, and a manual installation using either native packages or .wbm Webmin packages, as documented in the Manual Virtualmin Installation page. When possible, the automated installation is recommended, as it removes many possible errors during configuration and insures that all applications are built with appropriate options for virtual hosting within the Virtualmin system.

Automated installation with install.sh

Installation involves first installing a basic install of your preferred Operating System, according to the documentation provided by your OS vendor. If the vendor provides a "server" version of the system, it is generally recommended you use it, as it will include fewer extraneous packages. A list of supported Operating Systems is provided at the OS Support page. There are a few simple guidelines for your system that must be met for proper operation of all Virtualmin features, which are detailed in the rest of this section.

Partitioning

The partitions on your Virtualmin server should be allocated in one of the the following two ways, depending on your requirements and preference. Either partition scheme is supported by the Virtualmin Professional Installer. Other partition layouts may lead to incorrect configuration of filesystem quotas, but can be corrected after installation is completed if other partitioning schemes are preferred.

One Partition

In this partition layout, you will only have one system partition plus a swap partition and /boot partition. The system partition contains /home for users, /var for logs and databases, as well as all of the normal system executable files, documentation and libraries. It is often simpler to deploy. Traditionally, "one big partition" was considered problematic from an administration standpoint, but most such issues have been resolved by modern filesystems, backup utilities, and improved hardware reliability. If you are unsure what to choose for your needs, this is probably the right option.

swap: The swap partition should be at least twice the size of RAM on the system.

/boot: The /boot partition should be large enough to accomodate a few system kernels and initrd images. Your OS vendor probably knows best what size this should be.

/: The remainder of the disk(s) should be devoted to /. This is where all system and user data will go.

Multiple Partitions

This layout spreads files across a few partitions, in order to facilitate usage of some types of backup utility as well as making some types of administrative task easier (for example, installing larger disks for some partitions at a later time). Historically, multiple partitions were considered wise administrative policy, but most modern systems and backup utilities eliminate the reasons for utilizing multiple partitions. Unless you know why you are dividing your disks into lots of partitions and can't achieve your goals any other way, you probably shouldn't.

/: This partition is used for all of the operating system files, executables, and configuration files. This partition should be at least 3.5 GB for most operating systems.

/boot: The /boot partition should be large enough to accommodate a few system kernels and initrd images. Your OS vendor probably knows best what size this should be.

swap: The swap partition should be at least twice the size of RAM on the system.

/var: The /var partition is where system logs, various changing data, and MySQL and PostgreSQL databases are stored. Depending on whether you will allow your domain users to use the database features, this partition may be between 2 GB and 10 or more GB. If users are expected to be heavy database users, you may opt to divide the remaining disk space between /var and /home.

/home: The home partition is where all of your domain users data, email, CGI scripts, logs etc. will be stored. Pretty much anything that belongs to your users, except for MySQL and PostgreSQL databases, will reside on /home. Devote the remainder of your disk to /home, as usage will likely grow rapidly if you have many users.

Package Management

In order for the install.sh installation method to work, your system must have a working package management system. Supported systems are yum and up2date on RPM-based systems, and apt-get on Debian and Ubuntu systems. The FreeBSD ports and pkg system is used, when possible, though limitations of package management on FreeBSD only allows system packages to be installed via these means, while the Virtualmin packages are installed from our own wbm package repository. The Virtualmin Professional installer uses the native package manager in order to cleanly and safely install all of the appropriate software dependencies. The installer will then install the Virtualmin-provided packages, including some custom versions of packages that include features necessary for all features of Virtualmin to operate. If your native package management tool requires configuration to operate correctly, this step should be done before running the Virtualmin install script. Most distributions come with a working package management system; CentOS and RHEL will use yum, Debian and Ubuntu will use apt, and FreeBSD will use the ports system and the remote installation capability of pkg_add.

Update Your System

Packages in Virtualmin depend on a lot of OS-standard packages in addition to the packages our repositories provide. And most package managers are a bit temperamental about dependencies; sometimes they'll refuse to install a package because an older version of one of its dependencies is installed. So, in order to avoid dependency problems of this sort it is best to fully update your system using your native package manager prior to running the install script.

Network Connectivity

The Virtualmin installer requires network connectivity, including DNS resolution. The speed of your connection may impact the speed of installation, as up to 200 MB of packages will be downloaded and installed (if your system already has the majority of the dependencies installed, the download size will be reduced). Latency and bandwidth usage can be reduced significantly for multiple system installations by running a local caching proxy server like Squid, or by operating a mirror of the Operating System being used. It is also possible to pre-install most of the packages during OS installation, and only updates will need to be downloaded over the network.

Pre-Installation Checklist

So, let's boil down all of those preliminaries into a simple checklist. These are the things you need to do before running the install.sh:

1. Confirm that networking is fully functional. Ping software.virtualmin.com. If it doesn't work, you'll need to fix it.
2. Confirm that your package management tool (up2date, yum, urpmi, yast, or apt-get) works correctly and is configured to use sources that are available.
3. Fully update your system with the native package manager before beginning installation.
4. Confirm you have perl and either wget, curl, or fetch installed.

Note: If you are installing on a low memory system, the package manager (both yum and apt-get/dpkg) can be very memory intensive during installation. A possible solution is to disable all but the necessary repositories (the OS standard repositories and the Virtualmin repositories. This is generally a good idea, anyway, as packages from non-OS sources may conflict with the Virtualmin packages and lead to unpredictable results.

Running the Install Script

Installation is performed automatically by the OS-neutral Virtualmin install.sh script. This script sets up the license key in /etc/virtualmin-license and configures the appropriate package management and installation tool for use with the password-protected Virtualmin software repository. It will then install the virtualmin-base package, which performs the remainder of the installation, appropriate for your OS and version.

Download the file from the Software Registrations page at [[http://www.virtualmin.com/serial/]]. All of your purchased products will be available for download throughout the life of your license period. Copy the file on to the server to be installed, using scp on Linux or Mac OS X client machines or WinSCP or PSCP on Windows.

Note: A frequent source of trouble is the use of FTP to make the transfer to your server. Because Windows uses different line endings than UNIX and Linux systems, the script can become corrupted if care is not taken to insure a "binary" mode transfer. scp and FTP over SSH are not generally subject to this problem, and so using the scp protocol for the transfer avoids many possible troubles.

Then, as root, run this:

# sh ./install.sh

Questions install.sh might ask you

Depending on your OS and the state of your system, the install.sh script may ask one or more questions.

Fully qualified domain name

If your system does not have a fully qualified domain name (FQDN), the installer will stop and ask you to choose one. This is mandatory because many services rely on having a fully qualified domain name in order to function. Mail, in particular, but some Apache configurations and many of the Virtualmin-created configuration files, also require a valid fully qualified domain name to function correctly. A fully qualified domain name is one of the form "www.virtualmin.com", or simply "virtualmin.com". We recommend you choose a name that is not one for which you will be receiving mail, in order to simplify later configuration. A good choice is to use a name server designator, such as "ns1.virtualmin.com". Some customers also choose something like "host1.virtualmin.com" or "primary.virtualmin.com". Any of these would be valid and would satisfy the install script and the services that rely on this option. The install script will add this name to /etc/hosts, which will satisfy all local services. It is even better if this name resolves correctly when looked up from outside of the system--this requires the name be added to your DNS zone for the second level domain. If the Virtualmin server you are installing will be the authoritative name server for this zone, you can later use Webmin to add a record for this name to the zone.

Completing the installation

Once the necessary questions have been answered, installation will proceed automatically. After 15-45 minutes, depending on the speed of your network connection, your system will be configured for Virtualmin and ready to login to. You can then login to Virtualmin. Virtualmin runs on port 10000 and is encrypted using SSL. Thus, you can connect to your system with an address of the form:

https://example.com:10000

Or:

https://192.168.1.1:10000

And then log in as the "root" user, or any user with sudo access.

The final step in the installation is to perform the configuration check, by clicking the Check Configuration button at the top of the Virtualmin System Information page.

Setting a root password

If your system does not have a password set for the root user, you will need to set a Virtualmin root password before you can login on port 10000. This can be the case when installing on an EC2 instance that uses an SSH key to login as root, or an Ubuntu system that uses sudo.

To set a root password for Virtualmin, run the command :

/usr/{share,libexec}/webmin/changepass.pl /etc/webmin root XYZ

where XYZ is the password you want to use. Make sure it is strong, as an attacker who guesses this password would have full control over your system.