FastCGI is recommended for speed, performance and security. The PHP scripts are running using the account owner so if there is a security flaw or hack, it will affect just one site instead of globally by using Apache.
Using FastCGI is an easy job if you only have one website to host but it becomes a challenge when you have many accounts on the same VPS server and you need to treat them differently.
Case 1: Different PHP settings for each account (in my case there were several old websites which needed the register_globals value to be ON – environment: Rackspace hosting, Plesk platform).
The thing is that FastCGI reads only the server’s global php.ini settings. Any attempt to use custom php.ini setttings (suPHP style) or custom apache flags (through .htaccess or vhost.conf) will fail.
My solution was to separate the exceptions (those websites needing special settings) from the majority (the ones that will use global settings) and run PHP as Apache module for the exceptions.
Of course, the global php.ini file will remain reserved for the majority which use FastCGI.
How to overwrite the settings for the exceptions? That depends of the type of value you want to set.
Sure, you can just set the accepted php flags like register_globals using .htaccess (php_flag register_globals on).
I’ve personally choosed to use custom vhost.conf files instead and also set a different open_basedir value for each exception. This way I wanted not to compromise all the security gained by using FastCGI. Every php file running with apache user is limited to the account’s web folder.
- Create vhost.conf file
$ vi /var/www/vhosts/%domain%/conf/vhost.conf
and add
<Directory /var/www/vhosts/%domain%/httpdocs> php_admin_value open_basedir "/var/www/vhosts/%domain%/httpdocs/:/tmp/" php_admin_flag register_globals on </Directory>
- Install vhost file
$ /usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=%domain%
- Restart Apache
$ /etc/init.d/httpd restart
Case 2: When you have a lot of websites installed using FastCGI on the same server (hundreds in my case)
some of them could start to return 503 (Service Unavailable) errors while others still work.
This is a file descriptors issue (file descriptor limit being reached for Apache) and it can be solved by increasing the limit of file descriptors available per Apache process by adding/changing the ‘ulimit -n ‘ line in the /etc/sysconfig/httpd file (e.g ‘ulimit -n 4096‘, 1024 “Max open files” being the default value).
You can verify the value of “Max open files” by finding an Apache process ID:
$ ps aux | grep httpd
..and then viewing the contents of the associated PID limits file:
$ cat /proc/%processID%/limits
