Recently, when upgrading the Docker base image for a Ruby on Rails app, the app suddenly started raising SSL error: certificate verify failed exceptions when attempting to connect to Postgres. Unfortunately, the error message doesn’t describe why verification failed.
The base image was being upgraded from Debian 9 (Stretch) to Debian 10 (Buster). The Postgres 11 instance (which started life on 9.x, so it’s older) is hosted by AWS RDS and configured to require TLS connections.
It turns out that AWS RDS only supports TLS 1.0. However, Debian 10’s openssl config defaults to requiring TLS 1.2+. The result is the certificate verification error above.
The quick fix is to modify /etc/ssl/openssl.cnf (as this is what changed between Debian 9 and 10) to allow TLS 1.0. Near the bottom of the file, change
Rails 6.0 adds support for multi-environment credentials. Here’s a quick summary of how it works:
By default, behavior is the same as Rails 5.2. To configure credentials for another enviornment, just add --environment <env>.
rails credentials:show [--environment <env>]
rails credentials:edit [--environment <env>]
Example: rails credentials:edit --environment production
(Hint: RAILS_ENV=<env> rails credentials:show won’t work. --environment must be used instead.)
How Rails behaves
Rails continues to use the 5.2-compatible files (config/master.key & config/credentials.yml.enc) in the absence of an environment-specific file.
If an environment-specific file is available, then that is used instead (and the default file is ignored – they are not merged). This is convenient when you want multiple environments, eg: development and test, to both use the same file. In this example, use the default file for those two environments, and then provide an environment-specific file for production only.
For reference, Rails will look in the following places for the master key for decryption:
And it will look for the actual encrypted credentials at these locations:
I recently started a new Rails 5.1 project. I wanted to try out webpacker, which is now at version 3. Turns out, the webpacker team has been working hard to simplify things and they’ve accomplished quite a bit. Most posts online talk about v1 or v2, and they include a lot more steps than are now necessary.
On a recent project, I had need again to use GeoIP (by the lovely people at MaxMind). I decided to take some time to benchmark a handful of various GeoIP gems, both for GeoIP v1 (legacy) and the newer GeoIP v2.
I decided to benchmark the extraction of 3 pieces of data, using the GeoIP Lite City database: