Debian 11 and Hestia

Community Support
1

Did anyone try to install Hestia on Debian 11?
Does Hestia support it?

2

Will be checked and merged in the next few days.

3 Likes
3

Thank you so much!

4

has it been merged yet?

5

Currently in public testing: Install: HestiaCP + Debian 11

6

what if i have to update debian 10 to 11 and also hestia? do i follow the same way?

7

No wait till we release the packages this currently works only for new installs.

You have to make more updates due to changing configs…

1 Like
8

allright i see… so for now just stay with what i got? will the configs be handled automatic when you release?

9

No there have 2 changes in files maybe some more but we have to test it first we will provide an upgrade “information” when needed.

1 Like
10

has the upgrade guide been released yet?

11

Those are the extra changes for the rest search any Internet tutorial…

12

Have to say after a few tweaks its running rock solid (fresh install) so far

13

Would you like to share your tweaks? Jist in case they are relevant and could be implemented to the next release.

14

Hi

The tweaks were not to core hestia, just tuning mysql which needed doing and solved an issue i was having with one of my sites, since that was tweaked its been flying, but sql tweaks are unique i guess to each persons setup and use case.

The only thing that could use tweaking although i may have misunderstood how its actually setup by hestia is database users. I thought that setting up a database with a user meant that user has only access to that DB. but it appears at least to sql tuner that each user is granted access to all DB’s, not sure if thats correct.

But i literally have setup debian 11 and various control panels at least 50 times the last week to get a decent responsive setup.

The only issue i had on stock settings which is weird in that on one site only it would respond weirdly for example click on a link and TTFB would be 5-10 seconds, click on another link and the same, but then after a minute or so, TTFB reduced to sub 1 second which is how it was on plesk.

So i have made changes to one area only at a time to see where the issue was. Redis tweaks were fine, apache tweaks were fine (already tweaked keep alive settings and additional directives) but the issue persisted. Took out Modsecurity rules which made no difference.

However last night made a couple of minor changes to Mysql and now the TTFB is always sub 1 second.

First was to bind to 127.0.0.1 which is not set in the config
However added Skip-networking flag and some tweaks to the existing elements and now it flies with a really responsive TTFB

All i added in various areas based on past experience:

Apache

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 100

Changed Opcache to -
opcache.memory_consumption = 256
adjust opcache.max_accelerated_files (set this to above the number of scripts i have)
opcache.interned_strings_buffer=16

Apache settings which are not relevant to all sites (i use admintools to set per type expires this is just a catch all )

< IfModule mod_expires.c >
ExpiresActive on
ExpiresDefault “access plus 365 days”
< /IfModule >

Mysql (security and performance)

bind-address=127.0.0.1
skip-networking=1
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M

Redis -
tcp-keepalive 300

Plus a few other tweaks to my.cnf but again they are subjective and different was a case of raise a little and read logs and then tweak some more

But with the above, i have to say the performance of hestia is smashing that of Plesk, even with modsec running, i do run a slim version as i have no exim postfix mail server or bind running at all, just the basic core setup.

4 Likes
15

Thank you for sharing!

1 Like
16

Thanks for the detailed report!!!

Could you maybe open a issue report about the mysql permission on github please, we should track that down - usualy db user should only habe access o the related db.

17

I may of explained that wrong as just re-looked at the message, its about restricting the DB User to IP or Localhost this is the message, but if its still an issue i can log it on github yes

Restrict Host for ‘xxxxx_xxx6969thxxxxx’@’%’ to ‘xxxxx_xxx6969thxxxxx’@LimitedIPRangeOrLocalhost

RENAME USER ‘xxxxx_xxx6969thxxxxx’@’%’ TO ‘xxxxx_xxx6969thxxxxx’@LimitedIcPRangeOrLocalhost;

I presume thats because out of the box mariadb is available externally so most likely just a preference rather than an issue to be honest

18

Ah, that’s ok - we decided to close the mysql port by default, on vesta, it was open to public. So no reason to be concerned - thank you for the update!

19

Thats odd, then because on the last install i did port 3306 appeared to be open on all interfaces.

I did a fresh install basic setup and then did two checks

netstat -ant | grep 3306

showed it open on localhost and either my ip or 0.0.0.0 cant remember now to be fair

And when i did an nmap scan it also showed 3306 as being open even though the port is not permitted through csf

I added the bind.address to my.cnf as that was not present and restarted mariadb and then it only appears as on localhost.

Im just going to fire up another instance as a quick test

20

The firewall should not accept any connections on mysql port - please let me know if the behaviour should not be like i wrote.

1 Like