VMWare Workstation split (multiple) to monolithic (single) virtual machine disk (vmdk)

While evaluating BackupChain a requirement was to convert a VM from a multiple (or "split") disk configuration to a single (or "monolithic") disk configuration.  (This is because certain features of BackupChain currently - and unfortunately - only work with single vmdks).

VMWare's Virtual Disk Manager was all I needed, after stopping the VM:

"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r Orignal.vmdk -t 0 NewSingle.vmdk

I then removed the Orignal.vmdk and it's associated Orignial-s###.vmdk files and renamed NewSingle.vmdk to Original.vmdk.  The VM fired up perfectly in the new configuration.


References

Virtual Disk Manager User Guide
Split vs. Monolithic Virtual Disks

Virgin Mobile Broadband (Australia) and VPN (PPTP)

A word of warning: Virgin Australia Mobile Broadband does not support VPN (PPTP), which you may find a little inconvenient if you decided to do something desperately radical, like say, work from home!

I tried to ascertain the reasons for this, but their technical support were unable to clarify anything other that it's not supported.  Apparently it might work sometimes, but it has never worked for me.  I suspect the GRE protocol (used for the data channel) causes the problems as the establishment sequence seems fine right up to and including verifying username and password (suggests TCP control channel to port 1723 ok).

A brief web search found others with the same problem.  Pretty fundamental if you ask me, and a bit embarrassing for them that it seems to work ok on Telstra Mobile Broadband.

And it looks like the usual SSH/Port Forwarding solution is not going to work as reports say GRE not supported.  Even if it did you probably don't want to be encrypting twice.

References

Which ports to unblock for vpn traffic to pass through
VPN issues with Virgin Broadband
Is it possible to tunnel PPTP over SSH?

DuckDuckGo

At last... an alternative to Google?

bitcoin - an update

First mentioned Bitcoin just over 2 years ago.  It had just reached parity with USD.  Well, it's been an interesting year for Bitcoin - it peaked at about 220 USD in April and then crashed spectacularly, but it's currently mounting a bit of a comeback.

Guess it's a great example of creating a limited commodity.  It has even less intrinsic worth than gold, but give people a limited resource and talk it up and it all goes nuts.  But do we really want to use Bitcoin as a store of wealth/for speculation, rather than a living, breathing currency?!

Personally, I welcome digital currencies and especially those that cannot be controlled (i.e. manipulated by politicians trying to win votes / dig themselves out of a mess).  However, some say Bitcoin, by nature is deflationary (people won't spend if it's going to be worth more in future), so perhaps we need Bitcoin v2.0: a system which is not limited to some some arbitrary number (in Bitcoin's case 21 million) - we need a system that will continue to mine coins at a set rate ad infinitum thus creating something more akin to the inflation we're used to.

Anyway I'm off to dig out the high school economics books, it was this forum article that got us thinking about it all.

Java and trusting self-signed SSL certificates

Self-signed SSL certificates crop up regularly in internal environments, and can result in your Java application complaining.

For example, say a Maven build attempts to download jar files from a server with a self-signed certificate.  You may get an error similar to:

peer not authenticated

The problem is you need to let the application know it can trust this server.

The JSSE Reference Guide states the following steps will be tried to find trust material:

1. A file defined by the javax.net.ssl.trustStore system property
2. The <java-home>/jre/lib/security/jssecacerts file
3. The <java-home>/jre/lib/security/cacerts file

Note if the file is found in any step, that file is used and no more steps are applied.  Note further that if the trustStore property is set, but the file does not exist an empty file will be assumed.

I generally add the self-signed certificate to the jssecacerts file (default password is "changeit").  If this file does not exist you can create it with a copy of cacerts, or simply run the command below and it will create the file (and you will be prompted to enter a new password). 

A simple way to get hold of the certificate is to navigate to the site in your browser and then store the certificate in x509 format (in Firefox: click on padlock next to the URL and press "More Information", "View Certificate", "Details" tab, "Export".  Save as x509(PEM))

To add this certificate to your truststore, type the following command:

keytool -importcert -file <file> -alias <alias> -keystore %JAVA_HOME%/lib/security/jssecacerts 

And finally a quick sanity check of the truststore:

keytool -list -alias <alias> -keystore %JAVA_HOME%/lib/security/jssecacerts