Jump to content


Photo

Php Upgrades


  • Please log in to reply
28 replies to this topic

#1 TCH-Dick

TCH-Dick

    General Manager

  • Admins
  • PipPipPipPip
  • 5,786 posts

Posted 10 August 2010 - 02:26 AM

Greetings,

We are now in the process of updating all shared/reseller to PHP 5.2.14, however, there are some major changes being made to our setup. The primary change being that we are migrating our PHP Handler setup from DSO to SuPHP for added security and to make the use of PHP more user friendly.


So what does all this mean for you?

  • PHP scripts will no longer be ran or owned by the user "nobody", you will now own all of your files and those created by your scripts.
  • File & Folder Permissions are now easier to work with and more secure. You no longer need to have directories or files set to 777 and there is maximum supported permission of 755.
    • Any scripts that require 777 should use 755 instead.
    • Generally, set folders to 755.
    • Generally, set files to 644.
  • php_value and php_flag options no longer work in .htaccess files NO! While this is standard for SuPHP, we found it to be an unacceptable compromise and have implemented an additional option to allow continued use of these options. To use these options they must be enclosed in the <IfModule php_config> </IfModule> container element.
    Example:
    <IfModule php_config>
    php_value register_globals 0
    </IfModule>


We plan to complete these updates by the end of the month, however, there are no specific dates set per server. Since the downtime will minimal or not all, we will announce each update in the appropriate server thread once completed.

As with any server updates, we do expect a small of amount of accounts to have issues. We will do all we can to mitigate any issues, but should they occur we will be here to assist and correct.

Thanks your for time and please let us know if you have any questions or concerns.

Dick DeVance
General Manager
TotalChoice Hosting, Inc
dick@totalchoicehosting.com


Posted Image


#2 OJB

OJB

    Immediate Family

  • Members
  • PipPipPipPip
  • 364 posts

Posted 10 August 2010 - 03:24 AM

Thanks for the info, Dick, do you happen to know whether if we have the php_value and php_flags in our .htaccess without the additional module block you show above will result in application errors or if it would essentially die gracefully and not throw any errors and just ignore them? Reason I ask is if I am not 100% on the ball and the upgrade to the server I am on goes through would any sites making use of those .htaccess commands stop working, or will those commands just be ignored and the application will continue to run?

#3 SteveW

SteveW

    Distant Family

  • Members
  • PipPipPip
  • 129 posts

Posted 10 August 2010 - 04:49 AM

Thank you for the advance notice, and thank you for posting the changes in the server threads. It will help a lot to know right away when the changeover occurs.

Even if the <IfModule php_config> workaround allows PHP configuration to continue to work in .htaccess, will it be permitted to use a public_html/php.ini file as an alternative? Would it be the preferred alternative? There are some options allowable in php.ini that can't be done in .htaccess.

#4 TCH-Ryan

TCH-Ryan

    Immediate Family

  • Members
  • PipPipPipPip
  • 274 posts

Posted 10 August 2010 - 09:33 AM

Thanks for the info, Dick, do you happen to know whether if we have the php_value and php_flags in our .htaccess without the additional module block you show above will result in application errors or if it would essentially die gracefully and not throw any errors and just ignore them? Reason I ask is if I am not 100% on the ball and the upgrade to the server I am on goes through would any sites making use of those .htaccess commands stop working, or will those commands just be ignored and the application will continue to run?


We have in place a conversion process that will take any existing php_flag/php_value options from htaccess files and wrap them in the <IfModule php_config> element tag, this allows for a seamless migration and avoids any errors. Specifically though, once a server is migrated to suPHP, without the element tag surrounding the php_flag/php_value options, the site will throw error 500 pages which is why we are putting so much time and effort into ensuring that our conversion process for .htaccess files is one that is reliable and consistent.
Kind Regards;
Ryan MacDonald
Data Center Manager | TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com | ryan@totalchoicehosting.com

#5 TCH-Ryan

TCH-Ryan

    Immediate Family

  • Members
  • PipPipPipPip
  • 274 posts

Posted 10 August 2010 - 09:36 AM

Thank you for the advance notice, and thank you for posting the changes in the server threads. It will help a lot to know right away when the changeover occurs.

Even if the <IfModule php_config> workaround allows PHP configuration to continue to work in .htaccess, will it be permitted to use a public_html/php.ini file as an alternative? Would it be the preferred alternative? There are some options allowable in php.ini that can't be done in .htaccess.


