This can be done from "PHP Configuration" under your Apache settings
or from SSH using something like the following:
Code:
# /usr/local/cpanel/bin/rebuild_phpconf 5 none dso enabledWhy in the world would want to switch **TO** Apache Module (dso)?
That is going in the exact opposite direction as most of the rest of the world, opens you up to enormous security issues to be concerned about, and doesn't really gain you any performance and in fact in some instances might even reduce your performance verses for example running on an optimized FCGI PHP (cgi) configuration that very often
runs circles around Apache Module (dso) based PHP.
If you are looking back at Apache Module (dso) based PHP for compatibility reasons with applications then you are again looking in the wrong direction as almost always the issue is the program author's incorrect instructions that the PHP and most often the real issue at hand is the correct permissions needing to be used and that is one area that I could definitely more than help you or anyone else with.
So anyway, mainly a curiosity but switch to Apache module -- "why"?
vBulletin runs best under CGI/FastCGI (FCGI) w/X-Cache actually
(There is a lot of technical reasons for this but the simplified basics of that the PHP engine start up is moved off of Apache and the connection and process handling is changed to a non-blocking design)
Anyway though, this will give you substantially faster performance than DSO by a long shot and be comparable to the security of operating under SuPHP so you kind of get a "cake and eat it to" situation there.
I deal with a lot of large scale vBulletin forum clients and what I just said is typically the most popular requested configuration among them all.
Do your clients report or discuss any issues with vBulletin when running php as CGI? vB staff is "down" on cgi but they have not offered any details as to why.
On the contrary, vBulletin is heavily in favor of "CGI" actually and also highly recommend it as the solution to just about everything and if I did not mention this earlier their own support is who told my clients to switch over to "CGI" in each case and that always helped greatly!
Confused? I'm not surprised!
I just used the term "CGI" differently than what you expected and I did so deliberately to illustrate a very strong point as you will soon see.
The reason you are are confused a bit is because the same word "CGI" is used in several different ways when discussing it's relation to PHP and complicates many discussions as it's application depends on it's usage ....
CGI, in the broadest sense covers most everything PHP related that is not "Apache Module" (DGO) and the term can be applied loosely to most any PHP type out there when used in this manner.
CGI, as a specific PHP type usually always refers to phpSuExec though.
When you hear people talking about not using CGI with vBulletin", they are specifically referring to not using either straight CGI or phpSuEXEC which both have some very serious problems which would also be the very reason they have been pretty much abandoned for all practical purposes these days in favor of some of the newer PHP types.
However, in somewhat of an irony, these very same people who tell you that you should not use CGI will at the same time tell you that you should indeed use FastCGI or FCGI though which is actually a CGI based PHP type to add to the confusion and irony. However, this is NOT phpSuExec which I will explain more below. Basically, you have got multiple use of the very same terms and it is not surprising that this little fact creates a lot of confusion for many people out there.
I don't have time to sit here and give you all the in depth technical details as to how each of these PHP type work inside and underneath it all or the reasons and whys as I would be here typing all night as it would be very each to write a 10,000+ book on that subject alone.
With that said though, I will give you a very brief rough outline of the PHP types out there and what you really need to know:
Apache Module (DSO) -- original PHP type that would be the 3rd fastest performance of the PHP types but due to they way it is designed causes more resource consumption, cannot handle ownership and file permissions very well and is riddled with massive security problems and could probably write another book on the subject of why not to use it as the issues with dso cross into nearly every area of discussion.
***** NOTE: I DO NOT RECOMMEND ANYONE USING DSO AT ALL *****
CGI -- The first CGI based PHP solved some of the resource issues previously felt from it's DSO sibling but at the expense of performance and was even more of a nightmare with the unending problems and turned out to be worse than DSO security wise to complicate matters.
phpSuExec -- Basically a subtle variation of plain CGI adding 'setuid' (suexec support) and a few other modifications mainly in an effort to try to address DSO's massive cross site scripting exploit problems specifically but while doing so it actually introduced a few new security issues of its own that much like it's predecessor were much worse than those it was meant to solve. (This is presently CGI plus SuExec)
[NOTE: SuExec is NOT the same as phpSuExec but does use it]
SuPHP -- A different group trying to take a new stab at creating a solution for the problems went back to the drawing board and actually ended up creating a "mixed technology" type that is a blend of both DSO and CGI and unlike prior attempts finally resolved much of the security problems where failed with each of its predecessors. As a plus, it is also substantially faster in performance than either straight CGI or phpSuExec and only slightly slower than DSO but well worth the security and resource advantages it offers which far outweigh any slight degradation in performance over it's DSO counterpart. It is also the best equipped for handling larger numbers of sites on a server making it the best choice for shared hosting type environments since it essentially takes from the best aspects of each of the types out there.
FastCGI/FCGI -- These are actually two different flavors of PHP but I will lump them together because they are so very similar. Originally, this was essentially just a higher performance versions of phpSuExec but it has since evolved substantially and today this is much more like a higher performance version of SuPHP in that its security is now very nearly identical to that of SuPHP though it is a bit more complicated to configure and maintain and not as well suited to handle large numbers of web sites on the same server machine but it's strengths lie very heavily in its ability to handle larger and more heavy traffic sites with a lot more simultaneous users and this is also the PHP flavor with the fastest performance of all the PHP types. It is a very good choice if you have a few sites on your server or a really busy web site with a lot of visitors. The technical differences are quite fascinating from a programmer's perspective but that is definitely beyond the scope of this post which is really just meant as rough draft overview to answer your question.
My first choice in the case of vBulletin would be FGI/FastCGI and might also look into a caching accelerator like X-Cache or similar to push the performance bar a bit further. The second choice on the totem pole behind that would be SuPHP behind that.
I would **NOT** use DSO (Apache), phpSuExec, or standard plain CGI for this (or any other purposes for that matter) for a great many reasons.
Hope this helps clears up a few of these things a bit for you
Spiral
Thanks so much for the post and the time it took to write.
Been pulling my hair out with the working with Impex then vB. vB did ok in testing but yikes, it definitely does not like straight CGI.
This whole php handler issue has taken much to get my head around. Your post helps fill in blanks.
I think I will make a point with vB about how cgi is handled in the documentation and in communications with support staff.
I seriously considered switching to CGI/FastCGI (FCGI)but Php as suphp with suexc is a simple config in WHM. In this mode vB is running fine now although Impex or vB in CGI mode may have buggered mysql. Joomla and kayako are running fine as well.
Thanks again for the post.
Thanks so much for the post and the time it took to write.
Been pulling my hair out with the working with Impex then vB. vB did ok in testing but yikes, it definitely does not like straight CGI.
This whole php handler issue has taken much to get my head around. Your post helps fill in blanks.
I think I will make a point with vB about how cgi is handled in the documentation and in communications with support staff.
I seriously considered switching to CGI/FastCGI (FCGI)but Php as suphp with suexc is a simple config in WHM. In this mode vB is running fine now although Impex or vB in CGI mode may have buggered mysql. Joomla and kayako are running fine as well.
Thanks again for the post.
To throw in another wrench to the topic of PHP being complicated, every PHP type except DSO and sometimes FCGI shows up as just plain "CGI" when you look at your phpinfo() screen even though they are different so trying to tell what kind of PHP you are using cannot be done from the phpinfo() screen reliably other than simply telling whether a server is DSO based or not and that is pretty much all you can do there.
To really tell what kind of PHP is running on a system, you should look at "PHP Configuration" in WHM, in the "/usr/local/apache/conf/php.conf" file, or run the shell based PHP configure command from Cpanel:
Code:
# /usr/local/cpanel/bin/rebuild_phpconf --currentYou're welcome
The operational aspect of FCGI and SuPHP is identical and you can usually switch back and forth between these two without having to make any changes to your web site scripts and applications.
However, when switching from DSO, there are some rules:
1. No folder or file anywhere should have 777 permissions
(Actually 777's are not needed under SuPHP or FCGI either!)
2. Do not use any "php_flag" or "php_value" commands in .htaccess
3. All files on your site should be owned by your username and
not mixed ownerships with "nobody" as you find under DSO.
Ignoring the above rules can cause your site to fail with Error 500 or run
into slowdowns, performance issues, and other bugs and problems.
Regarding #1 (permissions) above, the following is good choices of
permissions to use under either SuPHP or FCGI on your site and
would actually super-ceed any script authors instructions:
755 All Folders (Including those script authors tell you to set '777')
600 All PHP Scripts
400 Those PHP Scripts that Complain about being "Writable"
and wrongly assume your 600 is really 666 or 777. (Rare)
755 All Non-PHP Scripts (*.pl, *.pm, *.py, *.cgi, *.e)
644 All Non-Script Files (Images, Templates, Plain HTML, Text, Etc)
Anyone having problems getting around why their scripts work or don't
work under different PHP types may find this post of significant help but
anyway good luck with your forum ventures there.
Hi Spiral,
So if I read your suggestion correctly, you are recommending to (in EasyApache):
- Turn ON Mod FCGID
- Turn ON Fastcgi
Correct?
1. Do you recommend turning OFF Mod SuPHP? Or leaving it on?
2. What about Suhosin? Off or on?
Thanks in advance.
So if I read your suggestion correctly, you are recommending to (in EasyApache):
- Turn ON Mod FCGID
- Turn ON Fastcgi
Correct?
1. Do you recommend turning OFF Mod SuPHP? Or leaving it on?
2. What about Suhosin? Off or on?
Thanks in advance.
You have to enable FastCGI in BOTH PHP and Apache options in EasyApache in order to have FCGI based PHP available to your server.
To be perfectly honest, I recommend anyone compiliing for FastCGI
to leave SuPHP fully enabled when rebuilding their server in EasyApache.
Why do I say this when you can only use one or the other at a time?
If you build your system with both FCGI and SUPHP, you can switch between them in a heartbeat without having to recompile your server and I have found this very useful on many, many occasions.
FCGI and SUPHP are file and folder permission identical so you don't have to update any of your web site content when changing between these two types of PHP and can go back and forth easily in a matter of seconds on servers that have built to support both of these types.
Code:
# /usr/local/cpanel/bin/rebuild_phpconf 5 none fcgi enabled
Code:
# /usr/local/cpanel/bin/rebuild_phpconf 5 none suphp enabledSpeaking from a security point, having Suhosin installed and is a good idea.
Asking about it working with vBulletin and such, I have never known it to be any great conflict or cause any significant problems with that program.
That's great. Do per-directory php.ini configurations work with FCGI just as they do on SuPHP?
Yes, but unlike SuPHP it is not as easy to disable which is a secondary reason why I don't generally recommend FCGI for commercial shared hosting but for single sites or more privately controlled sites, then FCGI is the more ideal choice in many cases.
(On SuPHP, I like to disable user controlled PHP.INI files and move the custom configurations off to administrator only controlled areas of the server for security reasons)