Compile the Seom library

I choose to install both Seom and Yukon in a custom prefix /home/plouj/yukon, rather than the system wide /usr or /usr/local.

$ svn co https://devel.neopsis.com/svn/seom/branches/packetized-stream seom
$ cd seom
$ ./configure --prefix=/home/plouj/yukon --arch="x86" --cflags="-W -Wall" && \
make CC="gcc -m32" && make install LIBDIR="lib"

Note that “–arch=”x86″ and “-m32″ are only necessary for me because my operating system is 64bit and I need 32bit versions of seom and yukon (to work with 32bit Google Earth).

Compile and install Yukon

$ svn co https://devel.neopsis.com/svn/yukon/branches/rewrite yukon
$ cd yukon
$ ./configure --prefix=/home/plouj/yukon/ --libdir="lib" --arch="x86" && \
make CC="gcc -L/home/plouj/yukon/lib -I/home/plouj/yukon/include -m32" && \
make install

Install Google Earth for Linux

Obviously get it here: http://earth.google.com/

Modify the Google Earth startup script

Since I chose /home/plouj/bin/ as the “Binary path” for Google Earth I was editing /home/plouj/bin/googleearth. All I had to do was to add yukon/seom library and executable paths at the end of the script:

...
cd "${GOOGLEEARTH_DATA_PATH}/"
LD_LIBRARY_PATH=/home/plouj/yukon/lib/:$LD_LIBRARY_PATH \
PATH=/home/plouj/yukon/bin:$PATH exec yukon "./googleearth-bin" "$@"

instead of the original:

cd "${GOOGLEEARTH_DATA_PATH}/"
exec "./googleearth-bin" "$@"

Capture

Finally, the capture process is well documented on the Yukon website.

In Fedora 8, Jigdo was easy to install:
# yum install jigdo

From the jgdo manpage I discovered that the command line client version of jigdo is actually called “jigdo-lite”. Using this client turned out to be as easy as telling it which “.jigdo” file to use:

$ jigdo-lite http://www.muug.mb.ca/pub/fedora/linux/releases/9/Fedora/x86_64/jigdo/Fedora-9-x86_64-DVD.jigdo

Jigdo was nice enough to ask me to enter a path to previous installation media (presumably Fedora) to check for files which can be reused. To my amusement it turned out that the Fedora 7 x86_64 DVD contained no such files while the Fedora 8 x86_64 DVD contained 116 of the 2691 files required by the template.

Resuming jigdo was an interesting process. I canceled the first attempt with Ctrl-C. Then I simply re-ran the original jigdo command and it told me:

