I have a brand new AsteriskNOW 1.7 32-bit system running Asterisk 1.8.x (from digium’s vanilla AsteriskNOW repository), and FreePBX 2.9.0.9 which I upgraded from the pre-installed version (after disabling the FreePBX yum updates).
Mostly things are working well. However, today is the first day that I tried to use the ARI (http:///recordings.
Oddly enough it allows me to login via the admin, as well as any extension. But the instant that I click on any link in the ARI, or submit a search query, I am redirected to the ARI logon page. Very annoying.
I am not seing any errors or anything helpful in the apache logs. I’m really not sure why it’s not working here, whereas it has on other systems. Is there something that I’m forgetting that still needs setup?
I’m not familiar with the upgrade scripts. I’ll check that out. But just to be clear, I disabled the FreePBX updates in yum as per: http://www.freepbx.org/trac/wiki/AsteriskNow
Then I went into the FreePBX module admin & upgraded to the latest 2.9. I’ve done this on 2-3 other AsteriskNOW systems w/o any noticeable isseus…
I seem to be experiencing the same thing. I did do a yum update over the weekend and it updated php. FreePBX 2.9.0.9. If I click on the icon to download a recorded file, I also get “404 File not found!”
Not a distro version - 1 year 2.9 runner, upgraded to 2.10.0beta2 then to 2.10.0rc1
Issues experienced similar to these and other posts experienced after a recent yum update and running 2.10.0rc1 GUI functonality fell over following yum update on our production system, picked around various posts and ideas for a few days without action just in case cure ‘worse than disease’ and system failed entirely. It was operating OK in most respects except would not register IAX trunks or display CDR records, fortunately we have POTS trunks too.
symptom 1 improper graphic when logged onto GUI
symptom 2 apply config bar would not proceed withour error message
symptom 3 not register IAX trunks
symptom 4 nil display CDR records
symptom 5 required ARI logon for every page change.
Thank you for posting this command “chown -R asterisk /var/lib/php/session” I was having the same problem with the FreePBX main admin not with ARI and I spent over 8 hours, but this command fixed my issue.
Well, CentOS 5 repos have a new updated PHP5 as: php-5.1.6-27.el5_7.5.i386.rpm
I figured I’d install it via yum update & see if the problem returned. Sure enough, http:///recordings redirects to its login page after each link I click after logging in.
Then a chown asterisk /var/lib/php/session, and we’re back in business.
Is this seriously going to break after each PHP5 update from now on? Ugh.
Looks like this is actually a long-standing issue that’s at least over 2 years old (although I’ve never seen it before, which makes me wonder whether it has come & gone a few times).
What do you all think is the best long-term fix for this? Basically the problem is that with FreePBX, the apache webserver runs as the “asterisk” user. Whereas it appears that the CentOS/RHEL default is for the apache web server to run as the “apache” user. When the PHP updates get released through yum, their RPMs are changing the ownership of /var/lib/php/session from the “asterisk” user to the “apache” user. When this happens, the apache web server that FreePBX runs on, no longer has the necessary access required to save session files to /var/lib/php/session.
Doing a little digging, /etc/php.ini has many variables regarding the PHP sessions, including:
session.save_path = “/var/lib/php/session”
However, I don’t see anything there dealing with ownership of that dir. And truthfully, I don’t think php.ini is really helpful here, because it’s not like apache/php can change the permissions on a dir it doesn’t have access too anyway.
So it would seem to me that the solutions here are either:
Write a cronjob that just resets the ownership daily or hourly, as a fail-safe safety net for whenever this issue transpires.
OR
Try to get the package maintainers to stop including the ownership change of /var/lib/php/session with their RPMs.
Anyone else know of any ideas as to how we can solve this in a permanent fashion? I’m wondering whether the php 5.3 RPMs (avilable by installing "yum install php53) would exhibit this issue. I presume php 5.3 is compatible with FreePBX? In fact I don’t know why my AsteriskNOW 1.7 distro uses php 5.1 rather than 5.3 in the first place.
Anyway, I guess for the time-being, I’ll just have to setup a cron job for all client’s systems until we figure out something better.
States that the release notes on this one go back to a Red Hat employee: Joe Orton [email protected]. It appears that Joe Orton is a Red Hat employee who maintains the PHP package, as per: http://fedoraproject.org/wiki/User:Jorton & then click on the “Packages I maintain” link. So maybe I’ll contact him about the issue.
Additionally, the above rpmfind.net URL does state that the package includes the following files:
/etc/httpd/conf.d/php.conf
/usr/lib/httpd/modules/libphp5-zts.so
/usr/lib/httpd/modules/libphp5.so
/var/lib/php/session
/var/www/icons/php.gif
I’m not sure why they’re including the php/session directory, as it should already exist. Maybe just to make sure that it does indeed exist…?
The only thing I don’t know is whether CentOS package maintainers are making any modifications that would come into play here, or whether Joe is really the one whose work is introducing our issue. I’ll ask him & chime back in here.
Anybody have experience with RPM Macros? I’m wondering whether this would be a quick/permanent fix that would enable us to re-force ownership on the dir any time after a php RPM is installed.
If you use the upgrade scripts in the distro this is taken care of for you.
I assume that the package maintainer is going to have some very snarky remarks for you to set your permissions.
The team goes to great lengths to insulate distro users from this kind of stuff. Why on earth do you feel compelled to update PHP on perfectly running systems? OS Package dependencies are very tricky and they can be frustrating even after years of experience. To me it’s almost unapproachable for those without a solid Linux foundation.
To use an analogy, instead of using Windows Update try replacing services in IIS with different versions and see what happens.
I suspect you may be right on this Skyking. No response from him yet. However, it does appear that FreePBX is taking it upon themselves to try to fix this issue from their end anyway, even though it’s not their fault: http://www.freepbx.org/trac/changeset/13405
In other words, we are a security-centric company. We try to never knowingly leave customer’s systems without security patches, when those patches are readily available. I realize that as long as their box is not accessible to the public internet, odds are that a vulnerability like this would never be exploited anyway. But it is simply a security best-practice.
And of course on the other end of the coin, there is the whole “patch testing” process that is also a best-practice so that issues like this one don’t transpire (i.e. a patch doesn’t break your software, rending it wholly or partially unusable).
It sounds to me that maybe this is a part of what the FreePBX distro is all about. And I actually haven’t really looked into the FreePBX distro at all, and I think it’s probably time that I do.
