Backup/Restore

[guenni]

I repeatedly did a full restore from a backup made some minutes ago.
Even if I de-select “contactmanager”, contact manager tables are in the backup. And they are quite wrongly restored whithin the restore process.
From restore-log (KVStore can not be de-selected):

Processing contactmanager
Resetting contactmanager module data
Remove all contact manager tables
Dropping table contactmanager_groups…Done
Dropping table contactmanager_group_entries…Done
Dropping table contactmanager_entry_speeddials…Done
Dropping table contactmanager_entry_numbers…Done
Dropping table contactmanager_entry_images…Done
Dropping table contactmanager_entry_userman_images…Done
Dropping table contactmanager_entry_xmpps…Done
Dropping table contactmanager_entry_emails…Done
Dropping table contactmanager_entry_websites…Done
Updating tables contactmanager_groups, contactmanager_group_entries, contactmanager_entry_speeddials, contactmanager_entry_numbers, contactmanager_entry_images, contactmanager_entry_userman_images, contactmanager_entry_xmpps, contactmanager_entry_emails, contactmanager_entry_websites…Done
Generating CSS…Done
Restoring from contactmanager [FreePBX\modules\Contactmanager\Restore]
Importing KVStore from contactmanager

Instead of restoring the contact-manager-group “external” with 3,000 single entries, the restore creates 3,000 “external” groups. Each has only one entry. However, freepbx can not handle 3,000 groups with the same names. So there seems to be a bug in the dump tables script of the backup, or a bug in restore procedure.
Any one who can repair this?
The only help for this so far is to deinstall contactmanager afterwards, and install it new and empty.

[lgaetz (Lorne Gaetz)]

If this is reproducible in the current edge version of the backup module (15.0.10.33) then please open a ticket at https://issues.freepbx.org/

[guenni]

ok. I’ll check the module versions.
Thanks so far.

[guenni]

I do not have the latest edge version. Only 15.0.10.28 release.
Do you think I shall wait with my ticket until .33 is released?
By the way can you help with my firewall (possible) issue?
The quartely asterisk cronjob stopping and starting the firewall often results in gui screen, where firewall is marked as disabled. From my earlier knowledge with iptables, I’ m aware that there should be a small break between stopping and starting, giving the system enough time to stop before the restart.
Could you help in changing my crontab by including something like ‘wait 10’ or so?
*/15 * * * * [ -e /etc/asterisk/firewall.enabled ] && touch /var/spool/asterisk/incron/firewall.firewall

I’m not the real scripting hero.
Is it really nescessary to have this quarterly cronjob? Or would it helpfull to uncomment the restart line in /etc/logrotate.d/fail2ban
error in fail2ban.log:
2020-09-01 19:21:29,471 fail2ban.jail [29259]: INFO Jail ‘recidive’ stopped
2020-09-01 19:21:30,472 fail2ban.jail [29259]: INFO Jail ‘ssh-iptables’ stopped
2020-09-01 19:21:31,243 fail2ban.jail [29259]: INFO Jail ‘apache-badbots’ stopped
2020-09-01 19:21:31,779 fail2ban.actions.action[29259]: ERROR iptables -D INPUT -p all -j fail2ban-SIP
iptables -F fail2ban-SIP
iptables -X fail2ban-SIP returned 100
2020-09-01 19:21:31,966 fail2ban.jail [29259]: INFO Jail ‘pbx-gui’ stopped
2020-09-01 19:21:32,783 fail2ban.jail [29259]: INFO Jail ‘asterisk-iptables’ stopped
2020-09-01 19:21:33,690 fail2ban.jail [29259]: INFO Jail ‘vsftpd-iptables’ stopped
2020-09-01 19:21:33,693 fail2ban.server [29259]: INFO Exiting Fail2ban
2020-09-01 19:21:34,577 fail2ban.server [29998]: INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.14
2020-09-01 19:21:34,579 fail2ban.jail [29998]: INFO Creating new jail ‘asterisk-iptables’
2020-09-01 19:21:34,584 fail2ban.jail [29998]: INFO Jail ‘asterisk-iptables’ uses Gamin

Deleting the SIP-line all the times creates an error message. In iptables -nvL there is no specific SIP-rule.

[guenni]

Lorne, I made a report today. Even .33 version has the same backup-restore error.
Firewall is now working again since I started it via CLI.