We just updated the hestia rc package which resolves the issue which @Active8 reported, also an additional issue which leads the filemanager to fail due to less memory. There is no need to reinstall the package, the changes arent relevant for running systems - just for the upgrade procedure itself.
link ```
wget https://apt.hestiacp.com/beta/hst-OS-VERSION/hestia-nginx_1.17.10.deb
is not working for me
Replace OS with debian or ubuntu and version with 9, 10, 1604, 1804 or 2004
If it not work please give us the file you are downloading…
Thank you @eris
Now on webmail (roundcube) i have server name, after upgrade, is this correct?
And if yes, what the server name?
Normally webmail.yourdomain.com should work at least if you created the domain…
Your server name should be hostname that you supplied…
Hestia v1.2.0 is about to be released this week, so any feedback you guys have, would be very helpful.
I’ve installed the RC on a Ubuntu 20.04, but had the problem, that the hestia service wasn’t able to start:
hestia[16148]: * Starting hestia-nginx hestia-nginx
hestia[16148]: …done.
hestia[16148]: * Starting hestia-php hestia-php
hestia[16153]: /usr/local/hestia/php/sbin/hestia-php: error while loading shared libraries: libzip.so.5: cannot open shared object file
I had a look on the dependencies of the hestia-php package:
Depends: hestia, libzip5 | libzip4, unzip, libonig5 | libonig4
Since libzip4 was installed on my system, the dependencies were ok. After I installed libzip5, hestia-php was working fine.
Hi @ronald
Thanks for your feedback, did you maybe upgraded your system from ubuntu 18.04 to 20.04? I just ask myself why you’re running libzip4, as far as I can see, Ubuntu 20.04 gets shipped with libzip5 (and libonig5).
No, I used a minimal Ubuntu 20.04 image from netcup.de, which didn’t have the libzip5 installed.
I’ve upgraded an old version of hestia 1.1.1 to 1.2.0 RC and hestia-php 7.4.5 to 7.4.6. I think the installation of hestia 1.1.1 or hestia-php 7.4.5 has installed the libzip4. After the upgrade to hestia 1.2.0 and hestia-php 7.4.6 there was no need for the package manager to install libzip5, becase libzip4 was installed.
Hmm, Hestia 1.1.1 wasnt ready for Ubuntu 20.04, the official support will be added with 1.2.0. Not sure if the issue is relevant for the release, infact libzip4 isnt available for 20.04 (https://packages.ubuntu.com/focal/libzip4), libzip5 should be installed by default. Thanks for reporting it, also glad that you got it fixed on your own !
I had a closer look on the problem. I’ve php7.3 (7.3.19-1+ubuntu20.04.1+deb.sury.org+1) and phpmyadmin (4:4.9.5+dfsg1-2) installed on the system. phpmyadmin depends on php-zip, which is provided by php7.3-zip (7.3.19-1+ubuntu20.04.1+deb.sury.org+1). The package php7.3-zip depends on libzip4. This is the reason, why libzip4 is installed and there is no need to install libzip5 with hestia.
I have just tried installing on a Debian 10 (buster) CT (first installed v1.1.1 and immediately upgraded to 1.2.0)
Some very quick comments:
-
Before successful installation of hestia_1.2.0_amd64.deb I had to install debian pkg “lsb-release”:
() Hardening Apache2 Server Status Module…
() Install sury. org Apache2 repository…
/usr/local/hestia/install/upgrade/versions/latest.sh: line 25: lsb_release: command not found
() Updating Roundcube configuration…
() Updating exim4 configuration…
() Configuring Filegator FileManager…
() Upgrading phpMyAdmin to version v5.0.2…
() Rebuilding domains and account for user: admin…
() Restarting services… -
I had apt source duplication error:
root@vm05:~# apt-get update && apt-get upgrade
Hit:1 http: security. debian .org/debian-security buster/updates InRelease
Hit:2 http: deb. debian .org/debian buster InRelease
Hit:3 https: packages .sury.org/php buster InRelease
Hit:4 http: ams2. mirrors. digitalocean .com/mariadb/repo/10.4/debian buster InRelease
Hit:5 https: apt.hestiacp .com buster InRelease
Hit:6 http: nginx .org/packages/mainline/debian buster InRelease
Reading package lists… Done
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Translations (main/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Packages (main/binary-all/Packages) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Translations (main/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
W: Target Translations (main/i18n/Translation-en) is configured multiple times in /etc/apt/sources.list.d/apache2.list:1 and /etc/apt/sources.list.d/php.list:1
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@vm05:~#root@vm05:~# cat /etc/apt/sources.list.d/apache2.list
deb https: packages. sury .org/php/ buster main
root@vm05:~# cat /etc/apt/sources.list.d/php.list
deb https: packages. sury .org/php/ buster main
root@vm05:~#
-
In the WebGUI Quick Install Apps, I noticed it says Wordpress version: 5.3.2, but I think in the code it installs the latest:
$ fgrep Wordpress web/add/webapp/index.php
[ ‘name’=>‘Wordpress’, ‘group’=>‘cms’, ‘enabled’=>true, ‘version’=>‘5.3.2’, ‘thumbnail’=>’/images/webapps/wp-thumb.png’ ],
$ fgrep latest web/src/app/WebApp/Installers/WordpressSetup.php
‘archive’ => [ ‘src’ => ‘https wordpress org /latest.tar.gz’ ],
Thank you very much for such a great software, please keep up the hard work!
PS: Sorry I had to mangle the URLs above because the forum wouldn’t accept my post otherwise …
Looking at today’s git commits all 3 issues I reported seem to have been resolved.
Thank you @Lupu
To follow up my previous post, I had left the freshly installed Debian 10 CT with HestiaCP 1.2.0 running unattended for about a day, and I just checked it only to find out a huge mail queue with tens of thousands of mails!
root@vm05:~# mailq | wc -l
27126
root@vm05:~#
root@vm05:/var/mail# mailq|tail
0m 772 1jnQld-0001rU-UT <[email protected]>
[email protected]
0m 1.7K 1jnQle-0001rY-2i <> *** frozen ***
[email protected]
0m 1.7K 1jnQle-0001rd-38 <> *** frozen ***
[email protected]
root@vm05:/var/mail#
Apparently the 1000s of e-mails are generated by cron taks, due to DNS config issues:
root@vm05:/var/spool/exim4# more /var/spool/exim4/input/1jma2b-0007xP-Uu-D
1jma2b-0007xP-Uu-D
sudo: unable to resolve host vm05.mydomain.tld: Name or service not known
root@vm05:/var/spool/exim4#
The /etc/hosts file has no FQDN entry for vm05
root@vm05:~# more /etc/hosts
127.0.1.1 vm05
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Any ideas if this huge flood of e-mails is normal for a HestiaCP system with DNS problems or if something else might is going on here?
You didnt have set your hostname properly, add vm05.domain.tld after vm05 with a space between - so the messages will stop. You can also clear the freezed messages, a short google search will lead you to the right command. To prevent this in future, we currently discuss a valdiation check during installation.
Sure, I know how to manually configure DNS ( /etc/hosts and ISC Bind or dnsmasq), but I assumed HestiaCP would configure everything automagically.
Btw a good idea would be to add a header “Don’t edit this file manually … blah blah” to any config files that would be over-written by HestiaCP’s scripts.
Basicly this would be “only” the content of /home/user/conf, but we will discuss this aswell .
Since DNS is so critical for the operation of any Internet server, please suggest some “best practices” when setting up a reliable HestiaCP server e.g.
- manually add the FQDN and real IP into /etc/hosts (assuming it won’t get overwritten automatically by some HestiaCP script later)
- add HestiaCP hostname to our external DNS servers
- add HestiaCP hostname in BIND (if running locally on)
I just checked an Debian 9 & 10 and Ubuntu 18.04 server all consult files then dns, according to /etc/nsswitch.conf
hosts: files dns
A decent summary of what /etc/hosts should look like can be found at
PS: I don’t mind at all configuring the HestiaCP server MANUALLY, as long as I know that HestiaCP won’t touch the same files. Btw let’s suppose that you wanted to RENAME the server, how would you do it ?