Has anyone here run FreePBX on Linux Mint: Debian Edition or Arch Linux? I’m getting ready to migrate to FreePBX 17, and wanted to know if there are other distros that I can install FreePBX on. I understand that this probably isn’t officially supported. Just looking for insight before I make a long-term decision.
Lots of bad decisions with the upgrade path to fbpx17
In the good old days, sangoma would support a centos derivatitve and allow us to use it as an appliance kind of thing.
Moving forward to version 17, there is no such thing, but we are forced to use debian AND install migrate and maintain the os on our own.
The assumption that this is the only linux system around and that there are no other distros to support is problematic to say the least.
The enteprise world is using redhat, oracle linux and its derivatives, such as alma and rocky.
a debian system isn’t exactly convenient to support and creates a mixed environment out of the blue.
Everyone understands the need to protect commercial modules with ioncube et al, but the vendor should also understand that a pbx can’t be the central pivot of os selection of any business.
Genltemen, we either need a supported appliance, or at least support for major linux distros.
Supporting multiple linux flavors is an administrative nightmare.
And I suppose that you prefer us buying and using commercial modules, instead of using just the open source part and look elsewhere for everything else
Do you?
Sounds fun, but Mint is for desktops ? Maybe for testing ?
That would probably be a lot more work, but great if FreePBX could run there, sure. Arch looks like it has decent, current Asterisk packages and docs.
To clarify, their offering is Red Hat Enterprise Linux nowadays ?
Which is basically RHEL ?
The main concern with relying on RH/OL seems to be that they might go the way of the dodo bird CentOS – which could be why their OpenEL Association got up and running a whole year ago.
It does seem like those two have some staying power, and they come up in testing situations, but they are still both relatively new entrants to the space.
There’s a lot of cross-over between Debian and Ubuntu – admins of either can easily cross-over. And given that Ubuntu dominates Linux with over one-third of the market, followed by Debian and CentOS, at least according to this recent article, then the decision might make more sense based on that alone.
Arch and archies are for tinkers and hackers. Hardly to be found in a corporate env.
If you feel like supporting it will be fun, but apart from that,there are second thoughts
Let the archies figure it out. Its in their blood.
Linux mint is for desktops. no juice here
Redhat, oracle linux, alma AND rocky are essentially the same, and supporting one would also mean all the others.
Redhat won’t go away, neither oracle will, and oracle is a free os too
Redhat has an offering for free enteprise linux up to 15 hosts, for small production workloads too.
Alma and redhat are continuing the centos saga., and have some solid funding behind them
Ubundu and debian is another story, coming the first coming of desktops and debian being a historical release.
And of course there is suse too.
In a nutshel, supporting debian (and ubundu) is the one, and redhat and its derivatives is the second.
Shouldn’t be that hard too, since freepbx was a centos thing, and for the ones migrated fron centos 7 to redhat, oracle, alma, or rocky, things are quite familiar.
And do note that running production grade solutions such as pbx’s in many corporate env also means running it on a supported os. And often , support contracts are acquired centrally and with site licenses.
So please, give us the options. We need them.
Options for what exactly? You are free to install FreePBX on any OS you would like. That hasn’t changed.
Really? Including commercial modules? Since when?
I don’t speak for Sangoma but I expect you will get that with PBXact 17.
No, not commercial modules. The same rule applies as it always has for commercial modules, you want to support them you have to install the supported distro/release format.
So are you asking about the ability to just run FreePBX on any OS? Or are you going on about how FreePBX was on a CentOS derivative (meaning Sangoma’s modified version of it) and because you’re a RHEL/CentOS shop it fit in your “supported OS” rule?
The reality is there are plenty of IP based PBX systems out there where the vendor of said systems does not list what the underlying OS is or even gives you access to said OS. When you buy your PBX from vendors like that you go to the vendor for support not who made the OS.
Even with the FreePBX Distro, as I said it is a derivative of another OS. You can look through the forum history and you will see plenty of instances where people tried using RHEL/CentOS packages for something in FreePBX Distro and having issues because either that package or some (or all) dependencies needed for it conflict with the versions of said packages from Sangoma’s OS.
So not sure how you would get a support contract for an OS that either RHEL or CentOS have no control over or any idea of what changes were made to the OS or packages.
I’m not sure if I can provide a professional answer to this. But I would like to try providing one from a different perspective:
Perhaps open source Linux software be written in a way that’s:
- focused (good at one thing, or a collection of closely-related things)
- portable (write once, run almost anywhere that’s POSIX-compliant)
- distro-agnostic (write for Linux, not for a specific distro/kernel)
If we collectively wrote software in this manner, it may end up being easier to install and configure services on most distros. This could reduce reliance on software vendor/publisher provided support, allowing administrators to be more independent and productive. Could also reduce the likelihood/prevalence of vendor lock-in. But I could be sorely mistaken.
EDIT: Packaging for different distros is tough to avoid, so I won’t pick on that part. But there are other parts of the process that could be addressed, I suppose…
Pertaining to the last point, it makes sense in short-term. Until the top distro is displaced by yet another popular choice. Writing only for Debian could be come an Achille’s Heel if the maintainers/developers of said distro do something that alienates them from the rest of the Linux/FOSS community (or if something happens to the Debian project in general). While Debian, the software, is stable, people inherently aren’t. Betting on one distro is like hedging bets.
To be clear, I want Debian to stick around. But I also don’t want to be reliant on (compatibility with) one distro for everything.
I’d also like to mention that, while Mint itself is Ubuntu-based (if memory serves), LMDE is Debian-based. LMDE may actually be capable of serving as a decent base, as long as there aren’t too many changes from base Debian.
I will admit, I prefer distros like Arch because you can shape it as you please. It’s almost as if it’s designed to be whatever you need. I use Artix, which is based on Arch (without systemd). These are few steps away from what we may call meta distributions.
Distros like Gentoo and Bedrock are practically a blank canvas for anyone with enough time and will power to create what they want.
This is exactly my point. If it is an “appliance” then I would get support from whoever is managing the integration of the application and the os, and I don’t care about if it is debian, ubuntu or win95.
(oh well I would for the latter, but for other reasons 
)
But forcing me to support debian just to run the paid parts of fpbx (which I need) is
just cutting corners sangoma side.
Introducing a new flavor os in a regulated environment most probably will exceed the benefits of fpbx at the tco level easily.
So what I’m saying is, either make it an appliance distro derivative (just like sangoma os was) and I couldn’t care less if it is debian underneath, OR support the major enteprise grade platforms.
Its all about how you protect the commercial modules, and it is well known that the methods used are also supported on all major enterprise grade distros too.
It wouldn’t be that hard bottom line.
Any competent linux redhat versed admin can understand and find her way on a debian or ubundu box at ease, however this doesn’t mean that the need of integration of specific linux flavor into security, hardening and maintenance schedules is negligible, which of course is otherwise heavily minimized if it is an appliance level box.
You are forcing us to the hands of 3cx et al, in a loose loose spiral.
Would you be using their Windows or Linux version? Since their Linux version runs on top of a normal Debian 12 install.
Basically what I see here is pre-v17 the Distro was a derivative of CentOS in which only commercial modules could run on. You could install it on any OS but if you wanted commercial modules you needed the Distro. That seems to be OK with you because you’re on about RHEL/CentOS.
Now with v17 and moving forward, you can still install on any OS but if you want commercial modules you need to use Debian 12+ for that. This is where you get something stuck in your craw because it’s not RHEL/CentOS and that’s what you use.
Threatening to move to another vendor who’s PBX runs the exact same OS that you are complaining about and thus making the threat over…is telling.
No, you are wrong.
Pre 17 was running on sangoma os, a modified centos distro.
Updates and support would come from sangoma, NOT centos
(even when centos stopped supporting centos7, sangoma would stil post updates)
But now I have to run and maintain debian/ (or redhat or oracle linux if it could run)
It has nothing to do with what suits me.
I don’t want to fiddle with anyones integrated os, as long as he can support it.
Passing this support to me is the problem.
3cx offers an iso with everything. (which is debian btw, but I don’t care)
And last but not least, no this definitely not a threat. I’m sorry if you see it that way.
Ahh, that isn’t entirely true. With older versions you had to run update scripts because using yum update would break the system. With SNG7 you no longer had to use the update scripts, instead you could use yum update which used the Sangoma Repos which had mirrors to standard CentOS repos.
You doing nothing more than you were doing with SNG7. Instead of running your choice of yum update and/or yum upgrade you now do apt update and/or apt upgrade just like with SNG7 it will pull from Sangoma and Debian repos for the software.
So really, it seems you are taking issue more with the fact the decision for v17+ is that the install is done like an application that setups of the OS just as it would if it was coming from an ISO. Would having an ISO that just installs Debian 12 for you and then runs the exact same install script to set it up as it does now make it better?
It is not about installation. That’s trivial.
If apt-get update would get updates from sangoma servers, and someone had checked before hand that this won’t break anything, then yes. And I will raise a ticket if anything coughs.
This is not at a theoretical scenario. Php will upgrade it self sooner than later, and then its up to the end user to make sure that nothing breaks.
So each time I fire up apt-get I need to do this on a test system, with licensed commercial modules too? And if it bombs, I have to figure it out? Really? With encrypted code ?
Give me a break. This isn’t an enterprise solution. Yes we do backups and snapshots, and there is failover and contigency, but If I have to rely solely on that for everyday maintenance, which I didn’t had up to now. (since it was an appliance os ), I definitely have second thoughts.
its all about responsibility.
I really can’t follow that last thread but if something doesn’t work right, including a system update, you can get support from Sangoma. You can get support here.
I guess I’m at a lost as to why this is all an issue. Outside of an OS change and there no longer being an ISO, maintaining your FreePBX system is no different than it was in the past. Some different commands but the same thing. If you are using the official install of FreePBX, distro or otherwise, you can get support them same way you always have.
You have made comparison to 3cx - and the equivalent Sangoma product in my opinion is PBXact. You get an appliance prebuilt and fully supported by Sangoma. The value is incredibly high compared to piecemeal FreePBX with commerical modules. But specifically to your point, you have “one throat to choke” and that’s Sangoma, not CentOS open source maintainers or Debian or whomever else.
I would agree with that, but I still need a software appliance, not a hardware box.
I understand this is also available, but I can’t get it on line, it seems I need a reseller and pricing options isn’t available online too.
Obviously, sangoma has a reseller ecosystem to cater for, but working without even a published list price is a big departure from commercial modules bought on line, don’t you think?
I’m pretty sure you can see the retail pricing for everything on the Sangoma portal store. Log in to the portal and click Store.