In my ongoing quest to get rid of unnecessary use of WinWord, I moved a two-page checklist into our internal wiki. Unfortunately I came across two problems while doing that:

1. HTML <li>s don't support big empty circles. They default to black bullets, and the CSS {"list-style-type: disc;} only creates tiny circles.

   Unicode to the rescue: \x25EF, also known as \N{LARGE CIRCLE} or ◯ makes a fine replacement. Two lines of CSS to fix your list:

   ul { list-style-type:none; }
   ul li:before { content: "\25EF"; }
   

2. No page breaks. The list was on two pages for a reason and I needed to keep it that way. That was easily fixed by inserting

   <br class="break" /> 
   

   and making the break with CSS:

   br.break { page-break-before: always; }
   

   My first attempt was to use a <hr> instead – but strangely enough it made Firefox print another empty page at the beginning when used inside our wiki.
   

Putting it all together for TWiki:

<!-- <pre> -->
<style type="text/css" media="all">
br.pagebreak { page-break-before: always; }
.patternTopic > ul { list-style-type:none; }
.patternTopic > ul > li:before { content: "\25EF"; }
</style>
<!-- </pre> -->

The .patternTopic makes it only apply within the article, and the > makes it only apply on the first level after that.

– Sec

Last time we discussed the block order of linux-mdraid.

How do you find out which block order your RAID has?

The simplest way requires a working RAID to test against. (Ray created a small (50MB) test-RAID for that). First we get the first few blocks from each raw disk:

for $disk in sda1 sdb1 sdc1 sdd1 ;do
  for $nr in 0 1 2 3 4;do
    dd if=/dev/$disk skip=$nr count=1 bs=16k of=B.$disk.$nr
  done
done
dd if=/dev/md0 bs=16k count=20 of=RAID

Note that this assumes your stripe-size is 16k. If you know it is different, change it, if not you will find out later and have to retry with an adjusted value.

Now try to match up the first block with the RAID contents like this:

cat B.sda1.0 | cmp - RAID

If the block matches, you will get:

cmp: EOF on stdin

If the block is the wrong one:

stdin RAID differ: char 1, line 1

If none of your first blocks (the files ending with .0) match, either your block-size is too big (try again with half the previous size) or your RAID prefixes the disks with some internal bookkeeping info (in that case you can try to start with later blocks)

Now try to match the next blocks by adding then one by one to the cat command line like this:

cat B.sda1.0 B.sdb1.0 | cmp - RAID

that way you will easily recover the block allocation order of your RAID.

For example our linux-mdraid starts like this:

cat B.sda1.0 B.sdb1.0 B.sdc1.0 B.sdd1.1 B.sda1.1 ...

After that, its only a two-line patch to raidextract to fix that – hope you know C ;-)

That concludes our intermission for today. Tomorrow we will see why all this work wasn't even necessary.

– Sec

We left our heroes yesterday with a broken RAID 5 due to read errors on multiple disks. (Read part I: here)

A great starting point is raidextract by Peter Benie which attempts to re-assemble a RAID5. His web-page on this tool also serves as a great overview in the inner workings of standard RAID 5.

The first problem we stumbled upon is the fact that it assumes a certain pattern of the Parity blocks. (All examples from here on assume 4 disks, since that is what we had. But of course that's all applicable to any number of disks)

Adapting the example from his page:

Our Linux-mdraid unfortunately didn't conform to this expectation. Not only does it start with parity on the last disk (which raidextract would support with --rotate), but it also moves the parity block 'backward' instead of 'forward'.

The correct allocation order looks like this:

A quick&dirty hack to raidextract to implement this order:

--- raidextract.c	2008-07-26 11:33:53.000000000 +0200
+++ raidextract-new.c	2010-06-28 13:49:54.000000000 +0200
@@ -316,8 +316,10 @@
 	int paritydisk=(stripe / (disks-1) + rotate) % disks;
 	int len=stripesize-offset;
 	int bytes;
+	int ndisk;
 	char *ptr;
 
+	ndisk=(disk-paritydisk+3)%disks;
 	if (!noparity && paritydisk <= disk) disk++;
 	if (len>raidlen) len=raidlen;
 	if (winoffset+len > datasize) len=datasize-winoffset;
@@ -337,7 +339,7 @@
 	raidstart+=len;
 	raidlen-=len;
 
-	ptr=window[disk][windowalt]+winoffset;
+	ptr=window[ndisk][windowalt]+winoffset;
 	while (len)
 	{
 		bytes=write(STDOUT_FILENO, ptr, len);

A run on an error-free test-RAID confirms this and extracted it correctly. Yay!

continued in part III, coming soon

– Sec

The Munich CCC fileserver uses (as many other servers) software RAID 5 amongst its disks. We all (should) know that RAIDs are no substitute for backups, which was reinforced by a recent problem we had. While RAID level 5 can recover gracefully from a single failed disk, it generally can't cope with multiple failed disks at the same time.

One of the problems with large harddisks is, that there may be yet undetected errors on it, just because you haven't attempted to read that part for quite some time. Now when you start a rebuild of a RAID5, these errors quickly pop due to the rebuild process needing to read all the data. This is the main reason why you should regularly run complete surface scans on your RAID arrays.

Almost all RAID implementations tend to mark a whole disk as failed as soon as it contains a single error. This becomes a problem as soon as you detect a second error on your currently degraded RAID you are just attempting to rebuild.

Fortunately there is still hope. If the errors on your failing disks occur on non-overlapping points of the array, you can recover a complete copy of your data by assembling just the right pieces. But unfortunately there appears to be no hardware or software RAID solution able to do that out of the box. So we're left to try this manually.

more on this saga in part II, coming soon…

– Sec

Huch, schon steht es vor der Tür – Das diesjährige FilmFest.

Dieses Jahr sinds doch wieder 24 Filme geworden, obwohl «Tod in Istanbul» leider schon ausverkauft war. Mit von der Partie sind diesmal 3 Mitternachtsfilme, das wird vermutlich ein wenig anstrengend, dieses Jahr %-)

Wenn jemand von euch in einen gleichen Film geht kann er sich ja melden ;-)

