I have a problem with the keyboard mapping in virtualbox guests. 

A number of keys show no action at all or turn out wrong symbols and changing the keyboard layout settings in the guest does not fix it.
Both the host and the guest run in 64 Bit.
The problem occurrs both in windows and linux guests.
On the host I tried Debian 7 with XFCE, Trinity and LXDE and I checked both the virtualbox 4.1 that comes with the distro as well as the current 4.2 installed from the wheezy backports.
I started all new then, with centos 6.4, Gnome desktop. Same issue appeared with virtualbox 4.2 installed from the virtualbox.repo
This is on a remote server which I access through vnc (tightvnc on debian and tigervnc on centos, local client is KRDC)
 
I have a German keyboard layout but I prefer to have the box run in English.
 
On centos 
cat /etc/sysconfig/keyboard
 
KEYTABLE="de"
MODEL="pc105"
LAYOUT="de"
KEYBOARDTYPE="pc"
 
LANG=en_US.UTF-8
 
All is well accessing the machine via ssh, yz at the right places, umlauts and all the symbols at the right place and available. 
All is well still accessing the host through vnc. I open Gedit and doing the same tests as above there is no problem.
In the guest however testing with a linux mint live cd, while zy still have the correct place some keys show no activity, including the key right of the P (udiaeresis Udiaeresis) and the keys right of L that should give odiaeresis and adiaeresis. The key to the left of the 1 and the key to the right of the 0 show no action. 
Other keys including the shift values of 3,7,0 and the symbol-keys on the right side have wrong output.
 
On the linux mint guest I checked the key codes with xev and those keys that show no activity apparently do not evoke a key event when hit. I can type üöäß as long as I want in the guest and xev wont output a single line.
 
Going back to the linux host xev running there outputs:
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158645, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XmbLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158781, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171357, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XmbLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171481, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13174995, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XmbLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13175522, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13179885, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XmbLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13180045, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
=================================
 
So I got it working in the end. There was a bug discussion on virtualbox with helpful info about the way virtualbox handles keyboard input:

I will quickly sumarise how we handle keyboard translation on X11 hosts. In fact we have two algorithms for doing this. The first one, which is the preferred one, is to try to determine whether one of the two standard X.Org PC mappings is in use (kbd or evdev). We do this by checking the keycodes of certain keys that are not likely to vary - like the left side modifier keys, tab, the first eight function keys - and seeing if they match one of the well-known mappings (and we do check for swapped ctrl and caps lock). If they do, we use that mapping, but certain custom keyboard layouts, like Neo and probably like your Dvorak layout, defeat this.

The second algorithm originally came from Wine, although a lot of work has gone into it since then. It works by reading the symbols attached to each keycode and comparing them to standard national layouts, and working back from there to the keyboard mapping. This is needed in particular for Sunray and I believe for X over ssh and VNC (although I should probably add Sunray to the standard layouts).

So this confirmed my suspicion that virtualbox performed some weird voodoo based on what it sees as the keyboard settings. And while all looked well judging from typing on the machine, both in a ssh shell or via vnc and X, I found rather strange tables with Xmodmap -pke . 
I created a valid xmodmap on my desktop box, shortened it to only contain those keys I actually need and use and put that into a file on the remote machine. 
I edited the ~/.vnc/xstartup script of the user who runs the vnc server to include the line 
xmodmap custom-modmap
at the top. And that made the difference.

I will not pretend to understand how things actually work together, my desktop, the remote machine, the xmodmap all use and are set to a German keyboard and still virtualBox now starts and presents an English keyboard to the guest machines. But this is something the guests are happy to remap to German and at least each keypress results in a key event now.

Notizblock encryption

Saturday, August 24. 2013

Paar Verweise, die ich letzlich sah und die ich eben mal zugänglich festhalten will.

Ein einsichtsvoller und wohlinformierter Artikel der New York Times über eine berliner Filmemacherin, einen brasilianischen Journalisten und einen SysAd aus Hawai.  

Register mit einer Aufstellung von Ratschlägen, wie man Briefe un-mit-gelesen einem Empfänger übermitteln kann.

