PLANNING AND CONSIDERATIONS

So first when planning a system like this you need to decide a few things. What are the aspects that are most important to you?

• Speed?

I've decided that this system will be a mass-storage. A data-grave. Thus i have made no attempts whatsoever to optimize speed in any way. The result is relatively clear - not really fast.

• Security?

Does the data need special protection? For me it was simple - i've got a okay~ish CPU in the host box, so encrypting the whole data is no big problem. Why NOT do it?

• Reliability?

How important is the data you want to save really? RAID is nice, but it is NO BACKUP. Are there special considerations to make for desaster recovery? As this is going to be a data-grave for me i've opted for a "best effort" policy. I've got a used UPS to protect my equipment (server and this storage) from power losses and voltage fluctuations. Then i've decided for a RAID system, namely the old RAID 5. As i said i haven't optmized for speed, so RAID 0+1 was no option since you'd need more disks to get the same actual storage size. As for desaster recovery i've decided to use a LVM layer on top of my crypto layer. This allows me for snapshots (in case of huge write events when snapshotting i think i can even use a external large disk as a snapshot device...) when i perform critical filesystem operations. If the filesystem ever fails so hard that i have to perform potentially dangerous operations (and FSCKing a "crashed" ext-filesystem IS dangerous) i can always just snapshot, toy around, if i break it revert the snapshot...

• Noise and vibration?

As for vibration (and thus much of the noise of a harddisk array) you need to trade a few things off. On one hand its really nice to mount disks with thick rubber layers to dampen their vibrations. This has the backdraw that the harddisks will always move - they'll swing on the flexible rubber layer. Consider this article/video by Brendan Gregg to see why this is bad: Unusual Disk Latency. So basically you'd want something that is very rigid so the drives don't move *too* much. On the other hand, to isolate each harddrive from the vibrations of the others (huge commercial raid arrays all have/need ways to deal with isolating individual drives - consider a scenario where a RAID 5 or similar level array starts writing, many drives start seeking at the same time sending a huge vibration-wave through the case disturbing (and as i've heared - yes, only heared) and even headcrashing other drives.

