Building qfsm on Ubuntu 8.04

I just tried to build qfsm on Ubuntu 8.04. The only dependencies listed by qfsm are CMake and Qt 4.3.x – both of which are available through the Ubuntu packet manager.

However, when I followed the instructions provided along with the qfsm source code, I encountered this error message:

[ 41%] Building CXX object CMakeFiles/qfsm.dir/src/ExportAHDLDlgImpl.o
In file included from qfsm-0.51.0-Source/src/ExportAHDLDlgImpl.h:21,
                 from qfsm-0.51.0-Source/src/ExportAHDLDlgImpl.cpp:21:
qfsm-0.51.0-Source/src/ui_ExportAHDLDlg.h:27: error: expected constructor, 
  destructor, or type conversion before ‘class’
make[2]: *** [CMakeFiles/qfsm.dir/src/ExportAHDLDlgImpl.o] Error 1
make[1]: *** [CMakeFiles/qfsm.dir/all] Error 2
make: *** [all] Error 2

It turns out that the definition of the QT_BEGIN_NAMESPACE macro was nowhere to be found on my system. Luckily, removing the corresponding lines in the qfsm source code allowed me to build the code just fine. I used this one-liner to remove the offending lines:

$ for file in `grep -R QT_BEGIN_NAMESPACE * | awk -F : '{ print $1; }'` ; 
  do sed -i -e '/QT_.*NAMESPACE/d' $file ; done

Follow-Up

A quick follow-up to "Parallels" for Linux. I’ve managed to run the Windows XP Partition on my Laptop inside KVM-88 like this:

#!/bin/sh

export SDL_VIDEO_X11_DGAMOUSE=0
sudo qemu-system-x86_64 -hda /dev/sda -net nic -net user -m 1024 -cdrom fixntldr.iso -boot d -usb -usbdevice tablet -monitor stdio

To send Ctrl+Alt+Del, I needed to enter this at the QEMU shell:

sendkey ctrl-alt-delete

Edit (Jul 30th, 2009): Here is a link to the QEMU console commands.

Avnet Spartan-3A Eval Board

So I got this Xilinx Spartan-3A Board by Avnet recently. I bought it because it features a fairly large parallel flash chip (32 MBit) and an even larger SPI flash (128 Mbit).

The board also features three clocks. One 16MHz clock is driven by an on-board oscillator while the other two (12 MHz and 32 kHz) are derived from a small controller.

For the last few evenings, I tried to get the parallel flash to work. Since a single cycle of the slow 32 kHz clock meets the timing requirements of the parallel flash chip, I thought I’d try to use that before enhancing the design to also work w/ the faster clock(s).

Unfortunately, that didn’t work. When using the slow clock, mapping a signal directly to an output (LED) worked just fine, but routing the signal through more than few flip-flops didn’t work at all. Apparently, the FPGA didn’t like the slow clock too much.

Bottom line: Took me three days to figure out that the board doesn’t work with the slow 32 kHz clock. Oh well, at least I learned something new…

SSH Tricks

My shell scripting skills suck. So it comes naturally that I learn a lot every time I need to write a script. The trick I’m about to describe is so neat that I want to share it.

Assume for a second that you need to execute a series of commands on a remote machine, but you can’t pass them to SSH at once. Or consider that you might need to transfer a file over to a remote host and then extract it there. Normally, you’d need to create several SSH connections for this. In the “transfer, then extract” scenario, you need one connection for scp(1) and another one to extract the file on the remote host. Unless you have your public key in the remote host’s ~/.ssh/authorized_keys file, you need to enter your password for the remote host twice. It’s probably not a big deal for most, but it’s annoying at times.

It might be obvious for some, but I recently found out that ssh(1) offers a solution for the problem described above. It allows you to open one connection in "master" mode to which other SSH processes can connect through a socket. The options for the "master" connection are:

$ ssh -M -S /path/to/socket user@rhost

Alternatively, the ControlPath and ControlMaster options can be set in the appropriate SSH configuration files. Other SSH processes that want to connect to the "master" connection only need to use the -S option. The authentication of the "master" connection will be re-used for all other connections that go through the socket. I’m not sure if SSH even opens a separate TCP connection.

Going further, this can be used in scripts to save the user a lot of password typing, especially if the execution flow switches between local and remote commands a lot. At the beginning of the script, simply create a &qout;master" connection like this:

$ ssh -M -S /path/to/socket -f user@rhost 
    "while true ; do sleep 3600 ; done"

It should be noted that the path to the socket can be made unique by using a combination of the placeholders %l, %h, %p, %r for the local host, remote host, port and remote username, respectively. The -f parameter makes SSH go into the background just before command execution. However, it requires that a command is specified, hence an endless loop of sleep(1) calls is added to the command line. Other SSH connections can be opened like this, not requiring any further user input (for authentication):

