• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

PHP as FastCGI - domain specific php.ini?

M

mindpalette

Guest
Hi - is it possible to run PHP as FastCGI and have per-domain php.ini files in Plesk? I've got PHP running as FastCGI, but things like sessions aren't working (presumably permissions problem from not being able to write to the top level /tmp directory?), and I'd like to be able to set basedir and other common config options on a per-domain basis.

Wasn't sure how to run PHP through a wrapper that loaded the extra configs... thanks in advance for any advice.
 
There's not much on this in the PLESK docs or FAQs it seems. And there is no obvious setting in the PLESK admin web either to get a domain-specific php.ini.

For sessions to work, the PHP value sessions.save_path has to be set to a path writable by the current user. Overriding this value in .htaccess does not work any more, since the PHP interpreter runs as FastCGI and not module. Since at least on CentOS 5 Parallels included mod_fcgi < 2.1, options to the FastCGI executable cannot be specified in the httpd.conf either.

So the way to specify a per-domain php.ini would be to modify the apache per-domain configuration and have the httpd call the FastCGI executable using a wrapper script like:

$ cat /var/www/vhosts/somedoma.in/cgi-bin/php-fcgi
#!/bin/sh
export PHPRC='/var/www/vhosts/somedoma.in/conf'
exec /usr/bin/php-cgi "$@"

The php.ini would then be searched for in the ./conf subdirectory of the domain.

This setup works great for me on another server without PLESK and based on Fedora. But on the Plesk 9/CentOS 5 based machines, the php-cgi seems to ignore PHPRC and command line options like -d and -c.

If anyone could provide any insight on why this is happening. Is it intentional?

Thanks,
-h
 
Or htscanner.

Thanks for suggesting mod_suphp. It looks like a viable solution, but I haven't tried it yet. How do you specify the path to a per-domain php.ini using mod_suphp?

Another solution might be htscanner, which allows having php_value settings in .htaccess files for php-cgi. I kind of like the idea of not having to manually maintain a php.ini or an fcgi-wrapper for each domain. When a domain needs to have it's session.save_path modified, it could just do so in it's customized .htaccess. I wonder how htscanner determines which settings the customer may override.

I'll take both mod_suphp and htscanner for a spin today or tomorrow and post my findings here.

-h
 
Is not supported by PLESK, but it is easy to install and can be managed by Power Toys.
 
Thanks, had a look at the howto. Seems all suphp does it defer the executing to php-cgi. Anyone can explain me the advantage of using suphp over just, say, FastCGI?
 
Does anyone know if newer Plesk versions have support for having PHP specific settings per each domain?

Thanks.
 
Not in the best way there is FastCGI but not working (at least for me) so this is why we still suggest mod_suphp, we run it in over 20 server now (and installed on over 100) and working fine.
 
I'm trying to do this too, and I don't want to install suphp or any other module if at all possible. The core of the problem seems to be that PHP doesn't look for php.ini files in the 'current working directory' as it' suppused to. A php.ini file in the same directory as the executing script isn't picked up.

I've done some research and it seems that because Plesk arranges things so that php-cgi is called via a wrapper script, PHP thinks the 'current directory' is the wrapper directory when it is invoked. phpinfo shows the wrapper directory as the ENV variable for PWD. Yet if you make a .php file just shell execute and display the PWD it shows that .php script file's directory. So by the time the .php script is actually running, it knows the correct current directory - it's just during invocation when php-cgi is looking for a php.ini that it's confused.

Now if the wrapper file was doing something obviously useful (initialising stuff or setting env vars etc) I could see why it would be a problem bypassing it. But all it seems to do is exec the php-cgi binary. I know I could just edit the wrapper to set a PHPRC path or use a -c option on the php-cgi call. But that would hard code that php.ini for all domains (effectively the same as I have now!)

What I'd like to do is set the apache conf file(s) to point to the php-cgi directly, rather than the wrapper. That way I hope php-cgi will look in my script's directory (on whichever vhost it resides) for a php.ini file. Anyone know which files to edit and how? I've tried some obvious ones - changing the 'path to wrapper' to /usr/bin/php-cgi in the php-cgi.conf file. But didn't seem to work. Also found a path to the wrapper script in zz0_blah plesk apache conf file. But that one has dire warnings about editing it. So I didn't, and came here instead!

Can anoyone point me in the right directiom here? Really want to avoid suphp etc. This should be a simple fix, surely.

Many thanks,

Rich
 
So the way to specify a per-domain php.ini would be to modify the apache per-domain configuration and have the httpd call the FastCGI executable using a wrapper script like:

$ cat /var/www/vhosts/somedoma.in/cgi-bin/php-fcgi
#!/bin/sh
export PHPRC='/var/www/vhosts/somedoma.in/conf'
exec /usr/bin/php-cgi "$@"

The php.ini would then be searched for in the ./conf subdirectory of the domain.
Further to my previous, I can't get PHPRC to work either but I am able to edit the wrapper file to include a -c option when invoking php-cgi. But I don't know how to edit the per domain configuration file to call a custom wrapper script.

Better still would be a clever way to set the PHPRC to the correct per-domain path at run time depending on which domain was firing thw wrapper. Something like /var/www/vhosts/[$DOMAIN]/conf. Is there an alias for the domain name I can put in there?

Thanks,

Rich
 
Last edited:
Back
Top