OK, this time I want to document the steps for HestiaCP customizations (see installation tutorials here). Note that the following instructions are based on real websites hosted on a spare Linode server. I may make some videos showing how to do fresh install and customizations on a unmanaged Hostwinds VPS server.
Here is a short list of things:
(1) Enable secured mail access and URL for HestiaCP and Webmail login (this can be done using the built-in v-* commands) – this section also includes editing DNS settings for the hostname root domain thefirstdomain.com to make sure it uses this BIND9 template: child-ns in order to host more than one domain on the same server.
(2) Change HestiaCP login port for security reasons instantly with a single short command.
(3) Adding PTR and AAAA records for hostname domain pan1.myprimarydomain.com
OK, now we can go throgh the the details for each of the above goals…
(1) Enable secure mail access and URL for HestiaCP and Webmail login
Normally after a fresh install of HestiaCP (and for VestaCP as well), the login can only be accessed using an IP-based URL. And using this IP-based URL, you will see a warning as it is using a self-signed SSL certificate. The connection is secure but you do not want your customers to see this warning.
If you want to login using the hostname domain like this: https://pan1.myprimarydomain.com:8083 it is impossible because pan1.myprimarydomain.com cannot resolve to the server IP – its DNS zone is empty and its root domain’s DNS zone is empty as well. Take a look at this fresh install screenshot again:
As you can see, there is only one USER which is admin, and only one WEB domain which is pan1.myprimarydomain.com. There is no DNS and MAIL domain at all because the DNS zone is empty for a fresh install, and the pan1.myprimarydomain.com cannot resolve to the server IP even when its root domain myprimarydomain.com points to the server IP by the glue records set at your domain registrar.
I had tried in the past adding the root domain and then add an A record for pan1 in its root domain’s DNS zone. But if this is not done properly, we are going to see many problems as I did before with much headache. So keep reading for the proper way that is all done via Hestia and its own commands.
So the proper way is to make sure the default hosting package is edited for the right settings before we add the root domain.
Click on “Packages” from within HestiaCP and then click on “Edit” when you move your mouse over to the default package.
Make sure the DNS Template BIND9 entry is child-ns. This ensures that the next domain to be added, that is the root domain myprimarydomain.com acts as a child of the DNS glue records you set at your domain registrar.
Note that only this domain’s DNS template needs to be set this way. For all other domains to be added later on, you can use the default DNS template. This is critical if you plan to host more than one domain on the same server. Pay attention to the section that is hightlighted in red:
Note also, I changed the Apache2 Web Template to hosting from default as I need to run mostly WordPress websites which are not static HTML websites.
Scroll down further before saving to make sure the Name Servers are entered as shown (with your own values of course):
Then we can add the first domain account (not couting the default one added by Hestia installation script) myprimarydomain.com like this:
This time we want it to Create DNS Zone and Enable email services because it is a FQDN that is truly associated with the server IP.
As soon as we do this, we should be able to see this first FQDN site from the browser right away because HestiaCP has just generated a default page in its public_html folder a file named index.html, a proper set of DNS zone records has also been set and mail services have been configured as well.
However, for the next step and for future use, make sure you edit the deault hosting package again and change the DNS template setting from child-ns BACK to its default value – this is critical as we want to glue all other domains to the first domain so that all can use the same ns1/ns2.myprimarydomain.com name server settings.
Now the real trick…
The trick is to Remove and Add Again pan1.myprimarydomain.com in the DOMAIN section, as simple as that. The reason we do this is because when HestiaCP set it as the hostname subdomain, it did not set the domain up for WEB, MAIL and DNS Zone at all — all these are empty for this subdomain. That is why we cannot use it for browser access. It is there only for identification purpose, a subdomain that is tied up to the server. Normally we do not use it, but we need it now for domain-name-based HestiaCP login.
I won’t show the removal part. Here is the screen for the re-adding of pan1.myprimarydomain.com:
You may uncheck the Create DNS zone as a DNS zone for its root domain has been already created when we added it earlier. But it does not hurt if we check it because we then do not need to add the pan1 A record for the root domain.
By this time you sould be able to see the domain-bame-based Hestia login with its HTTP URL, but it will quickly redirect to its HTTPS URL as it has been internally set that way.
Now we need to make the HestiaCP login URL secured. We can issue the LetsEnscrypt SSL certificate from within the HestiaCP’s area, I mean the browser accessed area. However, in order to see the potential error messages, it is better to use the following v-* commands (also called CLI commands) that come with Hestia/Vesta.
First we need to enter this simple line of command to generate the LetsEnscrypt certificate for the hostname domain (with root SSH login or admin login as the root’s super user):
v-add-letsencrypt-domain 'admin' $HOSTNAME '' 'yes'
You may see an error message such as the following if something is wrong (my explanation in brackets):
Error: Let’s Encrypt validation status 400 (may be due to wrong configuration)
Or this error:
Error: Let’s Encrypt finalize bad status 429 (too many certificate requests)
Once you see this error, you may have to wait for at least 7 full days before you can get another one issued for your domain.
If the certificate is issued without any problem, then we use it for HestiaCP login, exim and webmail access by doing this:
v-update-host-certificate admin $HOSTNAME
If you encounter the following error using the v-” commands for the first time:
bash: v-add-letsencrypt-domain: command not found
Enter these two lines of command in sequence as root:
PATH=$PATH:/usr/local/hestia/bin && export PATH
Then you should be able to run all the v-* commands now and in the future.
After you have gone through all the steps as instructed above, you should be able to access the Hestia login area from this URL without receiving a warining:
Take look at this screnshot:
You see the green lock on the top left? There you go!
Add one email account to the first domain, then test to see if the LetsEnscrypt SSL certificate works for your mail server access as well.
(2) Change HestiaCP login port
For security reasons, we need to change the port from its default 8083. With VestaCP, there are several steps to take to do that. However, I have found a CLI v-change-sys-port command from this link at HestiaCP’s website.
Example usage: v-change-sys-port 5678
As soon as you use that command as super user at the SSH terminal, BOOM, the port is changed in a split second:
(3) Adding PTR and AAAA records for hostname domain pan1.myprimarydomain.com – this is too easy to do from the DNS area. Ask in the comment area if you still don’t know how to do it.