PHP 5.4, PHP 5.5, and Apache 2.4

We are finally officially announcing that PHP 5.4 and PHP 5.5 are available to all members. In the past, we have offered “Fast” and “Flex” versions of PHP for people with different needs. That’s no longer the case for PHP 5.4 and beyond; we have developed and deployed new technology that is both faster and more flexible, all in one. This is a big deal for us; with this step, we’ve gone from being behind the curve on PHP to — I feel — ahead of it, and we’re well-positioned to stay there.

We’ve also rolled out Apache 2.4 for these new server types, and we have some config advice for those looking to make the switch.

PHP 5.4 and 5.5

The most important change with this upgrade is that PHP 5.4 and 5.5 do not use safe_mode or open_basedir. Although we’re sure most people will view this as a huge advancement, we view it as good and bad. (Mostly good though.)

First, the good. Nobody’s going to weep for open_basedir. Our dependency on it has historically caused terrible disk I/O performance for us and rendered large applications with thousands of small files (Zend framework, I’m looking at you) nearly unusable on our service. We’ve replaced this with a much more efficient system developed internally and adapted from our CGI and ssh environments, called NFGI. That also means PHP scripts under 5.4 and 5.5 will use the same paths as the ssh environment, which definitely makes life easier when interacting with web applications from the command line.

On the other hand, we’re going to miss safe_mode, although we might be alone on that. It is massively unpopular, because it makes it difficult to set up PHP applications that read and write files. If you don’t set file permissions and ownership with exacting precision, you will “enjoy” obscure error messages that point to everything but the actual problem. Although this is very good for site security when set up properly, it’s also supremely annoying to people who haven’t invested significant time in understand exactly what’s going on and why in every last detail.

Unlike open_basedir, safe_mode isn’t being replaced with anything; it’s just going away. The PHP developers didn’t like maintaining it any better than most people liked living with it, and so they cut it loose. We prize security, so that’s not a tradeoff we would have made, but we understand why they did it even if we don’t agree. (Actually, our rather strong feelings on this subject have been vented expressed on our forum in the past and won’t be repeated here.)

Unfortunately that does mean that just as it will be easier to set up applications to read and write files, it will be easier for hackers to exploit sites that make even small mistakes in setting their permissions and ownership. As a result, it’s more important than ever to resist the urge to allow your site to update itself over the web. Since this comes up most frequently with respect to WordPress, PHP 5.4 and beyond support the fantastic wp-cli tool by default to help with that. (Just run “wp” from the ssh command line after switching to 5.4 to learn more.)

Since there’s not much else we can do in the name of prevention at the current time, we’ve added a pound of cure. We’ve improved our backup methodology to make it much more likely that if some exploiter does manage to slip through a bug in an outdated WordPress theme or similar, and trashes your site files — or even if you just accidentally delete something — it’ll be much more likely that we’ll be able to help.

These changes also mean that PHP 5.4 and 5.5 have features that have never before been available on our service, or have been limited to the ultra-slow Flex type. For example, executing external programs like ImageMagick from within PHP is now fully supported. Our PHP 5.5 server type also has experimental support for 5.5’s built-in opcache, which can accelerate frequently-hit pages considerably under some circumstances.

The PHP per-request memory_limit is also gone, in lieu of a much larger per-site limit. This provides much more flexibility to work with large images or load more plugins. And we did all that while making PHP actually take up considerably less memory, leaving the rest for you. (Yes, sometimes we even amaze ourselves!)

Both PHP 5.4 and 5.5 also use a new configuration method. Rather than pasting PHP-related configuration directives into .htaccess files, instead you can create a /home/conf/php.ini file that will be parsed after (not instead of) the main php.ini file. You can put your custom settings there.

Q. Does this php.ini customization mean I can even build, load and use custom PHP extensions that NearlyFreeSpeech doesn’t officially support, like PECL modules?

A. Yes, imaginary reader, it totally does.