I've attempt to achieve this by applying my knowledge from building speaker enclosures. The scenario as well as the vibration frequency range are quite similar. To supress case movements i've chosen a even (internally) and dense material: MDF. While this has the backdraw that it heavily couples the drives it will do a good job at dampening the overall vibration. As a upgrade to this (which i haven't implemented yet) one could use a additional "energy trap" consisting of a moveable, rubber-like but very stiff material. Fortuneatly this is readily available as a mat to put your washing machine on! If i'm not entirely mistaken even putting the whole construction on a piece of such a mat will not only effectively lower the (hearable) noise from the array but also further dampen vibrations by taking in the (slight) case movement and turning it into "heat" (by elastic deformation(?TODO: ASK PHYSICIST?)).

• Connection?

How do you plan to connect the device to your computer? There are basically two ways of doing this: One is to use a cheap S-ATA adapter card with enough ports (see below) which will then leave you with a large pack of cable running from whereever you place the array to into your computer (also requiring some kind of large hole in your case to route the cables through). I've chosen this option as it fits my needs (server standing somewhere in a drawer) better. The other thing i've come across are sata multiplier cards. These nifty little things implement a integral but not widespread part of the sata-specification: some kind if hub/switch. If your card supports sata port multipliers (and really REALLY check if it does!) you can get a rather cheap (~60Eur maybe) multiplier card (e.g. from "dawicontrol") which enables you to build a completely self-contained storage - just plug one (e-)sata cable into your computer and zuuup, there are your 5 drives!

CHOOSING PARTS

Theres a bit of a philosophical question here regarding harddrives. You could either use 5 exactly same drives bought from the same store, thus having a larger probability to be from the same production batch. For one this would be great because seek and throughput performance would be the same, you wouldn't waste bandwidth waiting for one slower drive. On the other hand this can suck because ... if theres a manufacturing error and one drive dies, you replace it, start a rebuild, the rebuild puts heavy strain on the other drives, bearing the same error they'll be likely to die too leaving you with severe data loss. So i'd recommend you either to try to get the same drives from different batches, or - that was the way i did it - buy 5 completely different drives. As speed is a non-issue for me this seemed the safest choice when it comes to per-batch production errors.

As for the adapter card i was very lucky to find leaf-computer.de who seem to offer quality storage controllers used on very simplistic PCBs - such as this: Marvel 8Port SATA Adapter. Exaclty what i need! And at what a small price tag! The marvel chip used on this board is known for excellent linux driver support as well as good performance and a nice feature set. Heck you could even plug sata port multiplier on this and achieve a 8x 5-disk-raid-5! It does also support staggered spinup (spinning up one drive after another putting less load on the PSU)

As for the other components i've simply tried to choose reasonable at a good bang for the buck ratio. A simple 450W PSU with 85% efficiency even in the medium power range, a reasonably silent and powerful large fan... thats about it.

IMPLEMENTATION (hardware)

Taking the measurements at the drives and calculating the case sizes was a bit of a hassle, but in the end it worked nicely. Here you can see a the parts of the case loosely put on each other.

As for the parts needed - heres the list:

• 1* 306x186mm
• 2* 102.2x186mm
• 1* 219x186mm
• 2* custom measures parts of ??x105.4mm

everything is made of 16mm MDF.

Here you can then see how the PSU will be mounted (it has two mounting holes where that square timber is) and the two custom measured parts. They close the edges of the fan and depend on the outer sizes of your fan - so first mount/measure the fan, then cut the MDF.

The case itself is assembled by using simple wood glue, then reinforced (as seen below) by counterbored screws to make the vibration-transfer better and distribute it throughout the whole case.

Now comes the most tricky part, and i must admit that i've forgotten to make detailed notes of this. You need to measure the harddrives (they're more or less 25.4x146.5x101.6mm by specification) and where their screw-holes are, then measure it on the top of your case, drill a hole that'll just fit your screw, then drill a little with a larger drill to countersink their heads...

After finishing the holes i've found a nifty little gadget in my old hardware scrapbags - a simple fan control pcb! Woo! I've just mounted it where it looked nice - please note that this is totally optional .

The next trick was to get the PSU to start and stay always running without attaching a mainboard or switch. Thanks to Wikipedias ATX Article this was very simple. Find the PS_ON pin, some random ground (the one above/beneath PS_ON for example), rip them out of the poor connector and solder them together... magic works, the PSU runs!

Now its time to mount the harddisks. This turned out to be a little more difficult than expected as you need to place the drives exactly under the drilled holes without looking. In the design i proposed there is a little space between the drives making this a little harder yet. I've had luck with using a led flashlight on the backsides (the one with the PCB) of the HDDs and looking through the holes from the top of the case...

... and having a hand in the front of the case is also very handy

Then i've packed all SATA cables into a nice large batch (wow, this looks SO professional )

and finally placed it where it belongs - in my drawer above my server!

After using it a few days i must say that both noise and heat is very good. Even with the fan on full i can barely hear the array even under full load (seek-hell). The drives report temperatures of 25-41*C through smart, which is really okay. When feeling with your hand it only barely warm...

IMPLEMENTATION (software)

Now as the hardware is completed, up and running lets head for the software. This was a little harder than i expected to get right. As already said i've chosen a design like MD <-> CryptSetup (LUKS) <-> LVM <-> EXT4 to have maximum flexibility, data security as well as a little more help in case of a data corruption.

