On Wednesday 24 May 2017 03:40:54 Lester Caine wrote: > On 24/05/17 02:05, John Iliffe wrote: > > On Tuesday 23 May 2017 02:40:03 Lester Caine wrote: > >> On 23/05/17 02:41, John Iliffe wrote: > >>> The Apache directive invoking this script is: > >>> ProxyPassMatch "^/.*\.php(/.*)?$" > >>> fcgi://127.0.0.1:9015/httpd/iliffe/ > >> > >> ProxyPassMatch ^/(.*\.php(/.*)?)$ > > > > Some further info: > > > > Yes, /httpd is the root directory for the web pages. The production > > server has a lot of named virtual hosts on it and each one has a > > document root of /httpd/<server name>/ and the test server is set up > > the same way. The test server is www.iliffe.ca and its document root > > thus becomes /httpd/iliffe plus a few subs below that where needed. > > In this case, there are no additional subs. > > One of the major problems with Linux is the way each distribution > modifies just where it installs key applications and how it manages > them. I'm on SUSE myself and apart from a couple of attempts at other > distros when the SUSE guys just totally lost the plot, I've been with > that since version 6. My problem is installing later APACHE/PHP builds > while maintaining the stable SUSE installs ... and getting paths right > teds to be the problem. > I used to do disk management in a very large data centre in the 1970's and so I have developed ways of keeping track of the data. For one thing, I never intersperse the data with the system stuff and I always keep the application software (PHP, Apache, Pgsql, etc, separate too. At the very least that allows me to have various versions of the software and bounce around between them. Idiosyncratic, I have been told, but it makes managing everything easier! Once you have the paths figured out once, everything stays the same or moves in a predictable manner. Also, downloads from repositories have a bad habit of installing incompatible updates. For example, any attempt to upgrade from PHP5 to PHP7 in a automatic install will cause great and unexpected grief for the programmers. Read the change notice! > > THAT is telling me that /httpd/iliffe/i_phpinfo.php is not the path to > the file. Yes, it is for sure. lstat in the trace gets a 0 response code which confirms existence and file type. namei also confirms the path. Also, there is a major cron PHP batch component to the production server that is replicated on the test server and all of it runs correctly from a similar directory arrangement ( /batch/... ) I had to test all of these CLI scripts to make sure they would run correctly on PHP7. > Bit like one gets with windows where it hides the real > physical location and only gives you a 'user' view of the path. My copy > of Apache is using wwwrun:www user when it is running, so all of the > /<server name> folders and files have that user name and group, but even > with that php should be able still to read the file so I'm still > thinking the path is wrong in some way. A quick search on Fedora give > /var/www/html/ as the default where SUSE gives me /srv/www/htdocs ... > > > > > I seem to be getting a good argument here for backing off to PHP5! > > If there was a good security reason for changing the PHP5.4 machines I'm > still running then I'd move, and eaccelerator still provides all the > speed improvement I need, so I'm not surprised three quarters the world > has yet to even move to a higher version of PHP5 ... and less that 5% > are using PHP7 front facing. I've been playing with this since January with absolutely no useful results so I think I will conclude that there is a serious unresolved problem with PHP7 and back off to PHP5. I still have the unmodified versions of the scripts that required changes (3 out of several hundred) and I suspect that they would have run except that they were badly written in the first place. Thanks for the help Lester. John -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
