tl;dr: FreePBX deployment can disassociate just by assigning an IP address to a previously-unused interface, without making any hardware changes. Assign IP addresses to all of the ethernet interfaces before activating FreePBX and set them to Start Automatically, even if those interfaces are not connected.
Spontaneous Deactivation
The issue of “spontaneous deactivation” of FreePBX installations has been a problem with FreePBX for years; e.g.: Our deployments became not activated after enabling a second Ethernet interface . It matters because purchases of Sangoma commercial modules are tied to a specific Sangoma Deployment ID, and upon activation, a Deployment ID is supposedly tied to a specific machine. Sangoma allows you to break the connection between a Deployment ID and the specific machine twice, but after that, the Deployment ID (and the commercial modules attached to it) cannot be changed to a different machine.
The problem is that it is not necessary to make ANY hardware changes to a machine to inactivate the Deployment ID’s connection to that machine, and after those two resets, either you must abandon the value of the commercial modules you have purchased, or ask Sangoma support to allow an additional reassignment.
Like others, I set up a machine in the lab, but when I took it to production, I found that the Deployment ID no longer worked with the machine, in spite of there having been no hardware changes to the machine whatsoever. Therefore, I have put this information together based on my testing, to save others (and my future self) time when this comes up again.
Zend Guard and Zend Host ID
It appears that this is due to the use of a product called “Zend Guard” to protect the Sangoma commercial modules. Zend Guard calculates a “Zend Host ID” based on the hardware, and that Host ID is what is tied to the Deployment ID. The Host ID tied to the Deployment is visible on the Edit Deployment page on the Sangoma Partner Portal, and there is a button to disassociate it on that same page (although that button did not work for me). There is apparently a zendid executable available from Zend to determine that ID for a specific machine. The only place I found that executable was by downloading the Linux Zend Guard installation and looking inside the tar file. However, I have not attempted to use the zendid program.
However, it looks like there are several Zend IDs for a specific machine, and as described at https://www.setasign.com/support/faq/zend-guard-loader/how-to-get-the-zend-id/#question-70, you can most easily see the list of Zend Host IDs for a FreePBX machine by creating a small php file containing:
<?php
echo '<pre>';
print_r(zend_get_id(true));
And saving that (perhaps as zendid.php) at /var/www/html on the FreePBX server. (For security reasons, you should probably remove that file once you are done with setup, or it could allow potential intruders too much information about your system.) Make sure that permissions allow the asterisk user to read the file, and then go to /zendid.php on the web interface, to get a list of the Zend IDs. As pointed out on the page referenced above, there are several types of Zend IDs, each type prefixed with a letter and a colon:
H: Hard Drive ID.
M: Network Card (MAC Address ID).
I: IP address
L: Libraries
In my testing, I get one M and one I for each ethernet interface with an IP address assigned (plus a single L), but I got no Zend IDs for ethernet interfaces that did not have an IP address assigned or were not up. It appears that the list of Zend IDs is in alphabetic order of the interface names, and the Host ID assigned to the Deployment seems to be based on the first “M” (MAC) one found.
Relationship to activated ethernet Interfaces
My FreePBX box has a single built-in ethernet interface, and also has a four-port ethernet card installed. The four-port card is assigned eth0 – eth3 during boot, and the built-in interface is assigned eth4. So, it appears that whichever interface, eth0 through eth4, is the first one that has an IP address assigned and started, is the interface that determines the connection between the Deployment ID and the machine. It does not appear to matter which interface was used when the Deployment ID was initially tied to the machine using the web interface.
In my case, I had used the built-in (eth4) interface to set the machine up in the lab, and when I later started using one of the other ports, that port (with a lower “eth” number) then determined the Zend ID, which was now different, and the Deployment would no longer work.
What to do before activating your FreePBX
For me, the solution appears to be to assign static IP addresses to all of the ethernet interfaces (or at least to eth0) before activating the Deployment to the machine. I did not have luck using the System Admin module for that, because (1) the newly-assigned IP address would not appear in the System Admin page, and (2) when the IP assignment was successful, and a lower-numbered ethernet port had been configured, the Host ID changed and the machine immediately deactivated and would not allow me to use System Admin any longer.
The easier solution for assigning the static IP addresses was to edit the /etc/sysconfig/network-scripts/ifcfg-eth* files to read something like:
DEVICE=eth0
BOOTPROTO=static
ONBOOT='yes'
IPADDR=192.168.11.3
NETMASK=255.255.255.0
DEFROUTE=no
The DEVICE entry should be named for the appropriate ethernet interface, will be different for each file, and that line should already have been added to the file. I had better luck using different subnet addresses (the third octet of the IP address when this netmask is used), but the ports did not need to be connected to anything. I used DEFROUTE=no so that the default route in the routing table is not impacted, especially if I later used dhcp for one of the interfaces.
How to Force a Port to be Ignored for the Zend Host ID
If you want a port to be ignored for the purposes of the Zend Host ID, change ONBOOT to ‘no’ ; if you do that for eth0 and go the System Admin module, you will be able to deactivate the machine (so it can be activated to a different deployment) without using one of your two deactivations. Then, change it back to ‘yes’ and reboot to associate to a different Deployment ID. (I was not able to get the deactivation to work from the Portal, so I used this trick to get back and activate my old deployment, and then deactivate it from the FreePBX System Admin page.)
Then, after a reboot, you should be able to assign a Deployment ID, and unless you later change which ports have IP addresses assigned, the activation should not change.
The above is, of course, just my hypothesis, and additional testing by others may reveal my mistakes, but hopefully this will save us some time. Sorry for the long post, but this is what I wish I knew before I activated my FreePBX. Please add your comments.