please help - am at wit's end on this

[sfullman]

I believe I can explain the situation and give an example - what I can't do is understand why. PLEASE HELP 🙂 has to do with PHPSUEXEC

I have a linux server - it's a dedicated server with hostgator

I developed a great application for console management on my main site in a folder called console

on my other sites, I did the following:

ln -s /home/rbase/lib/console

the console ap majically figured out its environment and worked for each of my clients' websites

furthermore, I also did this

ln -s /home/rbase/lib/devteam/php/atomic_functions functions

so any of my sites can do this:

require('functions/myfunction_whatever_v100.php');

NOW, ENTER PHPSUEXEC (dramatic music here)
We moved to a newer server running phpSuExec, and when I try to call www.clientsite.com/console in the browser I get,

Internal Server Error

However the weird thing is that the second feature, i.e. the require() feature, works just great. And furthermore, I can view non-php files, but trying to call any php file in the browser will give me the same Internal Server Error

If you want to see this, go to:

http://www.corridorcats.com/functions

Again, the functions folder is not a real but a "symbolic" folder linking to my main account

click on changelog.txt - that reads fine

now click on the first php file - function_CMSB_v100.php - notice, Internal server error

I MIGHT accept some unimaginative IT guy telling me that you can't run cross-account files like this, but I don't believe that because, in any file in corridorcats.com, you could do this and it would work/process fine:

require('functions/function_CMSB_v100.php');

I am really desperate to solve this; would be willing to pay for a solution as my console is down till this is fixed.

Thank you,
Samuel

[bradgrafelman]

First question that comes to mind: is safe_mode enabled (do a phpinfo() to check) ?

[sfullman]

Brad, safe_mode is in fact off - running php version 5.2.13

I know from hostgator that we are running PHPSUExec - though I don't know where to see that but I do know it's running because it's damnably restrictive 🙂

the most unusual thing is this, for a symbolically linked folder on the site leading to another folder, you can do this:

require('my_sym_link_folder/my_sym_link_file.php');

which will process exactly as if we were calling the file ourselves - so i.e. it executes. Yet if I try to go to:

http://mysite.com/my_sym_link_folder/my_sym_link_file.php

I get that Internal Server Error msg

Am convinced this is a SuEXEC/permissions issue

What do you recommend next?
Thanks

[bradgrafelman]

Not sure what to say (other than perhaps ask your host?). You could try creating a .htaccess file in the root of your site that has this:

Options +FollowSymLinks

but that's just a shot in the dark, really.

[sfullman]

so to PHPSuExec I say:

"I am Samuel Fullmanin Maximus .. and I will have my revenge - in this life or the next"

[sfullman]

OK, so on this crazy adventure here's the deal. I found a hack solution. First of all, so, you can REQUIRE() a file inside of a symbolic link, but if you try to "GO TO" a file in a symbolic link, it says Internal Server Error - however:

1. I'm not convinced this is a real limitation, I believe it's a permissions issue with either too little or, with PHPSuExec running, too much.

2. I will come up with a better solution than this - either in this life or the next..

HERE IS THE SOLUTION:

1. rename the symbolic link console-sym

2. create a "real" folder named just console

3. create a .htaccess file in the console folder with this line:
   ErrorDocument 404 /console/index.php

4. Now create the index.php page with this simple coding:

   
   if($GLOBALS['REDIRECT_URL']){
   	$QUERY_STRING=$GLOBALS['QUERY_STRING']=$GLOBALS['REDIRECT_QUERY_STRING'];
   	require(preg_replace('#^/console/#','../console-rbrfm/',$GLOBALS['REDIRECT_URL']));
   	exit;
   }else{
   	require('../console/index.php');
   }
   
   

   I'm sure this index page coding needs to be tweaked some (OK a lot), but lo and behold I was able to view the dynamic console again and it navigates just as if it were the "symbolic" console on the old server.

   I hope this helps someone who really wants to use symbolic links in this type of environment.

   Samuel

[bradgrafelman]