Und hier ein Tip, wie man Katzenbilder aus dem Net noch etwas aufwerten kann

Ein gpg-howto und noch ein weiteres 

 

 I used to store my calendars, contacts, tasks at Google and sync them from there to my android phone and thunderbird/lightning on different machines running linux or win*. For a number of reasons I decided to deGoogle my data habbits and have migrated to an ownCloud server.

Google contact has a rather easy to use way of grouping contacts, actually it's more like tagging the contacts to belong to a group. Android supports those groups out of the box. Thunderbird, with the help of an addon, syncs those contacts and automagically has a mail list for each of the groups defined in Google contacts. Ease of use and clarity for data handling, each contact has the info about which mail distribution list will apply directly as a property with itself. I like that.

OwnCloud, at least with the last few versions of it's 5er, does it more or less as well as Google does. The interface may not be that refined and handy, but the structures and functionality is there, which I appreciate a lot. 
Syncing to android requires 2 apps (cardDav-sync and calDAV-sync) costing few € each and then everything works nicely like it ever did. Fun.

Syncing to Thunderbird's addressbook needs an addon which, unfortunately, is crippled in the way it handles mail lists. Categories are synced and recognized, I can even edit them conveniently. But there is no automatic and no decent manual way to build a mail list based on the categories of the synced contacts. There is a modal window that expects me to type email addresse in order to add them to the list. Type. No filter select, or at least drag and drop. Type. 

This is the moment that I start to check Kontact again. Not the first time, KDE on arch is my main desktop for a year and it was KDE on debian before (less fun). 
Connecting Kontact to ownCloud is very easy, actually comfortable. Syncing the contacts works smooth and fast, including the contact photos. KAddressbook shows me a flat list of names but there is a context menue which allows me to add fields for display and sorting. My pet property, Categories, is not included though.

Double click on a contact entry opens a editor dialog with a field for the categories, comfortable to select from a list of all existing values, if I decide to create a new one it is synced to ownCloud minutes later. Very nice indeed.

But try to create a group and populate it and there is a time tunnel back into the computational stone ages! There is a New Group dialog which is modal and no drag & drop is possible. Select a number of contacts, New Group -> the very same dialog, no 'selection awareness' and adding the selected entries to the new group. No!
The dialog expects me to type the name, at least offering an input-aware selection as I start to type. Seriously no fun!

So:
- is there any known way to automatically sync groups according to category settings?
- or at least, any known way to populate groups via drag&drop of selected entries?
- or, at the very least, any docu, examples, helpful sites on how to get and set the relevant data, methods etc to script my own way with qdbus-qt4 ?
I can 
qdbus-qt4 org.kde.kaddressbook /kaddressbook/MainWindow_1 org.kde.KMainWindow.activateAction akonadi_contact_group_create 
but i just opens the modal editor window and thus gets me nowhere.

 groklaw.net ist beendet.  Slashdot dazu. heise

 

jahrelang habe ich praktisch jeden Tag bei groklaw reingeschaut,
 
mitgelesen und verfolgt wie sie standhaft, fleissig engagiert zusammentrug, analysierte, koordinierte und eine kleine Heerschar Recherche-Ninjas in einem Feldzug für freie Software anführte. 
Das rote Kleid, von PJ einmal in einem Nebensatz scherzhaft für den Tag des erfolgreichen Prozessausgangs angekündigt, ist dann mit diesem Cartoon quasi ihr offizielles Bild geworden, -
 
und mit dem Bild hier noch mal meinen Dank und meine Bewunderung für diese tapfere Frau und was sie zu bewegen vermochte.
 
(pj im roten Kleid)

