Remote Login to Kubuntu via XDMCP

Background
After searching the Internet for the elusive solution, here's what worked for me, using Kubuntu 10.10. Using SSH tunneling to run GUI programs on a Linux server would be easier for me as it's the standard practice at my workplace, but takes out the fun in having to play around with the entire desktop display.

My ex-colleague in my ex-company showed me how to do remote login to a Solaris 9 box via XDMCP using Cygwin (xwin) on Windows XP. Back then there was no need to configure anything on that Solaris box, it just works. When I moved on to my current company, I tried to do the same on the 'standard build' RHEL3/4 box. Failed miserably. The 'standard build' stripped the window manager away, and I have to settle for SSH tunneling. Some simple applications can be run, most of the cool ones don't.

Of course, there are other alternative ways to display the desktop remotely, such as VNC, but I prefer XDMCP because the display resolution is 'customized' to your viewing machine's resolution. XDMCP also establishes a different session so unlike VNC, it will not 'hijack' or take over the current user's session. Maybe VNC can also do these things with some tweaking, but this out of scope in this posting.

Server Settings
Ok, firstly, make sure KDE (I'm using Kubuntu) is running fine & fast. If you are using NVIDIA graphics card, update your drivers via launcher: Applications > System > Additional Drivers. This is the fastest & easiest way. In my workplace where I needed to set a global proxy to connect to the Internet, this way didn't work. I've tried downloading the drivers from NVIDIA website and followed the instructions, but to no avail.

Ok, here's the real meat:

1. As root, open up /etc/kde4/kdm/kdmrc file. Search for the section with header [Xdmcp], and update as highlighted below (even though the comment says 'Default is true', the Enable key had the value 'false' by default)
   
   [Xdmcp]
   # Whether KDM should listen to incoming XDMCP requests.
   # Default is true
   Enable=true
   
2. Save the file above. If you are happy with the defaults, then open up /etc/kde4/kdm/Xaccess file, and uncomment the following lines (remove the # at the start of the line, and both lines are not next to each other, it's shown as below for conciseness):
   
   * #any host can get a login window
   
   * CHOOSER BROADCAST #any indirect host can get a chooser
   
3. Save the file above. Ok, now just restart KDM only, but restarting the OS will also achieve the same effect.
4. Before we move on, make sure you have the server's IP address, we'll need it for the client setup below. Let's say it's 192.168.2.2

Client Settings
For the client, I used Windows XP. I wanted to use Cygwin (xwin) but somehow the command prompt just closes by itself after a few seconds. It's a mystery...but I also have Xming installed. So I used it instead. Get Xming @ http://sourceforge.net/projects/xming/

1. Open up the command prompt and navigate to the Xming installation folder. It should contain xming.exe file.
2. Then run this command (replace the IP address with your own server's IP): xming -query 192.168.2.2
3. It will take a while if your server is not that powerful and using a slow network connection (I was using my old P4 box as server and my WinXP notebook was connecting via wireless). If everything's working, you will see the KDE login screen. Yahoo!

RAR in Linux

RAR is a very popular compression format in Windows (at least, since I am using Windows at work & at home). RAR generally has a better compression ratio than ZIP, and in places where disk space counts, would be cost-saving and "life-saving".

At my workplace, there's a need to Un-RAR a RAR file (created in Windows) in a Linux box. In the standard build of Linux (based on RHEL4) that we were running, the "unrar" command-line program is not present. Fortunately there's a free version on the Internet. Just need to do a little searching to get the RPM.

So I went to http://rpm.pbone.net/ and I found the right RPM file. My exact search result: http://rpm.pbone.net/index.php3/stat/4/idpl/11979708/dir/redhat_el_4/com/unrar-3.7.8-1.el4.rf.i386.rpm.html

Installing it is a breeze (phew!), with all the dependencies fulfilled in my Linux box. The command is simple (recommended using root-access to run):

rpm -i unrar-3.7.8-1.el4.rf.i386.rpm

So now, we can un-RAR files in Linux!

Basic usage:

unrar x myrarfile.rar

where 'x' is to extract files. Full list of options can be obtained by just typing "unrar".

What about creating RAR files in Linux? AFAIK, there's no free tool, but you can purchase or try one. Go get the files @ http://www.rarlabs.com

XMLBeans - First Steps

I attempted to revisit XMLBeans to generate XML-Java mapping codes based on the IFX schema. I've tried JAXB v1 but failed miserably (there might be some tweaking needed but I've searched high and low, to no avail...few years ago) The multi-XSD file structure from IFX Forum website was used.

In the XSD folder (all files are from the IFX Forum):
$pain.001.001.01.xsd
$pain.002.001.01.xsd
$pain.004.001.01.xsd
IFX170_XSD.xsd
RemitDetail_Type.xsd

Using XMLBeans 2.5.0 distribution, the command I run:
E:\experiments\exploded-apis\xmlbeans-2.5.0\bin>scomp -mx 1024M -out ifx17.jar E:\yk\xpdesktop\IFX-SIT\IFX1.7_XSD\IFX170_XSD.xsd

IFX is a HUGE schema so the heap size is increased to 1024M in order for the command to complete successfully.

Results:
Time to build schema type system: 3.39 seconds
Time to generate code: 109.938 seconds
Time to compile code: 145.939 seconds
Compiled types to: ifx17.jar

Wokay, this is good. First try without fancy options, and a JAR file is produced. I couldn't achieve the same thing in JAXB v1. Will need to try out using JAXB v2. More on this later.

Java VisualVM - Remote Display, Firewall-Protected, Offline Environment

VisualVM can be used for remote monitoring of Java applications. Things work fine for an environment without firewall "interference". For folks that are fortunate enough to have the protection of a firewall, here's a trick which worked for me, and may work for you.

Basically, I used SSH + X-Windows to view the VisualVM GUI on my local PC. In my current company's testing environment, SSH access is given and certain number of ports e.g. 80-90 (HTTP), 443-449 (HTTPS) are open for access as well. The rest are inaccessible i.e. blocked by firewall. No doubt firewall ports can be opened to allow RMI traffic essential for VisualVM to connect to the remote machine, but due to the nature of the out-of-the-box RMI implementation that dynamically assigns its port numbers, ports assigned are only valid for that particular time. A restart will have different ports assigned. There are ways to go around this behaviour, but exploring this option is out of the scope of this blog entry.

So the tools I used: Putty (for SSH), NetSarang's Xmanager2 (for X-Windows display), and of course, Sun JDK6 (u21).

First, I run Putty to access Machine A (Linux box) via SSH. Xmanager2 is also running in the background in Passive mode. At the Putty console, I ran the command below to enable X-Window display on my PC (assuming IP=10.123.124.67):

export DISPLAY=10.123.124.67:0.0

Then just run VisualVM on Machine A. On Machine A (could be different in your own environment):

/usr/java/jdk1.6.0_21/bin/jvisualvm &

The VisualVM GUI will then appear on my PC, but running on Machine A. So you can just "remotely" monitor your Java applications running on Machine A as a local client.

But unfortunately, the stock VisualVM application that comes with Sun JDK6 doesn't have the MBeans viewer plugin installed. And Machine A does not have access to the Internet, so online installation of the plugin is not possible. But fortunately, the plugin files (*.nbm) can be downloaded and installed offline (https://visualvm.dev.java.net/pluginscenters.html).

So that's it. I will be using the MBeans viewer to monitor my application's Tomcat database connection pool, after I'm done converting from Apache DBCP to Tomcat Jdbc Pool. More on this later.

If there's no firewall to make this complicated, you can add this to your Java application startup command:

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9394
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

This will disable SSL and authentication (username/password). You can then use VisualVM to connect to the remote machine.

Hacking your way to smoother SSL testing: Follow up #1

Yup, after a long "break" from blogging, I have restarted my "engines" to blog about this topic. Decided to write more on this before my memory starts failing...

Back in 2006, I applied the short-circuit codes to go around using HTTPS without having the proper certificates imported to the local truststore...was doing some POC for sending SMS requests via web services to an SMS gateway provider. But the SMS sender is just a standalone Java program. The hack worked nicely.

Returning to the future (present day, 2009). But security has its price...'real' SSL certificates (even testing, self-signed ones) have an expiry. When the testing team must shift the server dates earlier or later to "sync" with the mainframe data, this may cause the certificates to "prematurely expire". Sure, just regenerate the self-signed cert and whack it back into the truststore. The "good" way to do it. Or just use HTTP, code's still the same, just a parameter change. "Oh but this won't simulate closely to the production environment. If something goes wrong because you skipped something, will you be able to bear the brunt???", says the support manager...and if testing team finds out then there will be ICBMs flying around (aka email wars).

But I am just not a "normal, well-adjusted" coder. Always trying to find ways to circumvent stuff :)...

So, I tried to apply the hack (previous post) to see if it still works in WebSphere Application Server (WAS). The DummySSLSocketFactory class have to be refactored to use javax.net equivalents of the Sun-specific classes used by the Java tip article (http://www.javaworld.com/javatips/jw-javatip115.html). First I tried it on a standalone program with a few JDKs:

• Sun JDK 1.4.2_18 - Failed (Noted in previous post, but after 2 years passed, I still have verify this)
• IBM JDK 1.4.1 (comes with WSAD) - Passed
• Sun JDK 1.6.0_10 - Passed

OK, WAS 5.1 is running on IBM JDK 1.4, so chances of success is high. I fitted the code to set the security property to use DummySSLSocketFactory in a startup class in my webapp. Added a logging statement to ensure that this code has been executed during server startup. Then the code to call a HTTPS web service is triggered....FAILED!

Hmm, strange. I suspected that the security property set failed to take effect. I looked up the javadocs for javax.net.ssl.SSLSocketFactory. There's a method "getDefault()" to get the default SSL socket factory object. Went back to the standalone test program and called this method and print the class name out before setting the security property and after setting it.

The output looked like this:
Before: com.ibm.jsse2.SSLSocketFactoryImpl
After: com.ibm.jsse2.SSLSocketFactoryImpl

Ahhhh....so calling SSLSocketFactory.getDefault() will render the security property setting to none effect. The above output is similar when testing the webapp in WAS...no effect.

So, there must be something "magical" going on in this SSLSocketFactory class. Ok, let's look at the source code. But the code isn't there in the JDK (src.zip). I can't believe my eyes, why is it absent in the uber source code zip file??? It's also missing in Sun JDK 1.6.

Well, maybe Google can give me some answers. Some folks are also puzzled by this, and there's even a bug submission (yeah, Bug ID 4811569, take a look: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811569). Is it fixed? Nah, it's not a bug, evaluation:

Not a bug. What's in javax.net is part of the Security Code (JSSE) therefore, the sources are not available through normal means for export control reasons.
However, it is possible to get access to it through the SCSL process.
See http://wwws.sun.com/software/java2/download.html

OK lo, I'll go look them up sometime later.

So, the hack is not all-encompassing, after all, it's just a hack. Maybe if there's a way to inject a certificate into a truststore without the hassle of running keytool or ikeyman...sometimes the keytool doesn't work (due to a vendor solution putting in extra jars into the WAS JRE's lib/ext folder and screwing up the tool, and there's no other JDK/JRE lying around...ya, just install a clean JDK and use it...sure, but it's production environment, and I can't just install anything I like, and there are more than a dozen machines running similar applications...things get unnecessarily complicated when you are not in total control), and the only means of communicating with the machines in a DMZ is using SSH via VPN, which somehow is not able to display GUIs (is there a way, or maybe not allowed by firewall?). So, learn the ikeyman command line version, or find out how to inject certs programmatically?

I chose the way of the code...stay tuned for the next follow-up post...

Yes, I re-iterate, I am not a "normal, well-adjusted" coder.

Hacking your way to smoother SSL testing

I referred to this post (http://www.javaworld.com/javatips/jw-javatip115.html) which has 2 cool files (DummySSLSocketFactory.java & DummyTrustManager.java) that enable an application to accept all certificates WITHOUT validation, even if the certificate name differs from the server name. At your application, add the following statement (preferably just as the program starts):

Security.setProperty( "ssl.SocketFactory.provider", "DummySSLSocketFactory");

Yeah, this is coooool....

But unfortunately, this doesn't work in JDK 1.4.2. Excerpt from http://java.sun.com/j2se/1.4.2/docs/relnotes/features.html#security:

The JSSE implementation provided in this release includes strong cipher suites. However, due to U.S. export control restrictions, this release does not allow alternate "pluggable" SSL/TLS implementations to be used.

Aiii, need to do those keytool import/export/genkey stuff.....

But anyway, using JDK 1.5, it works! But I wonder, has US export restrictions got lax??? Kekekeke...but don't bother doing this in your startup script:

-Dssl.SocketFactory.provider=DummySSLSocketFactory

Coz it doesn't work!!! Stop wasting your time :p

Eclipse 3.1 startup memory settings

Edit eclipse.ini @ Eclipse root folder, change the min & max memory:

-vmargs
-Xms128m
-Xmx512m

Then restart Eclipse. The startup time will be noticeably faster.

Do this if you have lots of memory to spare, and there'll be less "hangups" using this smashing IDE ;)