Though we would rather see .htaccess files used to configure PHP, we do fully support the use of php.ini files on suPHP servers.
Kind Regards;
Ryan MacDonald
Data Center Manager | TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com | ryan@totalchoicehosting.com

#6 SteveW

SteveW

    Distant Family

  • Members
  • PipPipPip
  • 129 posts

Posted 10 August 2010 - 10:15 AM

Considering that TCH has automated methods for the transition, none of the below may be necessary but I'll go ahead and post it anyway, partly to find out if there is a recommendation that these steps not be done.

OJB, I had the same concern as you, that *not* using suPHP requires one .htaccess format and using suPHP requires another. From the moment the changeover occurs until I notice it's happened, it seems possible my site might throw "500 - Server Error" until I make the .htaccess change manually.

So here's a possible template that should handle both situations, making the transition seamless:

TCH-Dick or TCH-Ryan, does this look correct?

Is mod_suphp.c the correct name of the module to test for?


# .htaccess code for if you want to continue using .htaccess for PHP configuration:

# THIS BLOCK WOULD BE ACTIVE BEFORE THE TRANSITION TO SUPHP
<IfModule !mod_suphp.c>

php_flag display_errors Off

</IfModule>

# THIS BLOCK WOULD BECOME ACTIVE AFTER THE TRANSITION
# IT WRAPS THE CODE IN THE php_config TEST
<IfModule mod_suphp.c>
<IfModule php_config>

php_flag display_errors Off

</IfModule>
</IfModule>

OR

# If when the transition occurs, you want to switch to using php.ini:

# THIS BLOCK WOULD BE ACTIVE BEFORE THE TRANSITION TO SUPHP
<IfModule !mod_suphp.c>

php_flag display_errors Off

</IfModule>

# THIS BLOCK WOULD BECOME ACTIVE AFTER THE TRANSITION
# IT CAUSES PHP.INI TO BE USED INSTEAD OF .HTACCESS
<IfModule mod_suphp.c>

# This tells suPHP where your php.ini file is.
suPHP_ConfigPath /home/USERID/public_html

</IfModule>

# PROHIBIT ANYONE FETCHING YOUR PHP.INI BY WEB
<Files php.ini>
order allow,deny
deny from all
</Files>


Sample public_html/php.ini text file

allow_url_fopen = Off
allow_url_include = Off
display_errors = Off
display_startup_errors = Off
expose_php = Off
register_globals = Off

A remaining issue is that I believe suPHP doesn't tolerate folders with permissions at 777 or files with 666. I don't know what happens if it encounters any. If you have any, I can't think of a way to make that part of the transition seamless (automated), but maybe TCH will automate that, too?

Edited by SteveW, 10 August 2010 - 10:30 AM.


#7 TCH-Ryan

TCH-Ryan

    Immediate Family

  • Members
  • PipPipPipPip
  • 274 posts

Posted 10 August 2010 - 12:54 PM

Our conversion process expects that htaccess files will not already have <IfModule php_config> elements in it, these will be added for existing php_flag/php_value options in htaccess files so adding these in advance will create unforeseen problems, so I would discourage it strongly. Permissions are handled during the conversion process, any files/paths owned by user nobody will be set as the account user and any world writable (777) files/paths will be set to 644/755 as standard.
Kind Regards;
Ryan MacDonald
Data Center Manager | TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com | ryan@totalchoicehosting.com

#8 SteveW

SteveW

    Distant Family

  • Members
  • PipPipPip
  • 129 posts

Posted 11 August 2010 - 12:23 AM

Thanks, Ryan. That's great. I won't make any changes, then.

#9 slawsonb

slawsonb

    New To The Neighborhood

  • Members
  • Pip
  • 21 posts

Posted 14 August 2010 - 01:15 AM

Unfortunately the decision to run the php scripts as me causes osCommerce to display the error:

Warning: I am able to write to the configuration file: /home/twowheel/public_html/includes/configure.php. This is a potential security risk - please set the right user permissions on this file.

This is disturbing my customers. Is it possible to go back to "nobody" or can I create a separate user for running php webapps?

Thanks,
Bruce

#10 TCH-Ryan

TCH-Ryan

    Immediate Family

  • Members
  • PipPipPipPip
  • 274 posts

Posted 14 August 2010 - 01:56 AM

