VPS newbie trying hestiaCP via CPanel import - please help

I installed hestiaCP v1.7.7 on a freshly provisioned Debian 11 updated to 11.7, and did

v-import-cpanel /backup/backup-5.22.2023_01-37-57_myloginid.tar.gz yes

That seemed to go fine, so I suspect someone with experience might be less than an hour away from being able to go live with it, but I have some remaining issues and questions before I dare point the registered domain to the new digs, and I could sure use some help (I can follow directions, just haven’t found them), please…

When I point my web browser to the VPS’s IP address (without :8083), I see a green check mark and “Success Your new web server is ready to use.”, but I do not know how to make the browser’s request find the index.html in /home/admin/web/host.mydomain.com/public_html much less to the domain’s imported web site in /home/myloginid/web/mydomain.com/public_html (which is what I want; I don’t even know what I might ever do with admin’s – the server’s – public_html).

But once I do get incoming web requests pointed to myloginid’s / domain’s public_html I am also baffled by finding the server’s default cgi-bin directories alongside, rather than under, public_html (where they got imported to, where they’d run with shared hosting, so that the web-friendly perl scripts could be accessed via web browser). I think this difference might require a change to httpd.conf, but don’t know what to do.

Meanwhile, attempts at generating an SSL cert have failed… When I go to Edit Web Domain and Enable SSL for this domain, if I choose Use Let’s Encrypt to obtain SSL certificate, and then Save, it says Error: Let’s Encrypt validation status 400 (apparently because the domain on the old CPanel server, where the domain still points, didn’t answer an acme-challenge?). So I tried a self-signed cert, pasted all 3 fields, clicked Save, and get Error: SSL intermediate chain is not valid

So I still don’t know how close I am to being able to go live with the domain’s web site on the new hestiaCP VPS, or how far away it might be regarding mail functionality (DNS settings got imported…).

For extra credit/thanks:

Is changing “22” to some other number on the SSH line of hestiaCP FIREWALL all it takes to change ssh/sftp logins to a non-standard port#? (fail2ban has been busy…) By the same logic, should 8083 also be changed to something non-standard?

Before I try muddling through, do step-by-step instructions exist for enabling ssh login key pairs (I know how to make them) and disabling ssh password logins?

Lastly, I also find myself stuck in endless chicken-and-egg loops as I ponder using the vps’s nameserver to point to domain(s) on the vps (IP address, ok; but will I need 2?), and also being able to test readiness to go live without going live. (Yes, I did “Please read this, before you start!”, but I suspect I’m pretty close to success; Helping pave the way for me and other shared_hosting CPanel users to migrate to hestiaCP can be good for hestiaCP, which seems like a great tool…)

TIA for any/all instructions, directions, URLs, advice, hints and/or clues.

Best info I’ve found was Ricky’s…

Prepare/secure server for hestiaCP install - main/ubuntu

Prepare/secure server for hestiaCP install - debian

hestiaCP tutorial (video) (long)

Both tutorials can be skipped for 50% …

It tries to install UWF as Firewall even Hestia does remove it when detected…

  1. Make sure to update the DNS to your new server before activating the letsencrypt…

So I wiped the vps and started over, fresh Debian 11, upd’d to 11.7, secured it, then installed hestiaCP with --force

still no bind service:

bind9 is still (in the) red :frowning:

$ systemctl status bind9
● bind9.service - LSB: Start and stop bind9
Loaded: loaded (/etc/init.d/bind9; generated)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)

$ sudo systemctl start bind9

$ systemctl status bind9
● bind9.service - LSB: Start and stop bind9
Loaded: loaded (/etc/init.d/bind9; generated)
Active: active (exited) since Sun 2023-05-28 05:26:57 EDT; 8s ago
Docs: man:systemd-sysv-generator(8)
Process: 8701 ExecStart=/etc/init.d/bind9 start (code=exited, status=0/SUCCESS)

bind9 is still (in the) red :frowning:

as per Add bind9 to an already installed hestia I ascertained that DNS_SYSTEM=‘bind9’ was already in $HESTIA/conf/hestia.conf

out of ignorance/desperation (figuring I can just wipe the vps and start over again if it doesn’t work), I took “Run the following commands” to mean that I should copy the lines of “Configure Bind” code (containing cp, chown, chmod) into config_bind.sh and stopped bind9 and did sudo bash config_bind.sh

I started bind9, then told hestiaCP to Restart.

bind9 is still (in the) red :frowning:

TIA for any/all instructions, directions, URLs, advice, hints and/or clues.

I knew from the initial attempt that hestiaCP did its own firewall so I ignored that UWF portion, thanks.

Thanks for the quick reply but I don’t know what to make of it.

I only see the insserv msgs during hestiaCP install, not when performing systemctl command.

the following 2 commands elicit the same text response

$ sudo systemctl status bind9

$ sudo service bind9 status

Why the bind9 conflict? Would the hestiaCP installer prefer if I somehow(???) removed(???) bind9 first? :expressionless:

Hestia runs multiple times systemctl start / stop / restart during the installer…

I have no idea why it caused…

So the “solution” in the link in post #6 was to do

find /etc/init.d -name "*.debian" -exec rm -f {} \;

because supposedly script files, left over from some prev upgrades, were somehow interfering, but I checked /etc/init.d and none of the files were .debian

Hestia runs multiple times systemctl start / stop / restart during the installer…

