getent passwd asterisk returns that, so that’s fine I guess.
php -m | grep posix returns “posix”, nothing else
getent passwd asterisk returns that, so that’s fine I guess.
php -m | grep posix returns “posix”, nothing else
I think it’s best that I either reinstall it or switch to something else, I’m not sure tho
I got a similar issue when Debian updating my php to 8.4 check what php version you are running and if necessary drop back to PHP 8.3 it fixed my issue.
How many extensions? Why don’t you use local hardware? I use Intel NUCs with Linux Mint. FreePBX is installed as a Virtualbox machine. The advantage is that you can backup freePBX within minutes and reinstall the image on any other machine which runs Virtualbox.
Another advantage…freePBX is not accessible from outside. I use noMachine to access the Linux Mint machine.
Hi Tyler,
If you are using the “Debian 12 image” from Digital Ocean that is likely the source of the problem. We have seen this over and over and over when people try to setup FreePBX in “the cloud”
What is going on is the cloud service providers customize their Debian 12 images. They CLAIM that what they are doing to their images shouldn’t impact normal applications - but that’s really only true if your just running straight apache+php like a lot of people do.
In my view, anyone running an experimental non-production server should START by running it locally. Just go down to your local garbage dump and fish around and you are sure to find an elderly PeeCee that used to run Windoz and was booted out the door because it couldn’t run Windows 11 - and it will have statistics that will kick the stuffing out of the miserable meagerly allowance from Digital Ocean, and be 100% free to boot.
Cloud is for proven, income-generating applications that generate a monthly revenue some of which can offset the monthly subscription cost. Otherwise it’s a money-loser. And, when running a PBX in the cloud, you must get a true “virtual” image and upload your own install ISO and install it into the image - don’t use the providers Debian 12 image which they have hacked up to add their instrumentation into.
Many people have installed FreePBX v17 in the cloud and on various cloud providers. I’ve done it and no, their images did not cause any issues.
Not a single thing provided in this thread explicitly points to “It’s a VM so that’s the cause”. All the errors and issues so far could happen (or have happened) on non-virtual systems in the past of various versions of FreePBX.
Can we stop the banal replies of “It’s the VM” or “It’s the cloud” each time in replies to threads like this?
There’s a lot of clouds so Your Virtual Machine Mileage May Vary (YVMMMV) from day-to-day
etc.
The Debian Cloud Team puts together many of the “official” base images used across various providers, using multiple different tools e.g. FAI to build Amazon EC2 AMIs.
Cursory glances over the past several months of discussion on the Debian Cloud Mailing List reveal locale configuration issues in the images, some Go library blockers when dist-upgrading from bookworm to trixie that broke (sound familiar – might be your issue, OP @tylerfrominternal ?) google-guest-agent dependencies, missing bullseye-backports in Azure, some (tangentially cloud - maybe a mist ?) Docker images with xz CVEs still embedded, and software stuff like that.
I have open source FreePBX-17 and Asterisk 22 running on Debian-12 on Vultr, Crown Cloud, Rack Nerds, and Colo Crossing vm’s with no issues. I have not tried to use the FreePBX tarballs. I always install from scratch. I’ve never had any issues with installing on cloud VM’s but I’ve had far more issues dealing with routers, firewalls and poor ISP’s when trying to do on-site installs.
Probably not because so many many times when we get these kinds of problems it is due to things that are clearly operating system issues, often file corruption, all of these fall under the category of “system administration” issues.
Yet the OP is blaming the application NOT the OS. A lot of people ya know, take a bit of offense when people do that - because they run FreePBX on their own hardware or own vms with no problem.
I hate to tell you but the moment someone says “I’m using the cloud” in most people’s minds they fall into the category of “doesn’t know how to setup bare metal, doesn’t know how to install operating system, doesn’t know anything about system administration which is why they are outsourcing it to a cloud provider” It may not be fair, but people who lead off saying “I’m hosting in the cloud” have to -prove- through subsequent posts that they actually know what they are doing - because frankly the majority of people running to the cloud - don’t. That’s WHY they are going to the cloud - because they don’t know how to install an OS let alone troubleshoot hardware.
Then when they follow up with posts indicating they are using a dynamic home-user residential internet connection, ISP-supplied modem, sip trunks from the cheapest provider they can find in the cloud, and a total of 5 extensions they are using in their house - the entire thing screams “newbie” And so, they are going to make newbie mistakes - and mistakes in system administration are top of the list.
Of course, there are also those at the opposite end of the spectrum - dragging out some raspberry pi micro who know a ton about hardware but are hell bent on winning the award for “smallest PBX install on a computer half the size of a pinhead that they can boast to their nerd friends about” who lack common sense - once more, just as bad.
I don’t see anything wrong with advising newbies to start with some old cast off PeeCee and do a local install on it - learn about hardware, learn about operating systems in an environment where you are not paying a per-minute charge and the pressure is on to get it working because while it’s not working your throwing money down the rathole.
The fundamental fact here is - I’ve never run into someone who has successfully self-hosted locally who has had problems with cloud installs but I’ve run into TONS of people who have NEVER successfully self-hosted locally who seem to have lots and lots of problems with cloud hosting, also.
Horse, meet cart.
No one is taking offence to this. At least, I haven’t. The application (FreePBX) is running a command and getting a response that indicates the user doesn’t exist. Everything else after that has been double checking that response.
Now since the code checks two different things and they are both failing, could it be the code? Sure but what is failing means everyone should experience it if running the same code. However, since the system doesn’t think /home/asterisk exists or spool directory doesn’t exist something else is going on. Either a configuration issue somewhere or something at the system level.
Again, not a single thing in this issue is related to the system being a VM or standalone. The issue at hand could happen on either. Just blaming the VM and offering no actual insight to the issue isn’t helpful and a waste of space on this thread.
The OP contacted me and says he has set it up using Hyper-V and a Reverse Proxy. Everything is working for him now. No need to duke it out further on here.
I think the devs would be offended by the statement:
“What the **** is it with FreePBX? I keep getting issues, over and over and over. Do any of you recommend an alternative as this is just getting worse”
And, considering the OP set it up on a different hypervisor using an (obviously) different VM and it’s now working - I guess my conjecture that his VM was duff proved out to be correct. And FreePBX was vindicated as not the problem.
Unfortunately, without detailed troubleshooting, we don’t know WHY the DigitalOcean Droplet failed - but since the OP does not have control of the hypervisor the droplet was running on and therefore cannot read any of its logs, he pretty much can’t do anything to investigate. Digital Ocean’s techs could - if they cared to investigate.
This is one of the fundamental problems in IT. You can’t do everything - from writing the code from scratch for the applications, OS, phones, etc. - so you have to create dividers from what you control to what they control.
With on-premise hosting the dividing line is between the OS and app devs and your gear.
With paid hosting that line gets moved closer to you - you have less control, they have more control, you are more beholden to them than if you self-host.
This matters when problems like this show up. Which is why this troubleshooting thread is a -textbook- example of the biggest downside of cloud hosting - the less control you have over the system, the less ability you have to fix problems in the system.
I know you are very invested in cloud, Tom. I submit that your heavy investment in it is clouding some of your judgement on the faults of cloud. It is NOT better than on prem and in some ways - like this - it’s just a misbehaving black box that your never going to know what was going wrong with it.
You might be sick of people blaming cloud for being cloud. I think far more people are sick and tired of people touting cloud as the greatest thing since sliced bread. Maybe it’s time for the cloud proponents to actually buckle down and prove their value instead of the incessant din of how cloud is better because it’s cloud that wore thin about 5 years ago. Fortunately, they are now being drowned out by the AI proponents who are equally obnoxious.
Haven’t used that image since its FreePBX 16 ( i think), ive installed it via the recommended way
10 extensions, was looking into purchasing a server
This is a very interesting conversation. Judging by your responses, I can assume that one of the modules wasn’t updated due to some automatic update.
I suggest trying updating all modules to get the latest ones.
Step-by-Step Instructions
Run the system update:
apt update
apt upgrade -y.
Update modules:
fwconsole ma upgradeall — for all current modules.
Check the system for readiness for the update:
fwconsole versionupgrade --check — the system may detect unsupported or outdated modules. If any are present, they should be removed using the command fwconsole ma delete MODULENAME and rebooted.
Run the update:
fwconsole versionupgrade --upgrade — the system will notify that the update is complete; you can exit with Ctrl+C.
Restart FreePBX components (if Asterisk, sangoma-pbx, or fail2ban have been updated) — fwconsole restart.
IMPORTANT!
Do this only if you’re confident in your abilities. Unfortunately, version 17 isn’t working very well. I hope the developers fix all the bugs.
Nonsense. Some of us have no issues whatsoever.
@dagmatik please reply to the previous DM request to mark your post as AI-generated, if applicable. There are some glaring errors which indicate your work might not be your own – which is not cool per the Code of Conduct’s “Post Only Your Own Stuff” section – such as suggesting versionupgrade for moves to v17.
I have lots of DO droplets running off their DO 12 image. It works just fine.
I’m sure you do. And, sadly, if you had been around here weeks ago on Sept 26 when the OP posted, you could have responded to that and closed a HUGE rabbithole that a few other people besides me who were trying to help him went down into. Because, the OP said he checked everything else.
You also I’m afraid didn’t really read - or digest, perhaps - what I said earlier. I said:
"With paid hosting that line gets moved closer to you - you have less control, they have more control, you are more beholden to them than if you self-host.
This matters when problems like this show up. Which is why this troubleshooting thread is a -textbook- example of the biggest downside of cloud hosting - the less control you have over the system, the less ability you have to fix problems in the system."
To put it simply - the OP - AND you, by the way - have ZERO ability to troubleshoot problems IF there’s a problem in the DO droplet. You both have to completely trust that DO did everything properly and that there’s no problems on THEIR side.
It’s very significant that the final report was that the OP got everything working when he repatriated from the cloud and self-hosted. You see, doing this moved that line of responsibility I was referring to in my post towards him. Once he vacated the cloud - he could then troubleshoot the complete system not just a small part of it - and, doing that, obviously let him fix it.
I would wager a bet that BEFORE you did any DO drops, that you had your own self-hosting servers, worked out all the bugs and such when they were on prem, then moved them to the cloud. So, you also benefited from moving that line of responsibility AWAY from the cloud.
But of course, I also know, that this kind of discussion about the cloud’s faults is likely way beyond what a typical drive-by poster like yourself is interested in. So, be my guest and pat yourself on the back that “you proved that cloud-disser wrong dad gummit”
I’m not saying it works poorly, I’m saying there are some flaws, especially in the settings. For example, when changing the web interface language, confirmation is required every time, and the entire framework is restarted. And this is with a ready-made build, while with the one translated from beta testing, this doesn’t happen. Or, for example, my Asterix doesn’t restart automatically, or I constantly have to do a fwconsole chown.
These are small problems, but they exist.