vollständige Liste...
posted at: 11:58 | Category: /misc | permanent link to this entry | 1 comment (trackback)

Für alle dies bisher nicht mitbekommen haben, die Kurzzusammenfassung:

Auf der Easterhegg gabs als Badge das Haserl. Fertig bestückt mit einer kleinen analogen Schaltung die die LEDs bei Dunkelheit leuchten lässt.

Mehr Text und Bilder hier...
posted at: 22:20 | Category: /tidbits | permanent link to this entry | 0 comments (trackback)

Danke zu freundlich, aber ich will wirklich nicht

So gings mir heute mit Ubuntu. Ich wollte einen sshd installieren, aber auch wirklich nur einen sshd, und kein X11. Ubuntu ist aber wohl leider der Meinung ein X11 gehört auf jedes System. apt-get install openssh-server sagt u.a.:

Was tun? Nach ein bisschen frickeln bin ich auf folgende, an sich recht einfache, Lösung gekommen:

Voilà. Kein Plattenplatz im chroot für nix verschwendet. Yay!

– Sec

Gerade diesen wunderbaren Zettel gesehen:

(Liebe Mitmenschen ...)

Ehrlich gesagt sieht das wirklich mehr nach Mülleimer aus, besonders von
leicht weiter weg:

(Mülleimer?)

– Sec

Wie sagt man so schön? Traue keiner Statistik die du nicht selber gefälscht hast.

Aus dem Tätigkeitsbericht 2008 der Wikimedia Deutschland. (Ja, genau die, die Kritik nicht vertragen.

Fällt euch was auf?

Neueintritte Wikimedia Deutschland 2004 bis 2008:

So macht man sich elegant mal eben doppelt so groß :-)

– Sec

The Greasemonkey-script to insert xkcds image title tags broke yet again. This time Randall Munroe added a link around the image which my script didn't expect. Seeing that the last breakage is over a year in the past, I think this is a good track record :-)

Without much further ado, here is the fixed version: xkcd-titles.v4.
– I hope it works for you :)

– Sec

(Oder auch: Hilfe, mein Echofon ist nicht mehr rechts :-)

Ich bin ja seit längerem Fan von echofon (also, damals als es noch Twitterfox hieß). Beim letzten Update/Neustart von Firefox war das Icon von Echofon nicht mehr rechts unten in der Ecke der Statuszeile sondern deutlich weiter links. Verdrängt von lauter anderen Extension-Icons (NoScript, Operator, HTML Validator, Greasemonkey, Firebug, FoxyProxy, CookieSafe, Ghostery, RefControl, Adblock Plus, NoSquint, Read It Later)

(Wann gründet eigentlich mal jemand die Selbsthilfegruppe anonymer Extension-Süchtiger?)

Naja, zumindest war das Icon nicht mehr rechts, was ich ja noch verschmerzen könnte, aber auch das Popup-Window war über dem Icon, und somit Mitten in der Seite.

Nun, was tut der findige Geek? Nachdem man die Position nicht konfigurieren kann, muss sie wohl an der Startreihenfolge der Add-Ons liegen. Also flugs mal Echofon ans ende der Liste gepackt, und siehe da, beim nächsten restart ist Echofon wieder brav am rechten Rand. Yay!

Nun einfach Echofon mit dem letzten Platz der Liste vertauschen. Nicht vergessen die Nummer am Anfang der Zeile anzupassen, und fertig.

– Sec

Grade geisterte durch die Medien das eine Liste mit 10000 hotmail Passwörtern aufgetaucht sei. Das hat mich als Sysadmin natürlich gleich interessiert.

10 Minuten, und einen Bittorrent-Client später hatte ich dann auch ein File:

Nun aber die Preisfrage weshalb mich das File interessiert hatte:

Was ist das häufigste Passwort in der Liste?

Mehr nach dem Weiterklick...
posted at: 19:26 | Category: /tidbits | permanent link to this entry | 1 comment (trackback)

Unter Ubuntu gibt es mittlerweile eine sogenannte Bildschirmlupe die man hervorragend aus Versehen aktivieren kann. In Wirklichkeit ist das aber keine Lupe, denn es wird einfach nur der gesamte Bildschirm um ca. Faktor 4 vergrößert. Verstellen kann man die Vergrößerung dann per Windows+Mausrad.

Wer das loswerden will, dem sei hier ein:

und/oder ein

empfohlen.

– Sec

Heute fast direkt vor der Arbeit auf dem Weg zum Mittagessen gesehen:

Klarmachen zum Ändern!
(48°7'44.64"N,11°35'38.61"E)

Yay! für Piratenwerbung. Ich hoffe sie hilft.
Wählen darf ich hier ja leider nicht.

– Sec

Gerade auf dem Weg zum Mittagessen auf dem Boden entdeckt:

(Graffiti, 48°7'44.76"N,11°35'37.70"E)

Bizarr. Erinnert mich spontan irgendwie an Planet Unicorn. :-)

– Sec