Managing Trunk State with Backup/Restore

FreePBX Development
1

Greetings,

I’d like to propose a modification to core in terms of managing trunk status.

Presently there is a “Disable Trunk” with a checkbox. The setting of this is stored in the trunks table under the column disabled of type varchar(4). I’d like to propose that this be changed to “Trunk Status” in the GUI and a pop-up menu with the values:

Enabled - Trunk will be enabled on both primary and backup Primary Only - Trunk will be enabled on primary only. Backup Only - Trunk will be enabled on backup only. Disabled - Trunk will be disabled on both primary and backup.

In the database the values would be stored with the corresponding values:

Enabled - on Primary Only - pri Backup Only - bak Disabled - off

In the processing the values of ‘pri’ and ‘on’ will be interpreted exactly the same. If a trunk is set to ‘pri’ on any system, the trunk will be enabled. Similarly, the values of ‘bak’ and ‘off’ will be interpreted exactly the same. There is nothing in the processing of these values which needs to know if the configuration being built is on the primary or the backup.

The remote backup and subsequent restore process would then handle the new values. Prior to the freshly “restored” configuration being applied on the backup system the database is adjusted with something like:

update trunk set disabled = 'on' where disabled = 'bak'; update trunk set disabled = 'off' where disabled = 'pri';

There should be no modification of the trunks with disabled entries of “off” or “on” through this process. At this point the freshly “restored” configuration can safely be applied.

The benefit from this change: SIP trunks for both primary and backup could be defined on the primary system with states that reflect their usage. Both systems can have the same configuration beyond the trunk state. Both the primary and backup trunks could then be defined in the Outbound Routes and the rest of the configuration would be the same. This should take us closer to a HA solution.

An alternate to this is to modify the 2.8 Backup/Restore module to add a hook that will be executed on the non-primary system. This will allow l33t an opportunity to do more customized fiddling of the database directly (as well as other system things like aastra scripts?). This hook would similarly need to be called just prior to automatically applying the configuration. The exit value of the hook could be ignored or a non-zero exit status would prevent the auto-applying of the freshly “restored” configuration.

Thank you for this consideration,

2

The concept is a good one.

A few questions come to mind that could/would create confusion:

Restoring a backup set manually on either a local or remote server, does the backup script have any idea of the current state? (Is this a remote server or not and thus what should I do?)

Depending on the above, does this only happen when choosing the remote backup option with the Restore to this Server checked.

Do we need to add an option in the restore process that allows the user to tell it to treat the restore as if it were a remote backup thus applying the rules above?

3

In my proposal the only time any change is made to the configuration after a restore is when the “Restore to this server” option is checked in the “Remote Backup Options” – as you note.

I don’t think a manual restore would need to options treat the backup as a remote restore. Being applied manually, the trunk reconfiguration could be done by the administrator prior to applying the restored configuration.

Other consideration? Are there other parameters which could benefit from such handling other than trunks?

There is a blog which describes license key files (FAX for Asterisk and G.729 are examples) or possibly manipulating the hostid of the system. I think the backup server needs to be independently licensed. The primary’s license files may be copied to the backup server but I don’t anticipate them to activate on the backup server.