Yosemite and SSL Certificate Verification Failed with cURL

Let's say you're a developer, like myself, and you have just updated to Apple's latest operating system (Yosemite or 10.10) and all of a sudden the Twilio PHP SDK stops working. And, it gives you an error something like this:

SSL: certificate verification failed (result: 5)

The problem disappears when you comment out the CURLOPT_CAINFO option, which makes it a bit more confusing. In other words, you can't use your own CA bundle/file. Others have also noted that it only really happens with certain certificate types, like wild-card domains (e.g., api.twilio.com doesn't work, for example).

Well, it seems to be a bug on the specific version of cURL, version 7.37.1, that Apple has bundled with their operating system. Version 7.37.0 and the latest version of cURL both work fine.

Check this out for all the details: http://sourceforge.net/p/curl/bugs/1404/

I haven't found a good way to fix it yet, myself, but the above link does offer some suggestions.

Fixing InnoDB error "the age of the last checkpoint is..."

I recently switched a production database from MyISAM to InnoDB and I noticed the next day my logwatch email had a bunch of errors like this:

[140617 02:04:22] 140617  2:04:22  InnoDB: ERROR: the age of the last checkpoint is 9433709,
[140617 02:03:40] 140617  2:03:40  InnoDB: ERROR: the age of the last checkpoint is 9433931,
[140617 02:01:58] 140617  2:01:58  InnoDB: ERROR: the age of the last checkpoint is 9433673,

Well, what does all this mean? First, as the comma at the end indicates, logwatch truncated the error message. I found that there is more information in the actual mysql.log file had more info:

InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

So, as it seems, the InnoDB log file settings need to be updated. I found a listing of the steps to take on MySQL's website. Here are those steps fleshed out a little.

1) Make sure your innodb_fast_shutdown settings is not 2. To fix this, set it to one by runnning the following query:

SET GLOBAL innodb_fast_shutdown = 1;

2) Shut down mysql and look for errors in the log to make sure nothing went wrong.

service mysqld stopcat /var/log/mysql.log

3) Copy the old log files to a new place in case something goes wrong.

mv /var/lib/mysql/ib_logfile* ..

4) Next edit your /etc/my.cnf file to increase your InnoDB log size:

innodb_log_file_size = 128M

You may see people suggesting really large values for the log file size -- I saw a value of 768M in one StackOverflow answer. If that seems like a suspiciously large, random value to you (especially considering the default is 5M) then you're on to something. But that begs the question, what should the value be? Here is a helpful article on how to properly size your log files.

5) Lastly, watch your /var/log/mysql.log file and start MySQL back up.

service mysqld start

One helpful tip, if you see this error in your log file,

/usr/libexec/mysqld: Incorrect information in file: './schema_name/table_name.frm'

then you probably tried to skip step 3, like I did. Turns out, this is an important step and your MySQL server may not even start up, without it. It's easy to fix though, either go back and do step 3 or remove your edits made in step 4 and restart mysqld. You should be all set.

Fixing json_encode() Problem in PHP 5.5 on Ubuntu 13.10

I upgraded to Ubuntu 13.10 over the weekend and everything went pretty well. It automatically brings PHP 5.5 with it, too. When I tried to run a web app I was working on, though, I received this message:

Fatal error: Call to undefined function json_encode()

I subsequently Googled around and came across a highly-ranked blog article which makes it sound like PHP 5.5 drops support for json_encode because of some silly licensing argument. The truth is, PHP 5.5 does NOT drop support for json_encode. For a much better and much clearer explanation, I recommend reading this article.

Now, enough of the balleyhoo! How do we fix it?

It was was easy! Install the php5-json package and restart Apache. Voilà!

sudo apt-get install php5-json
sudo /etc/init.d/apache2 restart

Note that the author of the blog article linked above mentions that re-installing the php5-dev pacakged fixed his woes. While that didn't help me, you may want to give it a try if the above didn't help you.

Symmetric-Key Encryption: AES in PHP and what "mode" to choose