The main problem with the software setup was to get all those abstraction layers neatly aligned. However, first things first. If you got new drives, what do you do? Right - badblocks and smart. The thing with badblocks on a new drive is that it almost in all cases will NOT yield badblocks. This is because a modern harddrive has some free blocks that are not mapped at the start of its livetime. As the drives firmware finds bad blocks while operating it'll replace them with those replenishment-blocks. Only when you run out of those you're in serious trouble. However, as smart prints the "Reallocated_Sector_Ct" field you'll identify a defective harddrive after a exhaustive badblock test even if there are replacement blocks left.

badblocks -s -w /dev/sd[efghi]

Is what you want to run now (assuming dmesg agrees that your new drives are sde,f,g,h,i). Do expect it to run quite long, if you want the RW test as proposed around 2-3 days. After that we'd want to start a smart long selftest (smartctl -t long /dev/sd[efghi]) and then read and try to interpret the results (smartctl -a /dev/sd[efghi]).

The next thing is ... naming your array! Its important for such hardware to have a good name. I've chosen the name "dantalian" of the recent anime "Dantalian no Shoka" (The Mystic Archives of Dantalian, ダンタリアンの書架). Its basically that this cute tsundere little girl here to the left does contain a large library of magic books in her chest, making her a library (the magic library dantalian). And as its magic it is HUUUGE. What is this array? HUUUGE! Nice fit!

Anyways, back to the software setup. Now that the drives are tested we can start to initialize the array. This can be done with:

mdadm --create -x 0 -l 5 -n 5 dantalian /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/sdi1

after partitioning your drives so you'll have one partition of the type "FD", aka linux raid autodetect. For testing purposes i propose to create a smaller partition, e.g. 100gb, on each drive. That way you can run your various desaster tests (and i've run SOME!) without the raid rebuild taking ages each time!

Now that md is told of the array, we need to persist its configuration. This can neatly be done byletting mdadm itself create the config

mdadm --detail --scan >> /etc/mdadm/mdadm.conf

This assumes a standard debian mdadm.conf (especially containing "DEVICE partitions", telling mdadm to probe all partitions known to the system to find raid drives...). Now you can monitor your raids initial 'rebuild' status by issuing

watch -n 10 cat /proc/mdstat

which will yield something like:

Personalities : [raid6] [raid5] [raid4] md127 : active raid5 sdi1[5] sdh1[3] sdg1[2] sdf1[1] sde1[0] 7814041600 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [UUUU_] [&gt;....................] recovery = 1.4% (28754816/1953510400) finish=1590.0min speed=20174K/sec

Now, according to a good source

If the device to be encrypted is an md RAID array, you should use the --align-payload= to ensure that crypto blocks are aligned on RAID stripes. This option takes as an argument the number of 512-byte sectors in a full RAID stripe. To calculate this value, multiply your RAID chunk size in bytes by the number of data disks in the array (N/2 for RAID 1, N-1 for RAID 5 and N-2 for RAID 6), and divide by 512 bytes per sector. In the example below, /dev/md0 is a RAID 6 device with 4 data disks and a stripe size of 128 kbytes: 128 * 1024 * 4 / 512 = 1024 sectors. # cryptsetup --verbose luksFormat --verify-passphrase --align-payload=1024 /dev/md0 When prompted, supply the key you created in the step above.

So, adapted to our scenario that means that we'll create the crypt layer using:

cryptsetup --verbose luksFormat --verify-passphrase --align-payload=4096 /dev/md/dantalian

Now (after opening the device using cryptsetup luksOpen /dev/md/dantalian dantalian-crypt) lets create the LVM:

Consider this formula:

metaatasize = chunk size times number of data disks in the array

which then gives us the command to create the physical volume format on the crypto-pseudodevice:

pvcreate --metadatasize 2048K --dataalignment 4096 -M2 /dev/mapper/dantalian-crypt

now, using pvscan you can let this new volume be autodetected as:

PV /dev/dm-2 lvm2 [7.28 TiB] Total: 1 [7.28 TiB] / in use: 0 [0 ] / in no VG: 1 [7.28 TiB]

