Prepping for new rodsadai

So, today I spent some time prepping for the poicondai loader load of a lot of zip code polygons into a database.

But a lions share of the day was spent setting up the shiny new secure tomcat installation on the staging node. Also known as "boy, I love being able to configure different ports!"

So, the window for taking down the node and updating RODSAdai to call secure tomcat is tomorrow... but that didn't stop us from making sure we couldn't set up secure globus and make some ogsadai calls to it. That took a little bit of time mainly because the tarball I set up apparently broke or was not happy in it's new environment, so we had to build a new one from scratch.

Many thanks to Felicia and Dan for pretty much doing most of the footwork before me so all I had to do was go "get this, put that there, lemme check... yay!" Dan was awesome with the configuration and Felicia knew most of this stuff from having to deal with it before a couple of times.

Tomorrow is loading polygons, updating build styles, and starting the poicondai-web modifications.

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.

Well, I got some documentation updated and MySQL on a server

Today I did a lot more research, tried getting tomcat secure access working (I did) to see if it would make secure client OGSA-DAI access from tomcat work (it didn't). I am out of ideas, but I sent out more feelers to see if other people could help me or provide working examples.

Otherwise, I documented and cleaned up a bunch of the RODSAdai code, and I am setting up a dedicated MySQL server just so we have a MySQL database in the lab that is not eaten by globus/vdt.

RODSAdai Webapp not able to find certification path

Today was pretty much all day trying to hammer against tomcat and getting it to recognize the globus certificates for clients... and I have no idea where such things are controlled within tomcat, and the things I tried didn't fix the problem.

Thus, the "the secure client won't run through tomcat" problem is back, and I still am not sure how to tell tomcat "use these keystores that exist within globus when invoking this client which connects to a secure globus server". The error that is thrown is the familiar "unable to find certification path"

I really have two problems: The first is that I have no idea how to get tomcat to use a keystore other than the default java one for client programs. Ideally it should be made-to pick up the certificates and look up the proxies like the command line clients... something about the tomcat container prevents security policies from being overwritten in the same way they are within the command line clients.

The second problem is that there is tons of stuff written about how to enable tomcat as a secure ogsadai/wsrf server, and it is blocking out google searches of how to enable tomcat to run secure clients which access other globus/wsrf servers with things other than the default keystore.

I have tried several things which haven't worked:

1. Moving client-config.wsdd into the WEB-INF/classes/ directory of the web-app.
2. Modifying server.xml in [tomcat-root]/conf to use the globus certificates for secure access as described by this website: 'http://www.gridlab.org/WorkPackages/wp-5/guide/axis.html#install' and it was really more of an old way of setting up some sort of globus ws server with an old version of globus.
3. importing cog-tomcat.jar into the libs directory (of the webapp and the server), after finding that cog-tomcat seemed to hold several of the security handlers...

I am out of ideas at the moment... Dr. Jeremy Espino is working on setting up his globus/ogsadai environment and then he'll tinker with it too.

I figure there is a workaround to write clients that explicitely invoke the globus security elements... but I imagine I will have to pore over acres of ogsa-dai and wsrf source code to set such things up and any resulting code might be locked to very specific versions of ogsadai and/or globus.

I just feel like there is some "oh, you just set this property in the config file for the webapp" thing I don't know exists... I just have no idea where that is and my attempts to look for it keep getting flushed out by examples showing me how to enable https on port 8443.