Quick version - is there any way to compile the php port to get both the cgi version of the php executable and mod_php, as well as PEAR?



Long version - mod_php is not affected by apache suexec - instead, php files in the normal document root of the webserver are executed as the global apache user, www by default. suexec only affects cgi scripts.

But I have a php script that has to run on a multi-homed machine where some users already use mod_php. The script needs to be able to create, delete and modify files. Rather than give the www user permission to do this, so every virtual host on the machine could run scripts to edit and delete the files in question, I want to run the script suexec from the cgi-bin.

I can run php scripts suexec as cgi by prefacing them with #!/usr/local/bin/php and making them executable. But I need the cgi version of the php executable for this to work. Http headers get mishandled otherwise and it can be all very irritating.

make options in the /lang/php4 port include:

WITHOUT_APACHE (not mod_php - defaults to cli(command line))
or
WITHOUT_CLI (defaults to mod_php (equivalent to installing the www/mod_php port))


only with both options do you get the cgi version of php - but no PEAR and of course no mod_php.

So how do you compile with both mod_php and cgi php? They do seem capable of working together. I made but didn't install www/mod_php4, then made and installed /lang/php4 with the above two options, getting the cgi executable at /usr/local/bin/php, then I copied libphp.so from the work directories of www/mod_php4 to /usr/local/libexec/apache/ and made sure the correct lines were in httpd.conf and they both seem to work fine.

Another alternative would be to copy the cgi version of /usr/local/bin/php off to one side, install /lang/php4 as normal, then copy back the cgi pgp executable. That way, I'd have PEAR. If I also want the cli version available, I assume I could rename it php-cli or something before copying back the cgi version.

I am a bit unhappy at this being outwith the normal package/port management system, though. I'm also concerned there might be issues I am unaware of that affect the wisdom of this type of activity.

Does anyone have a more elegant solution to this problem? I considered mod_suphp (http://www.suphp.org) but feel reluctant to put it on a production machine.

PWR.

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to