At least here in Europe, Hetzner is a good supplier of dedicated servers.
Good price and excellent quality and features.
But I’ve been in despair for almost two weeks to get a working HestiaCP installation.
Despair becomes panic when you realize that other panels work and Hestia is in chaos.
But without stress …
I understand the problem.
Hetzner uses its own linux templates that for one or several reasons are incompatible with HestiaCP.
To solve the problem definitively, you have to install Debian or Ubuntu using the “rescue” option.
IMPORTANT, you do not install Linux directly through the Hetzner panel.
1- You enter the Rescue option
2- Reset System
3- Enter as root and type:
root @ rescue ~ #installimage
4- Then follow the steps indicated
5- VERY IMPORTANT
Hetzener automatically configures your DNS, it is imperative to change the respective files
DEBIAN:
nano /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001: 4860: 4860 :: 8888
nameserver 2001: 4860: 4860 :: 8844
In addition: We also use Hetzner Cloud as testing infra for the most prerelease checks. Also I use their own dbs servers for all hetzner based hostings, no issues here. Can you share your server informations (ax41, ex41, whatever you took) and steps which you did to install hestia?
At the moment I have about 6 Hetzner servers all AX41-NVMe.
I installed HestiaCp in two so far.
In the first I only had problems with SSL Certificates and DNS, in the second it was chaos, I was clicked any button and I waited 5m to do anything.
So it leads me to believe the Hetzner has different configurations in the same product depending on the clusters.
On the other hand, I tested HestiaCP on an OVH Server and I found zero problems, but on OVH servers I install the original version of Linux by default.
It was really the experience I did on the OVH servers that led me to insist on solving Hetzner’s problems.
I have several servers with Vesta and I have need to solve this issues shortly.
Currently using ax41 with proxmox on top, do you use it baremetal? The load issue could be something with the firewall, did you have the issues directly after install or after doing some modifications?
I forgot
Step 4.1 - update-locale LC_CTYPE = pt_PT.UTF-8
I will convert all my servers to HestiaCP, except the servers with Moodle, I tried with Moodle, saw some errors and gave up without paying much attention to it due to lack of time.
This week I don’t have much time because I delayed all the work due to this situation, but I have to convert all the servers soon because I no longer trust Vesta.
I prefer to spend time with online servers than wasting my time with offline servers
I also tried with Ubuntu, it was not slow but it showed errors in DNS and SSL certificates.
But I gave up because I personally don’t like Ubuntu very much for these things.
Hi
Obviously I’m not making up problems, because I don’t even have time to solve the ones I already have.
I just created this post in an attempt to help all those who encounter the same problems that I encountered and thus save them several days of work to debug, research and solve.
I have been using dedicated OVH servers for a long time and the experience of the years has led me to the discovery that equal servers assembled on different dates have different configurations that manifest themselves in small details depending on the specific needs of each project.
On OVH servers a couple of years ago I chose to always install the original Linux version to avoid surprises after the Servers are working in production.
We all know that our work is dynamic and is not always the same in similar terms.
But if you believe that my post is abusive or that it somehow misrepresents the truth, please let me know.
I still haven’t had time to look in more detail and I may be mistaken in what I’m going to write next, but my suspicions are that the problem is in the configuration of Iptables because during the installation of Hestia Iptables takes too long to configure and when this happens the error also happens.
About the ssl errors triggered by the fact that the system cannot resolve the DNS I found this article.
Check post 4 from 2016
I was running into a similar issue (on other server though) just after a fresh install and enabling iptables manually (because it didn’t get automatically started after reboot).
Well, even on sudo I was getting this: sudo: unable to resolve host example.com: Temporary failure in name resolution
Every request was taking ages to response back …
Result is that I needed to allow established connections to continue in iptables:
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Why it wasn’t even there at first glance, I have no idea, but my iptables rules didn’t mention that before I added it.
