mod_php with ruid2 vs PHP-FPM - for shared hosting

nservices

Verified User
Joined
Dec 11, 2008
Messages
301
Hi,
I Would love to get advice on choosing the method of work in custombuild 2.0
What matters to me (in order of importance):
1. Security
2. Speed / Performance
3. server resources
4. "default" File Permissions (644 + 755)
5. Flexible user-level resource limit (memory and PCU, Processes limit)
6. Set php.ini file per user
7. nginx Compatibility (for the future)

Best Regards,
Star Network.
 
Last edited:
Hello,

1/2/3/4/5/6) Each setup has differences which may make it more secure in one case, but less in another.
CLI: this mode runs php scripts as "apache". This means it cannot write to disk unless folders are either chmod to 777 or chowned to apache.
This can be more secure since a compromised script cannot affect anything, as apache cannot write to a folder which is chowned to the User (assuming it's not 777).
However, since the php scripts run as apache, it's more difficult to track down which script belongs to which User.. say for example, which User was writing to a tmp folder, or which script is using up all of the server resources.
CLI is also quite quick and low memory usage since no forking is done, and the same process can be used for all VirtualHosts (no user changes needed). Memory accelerators can be used with this mode. CLI cannot have per-User php.ini files, but can have per-domain settings in the VirtualHosts to enable/disable php features. It can also use .htaccess files to enable/disable php features. It's difficult to lower cpu usage in this mode because the processes run as apache, so the system can't easily tell which User to slow down (if a limiter is available)

suPhp: This mode runs php scripts as the DA User (owner of the files). This has advantages for shared hosting, as it keeps users contained to their own directory more easily. With suPhp, you can chmod a php script to 600, which is much more secure. It also is one extra layer of security. With CLI, security relies on the secure_access_group, the apache symlink patch, open_basedir, etc.. With suPhp, you can use those, in addition to the User privilege segregation, making things one extra level more secure. However, php scripts that run as the DA User, can also write to folders owned by the DA User (eg: all of that User's files). This means, if a script is exploited, although the issue will be self contained to that User, the exploit can potentially hurt that User more. The performance of suPHp is likely the lowest of the 3 types of php, however for most cases, you won't notice any sort of slowdown (we use it on several of our test boxes for the extra level of User segregation/security). Memory usage is going to be slightly than CLI on a per-request basis. It keeps the box and everyone else safer if anything bad happens. suPhp supports per-user php.ini files to make changes. Memory accelerators can not be used with this mode.

php-fpm: This mode runs php via a stand-alone php server. Apache acccesses this php server to make queries. Php scripts run with php-fpm have many of the same features as with running suPhp. Php-FPM is a much more complex system, but if working correctly will give you the absolute fastest performance, as memory accelerators can be used with this mode, in addition to the benefits of having a separate php server (file caching). Memory usage with php-fpm can vary drastically depending on how it's setup. At least 1 process is needed per DA User during a request for that User. We use the on-demand mode which only runs the User processes that are needed...they stick around for a while in case other requests come in, but then dies after a short period to help lower the memory usage. If all of your sites are very busy, then you may be very short on ram. The php.ini setup is on a per-User basis, in a php-fpm.conf file. php-fpm is much newer technology, and has much less testing.. and add the extra complxity, and it may not yet be the best choice for a production box.. but after more testing and proving itself, it may end up being the top choice.


7) Changing out nginx is a fairly major thing to swap out... I've not personally used it before, so cannot comment on it too much, however by using php-fpm, php is completely unaffected since the php-server is separate from nginx. The requests to php-fpm are the same from apache, as from nginx (no php config changes would be needed)

8) I've added an extra point to mention mod_ruid2. What mod_ruid2 does is lets the actual apache process run as the User as needed. It does this with the seteuid function instead of the setuid function. What this means is that it can go back and forth between Users without forking, making it essentially zero cost to add in. If you combine mod_ruid2 and CLI, this will be the simplest, quickest, proven, and most flexible combination at the moment. It runs php as the User (like suPhp and php-fpm) for the extra level of User segregation. For these reasons, this is the default for CB 2.0.

John
 
Hi John,
thanks for the answers - It helps me a lot!
if mod_php with mod_ruid2 run php as the user I can configure php file per user?
there is guide for it?

Best Regards,
Star Network.
 
php-fpm is stable from long time (from 5.3.3?). CB 2.0 don't change it, don't make it more stable ;)
 
Hello,

php-fpm itself is likely stable, however, the use of it with CB2 is still very new and still in testing (although, I believe we're in RC1 now)
As mentioned, it's setup and control is a very complex one (not to mention new to us), so there may be bugs in how we've implemented it (configs, etc..).. but not with the php-fpm itself.
For this reason, it may not be the best choice for a production environment, unless you're very familiar with php-fpm, it's use, and how we've gone about setting it up.. as bugs can, and usually do happen with the implementation of new technologies.

John
 
Recently I've found this article, which I'd like to share:
http://boomshadow.net/tech/php-handlers/

There are no speed comparisons posted there, nevertheless it might be interesting for those, who are not sure, what implementation to choose. A Comparison Graph looks very interesting.
 
Hello,

php-fpm itself is likely stable, however, the use of it with CB2 is still very new and still in testing (although, I believe we're in RC1 now)
As mentioned, it's setup and control is a very complex one (not to mention new to us), so there may be bugs in how we've implemented it (configs, etc..).. but not with the php-fpm itself.
For this reason, it may not be the best choice for a production environment, unless you're very familiar with php-fpm, it's use, and how we've gone about setting it up.. as bugs can, and usually do happen with the implementation of new technologies.

John

Can i file a bug report?
last weekend i tried to build my newly setup server with the php-fpm option so i set the option and built php. After the build process apache fails to start due to syntax error, the error message in the log states "Syntax error on line 4 of /etc/httpd/conf/extra/httpd-hostname.conf: </IfModule>". When i looked into that file with nano i noticed that the syntax was not correct. The conf file closed with </IfModule> and </Directory> but the start tags where missing. If i added the tags, apache would restart and function normally.
 
There was a bug in the httpd-hostname.conf, but resolved about 7 days ago.
Confirm you've got a fixed version by doing
Code:
./build update
./build rewrite_confs
John
 
Great ;-) tried it again and it works like a charm now ;-)
thanks for the quick reply and help!
 
This is a bump reaction, but there is important information in this topic I want to respond to.

Is php-fpm safe to use? What if a user gets hacked, is the damage still limited to that user (like suphp or mod_ruid2) ?
 
Back
Top