FreePBX 14 + Debian 9: Apache running as www-data fails

I’ve installed FreePBX 14 in my debian server. I need to run Apache as www-data but I am experiencing issues I cannot resolve.

If I run Apache as user “asterisk” everything runs ok. But I soon as I run apache as “www-data” I am not able to change configurations since it fails.

I have already changed directories and file permisions, added www-data to the asterisk group, and edited /etc/amportal.conf but nothing seems to work. I’m lost.

You are going to have to get creative. The webserver needs to run as Asterisk or you won’t be able to update your system. This is a mandatory component of the system.

Where has this been clearly stated as mandatory?

There are lots of php code in FreeePBX to handle this, as well as configuration items in amportal.conf … are you saying a decision was made to turn all this stuff obsolete and require that asterisk and apache run under the same user?

You’re right. Never mind.

Its not mandatory but unless you are using the asterisk user you are on your own. If you want to submit code back that fixes issues then that is up to you and it’s more than welcome but we do not and have not ever tested this in the last 10 years of me working on this project. FreePBX has to write out configuration files that asterisk can read. So the apache user needs to at least be in the same group as the Asterisk user

I understand this, but even though I added www-data to the Asterisk group the code fails… I saw bug reports for FreePBX 13 and nothing for FreePBX 14 and assumed it was solved, but I now guess it was not.

I guess we have a situation here :wink:

“If the mountain will not come to Muhammad, then Muhammad must go to the mountain”

Possibly the answer is to identify which role is more movable and concentrate on the lowest expenditure of energy.

So you believe that Asterisk is not movable. Is your so far unidentified www-data dependent code equally un-movable? If so we have a “Catch 22” Yossarian (please excuse my mixed metaphors)

Possible

is also still pertinent

I solved this situation instantiating a separate apache process ran by asterisk user

1 Like

Nice one, make sure you have enough asterisk owned processes running to cover both the FreePBX interface any any other UCP or whatever needs.

You aren’t doing other things on this system right? It’s 100% dedicated to being a PBX appliance?

Of course there are other things going on on this system, that’s exaclty why I don’t want asterisk user messing with other user spaces. It’s not a heavy duty thing so it’ll be allright.

FreePBX is not designed to run on a “shared system” like that. It is designed to be a PBX appliance and should be treated as such. Not doing so will result in complications and issues down the road. You may not see them now but you will have them.

While running manual installations on unofficial OS’s such as Debian already limits how much support you can get. Running it in this style of setup and environment makes it completely unsupported.

So for the most part you’ll be on your own as far as figuring things out. You’re running things out-of-scope and not something anyone would be familiar with.

Well, this is the beauty of free software, open source and all this… I’m a computer science graduated so I have a very good idea of what I am doing… I needed a good PBX running asterisk at one of my VPS and I got it despite some complications dealing with a “non standard” setup. If I had more resources I would just use a virtual machine, but I can’t afford that right now.

1 Like

It works very nice. The only drawback is you need to use a nonstandard port for either http or https (I use https), but so far so good, I’m up and running a small PBX at my system without any other trouble right now.

You have to read a little about how things are designed to make it easy to configure as many apache instances as you want/need.

Of course but directory re-directives can mask a lot of that to your users. You are aware that apache2 is only needed to manage the asterisk instance through FreePBX, you can happily stop it and asterisk will continue to operate just fine.

An opposing perspective . . . .

Actually FreePBX/Asterisk is well designed to run under a multiplicity of OS’s, at least until recently when yum specific creep is becoming more intrusive.

As such it can share resources with other well behaved apps. I would agree that many years ago a 286 intel would be hard pushed to support anything more than chewing gum.

But that is not where we are now :wink: given a likely current hardware box or even a very low end VM, then your system likely can easily support a full-on Linux Desktop, a full-on media server and a full on Free-PBX without dropping a packet from your SIP conversations.

If you want to check that out without prejudice , install any linux desktop of your choice, add xrdp for grins. It’s pretty well guaranteed that your system can both do the walking and the gum chewing .
If you have other results please show us after your failure,

A 5$ a month VULTR investment would be all it takes to prove or disprove this pudding (and that is pro-rated)

Again JM2CWAE

That’s fine, thanks. I treat my PBXes like appliances and have no interest in doing it any other way.

Gotta love intransigence, go with it. it ultimately works for few :wink:

Hmmm , while thinking about your replay do you actually know what intransigence means?

Big words don’t mean much. I don’t have to change my view on this for any reason. I’ve explained to your before I’m not a PBX vendor. The PBX systems that I deal with here and there don’t need me to be fancy or tricky with them. They need to follow standards and can be easily supported by the next person and most importantly the vendor. So yeah, I tend not to do weird things for the hell of it on those systems.

Since I have no need or requests for this type of setup I have no desire to worry about or even spend my time on it just because. This isn’t a hobby for me.

Very cute. Just couldn’t help yourself could you. You are literally not worth the time. Have a good day.