More tea please.

Hacking in Iceland!

I’ve been in Iceland now for over a week, along with the glacsweb team — including Jeff and Tom. We’ve just moved into our third accommodation, which has a free wifi connection that makes it highly compatible with our high bandwidth requirements. I took a couple videos. The first is of our previous (and second) hacking situation:

Yesterday, Jeff and I finally got to go to the glacier (we were locked in the above shed for about 5 days and gradually became more and more insane).

At the moment we’re fighting a battle against failing probes. When we start looking at one, it fails! Argh!

I’ll try and stick more up here later.

Posted at 6:51 pm on Saturday 9th August 2008
One Comment

sendkey: Automated ssh key setup

I sent my “sendkey” script to Ivor. This script automates the injection of one’s ssh public key into a remote host’s authorized_keys file (to allow password-less login). It didn’t work very well when Ivor ran it. I’ve now updated the script:


KEY=`cat ~/.ssh/id_rsa.pub`

ssh $1 bash <<EOF                                                                                                                               
mkdir -p ~/.ssh
chmod u=rwx,g=,o= ~/.ssh                      
echo $KEY >> ~/.ssh/authorized_keys
chmod u=rw,g=,o= ~/.ssh/authorized_keys

It can be run like this:

% ./sendkey remoteusername@remotehost

15/02/2007 Update: I fixed the script so that it made the .ssh directory first… kind of important.

29/02/2007 Update: Klaus pointed out that it might be useful to write how to generate one’s ssh keys:

/usr/bin/ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''

Posted at 10:38 pm on Wednesday 13th February 2008

I2C Device udev rule

I just wrote a udev rule that would make any userspace i2c devices be owned by the i2c group:

KERNEL=="i2c-[0-9]*", GROUP="i2c"

(You can stick that in a file in /etc/udev/rules.d if you’re using Fedora).

Posted at 12:24 am on Tuesday 29th January 2008

A file IO monitoring utility: iomon

Recently I needed to log the calls to read() and write() calls that a program made, including the data that went through them. I hacked together a small program, called “iomon”. It runs on Linux (or at least on my Fedora 8 install anyway). What makes it exciting is that I can use it without modifying the program I’m monitoring.

It uses features of the dynamic linker (the thing that’s resposible for loading the shared libraries that a program needs during execution – see man ld.so) to interpose a monitoring function between a call to a library function and the actual library function. When read(), write() or open() are called, an event is logged.

You can get iomon by checking it out like so:

git clone http://xgoat.com/proj/fiu/iomon/iomon.git/

You can build it by just running “make”:

% cd iomon
% make

You might need to install the glib 2.0 headers (in Fedora, they’re in the glib2-devel package).

Example Usage

I thought it might be useful to demonstrate how to use it with an example. After building iomon, build the following C program (also available here) using gcc:

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

int main( int argc, char** argv )
        int f, g;

        umask( 000 );
        f = open("test-file1", O_RDWR | O_CREAT);
        g = open("test-file2", O_RDWR | O_CREAT);

        write(f, "test", 4);
        write(g, "second file", 11);

        return 0;

This is the program that we’re going to monitor. As you can probably see, the program just opens a file called “test-file1” and another called “test-file2”. It then writes “test” and “second file” to the first and second file respectively. Not really a very useful program, but it will suffice for this demo.

The next thing to do is set the LD_PRELOAD environment variable to contain iomon.so. The dynamic linker needs to be able to find the shared object file, and so the easiest thing to do is to put the full path into LD_PRELOAD:

% cd iomon
% export LD_PRELOAD=`pwd`/iomon.so

Now every time that you run a program in this shell, iomon.so will be loaded first. At the moment iomon will default to dumping all the read, write and open calls to standard output in raw format. I suggest that you don’t run anything in this mode… iomon is configured through the IOMON environment variable. This takes a list of arguments just like any command line program:

% IOMON="--help" cat /dev/null
  iomon [OPTION...] 


Help Options:
  -?, --help         Show help options

Application Options:
  -f, --file         File to monitor access to.
  -l, --log          Log file
  -t, --text-log     Log in text, instead of binary
  --times            Include times in the log

There’s some helpful information on how to use it. I’ll explain the arguments in a little more detail:

Right! Now we can run the test program:

% IOMON="-t --times -f test-file2" ./test
0.000016 open: 74 65 73 74 2D 66 69 6C 65 32 
0.000138 write: 73 65 63 6F 6E 64 20 66 69 6C 65 

And there we see the call to open for test-file2, followed by the filename in hex. Then there’s the data sent to it through write() also in hex. The logged call to open() happened 16μs after the first call to open(), and the write() call we were interested in happened 122μs later.

Hopefully I’ll be writing about why I needed this utility later.

Posted at 8:06 pm on Monday 21st January 2008

Site by Rob Gilton. © 2008 - 2019