Code the need.

So, I am excited to say that I got the JBoss server unbound to localhost. The best guide I found for opening up the server for production and removing all of the dangerous programs was here: http://www.jayson.in/programming/how-to-configure-jboss-as-production-settings-and-tuning-tips.html

So, I managed to get JBoss unlocked, and then found out that there is a lot of location-specific stuff that is not sitting in a properties file, but is instead sitting in hard code.

This is bad.

Thus, in addition to massaging the PoiConDai server to be nicer, I am going to be massaging RODSadai and RODSAdai-web to better handle being placed on different servers... because trying to remember the immediate coding environment specifics is really annoying and should just be able to sit in the given JBoss environment.

Otherwise, more demos soon, yay.

JBoss and security

So, one of the things I noticed when I was setting up for the demo is that I cannot just connect to JBoss from any old computer.

It took me about three days of idle wanderings on the internet to figure out that JBoss makes things super-secure by default. One of the ways they do this is by locking down the server to only localhost connections (so that essentially, only the computer the server is on can ever touch the server)

Thus, I finally figured out how to disable it and this methodology... The caveat being that you have to read a large disclaimer about how you might be opening up security risks and should mitigate all of them before you can comfortably do this.

Looks like I get to sit and read a doc for a while to make sure I know how to turn off the remote administration stuff and other big-scary-nasties before I open it up completely. I miss tomcat.

Otherwise, I am working on polishing up the PoiConDai demo and documenting the next steps in RODSAdai and how they might contribute to the NCPHI toolkit. Docs to follow, excitedness here now.

RODSAdai on Jboss Worked!

So, this morning I finished up installing JBoss-4.2.2, got it running and then transferred over the Rodsadai-war from the maven target directory into the JBoss deploy directory.

Then, I went to the server endpoint, and tried running my little test JSP. And it worked! As simple as that. It didn't throw errors, it didn't say anything about failed path building, it just ran and gave me the output I wanted when I first tried all this Thursday week before last. So now I know it works and can start being integrated with RODS.

The downside of this, is that it's yet another server. Fortunately, I talked to Jeremy and he already had RODS running in a few JBoss instances, so it will not be an obstruction of his coding plans to say "this needs to run in JBoss to work"... going "RODS needs to become a gridsphere portlet" would be much less palatable. It might require some musical ports if tomcat and jboss need to run on the same server, but honestly the secure OGSA-DAI we are running would be in the globus container and not in tomcat, and other tomcat applications can run on the tomcat within jboss.

That doesn't mean I didn't spend a lot of time today trying to get tomcat to work securely based on how JBoss' tomcat did it. It appears that JBoss' tomcat uses an entirely different realm, passing itself to the security engine that JBoss manages. I tried pulling jars from JBoss into standalone tomcat and adjusting the realm and started getting all sorts of "hey, you're trying to run me outside of JBoss type errors and library failures."

Maybe Globus already has some sort of realm tweak you can perform for tomcat that makes it point to the globus container and security manager. Maybe one can be designed. Then again, maybe saying "it needs to run in JBoss" won't be a fatal problem.