Der Anti-Hype

Juhuu, KDE 4.0 ist draussen. Ich persönlich bin ja ein KDE-Fan und überlege gerade ob ich nicht mal eine Testversion davon laden soll und ausprobieren. Optisch ist das ganze allerdings meiner Meinung nach noch nicht so der Hit. Golem hat einige Bilder im Artikel. Okay, die größten Änderungen sind unter der Haube geschehen. Bis das ganze eine Augenweide ist werde ich dann wohl noch bis KDE 4.1 warten müssen. Ich mag ja auch optisch schicke Desktops, auch Effekten bin ich net abgeneigt, ganz im Gegenteil, so lange sie die Oberfläche nicht verzögern.

Auf meinem Server hatte ich plötzlich das Problem, dass der SVN-Server hing. Nach einigem Suchen viel mir auf, dass es an /dev/random lag von dem SVN Zufallszahlen besorgen wollte. Und warum lieferte /dev/random keine? Nun, /dev/random soll im Gegensatz zu /dev/urandom sichere Zufallszahlen liefern. Die dafür nötige Entropie sammelt es scheinbar von Mausaktionen und Tastatureingaben oder auch Festplattenaktivität. Nun, da an dem Server weder eine Maus noch eine Tastatur hängen gab es nicht viel zu fresse für /dev/random und auch die Festplatte hat nicht laufend was zu tun.

Nachschauen wieviel Entropie vorliegt konnte ich mit:

$ cat /proc/sys/kernel/random/entropy_avail
156

Nach ein paar Checkouts über SVN konnte ich feststellen, dass nach kurzer Zeit kaum noch Entropie vorhanden war und SVN blockierte und auf weitere Entropie wartete.

Als kurzen Workaround hab ich dann /dev/random verschoben und einen Verweis auf /dev/urandom angelegt.

$ cd /dev
$ mv random random.bak
$ ln -s /dev/urandom /dev/random

Problematisch nun allerdings, dass alle Anwendungen, die sichere Zufallszahlen benötigen greifen jetzt auf /dev/urandom zu, welches zwar immer Zufallszahlen hergibt und nicht blockiert, aber nicht unbedingt die sichersten. Dazu der Eintrag aus der man-Page:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

Mein Workaround war also nicht so sehr hilfreich, statt dessen müsste irgendwie /dev/random mit Entropie gefüllt werden. Nach ein wenig Suchen fand ich dann rng. Ein kurzer Auszug aus der man-Page:

rngd - Check and feed random data from hardware device to kernel random device
[..]
This daemon feeds data from a random number generator to the kernel's random number entropy pool, after first checking the data to ensure that it is properly random.

Okay, rngd soll nun also mein /dev/random mit Entropie versorgen. Also den Workaround wieder rückgängig machen:

$ rm -rf random
$ mv random.bak random

So, und jetzt rng besorgen, mit emerge (Gentoo) und dann starten:

$ emerge -av rng-tools
[..]
$ /etc/init.d/rngd start
[..]

Und nun besorgt rngd genügend Entropie. Zum testen hab ich mir dann ein wenig die vorhandene Entropie angeschaut und parallel ein paar mal mit SVN einen checkout gemacht.

$ watch "cat /proc/sys/kernel/random/entropy_avail"

Ja, und es funktioniert - es gab Entropie genug und keine Hänger mehr.

Kann sein, dass der Blogeintrag ziemlich öde ist, aber vielleicht hilfts ja wem

P.S: Wer einmal kurzzeitig etwas Entropie benötigt und nicht auf rngd zurückgreifen kann, der kann ja mal ein wenig seine Festplatte durchstarten lassen, z.B. mit "du": 

$ cat /proc/sys/kernel/random/entropy_avail
3603
$ du /
[..]
$ cat /proc/sys/kernel/random/entropy_avail
4032