So the new PHP 5.4 and 5.5 options are faster, more efficient, more flexible and have more features than ever before. We’re very excited about it, and not just because this represents the public emergence of two years of secret internal development on a security model that both performs well and offers all this flexibility. (And that is extendible to other languages, but that’s a subject for another blog post.)

PHP 5.4 is stable and fully supported for both stochastic and legacy billing options. It will become the default for new sites around November 1st. At that time, we will phase out our remaining support for PHP 5.2, which is well past its end-of-life. Sites will be migrated from 5.2 to 5.3 in November, although if you prefer to control that yourself at a time of your choosing, you can do it anytime between now and then. We will also phase out the ability to create new Flex sites or change existing sites to the old Flex types at the same time. (We hateses the Flex, don’t we precious? We hateses it!) But, we will continue to support existing Flex sites as long as we can, and we expect that to be a long time.

PHP 5.5 remains in beta for the time being as we kick around the opcode cache and some other new things, and is offered only on a stochastic model with resource charges waived during the beta, which makes it a great deal if you have a non-production site and don’t mind being experimented on!

Support for 5.3 will continue as long as the PHP developers continue producing security patches for it. (We don’t want to end up in another 5.2 situation where we do that ourselves for years after official support ends.)

To take advantage of PHP 5.4 or 5.5, create a new site — you’ll now be prompted for what kind of site you want — or go to the site details panel in our UI for an existing site and pick the “Change Server Type” action in the Actions box.

A note about Apache 2.4

While most of our service still uses Apache 2.2, the PHP 5.4 and 5.5 server types are the first to roll out Apache 2.4. This upgrade is mainly transparent, but we have found one compatibility issue worth mentioning so far.

If your .htaccess files use the “Order” directive, they won’t work with Apache 2.4. It handles authentication and authorization using a new framework. It’s very easy to adapt .htaccess files to the new format, but it has to be done by hand or you will get the dread “Internal Server Error” after switching your site. The official Apache documentation has a very concise and easy-to-follow summary of what needs to be changed when you make the switch.

Update: PHP 5.2 and the antique (pre-4.1) MySQL password format

As we have started migrating sites from PHP 5.2 to 5.3, we have learned that a handful of people with really, really old MySQL processes who haven’t updated their MySQL passwords in the past 10 years or so may see the following error (or similar) on their site after the upgrade:

mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‘your_existing_password’). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file

(Emphasis added.) If you have any current passwords, you may be able to issue the suggested command to update the password through phpMyAdmin, but the recommended approach is to use the ssh command line. Please also consider changing the password while updating it, since it’s been awhile. 🙂

5 Comments

RSS feed for comments on this post.

1. […] is not all. If you read our PHP-related blog post, you may have noticed us practically cackling over a brand new layer of secret sauce called NFGI […]

   Pingback by NearlyFreeSpeech.NET Blog » CGI/ssh Upgrades — September 21, 2013 #

2. Though I understand your reasons for missing it, I shall be doing a traditional jig on top of its grave.

   Thanks a ton for all of your hard work! <3

   I think that gravetop is going to get pretty crowded. -jdw

   Comment by Kat — September 21, 2013 #

3. And by “it,” I meant safe_mode. I… felt that needed clarifying.

   Comment by Kat — September 21, 2013 #

4. Please will you also update the wiki, faq and forums to no longer explain all the work arounds for safe_mode?

   Comment by Rob — September 22, 2013 #

5. PHP 5.3 is still the default for new sites, and will remain available for some time yet. Removing correct, useful information is not something we would do, and even without safe_mode much of the advice given for working within it remains good security advice.

   We will update the FAQ with information about PHP 5.4 and beyond as it becomes appropriate (in fact we have already started to do so). We do not attempt to revise the past on the forum, as that is both creepy and impractical. The wiki is member-maintained unless we find a factual error.

   Comment by jdw — September 22, 2013 #

Sorry, the comment form is closed at this time.