netzhure.de

Als ich bei Fefe einen Eintrag über das OpenSSL-Debakel bei Debian und dessen Auswirkungen gelesen habe, insbesondere der "Spaß" mit kompromittierten Keys, solange sie nicht abgelaufen sind und der passende Private Key berechnet wurde. Dazu kamen mir folgende Gedanken:

Wir haben das Problem, dass es bei SSL bzw X.509 zwar die Möglichkeit gibt, Zertifikate zurückzurufen, wobei diese Informationen dann über die so genannte "Revocation List" einsehbar ist, dieses Verfahren aber kaum eingesetzt wird. Außerdem bringt es prinzipbedingt das Problem mit sich, dass nur der negative Status eines Zertifikats überprüfbar ist, also ob es gesperrt wurde.

Dieses Problem sollte durch OCSP beseitigt werden, hier gibt es nun auch die (optionale) Möglichkeit auf die Abfrage hin ein Zertifikat eindeutig als gut auszuweisen. Nur kann ich mir weiterhin nicht vorstellen, wer freiwillig solche Server betreiben möchte. Die Last dürfte doch sehr hoch sein.

Aber so an sich haben wir eine einzige brauchbare, wirklich skalierende, verteilte Datenbank. Das Domain Name System. Es gibt zwar gewisse Latenzen durch das Caching, aber eine Lösung die mir mit ein paar Stunden zurückgerufene Keys anzeigt ist mir immer noch lieber als eine theoretisch existierende, aber nicht verwendete. Dazu müssten ein oder zwei neue Record-Typen eingeführt werden, und schon könnten der Fingerprint des aktuell gültigen und/oder der zurückgerufenen Schlüssel dort abgelegt werden. Mittels DNSSEC könnte die Authentizität dieser Angaben gesichert werden.

Disclaimer: Ich bin kein Experte was Kryptographie angeht, daher bitte ich bei Fehlern in meinen Gedanken um Rücksicht und entsprechende Kommentare

Da ich hier gerade auf einer Kiste (naja, eher mehr - ein ASUS M2N32WS mit 6x500GB SATA für ein schicken Fileserver) mich mit XEN und pciback rumschlage, und das ganze mit AMD64 nicht so ganz tut, wollte ich nun mal auf i386 zurückfallen. Aber idealerweise ohne irgendwelche Daten zu verlieren, und da /boot nicht im LVM liegt, brauche ich zumindest hier ein Backup. Den Debian-Installer habe ich schon per PXE gebootet, um mir das Brennen einer CD sowie den einbau eines passenden Laufwerks zu ersparen. Aber immer die Config ändern, jenachdem, was man booten möchte, saugt irgendwie. Also muss ein Bootmenü her, welches GRML sowie die Debian-Installer wahlweise startet. Und wenn innerhalb von 20s nichts ausgewählt wird, wird von Platte gebootet. Somit kann PXE in entsprechend gesicherten Umgebungen einfach angelassen werden, ohne dass es zu Probleme führt.

Was wir brauchen:

• Das GRML-ISO
• Das für das Release passende GRML-Netboot-Package
• Das AMD64-Netboot-tar
• Das i386-Netboot-tar
• Die syslinux-quellen

Nun geht es ans vorbereiten, natürlich als root ;)

# mkdir /srv/tftp/
# cd /srv/tftp/
# wget http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.51.tar.gz
# tar xvfz syslinux-3.51.tar.gz
# cp syslinux-3.51/com32/modules/menu.c32 .

syslinux brauchen wir nur für die menu.c32, welche den notwendigen Code zum darstellen des Menüs enthält. Nun geht es ans besorgen der Debian-Installer:

# wget http://ftp.debian.org/debian/dists/etch/main/installer-amd64/current/images/netboot/netboot.tar.gz
# tar xvfz netboot.tar.gz
# rm netboot.tar.gz
# wget http://ftp.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
# tar xvfz netboot.tar.gz
# rm netboot.tar.gz
# rm pxelinux.0
# rm pxelinux.cfg

Jetzt, wo die Installer für die beiden Architekturen da sind (beim entpacken über die Fehlermeldung von wegen bereits existierenden symlinks nicht stören lassen, die legen wir sowieso später selbst an!), fehlt eigentlich nurnoch GRML, bestehend aus dem Inhalt der CD und eimer speziellen Initrd für den Netzwerkboot

# mkdir grml
# wget ftp://ftp.uni-erlangen.de/pub/mirrors/grml/grml_1.0.iso
# mount -o loop grml_1.0.iso /mnt/tmp/
# cd grml
# cp -r /mnt/tmp/* .
# cd ..
# umount /mnt/tmp
# wget http://grml.org/terminalserver/grml_netboot_package_1.0.tar.bz2
# tar xvfj grml_netboot_package_1.0.tar.bz2
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/linux26 grml/boot/     
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/minirt26.gz grml/boot/
# cp tmp/terminalserver_grub.Ln6542/grml_netboot_package_grml/tftpboot/memtest grml/boot/

