windows


Due to better 64bit support, we decided to use VMWare instead of VirtualBox. To prevent of installing a gentoo to a VMWare image, I decided to convert the already working virtualbox image (a vdi file) to VMWare (vmdk). Qemu-img is the command line tool for this task, using the following line, I can get a vmdk:
qemu-img convert -O vmdk gentoo32.vdi gentoo32.vmdk
However, this vmdk is not recognized by VMWare 6.5. I guess it has something to do with the fact that the original vdi file is using dynamic sizing (the file contains a 5G partition, and it only has 1.9G data, so the real size for the vdi file is about 2.1G): the converted vmdk is 1.9G, and VMWare reports that it has 2.1G total size.When booting with this image, VMWare fails to read any data from the virtual disk. After tried another time with the above approach, which also failed, it seems I have to find another way. Luckily, VirtualBox comes with a command line tool called vboxmanage, which can do all sorts of operations on vdi files, including converting vdi to raw disk image, so let’s try that:
vboxmanage internalcommands converttoraw gentoo32.vdi gentoo32.raw
The above command will generate a 5G gentoo32.raw file. Then use qemu-img:
qemu-img convert -O vmdk gentoo32.raw gentoo32.vmdk
To convert the raw file to vmdk. The resulting vmdk file is also 1.9G, but this time VMWare recognize it just fine (reporting its real size as 5G). After changing the root device from /dev/sda1 to /dev/hda1, this image can boot just fine in VMWare, with one exception: the network interface eth0 can not be started. More inspecting reveals that “udev renames network interface eth0 to eth1″. This is caused by the fact that one of the default gentoo udev rule (/etc/udev/rules.d/75-persistent-net-generator.rules) will write another rule file which saves the MAC address for each NIC, and sure enough, the MAC address for the NIC in VirtualBox is different from that of VMWare. However, this is very easy to fix, once you know where the generated udev rule is: Open /etc/udev/rules.d/70-persistent-net.rules and remove all rules in this file, save and reboot, eth0 won’t be renamed to eth1 any more.

In order to support IE, which does not run reliably under linux with ie4linux, I have to stick with M$ windows when working on dojo. However, the experience with windows svn client was not pleasant: as svn+ssh protocol is used to access dojo repository (among other svn repositories I use), I had to input my password each and every time when I update/commit to it. What’s more annoying, when doing some operation, such as svn log, I am asked three times for password (or maybe twice?).

I had hoped the svn client I use, TortoiseSVN, could support Public Key Authentication for svn+ssh, just as what the svn linux client can do.

Today, I had a look at the documentation of TortoiseSVN and found out that it IS INDEED possible to configure TortoiseSVN to use Public Key Authentication. It was just my assumption, it has not implemented this support, prevented me from digging into it.

The key point is to understand this: TortoiseSVN makes use of putty behind the scenes (more specifically, it uses a derivate work of plink, a windows ssh command client). You can tell putty to login ssh with Public Key Authentication: just go to Connection -> SSH -> Auth, select the a private key file for the authentication. Under Connection -> Data, you may also fill in Auto-login username, so that you don’t need to specify the username every time you login.

If you do not already have a pair of your own private/public keys, then you may want to check out PuTTYgen and Using public keys for SSH authentication.

If you come from linux world, like me, and already have your own private/public keys, just import it with PuTTYgen and save the private key to a format putty recognize, then select this saved private key in the place mentioned before. You have to save the session under a name, such as dojo, in order to make it accessible to other ssh dependent applications, such as TortoiseSVN.

Don’t forget to add your public key to file ~/.ssh/authorized_keys in your subversion server.

After that, you should be able to ssh to your remote server without input your password. Next step is to tell TortoiseSVN to make use this Public Key Authentication. You don’t need to explicitly teach TortoiseSVN to use putty for ssh connection. All you need to do is in the checkout dialog of TortoiseSVN, instead of the normal host of the svn repository server, you just specify the session name (in this case, it is dojo). So instead of checking out dojo from this address:

svn+ssh://liucougar@svn.dojotoolkit.org/var/src/dojo/trunk

just use this:

svn+ssh://dojo/var/src/dojo/trunk

That’s all. TortoiseSVN can make use all the information you saved in that session for ssh connection, and you don’t need to type in password any more. That’s neat.

(As how TortoiseSVN knows about session saved in putty, here is my guess: putty stores all information of sessions in windows register, so that’s can be accessed by TortoiseSVN.)

One of my friends asked me to help install movie players in his computer so he can watch movies. The computer is his company’s, and some limitation is imposed. The most annoying one is that the property of local network connection is disabled! I never thought this is possible under windows XP. Anyway, as I need to copy some files over, so I have to setup the connection between my laptop and his. The workaround is to set my IP address to something in the same C sub net as his computer, such as 169.254.220.235.

(more…)