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