Ich habe von meinen Eltern zu Weihnachten einen schicken 16:10-TFT bekommen, welcher natürlich auch Digital angesteuert gehört. Und dann bitte auch in seiner nativen Auflösung von 1680x1050 Pixel. Aber genau das führte zu viel Kopfzerbrechen - der Xserver startete immer nur in 1280x1024 oder auch 1024x768 :/

Nun hatte ich zwar passende Einstellungen in der xorg.conf, aber diese haben keinen Effekt gehabt:

Section "Screen"        
        Identifier      "Default Screen"
        Device          "NV15"
        Monitor         "SyncMaster"
        DefaultDepth    16
        SubSection "Display"
                Depth           16
                Modes           "1680x1050" 
        EndSubSection                                                         
        SubSection "Display"
                Depth           24
                Modes           "1680x1050"
        EndSubSection
EndSection

Es fand sich auch keine brauchbare Fehlermeldung in der /var/log/Xorg.0.log – bis ich irgendwo den Parameter für das Debug-Level des Xservers fand: startx -- -logverbose 5 Nun hatte ich auch das erste mal eine brauchbare Aussage in der Logdatei, woran es denn liegt:

[...]
(--) NVIDIA(0): Connected display device(s) on GeForce FX 5200LE at
(--) NVIDIA(0):     PCI:1:0:0:
(--) NVIDIA(0):     Samsung SyncMaster (DFP-0)
(--) NVIDIA(0): Samsung SyncMaster (DFP-0): 135.0 MHz maximum pixel clock
[...]
(--) NVIDIA(0): Detailed Timings:
(--) NVIDIA(0):   1680 x 1050 @ 60 Hz
(--) NVIDIA(0):     Pixel Clock      : 146.25 MHz
[...]

Für diese Auflösung wird eine Pixelrate von über den 135Mhz, den die Grafikkarte maximal liefern kann, benötigt. Und somit muss es mich nicht wundern, dass es nicht tut. Aber damit gab ich mich nicht zufrieden...

Man nehme ein normales fernsteuerbares Flugzeug, dazu eine in zwei Achsen schwenkbare Kamera und ein Head Mounted Display mit einem Gyroskop. Das Flugzeug lässt sich nun ganz normal fliegen, aber man sieht über das HMD aus dem Flugzeug heraus, und die Kamera folgt sogar noch den Kopfbewegungen. Sehr nett :)

Gesehen bei The Raw Feed, weitere Infos im RC-Cam-Forum

Wie die Projektverantwortlichen bei Debian heute mitteilten, soll Ende dieses Jahres Etch aka Debian GNU/Linux 4.0 erscheinen. Bis dahin soll den Bugs in mehreren Bug Squashing Partys zuleibe gerückt werden. Debian 4.0 wird das erste stable-Release mit

• Xorg
• GCC 4
• Secure Apt (gpg-Signaturen etc)

sein, um nur ein paar Änderungen zu nennen. Ich bin gespannt wie sich die SELinux-Unterstützung zeigen wird, von der ich bis jetzt noch nicht viel gemerkt habe. Auf jeden Fall werden ich meine Server dann nicht auf testing belassen, sondern das neue Stable/etch (womit sie atm auch schon laufen) beibehalten.

Übrigens, wer sich schon immer gefragt hat wie das Debian-Team zu den Namen seiner Releases kommt: Das sind alles Namen von Figuren aus dem Film Toy Story. Sid nimmt hierbei allerdings eine Doppelrolle ein: Es ist einerseits der Name des bösen Jungen von nebenan, der immer das Spielzeug kaputtmacht, andererseits auch ein Akronym für "still in development".

Wer mal immer Wissen wollte, über wie viele Ecken sein GPG-Key meinen kennt:

your key id :

Und für die Leute die das ändern wollen habe ich immer ein paar Schnipsel mit meinem Fingerprint im Geldbeutel, sozusagen jederzeit Signaturwillig :)

Ich habe gestern und Heute im Betrieb damit verbracht, defekte HDDs von ganzen zu trennen. Dabei habe ich mir erlaubt, ein klanglich wunderschönes Exemplar zu öffnen und ein kleines Video davon zu drehen, welches ich an dieser Stelle präsentiere. Am besten lässt sich der Klang so ca bei 0:40 hören, eine bessere Qualität gab mein Handy leider nicht her. Die Scheibe sah danach mehr nach feinem Schmirgelpapier als nach Festplatte aus...