Red Hat’s OpenShift Data Foundation (formerly “OpenShift Container Storage”, or “OCS”) allows you to either (a) automatically set up a Ceph cluster as an application running on your OpenShift cluster, or (b) connect your OpenShift cluster to an externally managed Ceph cluster. While setting up Ceph as an OpenShift application is a relatively polished experienced, connecting to an external cluster still has some rough edges.

NB I am not a Ceph expert. If you read this and think I’ve made a mistake with respect to permissions or anything else, please feel free to leave a comment and I will update the article as necessary. In particular, I think it may be possible to further restrict the mgr permissions shown in this article and I’m interested in feedback on that topic.

I find myself working with Raspbian disk images fairly often. A typical workflow is:

• Download the disk image.
• Mount the filesystem somewhere to check something.
• Make some changes or install packages just to check something else.
• Crap I’ve made changes.

…at which point I need to fetch a new copy of the image next time I want to start fresh.

Sure, I could just make a copy of the image and work from there, but what fun is that? This seemed like a perfect opportunity to learn more about the device mapper and in particular how the snapshot target works.

Occasionally we will deploy a virtual instance into our KVM infrastructure and realize after the fact that we need more local disk space available. This is the process we use to expand the disk image. This process assumes the following:

• You’re using legacy disk partitions. The process for LVM is similar and I will describe that in another post (it’s generally identical except for an additional pvresize thrown in and lvextend in place of resize2fs).
• The partition you need to resize is the last partition on the disk.

This process will work with either a qcow2 or raw disk image. For raw images you can also run fdisk on the host, potentially saving yourself a reboot, but that’s less convenient for qcow2 format images.

This articles describes how I got CrashPlan running on my FreeBSD 8(-STABLE) system. These instructions by Kim Scarborough were my starting point, but as these were for FreeBSD 7 there were some additional steps necessary to get things working.

Install Java

I had originally thought that it might be possible to run the CrashPlan client “natively” under FreeBSD. CrashPlan is a Java application, so this seemed like a possible solution. Unfortunately, Java under FreeBSD 8 seems to be a lost cause. I finally gave up and just installed Java under Linux.