Hi, I tried installing HestiaCP on 3 different VPS and had the following experiences/issues:
Installed on a KVM NAT VPS running Debian 10. Install script said only 8 and 9 were supported, but it seemed to download the same package, so patched the script and tried again. Script installed nginx and another thing or two and crashed. Ok, Debian 10 isn’t supported, so I’ll just wait, for now I can’t call this a Hestia issue.
Installed on OpenVZ VPS running Debian 9. Installation seemed to complete after a few minutes, but an “ssl-params” was left running hogging all available cpu for several minutes on a somewhat cpu starved system (VPS host gets upset about heavy cpu use). I killed the process, but rebooting the VPS restarted it hogging again. It seems to be part of dovecot so I uninstalled dovecot, which got rid of the immediate issue but I reinstalled the whole VPS just to be sure.
Installed on a new 1gb Vultr high frequency instance running Debian 9. This is a stupendously fast VM, like 5x the speed of the OpenVZ mentioned above. Installation proceeded as before, resulting in ssl-params process hogging cpu for somewhere between 3 and 5 minutes. This is really excessive. It would have been 30+ minutes real time on the slow, overloaded OpenVZ mentioned above, that should have been ok for a simple Hestia instance. I don’t know if it’s a Hestia issue per se or a problem with Dovecot, but web search indicates that Dovecot re-does this procedure every week or so. Whatever it’s doing should be considered broken. I don’t know how or whether to report this to dovecot dev though.
I found I had closed the window where I installed Hestia, so I lost the initial password that I used. Looked at the docs and saw lots of nice command line tools, but no indication how to run them (they were not in PATH, so docs should say where they are). Docs or FAQ should also say specifically how to reset this password. I didn’t bother investigating but simply reinstalled the Vultr instance to try installing Hestia again. I hit a snag or two (not Hestia problems) while doing this so haven’t tested further yet but will do so later.
Thanks for working on Hestia. I’m not really a panel user, but am playing with Hestia because of the recent drama surrounding cpanel that you’ve probably seen.
Followup: I chased down the slow dh_param generation a little more. First, this step took over 10 minutes on the vultr instance when I re-ran it, which is imho completely intolerable for this type of operation. Second, it’s a dovecot utility but it calls the deprecated OpenSSL DH_generate_parameters function which per its documentation “can take several hours”. Looking at the code for that function, it seems at first glance to be using a rather silly (i.e. much slower than necessary) algorithm, though I haven’t completely analyzed it yet. This gets a bit deep into crypto geekery but a few different fixes are in order, both in dovecot and maybe in OpenSSL itself. I can bring it up with the OpenSSL devs. I’m less familiar with the dovecot world but will check into it.
OK, I have the panel running, logged in and added a test user.
Panel said it emailed credentials to the user’s address, but that address didn’t receive an email, including in spam folder. This could be because of Vultr firewall blocking SMTP or some other VM config issue. There are some things I can try fixing on the VM, but it would be good for Hestia to report the error if it can detect trouble sending out the email. I don’t see any type of error report.
Adding user said last name must not be left blank. That seems annoying and unnecessary for an admin function. It should just use whatever name the admin supplies, even if it’s just a first name.
There’s a row of icons at the top of the panel, the rightmost of which I (now!) recognize as a door with an arrow pointing outward. Clicking on it unexpectedly logged me out. These icons should have tool tips, including “log out” on the door icon.
This is all intended as “test reporting” rather than complaining, so I hope it’s accepted in that spirit ;). Keep up the good work.
thanks for your checks, I would like to comment them below for each of your point.
Debian 10 will be supported with Release 1.1.0, the release should follow within a few weeks.
As you already noticed properly, ssl-params will be triggered from dovecot due to the ssl configuration. This will take some time and produces cpu load, this is a step we can’t prevent.
As above.
As the installer inform, you need to logout and login, that the path var gets loaded properly. As soon as you’ve done that, you can use the v-commands directly from every folder, for example v-change-user-password admin YourNewPass
This can happen due to restrictions of the mail provider: For example spf record would block incoming mails from unknown ips.
We already working on a changed form, so we can bring pre- and lastname together to one name field.
Usualy, the sign and position of the logout button should be clear enough, we will check if we can implement hover notifications. At least it is just logout and not a delete function .
Thanks for the response! I think there is a chance that SSL parameter generation in Debian 10 will be faster, since Dovecot 2.3 supposedly switched to a different algorithm (elliptic curve DH rather than integer). So I’ll wait and see before worrying more about this.
I had thought I’d logged out or rebooted before trying the CLI commands but maybe I got confused. Anyway, they work now, so thanks.
If the email receiving end blocks a message, I wonder if Hestia can detect it, even possibly after a delay (such as if there is a bounce message). I don’t know how common it is for a receiver to simply drop a message without reporting an error. But I still have to fix the DNS for this VM so that may help.
It could be nice (if it isn’t there already) to have a setup option to use a 3rd party email provider like SES (I use MXRoute), instead of relying on sending email from the possibly-unknown machine that Hestia is on.
I’m looking forward to the next version! I still need to read the docs some more too, of course.
The welcome email just sends you the login credentials. They will also be displayed at the end of installation and can also be set back easily using cli. So I don’t see there any reason for a delayed delivery, even this is already standard on exim.
You can setup a relay on your own in your exim main configuration, we will work on a backend integration for a feature release.
The issue is Dovecot wanting to generate a (it turns out) 4096 bit safe prime on installation. That is computationally very slow. If it was an entropy issue then /dev/random might block for a long time but it wouldn’t burn cpu like that.
.