Okay, we've got our physical volume for LVM, so lets create one volume group containing one (or more, depends on your preferences here) logical volume on those:

vgcreate dantalian-vg-main /dev/mapper/dantalian-crypt

lvcreate --name dantalian-lv-main -l 100%FREE dantalian-vg-main

Now, after some more vgscan and lvscan you should be presented with your /dev/dantalian-vg-main/dantalian-lv-main device - ready to create a filesystem. This again needs to be .... ha - what is it ... ALIGNED! Hell No!

Lucky for us EXT4 pretty much autodetects that it is on a raid device, what stripe-width and stride-width are, but to be sure lets ask our source from before again:

The relevant options for ext3 are stride and stripe-width. stride is identical to the md array chunk size, and stripe-width is identical to the array stripe width, except that both options are specified in units of filesystem blocks instead of bytes. The default ext3 (and ext4) block size is 4096 bytes, so simply divide your chunk size and stripe width by 4096 to get the proper values for these parameters. Here's an example using a RAID 6 array with 6 disks (i.e., 4 data disks) using a chunk size of 128k (stripe size is therefore 512 kbytes)

So for us its now:

stride = chunksize / blocksize, (512*1024)/1024 = 128.0

stripesize = stride * datadisks = 128 * 4 = 512

which will then result in the following mkfs command:

mkfs.ext4 -n -m 0 -E stride=128,stripe-width=512 -b 4096 /dev/dantalian-vg-main/dantalian-lv-main

leaving us (when removing the -n option) with a nicely aligned filesystem that is aware of the striping/striding. The last point is then again a data-security thing. If ever the unlikely case should happen that the crypt layers metadata get corrupted it is really handy to have a backup. This can be achieved by

cryptsetup luksHeaderBackup --header-backup-file DANTALIAN-LUKS-HEADERS /dev/md/dantalian

cryptsetup luksDump /dev/md/dantalian &gt; DANTALIAN-LUKS-HEADER-DUMP

with all its backdraws. Those can be found in the cryptsetup/luks FAQ!

Now after some while of using the array i'm quite fond of it. Its not only faster than i've feared (i do get 25-30MB/s over my gbit lan) its also proven to be quite sturdy in case of bad(TM) events. I've tried killing the power of the array, the host computer, tried unplugging single harddrives or even more than one harddrive - all even with heavy random access (compiling a kernel). I haven't succeeded in creating a situation that would've lead to data-loss.

Again, if you're interested in more details, would like to know the exact locations of the holes you need to drill for the harddisks or something else - just write a email or leave a comment!

As you can imagine our friend was flabbergasted (i somehow like that word) to the last. Read on for more details on how to build it!

So, there we are for detailed build instructions. As for materials and tools you'll need ... this could be somehow hard to get depending on where you live. We're lucky to have a *good* shop for metall stuff around, so we had a cheap go on a remaining stock Aluminum-sheet-metal. We went for quite thick material as we wanted to bend it, 1.8mm for reference. That descision might sound a bit too much, but it simply looks better, more sturdy and has less risk of breaking when bending it into the final form.

Aside of that you'll need a printer, a hobby-knife for cutting out the template and some transparent film for protecting the metal as well as pinning the template to the metal. For cutting out we used a Dremel (not original, but by Proxxon) and for the final finishing you'll need some fine/small files.

If you want to give the Aluminum a brushed look you'd need a thick (and straight) piece of wood, a F-clamp as well as some 600-sandpaper.

Again, only IF you want to seal it - we recommend a airbrush/spraygin and proper clearcoat, we used something slightly different - worked nice nonetheless.

Okay, off we go for the actual work. Print out your template, cut out the outlines with your hobbyknife and pin in to the sheetmetal. Then put the protective mask/film over it to protect the metal from scraches and hold the template properly.

What you'll need - and how to use

Start cutting out the outlines very slowly (the thick material may take you a long time...)

