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.

CivClicker Type Availability User Script

Awhile ago I wrote about how I’d gotten addicted to the Cookie Clicker game to the point that I made a userscript that would display a countdown showing how long it would take for me to get to a certain amount of cookies.

The same people that pullled me into that game tried to get me into a new one, CivClicker.  I think I’ve managed to avoid getting pulled in too far but not before noticing an issue and writing a user script to handle it, which I figured I’d share.

In the game there are several classes of job you can assign your people to.  Six of them require there be enough space in a class of building to hold them.  Ten soldiers for each barracks built, for example.  The problem is that nothing shows how much space you have available, so you might intend to assign a bunch of soldiers only to be unable to and not realize why.  My script provides that information.

As with the Cookie Clicker one, this user script is available on GitHub.  I’ll break it down here, though.

One caveat: There are classes that require not only space in buildings but other resources be available to assign people to them.  I didn’t take that into consideration, this is just about space.

Just like the Cookie Clicker script, we start with some basic stuff. On page load we run exec() which accepts a function and is defined below.

In CivClicker there is a table of all of the job types. Each row has an ID matching the naming convention of <type>group. We create an array of the six types we care about, then we loop through the table rows. On the ones that match a name we’re looking for, we add a span to the sixth field (the one that shows how many you already have of that particular type). Through some string manipulation, we give that span the ID of <type>Available so we can reference it later.

We set the update_availability() function to run every second.  This means there can be some lag but I didn’t think this needed to run more often.

We see that update_availability() is what actually finds the number of each class that you can have, then subtracts what you already have and displays that in the spans we established earlier.  I’d like to be able to get this down a little bit, we should be able to loop through each class, but since the game itself doesn’t have a list of all the classes available I didn’t bother to expand on that either.  The prettify() function is from the game, however, as I figured I should display numbers the same way they do.

Last we wrap things up and define the exec() function, which allows us to do this all via script injection, giving access to the game-defined variables.

It’s hardly revolutionary but is another thing I wanted to throw out there.  For the record, your screen ends up looking like this (when you have the font size turned down):