If you go ahead and check the website now you should find that the error is now gone. I have set the configure.php file chmod 444 for you, since your user still does own the file you can at anytime set the file as 644 if you need to edit it, this can be done with most FTP applications without much fuss.

If you require further assistance on this matter, please feel free to open a help desk ticket at https://www.tchhelp.com and we will be glad to assist.

Unfortunately the decision to run the php scripts as me causes osCommerce to display the error:

Warning: I am able to write to the configuration file: /home/twowheel/public_html/includes/configure.php. This is a potential security risk - please set the right user permissions on this file.

This is disturbing my customers. Is it possible to go back to "nobody" or can I create a separate user for running php webapps?

Thanks,
Bruce


Kind Regards;
Ryan MacDonald
Data Center Manager | TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com | ryan@totalchoicehosting.com

#11 slawsonb

slawsonb

    New To The Neighborhood

  • Members
  • Pip
  • 21 posts

Posted 14 August 2010 - 09:46 AM

If you go ahead and check the website now you should find that the error is now gone. I have set the configure.php file chmod 444 for you, since your user still does own the file you can at anytime set the file as 644 if you need to edit it, this can be done with most FTP applications without much fuss.

If you require further assistance on this matter, please feel free to open a help desk ticket at https://www.tchhelp.com and we will be glad to assist.


Thanks. I tried setting permissions to 444 using my Transmit FTP client last night but it wouldn't take. I was assuming it was trying to prevent me from removing all write permissions.

#12 HugoVarotto

HugoVarotto
  • Members
  • 1 posts

Posted 14 August 2010 - 10:55 PM

I'm having issues with Gallery, it used to work great, but now if I try to access it it just gives me a blank page with a big "Error" in it (used to work great up to 2 days ago)

#13 TCH-Thomas

TCH-Thomas

    Volunteer Moderator

  • Members
  • PipPipPipPip
  • 14,908 posts

Posted 15 August 2010 - 03:25 AM

Welcome to the forum, HugoVarotto. :)

Please submit a ticket with the helpdesk and the techs will look into it. Link on top of page and in my signature.

Thomas Jikrantz
Forum Moderator
TotalChoice Hosting, Inc.

Any links or suggestions for third party software/sites should be used at your own risk. My opinions and recommendations are not necessary those of TCH and TCH is not responsible.

As a Forum Moderator I can assist in answering many of your hosting related questions. However, I am unable to answer questions about specifics relating to your account such as billing and server related issues. Should you need assistance in these areas, please contact our Help Desk or our many other options. Another good place to find answers is with our help pages, tutorials and movie tutorials.
Web Hosting by Total Choice Web Hosting - 24/7 Help Desk


#14 TheCanadian

TheCanadian

    Family Friend

  • Members
  • PipPip
  • 64 posts

Posted 15 August 2010 - 11:48 AM

Question... is it possible that before this change, files uploaded/created by scripts running on the server as user "nobody" were not being calculated in the web space quota shown in CPanel and WHM? Because I had one site bloat by 100megs overnight, and I can't find anything on it that has significantly changed since the other day.
- Jeff

#15 TCH-Thomas

TCH-Thomas

    Volunteer Moderator

  • Members
  • PipPipPipPip
  • 14,908 posts

Posted 15 August 2010 - 11:56 AM

Please submit a ticket with the helpdesk about the quota question since the techs don´t visit the forums as often as we mods do. Link on top and in my signature.

Thomas Jikrantz
Forum Moderator
TotalChoice Hosting, Inc.

Any links or suggestions for third party software/sites should be used at your own risk. My opinions and recommendations are not necessary those of TCH and TCH is not responsible.

As a Forum Moderator I can assist in answering many of your hosting related questions. However, I am unable to answer questions about specifics relating to your account such as billing and server related issues. Should you need assistance in these areas, please contact our Help Desk or our many other options. Another good place to find answers is with our help pages, tutorials and movie tutorials.
Web Hosting by Total Choice Web Hosting - 24/7 Help Desk


#16 TCH-Carl

TCH-Carl

    Technical Support

  • Staff
  • PipPipPipPip
  • 1,180 posts

Posted 15 August 2010 - 05:44 PM

Question... is it possible that before this change, files uploaded/created by scripts running on the server as user "nobody" were not being calculated in the web space quota shown in CPanel and WHM? Because I had one site bloat by 100megs overnight, and I can't find anything on it that has significantly changed since the other day.