The temporary directory `Fedora-9-x86_64-DVD.iso.tmpdir' already exists. Its contents
ARE GOING TO BE DELETED (possibly after having been copied to the
image, if they are of interest for it). If you do not want this
to happen, press Ctrl-C now. Otherwise, press Return to proceed.

This puzzled me because it didn’t say what is the meaning of the files in the *.tmpdir directory. Without knowing that I shouldn’t be expected to assess the importance of the directory and make a decision about deleting it. My initial guess was that it contained everything that jigdo has downloaded in the previous session. I checked the “jigdo” and “jigdo-lite” mangpages but they did not mention resuming. Thankfully, the documentation on the website was more helpful. The Downloading Of The ISO section made it clear that I shouldn’t fear to loose Fedora-9-x86_64-DVD.iso.tmpdir after all. Apparently it simply stores files which have just been downloaded but haven’t been merged into the temporary image (which is called Fedora-9-x86_64-DVD.iso.tmp). I checked that currently Fedora-9-x86_64-DVD.iso.tmpdir is much smaller than Fedora-9-x86_64-DVD.iso.tmp so I feel confident in letting jigdo delete that dir:

$ ls -lah
total 3.9G
drwxrwxr-x  3 plouj plouj 4.0K 2008-05-14 15:48 .
drwxr-xr-x 25 plouj plouj 4.0K 2008-05-14 11:16 ..
-rw-rw-r--  1 plouj plouj 314K 2008-05-14 11:30 Fedora-9-x86_64-DVD.iso.list
-rw-rw-r--  1 plouj plouj 3.9G 2008-05-14 15:47 Fedora-9-x86_64-DVD.iso.tmp
drwxrwxr-x  4 plouj plouj 4.0K 2008-05-14 15:47 Fedora-9-x86_64-DVD.iso.tmpdir
-rw-rw-r--  1 plouj plouj 211K 2008-05-12 13:11 Fedora-9-x86_64-DVD.jigdo
-rw-rw-r--  1 plouj plouj  12M 2008-05-12 11:38 Fedora-9-x86_64-DVD.template
-rw-rw-r--  1 plouj plouj 3.0M 2008-05-14 11:30 jigdo-file-cache.db
$ du -sh Fedora-9-x86_64-DVD.iso.tmpdir
7.5M	Fedora-9-x86_64-DVD.iso.tmpdir

Find confirms the same:

$ find Fedora-9-x86_64-DVD.iso.tmpdir -type f
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/lucene-contrib-2.3.0-1jpp.0.fc9.x86_64.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/libpng-1.2.24-1.fc9.x86_64.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/lftp-3.6.3-2.fc9.i386.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/www.muug.mb.ca/pub/fedora/linux/releases/9/Fedora/x86_64/os/Packages/glibc-2.8-3.x86_64.rpm

After I pressed “Return”, jigdo happily resumed downloading my Fedora 9 DVD. Some time later, the download finished successfully and the resulting image passed the SHA1SUM check.

In addition to the resuming confusion I noticed a few other problems with Jigdo. Firstly, it just takes a long time to download and check all the files. It has been running for over 3 hours and at 500KB/s (the average speed I get from good servers) the whole DVD image (3970.8 MB) would have been downloaded by now. Secondly, the name is hard to spell correctly. I’ve gone from “Jingo” to “Jidgo” to “Figdo”.

To be fair, I have to admit that the coolness of what jigdo does in the background outweighs its shortcomings and I am happy with it in the end.

Right away I knew that I wanted to be able to easily attach to the bittorrent screen session at any time, so I used an easy to remember name for it:

screen -s torrent

I also knew that for screen to work with cron it had to start in a “detached” mode. Thankfully, the screen manual told me how to do that:

screen -d m

During my research I came across different people mentioning a short form for all of the above switches:

screen -dmS torrent

Since I like to simplify things I immediately adopted it and unfortunately paid dearly in the end. In fact, this was one of those attractive in theory but poorly executed features that cause other things to fail and waste my time with unhelpful error messages. It took me a few hours to figure out that it was causing screen to keep failing to start from inside cron with a “Must be connected to a terminal.” error.

Once I got over that hurdle I tried the full command without cron:

screen -d -m -S torrent /usr/bin/rtorrent

Everything was good until I noticed that I couldn’t use any rTorrent keyboard commands. I couldn’t even quit it apart from killing it from a separate terminal. According to the rTorrent user guide this was a result of a flow control conflict with screen. Thankfully screen also had a switch -fa just for that:

screen -fa -d -m -S torrent /usr/bin/rtorrent

To be on the safe side I used an absolute path to screen in the cron job:

/usr/bin/screen -fa -d -m -S torrent /usr/bin/rtorrent

Making sure cron starts this each time my computer boots was easy with the @reboot directive so this is exactly what should go in the crontab:

@reboot /usr/bin/screen -fa -d -m -S torrent /usr/bin/rtorrent

After running rTorrent like this for a few days I noticed that it was a bit unstable and would crash sometimes so I came up with a simple Bash script to keep it running:

$ cat ~/bin/myrtorrent
#!/bin/bash
PROGRAM="/usr/bin/rtorrent"
GRACE_DELAY=15
while true;
do
    "$PROGRAM"
    RETURNED=$?
    if [ $RETURNED -ne 0 ]
    then
	echo "$PROGRAM did not exit cleanly with status code $RETURNED"
	echo "pausing for $GRACE_DELAY seconds before restarting $PROGRAM"
	sleep $GRACE_DELAY;
    else
	echo "$PROGRAM exited cleanly. It will not be restarted automatically"
	exit 0
    fi
done

The final cronjob looks like this now:

@reboot /usr/bin/screen -fa -d -m -S torrent $HOME/bin/myrtorrent

Sadly, the usefullness of this setup is questionable since Bell is throttling DSL resellers’ peer-to-peer traffic.