Slowly (any normal dremel won't allow you anything else) cut along your mark. Be carefull not to make your cut too long for "inside" corners - so you don't harm the actual shape.

Remember to flip your sheet metal from time to time - the backside is wonderful for refining the edges - especially for "inside corners"

As a little note: Really really be careful not to grind too far at "inside corners", it'll look really bad. A nice fix for "too small" edges is to turn over the sheetmetal and cut a bit from the backside, then turn to front again, and so on. Also, if one of your grinding discs got too small - save it for those jobs!

The first (easy) piece comes off ... huge success!

Back view of the next, more complicated cut

Skipped forward a bit. After cutting you want a good fine and small file to smoothen up the edges and corners. Remember to keep the protection layer so you don't make any unwanted scratches - which happens easily with files.

Detail of the head-section - this was the hardest cutting-work.

Okay, so for the brushing. First off - this is a picture of our first try, please note that it is a bad idea to first bend the deer, then brush it. But as for the general method - you need a straight piece of wood (here: the triangle) and push your sheetmetal against it so to straighten it. Then take another (smaller) piece of wood and wrap the sandpaper around it. If you now grind using the triangle as a guidance so all your "streaks" and scratches are exactly in the same direction you'll get that nice brushed look. You'll need to grind forth and back about 4-5 times, if you want a finer brushed look more often using a finer (800) sandpaper.

Brushing *after* bending is no nice idea . Remember to do it before.

Details of the brushed look.

Yay, finished (almost)!

Detail before cleaning/sealing.

The two finished deers (uncleaned/sealed)

For sealing we'll use our airbrush (0.2mm nozzle)...

... and lascaux transparent matte varnish/sealer. Wasn't made for this usecase, works like a charm nontheless. Remember to use this only thinned at least 1:1.

After spraying quite some of that stuff on the two deers they need to dry at least 30minutes.

And finished they are - holding our stack of University and Nerd books

Check out that DIY brushed alu - nice, isn't it?

Nice, isn't it? You may consider a different cutting technique for the rough outlines as normal dremels take *ages* (litterally, we've been grinding and cutting almost 16hours for those two deers here). Nonetheless this brithday-present was a rock-on gift, and the ability to custom-make any pixel-art into a bookstand is *THE* idea for a decent gift.

I hope you enjoyed this a bit picture-centered tutorial. If you have any questions, feel free to use the comment system, i'll answer as soon as i can.

Okay, so after almost two days of fighting with XeLaTeX to get nice unicode support and fighting defoma for getting a nice font its finally done!

You can fetch the PDF here, the booklet printing (just print it, fold the whole stack in the middle (short-edge oriented) and staple it together) version as postscript is available here.

Also note that there might be a few mistakes due to the hardcore TeX action in the typesetting, feel free to report those to me to get 'em fixed. For errors in the original document please contact the original author or me.

I hope you're having your fun playing with those rule sheets, i hope they came out nicely . For a nice, short yaku overview just surf up here.

I wanted to parse a website that had no RSS feed for changes and create a RSS feed. I first tried around with various of the ideas mentioned above but as the website is kind of "irregular" (every item is a slight bit different) and W3 validator shows over 11k of errors (in 1.1 transitional) i had quite some problems.

Until i found Rubies Hpricot, a HTML parser that lets you realize robust HTML parsing of fucked up formatted and non-standard-compliant content at ease.

Hpricot is quite simple to use. The basic idea of the parsing part is that you specify the tag-order you want to walk down in the tree. So maybe you want the content of a div inside a td inside a tr inside a table inside a table inside a div ... you get the idea. By the way, Firebug is extremely useful for finding the structures you need in the HTML tree hirarchy. Hpricot will walk you down all paths that match your criteria and return you the rest portion of the tree found down there:
require 'hpricot'
require 'open-uri'
overview = Hpricot(open("INSERT SOME URL HERE"))
prodno = 0
(overview/"table").each do |product|
if product.attributes=={} and not product.to_s.include? "closed on the days marked"
(product/"tr/td/table").each do |article|
prodno += 1
end
end
end
This is a small snippet of my parser code, it will open the url, fetch the content and create a Hpricot parser object, then for every table check whether its the table we search for (identified by the attributes and content text). Then it will count every item (in a 2-column table).

