PHP 5.3.10 and Apache 2.2.22 upgrade

[tmaher]

Motivated by some traffic on security@

• Apache from 2.2.19 to 2.2.22
• PHP from 5.3.6 to 5.3.10
• fixed APC (it was built but not enabled)
• added mcrypt module at compile-time
• Cut "hello world" slug size from 22MB to 9.5MB (stripped debugging symbols; removed apache docs)
• Stopped using per-app buildpack CACHE_DIR; should significantly reduce storage overhead
• switched display_errors from On to Off

The last one is the only thing that I anticipate actually impacting the experience of PHP developers. In the current buildpack, display_errors is On. All errors are sent to stdout (read: the user's
browser). With display_errors Off, they only go into the system. This is normal production practice.

The build artifacts are already in place in the php-lp bucket. If you want to see an example of the new buildpack in action, check out

old: http://php-default-bp.herokuapp.com/
new: http://php-tmaher-bp.herokuapp.com/

[tmaher]

Per conversation with @pedro , I cloned the FB PHP template app and tested it on my buildpack. It works fine - https://high-cloud-2320.herokuapp.com/

I'm now merging the pull request myself. I'll re-test with a new app once it's live to make sure I haven't broken FB provisioning.

[winglian]

@pedro Why was this merged in? It doesn't show the steps to recreate the binary so doesn't allow anyone who forks from this point to build a working binary. Also why was support for the cache removed?

[tmaher]

@winglian - This was merged in to upgrade to PHP 5.3.10 and Apache 2.2.22, as well as flip the PHP config display_errors to off (general security best practice and minimizes error spew on the page being displayed).

For the build instructions - #3 (comment) but the conversation might be better tracked in #6 as part of the move to Vulcan

For the cache: It's a little tricky. Buildpack caches are intended to create app-specific persistent artifacts from build to build, and those artifacts for whatever reason don't belong in the git repo itself. For Ruby, you'd use this to have the build system pull in various Ruby gems the app uses and (if necessary) compile shared libraries. For PHP, an obvious use would be to pull in pear/pecl dependencies and stash them there. However, that wasn't how this buildpack was actually using it. Instead, what happened was that the build system was copying the PHP & Apache binaries from the S3 bucket and copying them into the cache, ostensibly to save itself the work from re-downloading them again out of S3. However, in between builds, the cache itself is archived into S3, and then fetched back to the build system. So, there was no actual efficiency improvement, and in fact it winds up creating a bunch of useless copies of the PHP & Apache binaries.

Now, it'd certainly make sense to add some sort of automatic pear/pecl extension fetching system (similar to Ruby's builder), and that'd totally make sense to use the cache. I think we'd welcome a pull request of that nature.