ok, this seems to indicate that the file is no longer where you expect it to be. Are you using virtual domains at all, or doing anything different from how it was on the old server? You may be stuck testing various partial upgrades to find the problem, for instance installing a test machine with the old Solaris and Apache but the new PHP, or the new Solaris but the old Apache and PHP. I would personally never attempt upgrading all three at once, there are too many opportunities for an insignificant difference in one of them to snowball into a big problem, although the temptation to "get it all over with in one swell foop" is certainly a significant incentive. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Blondé Web Programmer enTel Communications Inc <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] 250.633.5151 866.633.2644
-----Original Message----- From: Jesse Santana [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 1:55 PM To: Matthew Marino Cc: Paul Blondé; php-install@lists.php.net Subject: Re: [PHP-INSTALL] PHP v4 vs. PHP v5 behavior Matthew, Hard coding the entire path causes the script to work under both PHP v4 and PHP v5. I would think that would eliminate the permission possibility. Jesse Jesse Santana Project Lead - Enterprise Services Group Information Technology Services California State University, Long Beach 1250 Bellflower Blvd. Long Beach, CA 90840 Office: (562)985-8511 Fax: (562)985-8855 Matthew Marino <[EMAIL PROTECTED]> 08/10/2007 01:00 PM To Jesse Santana <[EMAIL PROTECTED]> cc Paul Blondé <[EMAIL PROTECTED]>, php-install@lists.php.net Subject Re: [PHP-INSTALL] PHP v4 vs. PHP v5 behavior Pardon me for oversimplifying, but it doesn't report the file not found, it reports a permission error. To debug the problem further I'd hard code the entire path to the file and see if the error still occurs. If so, look at the user and group of Apache and make sure there's --x permissions at the least for the world. relax the permissions to 555 and if it works start to ratchet down till it breaks. Probably at anything less than 511. There's also some new security enhancements like those in SELinux that prohibit access to files regardless of loose permissions. On Aug 10, 2007, at 2:30 PM, Jesse Santana wrote: > > Paul, > > Thank you for the response. Unfortunately, changing the include to: > > include("../extension.inc"); > > Produces the exact same result: > > Warning: include(../extension.inc) [function.include]: failed to > open stream: Permission denied in /home/bu/jsantana/htdocs/php/ > IncludeExample.php on line 3 > > Warning: include() [function.include]: Failed opening '../ > extension.inc' for inclusion (include_path='.:/usr/local/php5/lib/ > php') in /home/bu/jsantana/htdocs/php/IncludeExample.php on line 3 > > Thank you for the .inc.php advice. I am not the programmer here > but will pass that information on to him. > > Jesse > > Jesse Santana > Project Lead - Enterprise Services Group > Information Technology Services > California State University, Long Beach > 1250 Bellflower Blvd. > Long Beach, CA 90840 > Office: (562)985-8511 > Fax: (562)985-8855 > > > > Paul Blondé <[EMAIL PROTECTED]> > 08/10/2007 11:18 AM > > To > "'Jesse Santana'" <[EMAIL PROTECTED]> > cc > Subject > RE: [PHP-INSTALL] PHP v4 vs. PHP v5 behavior > > > > > > I believe the notation "./../" is illegal, perhaps either the new > PHP or the new Solaris is probably now enforcing that when the old > did not? > > I would recommend dropping the leading "./" (since it just means > "start from the current directory" anyway), and trying it with just > "../extension.inc" > > I would also recommend not using .inc as a suffix, as anyone with > half a brain could view the source code by just typing in > www.whatever.com/allmydatabasepasswords.inc or something similar, > telling Apache to deliver it as text. Following the practice of > double-suffixing all include files like so: "myphpcodefile.inc.php" > will indicate that the file is an include file while still forcing > Apache to send the file through the php preprocessor before > displaying it, rendering the user unable to directly view the > source code in your include files. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Paul Blondé > Web Programmer > enTel Communications Inc > [EMAIL PROTECTED] > 250.633.5151 > 866.633.2644 > -----Original Message----- > From: Jesse Santana [mailto:[EMAIL PROTECTED] > Sent: Friday, August 10, 2007 10:54 AM > To: php-install@lists.php.net > Subject: [PHP-INSTALL] PHP v4 vs. PHP v5 behavior > > > Maybe someone can shed some light on this problem for me. Our > current production server is a Solaris 9 machine running Apache > 1.3.37 and PHP 4.4.2. The following script works perfectly on this > machine: > > <?php > include("./../extension.inc"); > > echo "<BR>"; > echo "Hello World!"; > ?> > > The new server we are setting up is running Solaris 10, Apache > 2.2.4 and PHP 5.2.3. The same script I mentioned above produces > this error: > > Warning: include(./../extension.inc) [function.include]: failed to > open stream: Permission denied in /home/bu/jsantana/htdocs/php/ > IncludeExample.php on line 3 > > Warning: include() [function.include]: Failed opening './../ > extension.inc' for inclusion (include_path='.:/usr/local/php5/lib/ > php') in /home/bu/jsantana/htdocs/php/IncludeExample.php on line 3 > > Hello World! > > If I define my include path as include("/home/bu/jsantana/htdocs/ > extension.inc");, the script works fine with PHP 5. Can anyone > explain why under PHP 5 the ./../ does not back up one directory > from the directory where I call my script from? > > Thank you, > > Jesse > > Jesse Santana > Project Lead - Enterprise Services Group > Information Technology Services > California State University, Long Beach > 1250 Bellflower Blvd. > Long Beach, CA 90840 > Office: (562)985-8511 > Fax: (562)985-8855 Matthew Marino IT Manager CSW Inc. 45 Tyburski Road Ludlow MA 01056 (413)589-1311