As you see the basic idea is quite simple, fetch element by tree position, identify the element with no doubts, do the actual magic.

For the actual magic point Hpricot also helps you alot! Things like
linkurl = (content/"a")[0].attributes['href'].to_s.gsub("\r\n","")
imgurl = (img/"img")[0].attributes['src'].to_s.gsub("\r\n","")
name = (content/"a")[0].inner_text.to_s.gsub("\r\n","")
are so simple (attributes seems self-explanatory, inner_text extracts only the text, not the tags that are children of the element you call it on).

A slightly more sophisticated example would be this:
detail = Hpricot(open(linkurl))

price = nil
stock = nil
sale = nil
(detail/"table//tr//td//table").each do |data|
if data.to_s.include? "can buy from here"
entries = (data/"tr")
entries.delete_at(0)
entries.each do |entry|
estr = entry.to_s.downcase
if estr.include? "sale price"
price = (entry/"td")[1].inner_text.to_s.gsub("\r\n","")
elsif estr.include? "sale status"
sale = (entry/"td")[1].inner_text.to_s.gsub("\r\n","")
elsif estr.include? "stock status"
stock = (entry/"td")[1].inner_text.to_s.gsub("\r\n","")
end
end
end
end
Here a site like this is parsed for information like stock status, sale status and price tag.

As you see this is a more robust approach compared to python string.split, XML DOM/SAX which doesn't work for non-standard sites. It's not as perfect as i would wish for "easy" html parsing, but its better than everything i've seen so far.

Also i'll post the script for parsing amiami.com for changes later (beware, no nice ruby code, hacked late at night in 1h ) so you can see a more elaborate example. I hope you'll have more fun parsing HTML using these Hpricot and these snippets .

So, that's why you might want to rebuild all those Tools you're used to in a trusted environment - your own server. You don't want your mail stored in some possible hostile environment on a untrusted machine that could leak your valuable data. Turns out its not that easy sometimes. I've only worked on getting a capable Web Mailer and Feed Reader to run smoothly. What surprised me here - and why I'm writing about this - is that it was exceptionally hard - or rather time-intensive - for something sounding as easy as this.

I first targeted the Reader, looked around Freshmeat and SourceForge where you expect to find decent free software for that task. I've found quite a few not-so-simple-looking projects, including Tiny Tiny RSS. Turned out TinyTiny RSS is almost there, but needs PostgreSQL. So  i set up PostgreSQL, installed TTRSS and set it up. Imported GoogleReaders OPML, and zup. worked. Problem's all the feeds are in one big Table - resulting in the whole thing beeing painfully slow. So up for 7-8 Hours of harcore Postgres performance tuning, trying to hack memcached into ttrss, etc. Speedup of almost 100%, yet it was not close to beeing usable. Turns out the developer didn't intent the project for archiving articles for having a searchable archive. So up for something different, Gregarius, which the TTRSS dev recommended. This worked quite out of the box, except for 3-4 Hours of tinkering and writing small plugins to get the whole thing to work properly. But it does - and has almost all the feature one expects.

The harder part came now, Webmail. I first tried to hack the roughly-set-up RoundCube that still was on my server. After short testing and many functions that just did not work due to unknown reasons i knew i needed something different - and started toying around with Horde and its webmailer Imp(4) in the Horde Webmail Edition pack. Horde feels somehow "unix style"-ish, like ... building a highly reusable backend, letting other projects include/work ontop of that backend, etc. - but let me say one thing: This beast is so darn hard to set up. I've got it working - more or less - after hours and hours of doc reading, tinkering around with mysql tables and databases and reading Horde source due to its ... slightly lacking ... documentation on some points. Still, it was so unstable and lacked features too. So i finally decided Horde/IMP was a bit too much to go with. After searching around its a lets-get-back-to-Roundcube.

