Before I describe the issue that I encountered, let me be very clear. This hack is potentially dangerous and should absolutely only be done in development environments. This won't affect your host system, only the docker container so the most damage you'll do is prevent hostname and possibly user/group lookups within the container itself.

Recently I've been playing around with building a pure javascript full text search engine for static content sites like this one. One of the challenges with doing this has been working around the Markdown markup embedded in the written content.

I've been using the PostgreSQL's hstore extension in a Rails application lately and kept encountering the error that is this post's namesake. It would specifically happen when a database had been dropped, recreated and I freshly ran the migrations.

I've found several places where I needed to be able to update my kernels but for one reason or another can't update the kernel that gets booted initially. A couple of these situations were:

• Running Custom or Updated Kernels on DigitalOcean (this is one of their biggest failings IMHO)
• Allowing updating of kernels on embedded linux devices that require their kernel flashed into NVRAM.
• Running an embedded system that used an active/backup partition scheme for updating.

In all cases the process was pretty much the same, though there were some custom changes to the preliminary init system depending on what I needed to get done, especially with the last one which I may cover in a different article.

I regularly find myself working on projects that involve the manipulation and storage of RSA keys. In the past I've never had to worry about identification or presentation of these keys. Normally I've only got one too three pairs at most that I'm manipulating (server, certificate authority, client).