Doing some encryption? Want to use the same key for encryption and decryption? Well, I did too. Here are the results of a lot of internet searching.

The 'mcrypt' extension in PHP is the place to go for AES, symmetric-key encryption. AES is safe and secure – the US government has even ok'd 192-bit AES (and up) for top secret documents. You can install it by running yum install php-mcrypt (if you're running Red Hat or CentOS) and then it is available for your coding pleasure.

The next decision is what "mode of operation" to use for your AES encryption. There are a few different ways to do all the fancy math and permutations. Some are more secure than others. You'll notice that when using the mcrypt_encrypt() command, you have to specify the mode as the 4th parameter. You have a choice to make. PHP 5.4 currently has the following modes available (you can find all the options available to your environment by using mcrypt_list_modes):

• cbc
• cfb
• ctr
• ecb
• ncfb
• nofb
• ofb
• stream

If you're in the same boat I'm in – aka "not a cryptographer" boat – then this is just a nice list of letters. But there are a lot of cryptographers who put a lot of good info on the interwebs, thank goodness. I ran across this article on AES usage tips, then there is the overly-neutral Wikipedia article, and a good-enough answer to a similar question on Stack Exchange.

Here are my collected thoughts on the matter:

1. One glaring thing I came away with from all these sources is this: DON'T USE ECB. 
2. The second thing I came away with is this: CTR would be the ideal, if it was available. This is because it does some authentication to make sure the encrypted message really is an encrypted message and not some sort of cryptographic trojan horse. (The simple solution to this is to make sure you HMAC hash your encrypted text to make sure it isn't tampered with.)
3. The last thing I came away with is: Use OFB or CFB because they are pretty darn good and available in mycrpt.

Other thoughts? Do you know of even better articles on modes of encryption? I'm all ears!

Checking the last SQL statements used by PHPActiveRecord

I'm using PHP-ActiveRecord on a project and am loving it. But there are some things to learn and as a guy coming from the write-your-own-sql world, I do occasionally want to check what SQL queries that ActiveRecord is sending out there. I've used this bit of a code a few times to do so and it is immensely helpful for me as I try to see if I'm using this package correctly:

echo Model::table()->last_sql;

Pop that in after you do your Model::find() or Model->save() or whatever, just be sure to swap 'Model' out with your model's actual name.

Error starting Apache (httpd) - Configuration files not readable

Here is an interesting issue I ran into today while setting up a new VM. I had copied the Apache conf file and SSL/TLS certificate files onto my new server as root using wget. All of the file's ownerships and permissions looked right and I thought I was ready to go. Then I ran into these two misleading errors:

Could not open configuration file /etc/httpd/conf.d/ssl.conf: Permission denied

and

SSLCertificateFile: file '/etc/pki/tls/certs/mydomain.com.crt' does not exist or is empty

Contrary to what Apache reported, the ssl.conf file did have the correct permissions and the crt file did exist and had contents. So what gives? Our trusty SELinux friend is at it again, it seems. Because I had copied these files in from somewhere else, SELinux was detecting something off. It is an easy fix, though. Just run this command, specifing each of the files above:

restorecon -v /etc/httpd/conf.d/ssl.conf

and

restorecon -Rv /etc/pki/tls/certs/

That -R is for "recursive" and it means I want it to do the whole directory.

After fixing up the SELinux permissions for these files I brought in, everything started up just fine!

Using SQLite for Unit Testing in PHP

Unit testing is infamous when one attempts to test database-interacting classes. I noted that some had suggested using SQLite when running phpunit to test these sorts of classes. Been working for me, so I thought I'd jot it down here.

First, make sure sqlite3 is installed. On Ubuntu you'd run the following at the command prompt (assuming this step is necessary, but now I'm not quite sure):

sudo apt-get install sqlite3 libsqlite3-dev

Next, make sure PHP support for sqlite3 is installed enter this at the command prompt:

sudo apt-get install php5-sqlite

And then, in the part of your PHP script where you set up PDO (if that's the class you use, as I do), you can specify sqlite's in-memory DB:

$conn = new PDO('sqlite::memory');