We have seen Android running on the T-Mobile G1 and very soon we will see Android on the HTC Magic (by Vodafone). But… did you know that you do not necessarily need a new mobile to run the Android OS? Due to its open source nature, the Android stack is available for everyone to tinker with, and tinkering they did. At the moment ports exist for the following phones (note: these are the ports that I’m aware of)
But also for our beloved mobile, the HTC Touch Diamond a port exists. It is not yet fully functional, as a few important areas are still missing, including power-management, sound and WIFI/Cellular data. But call management, SMS and the rest of the functionality of the Diamond works just as it should.
Detailed instructions for installation can be found on Connect-UTB, an enthusiast-run site, but it is as simple as downloading a zip-file and extracting it to a directory /tmp on the Internal Storage. Before running it, you should disable your PIN-code of your SIM, as the current port is not able to handle entry of the PIN-code after starting. Then it is just a matter of running haret.exe and having some patience. The first boot can take up to 2 hours.
Progress on this port can be followed here, or at the following pages:
let me know if it works for you!
As I already listed in the first post of this duet, I want to integrate my Eclipse installation with a 3rd-party managed configuration management environment. The first part of this post dealt with the integration of subversion, but now I want to integrate Mylyn with the Trac-environment that is part of the CMaaS providers offering.
This all starts with entering a new task repository in the “SVN Repository Exploring” perspective:
I selected the Trac repository type and clicked Next:
However, clicking ‘Validate Settings’ yields an error:
Uhoh…. The Mylyn FAQ indicates that this is caused by a missing certificate in the Eclipse keystore. It suggests executing the following command on a commandline:
keytool -import -keystore /path/to/.eclipsekeystore -file /tmp/certificate.pem
This would import the certificate into the keystore. Unfortunately, my certificate is in PKCS#12 format and not in PEM format which is required by the Java JDK keytool. Thus, keytool complains with an error: “keytool error: java.lang.Exception: Input not an X.509 certificate“.
We will need a way to convert the PKCS#12 certificate into a PEM certificate. This is best done using OpenSSL. A download for Windows XP can be found here. After downloading and installing OpenSSL, I executed the following commands on the commandline:
openssl pkcs12 -in cert.P12 -out userkey.pem -nocerts
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
openssl pkcs12 -in cert.P12 -out usercert.pem -nokeys -clcerts
Enter Import Password:
MAC verified OK
Now we have an almost usable certificate and a separate key. The openssl command includes a pre-amble in the certificate that keytools will complain about. Open userkey.pem in an editor and remove everything above the “—–BEGIN CERTIFICATE—–” line. After re-running keytool, the following output appeared:
keytool -import -keystore <path_to_eclipse_keystore>\.eclipsekeystore -file usercert.pem
Enter keystore password:
Re-enter new password:
< skipped output to protect the innocent >
Trust this certificate? [no]: yes
Certificate was added to keystore
Now the keystore is created and we can add it to eclipse by including the following lines in eclipse.ini:
-Djavax.net.ssl.keyStore=\path\to\.eclipsekeystore
-Djavax.net.ssl.keyStorePassword=123456
But what do you know… It still doesn’t work and the error shown below presents itself…
I found a bug in the Eclipse bugzilla that seems to refer to the exact same problem, therefore I think that this little quest is halted till this issue is solved. I’ll post updates when there are new developments.
OK, so here’s the deal: the company I work for uses a ConfigurationManagement-as-a-Service provider to handle configuration management for all internal projects. The provider itself is actually a subsidiary of the company but in the end this doesn’t matter much. For CM they use Trac and Subversion. Which is great. As a proper service provider, all CM configurations for customers are highly secured which is achieved in part by the use of client-certificates for both SVN and Trac. Getting Eclipse integrated with services listed as such was not as easy as it seemed. I’ve split my efforts into two posts: this one deals with subversion whereas the next one will deal with Trac.
First, the setup that I tried to make work:
- Eclipse 3.3.1 (Europa release)
- Mylyn 3.3.1 (Europa release)
- Trac 0.10.3
- Subversion (version unknown)
Everything will be running under Windows XP SP2.
First: Subversion
Integrating Subversion was supposedly as easy as installing Subclipse. This is done via a an update site, the installation instructions can be found here. After this, you can switch to the SVN Repository Exploring perspective. There I clicked ‘Add SVN Repository’ and filled in the URL. This is where the problems start. Subclipse (or at least the libraries it uses to handle SVN) does not ask for a client-certificate by default and connection to the repository fails. A little googling pointed me to the following page that stated that Subclipse requires a setting named ssl-client-cert-prompt = yes “in the “Runtime Configuration Area”. This “runtime configuration area” turns out to be %APPDATA%\Subversion\ under Windows. Here, I editted the ’servers’ file and stuck this setting in the ‘[Global]‘ section.
When re-entering the file it comes up with a certificate prompt where I can manually type the location of the certificate. Why there is no ‘browse’ button is beyond me, but alas. After typing the location of the certificate it asks for the passphrase for the certificate and goes to work… …only to bomb out with Propfind errors.
A further google reveals some pointers by the subclipse authors that I might need an ‘unlimited strength’ Java Cryptography Extension. By default, a JRE ships with ‘Strong encryption’, meaning that JCE will use strong ciphers such as DES and RSA, but with limited keysizes (max 128 bits for most). As it turns out, my certificate uses 512-bit RSA. The maximum keylengths are controlled by a policy file. To update to unlimited keysizes, you need to download this file from Sun. Extract the contents of the ‘jce’ folder in the zip-file in %JAVAHOME%\lib\security. Then, restart Eclipse to ensure that it accepts the new policy (I don’t know if this is absolutely required but better safe than sorry).
After the restart, I opened the SVN perspective again and entered the URL, again entered the certificate path and passphrase and lo’ and behold: a SVN repository appeared:
However, when clicking the little + sign, again the dialogs appeared that asked me to input my certificate path and passphrase. I was sure that I had ticked the ‘Save Answer:’ checkbox, but I entered my info again and the second level in the repository appeared. When clicking one of the branches in the tree, again I got the dialogs. It appears that the ‘Save Answer:’ checkbox doesn’t do anything. Rather than entering the certificate and passphrase for every action I take in the SVN Repository explorer, I opted for entering the certificate and passphrase into the SVN configuration file.
This entails entering the following info into the ’servers’ configuration file mentioned above:
ssl-client-cert-file = <location of certificate>
ssl-client-cert-password = <passphrase>
This solved the problem and I could browse the repository without problems afterwards. I checked out my project and moved on to the next task: integrating Trac into Mylyn.
