In my last entry, I mentioned that the United States Department of Defense had requested Defense Distributed remove the plans for their 3D printed firearm from the internet.  I also mentioned that I believed this was Defense Distributed getting the legal fight it had been spoiling for.

Eating my Words

However, I believe I have to eat my words.  It has now been more than a month since the USDoD requested the plans be removed form the internet and there has been no response (other than compliance) from Defense Distributed.  In my mind, this is indicative of Defense Distributed scrambling to find a response or believing they have achieved their goal.  If Defense Distributed had anticipated that they would be targeted using export laws, I believe they would have already responded.

My basis for analyzing Defense Distributed’s actions is a lawyer friend of mine.  I have seen him repeatedly take on laws he doesn’t like, believes are unjust or poorly written.  His typical …

Edit: Just before the publication of this article, Defense Distributed voluntarily removed the designs for the Liberator from their website, at the request of the Department of Defense.  In my opinion, this is Defense Distributed getting the legal fight with the government it was spoiling for.  More on that to follow.

Hello again world.  How are you today?  It’s been a while since I last posted, mostly due to school.  Good news is that I had an awesome semester and worked on some very cool projects.  A little polishing, and I’ll happily show them off here.

One of the things I’ve been very intimately involved with this semester is 3D printing.  Consequently, I have some thoughts to share on Defense Distributed, which is aiming to make a 3D printed firearm.  More specifically, I have thoughts on their 3D printed firearm and how much it does - and doesn’t - change the security playing field.  I also have a few thoughts on the attitude and approach of Defense …

So.  My laptop primarily runs linux.  However, I’ve got a few reasons to run Windows - gaming being one of them, watching streaming SilverLight video (choughnetflixcough) another.  Rebooting a machine every time I want to switch operating systems is rather a drag.  However, for some things (gaming), I’ll want to be doing this anyway.  So I figured out how to make Windows both bare-metal boot and VM boot.  I make no guarantees about any sort of performance.

As a side note, I’ll probably also play with enabling the Optimus video card on my laptop for the VM.  Letting the video-intensive VM have basically a video card all to itself ought to help performance….

Anyway, on to the setup.

My Setup/Things you Need

• VirtualBox
• Windows 8
• Windows Install DVD/DVD Image

Procedure

Prerequisite: Bare-Metal Dual-Boot

As it says.  I’m assuming here that your machine is already set up and properly dual booting.

Give Your User Raw Disk Access

Linux really doesn’t like …

I run a little server on my apartment network for small services (an IRC bouncer, some screens, SSH and MD-Raid).  However, I’m not always at the machine when I’m working on it.  I have, in the past, been lucky and not taken it totally offline when doing upgrades remotely.  Until this week.

Having now accidentally removed myself from all the services I usually use, I’m frustrated.  In my work life, I often use servers which have Baseboard Management Controllers (BMC).  The BMC is a device which sits on the motherboard of a machine and is able to do many things - report on sensors, whether the machine is powered or not, change the power status and connect a serial console.  A properly configured BMC makes it possible to do pretty much anything to a machine remotely, save for adjusting the hardware.  In my current conundrum (a kernel which won’t boot), this would be immensely helpful - I could use the serial console to select an older, working kernel and then fix …

Earlier this evening, I was playing with Android emulators.  Specifically, I was playing with emulating an application which uses libGL.  On emulator boot, I was getting messages like:

libGL.so: cannot open shared object file: No such file or directory

It turns out that though no version of the binary is included in the default ADK, the correct one can simply be linked in.  On my Debian Wheezy/testing machine, this was done as:

$ ln -s /usr/lib/x86_64-linux-gnu/libGL.so.1 ~/android-sdk-linux/tools/lib/libGL.so

Which also has the advantage that it requires no privileges.

If you need to find the .proper libGL.so file, consider using:

$ find / -name libGL.so* 2>/dev/null

OpenAFS is the open source version of the AFS - a file system developed at Carnegie-Mellon University.  AFS has a global, DNS-based address space.  It also has a ton of nice features with respect to allowing users to create and control their own groups and much more granular permissions.  All in all it seems to be a good way to get data into a cluster and to allow users to store and manage documents in a reliable format.