Das andere, wirklich Bittere: wie wir diese Texte jetzt zu lesen lernen. Texte, von denen wir wissen (oder uns denken müssen), dass sie unter einer gag order verfasst wurden, Texte, die die Zwangsumstände, unter denen sie verfasst werden, nicht benennen dürfen. Wie man die Einbruchsgeschichte als Metapher der konkreten Vorgeschichte der Seiteneinstellung lesen kann, wie womöglich die zentrale Aussage ihres Textes die ist, die nicht darin steht: es steht nicht darin, dass sie keinen national security letter  bekommen hat. Und das würde sie doch geschrieben haben, wenn es so wäre und sie doch weiss, dass jeder nun sowas vermutet...
- die reine Kreml-Astrologie. Sklavensprache.  Wir üben uns in den
Kommunikationsstrategien, wie sie seinerzeit im Ostblock üblich
waren. Damals, als es noch eine Konkurrenz der Systeme gab, als sie
sich hier noch mit Freiheitlichkeit profilierten. 
 
Bitter. Drei Jahre einer Regierung habe ich erlebt, die mit der
Losung "Mehr Demokratie wagen!" angetreten ist (und quasi mit einer
Notbremsung gestoppt wurde, von den Geheimdiensten). 
Und seither: 
40 Jahre Zurückrudern. Sicherheitsgesetze. Brot und Spiele und 
'Den Gürtel enger schnallen'.
 
- ein paar Etappensiege, ein paar Themen haben wir placiert - aber im
Grossen und Ganzen ist es voll in die andere Richtung gegangen.
 
Und unsere Regierung, die das Thema jetzt für erledigt erklärt hat,
weil die Dienste doch versichert haben, sich immer an die Gesetze zu
halten. 
 
Denken die denn wir wären so blöd... 
                                                                 - naja, sie haben schon das
Gefühl, so fest im Sattel zu sitzen, dass sie in aller Öffentlichkeit
eine Regieanweisung an die PropaHHHH^H Multiplikatorengeben
können. Aber in der Hauptsache sind sie wahrscheinlich sogar ehrlich,
es ist alles von Gesetzen/Abkommen/etc gedeckt. 
Nur, Kreml-Astrologie!, die wahre Rechtslage dürfen sie uns nicht
erzählen.
 
 
 
Welche Geheimabkommen, Geheimgesetze, formalisierten
Gewohnheitsrechte der vormaligen Siegermächte sind da derzeit aktiv
und nicht im Gespräch? Das wäre doch mal ein Thema für einen
Wahlkampf. Aber die, die was wissen, sind alle unter Schweigepflicht. 
 
Wie Pamela.
 

 

Passworte in /etc/shadow

Monday, August 19. 2013

 Ich bekam doch einen Schreck, als ich auf einem Rechner, der seit sarge oder so immer debian-stable hatte, bei einer Kontrolle darauf stiess, dass die Passworte in /etc/shadow nur mit md5 gehasht wurden. 
Der Sache nachgehend fand ich einen Thread in den Debian-User Foren, der dank eines hartnäckig nachfragenden Users eine recht erhellende Diskussion zum Thema hat. 

Bei einem Eintrag in shadows der Form:

webdb8_usr:$1$Ksmg|oP`$9S1FToADihC6K4o2cifd50:15672:0:99999:7:::
steht $1 für den Hash-algorithmus md5, zwischen den beiden nächsten $ stehen 8 Zeichen salt und dem folgt dann das Hash.
$5 wäre SHA-256 und $6 SHA-512
 
Die relevante config dazu fand sich in /etc/pam.d/common-password
Hier fand ich:
password   required   pam_unix.so nullok obscure min=4 max=16 md5
ich habe es ersetzt bzw ergaenzt durch
password   required   pam_unix.so nullok obscure min=8  sha512 rounds=65519 
 
nun ist die entsprechende Zeile in der Shadow auch deutlich länger....
 
Das abschliessende rounds=65519 sorgt dafür, dass das Passwort nicht einfach einmal gehasht wird, sondern das Ergebnis ein weiteres Mal, und dann wieder und wieder - 65519 mal hintereinander. Das hat hauptsaechlich den Nutzen, eine Weile zu dauern, immer noch zu kurz, um bei einer aktuellen Passworteingabe aufzufallen, aber lang genug, um brute force Passwortknackern lästig zu fallen.
(Page 1 of 3, totaling 11 entries) » next page