Testing Ubuntu 20.04

bash hst-install-ubuntu.sh --apache yes --nginx yes --phpfpm yes --multiphp no --vsftpd no --proftpd no --named yes --mysql no --postgresql no --exim no --dovecot no --clamav no --spamassassin no --iptables no --fail2ban no --quota no --api yes --lang en --hostname --email --password EvONyJxC --force yes

Will work…

2 Likes

Yes indeed it’s working now :smiley:

Please change your password after this :slight_smile:

you could simply omit the email address and password in the install string, and it will ask you during the setup for the mail and generate a random password that you can change afterwards.

especially for the password part I heavily recommend to not use the command-line switch at all, as this might lead to storing your password in plain text in .bash_history - something you would not want to do at all, right?

2 Likes

Let me take part in this testing :grin:

Install

Installed on: Hetzner Cloud CPX11 (AMD EPYC 2nd generation), 2vCPU, 2GB RAM
Installed with the commands:

wget https://raw.githubusercontent.com/hestiacp/hestiacp/master/install/hst-install-ubuntu.sh
bash hst-install-ubuntu.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 [EMAIL] --port [PORT] --api yes

I didn’t face any installation issues, apart from this. But that was my bad, cause I installed and configured /etc/fstab before installing Hestia. So I didn’t pay attention to that error.

Post Install Issue 1

I logged in to the web interface and started to look around. First issue I noticed is in Server > Task Monitor Under Bandwidth Usage eth0 I see this:


But I don’t think this is important and I expect for stats to even out eventually.

Post Install Issue 2

I confirm the issue with fail2ban: Clicking the Server menu, I see that fail2ban is not active (greyed out), although issuing the command systemctl status fail2ban.service I get the reply that the service is loaded and active

● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-16 10:34:41 EEST; 18min ago
       Docs: man:fail2ban(1)
    Process: 629 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS)
   Main PID: 701 (f2b/server)
      Tasks: 15 (limit: 2256)
     Memory: 16.0M
     CGroup: /system.slice/fail2ban.service
             └─701 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Even if I go and see other parts of the Web Panel, whenever I return to the Server, the fail2ban service is greyed out. Clicking Start or Restart from within the Web interface, I get the confirmation dialog if I wan to (re)start it, but even if I click OK the service status (on the web interface) doesn’t change.

One thing to note here is that fail2ban seems to be working OK, because I can see banned IPs in Server > Firewall > Managed Banned IPs

Post Install Issue 3

Clicking the Server menu on the web UI, I see that Hestia version 1.1.2 is installed. But when I go to Server > Updates it’s showing hestia version 1.1.1. Since this is a test release, I wouldn’t say this is a real issue, but devs will be the judges of that :slight_smile:

I haven’t loaded any domains yet, but I’ll get back when I do.

1 Like

#2
Fail2ban issue has been fixed in the master branch. Not yet in the release branch you are currently using

#3
Clicking the Server menu on the web UI, I see that Hestia version 1.1.2 is installed. But when I go to Server > Updates it’s showing hestia version 1.1.1. Since this is a test release, I wouldn’t say this is a real issue, but devs will be the judges of that :slight_smile:

True however it is still the code base of 1.1.1… Soon we will start prepare for the release on 1.1.2

Please use https://github.com/hestiacp/hestiacp#installing--testing-development-builds

1 Like

What is the approximate release date of 1.1.2 with 20.04 support?

there is no eta yet, we work on testing on the master branch, probaly 2-3 weeks. If you woule like to speed up the release date, it would be awesome if you could test the master branch :slight_smile:.

1 Like

I would like to help in testing, but I did not quite understand how to install the version for developers on the clean ubuntu server 20.04 … I must to install the regular version first, but it does not support 20.04?

Please use the following instructions

wget https://raw.githubusercontent.com/hestiacp/hestiacp/master/install/hst-install-ubuntu.sh
bash hst-install-ubuntu.sh

1 Like

Clean bare metall server which was upgraded from 18.04 to 20.04 Ubuntu.

Run the following commands:
1)
bash ./hst_autocompile.sh --all master no

bash hst-install-ubuntu.sh --apache no --nginx yes --phpfpm yes --multiphp no --vsftpd no --proftpd no --named no --mysql yes --postgresql no --exim yes --dovecot no --clamav no --spamassassin no --iptables yes --fail2ban yes --quota yes --api no --lang en --hostname myhostname --email [email protected] --port 8045 --force --with-debs /tmp/hestiacp-src/debs

Got the output:

The following server components will be installed on your system:

  • NGINX Web / Proxy Server
  • PHP-FPM Application Server
  • Exim Mail Server
  • MariaDB Database Server
  • Firewall (Iptables) + Fail2Ban Access Monitor

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

Would you like to continue with the installation? [Y/N]: y
Installation backup directory: /root/hst_install_backups/220520202258
Installation log file: /root/hst_install_backups/hst_install-220520202258.log

Adding required repositories to proceed with installation:

() NGINX
(
) PHP
() MariaDB
(
) Hestia Control Panel

Updating currently installed packages, please wait…-
mkdir: cannot create directory ‘nginx’: File exists
mkdir: cannot create directory ‘apache2’: File exists
mkdir: cannot create directory ‘php’: File exists
mkdir: cannot create directory ‘vsftpd’: File exists
mkdir: cannot create directory ‘proftpd’: File exists
mkdir: cannot create directory ‘bind’: File exists
mkdir: cannot create directory ‘exim4’: File exists
mkdir: cannot create directory ‘dovecot’: File exists
mkdir: cannot create directory ‘clamd’: File exists
mkdir: cannot create directory ‘spamassassin’: File exists
mkdir: cannot create directory ‘mysql’: File exists
mkdir: cannot create directory ‘postgresql’: File exists
mkdir: cannot create directory ‘hestia’: File exists
Now installing Hestia Control Panel and all required dependencies.
NOTE: This process may take 10 to 15 minutes to complete, please wait…