$ ssh -S /path/to/socket user@rhost

This leaves the problem of how the "master" process can be terminated when the script has finished. Some versions of SSH offer the -O parameter which can be used to check if the "master" is still running and, more importantly, to tell the "master" to exit. Note that in addition to the socket, the remote user and host need to be specified.

$ ssh -S /path/to/socket -O check user@rhost
$ ssh -S /path/to/socket -O exit user@rhost

However, there are still two problems to be solved. First, when the "master" quits, the dummy sleep loop continues to run. And second, how can the "master" be terminated if the given SSH version doesn’t offer the -O parameter (short of killing the process by its PID)?

hexdump(1) lies!

This week I found out that hexdump(1) on Linux doesn’t seem to work with bytes but with half-words. I found out because I compared a byte-by-byte binary dump (output of a separate program) to the output of hexdump(1) (dumping the same data) and noticed that hexdump(1)‘s output always swapped two adjacent bytes.

Maybe I haven’t found the right parameters, though.

An Encrypted File-backed File System on FreeBSD

The following is a compilation of information, largely based on the FreeBSD Handbook, Section 18.13 and Section 18.16. This post describes how a file-backed, encrypted file system can be built and used on FreeBSD.

Prerequisites

In order to follow the steps below, the following prerequisites must be met:

  • md(4) in the Kernel
  • gbde(4) in the Kernel, i.e. kldload geom_bde
  • The /etc/gbde directory must exist

First time installation

After those requirements are fullfilled, it’s time to take the first step which is creating a file that will serve as the basis for the file system. There is no support for growing images so you need to allocate all space now. This command creates a 128 MByte file filled with zeros:

$ dd if=/dev/zero of=encrypted.img bs=4k count=32768

Next, create a memory disk which is based on the the image file created above. As root, do:

# mdconfig -a -t vnode -f encrypted.img -u <unit>

In the example above, the parametr -u <unit> is optional and specifies a number which determines the number of the md(4) device. For example, if you use 4, then md4 will be created.

Now create a partition table which, e.g. one with an automatic layout:

# bsdlabel -w md<unit> auto

At this point, you have the equivalent of a hard disk w/ one or more FreeBSD partitions on it. Note that there is no filesystem, yet. In order to create an encrypted file system, an initialization step must be performed:

# gbde init /dev/md0c -i -L /etc/gbde/encrypted.lock

The initialization step opens an editor where the user is asked to enter a few parameters. Most notably it is probably sensible to change the sector_size to 4096, i.e. the page size on i386. When the editor is closed, the gbde(8) program asks for a password. This password will be used to encrypt the disk, so do not lose it. Note that the /dev/md0c parameter corresponds to the md(4) device which was previously created. The file of the lock name can be arbitrarily named as long as its ending is .lock. Also note that the lock file must be backed up as the file system cannot be easily accessed without the file.

Now the encrypted device can be attached by running

# gbde attach /dev/md0c -l /etc/gbde/encrypted.lock

You’ll be prompted for the password set in the previous step. If the password is accepted, you’ll end up with a new disk device at /dev/md0c.bde on which you can operate the same way as on a regular disk. That means you’ll need to create a file system, first.

# newfs -U -O2 /dev/md0c.bde

Make sure you use the .bde device node and not the raw memory disk as you’d end up without encryption. When you’re done, it’s time to mount the file system:

# mkdir /encrypted
# mount /dev/md0c.bde /encrypted

Unmounting the encrypted file system

Unmounting the file system is easy, but the gbde(4) device needs to be detached before the md(4) device can be destroyed.

# umount /encrypted
# gbde detach /dev/md0c
# mdconfig -d -u 0

Re-mounting an encrypted file system

Re-mounting is simple, but note that the FreeBSD handbook suggests that the file system be checked for errors before mounting:

# mdconfig -a -t vnode -f encrypted.img
md0
# gbde attach /dev/md0c -l /etc/gbde/encrypted.lock
# fsck -p -t ffs /dev/md0c.bde
# mount /dev/md0c.bde encrypted

Generating random passwords

Here are a couple of ways of generating random passwords without using a “password generator”. First, generate a random string like this:

$ dd if=/dev/urandom count=500 bs=1 | tr "n" " " | sed 's/[^a-zA-Z0-9]//g'

or like this

$ dd if=/dev/urandom count=500 bs=1 | md5

Then adjust the length by piping the output through cut(1):

... | cut -c-8

While the first option is more to type, it generates lower and upper case letters. The second option is easier to type but only generates lower-case passwords.

Update (Dec 12th, 2008): Fixed error. cut(1) must be used, not cat(1).