As you said, using require() works fine and yet trying to use the symbolic link in the URL does not. That would appear to suggest that Apache is falling short when it comes to symlinks. However, you did also say that plain .html files inside of the symlink'ed dir work fine, correct? If so, that would seem to place the blame back on PHPSuExec (or perhaps the two share the blame? :p)

To rule out permissions issues, however, did you try giving both the symlink and target PHP files wide-open (e.g. 777) permissions?

[sfullman]

Brad, the problem with PHPSUEXEC is that, if permissions are 777, the file will not run at all.. PHPSuExec means php runs as that site username vs. nobody - and if a file is chgrp'd to someone else and esp. if grp has rwx access, phpSuExec will not process. So ironically too much permissions are a problem too, and I've not yet seen a definitive chart on exactly how PHPSuExec Thinks.

Thanks,
Samuel

[bradgrafelman]

If you're on a dedicated server... is there really any need for something like PHPSuExec anyway?

EDIT: Found this:

The maximum permissions permitted on directories and .php files is 755. Failing to have have permissions set to a maximum of 755 on php files and their installation paths, will result in a 500 internal server error when attempting to view them.

So... what are the permissions on your symlink, the target dir, and the target PHP file?

EDIT2: Some more FAQ's that might be of use:

#5. Troubleshooting
My php script doesn't work or I have an error message:
1. Check that the php script that you are attempting to execute has permissions of no more than 755. Permissions of 644 will work just fine normally. This is not something that will need to be changed in most cases.

2. Check that the directory permissions that the script resides in are set to a maximum of 755. This also includes directories that the script would need to have access to.

3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.

[sfullman]

bradgrafelman;10955091 wrote:

If you're on a dedicated server... is there really any need for something like PHPSuExec anyway?

before PHPSuExec, I had to do a special dance to give users access to upload and manage files - had to make the image folders available for write by "nobody" - but with PHPSuExec acting as that site name, that problem was solved.

However I heavily rely on symbolic link libraries, and after further testing i'm pretty well set to give up - PHPSuExec wins this one. However, there is a way I found to overcome this:

1. change the sym link folder name to application-sym for example
2. make a folder called application
3. in the application folder, have the .htaccess file say

   ErrorDocument 404 /application/index.php
   

4. have index.php simply have this code:

   require('../application/myhack.php');
   

   and have that file be the code I created above. application/index.php will masquerade as the symbolic application - a hack yes but it works. I'm refining the myhack coding for efficiency and will share with the forum when done.

How you code the links and includes in the application needs to be done more carefully and I'm finding there are a few rules, but nothing radical. AND this myhack coding should work for any symbolically linked folder.

but re: navigating to the file as a url, I put a simple hello world file in the server root, give it 644 permissions, and sym-linked it on a site - regardless of the permissions, it gives internal server error.

[sfullman]

Before I stated I'd figured out how to get past PHPSuExec with a linked library folder/application, here is a summary again with improved coding in the index.php page, and the .htaccess file,

to reiterate
1. name your symbolic link folder myapplication-sym
2. create a "real folder" named myapplication
3. in that folder have a .htaccess file as follows:

ErrorDocument 404 /myapplication/index.php
RewriteEngine on
RewriteRule (.+).(css|js)       ../myapplication-sym/$1.$2

4. in that folder have a file named index.php with this code:

   require('../myapplication-sym/aphack.php');
   

5. in your application folder, the code for aphack.php should read like this:

   header("HTTP/1.1 299 OK", true);
   if($f=$GLOBALS['REDIRECT_URL']){
   	$QUERY_STRING=$GLOBALS['QUERY_STRING']=$f;
   	require(preg_replace('#^/myapplication/#','../myapplication-sym/',$f));
   }else{
   	require('../myapplication-sym/index.php');
   }
   

Note the header - if you can actually get apache to output a 200 then go for it - but I can't seem to override a 404 with a 200, only a 299 and it does work.

I hope this helps someone bright enough to use symbolic links but unlucky enough to be stuck with PHPSuExec. PHPSuExec, I shall have my revenge..

Samuel