Guzzle Bug 568 and Shared Hosting

I ran across an interesting little problem this weekend and figured I’d share out what I discovered.  In hindsight, I think it’s something I should have figured out pretty quickly but I didn’t see anything about it in my searches so maybe this will help someone.

I use AWSSDKforPHP2 installed as a PEAR extension on three sites running on the same server.  One of those sites is a development environment for another.  Yes, I know I probably shouldn’t have a dev and live site on the same machine but, whatever, right now I do.

The AWS SDK was updated last week so I took a look at the feature set and decided I would install the update.  Updating had never actually broken any of my functionality before so I didn’t see it being a big deal.

I ran the install on the aforementioned dev site so I could confirm nothing would break and during the install process I saw that Guzzle, on which the SDK is dependent, also updated.

After the install, everywhere that uses the SDK is throwing a Guzzle error about an MD5 mismatch for /tmp/guzzle-cacert.pem.  A search revealed Guzzle issue 568, where the Guzzle temporary CA file doesn’t get updated on upgrade, so the MD5 comparison fails.  The fix is to manually remove the temporary file, which will then get re-created correctly.

This is where I should have noticed it would cause a problem in my shared environment but I went forward anyway.

I deleted the temporary file, then re-ran the script that I was using for testing.  The error persisted.  Confused, I checked the /tmp/ folder and saw that, yes, guzzle-cacert.pem had been recreated.

This is the second place I should have realized there was an issue.

I  deleted the temporary file again and re-ran my test script.  This time it worked, at which point everything fell into place to me.  I ran out to my live site and confirmed, yes, it was broken, then jumped back to my dev site, completed my test, and quickly upgraded the live site.

I install the AWS SDK (including Guzzle) on a site-by-site basis so I can test changes.  What should have been obvious from the start is that even if each site has its own installation, there’s only one temporary CA for the server, meaning as long as that check is happening, you can only have one version of Guzzle working on the server.

When I deleted the temporary file the first time, the live site ran before I ran my test on dev, so the old CA was recreated.  When I did it the second time I managed to run my test before anything on live went.  This got me the new temp CA but now when live failed the MD5 check.

In the end, stupid mistake on my part, but enough of a gotcha that I figured I’d throw it out there.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.