Rightio.. lol, where to begin with this one.
Well, recently we had some site downtime.. this started as a power failure at the data center apparently. Then we are informed that we were being moved to a brand spanking new server as the older server was out of warranty and our host does not run their servers after this has expired. They purchase new gear and transfer the sites to the new servers.. Sounds great.
I've also been informed that we have been move from a US data center to a UK data center, great.. I'm in the UK.. Suits me fine.
The move was smooth, the site has been running flawlessly and the support has been informative and concise.
Last night.. No site. I fire off a support ticket and wake this morning to find it working, although no style sheets are loading.. Now no site at all again. While we wait to have another ticket processed.. I'm here half asleep, rambling. Now, those in the know.. probably already know about this.. Those who don't.. it may serve as a heads up before your host makes the upgrade.. Read on..
QuoteHi Chris,
I'm forwarding this over to the support department who will deal with the Internal Server Error for you, it is due to phpSuExec running on the server.
Please hold on, they will fix it as soon as possible.
What phpSuExec is:
On most Apache servers, PHP runs as an Apache module. This is the default method of installation. Many hosts have this setup because it is default and potentially they do not realize that it is also possible to configure PHP as a CGI. Running PHP as a CGI can be more secure whilst also avoiding file and directory ownership issues.
PHPSuExec provides the facility to have all scripts running the relevant user account instead of under the Web Servers account. This facility allows the server Administrators to isolate and manage malicious or runaway script usage very quickly, avoiding unwanted or un-authorised scripts from running for a lengthy period of time. Evo uses PHPSuExec on all shared, semi-dedicated and reseller hosting servers.
What does phpSuExec Do?
777 Permissions
With non- phpSuExec configurations, PHP runs as an Apache Module it executes as the user/group of the webserver which is usually "nobody", "httpd" or "apache". Under this mode, files or directories that you require your php scripts to be able to write to need 777 permissions (read/write/execute at user/group/world level). This is not very secure because it allows the webserver to write to the file, it also allows anyone else to read or write to the file.
Under phpSuExec configurations, PHP running as a CGI with "suexec" enabled (su = switch user, allowing one user to "switch" to another if authorised) - Your php scripts now execute under your own user/group level. Files or directories that you require your php scripts to be able to write to no longer need to have 777 permissions. In fact, 777 permissions are no longer allowed, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a "500 internal server error" when attempting to execute them, this is done to protect you from someone abusing your scripts. Your scripts and directories can now, only have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else).
My script requires 777
So what about php scripts that say they require 777 permissions on some of their directory or files to work, such as a Joomla!, Forums, photo galleries and alike? Due to the transparent nature of phpSuExec this is solved very simply, any directories stated as requiring to be "writable" or "777" can safely be set to 755 (the maximum) instead. This is because, now that the web server runs under your own user account, only your own user account needs full write and execute permissions.
Goodbye ".htaccess" and Welcome ".ini"
Under the old Apache Module mode it was possible to manipulate the PHP settings from within a ".htaccess" file placed in the script's top-level directory, this was also recursively applied to all other directories below it.
For example you could turn on the php setting "magic_quotes_gpc" with this line in .htaccess:
php_value magic_quotes_gpc on
Now, when PHP is running as a CGI and phpSuExec protected, manipulating the PHP settings is still possible however you can no longer make use of a ".htaccess" file. Using .htaccess with the required PHP prefix of "php_value" will cause a "500 internal server error" when attempting to access the scripts. This is due to php no longer running as an Apache module, thus Apache is unable to handle those directives any longer.
Noting that Evo uses phpSuExec, ALL php values should be removed from your .htaccess files to avoid the 500 internal server error. Instead, you will now be creating and using your own "Local php.ini" file to manipulate the desired php settings.
What is a php.ini file?
The php.ini file is a configuration file that the server looks at to see what PHP options have been made available to the server or what their setting are, if different from the server's default php.ini. While the name may seem advanced to those unfamiliar with it, it is in essence a simple text file with the name php.ini
How to create a php.ini file
To create a php.ini file, just open up a text editor, add in the lines you need and save the file. You can name the file whatever you wish when saving, to ensure the correct FTP transfer mode is used, you might wish to name it "php.ini.txt". Once you have configured all your settings, upload the file to the directory where your script is located and then rename it back to php.ini
For example you can turn on the php setting "magic_quotes_gpc" with this line in php.ini:
magic_quotes_gpc = on
In many cases, you might need to have multiple copies of the same php.ini file in different directories, unlike .htaccess files, php.ini files are not applied recursively to lower directories. If you need the same functionality across all lower directries also, you will then need to copy the php.ini file each directory in turn that will have .php scripts running from within them. Click here for a sample php.ini configuration file.
Troubleshooting, something went wrong
My php script doesn't work or I have an error message.
1. Check that the php script that you are attempting to execute has permissions of no more than 755 - 644 will work just fine normally, this is not something that will need to be changed in most cases.
2. Check that the directory permissions that the script resides within is set to a maximum of 755. This also includes directories that the script would need to have access to also.
3. Check that you do not have a .htaccess file with php_values within it. They will cause a 500 Internal server error, when attempting to execute the script.
The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the php directives as explained above.
Tim M.
Managing Director
Evo Hosting
Which has confused the poo outta me as we have a nice custom .htaccess file that is now essentially useless
I suggest you make a BIG pot of tea, and then sit down, read the info again and take it step by step as explained in the text ;)
I think they had better fix what They broke.. else there will be no data center :knuppel2:
It's suddenly dawned on me that another public_html file resides inside the root public_html file. I don't have ownership of this file and it's been left there from an old support ticket.. It seems to me that they have confused the 2 and I have no idea what they did last night.
Boot in the but or put some 1000w/rms right in their ears and hope they will listen after that :2funny:
Gah.. I don't believe it!
Now they've confused the database with my test site at /smf2.labradio/
:uglystupid2: :tickedoff: :idiot2: :uglystupid2: :tickedoff: :idiot2:
I swear... I am going to scream *takes a deep breath* now I can't do a thing from work... Arrrrrggh!
Ignore me and my ranting
Good thing you have those backups, eh? ::)
Good thing my host backs the site up every night ;)
I'm still gonna throttle him :tickedoff:
umm TPH (http://www.tinyportalhosting.net) for you me thinks :coolsmiley:
Quote from: ZTN
Do you upgrade your servers every 2 years?
nope every year lol
My hosting service went though this about a year ago. In the long run I do believe phpSuExec is better, safer way to go, Pain to work out the bugs for each config... As far as your .htaccess file goes, it is still there and still used by apache for apache configurations... but for any PHP runtime configuration changes, that all gets moved to the ini file. At least that is the way it is working on my sites.
Good luck....
See-ya
Quote from: Lesmondâ,,¢ on May 30, 2008, 07:49:54 PM
Quote from: ZTN
Do you upgrade your servers every 2 years?
nope every year lol
Really? I will be surprised if you do! Very!! And I mean, new gear.
Quote from: GhostRider2110 on May 30, 2008, 08:22:48 PM
My hosting service went though this about a year ago. In the long run I do believe phpSuExec is better, safer way to go, Pain to work out the bugs for each config... As far as your .htaccess file goes, it is still there and still used by apache for apache configurations... but for any PHP runtime configuration changes, that all gets moved to the ini file. At least that is the way it is working on my sites.
Good luck....
See-ya
Thanks Mitch.. as always..
Look.. I don't know a huge amount about servers.. I know my trade as an electrician more than most.
I know about missiles and rockets.. not that I want to... But thats my job.
I know didly squat about servers.. I can help with TP.. The admin side...
Servers?.. yeehar!
hehehe.. hmm.. hate to say it, but im getting ready to learn about them too Zetan.. I'm picking up one i think that has about 20 gigs.. think that will be enough guys?? :o :P
by the way, that was a very interesting read.. funny how we learn something new everyday.. hope you get yours figured out.. ;)
hope you dont mind Z...
Smoky 20gb you can use up so fast, is that dedi/vps?
im not sure.. looking into it with a friend.. he knows way more than i do and will be running it so to say.. ;)
i know the different between them but the setup etc., not sure at all.. i should know more by Sunday.. :D
Carry on
I am about to break something though. It aint even funny anymore.
Angry is a polite word
Oh you poor lad.
Sorry to read that youre goin through this.
Head up, shoulders back, and launch the missles! lol
Hopefully everything comes full circle :)
Make sure you get a BIG refund for all the downtime in their mess
At least some hosting free. I posted a topic at our test site which seems to be working fine.
http://smf2.labradio.co.uk/index.php/topic,7.0.html