FreePBX | Register | Issues | Wiki | Portal | Support

Moving to a temp server while existing being rebuilt (licensing)


#1

Question for the masses. I’ve had some issues in the past as we were initially experimenting with Google Compute Engine (various changes to hardware ended up resetting ZendID) so I’ve had to have the nice folks at FPBX reset it (since we ate our 3 resets). During my conversations with them about that, I specifically said how frustrating it was that I couldn’t use the DEACTIVATE button to “check back in” the licenses so they could be reactivated on a different box, and I was told that’s just kinda how it was. I specifically stated that if that’s true, it kinda makes the deactivate button pointless.

I’m looking at that button right now, and it specifically says what I had hoped it would represent (the ability to check-in for moving to another box).
“You only need to use this button if you want to move this deployment to another, different, server.”. I recalled trying it once and although it deactivated the current box, it did not allow reactivation on another box.

So, here’s my question. We have a customer who is currently running FPBX13 on VMWare, but we now want to load it on it’s own box (as the other VMs have been migrated off that VM Host). When we do this, we’ll obviously be wiping the drive, but more importantly, moving FPBX from a virtual to physical machine, the hardware IDs will certainly change and it will be considered a different installation instance. IF I deactivate before wiping, and then reactivate after I’m done with the reinstall, should I be able to activate without a Zend Reset? We’re out of Zend Resets on that instance (because of the previously-mentioned migration/moving, etc (we also had such an issue when initially loading this in VMWare when we installed it). What I don’t want to have happen is we deactivate it, then try to activate it after it’s been rebuilt and can’t, but then have no way to contact support to have it reactivated until the following week. I really want to understand the DEACTIVATE button’s true function, as I’ve got an email thread that seems to conflict with the button’s own labeling.

Please advise.

Thanks.


(Dave Burgess) #2

There’s a process for changing the hardware out from under an existing system. In fact, Lorne just posted a link to the instructions for changing the site code on the fly.

If you need another ZEND reset, just post a request for support in the Support tab - the Sangoma folks have been pretty good about resetting those for everyone I’ve ever heard about.


#3

I scrolled through Lorne’s recent posts and didn’t see a subject that seemed to match - by chance do you have a link to it?


(Lorne Gaetz) #4

Provided you have not exhausted your 2 resets, you can move your deployment ID to new hardware using this method:
https://wiki.freepbx.org/display/FPAS/How+to+Move+a+PBX+Deployment+to+a+New+PBX

Once you’ve used your two resets, then you must open a customer service ticket and request it be reset for you.


#5

Right - that was my complaint all along. If I’m actually selecting on the system to DEACTIVATE, that should NOT affect my zend hardware reset count - I’m essentially de-authorizing that deployment in order to move it. A zend reset from the purchasing portal should only be for if the existing deployment is unrecoverable and you can’t use DEACTIVATE to move/migrate it. But when I hit DEACTIVATE, it should “check back in” my licenses allowing me to move them to the replacement machine.

The problem is (and yes, we already exhausted those 2 resets), opening the support ticket in off-hours (when a customer would want this work done), likely won’t be answered until the next business day, and the inability to check-in the license manually impedes off-hours work from being done. (sigh).

So, basically, with no zend resets remaining, there’s no way to migrate this in the off-hours (I can’t have the reset done early or the system will go unlicensed at some point when it trues up its licensing - doesn’t it check every so often?)…


(Erik Walthinsen) #6

I have to agree with this. If one is either moving the deployment to a new machine (either because the old one isn’t fast enough or is failing), there should be zero penalty for explicitly deactivating the licenses on the first machine before activating them on the replacement machine. Penalizing your customer for doing performing what is a common maintenance procedure just is NOT COOL.

The only time I should have to beg Sangoma for the ability to activate a paid-for license on a new server is if the machine the deployment is licensed for was burnt so badly that it cannot cleanly communicate with them and cleanly release the licenses in preparation for the move. That’s where “zend resets” should be a limited “resource”, and only there.

At this point I haven’t even rolled out a new PBX to my church, and for some reason I’m already at 1 reset remaining. For various reasons learned in the process of setting up the system in the first place, I’m now planning on moving the deployment to a VM, which to my understanding will leave me with ZERO resets. If that VM becomes damaged in any way and requires a rebuild, I will be completely screwed until Sangoma deigns to give me another reset, which is not acceptable. More immediately, if I determine during the process of building the VM up that for one reason or another it ends up not actually being a good idea, I’ll be screwed again unless Sangoma takes pity on me. I must activate the VM deployment, because in order to even consider placing this PBX in the “cloud” I must have VPN functionality, which is a licensed feature. I also must be able to validate EPM functionality in relation to the VPN.

EVERY other “seat”-based licensing system out there (I’m specifically referring to things like $1M software packages used for e.g. chip design, etc.) has a continuous check-in/check-out mechanism, with zero penalties for moving the license. FreePBX should be exactly the same.


(Tony Lewis) #7

We have no ability to know the license has been removed as we don’t have phone home stuff so even though we remove the license file on the machine we have no way to keep you from just putting it back from a backup and since we don’t force a phone home license update we have no way of truly taking back the license from the machine once it has it which is why we give you 2 resets but as we know their are plenty of abusers who run that same license on 2-3 machines using resets it does not make us want to give even more resets. If we move everything to 1 year license than it becomes a moot point.


#8

Tony, I really think this needs to be fixed. Right now, my FreePBX has some issues, and I’d really like to migrate to a clean install but I don’t want to waste one of my 2 moves. And when I upgrade to new major versions, I’d rather migrate to a fresh VM. Like you said, if FreePBX would do some basic phoning home for license purposes, then it would eliminate the majority of simple cheaters and we could get rid of that 2-times limit. For the more advanced cheaters, please understand that all software gets cracked so any restrictions only affect your good customers who pay, while the crack users enjoy a better experience than us. Please let us follow best practices without fear of downtime.


#9

In r14, it looks like there’s actually a daily CRON job to confirm the licensing is still valid on a given box (I don’t know if that was also on r13).

Now, I’m not sure if there are still ways for the crafty thieves to work around it, but it looks like, with that, there’s the potential to actually make a checkout/checkin licensing mechanism and have a decommissioned system check within a day to shut down…

@daily [ -x /var/lib/asterisk/agi-bin/update_license.php ] && /var/lib/asterisk/agi-bin/update_license.php --delay


(Andrew Nagy) #10

Nope. It will simply download a new license file if one is available. Licensing is checked locally, not remotely.


#11

And if licensing was removed for an instance - or rather, moved to a new ID, wouldn’t the nightly downloaded license then be invalid on that box?


(Tony Lewis) #12

The problem is in the license file itself. When you buy a 25 year module from us the license is set for 25 years. We don’t ever verify after the 25 years as people screamed at us when we use to that if I have something for 25 years it should not phone home.

We can’t just say hey when you phone home deactivate the licnese as you can just not phone home and have the license work for 25 years.
You will be amazed the number of cheats we have that try and cheat the system already.


#13

Just thinking of possible solutions: You could just require the phoning home and explain that it’s for good reason. Or, to make everyone happy, you could make the phoning home an opt-in thing so that people can choose either a two-transfer limit or an unlimited limit with phoning home.

Like I said though, advanced cheaters can simply crack whatever protection you build in, so please prioritize the needs of your paying customers over the never-ending effort of blocking the cheaters. I’m afraid to do a clean install because of the current limits. When I play video games, I never use my potions or single-use scrolls since I don’t want to waste them.

Thank you


(Andrew Nagy) #14

All you have to do is message support and they will take care of you. Even past the 2 limit. It’s the same for Microsoft. You have a limit of a certain number of activations (was 2) if you go past that just call them and explain and they give you another one.

Scanning through this thread it appears you haven’t even asked support about the issue you are going to face. Which means they could have just reset the limit for you to proceed with this. This is why you should ask them instead of speculating.

To be honest. This isn’t a priority. Instead we are slowing upgrading our backend licensing system to work with PHP 7+ which zend doesnt support. So perhaps Zend resets won’t exist at all. But that is speculating as well.