Some Bugs after Upgrade to 1.1.0

Community Support Mail
1

Hello all and congrats for the work being done! :+1: :wave:

I’m sorry for not being active, but various health reasons for the most part of this month, have kept me away from work :frowning: Things seem to stabilize now and here I am again :slight_smile:

Back to the topic now… My experience so far:

28/02/2020 - 12:50 EET
CLEAN INSTALLATION OF HESTIA 1.0.6 ON Ubuntu 18.04

wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
bash hst-install.sh --nginx yes --apache yes --phpfpm no --multiphp yes --named yes --vsftpd yes --proftpd no --iptables yes --fail2ban yes --quota yes --exim yes --dovecot yes --spamassassin no --clamav no --mysql yes --postgresql no --interactive yes --hostname $(hostname -f) --email xXx --password xXx --port 12110 --api yes

STARTING UPGRADE TO HESTIA 1.1.0

wget https://apt.hestiacp.com/beta/hestia_1.1.0_amd64.deb

ERROR HERE (already mentioned + solution)

dpkg -i hestia_1.1.0_amd64.deb
(Reading database ... 47752 files and directories currently installed.)
Preparing to unpack hestia_1.1.0_amd64.deb ...
Unpacking hestia (1.1.0) over (1.0.6) ...
dpkg: dependency problems prevent configuration of hestia:
 hestia depends on setpriv | util-linux (>= 2.33); however:
  Package setpriv is not installed.
  Version of util-linux on system is 2.31.1-0.4ubuntu3.5.