Yes, files with 'nobody' ownerships were not added to the account quota earlier. On the new setup all files 'should' be under the ownership of the user which would give you the correct disk usage of your account.
Carl Noonan
Techical Support Manager
TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com

TCH Help Desk .. || .. TCH Blog

Posted Image

#17 topdog

topdog
  • Members
  • 2 posts

Posted 18 August 2010 - 05:30 PM

I have several Joomla sites that are not working since this update. The home page works but the additional pages have no formatting or 404 - Component not found.

#18 TheCanadian

TheCanadian

    Family Friend

  • Members
  • PipPip
  • 64 posts

Posted 18 August 2010 - 05:52 PM

Something else I ran into with this upgrade is that the PHP virtual() command no longer works wince PHP is now being run in CGI mode instead of Apache mode. If you were using it to include text, html or PHP files inside your PHP script, try using require() or include() instead. If you were wanting to execute another script (like a Perl script), then you'll have to use passthru().
- Jeff

#19 TCH-Bruce

TCH-Bruce

    Volunteer Moderator

  • Members
  • PipPipPipPip
  • 19,960 posts

Posted 18 August 2010 - 06:14 PM

Thanks for the info Jeff. Topdog, please open a ticket with the help desk. The techs will help you sort it out. Link above or in my signature.

Bruce Richards
Forum Moderator
TotalChoice Hosting, Inc.
Webhosting by Total Choice Web Hosting - General Support Forum

I am a Forum Moderator. While I can assist in answering most of your hosting related questions, I am unable to answer questions about specifics relating to your account such as billing and server related issues. Should you need assistance in these areas, please contact our Help Desk or our many other options. Another good place to find answers is with our help pages, tutorials and movie tutorials.


#20 SteveW

SteveW

    Distant Family

  • Members
  • PipPipPip
  • 129 posts

Posted 18 August 2010 - 09:09 PM

Something from the help desk that might be useful to some people:

If you were previously using this .htaccess line to have PHP code parsed in .html or .htm files:

AddHandler application/x-httpd-php .html .htm
The new line to use is:

AddHandler application/x-httpd-php5 .html .htm


#21 TCH-Bruce

TCH-Bruce

    Volunteer Moderator

  • Members
  • PipPipPipPip
  • 19,960 posts

Posted 19 August 2010 - 06:49 AM

Thanks Steve

Bruce Richards
Forum Moderator
TotalChoice Hosting, Inc.
Webhosting by Total Choice Web Hosting - General Support Forum

I am a Forum Moderator. While I can assist in answering most of your hosting related questions, I am unable to answer questions about specifics relating to your account such as billing and server related issues. Should you need assistance in these areas, please contact our Help Desk or our many other options. Another good place to find answers is with our help pages, tutorials and movie tutorials.


#22 dobratzp

dobratzp
  • Members
  • 4 posts

Posted 24 August 2010 - 07:19 AM

I just posted to the WordPress forum, but this information might be useful here too.

I had setup lines in my .htaccess file to increase the limits on uploads so that I can upload files using the WordPress interface. After the upgrade, these looked like this:

<IfModule php_config>
php_value post_max_size 100M
php_value upload_max_filesize 100M
</IfModule>


Uploads no longer worked and I was logging errors saying that POST Content-Length exceeds the limit of 100 bytes. Of course, by "100M" I was hoping to be able to upload up to 100 Megabytes. After some poking around, it seems like PHP no longer likes the "M" but it does work if you write out the full value, like this:

<IfModule php_config>
php_value post_max_size 110000000
php_value upload_max_filesize 104857600
</IfModule>


Note: While reading up on this, I realized that post_max_size should actually be slightly bigger than upload_max_size.

Oddly, the WordPress interface reports my max upload file size as 100MB regardless of whether I write "100M" or "104857600" (100 * 1024 * 1024). However, the latter fails and reports an error in the user interface while uploading.

#23 DWD

DWD

    Immediate Family

  • Members
  • PipPipPipPip
  • 294 posts

Posted 30 August 2010 - 03:10 AM

And or those of you coming to this thread with Movable Type problems, I just posted the below in the MT forum:

When the upgrade hit my server, my Movable Type blog developed multiple problems namely a lot of "Error 500 Internal server error." The following is what I learned the hard way as to how to fix the problems. Maybe it will save someone the hours I spend figuring it out.

First, you need to change the file permissions on all of your Movable Type files that end in ".cgi" to 755. For me, most of the .cgi files were found in public_html/cgi-bin/mt4 folder and I found one straggler elsewhere.

