The problem is simple, I want to move my and my client's sites away from Dreamhost into an environment where I have more control over the server software running the sites. A little over two years ago, Dreamhost started (and rightfully so) retiring older versions of PHP on both its Shared and Virtual Private Server hosting services. This caused me to have to go, metaphorical hat in hand, to a number of clients and inform them that their opensource web-based productivity tools are going to stop working without intervention on my part. Some tools fell into the dreaded "dead project category" (such as phpBMS) which had to be replaced with other software (InvoicePlane) with all data being migrated by hand. While with other tools, I was lucky, with development of the projects continuing to this day (such as Moodle), with upgrade processes being as simple as running the provided database upgrade script.
While working on another project, I had to look for a free and easy to use control panel for a small development web server. I went through several options, running several test installations and configurations with tools like Ajenti, Froxlor, ISPConfig, WebMin, OpenPanel, Kloxo, and ZPanel. For the majority of these tools, I found the installation and setup process too difficult to bother with, some were severely out of date, and others wouldn't work on Debian 8 at all. I then stumbled upon Vesta Control Panel (VestaCP).
VestaCP is probably the easiest free and opensource web server control panel to install and configure. The installation process is literally only 2 to 5 steps and the UI is easy to follow and navigate. Based on the current version number, it is very much in its alpha stages, but it also has a very active user forum where help is just a post (or google search) away. It also has a very extensive list of commands in the command line where administrators can configure the web server or even write useful Linux scripts to achieve a particular task. I ended up writing a script that would allow me to use my VestaCP server to act as a dynamic domain name server server as part of my migration away from Dreamhost so that I could map my home internet connection to a subdomain of one of my domains.
As wonderful as all of this sounds, VestaCP is not without its limitations and flaws. Like almost all web server control panels, it really just acts as a configuration layer on top of existing open source software and so a failure could be as simple as an automatic update to the software it depends on. When you make changes to anything, VestaCP goes deep into the nuts an bolts of this software and automatically modifies the text files that are used to configure the services that it relies on.
This is both convenient and challenging. Since VestaCP is still feature-wise in development, it is not yet comprehensive enough to allow users to configure every single feature that the software it relies upon is capable of. As a result of this, administrators often find themselves manually editing the configuration files, only to have the configuration files later replaced by an update to other configuration settings via the GUI or by an update to VestaCP itself. It works pretty darn well, but it is not (yet) perfect.
Out of the box on a VPS running Debian 8 with full root access, IPv4 and IPv6 WAN addresses, VestaCP will quickly serve insecure dynamic web pages without any issues unless you have extensive PHP or MySQL maximum timeout or memory requirements. Email however is another story.
Making Email Work
Based on the default VestaCP installation options, recent updates to the email server software, exim4, required antispam software spamassassin, and required antivirus software clamav prevent email from working properly and will not work until the user intervenes.
Reverse DNS Record
It wouldn’t hurt to set up the reverse DNS record anyways for the server’s domain name. If using Linode, follow these instructions. Otherwise contact the VPS service provider.
Exim4 Configuration
When making connections to email services such as Gmail for the purposes of transmitting email, exim4 appears to prefer IPv6 compared to IPv4. In the shared hosting environment, this complicates things because of new email standards that were established to make it more difficult to send unsolicited email. The particular offender of this is the requirement to have a valid Reverse DNS record (also known as PTR records) that resolves your server’s domain name to its IPv4 and IPv6 addresses and have that domain match the domain in which email is coming from. This is particularly problematic when you are hosting more than one domain on your shared web server since any one IP address can only have one Reverse DNS record. The best solution to deal with this is to simply disable IPv6 so that exim4 simply does not use it.
First you should determine if exim4 is even using IPv6. To do this run the following command:
netstat -tulpn | grep :25
This runs netstat which returns a list of active ports that are being listened to by the various services on the server. It then pipes it to grep which then filters out only the rows that mention port 25 which is one of the ports exim4 uses for mail services. Once this command is run it will return a list of protocols, services and the status of the port. Look through the list, if you see tcp6 next to any of the exim4 rows exim4 is running using IPv6.
To disable IPv6 you must edit the /etc/exim4/update-exim4.conf.conf and add the following:
disable_ipv6=true
Clamav Configuration
A recent update to Clamav in Debain 8 prevents the clamav-daemon service from starting. To resolve this issue, the following should be commented out (by adding a # at the beginning of the respective line) of the /etc/clamav/clamd.conf configuration file:
#AllowSupplementaryGroups
You can then start the clamav service by typing:
service clamav-daemon start
The service will then start.
Automatically Starting the Spamassassin Service
For some reason, the spamassassin service is not set up to automatically start with Debian when the VestaCP installer installs it. To have spamassassin automatically start with the VPS, simply enter the following command:
update-rc.d spamassassin enable
Fixing Roundcube
The version of Roundcube webmail that is in the Debian 8 repository has a bug that does not allow users to send email from the webmail interface. To resolve this run the following commands:
rm -r /usr/share/roundcube
wget https://github.com/roundcube/roundcubemail/releases/download/1.1.5/roundcubemail-1.1.5.tar.gz
tar -zxvf roundcubemail-1.1.5.tar.gz
mv roundcubemail-1.1.5 /usr/share/roundcube
chown -R root:root /usr/share/roundcube
rm roundcubemail-1.1.5.tar.gz
rm -r /usr/share/roundcube/installer
Other Configuration Tweaks
Securing Sites Using the Let's Encrypt Certificate Authority
There is a third party plugin that quickly and easily integrates Let's Encrypt certificates with Vesta CP. To install the plugin, enter the following commands into the command line:
apt-get install git
cd /usr/local
git clone https://github.com/certbot/certbot.git
git clone https://github.com/interbrite/letsencrypt-vesta.git
mkdir -p /etc/letsencrypt/webroot
ln -s /usr/local/letsencrypt-vesta/letsencrypt.conf /etc/apache2/conf.d/letsencrypt.conf
service apache2 restart
ln -s /usr/local/certbot/certbot-auto /usr/local/bin/certbot-auto
ln -s /usr/local/letsencrypt-vesta/letsencrypt-vesta /usr/local/bin/letsencrypt-vesta
To install a certificate run the following command in the command line:
letsencrypt-vesta admin my-vps-domain.tld
Upon the first execution of this command, it will verify that all of the required dependencies are already installed prior to installing the certificate.
Securing VestaCP's GUI
VestaCP Automatically Generates a self-signed SSL certificate upon installation, while provides a certificate to encrypt the connection to the GUI Panel, it can also cause web browsers to freak out about the certificate not coming from a recognized authority.
To resolve this, use the same certificate that we generated for the VPS Domain name using the letsencrypt-vesta command. Once the command is executed, a message will appear indicating the successful installation which will include the path that the newly created certificate is stored. Make note of the directory.
Next create a symlink to the private key and the certificate in VestaCP's certificate directory /usr/local/vesta/ssl
ln -s /etc/letsencrypt/live/my-vps-domain.tld/cert.pem /usr/local/vesta/ssl/certificate.crt0
ln -s /etc/letsencrypt/live/my-vps-domain.tld/privkey.pem /usr/local/vesta/ssl/certificate.key0
Now we need to edit /usr/local/vesta/nginx/conf/nginx.conf to refer to these symlinks. Simply find the variables and replace the values with the following:
ssl_certificate /usr/local/vesta/ssl/certificate.crt0;
ssl_certificate_key /usr/local/vesta/ssl/certificate.key0;
Why not replace the certificates altogether? Parts of exim4 actually use the certificate that was generated by VestaCP's installer, it is best not to mess with them or otherwise you will run into email server problems.
Restart the Server to Make Sure Everything Works
After all of these tweaks are applied, the email server should start working without issue. It would not hurt however to restart the server after starting these just to make sure things continue to work after a reboot. Finally try a website and also try sending and receiving email to and from an account hosted on the server.###
Domain Health
It is also a good idea to check the health of your domain name using the MX Toolbox Domain Health Report.
Footnotes
- According to the VestaCP Version Road Map, the next version of VestaCP (Version 0.9.8-17) will come with Let's Encrypt support built in... As of September 2017 it does not work.