dpkg: error processing package hestia (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 hestia

MANUALLY INSTALL setpriv (upgrade to 1.1.0 continued automatically)

apt install setpriv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  setpriv
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 24.5 kB of archives.
After this operation, 136 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 setpriv amd64 2.31.1-0.4ubuntu3.5 [24.5 kB]
Fetched 24.5 kB in 0s (633 kB/s)
Selecting previously unselected package setpriv.
(Reading database ... 47819 files and directories currently installed.)
Preparing to unpack .../setpriv_2.31.1-0.4ubuntu3.5_amd64.deb ...
Unpacking setpriv (2.31.1-0.4ubuntu3.5) ...
Setting up setpriv (2.31.1-0.4ubuntu3.5) ...
Setting up hestia (1.1.0) ...

                _   _           _   _        ____ ____
               | | | | ___  ___| |_(_) __ _ / ___|  _ \
               | |_| |/ _ \/ __| __| |/ _` | |   | |_) |
               |  _  |  __/\__ \ |_| | (_| | |___|  __/
               |_| |_|\___||___/\__|_|\__,_|\____|_|

                  Hestia Control Panel Software Update
                            Version: 1.1.0
========================================================================

(!) IMPORTANT INFORMATION:

Default configuration files and templates may be modified or replaced
during the upgrade process. You may restore these files from:

Backup directory: /root/hst_backups/280220201303/

This process may take a few minutes, please wait...

========================================================================

(*) Enabling support for themes...
(*) Hardening SSH daemon configuration...
(*) Hardening security of Roundcube webmail...
(*) Updating exim configuration...
(*) Updating default writable folders for all users...
(*) Updating DNS template for Office 365...
(*) Updating backup compression level variable...
(*) Hardening MySQL configuration...
(*) Hardening nginx configuration, drop TLSv1.1 support...
(*) Migrate to new multiphp backend system...
(*) Upgrading phpMyAdmin to version v4.9.4...
(*) Rebuilding domains and account for user: admin...
(*) Restarting services...

========================================================================

Upgrade complete! If you encounter any issues or find a bug,
please take a moment to report it to us on GitHub at the URL below:
https://github.com/hestiacp/hestiacp/issues

We hope that you enjoy using this version of Hestia Control Panel,
have a wonderful day!

Sincerely,
The Hestia Control Panel development team

Web:      https://www.hestiacp.com/
Forum:    https://forum.hestiacp.com/
GitHub:   https://github.com/hestiacp/hestiacp/
E-mail:   [email protected]

Made with love & pride by the open-source community around the world.


Processing triggers for man-db (2.8.3-2ubuntu0.1) ...

ENABLE MULTIPHP FUNCTIONALITY

bash /usr/local/hestia/install/upgrade/manual/migrate_apache.sh

I have not found any issues so far. Next I will try to restore some users and files. I’ll update with any new information.

1 Like
2

Here are some more results. I think it’s a good idea to post what I have tested along with the results. That way we know if something is tested or not. If you think that’s too much unneeded information, just tell me.

  1. Obtain lets encrypt certificate for domain via WebUI (using web template default - php-fpm 7.3)
    OK - Success

  2. Enable automatic HTTP-to-HTTPS redirection via WebUI
    OK - Success (enabled/set + working OK)

  3. Enable AWStats via WebUI (for the server’s FQDN)
    Issue: While visiting the https://[FQDN]/stats/ page I get the results + this message
    Warning: HostAliases parameter is not defined, awstats choose “[FQDN Here] localhost 127.0.0.1”.
    Quick research: https://awstats.sourceforge.io/docs/awstats_config.html#HostAliases
    Inside the file /etc/awstats/awstats.[FQDN Here].conf HostAliases="" (empty)
    Possible solution: The warning dissapears when adding the FQDN in HostAliases (HostAliases="[FQDN Here]") and then running v-update-sys-queue webstats. I don’t know though if this is the right way to solve that issue.

  4. Assign SSL/TLS Certificate to all services (v-add-letsencrypt-host)
    OK (exim ports 465/587, dovecot ports 993/995, Hestia Web UI)
    NOT OK (FTP port 21 - still has HestiaCP Certificate)

  5. Added php-7.4 via WebUI
    OK

  6. Issue with Webmail
    Visiting https://[FQDN]/webmail/ instead of the Roundcube page I get:
    CONFIGURATION ERROR
    config.inc.php was not found.
    Please read the INSTALL instructions!
    …Although, creating a new web domain xxx.yyy via WebUI (+DNS +Mail domain) and visiting webmail.xxx.yyy works. So I guess support for https://[FQDN]/webmail/ (using the FQDN of the server) was dropped. Right?

  7. I just noticed that a new feature has been added in Fail2Ban, that checks the fail2ban log for repeated abuses and bans them for a longer period of time. Aka the [recidive] filter.

IPs banned by the recidive filter appear as Hestia in WebUI (Server > Firewall > Banned IPs) which is confusing, because it’s the same name as failed login attempt to HestiaCP. The way it is now, if you look at the banned IPs for “Hestia” you can’t tell if an IP was banned because it failed to authenticate on the actual HestiaCP or if it was an IP that repeatedly failed to authenticate on another service.

2 Likes
3

Thanks for the important testing @Felix! I’ll try to reproduce and answer the points as soon as I can. Please just post more here, if you find anything else. Due to current workload, my answer could be a bit delayed.

1 Like
4

I solved issue 6 changing permission from 640 to 644 on these 2 files

chmod 644 /etc/roundcube/config.inc.php
chmod 644 /etc/roundcube/debian-db-roundcube.php

And for Issue 4 you can try change cert path editing VSFTPD config on server tab or using
nano /etc/vsftpd.conf

changing
rsa_cert_file=/usr/local/hestia/ssl/certificate.crt
rsa_private_key_file=/usr/local/hestia/ssl/certificate.key

to
rsa_cert_file=/home/admin/conf/web/hostname.domain.com/ssl/hostname.domain.com.crt
rsa_private_key_file=/home/admin/conf/web/hostname.domain.com/ssl/hostname.domain.com.key

5

Hi @donko
Thanks for your input! Currently I can’t recommed both of your ways for productive systems - with 644 you let every user read the php file, so basicly they could get now the db credentials from debian-db-roundcube.php - at leat when they have ssh with their user.

For vsftpd I think there is only a restart missing, both issues are currently in debugging. Pleae give us some additional time, we will get them solved for sure!

1 Like
6

Could you check, if a service vsftpd restart solves the issue? Probaly the service restart is missing the related v-script.

1 Like
7

Yeap! That’s it @ScIT ! Issue 4 resolved by restarting the service with service vsftpd restart :+1:

Solution to Issue 6 by @donko also works! But I’m a bit worried about the security implications of giving read access to everyone on these files. Wouldn’t it be better to add the process/user accessing those files to www-data group?

1 Like
8

As I already wrote: not a good idea :smiley:, we are already working for a solution.

9

fixed: Fixed missing restart routine for vsftp on v-add-letsencrypt-host · hestiacp/hestiacp@a25b114 · GitHub

10

www-data doesnt help, I’ll need to work with @lupu for a solution, it’s a issue due to the changed right management with fpm. webmail.domain.tld is working properly as you already mentioned.

11

Is it possible, that you added a domain without any subdomain/alias? For example just test.domain.tld instead domain.tld (with www.domain.tld as alias)?

12

Yes. There is no “www” alias. The test was done on the default WEB domain which is created automatically during installation. The FQDN of the server is like server.domain.com.

For issue 7 I have created this pull request

13
  1. Issue with phpMyAdmin

I’m checking phpMyAdmin at https://[SERVER-FQDN]/phpmyadmin. I was able to login as MySQL root user, but then I got those errors at the bottom of the phpMyAdmin page:

The configuration file now needs a secret passphrase (blowfish_secret).

The $cfg['TempDir'] (/var/lib/phpmyadmin/tmp/) is not accessible. phpMyAdmin is not able to cache templates and will be slow because of this.

First of all I need to mention that the URL https://[SERVER-FQDN] is using hosting nginx template + default apache template + PHP-FPM7.4 template. Now let’s move on to troubleshooting…

I can see in file config.inc.php line 34 there is a file that should be included (/var/lib/phpmyadmin/blowfish_secret.inc.php). This file contains the cfg setting for blowfish_secret (random alphanumeric and special characters). So in theory, it should work.

Then I noticed that if I create an new domain (xxx.yyy using default nginx template + default apache template + default php-fpm template) and then login at the URL https://xxx.yyy/phpmyadmin/index.php , I get no errors there! It still works even if I change web domain to hosting nginx template + default apache template + PHP-FPM7.4 template (as is the https://[SERVER-FQDN]/phpmyadmin).

So I guess this issue is kinda similar to issue #6. Permission issue maybe?

1 Like
14

image
image804×180 2.44 KB

I can confirm this issue too!
webmail is working fine via - webmail.domain.com

15

Can confirm the php issues, we’re currently try to resolve this prior to the 1.1.0 release.

1 Like
16

Hello,

Issue 3: Confirmed.
Issue 6: I wasn’t able to replicate this (Ubuntu 18.04, nginx + PHP-FPM).
Issue 7: Will be amended at the next release, thanks for your contribution.
Issue 8: Confirmed, will be fixed at the next release.

1 Like
17

I just done a fresh install on fresh debian 10 install and am getting same errors?

thanks

18

Please open another thread and describe your issues.

19

Hello, i’m not sure if my problem is just the same or have relation to this. But i arrived to here trying to solving it and it worked also for me to run the command: service vsftpd restart

In my case it seems that the “Hestia” successfully updated Let’s Encrypt Certificates a month ago, but VSFTPD was using the old version of the certificate, so the FTP Client was alerting about an outdated certificate when connecting.

As i said, it got solved immediately manually running service vsftpd restart, but i think that there is some kind of “problem” here with the autonomous updating of the SSL certificates on VSFTPD.

Maybe i’m wrong… please i’m sorry if i’m talking about things that i don’t master yet :wink:

Anyway, thanks!!

20

Uppsss… now, another server with Hestia has updated hestiacp version too, and the SSL certificate used for https://mydomain.com is DIFFERENT that the used with https://mydomain.com:8083 (hestia panel)… !! the second one is outdated.

In other words, the address https://mydomain.com is using a right certificate, but https://mydomain.com:8083 is using an expired certificate.

I don’t know if it’s due to the update of Hestia to v.1.4.11 just a couple of hours ago or due to the expiring of the SSL certificate JUST ALSO today (a few hours ago).

Obviously, the :8083 certificate has not been updated, while the main it does !? So i’ve 2 doubts: a) is it required to use 2 different certificates for 2 different ports?, b) in affirmative case, why Hestia has not updated the :8083 certificate?

Tell me if you need more info. I think that could be some kind of error on Hestia with the auto-update of certificates. Is it possible?