Second, long...oh, so very long...story short, the MT default, at least for version 4.x, is to assign permission 666 to all files it creates. This causes problems with the new PHP upgrades. Additionally, manually tweaking the permissions will only provide a temporary fix as MT will change the permission back the next time it creates the file.

I was able fix the errors by making MT assign permission 644 to all files it creates. I accomplished this by adding the following at the very end of my mt-config.cgi file:

#==== NEW DEFAULT FILE PERMISSION ==

HTMLPerms 0644

Since making these changes, everything has worked fine.
This support forum is the reason I'm a TCH customer!
www.DanzFamily.com

#24 TCH-Thomas

TCH-Thomas

    Volunteer Moderator

  • Members
  • PipPipPipPip
  • 14,908 posts

Posted 30 August 2010 - 03:13 AM

Thanks for the info, DWD. :)

Thomas Jikrantz
Forum Moderator
TotalChoice Hosting, Inc.

Any links or suggestions for third party software/sites should be used at your own risk. My opinions and recommendations are not necessary those of TCH and TCH is not responsible.

As a Forum Moderator I can assist in answering many of your hosting related questions. However, I am unable to answer questions about specifics relating to your account such as billing and server related issues. Should you need assistance in these areas, please contact our Help Desk or our many other options. Another good place to find answers is with our help pages, tutorials and movie tutorials.
Web Hosting by Total Choice Web Hosting - 24/7 Help Desk


#25 cryptoknight

cryptoknight

    New To The Neighborhood

  • Members
  • Pip
  • 6 posts

Posted 30 August 2010 - 07:26 PM

Was there a memory quota imposed with this upgrade as well?

I've been trying to update my phpffl players list since the update and had nothing but
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 44 bytes) in <hidden>/phpffl/program_files/autorun/myffl/functions/players_functions.php on line 92

Normally I barely use my site... but FFL is starting up, and I need to pull a full update from the roster site (something I do once a year about mid to late august).

This is the first year I've had a problem pulling a 365 day update.

#26 TCH-Carl

TCH-Carl

    Technical Support

  • Staff
  • PipPipPipPip
  • 1,180 posts

Posted 30 August 2010 - 07:45 PM

Please drop in a ticket to the help desk (link on my signature and on the top menu). We will check it out.
Carl Noonan
Techical Support Manager
TotalChoice Hosting, Inc.
http://www.totalchoicehosting.com

TCH Help Desk .. || .. TCH Blog

Posted Image

#27 telcor

telcor

    Family Friend

  • Members
  • PipPip
  • 67 posts

Posted 16 September 2010 - 03:35 PM

The primary change being that we are migrating our PHP Handler setup from DSO to SuPHP for added security


Just wanted to write a big thank you for that :)

#28 kf4zmt

kf4zmt

    Family Friend

  • Members
  • PipPip
  • 53 posts

Posted 17 February 2011 - 08:51 PM

Though we would rather see .htaccess files used to configure PHP, we do fully support the use of php.ini files on suPHP servers.


Why do you prefer the .htaccess method?

#29 TCH-Dick

TCH-Dick

    General Manager

  • Admins
  • PipPipPipPip
  • 5,786 posts

Posted 18 February 2011 - 09:15 PM

Why do you prefer the .htaccess method?


It's not so much a preference as it is a recommendation to prevent issues for the average user. This is because most of the time someone is looking to make a change to a specific script, were as setting a php.ini file can have a broader effect if set for the entire site.

Depending on your needs you may use either, but note that there are caveats in using either method:

- php.ini files are directory dependent, adding a php.ini to public_html will NOT affect directories below public_html. If needed site wide, you must add the proper entry to .htaccess
****using the site wide php.ini method via .htaccess can have an affect on cPanels tools such as the redirect editor. Once you choose this option you would need to edit redirects via the file manager.

- .htaccess php flags do not directly translate to the same strings in php.ini,
for example: htaccess php_value(upload_max_filesize 64M) is not the same as php.ini (upload_max_filesize = 64M)

- .htaccess is limited in what options can be set

- .htaccess files normally have a recursive limit of 2 directories, therefor for entries to affect a script deeper than 2 directories, a new .htaccess file may have to be added to the deeper directory.

Dick DeVance
General Manager
TotalChoice Hosting, Inc
dick@totalchoicehosting.com


Posted Image





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users