Zabbix is running on a Master Node and each Client has an Agent. (Yes the master is an external System)
Zabbix can monitor clients active and passive.
Passive means the Master asks the system for data and the system delivers.
This does not always work within special networks where the master can not reach the client.
Then you use active monitoring then the client reports all data in a certain interval to the master.
There can be a master / slave / proxy setup for big scale monitoring solutions. (Google Zabbix HA Cluster Setup for more details)
The strange part is that there are no bans which is worrisome to me.
So, this doesn't work most because fail2ban itself works by scanning log files and as you said, there is nothing in the auth.log.
Generally, this is outside Cloudron configuration (as in, Cloudron does not configure or update all this on the server). My understanding is sshd logs always to syslog. You can check the Facility with which it logs in /etc/ssh/sshd_config. I think from there it goes to /etc/rsyslog.d/* config files to log based on the facility. Not 100% sure, maybe others can chime in.
There is a bug in the current release that the code crashes when trying to send a notification if a backup failed. This is fixed . I think in the coming releases we can explore more notification options but atleast now you should get an email.
@d19dotca I'm excited by the potential for https://ntfy.sh.
Maybe a cloudron official instance which sets up channels for all customers, so cloudron-generated notifications can be delivered to a customer.
Or maybe there's a better way. I just think ntfy.sh is so easy to implement into scripts.
@lonk no, monthly doesn't make sense apart from an email, like the new Cloudron release emails.
Weekly maybe, but ideally the day it is released.
From there those interested in those can subscribe to the stable Apps or unstable Apps notifications.
I like that. Opting into app updates without having them installed. Often times user's don't want to be the early adopters (I do, but I'm me 😂) so they wouldn't install anything initially, and getting release notifications even though the app isn't installed might eventually prompt them to. It's not even too difficult a change since it already exists for installed apps.
Thank you for the quick reply. But even in my testing environment, telling me my backup method is unsafe once a day is just a hassle to weed them out of the Cloudron update (valuable) notifications. I bet I can just trick Ubuntu into seeing the path as a volume to get rid of the notification.
But for normal Cloudron users, I bet an option to acknowledge and disable the “backup is unsafe notification” would be valuable for them especially in their first non-production use of Cloudron (where I’m personally at for now).