FreePBX 15.0.16.44 On AWS Ubuntu 20 With Asterisk 16 Failing To Install

configuration
Tags: #<Tag:0x00007f7029bfb080>

(Terry Mc Mahon) #1

Hi Folks
I noticed this problem from years ago and the solution was that it was fixed in 15.0.16.22. BTW I forced an install of 15.0.16.22 and it still failed…

In Encoding.php line 196:

Array and string offset access syntax with curly braces is deprecated

chown [-f|–file FILE] [-m|–module MODULE]

In Process.php line 239:

The command “/usr/sbin/fwconsole chown” failed.

Exit Code: 255(Unknown error)

Working directory: /usr/src/freepbx

Output:

Error Output:

Any pointers or solutions would be greatly appreciated before I flatten the EC2 Instance and go down another path :slight_smile:


(Matt Brooks) #2

Well, this is a PHP error. FreePBX does not currently support PHP 7. I believe you’ll need to install PHP 5.6 in order to fix the issue. You can verify what version of PHP you are running with the command: php -v


(Terry Mc Mahon) #3

Cheers Matt
I have been following an idiots guide to install asterisk 16 with freepbx 15 on ubuntu and it installs php 7.4. Now I know where to look I can fix it.
Cheers again


#4

Perhaps you could possible correct that by saying that the commercial components of FreePBX Don’t support php 7 and still require 5.6 (which went end of life Jan 31 2019)

Those of us quite happy with Opensource FreePBX find it currently sings along fine with all the way up to php 7.4.

edit:- I will adjust that All the way up to PHP 7.3 the above noted deprecation notice will get displayed by php 7.4 , the default php in ubuntu 20.04

It is noted that deprecation is not a deal breaker, just a warning to ‘get off the pot’ .


#5

7.4? My install bombs out with 7.4 on Ubuntu 20.04:

In Encoding.php line 196:
  Array and string offset access syntax with curly braces is deprecated

5.6 - 7.3 from sury.org are successful.


#6

Yep, I agree. it’s broken on 20.04 with 7.4


(Matt Brooks) #7

Like I said, FreePBX doesn’t currently support PHP 7.

There is a difference between being able to run on PHP 7.x versus being supported and it has nothing to do with our commercial modules. Sangoma will not provide support for FreePBX running on PHP 7.x at this time. There has been zero testing for PHP 7.x. This means if you are running FreePBX on PHP 7.x, this is an unsupported configuration and at some point it may give you a ‘bad time’. This also means we may not fix any of these issue for a while. Basically, you’re on your own.

Of course this is not the world I want I want to live in. I would love to say, yay we support PHP 7.x, install it world! But that’s just not where we are at this present time.

That being said, working on support for PHP 7.x is one of the top priorities for the FreePBX team. But it’s not going to be before the 16.0 release.


#8

I totally understand that Sangoma won’t support PHP beyond 5.6 but we are in 2020 and 5.6 is kinda RIP, no?

(My understanding is that the commercial modules are zend guard encrypted and apparently because zend guard is not available beyond php 5.6 then that’s a kinda Catch-22 if you need commercial modules but as this thread is rooted in Ubuntu, Commercial modules are moot anyway as until perhaps V16 they are just not a thing)

We who go ‘off the reservation’ are generally more than happy with FreePBX and all the patches from @billsimon that apparently have been accepted, and tested at least by some parts of the ‘community’

So

.
.
I believe you’ll need to install PHP 5.6 in order to fix the issue
.
.
.

is perhaps one way to get support for a FreePBX not running in a Sangoma environment, yet it comes with the intrinsic peril of using an end of life , hence considered insecure PHP.

Another way moving forward is to wait for Bill to get to 7.4 , or do a suri install of php 7.3 into Ubuntu 20.04, or (my preference) stay with Debian/Buster for a while which has 7.3 as its default PHP

A quick google suggest that the fix is as simple as replacing {…} with […] in those two files then updating the ‘signature’ behind said files


#9

If the changes required for php 7.4 are backward compatible to 5.6 they should be found acceptable by the development and QA teams. Go for it, @dicko, @jerrm, or @TerryMcMahon. I don’t have a system right now where I am wanting to move up to 7.4.

I had believed that the patches I submitted for PHP 7.3 did receive QA testing in order to progress through the release pipeline, so I am surprised at the statement about “zero testing,” though still fully understanding of the position not to give it full Sangoma support.


#10

Not a PHP guy, but so fixing

/var/www/html/admin/libraries/BMO/Media.class.php:283

springs

In Less.php line 5160:
                                                                                                                    
  The behavior of unparenthesized expressions containing both '.' and '+'/'-' will change in PHP 8: '+'/'-' will take a higher precedence                                                                                           

(Quite happy to stay with 7.3)


#11

Same here for now. My script is good for Debian amd64/arm64, Raspbian and Ubuntu 18.04/19.10 amd64. Kind of hoped it would “just work” with 20.04. Came close, but will have to fallback to sury for php. Not a big deal. Debian is my preferred anyway. Even on a Pi, Raspbian is just a host for a Debian arm64 container.


#12

The nicest thing for me using 20.04 as a host is a rock solid built in lxd/lxc and zfs, it makes containerization a piece of piss,

lxd init #(accept the defaults)
lxc launch images:debian/10/cloud fpbx 
lxc exec fpbx bash

and you are ready go with 7.3


(Matt Brooks) #13

The patches you submit were tested by QA, but I am fairly certain they were tested against php 5.6 and not against 7.x.


#14

Of course, makes sense.


(system) closed #15

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.