thanks for that; I guess the next (only?) thing to try is to wipe vps and do it all over again but this time do the update to 11.7 after installing hestiaCP (if successful)

same no-bind9 problem as last time, even though the installer congratulates me for having successfully installed…

This time I did NOT upgrade the host-re-provisioned Debian 11 to 11.7 before the hestia install, but the installer spent lots more time at “Installing dependencies…”, and once installed, SERVERS says 11.7, same as last time.

All I’d done was to change root passwd, set the time zone, install ssh pubkey, change ssh port# and disable passwd logins, then restart ssh to test login. I also snagged a copy of the detailed list of 244 files in /etc/init.d before doing the hestia install as root. I then snagged another list of the 316 files in /etc/init.d (in case anybody would like to see them).


Debian 11.7 is only a month old. Could this be some new incompatibility?

You are using the provider image it maybe custom build with their own changes …

Possible, but more likely the particular vps environment; it seems this is long-standing problem that affects current stable releases and latest updates of Debian and Ubuntu, as per Bind9 does not work on OpenVZ 7 VPS [Bug] · Issue #2560 · hestiacp/hestiacp · GitHub

Does the following, found in the above link, help? (if not, what have hestia users been doing about this for over a year already? sticking with old linuxes?)


Lines 1621 to 1624 in f7c1cc5

Workaround for OpenVZ/Virtuozzo

if [ -e “/proc/vz/veinfo” ] && [ -e “/etc/rc.local” ]; then

sed -i “s/^exit 0/service bind9 restart\nexit 0/” /etc/rc.local


Newer versions this work around doesn’t work and we still had issues with it we have added not to use only kvm or lcx

  • NOTE: Hestia Control Panel in combination with OpenVZ 7 or lower might have issue Bind9 server not starting or issues with Firewall. If you use a Virtual Private Server we strongly advice you to use something based on KVM or LXC!

Good to know, thanks! :smiley:

Since that probably means starting over in my search for a vps host, I’m open to suggestions, advice, URLs, etc (TIA)

'twould be nice if installer 1.7.7a detects this conflict/failure and indicates it, in red…

…knownhost confessed to using OpenVZ but wants 60% more $ for KVM (and Slightly faster storage), so the path of least resistance was to try Debian 10

I did see a few bind9 alerts when upgrading Debian 10, and then bind wasn’t running, but it started up seemingly ok. So I rebooted and ran the hestiaCP installer and there were no bind9 warnings, and now it lights up green, as it should, under hestiaCP 1.7.7 and Debian 10.13 :smiley:

Debian 10’s EOL is July 2024, so a year from now either kh will be scrambling to upgrade their about-to-be-obsolete vps (OpenVZ 7 will be 8y old then) offering or I will be looking for a more modern host – assuming I can actually get stuff to work (still doesn’t – haven’t imported yet)…

Again even under Debian 10 it has issue with Firewall. And yes KVM is more expensive as it assigns the resources different. OpenVZ is more flexible with sharing resources… and shares the kernel…

what kind of firewall issue? is it serious? (do I care?) (how much?)

The firewall screen looks ok, and the vps no longer answers ‘pings’ from traceroute – at either IP address – after hestiaCP install

Thanks for explaining why the free software costs more, but vultr KVM costs no more than kh OpenVZ and I can still get my money back from kh…

I imported from the old shared CPanel backup.

The domain sprang to life :smiley: when I switched DNS template to child-ns, but some glitches remain:

SSL is working for the domain and subdomains, but cgi-bin is still not functional.

The subdomains’ html files are not being found via web browser (the subdomains are still not used to having their own public_html, and the hestia setting to specify Custom Document Root, in an attempt to simply point web requests to the old web root subdirectory, does not seem to work). Further confusing me, within the subdomain’s public_html directory there is a subdirectory named “html” that contains all of the main domain’s web document root (html) files and directories…!

So the CPanel import seems to have gone less than perfectly well, and I’m not sure what’s up with the hestia Custom Document Root setting, but being so new2vps and to hestia, maybe it’s (all???) just me…?

I’m also not able to apply SSL to webmail so haven’t entered a password into Roundcube login screen yet. What’s the trick to that??

When I go (as admin) to Edit admin’s WebDomain, host.mydomain.com, Enable SSL, Let’sEncrypt, auto-https, Save, it says, “Error: DNS record for host.mydomain.com doesn’t exist”

When I go to DNS, the only thing I can do is Add DNS Zone. When I click that, I’m told, " It is strongly advised to create a standard user account before adding web domains to the server due to the increased privileges the admin account possesses and potential security risks"

But I don’t want to add a user, I just want host.mydomain.com (its Web Domain) to have SSL, in the hope that that will enable Roundcube to have SSL.

When I do log in as the user created by importing the CPanel backup, I’m shown the 3 web domains (main domain and 2 subdomains) but host.mydomain.com is not shown, apparently only editable by admin. :frowning:

Also, is there a way to (iow, how do I) keep hestia from requiring me to login again so frequently?


https://datapacket.net/vps-hosting/ seems like superior bang/buck but only 7 days (money back) to decide, so I’d like to first get it all ironed out @ kh where I still have longer than that…

Create add under the zone for mydomain.com a new record for host.mydomain.com. You don’t need to add an extra Zone.

Make sure both mail.domain.com and webmail.domain.com exists as DNS record and it should work fine