Hello,
my FreePBX version 17.0.25 is running on a virtual Proxmox machine under Debian 12. I would like to switch to Debian 13. Is that possible? What should I be aware of?
Regards, Stefan Harbich
To save you a lot of time, Debian 13 is currently unsupported with FreePBX 17. You’ll likely end up with a broken install if you update. There are some older threads on the forum that detailed some unintended upgrades when Debian 13 was first released.
I think the biggest problem is PHP. There’s some guides for older versions here:
The PHP authors have the attitude that they have the God-given right to break everyone’s stuff, since it’s free software their reasoning is that everyone can just go pound sand. This is an attitude shared with the Python devs as well.
The only people immune from this are those running FreeBSD since under that OS they have the Ports directory which allows for easy install of whatever version of anything is needed, since everything is compiled on the OS, you aren’t downloading pre-canned binaries. Sadly, FreePBX decided to use Debian instead of FreeBSD when they switched from CentOS so now we have this political binary hell to contend with. The one good thing about it is you can pretty easily host FreePBX on Ubuntu if your in a commercial environment where you want Canonical to support the OS.
There’s probably some people who might like it if you could hammer out a guide to installing FPBX17 on Debian 13, but it’s going to be a brute-force slugfest. I’d just wait for FreePBX 18. Debian 12 is going to be supported until June of this year, and then mostly supported until 2028 and I’m sure that if anything that maintainers choose not to update after June that affects FreePBX comes up, there will be plenty of info on how to handle that with FreePBX 17 installs.
Right now according to debian-security-support, only the libmfx1 package is abandoned and it’s pulled in by ffmpeg which FreePBX uses, but the library (like most ffmpeg libraries) is only really used for encoding/decoding H.264 video on Intel CPU’s that include integrated graphics. Only video phones use that encoding under FreePBX, and that is mainly the Cisco model deskphones (CP-8845, CP-8875, CP-8941, etc.) That library is abandoned because Intel is changing to libvpl in newer CPUs and I don’t think Debian 12’s ffmpeg maintainers shifted over to it yet because it does not support most of the older Intel GPUs (and, you really want the hardware acceleration on the older slower CPUs anyway_
What are you talking about? How is it their responsibility for the code someone else wrote? If someone is willy nilly updating their stuff without actually verifying or validating the process before they do it it’s not the PHP or Python developers problem. If you’re doing a major OS update like this and you aren’t validating the changes then that’s a you problem not anyone else’s problem.
It’s been made very clear that FreePBX v17 runs on Debian 12 only, not Debian 11 or Debian 13. So the failure is the OPs for not following the proper setup instructions for FreePBX v17. Now tell me again how that is anyone else’s issue or fault to be had…
People need to take ownership of their own actions and mistakes not blame everyone else under the sun.
You are conflating 2 ideas here.
The first one is what most of your rant is about - people willy nilly updating their stuff. The OP, Stefan, is NOT doing that at all - that’s why he’s here, ASKING what the issues are. So I don’t see why you are bashing the OP by implication. I think anyone reasonable would agree before upgrading that you check for incompatibilities, I do it myself. Of course, MANY times PARTICULARLY in the Windows and Mac environments this isn’t possible because companies like Microsoft and Apple who release new versions of their operating systems have a vested interest in HIDING the fact that their new versions break installed base of some software. I am NOT saying that FreePBX is hiding the fact it does not run under Debian 13 - it does not. I’m merely saying the overall attitude among commercial software developers is to screw over customers in this manner by lying. Practically everyone coming into FOSS is coming from those environments where the users get trained to just go hells bells forward with upgrades and then try to deal with the fallout if breakages happen. I’m NOT saying that is right. I’m saying that this IS how it IS. One of the huge benefits of FOSS is that people actually DON’T lie about breakages caused by upgrades. So you need to be a little more understanding of new users to FOSS that do “willy nilly” upgrade stuff because in most cases that’s how they have been trained to do it by those commercial software companies.
The second idea you have conflated in is that somehow when you write an API or library like for example pearl, gtk, php, python, etc. etc. etc. - that you have ZERO responsibility for backwards compatibility. This is utter bullcrap.
If you write a library that gets WIDE usage because it does something that’s valuable, and at some future date you get a bug up your rear that the API you wrote is somehow defective and needs to be replaced - it’s NOT your job to force the hundreds to thousands of software packages that are now dependent on that Really Useful API you created, to re-code.
If you look at how GTK handled this, they handled it the right way. The GTAK devs got that bug up their rear to break everything. So, they made absolutely sure to create GTK 3 completely separate from GTK 2. Lots of platforms - including Debian 12 - can STILL TO THIS DAY easily install libgtk2 even though development ended on it 6 years ago. That way, apps written with GTK2 do not have to recode. None of the GTK devs care one bit if someone wishes to continue fixing bugs in GTK 2 and continue releasing minor versions of it - fine with them - they just won’t work on it themselves. Pearl similarly did this, with perl 5. They made a huge big deal that it would break stuff, and both projects released guides to migrate, and both did not radically change APIs around to make it difficult to migrate.
Contrast this to Python and PHP which you can get on any development forum of projects that depend on these and find innumerable developers hopping mad at “stealth” changes that happen all-the-time in these projects with documentation buried in readmes and so on. And then large pushes to drop older versions, pull them from standard repos, or make them difficult to access. There’s like 8 or 9 steps to install PHP 8.3 instead of 8.4 in Debian 13 (did you not read the guide link I posted) and that’s just a MINOR version number 8.3 to 8.4 - yet breaks a ton of stuff which is why there’s even a need for using the 3rd party repo in the first place. I will grant, though, that php is marginally better than Python is about this stuff but they still are both bad with stinky attitudes.
The reality is people use those libraries and programs because they are stupid useful, and save everyone lots of time. But that does not give those devs license to change APIs willy nilly “for the good of the project” or whatever.
I’ll leave you with the famous xkcd comic which illustrates the problems that these kinds of changes cause, and is often cited. Presumably you understand the issue.
So FreePBX v17 doesn’t support PHP8.4, which is the standard in Debian 13? Is this being worked on, or do I need to look for an alternative product?
Any alternative product that supports php 8.4 will immediately break when the next 8.5 version of php is released, and so forth. So even if you could find an alternative product, your going to be faced with this same problem when distros come out with new versions.
There are not that many FOSS PBX projects out there the next larger one is FreeSWITCH. It has some GUI projects you can investigate here:
But you have to remember this - the PBX itself is a “toaster application” It is NOT a general purpose “linux server application” that people just run to doink around with. What that means is - the operating system in toaster apps is purpose-configured. You aren’t going to be running X Windows applications on your PBX nor anything else. The point is to set it up and leave it running and it runs reliably and constantly 24x7.
To me the compelling point of FreePBX is that Sangoma uses it as the core of it’s commercial PBXact product, and it even also sells that as a complete hardware/software package. So if you setup a vanilla FreePBX system on some piece of kit, and then get hit by a bus, your successor (if they aren’t particularly interested in phone systems) can hand over cash to Sangoma, get a complete blue box system shipped to them, run a backup and restore from your FreePBX system and in an hour have a 100% hardware & software Sangoma-supported phone system that they can then continue to ignore and have it be “Sangoma’s problem”
This is how people who run large phone systems with 100’s of users think. It’s NOT how people who want to just play with something and learn about phone systems with a few phones in their house tend to think. So I can understand your concern about versions and so on - you want to “stay current” because “staying current” is more important to you than “9 9’s of uptime” That’s SOHO thinking and there’s nothing wrong with it, honestly.
1 Like
Thanks for the reply. Then I’m happy to pay some money and look into a cloud solution.
Unmarked the previous response as the “solution” because there’s no guarantee a cloud solution would be using Debian 13 since that is not supported by FreePBX 17. It just doesn’t make any sense. 
For curiosity’s sake, what are the main FreePBX’s “PHP assets” broken by PHP 8.3 to PHP 8.4 upgrade ? Is there a Github issue somewhere listing main hurdles to cross to get a PHP 8.4 compliant FreePBX version ?
These could make great first issues in the FreePBX repos on GitHub (and then assignments to the v18 milestone.)