Jump to content

Php Upgrades


TCH-Dick

Recommended Posts

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 container element.

    Example:

    php_value register_globals 0

 

 

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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().

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
  • 5 months later...

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.

Link to comment
Share on other sites

×
×
  • Create New...