Just that this didn't make things better, well... a bit at least. It takes tinkering, fixing old plugins to work with the current version, finding out why the hell buttons are greyed out that shouldn't be and getting a "well, reset the database (again)" from the developers. All of that fun. As of now i at least managed to get everything except for Filter-Rules and sa-learning ham to work. Phew!

Okay, so why am i writing all this? you may ask yourself. Well, i've gone through some PITA for beeing independent. It really takes some work to get everything to run smoothly if you're used to professional systems that are customly coded (such as the google stuff) and backed by real money its still some hackish tinkering to get the Free Software tools that we're given by the community (which i'm not ranting against by the way, all that code out there is really beautiful in fact) to the same level. I also want to encourage everyone out there not to give away their data but to build something on their own, keeping their data. As computer users used to for a good reason for a long long time.

So, after a *ton* of googeling and looking around i found out theres a app for jailbroken iPhones which reads the .sqlitedb files of Contacts, Calendar and Notes and sends it to a specialized synchronization server for PIM. Luckily theres a bunch of clients for other platforms - including S60, evolution, ldap, etc. - we're interested in the Evolution one.

So, i installed Funambol (the syncserver) on my server and started it up. First to notice is that the startup often does not work at first try - i had to start/stop the server a few times before it would serve me on http://hostname:8080/funambol/. Also there seems to be a fucked-up state where the http-server is running but the admin-interface won't let you log in. At that point i also had to restart the server a few times *sigh*.
Then i installed iPhoneSync, the iPhone funambol client on my handset, started it up, entered my servers data and synced. Woosh, failed. The Log said "server returned error -1" ... wowziez, cool - whats that? No table of error codes, no description, no server debug log entries, nothing - not even a bugreport in some mailinglist. Basically its a funambol bug concerning contact-Thumbnails with more than 8k size *Sigh*. At least its fixed in svn trunk...

Now comes the fun part - compiling Funambol. As Funambol needs tomcat, netbeans, maven2 and a whole other bunch of dependencies its *really* fun. With some tinkering i made it to a installer package - that now even works with the iPhone.
So, for all of you out there running into the same bug as me - heres a Funambol binary of svn trunk with this bug fixed:

http://tmp.kanojo.de/funambol-8.2.2-SNAPSHOT.bin

So - here's what you basically need to do:

1. scp the above binary on your server, ssh there and execute "sh funambol-8.2.2-SNAPSHOT.bin"
2. install the server as guided by the installation program, i installed it to /opt. Also note it *really* only installs stuff there, so no worries about trash not managed by the package management on your system .
3. when asked whether you want to start the server say no
4. cd to /<wherever>/Funambol/, execute "./bin/funambol-server start", wait a few minutes (you can also check top whether java has stopped eating up your whole cpu-power)
5. start up the admin interface, either on the server by using remote X (ssh -X) "./admin/bin/funamboladmin" or in a installation of funambol on your current desktop box.
6. there, log in using "admin" as user and "sa" as password, go to user management, change the admin pw (important! ) and log in again.
7. once again in user management create a new user for you.
8. on your jailbroken iPhone with cydia, install "iphonesync" via cydia, start it up, enter your servers data (http://yourhostname:8080/funambol/ds) - and sync!
9. on your desktop box, install syncevolution, to configure do the following:
10. execute "syncevolution --configure --sync-property "username=123456" --sync-property "password=!@#ABcd1234" funambol". then open up ~/.config/syncevolution/funambol/config.ini and change the URI to the same as you used on your iPhone
11. sync using syncevolution -s <mode> funambol (<mode> can be one of the items seen in "syncevolution -s ?")

Happy Syncing!