Trying to activate a new FreePBX 13 installation. Was AsteriskNOW, then upgraded to FreePBX 13 UI. Didn’t activate under 12, as far as I know and now trying to activate 13.
Same as a few other forum posts here where you hit the Activate button, and things start thinking then the page reloads to the same Activate page. Nothing more, and no errors in logs.
I can see from a packet trace that the box attempts to communicate to 199.102.239.11 on port 443. It seems that this communication is bidirectional, as I can see that IP sending back to me during the transaction. I cannot ping that IP though.
Anywhere that this stuff is logged so I can see what’s failing in the Activation attempt?
Do MAC addresses have anything to do with activation? This PBX is running in an OpenVZ container, and I’ve had problems before where MAC address is used to identify the machine.
Maybe if I can call on @xrobau as I have an iptables problem too - would like to check out your iptables UI module but until I fix up this possible kernel module problem in iptables I’m not going to try…
The issue is we do not support OpenVZ as we only support Activation and Commercial Modules with our Distro and to install in OpenVZ means it would not be our Distro anymore.
That’s fair enough that you don’t support OpenVZ containers. But, can you provide any more details on the Activation process so I can troubleshoot it? Does it log to a file anywhere? Does it identify machines based on MAC address, or some other method of generating a unique ID? Is this unique ID generated at install time?
As per my original post, I can see that there is communication on https with (I assume) the activation server. I’ve been through other posts, ensured DNS is set correctly and etc but no luck. OpenVZ aside, I’m looking for information to get to the bottom of this or something that will let me know that the OpenVZ container is the problem.
Or, are you saying that Activation just doesn’t work with an OpenVZ container?
Your machine is tied to the Zend ID, which is generated by Zend Guard. We don’t really have any control over that, unfortunately.
The easiest answer for you is to just not do what you’re doing and install the standard Distro ISO into a normal VM. That will work, and everything will be fine. When you try to hack around problems that you discover by doing things another way, you end up chasing rabbits for weeks, that could have been avoided by just doing it the correct way in the first place.
No, I’m not interested in trying to make it work if it’s not meant to. I’m not at all interested in creating support headaches for myself.
So then, apart from support and commercial module licensing - is there something killer that I need to activate for? Something like, if not activated X doesn’t work, and without X you’re dead. We don’t plan on using any commercial modules. We’ve been using OpenVZ with Asterisk 11 for a while now without any hiccups, so far.
In that case, you’re 100% fine - if you don’t need commercial modules or Firewall, there’s no need for activation.
Support may or may not be able to help you on an OpenVZ container. They tend to shy away from it, because it can cause a bunch of really crazy issues that will end up having them spending hours chasing, only to find out it’s nothing wrong with Asterisk or FreePBX.
Firewall would’ve been nice but managing iptables from the console (which is what we currently do) isn’t a big deal at all.
I’ll keep it in mind that there could be some unforeseen problems with OpenVZ during my testing. We’ve had excellent results with earlier versions, and so far everything in 13 has just worked. Perhaps I could find more problems if I were using more features, and straddling into the Unified Communications space but up until now we’re only sitting in IP-PBX space. (if that made sense).
Unoffically, you might be able to get OpenVZ to work with Firewall, but there’s at least one kernel module (xt_recent) that is incompatible, that is used with the responsive firewall.
If you feel like spending some time getting it working, I’d love some pull requests 8)
