ghedo's log /dev/random

Building Debian packages using Linux namespaces

In the past few days I have been messing around with Linux namespaces, and developed a little tool (pflask) that automates the creation of simple Linux containers based on them (a sort of chroot(8) on steroids if you will).

While the whole raison d'ĂȘtre behind this project was "just because", and many more mature solutions exist, I decided that it'd be nice to find an actual use case for this (otherwise I tend to lose interest pretty quickly) so I wrote a lil (and rather dumb) pbuilder clone that uses pflask instead of chroot.

The nice thing about pflask is that, differently from e.g. LXC, it doesn't need any pre-configuration and can be used directly on a vanilla debootstrap(8)ed Debian system:

$ sudo mkdir -p /var/cache/pflask
$ sudo debootstrap --variant=buildd $DIST /var/cache/pflask/base-$DIST-$ARCH

Where $DIST and $ARCH are e.g. unstable and amd64.

Once that's done just run pflask-debuild on the package sources:

$ apt-get source somepackage
$ cd somepackage-XYX
$ pflask-debuild

The script will take care of creating a new container, chroot(2)ing into it, installing all the required dependencies, building and signing the package (it also runs lintian!).

The main difference from pbuilder is that pflask will mount a copy-on-write filesystem (using AuFS) on the / of the container so that any modification (e.g. installation of packages) can be easily discarded once the container terminates (similarly to what cowbuilder(8) does, modulo the hardlinks hack).

Additionally, thanks to the mount namespace created inside the container, all of this will be isolated from the host system and other containers, so that multiple packages can be built simultaneously on the same base debootstrapped directory.

Another possibility would be that of disabling the network inside the container using a network namespace, in order to prevent the package build system from downloading stuff from Internet while at the same time maintaining the network active on the host system, but I haven't done any experiment in this direction yet.

Note though that all of this is rather crude and experimental, but as a little hack it seems to work rather well (YMMV).

Minimal volume management daemon

Since I was a XFCE user I have been using the xfce4-volumed app, a daemon which makes the volume up/down and mute keys work automatically and also shows nice notifications.

Long story short, I stopped using XFCE and I wanted to get rid of some stuff from my system (e.g. xfconf and gstreamer) with xfce4-volumed being the only thing left using them. Not finding any better alternative, I have decided to write my own version:

Differently from xfce4-volumed, my version uses the ALSA (asound) and X11 APIs directly and does not require xfconf (or anything else really). You can find it on GitHub.

Demoscene - The Art of the Algorithms

Although existing art media have been transformed in the digital age, the advent of computers has brought new art forms into being. In the past, visual arts and music required both intellectual and physical skills, but in the present, computer programming permits people to make art just by using their minds. Moleman 2 presents a subculture of digital artists working with both new and old computing technology who push their machines to their limits.

Kernel module to disable ptrace()

I don’t really know why I ended writing this, but it all started as a way to do some Linux module coding.

Anyway, all this module does is overwriting the Linux syscall table, and replacing the ptrace() syscall with a custom one (which does nothing but printing a message).

Now, I’m quite sure there are better ways of doing this, so take the whole code just as a humble example of Linux module development.

The code is also on GitHub, as usual. There you can also find a Makefile to compile the code:

$ make

Then load the module with:

# insmod noptrace2.ko

And look at the output of dmesg:

$ dmesg | tail -1
[25374.003588] [noptrace2] ptrace syscall disabled

Which means everything went as expected.

x86 booting code

I have written a little snippet of code that magically boots on x86 hardware (not sure if it works on x86_64 as well). It’s a few lines of assembly code, just for fun.

It compiles with nasm(1):

$ nasm -o boot.bin boot.asm

It works pretty well under qemu(1), but I have not tried it on bare metal hardware yet. Not that it does anything fancy: it boots, prints a string and loops forever.

The code on GitHub includes a Makefile to make the iso image generation (using genisoimage(1)) and the vm start-up, easier.

With a simple make run it compiles the code, generates the iso and starts the virtual machine.

Enjoy :)

Page 1 of 3