I have to violently disagree with this. The enterprise today is all about virtualization. Either you are virtualizing on your own on-premise hardware or you are virtualizing in the cloud on Azure or AWS.
Microsoft has an Azure-optimized version of Linux called “Microsoft Linux” are you going to call for FreePBX to be supported on that?
If you have techs running IT in an enterprise that are only able to do it in a homogenous environment then I submit that they are not competent to run IT in an enterprise. I run an IT department and I’ve made it clear to all my staff that this isn’t a Windows-only world anymore and I expect them to be at least conversant with all the major OSes including Linux. Some of them were, I might add, stunned and dismayed when I booted Microsoft Linux on a PC in front of them and pointed at the Microsoft logo. But the ALL got the message. I will say that the prior IT Director was old-school and came from a Wintel environment but he clearly ignored the “Microsoft Loves Linux” advertising campaign as well as what is going on in the industry.
Go to ANY temporary agency that supplies IT techs and they will have ZERO problems finding techs for you that know Linux and Windows as well as different flavors of Linux. I would also guess your staff DON’T view it as “inconvenient” to support different flavors of Linux it’s only you that feel this way. I will also point out that there’s been multiple “flavors” of Windows to support and there are today - windows 10, 11, and multiple versions of Server.
One of the biggest commercial Linux distros out there aside from RedHat is Canonical’s Ubuntu. If you don’t feel your staff can support Debian 12 then you can get a support contract from Canonical for Ubuntu Server and have their staff install it or you can pay a consultant to install FreePBX on Ubuntu.
Another giant hypervisor product out there is VMWare and that’s also a modded version of Linux. And it’s NOT a Linux that is anything at all like RedHat or Ubuntu. And it’s been around for decades now I think.
I have had zero problems running Debian 12 VM’s with FreePBX on them on Ubuntu Server under qemu+kvm. qemu+kvm also has no problems running various flavors of WIndows from WIndows 10 to 11 to the server versions. Windows Server Standard, also, has no license restrictions on the number of Linux instances it can virtualize.
I would suggest if you have not gone to virtualization by now in your enterprise, that it is seriously out of date. This isn’t your Grandmothers IT environment anymore.
I totaly agree with what you say, but it isn’t a matter of competency or virtualisation, just plain tco.
The more testing you need to do, the more it costs.
It used to be an os and app combo, with a single upgrade path, and now we have the os and the app maintenance paths, to play along.
pbxact seems to be the solution that offers the same level of single maintenance source, with the additional benefits of bronze support, just a bit more expensive than fpbx + commercial modules.
It’s ALWAYS going to cost more to outsource than do it in house. The outsourcer has to pay their people also just as you have to pay yours.
There are not a lot of businesses that can justify a least cost solution that includes outsourcing. There are more that can justify that they HAVE to pay the higher cost and have no other option. Examples are, businesses located in highly undesirable places to live, highly cyclical, etc.
Buying an appliance answers that, as you observed. I can’t fault Sangoma for wanting more money for an appliance. If anything I am just pleased that they offer the option of support of just the PBX itself if the customer is willing to support the base platform.
I agree with your first point, pertaining to virtualisation. Whether it be VMs, containers, or other solutions – running directly on baremetal is a potential waste of resources now.
I also agree with your second point, pertaining to it being no longer being a Windows-only world.
The third point causes me some trouble though. I think that there may have been a lawsuit or two, pertaining to that. ESXi (or ESX) hasn’t been based on Linux for a while now, and even deprecated/stripped out support for Linux-derived driver modules with the transition from 6.7 to 7.0 iirc.
If you want to try out PBXact and tell us about how it goes, feel free to. Just be sure to take detailed notes, so that others know what the move to PBXact entails.
Moving from an vendor-provided appliance to packages installed on an existing VM doesn’t bother me much either. I just don’t want to be tied to a specific distro, if possible.
This is my point to. There is no single vendor/technology solution. And when talking about appliances, I mean virtual ones.Bare metal is dead, long ago. Something that can run on vsphere, kvm, nutanix, even kubernetes, at the appliance level.
At the platform level, the major linux distros. But since I will do the support and maintenace work, don’t tie me to a specific distro. We all know that it isn’t that difficult.
I didn’t know they had stripped out support for Linux-derived driver modules from 7.0 I don’t know about the lawsuit but I’m glad it was filed.
I stopped using ESXi after 5.5 for new projects and over time gradually replaced and phased out it’s use and replaced it with qemu+kvm. But for ESXi 8.0, after VMWare was sold to Broadcom, Broadcom removed the “free” version of ESXi for distribution in February of this year. And, now, you MUST buy a subscription license for it. This is over and above even what Microsoft is doing with Windows Server. But kvm is better, now, in every way than ESXi ever was.
Nothing prevents anyone from taking all of the bits and pieces, Debian, FreePBX and so on, and packaging it up as a single VM
I’ve thought about doing this for a while and am seriously considering doing it soon with FreePBX 17, Debian 12, Asterisk 22, Chan_sip, the Cisco USECALLMANAGER patch, and the Cisco Provisioning Server targeted as a drop in replacement for Cisco UCMs. Then releasing it as both a KVM vm image and a HyperV image.
The biggest problem you run into when doing this is proving it out on various hypervisors and hardware combos. Producing the VM is easy. Producing documentation for using it is more complex, but it’s not impossible, and even doing support on a freely available product (like for example FreePBX 16’s ISO) is not hard since there’s no contractual requirement to support all of the border cases. This is after all what Incredible PBX does but IMHO they overload it with hylafax, and the vpn and routing crap, which IMHO is either dinosaur tech (honestly, fax, in 2024???) that is better offloaded to a real higher end fax machine, or better offloaded to a hardware router, or openwrt box.
But the big problem is I don’t have 2,000 desk phones somewhere handy with 2,000 bodies making phone calls that could be used to push the thing to it’s limits on the hypervisor/hardware. With Switchvox/Starvox/PBXact they are selling licenses to specific limits which pretty much flatly states will support X number of phones - so if a business with X number of phones goes and buys one of those machines and the licensing for it - it’s guaranteed to work (or it’s fraudulently sold, obviously) with that number of warm bodies.
And then of course, there’s the deskphone support issue because phones require firmware loads which are copyrighted. Somehow, 3CX.com and firewall.cx seem to get away with distributing firmware versions of really old, antique Cisco phones without getting takedown notices from Cisco - but they both lack some key phone firmware files that are required to update older SCCP loaded phones to SIP. I wish I knew how they got away with it, maybe just the fact that they only have firmware for EOL phones available gets them out of the Cisco radar.
To making FreePBX easily installable on (just) Debian.
I’m suggesting that they go further and just make it available on any distro.
Or more specifically, to make sure it doesn’t favour/rely on one distro in the long-term.
Making it build-once/run-everywhere is a good start. Also need to make sure it doesn’t favour any specific init system as well. This will allow it to run almost anywhere.
To be honest, I never knew why Sangoma never created a script for each Linux distribution.
It would be smart and useful for Sangoma to do that. Gain? More commercial modules for Sangoma. That’s obvious.
If customers prefer Fedora or Debian as root, Sangoma could extend its capabilities to install any commercial module everywhere and not just on a specific OS.
SNG7 was based on Centos 7, so easy to migrate to Fedora. Then the choice was to migrate to Debian 12. ok, in that case, two scripts and then, why not adapt the scripts for the different OS step by step. for example: if there is a small difference for Rocky, or Ubuntu or other, a script of that. Or simply, add this specification on a makefile detecting the OS and performing the installation on the right environment.