Docker works, docker-compose fails

I ran into a funny issue yesterday. I was attempting to resurrect an old project (made with fig) using fig’s successor project, docker-compose. For reasons that will make sense in a minute, it’s worth noting that I’m on a mac, and all of the software under discussion was installed with homebrew. Running docker on a mac, means I’m also using boot2docker.

Plain old docker works fine:

$ docker run -it debian:latest bash
Unable to find image 'debian:latest' locally
latest: Pulling from debian
39bb80489af7: Pull complete 
df2a0347c9d0: Already exists 
debian:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:a25306f3850e1bd44541976aa7b5fd0a29beabc137f65acbac34d6918807fd6e
Status: Downloaded newer image for debian:latest

docker-compose, fails hard:

$ docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

A certificate problem doesn’t make any sense– docker depends on the same certificate files.

Google produced a number of false leads, but I landed on a discussion thread on Github that suggested that there is something broken about OpenSSL 1.0.2.

The comment I linked to above, suggests that I can use Homebrew to switch back to OpenSSL 1.0.1.

brew switch openssl 1.0.1j_1

But,  that presumes that I had the version in question installed at some point. Homebrew doesn’t actually delete old versions until you tell it to, so you can always use ‘brew switch’ to restore a previously installed version.

How do you install an old version, though? Homebrew doesn’t make this obvious at all. To do that, you need to locate the relevant “recipe”  file in the homebrew git repository, and identify the moment in time (in the form of a commit hash) when the software  version you want was current.

Here is the file in question. It seems like the right commit to use is ‘b5cffc8d5fc41540a41ed4deba23afbb6431435e’.

Now what? You have to roll your entire homebrew install down to that commit. In my case, homebrew was installed in /usr/local/homebrew.

$ cd /usr/local/homebrew/
$ git checkout b5cffc8d5fc41540a41ed4deba23afbb6431435e
Note: checking out 'b5cffc8d5fc41540a41ed4deba23afbb6431435e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at b5cffc8... openssl: update 1.0.1l bottle.

Then, you can ‘brew install openssl’, and you’ll get the correct version. After that, docker-compose will work.

$ docker-compose up
Creating solr_1...
Building solr...

RHEL Notes II: The least asinine way to get Docker on RHEL Workstation?

In the previous dispatch, I whined about Docker not being easily installable on RHEL Workstation. I also spent some time explaining the relationship between Fedora and RHEL.

The solution to my Docker problem comes from another interesting part of the Red Hat ecosystem: ‘rebuild’ distributions.

Just because Red Hat charges a bunch of money for RHEL licenses, it doesn’t stop being Free Software. All of the source code that makes up RHEL is available online. What stops anyone from using that code to compile and sell copies of RHEL? The surprising answer is “trademarks”. You are free to distribute an operating system built from the RHEL source code. You just can’t call it “Red Hat” or “RHEL”, or include any of their other trademarks.

So, several projects have sprung up to do that, most notably Scientific Linux and CentOS. These projects produce operating systems that are functionally identical to RHEL, but are available without licenses and subscriptions. One handy side effect of this, is that a package built for RHEL will work on these derivatives, and likewise, a package built for any of the RHEL-alikes will work just fine on RHEL.

Back to Docker. The CentOS folks have included Docker in their “extras” repository. I created a .repo file (stored in /etc/yum.repos.d) that instructs my system to include CentOS Extras when it searches for software.

name=CentOS-7 - Extras
includepkgs=docker* golang*

Then, it’s a simple matter of:

yum install docker docker-selinux

# if you want to run docker using a non-root account:
groupadd docker
usermod -a -G docker <account name>

# if you're logged into that account, log out and back in a again for the group change to become effective

Then you can docker all damn day.

Running Jenkins in Docker


updated 5/14 to include docker-selinux in the install instructions

RHEL Notes

One perk of being an RIT student, is that I can take advantage of the school’s site-license for Red Hat Enterprise Linux (you need an RIT computer account to click that link). I decided to give it a try.

Until this weekend, I had been using Fedora on my personal laptop. The relationship between Fedora and RHEL is pretty interesting. Fedora moves quickly, aiming for a new release every six months. Every two years or so, Red Hat takes a snapshot of the current Fedora, does a bunch of customization, quality assurance, and release engineering, and eventually mints the resulting operating system as a new RHEL release (with a price tag, and a 10 year support commitment).

For example, the current version of RHEL (7) is based on Fedora 19.

Are there reasons for an individual user to pick RHEL instead Fedora (Or Debian, Ubuntu, Arch, Suse, Elementary, or dozens of other completely free Linux distributions)?

I guess that’s what I want to figure out. I switched from Debian to Fedora because we had standardized on RHEL for our servers at work, and I was interested in pursuing Red Hat’s certification track. It made sense to use a Red Hat-like OS. By that logic, it’s hard to beat actually using RHEL.

That’s a pretty specific use case, though. The things I do on my personal laptop are mostly:

  • Use the web
  • Email
  • Light usage of a word processor and spreadsheet
  • Code (Mostly web apps, mostly Python)
  • Tinker and learn with the system itself, and available software.

So far, that last point seems the most impacted.

What do you mean I can’t run Docker?

Oh, I’m sure it’ll run, If I download and compile it myself– but Docker is nowhere to be found in the official repositories for RHEL Workstation or EPEL. It’s apparently only officially supported on RHEL Server.  I’m not that interested in “officially supported” anyways, so I’ll look for a more sustainable installation route before I go down the “make install” path.

This leaves a bad taste in my mouth, like running into a piece of Microsoft software in the 90’s or 2000’s that could only be installed on Windows Server, based entirely on licensing restrictions, not real technical limitations. Does Microsoft even still do that?

One thought I’ve had: is there any functional difference between using RHEL Workstation, and using RHEL Server with the desktop packages installed? Maybe I should just start over with a Server install (which is also available via the RIT license).

Déjà Dup

Over in Fedora-land, I had been using Déjà Dup to keep my files backed up to Amazon S3. Could I restore my backups on RHEL?

Pretty much. Deja is basically a more usable wrapper around duplicity, which is available in the RHEL repos. Deja Dup itself, not so much. It is technically possible to use just duplicity, but I’m too lazy for that– so I downloaded the Deja Dup source code, compiled and installed it. It did a fine job restoring my backups, and is now set to continue my daily backups in RHEL.


I like to have both Chrome and Firefox around. I generally use Firefox, but switch to Chrome when I want to use Flash, or some Google app that runs better in Chrome (Like Google Music).

Getting Chrome installed was no big deal. There are some un-advertised prerequisites, but the instructions on this post got me up and running without much fuss.


I have what (I think) is the first generation of the Dell XPS 13. There’s just nothing interesting to say here. Wifi, keyboard backlighting, volume and brightness keys– it all just works.

There’s one bit of weirdness with the trackpad– the bottom left corner doesn’t register as a left click, or really a click at all. It seems almost like it’s been reserved for some other purpose.


That corner is precisely where I do most of my “left” clicking. I’d really like to figure out how to make it work like it used to.

Android apps on Chrome

Item: Android developers can now package their apps into a form that will run on Google Chrome (including, and perhaps especially, Chromebooks).

Item: Google has been working to make Chrome apps behave more and more like traditional software on Chromebooks, Windows, and Mac.

Putting it together, the App ecosystem available to Chromebook users is potentially much larger, and the Android toolchain looks less like a kit for developing phone and tablet apps, and more like something akin to Adobe Air or Java– a portable app runtime.

The biggest weakness would seem to be that there are separate stores for Android and Chrome apps. I wonder how much longer that will be the case?