Artikel mit Tag gnome
Verwandte Tags
Dauerhafte Einträge
Gnome, Seepferdchen und Schlüssel
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...
Gemeine Sache, die einen viele Nerven kosten kann...
Geschrieben von Sven Grounsell
in Technisches
am
Samstag, 26. Dezember 2009 13:55
| Kommentare (0)
| Trackbacks (0)
Tags für diesen Artikel: administration
, bug
, dokumentation
, gnome
, inkompatibel
, lösung
, netzwerk
, seahorse
, server
, sicherheit
, software
, ssh
, technisches
, verschlüsselung
| Top Exits (0)
Gnome, TighVNC und Keymaps
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
(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:
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.
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.
Geschrieben von Sven Grounsell
in Technisches
am
Donnerstag, 22. November 2007 22:28
| Kommentare (0)
| Trackbacks (0)
Tags für diesen Artikel: administration
, austricksen
, bearbeiten
, beteiligung
, bug
, gnome
, gnome-session
, grotesk
, inkompatibel
, keyboard
, keymap
, kommentare
, layout
, loadkeys
, lösung
, netzwerk
, problem
, rechner
, server
, software
, technisches
, tightvnc
, treiber
, verwirrung
, vnc
, übersetzung
| Top Exits (0)
(Seite 1 von 1, insgesamt 2 Einträge)

Die letzten 5 Kommentare