Building OpenAFS

I’ve saved building OpenAFS for last because it is somewhat more complicated than the other RPM builds we’ve done so far, primarily due to some messiness with kernel versions.  Spcifically, the kernel interfaces that OpenAFS-1.6.1 (the current Linux release) were changed from the 2.6 to the 3.x branch.  OpenAFS has sources that are patched for this, but hasn’t released them yet.

Getting Source

So, to get the proper source, we’re going to have to get them from git.

$ git clone git://git.openafs.org/openafs.git

We then want to …

ZFS is one of those pieces of software that is almost frighteningly good at what it does.  It has a whole slew of features that make it, for many uses, the perfect filesystem.  These include: deduplication, compression, data integrity guarantees (ZFS can detect and repair silent data corruption), copy-on-write architecture and a built in concept of RAID.  The only problem is that the source is under a license incompatible with the linux kernel, so it will never be kernel mainline.  There is, however, the ZFS on linux project, which makes it easy to bring ZFS to several linux distributions.

Building ZFS

Download the SPL and ZFS packages from the ZFS on Linux homepage.

Building SPL

The main ZFS package requires that parts of SPL (the Solaris portability layer) be installed before ZFS can be installed.  So lets start by untaring SPL.  At the time of writing, the most recent version is 0.6.0-rc12:

$ tar xf spl-0.6.0-rc12.tar.gz

Now, lets build the RPMs:

$ cd spl-0.6.0-rc12
$ ./configure
$ …

Ceph is a distributed storage engine.  It can be used in a whole number of different ways - for example, as a block device or an object store.  The current version is codenamed argonaut, hence the header image.

In the ACM cluster, we’re using it as the storage engine for VMs.  This makes a lot of sense in our case, as the VMs are going to want to move from machine to machine and this stops them having to copy the disk image.  Ceph also has the advantage of being kernel-mainline, meaning that all the required bits for it are already built into the kernel and building it does not require patching the kernel at all.

Building RPMs

Building the Ceph RPMs is very similar to the other RPM builds we’ve already done.  Ceph is extraordinarily kind and provides their own (working!) spec file.  So first off, download the Ceph tar.bz2 from here.  Assuming you’re using the same ceph 0.48-argonaut version I am, you’ll then want to run

$  tar xvf ceph-0.48argonaut.tar.bz2 …

Welcome back to my ongoing series on building the JHUACM VM cluster.  In this part, I’m going to be focusing on building the RPM driver for the Myricom fiber cards that were given to us with the cluster.  Unfortunately the drivers for this are closed source.  However, through my connections to physics, I was able to get source code to build from.  In short, if you’re here looking for drivers, you’re out of luck - go talk to Myricom.

The specific hardware we have is driven by the mx2g driver, so that is what I’ll be working on.

Down the Rabbit Hole

The first thing I did when I got the tarball of the driver source was try to build the rpm.  The normal RPM build process is to copy the source tarball and a spec file into rpmbuild.  With these, it was some convoluted, undocumented and inflexible process.  In short, the process was to run “make rpm”, copy a magic folder somewhere magical, and then run rpmbuild against the spec file.  This also deliberately …

Next up,  lets build RPMs of Xen, a hypervisor.  Xen was chosen because on machines which do not have virtualization bits (like the cluster I’m building), Xen will do paravirtualization, which is still somewhat quick.Xen also has the concept of clustering and shifting VMs between instances - an important feature in a VM cluster!

Xen Spec Files

CentOS 6 no longer has support for Xen.  CentOS decided that they were going to put their weight behind QEMU/KVM as the virtulization solution and thus stopped distributing and supporting Xen.  There are a few third party sites out there hosting packages. But, frankly, I am sufficiently paranoid to want to build them myself.  I also could not find a freely available spec file.  So I wrote my own for Xen.  Hopefully the fact that I simply use the official Xen source and a spec file that is very simple and easy to examine will satisfy those who are as paranoid as I am.

On to Building the RPM

1. Download a copy of my spec file.  As before put it …