Customer: Everybody needs Connect - they WILL use it…
Me: Ok - Are you sure? Let’s just get you enough licenses to start out with, and we will see how it goes?
Customer: No, Everyone must use it - buy them all.
Me: Ok - Done.
Customer (Three days later): Oops - I guess we only need half of what we bought - oops!
I don’t want to return the license, but is there any way to move it to another deployment? If not, I will make the impatient customer suck it up - but It would be cool if I could use it on a different deployment.
Generally module licenses stay with the deployment permanently. But mistakes do happen, so purchases that are assigned to the wrong deployment can be moved if a customer service and billing ticket is created immediately after the purchase.
What is the problem with issuing license keys for every module? One of the main issues with migrating in with commercial modules.
We’d gladly purchase a spare key for every commercial module so we can temporarily assign to ensure that the new VM is fully working.
I remember the previous team saying that once you license EPM, the config and provisioning files will stay on the PBX even if you remove the deployment ID. So that’s why the licensing works that way, and that’s why EPM has no trial.
Well, how hard it is to store the endpoint config in a DB and generate them on the fly when it is being requested? That way, you can control what is being generated etc etc etc.
For example:
create a index.php that handles all the requests in /path/to/provisioning/folder/
Anyone can still create custom files and drop it in that folder. If the file requested doesn’t exist in that folder, index.php will serve the config generated from a DB.
The policy I was referring to is Sangoma being willing to move a license if you screw up (like this customer did) - not the overall licensing in general. That is a different subject.
One could also equally suggest that ftp and http provisioning also be dropped, both are only marginally more secure than tftpd , (but that will surely raise a howl or two )
I find it really frustrating that as my phones get older, they get less and less maintained with the current standards - I have committed to PJSIP on a weird, high port, locked down all access to the boxes to only HTTPS encrypted connections and tried to switch to HTTPS provisioning - Polycom VVX’s work fine with it - Grandstreams once their firmware is current, but older Yealinks are really hit and miss - 4XG’s have a problem with the default Key Size for Let’s Encrypt on FreePBX 15 so you either need to hack the generation script to get a smaller keyed cert, or fall back to insecure provisioning.
This comes under “Right-2-Repair” - If a manufacturer declares a product end-of-life, they should be forced to post (and maintain access to) the source code for the firmware binaries so that stupid things like the key size whacking the Yealink’s and Grandstreams can (hopefully) be fixed.
Right now, it’s throw the phone away or contort yourself into a pretzel to get them working - that is just WRONG!
The key size change makes it work with the current LE process that FreePBX 14 and 15 uses on SNG7.
But the unaltered process worked with the RSA-4096 key size in FreePBX 13 (CentOS 6).
You may also want to educate yourself a little on WTF RSA key sizes mean. There is almost no difference in a 2048 and 4096 length RSA key.
Here is a simple description from 2015 on the subject.
And the largest known (according to cited material) RSA key to be cracked is not even the no longer accepted RSA-1024.
)