When restoring a full backup from a FreePBX 14 to a FreePBX 17 server, the fail2ban service will refuse to start with error messages related to invalid log paths.
Operating Environment
Sysadmin module: 17.0.1.92
Relevant log output
There appear to be 3 log paths that a FreePBX 14 system uses that are not present on a FreePBX 17 system,
which is expected since these are specific to a RHEL-based system vs a Debian-based system. These appear to
be restored to the SQL database as part of the Backup->Restore process for upgrading from a 14 to 17 server.
Manual changes to the /etc/fail2ban/jail.local file will restore functionality, but the sysadmin module will
overwrite these fixes on the next startup.
Example error from /var/log/syslog:
[3017]: ERROR Failed during configuration: Have not found any log file for apache-badbots jail
SQL sysadmin_fail2ban table before fixes:
MariaDB [asterisk]> select * from sysadmin_fail2ban
-> ;
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
| id | filter_owner | filter_rule | logpath | opt_name | opt_port | opt_protocol | active |
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
| 1 | asterisk-iptables | asterisk | /var/log/asterisk/fail2ban | SIP | | all | 1 |
| 2 | pbx-gui | freepbx | /var/log/asterisk/freepbx_security.log | PBX-GUI | | all | 1 |
| 3 | ssh-iptables | sshd | /var/log/secure | SSH | ssh | tcp | 1 |
| 4 | apache-tcpwrapper | apache-auth | /var/log/httpd/error_log | apache-auth | | all | 1 |
| 5 | vsftpd-iptables | vsftpd | /var/log/vsftpd.log | FTP | ftp | tcp | 1 |
| 6 | apache-badbots | apache-badbots | /var/log/httpd/*access_log | BadBots | "http,https" | tcp | 1 |
| 7 | apache-api | apache-api | /var/log/apache2/*access.log | api | "http,https" | tcp | 1 |
| 8 | openvpn | openvpn | /var/log/openvpn.log | openvpn | 1194 | udp | 1 |
| 9 | sshd | sshd | /var/log/asterisk/fail2ban | sshd | ssh | tcp | 1 |
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
Fixing this is pretty straight forward, but requires manually editing the SQL database:
UPDATE sysadmin_fail2ban SET logpath = '/var/log/auth.log' WHERE filter_owner = 'ssh-iptables';
UPDATE sysadmin_fail2ban SET logpath = '/var/log/apache2/error.log' WHERE filter_owner = 'apache-tcpwrapper';
UPDATE sysadmin_fail2ban SET logpath = '/var/log/apache2/*access.log' WHERE filter_owner = 'apache-badbots';
SQL sysadmin_fail2ban table after fixes:
MariaDB [asterisk]> select * from sysadmin_fail2ban
-> ;
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
| id | filter_owner | filter_rule | logpath | opt_name | opt_port | opt_protocol | active |
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
| 1 | asterisk-iptables | asterisk | /var/log/asterisk/fail2ban | SIP | | all | 1 |
| 2 | pbx-gui | freepbx | /var/log/asterisk/freepbx_security.log | PBX-GUI | | all | 1 |
| 3 | ssh-iptables | sshd | /var/log/auth.log | SSH | ssh | tcp | 1 |
| 4 | apache-tcpwrapper | apache-auth | /var/log/apache2/error.log | apache-auth | | all | 1 |
| 5 | vsftpd-iptables | vsftpd | /var/log/vsftpd.log | FTP | ftp | tcp | 1 |
| 6 | apache-badbots | apache-badbots | /var/log/apache2/*access.log | BadBots | "http,https" | tcp | 1 |
| 7 | apache-api | apache-api | /var/log/apache2/*access.log | api | "http,https" | tcp | 1 |
| 8 | openvpn | openvpn | /var/log/openvpn.log | openvpn | 1194 | udp | 1 |
| 9 | sshd | sshd | /var/log/asterisk/fail2ban | sshd | ssh | tcp | 1 |
+----+-------------------+----------------+----------------------------------------+-------------+--------------+--------------+--------+
The restore process probably needs some logic to see if these are set to invalid paths during the restore
or perhaps just hard-coded to be set to the valid Debian-based paths on a restore for a 17 system.
jissphilip
commented
1 month ago
FreePBX Version
FreePBX 17
Issue Description
When restoring a full backup from a FreePBX 14 to a FreePBX 17 server, the fail2ban service will refuse to start with error messages related to invalid log paths.
Operating Environment
Sysadmin module: 17.0.1.92
Relevant log output