habe mir das Ubuntu 22.04.3 LTS und das aktuelle Asterisk 20.5.0 !
Dies lief ohne Probleme !
Nun aber wollte ich das FreePbx installieren, laut Anleitung die Version 16.
Die meldete natürlich einige PHP Fehler , da ja PHP V 8.1 installiert wurde.
Dachte ersetze die 16 durch die 17 und siehe da es funktioniert !
Also habe ich jetzt FreePBX 17.0.14.2
Alles funktioniert , nur ein paar Module unter der Ver 17 funktionieren leider nicht.
Das schlimmste ist , das RingGroup Modul !
Whoops\Exception\ErrorException: Optional parameter $grppre
Hab dort nur 16.0.11 zur Verfügung , doch schon gelesen das es 16.0.28 geben soll, aber wo ?
17 at best is under early development. From posts by @lgaetz they will be taking the distro in a direction similar to what you have but I am going to be honest. That is optimistically probably a year off if not more. You can file bugs at https://issues.freepbx.org and if motivated work through php 8 bugs on oss modules to help speed things along.
does not look promising due to the code possibly only php 7.4 compatible not latest php 8
Mit 17 hatte ich nicht viel Glück. sieht nicht vielversprechend aus, da der Code möglicherweise nur mit PHP 7.4 kompatibel ist, nicht mit dem neuesten PHP 8
working on debian 12
asterisk 18 Latest
and freepbx 16 latest
Thats the only way it can be done. There is no migration path from EL to debian based systems in any realm. That said unlike the old days they systems are pretty simular from a administrator perspective.
One of the reason to moving to Debian is to finally be able to have inline migrations and updates.
So for now, yes, backup and restore is the only way.
After 17, we get to ride Debian inline upgrades.
So what is the real timeline for this stuff, really? I have been trying all of 2023 to get some place in development with FreePBX 17 and have had nothing but issues with both the distro and non-distro development environments that are supposed to be used for FreePBX.
@lgaetz@ncorbic What about Marco’s in FreePBX 17? Clearly those will be removed but how is that going to impact the included macro calls that users have been told to use for years upon years. How are those changes going to be addressed for the user base?
Macro() appears to be removed from the default dialplan as installed by the EDGE tarball. There are still some contexts starting with macro- but they were migrated to be executed by Gosub(), for example in extensions.conf:
[from-internal]
include => from-internal-noxfer
include => from-internal-xfer
include => bad-number ; auto-generated
exten => h,1,Gosub(macro-hangupcall,s,1)
Well for some folks there is 15+ years of centos centric scripting and administration. This is a good time to break old stuff as there will be some learning curves for certain people. I imagine this is one of the delays actually. All the scripting for things like sysadmin is for EL systems and has to be migrated to debian. This is long over due. I would recommend people who have a vested interest in FreePBX build “official” dev platforms as early as they can. Start fixing stuff now then it won’t be an issue.
Side note not a bad idea to start learning PHP 8.X because the language isn’t quite as “loose” as it used to be. With any luck the team will use a tool like Psalm and using strong typing to help cleanup and reduce bugs.
You know, since this is going to basically require the majority of users to migrate systems this would be a good time to also just remove any legacy support for things like chan_sip or any other removed/deprecated application in Asterisk. Also be a good time to revisit all the AMI that is being used for things. Outside of deprecated actions/events there have been numerous additions for actions/events as well as updates to existing actions/events.
Thanks mostly to @billsimon , us debian guys have been ‘rolling’ Open Source FreePBX and the OS for many years without too much sweat, Debian 5 to 11, PHP 5.2 to 7.4, The RH based ‘scripting’ would seem to be almost exclusively a problem for any ‘Commercial’ modules used, but as they are all obfuscated, it would be hard to comment. If it stays ‘open source’ then . . . .
JM2CWAE
P.S. any scripts that run under sh or bash or zsh will not know whether they are in a RH or any other OS environment
Less ‘rolling’ and more ‘roleing’ below – @dicko you might find a little easier to debug step-by-step and/or customize with some flags on the command-line using Ansible vs. “install.sh” all-or-nothing approaches: