Hestia Post Install Tweaks

This is a general, share with the community post. There are a bunch of things I do whenever I set up a new Hestia server. Some pretty generic, and personal like fixing .bashrc to my satisfaction. But there are a bunch of others, so I thought I’d share them here, and see if anyone wanted to add to the list.
OK, so this one for a start … I generally set up a script called weekly_maintenance.sh and run it via root’s cron. Currently it looks like this

#!/bin/bash

# See if there's an update for wp-cli
/usr/local/bin/wp-cli cli update --allow-root --yes

# Clean systemlog
/bin/journalctl --vacuum-size=500M > /dev/null

# Remove tmp session files over one day old
find /home/*/tmp -type f -name 'sess_*' -mtime +1 -delete

# Clean fail2ban db
/usr/bin/sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "delete from bans where timeofban <= strftime('%s', date('now', '-90 days'));"
/usr/bin/sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "vacuum;"

If you haven’t checked out the size of your fail2ban and system log databases, its worth doing. I’ve found gigabytes of wasted space in there …

2 Likes
# Remove tmp session files over one day old
find /home/*/tmp -type f -name 'sess_*' -mtime +1 -delete

See /etc/cron.daily/php-session-cleanup done allready daily

find -O3 /home/*/tmp/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1
find -O3 /usr/local/hestia/data/sessions/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1

OK, good to know. That was a hang-over from vesta days, when it didn’t manage to clear those out properly. :slight_smile:

Thanks for sharing @pluto , keep in mind that the sqlite3 database could be in use by fail2ban when you run this script and the database will be locked during that time. You could retry a couple of times to execute the SQL query (with a timeout and a delay between runs)

1 Like

or shut it down, cleanup and restart :wink:

thanks for sharing @pluto let’s see what other suggestions come up.

  • enabling unattended-upgrades might be something to add to the one-time todo list.
  • maybe changing ssh port to avoid ground noise (needs adjusting firewall obviously)
  • also I use AllowUsers to add another level of control on ssh access, though this needs to be adjusted manually each time you add a new user that should be able to use ssh or sftp.
  • setting up something ipset in conjunction with a script that automatically pulls ip-blacklist I also find very helpful

I actually do that as soon as I log into the server, before installing Hestia, and then the install picks it up and writes the firewall rule for me!

OK, a couple more tweaks:

  • Put Apache access control on Hesta CP login, PHPmyadmin, and webmail.
  • Change default webmail skin from larry to elastic. Everyone who uses a phone to access webmail loves that one! :slight_smile:

PHPmyadmin and webmail are running on the server you have selected.

(In my case Apache (+ Nginx Proxy))

The webmail could use more improvements including 2fa, push notifications and many more…

Just thought of another. I like to add additional logging to exim with this line in /etc/exim4/exim4.conf.template. Just a few things I’ve found useful over the years. YMMV.

log_selector = +tls_sni +subject +delivery_size +incoming_interface

Since @pluto mentioned Exim4, it is a good idea to add more blacklisted file extensions.

I opened an issue about it at: https://github.com/hestiacp/hestiacp/issues/1138

Please create a pull request we are open for improvements and for sure some parts can use few improvements.

Hi @pluto I’m happy for your sharing with the community, because it is important for me too, because it is very useful.

@eris
Thanks again, but what this does?

find -O3 /home/*/tmp/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1
find -O3 /usr/local/hestia/data/sessions/ -ignore_readdir_race -depth -mindepth 1 -name 'sess_*' -type f -cmin '+10080' -delete > /dev/null 2>&1

It delete the php sessions created by session_start()…

Speaking of that… I use AbuseIPDB for that. But since the free plan at AbuseIPDB allows only a certain number of downloads per day, I download once per day the DB from AbuseIPDB and save it on a web accessible URL. I then use that URL to download the DB from, from my other servers. It’s not perfect but it works quite well. The only downside is that the free plan at AbuseIPDB can download a maximum of 10.000 blacklisted IPs :frowning: If you’re using another IP DB, please do share.

pick your poison: http://iplists.firehol.org/

:joy:

their level 1 compiles a few well-known lists already and cover quite some ground with 600M+ IPs … I also use level 2, while this isn’t as big it include blocklist_de amongst others, which is quite relevant here.

obviously there is a lot more available to pick from :wink:

1 Like

You must not use this tool from root user, wonder a warning is issued about this. Why? During the update, new files and directories will be created and all of them will have an root:root owner. What happens in this case? PHP interpreter will not have the necessary access to them.

Use the command instead of that:

sudo -u user /usr/local/bin/wp-cli cli update

Change the user for your exact user.

1 Like

But you need to be root user to update the binary, so that’s why I used it in that one specific case.

OK, just thought of another couple of tweaks.

I also like to retain logs for a bit longer than the default settings, so I go into /etc/logrotate.d and change apache and exim logfiles to rotate weekly, and retain for a year. None of my sites are particularly heavily used, so the log build-up isn’t too good.

I also install logwatch to send me daily reports (I write a few custom scripts depending on what I want to see). And I install vnstat so I can look at server traffic from the command line, and incorporate a summary into my logwatch daily report.