An alternative to Xming: an X Window virtual appliance

sometimes Xming misbehave connecting to some machines, so i devised a way to use a real, native, X server on a windows desktop.

install VMware player and create a new VM with the following parameters:
NAT networking

i used Red Hat 5, but other linux distribution will do: just make sure you choose one that supports Unity (seamless integration of VM windows on the Windows host desktop).
install only the base X, and do not select any graphic desktop.

after base OS install, add the packages that are needed to support graphics connections:

yum install gnome-terminal
yum install *metacity*
yum install gnome-themes
yum install gnome-session

make sure VMware tools are installed by now
edit Xclients to make sure a terminal is spawned at startup

#vi /etc/X11/xinit/Xclients

change the bottom of the file to look like this:

# Argh! Nothing good is installed. Fall back to twm
    # gosh, neither fvwm95 nor fvwm2 is available;
    # fall back to failsafe settings
    [ -x /usr/bin/xsetroot ] && /usr/bin/xsetroot -solid '#222E45'

#    if [ -x /usr/bin/xclock ] ; then
#       /usr/bin/xclock -geometry 100x100-5+5 &
#    elif [ -x /usr/bin/xclock ] ; then
#       /usr/bin/xclock -geometry 100x100-5+5 &
#    fi
#    if [ -x /usr/bin/xterm ] ; then
#        /usr/bin/xterm -geometry 80x50-50+150 &
#    fi
#    if [ -x /usr/bin/firefox -a -f /usr/share/doc/HTML/index.html ]; then
#       /usr/bin/firefox /usr/share/doc/HTML/index.html &
#    fi
    if [ -x /usr/bin/metacity ] ; then
        /usr/bin/gnome-terminal &
        exec /usr/bin/metacity
    if [ -x /usr/bin/twm ] ; then
        exec /usr/bin/twm

add an unprivileged user

#useradd user

enable it to sudo


add this line at the end of file

user    ALL=(ALL)       NOPASSWD: ALL

set autologon to user

#vi /etc/gdm/custom.conf

in the [deamon] section add the following lines


now it's time to trim down the VM by stripping all the unneeded packages:

yum remove yum-updates ypbind wpa_supplicant wdaemon
yum erase xinetd yum-updatesd
yum erase vnc-server
yum erase openssh-server smart* sendmail*
yum erase system-config-*
yum erase nfs*
yum erase cyrus-sasl
yum erase rhnsd
yum erase readahead*
yum erase iputils
yum erase portmap pcsc* bluez*
yum erase anacron
yum erase atd
yum erase audit
yum erase cups
yum erase dnsmasq
yum erase iptables*
yum erase krb5*
yum erase krb5-wo*
yum erase mcstrans
yum erase ntp psacct
yum erase irda*

and switch off what we can't remove

chkconfig atd off
chkconfig avahi-daemon off
chkconfig avahi-dnsconfd off
chkconfig gpm off
chkconfig mcstrans off
chkconfig netfs off
chkconfig restorecond off

create a windows shortcut to start your VM in Unity mode like this:

put a "-U" before the pathname of your vmx file: that will cause the VM to startup in Unity mode.
Launching that shortcut will open a gnome terminal right on your desktop.
From there you can connect to other machines with

ssh -X l user remotehost

and then run any graphic application alongside other windows applications on your desktop.


Doom Architecture

An ex-colleague/ex-classmate of mine has coined the term "doom architecture" looking at real world places that seem to be designed with a game level editor.
I support his "pursuit of ugliness" with this evidence.
It might belong to the technogothic Quake 1 style.


How to unlock a VMDK file

while trying to power on an old VM i've got the following error message:

Unable to access file <unspecified filename> since it is locked

to investigate the issue i've looked and the vmware.log in the VM home folder and i've found the following error

Sep 07 10:18:24.260: vmx| Msg_Post: Error
Sep 07 10:18:24.260: vmx| [msg.disk.noBackEnd] Cannot open the disk '/vmfs/volumes/49b105df-0d080910-d97a-000423d87441/server/server.vmdk' or one of the snapshot disks it depends on.
Sep 07 10:18:24.260: vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file.----------------------------------------

it seemed that the vmdk file was locked, but i was pretty sure that no other VM was using it and no snapshots were active.
after a little googling i've found the following thread that shows how to identify who is locking a vmdk file.
unfortunately, on my host it gave the following output:

[root@esx server]# vmkfstools -D server-flat.vmdk
[root@esx server]# tail /var/log/vmkernel
Sep  7 17:48:42 esx vmkernel: 36:03:13:22.953 cpu4:1041)FS3: 130: <START server-flat.vmdk>
Sep  7 17:48:42 esx vmkernel: 36:03:13:22.953 cpu4:1041)Lock [type 10c00001 offset 17129472 v 99, hb offset 3367936
Sep  7 17:48:42 esx vmkernel: gen 150, mode 0, owner 00000000-00000000-0000-000000000000 mtime 1213998]
Sep  7 17:48:42 esx vmkernel: 36:03:13:22.953 cpu4:1041)Addr <4, 21, 20>, gen 21, links 1, type reg, flags 0x0, uid 0, gid 0, mode 100600
Sep  7 17:48:42 esx vmkernel: 36:03:13:22.953 cpu4:1041)len 13958643712, nb 6656 tbz 0, zla 3, bs 2097152
Sep  7 17:48:42 esx vmkernel: 36:03:13:22.953 cpu4:1041)FS3: 132: <END server-flat.vmdk>

owner 00000000-00000000-0000-000000000000 was of no use to identify the culprit.
that same datastore was visible to several others esx hosts, so i tried the same command from another host and i had more luck: that time a full UUID was returned as the owner.
i've followed the original thread instructions to identify the esx host that was owning the lock and i've restarted it after migrating off all the VMs.
the reboot removed the lock and i was able to turn on again the old VM.

lesson learned: if at first you don't succeed, try on another host


Keymap-independent passwords

On my job I have to remotely administer a lot of servers, using every kind of access method: VNC, rdp, avocent, vmware remote console, PC Anywhere, even one nested into another.
Every server might have a different keyboard, based on the country it's in.
Nested remote consoles and tools that gives access to the physical console of a server often misbehave the caps lock key.
Pair a faulty caps lock with an unknown keymap and a rigid lockout account policy and one more try to enter the correct password may result in a locked account.
Sometimes, even trying the password before in the clear-text username field is not an option, because of people that might see the console at the remote site.
So I've begun thinking about passwords that are unchanged between different keymaps.
Rules are:
1) you can't use keys that are different from one keymap to another
2) only lowercase letters, because the shift and caps lock keys can't be trusted

I've checked all the most used european keyboards (Italy, Germany, UK, Spain), plus the default US keyboard (here Wikipedia is our friend: http://en.wikipedia.org/wiki/Keyboard_layout)

The invariant keys are:

If you add the France keyboard to the mix, the list will be even shorter, as french people like to distinguish themselves:

But how much security do you give up by using keymap-independent passwords?
A commonly used policy of 8 chars password, using all the standard ASCII characters (32-126 for a total of 94) leads to 6.095689385×10¹⁵ different passwords.
Using the reduced charset of the non-french keyboard mix you have only 39 chars: to obtain a similar complexity you will have to use a 10 chars password, with 8.140406085×10¹⁵ different words.