Selecting previously unselected package hestia.
(Reading database … 122854 files and directories currently installed.)
Preparing to unpack …/debs/hestia_1.1.2_amd64.deb …
Unpacking hestia (1.1.2) …
Setting up hestia (1.1.2) …
() Configuring system settings…
(
) Configuring Hestia Control Panel…
() Generating default self-signed SSL certificate…
(
) Adding SSL certificate to Hestia Control Panel…
() Configuring NGINX…
(
) Configuring PHP-FPM…
() Configuring PHP…
(
) Configuring MariaDB database server…
() Installing phpMyAdmin version v5.0.2…
(
) Configuring Exim mail server…
(*) Configuring fail2ban access monitor…
/usr/local/hestia/bin/v-update-firewall: line 175: /sbin/iptables-save: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 180: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 181: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 182: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 183: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 184: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 185: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 186: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 187: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 188: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
chmod: cannot access ‘/usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks’: No such file or directory
/dev/md2 [/]: group quotas turned on
/dev/md2 [/]: user quotas turned on
/usr/local/hestia/bin/v-stop-firewall: line 68: /sbin/iptables-save: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 73: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 74: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 75: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 76: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 77: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 78: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-stop-firewall: line 79: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
chmod: cannot access ‘/usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks’: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 175: /sbin/iptables-save: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 180: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 181: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 182: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 183: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 184: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 185: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 186: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 187: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
/usr/local/hestia/bin/v-update-firewall: line 188: /usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks: No such file or directory
chmod: cannot access ‘/usr/lib/networkd-dispatcher/routable.d/50-ifup-hooks’: No such file or directory
Error: ERROR: Restart of iptables failed.

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

Congratulations!

You have successfully installed Hestia Control Panel on your server.

Ready to get started? Log in using the following credentials:

Seems that the file is in another place. Using find gives result:
/usr/sbin/iptables-save
/etc/alternatives/iptables-save

As a result - iptables is grayed in Server list
Overall HestiaCP is working.

Also I noticed, that PHP 7.3 version is being used instead of 7.4 which is default in Ubuntu 20.20. Is it a bug or a feature which should be changed in server configuration menu? In one config place hestia-php has 7.4.5 version (screenshot below)…

Also Fm (File Manager?) page is giving 404 error. I don’t need FM anyway…

Correct, i noticed as well after installing last night.

Just did a test run on a Digital Ocean Ubuntu 20.10 droplet. (n.b. DO needs the --force flag as it has an admin account configured). Commands run:
wget https://raw.githubusercontent.com/hestiacp/hestiacp/dde0dc69d507e658334cb16d5540af5c79f6fbc0/src/hst_autocompile.sh
wget https://raw.githubusercontent.com/hestiacp/hestiacp/master/install/hst-install-ubuntu.sh
chmod 700 *.sh
./hst_autocompile.sh --all master no # … compile time approx 20 mins.
./hst-install-ubuntu.sh --vsftpd “no” --named “no” --clamav “no”
–port “7777” --hostname “test.domain.com” --email “[email protected]
–password “xxxxxxxxxx” --force --with-debs /tmp/hestiacp-src/debs

All seems to work. But a couple of small points.

  1. Initial domain got bound to the internal 10.x.x.x IP address. Vesta login worked, but needed to re-bind to the public IP address before the website showed up. DO VM has two IPs configured on eth0. Perhaps it picked the first one numerically? Second one was 66.x.x.x.

  2. Need to run v-add-letsencrypt-host immediately as previously noted. Would that be a sensible default to run on the end of the install? Always supposing the IP address resolves to the hestia box.

  3. I didn’t install ftp or bind, so as usual I removed the firewall entries. Perhaps these firewall entries could be disabled/removed if bind/ftp aren’t installed? Not a great problem if no daemon is running on that port though.

  4. I got an email alert “OpenSSH can not be restarted. Please check config:” after installing and rebooting, although ssh started fine.

That’s about all. Nice updated versions of roundcube, phpmyadmin etc.

Question: If I installed hestia using the compile script, will I still be able to update hestia through the normal channels afterwards. (I’m wondering whether to start to configure the server as-is, or whether to wait for the final release.)

1 Like

Hi @pluto

Just haven’t enough time here to answer the other questions, but for the one above a strong “no”: This is only for testing, the servers are not planed to get in the normal productive branch, also you may miss important updates during the dev state if you do it anyway.

1 Like

Also noticed, that PHPMyAdmin is not working. Instead there is 404 error.

Also it is not possible to change PHPcli version for user in GUI. It can be changed and saved, but when you go back to the user edit page - it is back to default 7.3

1 Like

Just to confirm:

Change first to 7.4 of any other version and then
execute in shell as the user or root :
cat /home/admin/.bash_aliases

And check with php -v the php version?

In case 7.4 it should read 7.4.5 or something like that. I think it is a interface bug

(https://github.com/hestiacp/hestiacp/commit/7bb52d8186f71b73ee8f54b4defb96bd59fdd911 is with the fix)

Are you using

http://ip/phpmyadmin?

or https://hostname.nl/phpmyadmin/

The first one has been disabled for security reasons