Raes Blog

Wenn Seahorse sich weigert, den privaten SSH-Key zu laden, obwohl er unter ~/.ssh/id_dsa oder id_rsa liegt und laut Dokumentation automatisch geladen werden sollte, und auch ein Import fehlschlägt mit der Meldung, der Schlüssel läge im falschen Format vor, dann liegt das vielleicht daran, dass der öffentliche Schlüssel nicht auch dort liegt oder falsch benannt ist.

Gemeine Sache, die einen viele Nerven kosten kann...

Jaja, lange nichts mehr gepostet, nix los hier, tote Hose etc. pp...

Ich weiß. ich weiß. Dafür gibt es jetzt einen kleinen technischen Leckerbissen, der dem Ein oder Anderen weiterhelfen mag, der ähnlich verzweifelt Suchmaschinen gequält hat wie ich zu dem Thema.

Ausgangssituation:
2 Rechner, beide mit funktionsfähigem und ordentlich konfiguriertem Betriebssystem drauf; der eine soll auf den anderen per VNC zugreifen können und in diesem VNC einen benutzbaren Gnome-Desktop vorfinden. Soweit kein großes Ding und relativ alltäglich.

Problem:
Der Gnome-Desktop im VNC ist nicht bedienbar, da aus irgendeinem Grund das Keymapping nicht funktioniert. qwertz ergibt beispielsweise c.gvn*, was von vornherein die Vermutung ausschließt, dass es sich lediglich um ein exotisches Layout handelt, das aus irgendeinem Grunde vorkonfiguriert wäre.

Einfach über das Control Center eine andere Keymap laden hat nicht funktioniert; genausowenig wie der Lösungsversuch, einfach aus einem Xterm heraus per loadkeys dem System eine andere Keymap unterzuschieben. Die esoterische Fehlermeldung dazu lautete

$ loadkeys de-latin1-nodeadkeys
Loading /usr/share/keymaps/i386/qwertz/de-latin1-nodeadkeys.map.gz
Couldnt get a file descriptor referring to the console

(Warum auch immer), brachte mich also der Lösung nicht wirklich näher.

Nach ausgiebigem Suchmaschinenquälen brachte mich dieser Link unverhofft näher an mein Ziel. Genauer war es folgender Kommentar zu diesem Bug:

I have the same problem described in "bug description". On 7.04, I can start a vnc server (tightvnc), and the keyboard is fine until I type "gnome-session", after which point it's remapped as described.

If instead, I run:
gnome-wm &
gnome-panel &
nautilus --no-default-window &
gnome-cups-icon &
gnome-volume-manager &

it seems to give me most of gnome, minus the inconvenient keyboard remapping.

Workaround: I modified my ~/.vnc/xstartup to be:

#!/bin/sh

xrdb $HOME/.Xresources
gnome-wm &
gnome-panel &
nautilus --no-default-window &
gnome-cups-icon &
gnome-volume-manager &
xterm &

Und ja, nachdem ich zwar an sich die Gnome-Umgebung gestartet hatte, aber den Aufruf von gnome-session verhinderte, konnte ich zumindest das halbwegs brauchbare US-Keyboardlayout laden - Was für die meisten Admins und längerjährigen Nutzer keine große Hürde darstellen sollte.

So ganz zufrieden bin ich damit nicht, da ich schon gern eine frei wählbare Keymap laden können möchte, aber es ist eine benutzbare Interimslösung. Falls jemand also in dieser Richtung eine Idee hat, sei er hiermit aufgerufen, mich/uns daran teilhaben zu lassen.

...ach keine Ahnung wievielte.

Jedenfalls enttäuschen die Jungs mich nicht und entsprechen der Analogie zum Horrorstreifen erneut, indem sie eine weitere, noch schlechtere und geschmacklose Fortsetzung bringen:

vanager.com [Support] an support
31. Jul.
Sehr geehrter Vanager-Kunde,

wir führen in der Nacht vom 01. auf den 02.08.2007 ein Neustart auf Hostsystem 35 durch. Dadurch werden Ihre virtuellen Server auf diesem Hostsystem circa für 15 Minuten nicht erreichbar sein; der Update-Vorgang beginnt um 1 Uhr morgens am 02.08.2007.

Vielen Dank für Ihr Verständnis.

Sagt mal, Jungs - Was zur Hölle wollt Ihr denn von mir?

Selbst aus Scientology, den Zeugen Jehovas, oder der Nazi-Szene kann man anscheinend leichter aussteigen als bei Euch.

Im Übrigen: Wo bleibt denn nun Euer Anwalt? Meiner ist schon ganz traurig, da er den versprochenen Fall immer noch nicht bekommen hat...

Normalerweise kenne ich es so, dass Tierarten auf eine Liste geschrieben werden und damit fortan als bedroht gelten. Wie so oft ist in der IT-Welt jedoch irgendwie alles anders als in der richtigen Welt. Da haben leute eine Liste mit Käfern^WBugs gemacht und nun sind nicht diese Bugs bedroht, sondern ein Prozessor - genauer die aktuelle Core 2 Prozessorgeneration von Intel.

Bei meinen Recherchen ob dieses merkwürdigen Phänomens stieß ich auf diesen Artikel bei Slashdot, wohl einer der führenden Nachrichtenticker der Branche. Da wird auf ein Posting von Theo de Raadt auf der openbsd-misc-Liste verwiesen, der ein paar der signifikanteren Punkte dieser Liste herausstellt (hier ist das Ganze nochmal etwas allgemeinverständlicher aufgearbeitet).

OK, zum Ernst der Sache. Das ist natürlich ein ganz schöner Hammer. Nachdenklich stimmt, dass laut de Raadt (seineszeichens OpenBSD-Gründer) einige dieser Bugs mit hoher Wahrscheinlichkeit sogar von Code im Userland ausgenutzt werden können, ohne dass ein softwareseitiger oder anders gearteter Codefix das verhindern könnte.

Nun bringt sogar schon die Hardware Sicherheitslücken ins System. Und das ausgerechnet auch mit dem gehypeten Sicherheitsfeature des Non-Executive-Bits, das unter Umständen einfach mal ignoriert wird.

Ausgerechnet jetzt, wo Intel sein zurückgewonnenes Performance-Oberwasser im Desktop- und Endkundenbereich feiert und der Core 2 allenthalben ob seiner Leistung und Sparsamkeit gelobt wird.

Fairerweiser bemerkt de Raadt, dass bei AMD die Situation in Bezug auf verbuggte Prozessoren kaum besser aussieht.