Just retweeting that the GT5.0 is now released. Although a big development over 4.0.x and 4.2.x, this doesn't include all the cool stuff that Crux will bring.
Although the community has pledged support for the 4.x releases through (at least) the end of 2010, there is a recommendation to upgrade to 5.0.0 immediately.
Showing posts with label GlobUS. Show all posts
Showing posts with label GlobUS. Show all posts
Monday, January 25, 2010
Thursday, October 8, 2009
GAARDS Security implementation.
So, my next task for the coming months is to learn, tinker-with, and hopefully implement some cool bits of the GAARDS service as made by the folks up at Ohio State and their work with CaBIG and CaGrid. After a few preliminary readings of white papers and discussions with other people who have investigated various security models, I'm going to try and summarize things as I understand them, and invite people to correct my summarizations...
Globus works with X.509 certificates. To save a lot of complicated two-stepping, I'd say the easiest way to think of a certificate is as a licence with a special key embedded in them. Two nodes wanting to talk to each other have to present their certificates order to access services and establish secure communication, and the nodes have to "trust" each others certificates.
The way to get "automatic" trust without having to add keys into individual trust stores would be to have all the certificates issued by a trusted third party like Verisign or Thawte. This is like getting a passport or a drivers license as ID instead of having a business card with your name on it. It is also expensive, and to have to do it for every node on the grid beyond 5-node grids is pretty much unscalable.
Enter Dorian. Dorian is a GAARDS component and is essentially a Grid Service that allows other authentication methods to be used to access the grid. On one hand, it allows for someone to say "people authenticated by [method] at [node] are allowed to access these grid services". Thus, instead of having to have a certificate, one might just need to enter a username and password, or use their operating system credentials, or use a certificate issued by the Node itself instead of a larger third party.
The other critical component is Grid Trust Services (GTS) which allows for grids with different certificate sets to talk to each other and delegate which services on each grid are available to others. It also performs important syncing functions so that updates to access and authentication chains are propagated through the different grids.
There are other bits too, like GridGrouper which allows for simpler group paradigms (members of the group 'Gridviewer' would be able to access various gridviewers on different nodes... ) and Web Service Single Sign On which would allow an easy port for web applications to gain access to grid services... and you can read about it at the GAARDS website
Either way, I am at the periphery of understanding right now. I hope within a couple of days to have a really good grip on how security works now (and it's limitations) use cases for what we need, and a stronger correlation to how GAARDS will answer those use cases and which components are needed to do it.
Then, over the next couple of months, I'll need to implement those pieces and see what service modifications are needed to use them.
Globus works with X.509 certificates. To save a lot of complicated two-stepping, I'd say the easiest way to think of a certificate is as a licence with a special key embedded in them. Two nodes wanting to talk to each other have to present their certificates order to access services and establish secure communication, and the nodes have to "trust" each others certificates.
The way to get "automatic" trust without having to add keys into individual trust stores would be to have all the certificates issued by a trusted third party like Verisign or Thawte. This is like getting a passport or a drivers license as ID instead of having a business card with your name on it. It is also expensive, and to have to do it for every node on the grid beyond 5-node grids is pretty much unscalable.
Enter Dorian. Dorian is a GAARDS component and is essentially a Grid Service that allows other authentication methods to be used to access the grid. On one hand, it allows for someone to say "people authenticated by [method] at [node] are allowed to access these grid services". Thus, instead of having to have a certificate, one might just need to enter a username and password, or use their operating system credentials, or use a certificate issued by the Node itself instead of a larger third party.
The other critical component is Grid Trust Services (GTS) which allows for grids with different certificate sets to talk to each other and delegate which services on each grid are available to others. It also performs important syncing functions so that updates to access and authentication chains are propagated through the different grids.
There are other bits too, like GridGrouper which allows for simpler group paradigms (members of the group 'Gridviewer' would be able to access various gridviewers on different nodes... ) and Web Service Single Sign On which would allow an easy port for web applications to gain access to grid services... and you can read about it at the GAARDS website
Either way, I am at the periphery of understanding right now. I hope within a couple of days to have a really good grip on how security works now (and it's limitations) use cases for what we need, and a stronger correlation to how GAARDS will answer those use cases and which components are needed to do it.
Then, over the next couple of months, I'll need to implement those pieces and see what service modifications are needed to use them.
Friday, June 12, 2009
Gridviewer is close
So, I managed to get gridviewer working in a sense last night.
It was pulling data and displaying it Quicksilver style when installed in tomcat and connecting to the GIPSE Globus Service running on a non-secure globus container. In Windows.
Today, I tried to build it for a training deploy when connecting to secure GIPSE Globus service running in a secure tomcat container. I found some more dependencies I needed to add. And then I found out that the GIPSE globus service seemed to be having configuration issues.
Thus, I figure the next best step is to get that GIPSE Globus Service running on a secure tomcat container in Windows... or move development over to my old Ubuntu development box (where I would still have to get the GIPSE service running in Linux). Both would be beneficial and work towards the goal of getting an environment more like the training node.
Otherwise, I hope to get that done relatively soon, and then start focusing on the refactors I have been planning for Grid Viewer but haven't been able to really work on in the attempts to just get something Grid-Viewer-ey completed and working (hopefully correctly).
The other thing that needs to happen is more services. One that is starting development will provide NPDS data in GIPSE form, and we should probably also deploy a smaller GIPSE service some place like Dallas so that we can pretend to have a smaller service that only has data for a few states and/or a few conditions. Multiple services with varying metadata is where Grid Viewer should get most of it's niftiness.
Cheers!
It was pulling data and displaying it Quicksilver style when installed in tomcat and connecting to the GIPSE Globus Service running on a non-secure globus container. In Windows.
Today, I tried to build it for a training deploy when connecting to secure GIPSE Globus service running in a secure tomcat container. I found some more dependencies I needed to add. And then I found out that the GIPSE globus service seemed to be having configuration issues.
Thus, I figure the next best step is to get that GIPSE Globus Service running on a secure tomcat container in Windows... or move development over to my old Ubuntu development box (where I would still have to get the GIPSE service running in Linux). Both would be beneficial and work towards the goal of getting an environment more like the training node.
Otherwise, I hope to get that done relatively soon, and then start focusing on the refactors I have been planning for Grid Viewer but haven't been able to really work on in the attempts to just get something Grid-Viewer-ey completed and working (hopefully correctly).
The other thing that needs to happen is more services. One that is starting development will provide NPDS data in GIPSE form, and we should probably also deploy a smaller GIPSE service some place like Dallas so that we can pretend to have a smaller service that only has data for a few states and/or a few conditions. Multiple services with varying metadata is where Grid Viewer should get most of it's niftiness.
Cheers!
Tuesday, May 26, 2009
Helping Dan debug Windows Container bugs
I've been helping Dan with some of the Windows bugs since I'm using a windows container to redevelop the AMDS services for the beta release.
I came across this bug when I tried globus-start-container.bat:
I thought I could fix this by running grid-proxy-init.bat prior to starting the container. This let Globus start up without error, but whenever I tried running a secure service I got an exception like this:
To fix this, you need to start up globus and with the "-containerDesc" parameter specifying a valid security_descriptor.xml (like the one found in $GLOBUS_LOCATION/etc/globus_wsrf_core) that specifies the location of the container cert and the container key. So your command would look something like "globus-start-container.bat =containerDesc c:\foo\security_descriptor.xml"
PS- For anyone trying to use the AMDS alpha, for the sake of debugging please wait for the Beta release on 5/31. The 5/31 release will re-write and fix a lot of what may be annoying anyone trying to use the current gar.
I came across this bug when I tried globus-start-container.bat:
Failed to start container: Container failed to initialize [Caused by: Secure con
tainer requires valid credentials]
I thought I could fix this by running grid-proxy-init.bat prior to starting the container. This let Globus start up without error, but whenever I tried running a secure service I got an exception like this:
Error: ; nested exception is:
org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected "/CN=hos
t/somehostname.cdc.gov" target but received "/O=PHGRID/OU=phgrid.net/OU=Globus Public
Health NCPHI/OU=phgrid.net/CN=someuser/CN=someuser")]
To fix this, you need to start up globus and with the "-containerDesc" parameter specifying a valid security_descriptor.xml (like the one found in $GLOBUS_LOCATION/etc/globus_wsrf_core) that specifies the location of the container cert and the container key. So your command would look something like "globus-start-container.bat =containerDesc c:\foo\security_descriptor.xml"
PS- For anyone trying to use the AMDS alpha, for the sake of debugging please wait for the Beta release on 5/31. The 5/31 release will re-write and fix a lot of what may be annoying anyone trying to use the current gar.
Thursday, April 9, 2009
GAARDS Whitepaper
A new draft whitepaper which provides a primer of the GAARDS toolset has been posted to the Wiki. It is located at http://sites.google.com/site/phgrid/Publications/GAARDingtheGrid.doc?attredirects=0. I would love to get your comments on this as we continue to refine the ideas and messaging behind the usage of these critical grid security components.
This is a the first draft ready for public comment. Special thanks to those who provided pre-public comment feedback initially. I look forward to further feedback from all!
This is a the first draft ready for public comment. Special thanks to those who provided pre-public comment feedback initially. I look forward to further feedback from all!
Monday, April 6, 2009
Introduction to Introduce
So, I read much more about Globus and got introduce up and running, more importantly I figured out what I want to try and do with it in the coming weeks: Make a service that will comply with latest AMDS Spec and a client that will allow me to ping it.
The part of converting Poison Center data into AMDS Responses and AMDS Queries into Poison Center queries, while tedious, is something I can envision doing. I can also envision doing the skeleton from scratch, but that would be absolutely horrible to try and do if I don't have any really powerful tools like XML-spy... or Introduce.
The only problems with Introduce for what we need to do is that it is a bit geared towards caGrid, and likes to package up a few special libraries that end up causing some interesting deploy behaviors using globus tools when it is NOT part of caGrid. It also doesn't produce particularly maven-able results from the get go, so there is some footwork to be done playing with packaging and building and deploy tools.
There is also some work to be done with the client and making sure that it's security libraries don't conflict with existing secure clients (like RODSAdai) or how to place libraries so they don't interfere.
Thus, this week will be devoted to getting the service skeleton set up for a secure globus service.
The other cool thing might be that once this is done, it can be saved off as a shell for any given skeleton that needs to wrap other services, since AMDS is supposed to be a repeatable standard.
The part of converting Poison Center data into AMDS Responses and AMDS Queries into Poison Center queries, while tedious, is something I can envision doing. I can also envision doing the skeleton from scratch, but that would be absolutely horrible to try and do if I don't have any really powerful tools like XML-spy... or Introduce.
The only problems with Introduce for what we need to do is that it is a bit geared towards caGrid, and likes to package up a few special libraries that end up causing some interesting deploy behaviors using globus tools when it is NOT part of caGrid. It also doesn't produce particularly maven-able results from the get go, so there is some footwork to be done playing with packaging and building and deploy tools.
There is also some work to be done with the client and making sure that it's security libraries don't conflict with existing secure clients (like RODSAdai) or how to place libraries so they don't interfere.
Thus, this week will be devoted to getting the service skeleton set up for a secure globus service.
The other cool thing might be that once this is done, it can be saved off as a shell for any given skeleton that needs to wrap other services, since AMDS is supposed to be a repeatable standard.
Friday, April 3, 2009
learning grid services.
So right now I am essentially reading the grid book, learning how to make grid services, and learning how to secure grid services. Then, I will be playing with Introduce to see how it makes all this stuff much easier and much more automatic with the help of Felicia.
I also hope to pick Felicia's brain about implementing security using the client.
Either way, Globus services are a lot more than I thought they were, they have a lot more involved for maintaining state and essentially having all of their interactions marshaled and grouped, and it is just crying out for a shiny (if not leaky) abstraction to make it all pretty and less scary to people who aren't programmers used to fighting with Webservices and some of the gooey "I was generated by a machine" code that can come out of them. I look forward to those abstractions, but until then, I am going to be learning a lot of transport layer fun to get secure/amds-based quicksilver running.
Cheers
I also hope to pick Felicia's brain about implementing security using the client.
Either way, Globus services are a lot more than I thought they were, they have a lot more involved for maintaining state and essentially having all of their interactions marshaled and grouped, and it is just crying out for a shiny (if not leaky) abstraction to make it all pretty and less scary to people who aren't programmers used to fighting with Webservices and some of the gooey "I was generated by a machine" code that can come out of them. I look forward to those abstractions, but until then, I am going to be learning a lot of transport layer fun to get secure/amds-based quicksilver running.
Cheers
Monday, March 9, 2009
Dueling for Certificates.
So, It appears that the problem between Rodsadai-web and Amds-web that they are playing musical chairs for the client-certificate.
Felecia (who is developing AMDS-Web) has been helping me debug. We were able to replicate the issues outside of staging on my dev node (handy, since debugging these involves a lot of jboss-restarts). It appears that it is just a mutual exclusion issue: If you started AMDS-web first, it will be able to marshal the needed security credentials, and when Rodsadai-web tries to marshal the credentials, it will not be able-to and the connection to a remote globus server will fail. The behavior is the same in reverse. If the rodsadai-web client is called first, it works fine and then AMDS-web will throw a connection error.
Now, we are not sure if the failure to marshal is because of slightly different needed credentials that are being cached (apparently Rodsadai-web is using tramsaction layer security (TLS) with only privacy and AMDS-web is using TLS with privacy and integrity) or whether there is some sort of explicit locking behavior that prevents different applications from using the same set of proxies.
Either way, it reveals that we need to find a better way for clients to make secure connections to Globus services. Whether it involves some sort of Server-level pooling or having the apps load application-specific certificates, the current method would not allow client applications with slightly different needs to coexist on the same server (or worse, not even allow client applications with the exact same needs to coexist).
Thus, we plan to delve into the innards of globus security to see whether the certs need to change or how they are being marshalled. (Probably both).
Felecia (who is developing AMDS-Web) has been helping me debug. We were able to replicate the issues outside of staging on my dev node (handy, since debugging these involves a lot of jboss-restarts). It appears that it is just a mutual exclusion issue: If you started AMDS-web first, it will be able to marshal the needed security credentials, and when Rodsadai-web tries to marshal the credentials, it will not be able-to and the connection to a remote globus server will fail. The behavior is the same in reverse. If the rodsadai-web client is called first, it works fine and then AMDS-web will throw a connection error.
Now, we are not sure if the failure to marshal is because of slightly different needed credentials that are being cached (apparently Rodsadai-web is using tramsaction layer security (TLS) with only privacy and AMDS-web is using TLS with privacy and integrity) or whether there is some sort of explicit locking behavior that prevents different applications from using the same set of proxies.
Either way, it reveals that we need to find a better way for clients to make secure connections to Globus services. Whether it involves some sort of Server-level pooling or having the apps load application-specific certificates, the current method would not allow client applications with slightly different needs to coexist on the same server (or worse, not even allow client applications with the exact same needs to coexist).
Thus, we plan to delve into the innards of globus security to see whether the certs need to change or how they are being marshalled. (Probably both).
Monday, November 17, 2008
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.
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.
Wednesday, August 13, 2008
Axis problem has functioning workaround
To address the axis mismatch problem (described here), we developed a separate RODSAdai download servlet that can be called by the RODS application to return either a TimeSeries or SpatialSeries object serialized over HTTP.
Jeremy has tested this in his Pittsburgh environment and it is working.
Mario also mentioned a tool called Jar Jar Links (http://code.google.com/p/jarjar/) that may be able to help. We'll investigate this once the time is found.
So good news is that we're no longer blocking on the custom Axis 1.2RC2 that Globus uses.
Jeremy has tested this in his Pittsburgh environment and it is working.
Mario also mentioned a tool called Jar Jar Links (http://code.google.com/p/jarjar/) that may be able to help. We'll investigate this once the time is found.
So good news is that we're no longer blocking on the custom Axis 1.2RC2 that Globus uses.
Tuesday, August 12, 2008
Axis mismatch is hurting RODSAdai
Dr. Espino discovered a pretty serious bug with how we are planning on using Globus that is preventing the RODSAdai code from running within the same war as RODS.
It comes down to Globus 4.0.5 using a customized version of Apache Axis 1.2RC2 (modified to specifically support Globus services). RODS (like many modern Java applications) also uses Axis. RODS specifically uses version 1.4 of Axis. The version of Axis used by Globus conflicts with the version of Axis used by RODS and is causing the RODSAdai code to fail.
The idea of RODSAdai is that it is a jar that can be included in RODS (or other Java applications) that calls out to OGSA-DAI services on the Public Health Research Grid. So it is beneficial to have the RODSAdai code be as drop in and easy to use as possible.
Jeremy and I had a call with the OGSA-DAI folks (Alistair and Mario) where they basically helped us work out that this is a limitation of Globus, not necessarily of OGSA-DAI. Mario is taking this question to the Globus community to ask how they typically deal with this situation.
In the meantime, Jeremy and I came up with a hack that should work for demo purposes until we get a proper solution from the Globus folks. We're running separate wars for RODS and RODSAdai. This will allow RODS to use the Axis 1.4 jar and RODSAdai to use the Axis 1.2RC2 jar that Globus/OGSA-DAI requires. The hack is that the two wars need to communicate with a HTTP based IPC. Not beautiful, but we'll see if it works.
I added a new servlet to RODSAdai to support this and Jeremy will test it out in his environment later today. Updates will be posted here.
We also found out from OGSA-DAI that they are working on a version that will work with Globus 4.2. Which should come in handy as Dan begins our 4.2 transition testing and planning.
It comes down to Globus 4.0.5 using a customized version of Apache Axis 1.2RC2 (modified to specifically support Globus services). RODS (like many modern Java applications) also uses Axis. RODS specifically uses version 1.4 of Axis. The version of Axis used by Globus conflicts with the version of Axis used by RODS and is causing the RODSAdai code to fail.
The idea of RODSAdai is that it is a jar that can be included in RODS (or other Java applications) that calls out to OGSA-DAI services on the Public Health Research Grid. So it is beneficial to have the RODSAdai code be as drop in and easy to use as possible.
Jeremy and I had a call with the OGSA-DAI folks (Alistair and Mario) where they basically helped us work out that this is a limitation of Globus, not necessarily of OGSA-DAI. Mario is taking this question to the Globus community to ask how they typically deal with this situation.
In the meantime, Jeremy and I came up with a hack that should work for demo purposes until we get a proper solution from the Globus folks. We're running separate wars for RODS and RODSAdai. This will allow RODS to use the Axis 1.4 jar and RODSAdai to use the Axis 1.2RC2 jar that Globus/OGSA-DAI requires. The hack is that the two wars need to communicate with a HTTP based IPC. Not beautiful, but we'll see if it works.
I added a new servlet to RODSAdai to support this and Jeremy will test it out in his environment later today. Updates will be posted here.
We also found out from OGSA-DAI that they are working on a version that will work with Globus 4.2. Which should come in handy as Dan begins our 4.2 transition testing and planning.
Wednesday, July 30, 2008
NLP & Ramp-Up Progressing
I completed the installation of Ubuntu on my laptop last night and I have installed Globus locally. I installed the Simple CA client to keep everything self contained. I will continue to install the other components in the installation guide before the end of the week.
I have access to both the GridMedLee and Zip Code project on my local box. I will begin writing the GridMedLee client in the morning. Both of the above projects were created using the Introduce tool which produces atuo-generated code client code. My intentions are producing a client outside of the Introduce framework.
I have access to both the GridMedLee and Zip Code project on my local box. I will begin writing the GridMedLee client in the morning. Both of the above projects were created using the Introduce tool which produces atuo-generated code client code. My intentions are producing a client outside of the Introduce framework.
Thursday, July 17, 2008
Gridsphere less promising, but what about JBoss
Well, I sent an email out to the globus user mailing list (at least I think I did, I'll have to check that later when I get home)... but I am stumped as to things to try with getting this client to run in tomcat.
Gridsphere, well first I think I installed the wrong version of it, as the newest Gridsphere doesn't seem to have grid portlets, but they might install, I will try that tomorrow.
Otherwise, I am going to try building and running RODSAdai out of JBoss... Dr. Espino indicated he has RODS running in JBoss (which makes it more ideal, should it work, than "some portal" which RODS would probably have to be re-engineered to use) and it seems to be a bit more heavyweight as an application server and might be able to deal with certification specification and security configurations (and may even have a shiny gui).
Gridsphere, well first I think I installed the wrong version of it, as the newest Gridsphere doesn't seem to have grid portlets, but they might install, I will try that tomorrow.
Otherwise, I am going to try building and running RODSAdai out of JBoss... Dr. Espino indicated he has RODS running in JBoss (which makes it more ideal, should it work, than "some portal" which RODS would probably have to be re-engineered to use) and it seems to be a bit more heavyweight as an application server and might be able to deal with certification specification and security configurations (and may even have a shiny gui).
Friday, July 11, 2008
Still having trouble with Secure Access client
Today was more trying to get secure tomcat working using this guide:
http://www.globus.org/toolkit/docs/4.0/common/javawscore/admin-index.html#javawscore-admin-tomcat-deploying
I did not have much luck.
Dr. Espino has been talking to some people who have gotten tomcat clients to access secure grid webservices... and it seems that we are on the right track looking for ways to get the validation path working. So there is hope, and he will probably be tinkering with getting secure clients to work as well.
Otherwise, I have also been researching portal software, things like gridsphere which are designed to handle all the grid authentication mess complete with update grid cert files. It seems to be the toolkit that PURSe operates from, so I will ask Dan more about it since he was researching PURSe a while ago.
A portal to handle SSO and user accounts (including background process accounts) will probably end up being essential for maintaining secure access on steady-state servers that poll constantly or for long-running queries or sweeps... then we don't have to extend proxy deadlines to unreasonable levels for processes that will take a lot of time or run indefinetely.
Otherwise, Anurag got access to the lab today. I got to show him the summary of what I have been doing and chat with him through something other than a phone.
http://www.globus.org/toolkit/docs/4.0/common/javawscore/admin-index.html#javawscore-admin-tomcat-deploying
I did not have much luck.
Dr. Espino has been talking to some people who have gotten tomcat clients to access secure grid webservices... and it seems that we are on the right track looking for ways to get the validation path working. So there is hope, and he will probably be tinkering with getting secure clients to work as well.
Otherwise, I have also been researching portal software, things like gridsphere which are designed to handle all the grid authentication mess complete with update grid cert files. It seems to be the toolkit that PURSe operates from, so I will ask Dan more about it since he was researching PURSe a while ago.
A portal to handle SSO and user accounts (including background process accounts) will probably end up being essential for maintaining secure access on steady-state servers that poll constantly or for long-running queries or sweeps... then we don't have to extend proxy deadlines to unreasonable levels for processes that will take a lot of time or run indefinetely.
Otherwise, Anurag got access to the lab today. I got to show him the summary of what I have been doing and chat with him through something other than a phone.
Thursday, July 10, 2008
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.
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.
Thursday, July 3, 2008
Lots of stuff done, lots of stuff to do.
Things completed:
- Confirmed that secure Ogsa-dai was working on the new 205 box. Many thanks to Dan for his help and awesomeness.
- Have pulled the current RODSAdai files over to the 205 box, and linked the 205 box's maven to the repository, showing that I can recreate all the dev code and have it building in about 5 minutes in a new environment... and that is so cool.
- Got the HL7_ADTS table on the 205 box.
Things to be done now:
- Implement the secureClient for RODSAdai
- Document
- Expand tests to deal with time and spatial series data.
- Work with Jeremy on integrating with RODS and getting the security to work with tomcat.
Cheers, Things seems to be rolling along nicely, have a good 4th of July weekend!
Wednesday, June 4, 2008
Maven and it's lovely repository
So, I spent a good part of the day paring down how many libraries my example client code actually needed from globus and ogsadai respectively. The list dropped from 40 to about 8.
Then I spent a lot of time putting one of those 8 into the local maven repository in a way that maven seems to recognize... and adjusting the pom file to point to it as a dependency. I hit "mvn package" (ie. compile) and I got a long, thoughtful message about how the dependency wasn't found and how I can add a file with the helpful "mvn install:install-file" command. They also had a "mvn deploy" command for deploying code to a commonly owned repository... showing that deploying to a central and accessible location is
Then proceeded to add all 8 files in about 30 minutes, along with dependencies to the pom file, and then ran mvn compile successfully.
I am really beginning to like maven!
Tomorrow, I am going to put some of the interface and repository plans for the RODS<->OD interface to paper... perhaps start some of the code for simple things like resource discovery. Then, I will test to see whether the jar produced runs properly when put into the proper environment... then I will start reading up on where to put the JSP files. I will also make an eclipse project file and import it into eclipse.
There is also a meeting to discuss package layouts and plans and the like. I am looking forward to it.
Then I spent a lot of time putting one of those 8 into the local maven repository in a way that maven seems to recognize... and adjusting the pom file to point to it as a dependency. I hit "mvn package" (ie. compile) and I got a long, thoughtful message about how the dependency wasn't found and how I can add a file with the helpful "mvn install:install-file" command. They also had a "mvn deploy" command for deploying code to a commonly owned repository... showing that deploying to a central and accessible location is
Then proceeded to add all 8 files in about 30 minutes, along with dependencies to the pom file, and then ran mvn compile successfully.
I am really beginning to like maven!
Tomorrow, I am going to put some of the interface and repository plans for the RODS<->OD interface to paper... perhaps start some of the code for simple things like resource discovery. Then, I will test to see whether the jar produced runs properly when put into the proper environment... then I will start reading up on where to put the JSP files. I will also make an eclipse project file and import it into eclipse.
There is also a meeting to discuss package layouts and plans and the like. I am looking forward to it.
Tuesday, June 3, 2008
SVN and Maven
I have checked in most of my code into the Sourceforge SVN, and I just got the note that we should be using the package gov.cdc.ncphi..... and not org.cdc...
I guess I get to learn about subversion directory changes next :).
Otherwise, I have hit a challenge on the maven-ifcation of the code. Maven prefers jar files stored in remote repositories somewhere. All the OGSA-DAI and Globus code is set up with a series of build files (especially globus considering it has a lot of C++ code in addition to Java code) but there is no maven repository. I experimented with moving jar files into a resource location, but I think I am just going to have to store the jar files in the local repository with the appropriate maven metadata. I am not sure of the best way to do that, whether there is some sort of tool, or whether I should try and get maven building the OGSA-DAI code.
I guess what I am looking for now is a resource for taking projects that already exist and getting it to a point where maven is now managing it, because a lot of the stuff that was handled by changing the classpath before now is going to be handled by formatting the myriad dependencies into an xml file.
I feel like in the end we will have the local repository and we will be able to publish it to our own repository so that other development groups can reference our files with the appropriate sets of Ogsa-Dai libraries and globus libraries.
I also need to start researching how to implement a globus WS extension and looking into the best ways to get data back and forth between RODS and Ogsa-Dai.
I guess I get to learn about subversion directory changes next :).
Otherwise, I have hit a challenge on the maven-ifcation of the code. Maven prefers jar files stored in remote repositories somewhere. All the OGSA-DAI and Globus code is set up with a series of build files (especially globus considering it has a lot of C++ code in addition to Java code) but there is no maven repository. I experimented with moving jar files into a resource location, but I think I am just going to have to store the jar files in the local repository with the appropriate maven metadata. I am not sure of the best way to do that, whether there is some sort of tool, or whether I should try and get maven building the OGSA-DAI code.
I guess what I am looking for now is a resource for taking projects that already exist and getting it to a point where maven is now managing it, because a lot of the stuff that was handled by changing the classpath before now is going to be handled by formatting the myriad dependencies into an xml file.
I feel like in the end we will have the local repository and we will be able to publish it to our own repository so that other development groups can reference our files with the appropriate sets of Ogsa-Dai libraries and globus libraries.
I also need to start researching how to implement a globus WS extension and looking into the best ways to get data back and forth between RODS and Ogsa-Dai.
Wednesday, May 21, 2008
New person / NLP Service Wrapper
Hello, I'm Brian Alexander Lee and I'm starting to work with the public health research grid team to help out on some of the proof of concept projects. I'm an enterprise architect and my background is in web services and software development, so I hope that I'll be of use to the projects.
To work with the Centers of Excellence, we had a call with Albert Lai of Columbia University on how to provide an interface to the Columbia Natural Language Processor (I think is called Medley).
We talked about some of the best ways to provide a wrapper to the existing NLP components and right now the thinking is to provide a web service wrapper through Globus that accepts medical free text (in either body text or files) that can invoke the NLP and respond with structured data in xml format. We'll post more as we start testing and designing more.
Also, Albert shared the URLs for two potential web service frameworks that we might be able to use in the test:
To work with the Centers of Excellence, we had a call with Albert Lai of Columbia University on how to provide an interface to the Columbia Natural Language Processor (I think is called Medley).
We talked about some of the best ways to provide a wrapper to the existing NLP components and right now the thinking is to provide a web service wrapper through Globus that accepts medical free text (in either body text or files) that can invoke the NLP and respond with structured data in xml format. We'll post more as we start testing and designing more.
Also, Albert shared the URLs for two potential web service frameworks that we might be able to use in the test:
Wednesday, May 14, 2008
Dr. Jeremy Espino and the wonderful RODS project
I had a rather long and very informative desktop-share and teleconference with Dr. Jeremy Espino going over RODS (Realtime Outbreak Detection System) and how it can be incorporated into POCs for the PHIN conference in September.
Furthermore, he created an SVN repository for grid-related code (whether it be related to RODS, Globus, OGSA-DAI, &c), showed me the wonders of Maven, let me see the prettiness that is IntelliJ IDEA, and generally got me really familiar with how RODS works and what peices he wants me to focus on.
The SVN repository is grand, because it gives me a place to put some of the code I have been working on... and more importantly will force me to clean it up to the point where I am not scared to have other people looking at it.
As for the POC and RODS... RODS has UI functionality with the ability to basically take counts associated with locational data and actually get it plotted to various geolocational displays (think Google Maps). Thus, it would be the perfect UI for any sort of grid monitoring system, and if we can make data plugins that pull from OGSA-DAI resources instead of the normal RODS database (which is populated over time by a listener that parses HL7 hospital data)... Needless to say I have had an explosion of ideas for how to orient grid nodes and how RODS code can be used. I look forward to discussing them.
Furthermore, he created an SVN repository for grid-related code (whether it be related to RODS, Globus, OGSA-DAI, &c), showed me the wonders of Maven, let me see the prettiness that is IntelliJ IDEA, and generally got me really familiar with how RODS works and what peices he wants me to focus on.
The SVN repository is grand, because it gives me a place to put some of the code I have been working on... and more importantly will force me to clean it up to the point where I am not scared to have other people looking at it.
As for the POC and RODS... RODS has UI functionality with the ability to basically take counts associated with locational data and actually get it plotted to various geolocational displays (think Google Maps). Thus, it would be the perfect UI for any sort of grid monitoring system, and if we can make data plugins that pull from OGSA-DAI resources instead of the normal RODS database (which is populated over time by a listener that parses HL7 hospital data)... Needless to say I have had an explosion of ideas for how to orient grid nodes and how RODS code can be used. I look forward to discussing them.
Subscribe to:
Posts (Atom)
Posts
