RT for crt.cs.wisc.edu
RT for crt.cs.wisc.edu
addGIPProbeIDtoDatabase.mysql
smime.p7s
|
|
| # | Fri Oct 17 14:22:19 2008 | jpackard@bnl.gov - Ticket created | [Reply] | |||||||||||
Oh yes, I forgot. I did remove the GIP probe addition from the setup script. Here's my email again with that step added: Hi Alain and Tim, We are ready to start packaging GUMS 1.3.0 into the VDT. The server can be downloaded from http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war and the client from http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz . You should follow the same procedure as you have before but also do the following: * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" during upgrades to import the data from the old schema to the new. * add the ...gums/WEB-INF/scripts directory to the classpath. This was supposed to have been done for the last release. * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied from the ...gums/WEB-INF/lib directory into ...tomcat/common/endorsed. Also copy glite-security-trustmanager-1.8.16.jar and glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib directory into ../tomcat/server/lib (and remove the older glite jars). Of course you'll need to test that these global dependency updates do not cause problems with other tomcat applications. * Add a new prima test to test the new GUMS XACML interface (please talk with Igor about this). * Update GUMS documentation URLs by replacing 1.2 with 1.3. I will be updating the documentation in the next 2 weeks. * run "mysql < .../gums/WEB-INF/sql/addGIPProbeToDatabase.mysql" on new installations to add the GIP probe DN. Let me know if you have any other questions. Thanks, Jay Gabriele Garzoglio wrote: > > Hi Jay, > did you decide, in the end, to separate the configuration of the > database for the GUMS probe from the rest of the db initialization > script? > I'm asking because I do not see an explicit step mentioned below. > Thanks > Gabriele > > Jay Packard wrote: >> Hi Alain and Tim, >> >> We are ready to start packaging GUMS 1.3.0 into the VDT. The >> server can be downloaded from http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war >> and the client from http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz >> . >> >> You should follow the same procedure as you have before but also do >> the following: >> * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" >> during >> upgrades to import the data from the old schema to the new. >> * add the ...gums/WEB-INF/scripts directory to the classpath. >> This >> was supposed to have been done for the last release. >> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is >> copied >> from the ...gums/WEB-INF/lib directory into >> ...tomcat/common/endorsed. Also copy >> glite-security-trustmanager-1.8.16.jar and >> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >> directory into ../tomcat/server/lib (and remove the older glite >> jars). Of course you'll need to test that these global >> dependency >> updates do not cause problems with other tomcat applications. >> * Add a new prima test to test the new GUMS XACML interface >> (please >> talk with Igor about this). >> * Update GUMS documentation URLs by replacing 1.2 with 1.3. I >> will >> be updating the documentation in the next 2 weeks. >> >> Let me know if you have any other questions. >> >> Thanks, >> Jay >> |
||||||||||||||
| # | Fri Oct 17 14:29:48 2008 | roy - Given to roy | ||
| # | Fri Oct 17 14:29:59 2008 | roy - Cc jhover@bnl.gov added | ||
| # | Fri Oct 17 14:30:01 2008 | roy - Cc garzogli@fnal.gov added | ||
| # | Fri Oct 17 14:33:12 2008 | roy - Cc cat added | ||
| # | Fri Oct 17 14:33:53 2008 | roy - Correspondence added | [Reply] | |
|
I'm resending this, this time through the ticket. If we can communicate here, it will be useful. Thanks! --------------------------- Thanks Jay! I have a couple of questions. On Oct 16, 2008, at 11:27 AM, Jay Packard wrote: > Hi Alain and Tim, > > We are ready to start packaging GUMS 1.3.0 into the VDT. The server http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war> can be downloaded from > > and the client from http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz.> > the following:> You should follow the same procedure as you have before but also do > * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" during > upgrades to import the data from the old schema to the new. > * add the ...gums/WEB-INF/scripts directory to the classpath. This > was supposed to have been done for the last release. These sound straightforward. > * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied > from the ...gums/WEB-INF/lib directory into > ...tomcat/common/endorsed. Also copy > glite-security-trustmanager-1.8.16.jar and > glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib > directory into ../tomcat/server/lib (and remove the older glite > jars). Of course you'll need to test that these global dependency > updates do not cause problems with other tomcat applications. These concern me deeply. Why do we need these changes that affect all webapps? The "Of course, you'll need to test..." clause is the complicated one. Every time these libraries are updated, or \ we add a new webapp, or we update a webapp, we'll be concerned about conflicts. Is this really needed? Can you explain further? > * Add a new prima test to test the new GUMS XACML interface (please > talk with Igor about this). Sure, this shouldn't be hard. > * Update GUMS documentation URLs by replacing 1.2 with 1.3. I will > be updating the documentation in the next 2 weeks. OK. > * run "mysql < .../gums/WEB-INF/sql/addGIPProbeToDatabase.mysql" on new installations to add the GIP probe DN.Can you clarify this a bit? Do we pass the DN as a parameter somehow? I'm confused. Thanks, -alain |
||||
| # | Fri Oct 17 14:33:55 2008 | RT_System - Status changed from 'new' to 'open' | ||
| # | Fri Oct 17 14:36:04 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, Glad to hear most of them are straight forward. You don't need to pass a DN to addGIPProbeToDatabase script - the DN is inside - just run the script. There is no particular reason to update the dependencies besides staying current and partaking of bug fixes and possible performance improvements in the later versions, especially for the glite libraries that have "dev" attached to them, suggesting a beta version. Isn't that reason enough? Jay Alain Roy via RT wrote: > I'm resending this, this time through the ticket. If we can communicate > here, it will be useful. Thanks! > > --------------------------- > > Thanks Jay! I have a couple of questions. > > On Oct 16, 2008, at 11:27 AM, Jay Packard wrote: > Hi Alain and Tim, > > >> We are ready to start packaging GUMS 1.3.0 into the VDT. The server > http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war>> can be downloaded from >> >> > >> and the client from > http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz.>> >> > >> You should follow the same procedure as you have before but also do > the following:>> > >> * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" during >>> upgrades to import the data from the old schema to the new. >> * add the ...gums/WEB-INF/scripts directory to the classpath. This >> was supposed to have been done for the last release. >> > These sound straightforward. > > >> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied >>> from the ...gums/WEB-INF/lib directory into >> ...tomcat/common/endorsed. Also copy >> glite-security-trustmanager-1.8.16.jar and >> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >> directory into ../tomcat/server/lib (and remove the older glite >> jars). Of course you'll need to test that these global dependency >> updates do not cause problems with other tomcat applications. >> > These concern me deeply. Why do we need these changes that affect all > webapps? > > The "Of course, you'll need to test..." clause is the complicated one. > Every time these libraries are updated, or \ > we add a new webapp, or we update a webapp, we'll be concerned about > conflicts. > > Is this really needed? Can you explain further? > > >> * Add a new prima test to test the new GUMS XACML interface (please >>> talk with Igor about this). >> > Sure, this shouldn't be hard. > > >> * Update GUMS documentation URLs by replacing 1.2 with 1.3. I will >>> be updating the documentation in the next 2 weeks. >> > OK. > > >> * run "mysql < .../gums/WEB-INF/sql/addGIPProbeToDatabase.mysql" on > new installations to add the GIP probe DN.>> > > Can you clarify this a bit? Do we pass the DN as a parameter somehow? > I'm confused. > > Thanks, > -alain > > > > |
||||||||||||||
| # | Mon Oct 20 09:38:58 2008 | roy - Correspondence added | [Reply] | |||||||||
I'm not sure I follow your answer. I don't understand why GUMS needs to make changes that affect the running of all webapps and Catalina itself. Can you explain further? -alain On Oct 17, 2008, at 2:36 PM, Jay Packard via RT wrote: > There is no particular reason to update the dependencies besides > staying > current and partaking of bug fixes and possible performance > improvements > in the later versions, especially for the glite libraries that have > "dev" attached to them, suggesting a beta version. Isn't that reason > enough? > > Jay > > Alain Roy via RT wrote: >>> >>>>> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied >>> from the ...gums/WEB-INF/lib directory into >>> ...tomcat/common/endorsed. Also copy >>> glite-security-trustmanager-1.8.16.jar and >>> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >>> directory into ../tomcat/server/lib (and remove the older glite >>> jars). Of course you'll need to test that these global >>> dependency >>> updates do not cause problems with other tomcat applications. >>> >> These concern me deeply. Why do we need these changes that affect all >> webapps? >> >> The "Of course, you'll need to test..." clause is the complicated >> one. >> Every time these libraries are updated, or \ >> we add a new webapp, or we update a webapp, we'll be concerned about >> conflicts. >> >> Is this really needed? Can you explain further? |
||||||||||||
| # | Mon Oct 20 09:40:02 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi, about the location of trustmanager and dependencies, like bcprov... we discussed this when we deployed CEMon last time. Trustmanager was left in the application environment, but the bcprov was put in the common location. Despite the fact that the configuration was easier, the philosophical justification to having the security libs in a common location was that administrators were allowed to set global policies for all applications at once. I do not know how much the philosophical justification holds and there are certainly practical reasons to do this: what I know is that every time that we deploy a new version of one of these applications, the issue of the location of these dependencies comes back. I wonder if we could simplify the deployment, somehow. At any rate, we discussed this in a long thread with Tim et al. on May 6, 2008. I'm appending here his considerations for keeping bcprov in a common location. Cheers Gabriele > Begin forwarded message: > > From: Tim Cartwright <cat@cs.wisc.edu> > Date: 16 November 2005 11:02:02 CST > Subject: Re: CEMon and System properties for trustmanager > >> What was the problem when the bcprov were not moved? >> I guess I never wrote up the full story for everyone. > > First, a bit of background. The trustmanager registers an instance of > the BouncyCastleProvider class with the Java Security class: > > Security.addProvider(new BouncyCastleProvider()); > > This happens (at least) in > org.edg.security.trustmanager.FileCertReader.FileCertReader() (and > yes, the particular example I provide comes from the older EDG > trustmanager, but I believe the latest gLite version works the same in > this regard). Later, there is code to get the instance of the X.509 > certificate factory from the BouncyCastle provider: > > certFactory = CertificateFactory.getInstance("X.509", "BC"); > > This is all fine -- for one webapp. > > Now suppose each webapp has its own copy of (the exact same) > bcprov*.jar file (and trustmanager, etc.). The first webapp to > register its BouncyCastleProvider instance wins, in that later > attempts will not cause the matching instance to be replaced; see the > JavaDoc for Security.addProvider(...) for more details. > > Let's say that VOMS Admin registers its provider first. The object it > registered was instantiated from a class loaded by Tomcat's > webapp-specific classloader. I don't understand all the details, but > this object is NOT available to other webapps. So, suppose GUMS comes > along and uses the trustmanager. It tries to register its own > BouncyCastleProvider instance, but fails, because there's already a > matching one in the system-wide Security class. Thus, the VOMS Admin > object is still in there. Then, GUMS (via the trustmanager) tries to > get the BC X.509 certificate factory. This fails, because the VOMS > Admin-registered BouncyCastleProvider instance is not available to the > GUMS webapp. Thus, GUMS fails. > > I believe the only solution is to move all copies of the bcprov*.jar > file out of their individual webapps and into a shared Tomcat > directory. It doesn't work to leave the JAR file in the webapp, > because Tomcat's classloader system prefers webapp-local JAR files > over Tomcat-shared ones. This is the solution I have implemented in > the VDT, and it appears to work. > > Taking a step back from the details, I think this solution makes > sense. The Bouncy Castle JAR provides a global resource, managed by > the JVM-global Security class. It's fitting, to my eyes at least, that > there be only one copy of a global resource in all of Tomcat. > > One consequence of this solution is that all webapps running under one > instance of Tomcat must agree on a version of the JAR file to use. So > far, the three webapps we run under Tomcat 5 agree, but when those > webapps need to upgrade, we'll have to be careful to coordinate. > >> what is the * when written open? I think there should be only one >>> file bcprov-jdk14-122.jar in the system, but installed in several >> locations, to the server/lib of tomcat and to each webapp. No other >> bc* files should be necesary and neither should it be anywhere else. > bcprov-jdk14-122.jar > > Based on my experience trying to fix this bug and on reading the > Tomcat classloader documentation carefully, I disagree with one part > of your statement: "but installed ... to each webapp". I believe there > must be only one copy in all of Tomcat -- see comments above. > Empirically, GUMS still didn't work when VOMS Admin contained its > webapp copy of the JAR file and there was a shared Tomcat copy. > > Also, there may be other copies of the JAR file floating around in a > full VDT installation, but I think that's because some apps have a > second copy for standalone Java applications; in those cases, the > second copy is outside of Tomcat. > > Any questions or suggestions for future experiments? > > -- > Tim Cartwright, Condor Project & VDT > University of Wisconsin-Madison, Computer Science Dept. > 1210 West Dayton Street, Room 4265; Madison, WI 53706; USA > Tel: +1 608 262 4002 / Email: cat@cs.wisc.edu Jay Packard via RT wrote: > Hi Alain, > > Glad to hear most of them are straight forward. > > You don't need to pass a DN to addGIPProbeToDatabase script - the DN is > inside - just run the script. > > There is no particular reason to update the dependencies besides staying > current and partaking of bug fixes and possible performance improvements > in the later versions, especially for the glite libraries that have > "dev" attached to them, suggesting a beta version. Isn't that reason > enough? > > Jay > > Alain Roy via RT wrote: > >> I'm resending this, this time through the ticket. If we can communicate >>> here, it will be useful. Thanks! >> >> --------------------------- >> >> Thanks Jay! I have a couple of questions. >> >> On Oct 16, 2008, at 11:27 AM, Jay Packard wrote: > Hi Alain and Tim, > >> >> >>> We are ready to start packaging GUMS 1.3.0 into the VDT. The server >> http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war>>> can be downloaded from >>> >>> >>> >> >> >>> and the client from >> http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz.>>> >>> >>> >> >> >>> You should follow the same procedure as you have before but also do >> the following:>>> >>> >> >> >>> * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" during >> These sound straightforward.>>> upgrades to import the data from the old schema to the new. >>> * add the ...gums/WEB-INF/scripts directory to the classpath. This >>> was supposed to have been done for the last release. >>> >>> >> >> >> >>> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied >> These concern me deeply. Why do we need these changes that affect all>>> from the ...gums/WEB-INF/lib directory into >>> ...tomcat/common/endorsed. Also copy >>> glite-security-trustmanager-1.8.16.jar and >>> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >>> directory into ../tomcat/server/lib (and remove the older glite >>> jars). Of course you'll need to test that these global dependency >>> updates do not cause problems with other tomcat applications. >>> >>> >> webapps? >> >> The "Of course, you'll need to test..." clause is the complicated one. >> Every time these libraries are updated, or \ >> we add a new webapp, or we update a webapp, we'll be concerned about >> conflicts. >> >> Is this really needed? Can you explain further? >> >> >> >>> * Add a new prima test to test the new GUMS XACML interface (please >> Sure, this shouldn't be hard.>>> talk with Igor about this). >>> >>> >> >> >> >>> * Update GUMS documentation URLs by replacing 1.2 with 1.3. I will >> OK.>>> be updating the documentation in the next 2 weeks. >>> >>> >> >> >> >>> * run "mysql < .../gums/WEB-INF/sql/addGIPProbeToDatabase.mysql" on >> new installations to add the GIP probe DN.>>> >>> >> >> Can you clarify this a bit? Do we pass the DN as a parameter somehow? >> I'm confused. >> >> Thanks, >> -alain >> >> >> >> >> > > > ------------------------------------------------------------------------ > > Hi Alain, > > Glad to hear most of them are straight forward. > > You don't need to pass a DN to addGIPProbeToDatabase script - the DN is inside - > just run the script. > > There is no particular reason to update the dependencies besides staying current > and partaking of bug fixes and possible performance improvements in the later > versions, especially for the glite libraries that have "dev" attached to them, > suggesting a beta version. Isn't that reason enough? > > Jay > > Alain Roy via RT wrote: > > I'm resending this, this time through the ticket. If we can communicate > > > here, it will be useful. Thanks! > > > > --------------------------- > > > > Thanks Jay! I have a couple of questions. > > > > On Oct 16, 2008, at 11:27 AM, Jay Packard wrote: > Hi Alain and Tim, > > > > >> We are ready to start packaging GUMS 1.3.0 into the VDT. The server > > http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.0/gums-service-1.3.0.war> >> can be downloaded from > >> > >> > > > >> and the client from > > http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.0/gums-client-1.3.0-bin.tar.gz.> >> > >> > > > >> You should follow the same procedure as you have before but also do > > the following:> >> > > > >> * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" during > >> >> upgrades to import the data from the old schema to the new. > >> * add the ...gums/WEB-INF/scripts directory to the classpath. This > >> was supposed to have been done for the last release. > >> > > These sound straightforward. > > > > > >> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied > >> >> from the ...gums/WEB-INF/lib directory into > >> ...tomcat/common/endorsed. Also copy > >> glite-security-trustmanager-1.8.16.jar and > >> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib > >> directory into ../tomcat/server/lib (and remove the older glite > >> jars). Of course you'll need to test that these global dependency > >> updates do not cause problems with other tomcat applications. > >> > > These concern me deeply. Why do we need these changes that affect all > > webapps? > > > > The "Of course, you'll need to test..." clause is the complicated one. > > Every time these libraries are updated, or \ > > we add a new webapp, or we update a webapp, we'll be concerned about > > conflicts. > > > > Is this really needed? Can you explain further? > > > > > >> * Add a new prima test to test the new GUMS XACML interface (please > >> >> talk with Igor about this). > >> > > Sure, this shouldn't be hard. > > > > > >> * Update GUMS documentation URLs by replacing 1.2 with 1.3. I will > >> >> be updating the documentation in the next 2 weeks. > >> > > OK. > > > > > >> * run "mysql < .../gums/WEB-INF/sql/addGIPProbeToDatabase.mysql" on > > new installations to add the GIP probe DN.> >> > > > > Can you clarify this a bit? Do we pass the DN as a parameter somehow? > > I'm confused. > > > > Thanks, > > -alain > > > > > > > > Message body not shown because it is too large or is not plain text. |
||||||||||||||
| # | Mon Oct 20 11:20:03 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
It's for the sake of "bug fixes and possible performance improvements". For example, the admins at Michigan have had to restart their tomcat running GUMS every so often (we don't have this problem at BNL so I can't debug it), and I've updated several library dependencies in hopes that this will fix their problem. As another example, I've had problems on my test machine when redeploying multiple times (I end up having to restart tomcat) and these updates seems to have already solved this problem. What I mean by the "dev" comment, is the library used by GUMS 1.2 is glite-security-trustmanager--1.6.3dev.jar and glite-security-util-java-1.0.0dev.jar, which makes me nervous to be using. Only applications that use the glite library for handling grid certificates and/or the xml-apis and xerces would be updated. I'm not sure how many there are. Also, having such a good testbed as you have should help you feel more confident in trying updates. Also, would you please use GUMS 1.3.1 instead of 1.3.0 at http://grid.racf.bnl.gov/mvn/gums/gums-service/1.3.1/gums-service-1.3.1.war and http://grid.racf.bnl.gov/mvn/gums/gums-client/1.3.1/gums-client-1.3.1-bin.tar.gz? A new version of opensaml was just released because of a bug fix and I fixed a bug in GUMS where removing a banned user did not update the matching list. There is no interface changes from 1.3.0 so you just need to drop it in. Jay Alain Roy via RT wrote: > I'm not sure I follow your answer. I don't understand why GUMS needs > to make changes that affect the running of all webapps and Catalina > itself. Can you explain further? > > -alain > > On Oct 17, 2008, at 2:36 PM, Jay Packard via RT wrote: > >> There is no particular reason to update the dependencies besides >>> staying >> current and partaking of bug fixes and possible performance >> improvements >> in the later versions, especially for the glite libraries that have >> "dev" attached to them, suggesting a beta version. Isn't that reason >> enough? >> >> Jay >> >> Alain Roy via RT wrote: >> >>>> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied >>> These concern me deeply. Why do we need these changes that affect all>>>> from the ...gums/WEB-INF/lib directory into >>>> ...tomcat/common/endorsed. Also copy >>>> glite-security-trustmanager-1.8.16.jar and >>>> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >>>> directory into ../tomcat/server/lib (and remove the older glite >>>> jars). Of course you'll need to test that these global >>>> dependency >>>> updates do not cause problems with other tomcat applications. >>>> >>>> >>> webapps? >>> >>> The "Of course, you'll need to test..." clause is the complicated >>> one. >>> Every time these libraries are updated, or \ >>> we add a new webapp, or we update a webapp, we'll be concerned about >>> conflicts. >>> >>> Is this really needed? Can you explain further? >>> > > |
||||||||||||||
| # | Mon Oct 20 17:00:26 2008 | roy - Correspondence added | [Reply] | |||||||||
On Oct 20, 2008, at 11:20 AM, Jay Packard via RT wrote: > It's for the sake of "bug fixes and possible performance > improvements". > For example, the admins at Michigan have had to restart their tomcat > running GUMS every so often (we don't have this problem at BNL so I > can't debug it), and I've updated several library dependencies in > hopes > that this will fix their problem. As another example, I've had > problems > on my test machine when redeploying multiple times (I end up having to > restart tomcat) and these updates seems to have already solved this > problem. What I mean by the "dev" comment, is the library used by > GUMS > 1.2 is glite-security-trustmanager--1.6.3dev.jar and > glite-security-util-java-1.0.0dev.jar, which makes me nervous to be > using. Only applications that use the glite library for handling grid > certificates and/or the xml-apis and xerces would be updated. I'm not > sure how many there are. Also, having such a good testbed as you have > should help you feel more confident in trying updates. I really don't understand how the location that the files are deployed in affects the ability to deploy bug fixes. You're proposing changing the behavior of the entire Tomcat installation, which I would prefer not to do, if possible. For example, in our VDT nightly tests, we test GUMS and VOMS by installing both within the same VDT installation (and same Tomcat instance): how will the changes you propose affect VOMS or other components that we are testing? I spoke with Gabriele this afternoon. My understanding is that you really need the XML parser updates to be available across Tomcat, not just in the webapp. Do you know if the APIs changed, or if this just provides bug fixes and new features? This will help us understand the safety of doing this. I understand that Gabriele has asked you to test putting the trustmanager in the GUMS webapp, and you'll email with the results of your testing. Thanks, -alain |
||||||||||||
| # | Mon Oct 20 17:00:28 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, I was mistaken. The glite jars are not in the server/lib when downloading gums 1.2.* from the VDT as I thought they were. They are only needed there when run in stand-alone tomcat mode (vs behind Apache as in the VDT). So I just tested GUMS in the VDT environment (both the older opensaml and the newer xacml interface) and it works without the glite jars. Sorry about that confusion. However, I've verified that the new xacml interface doesn't work without the xercesImpl and xml-apis jars in common/endorsed. This is because of the order of classpath loading in tomcat. We don't know of a way to programmically avoid this. Jay Alain Roy via RT wrote: > I'm not sure I follow your answer. I don't understand why GUMS needs > to make changes that affect the running of all webapps and Catalina > itself. Can you explain further? > > -alain > > On Oct 17, 2008, at 2:36 PM, Jay Packard via RT wrote: > >> There is no particular reason to update the dependencies besides >>> staying >> current and partaking of bug fixes and possible performance >> improvements >> in the later versions, especially for the glite libraries that have >> "dev" attached to them, suggesting a beta version. Isn't that reason >> enough? >> >> Jay >> >> Alain Roy via RT wrote: >> >>>> * Ensure that xercesImpl-2.8.0.jar and xml-apis-2.9.1.jar is copied >>> These concern me deeply. Why do we need these changes that affect all>>>> from the ...gums/WEB-INF/lib directory into >>>> ...tomcat/common/endorsed. Also copy >>>> glite-security-trustmanager-1.8.16.jar and >>>> glite-security-util-java-1.3.8.jar from the ...gums/WEB-INF/lib >>>> directory into ../tomcat/server/lib (and remove the older glite >>>> jars). Of course you'll need to test that these global >>>> dependency >>>> updates do not cause problems with other tomcat applications. >>>> >>>> >>> webapps? >>> >>> The "Of course, you'll need to test..." clause is the complicated >>> one. >>> Every time these libraries are updated, or \ >>> we add a new webapp, or we update a webapp, we'll be concerned about >>> conflicts. >>> >>> Is this really needed? Can you explain further? >>> > > |
||||||||||||||
| # | Mon Oct 20 17:10:25 2008 | roy - Correspondence added | [Reply] | |||||||||
On Oct 20, 2008, at 5:00 PM, Jay Packard via RT wrote: > I was mistaken. The glite jars are not in the server/lib when > downloading gums 1.2.* from the VDT as I thought they were. They are > only needed there when run in stand-alone tomcat mode (vs behind > Apache > as in the VDT). So I just tested GUMS in the VDT environment (both > the > older opensaml and the newer xacml interface) and it works without the > glite jars. Sorry about that confusion. Great, thanks! > However, I've verified that the new xacml interface doesn't work > without > the xercesImpl and xml-apis jars in common/endorsed. This is > because of > the order of classpath loading in tomcat. We don't know of a way to > programmically avoid this. OK, we'll need to investigate this just a bit deeper then. Do you understand if the new version changes any APIs, or just is bug fixes and new features? May it break other applications running in the same Tomcat instance? Thanks, -alain |
||||||||||||
| # | Tue Oct 21 13:27:24 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, Was Ted's explanation sufficient or do we need to look into this further? Jay Alain Roy via RT wrote: > On Oct 20, 2008, at 5:00 PM, Jay Packard via RT wrote: > >> I was mistaken. The glite jars are not in the server/lib when >>> downloading gums 1.2.* from the VDT as I thought they were. They are >> only needed there when run in stand-alone tomcat mode (vs behind >> Apache >> as in the VDT). So I just tested GUMS in the VDT environment (both >> the >> older opensaml and the newer xacml interface) and it works without the >> glite jars. Sorry about that confusion. >> > Great, thanks! > > >> However, I've verified that the new xacml interface doesn't work >>> without >> the xercesImpl and xml-apis jars in common/endorsed. This is >> because of >> the order of classpath loading in tomcat. We don't know of a way to >> programmically avoid this. >> > OK, we'll need to investigate this just a bit deeper then. Do you > understand if the new version changes any APIs, or just is bug fixes > and new features? May it break other applications running in the same > Tomcat instance? > > Thanks, > -alain > > > |
||||||||||||||
| # | Tue Oct 21 13:35:20 2008 | roy - Correspondence added | [Reply] | |||||||||
Yup, I think so. Thanks! -alain On Oct 21, 2008, at 1:27 PM, Jay Packard via RT wrote: > Hi Alain, > > Was Ted's explanation sufficient or do we need to look into this > further? > > Jay |
||||||||||||
| # | Tue Oct 21 16:30:24 2008 | roy - Priority changed from (no value) to '3' | ||
| # | Tue Oct 21 16:30:26 2008 | roy - Fix scheduled CUR added | ||
| # | Mon Nov 03 11:33:13 2008 | kronenfe - Stolen from roy | ||
| # | Thu Nov 06 13:27:59 2008 | kronenfe - Correspondence added | [Reply] | |
|
Hi Jay, I have upgraded to GUMS 1.3.3, and I am testing my changes to the configure_gums script. > You should follow the same procedure as you have before but also do > the following: > * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" > during > upgrades to import the data from the old schema to the new. I am getting an error when trying to import an old 1.1 database. Here's the error: ### 2008-11-06 13:18:42 (failsafe_system) /home/kronenfe/test/mysql/bin/mysql -u root </home/kronenfe/test/tomcat/v55/webapps/g ums/WEB-INF/sql/importFrom1.1to1.3.mysql ERROR 1062 (23000) at line 2: Duplicate entry '1' for key 1 Prior to executing the sql statements in importFrom1.1to1.3.mysql, I am setting up the 1.3 database with the gums-setup-mysql-database script. > * add the ...gums/WEB-INF/scripts directory to the classpath. > This > was supposed to have been done for the last release. Do you mean the path, not the classpath? We made a decision to not include this directory in the path because the scripts in here are either only used by scripts (gums-create-config gums-setup-mysql-database), or are used one time (gums-add-mysql-admin). |
||||
| # | Thu Nov 06 14:23:38 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Scot Kronenfeld via RT wrote: > Hi Jay, The database should be completely empty after running > I have upgraded to GUMS 1.3.3, and I am testing my changes to the > configure_gums script. > > >> You should follow the same procedure as you have before but also do >>> the following: >> * run "mysql < ...gums/WEB-INF/sql/importFrom1.1to1.3.mysql" >> during >> upgrades to import the data from the old schema to the new. >> > I am getting an error when trying to import an old 1.1 database. Here's > the error: > > ### 2008-11-06 13:18:42 (failsafe_system) > /home/kronenfe/test/mysql/bin/mysql -u root <> /home/kronenfe/test/tomcat/v55/webapps/g > ums/WEB-INF/sql/importFrom1.1to1.3.mysql > ERROR 1062 (23000) at line 2: Duplicate entry '1' for key 1 > > Prior to executing the sql statements in importFrom1.1to1.3.mysql, I am > setting up the 1.3 database with the gums-setup-mysql-database script. > gums-setup-mysql-database. I removed the automatic insertion of the GIP probe DN. Can you tell me if the database is completely empty after running the gums-setup-mysql-database script? > Yes, path>> * add the ...gums/WEB-INF/scripts directory to the classpath. >>> This >> was supposed to have been done for the last release. >> > Do you mean the path, not the classpath? > We made a decision to not gums-add-mysql-admin could be run multiple times. gums-create-config > include this directory in the path because the scripts in here are > either only used by scripts (gums-create-config > gums-setup-mysql-database), or are used one time (gums-add-mysql-admin). > could very well be used more than once, such as to upgrade to the latest osg template. For these reasons I think they should be in the path. |
||||||||||||||
| # | Thu Nov 06 16:03:11 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
> The database should be completely empty after running > gums-setup-mysql-database. I removed the automatic insertion of the GIP > probe DN. Can you tell me if the database is completely empty after > running the gums-setup-mysql-database script? Ahh, that was the problem. Because of the flow of the configure_gums script, I was calling the sql in addGIPProbeIDtoDatabase.mysql before running the import script. I've revised the script, and everything is working now. You can test the new GUMS and PRIMA with the following commands. Setting OLD_VDT_LOCATION is optional, if you do so, the GUMS 1.1 database will be copied from that location and imported into GUMS 1.3. export OLD_VDT_LOCATION=/some/path pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache: Thanks, scot |
||||||||||||
| # | Thu Nov 06 16:04:09 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
I forgot the package name in the pacman command. It should be: export OLD_VDT_LOCATION=/some/path # GUMS Service and GUMS Client pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMSOR # Just GUMS Service pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMS-Service |
||||||||||||
| # | Fri Nov 07 10:51:04 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Scot, just to double check... is it true that the new database will still have the probe information, at the end of the configuration? Thanks Gabriele Scot Kronenfeld via RT wrote: >> The database should be completely empty after running >>> gums-setup-mysql-database. I removed the automatic insertion of the GIP >> probe DN. Can you tell me if the database is completely empty after >> running the gums-setup-mysql-database script? >> > Ahh, that was the problem. Because of the flow of the configure_gums > script, I was calling the sql in addGIPProbeIDtoDatabase.mysql before > running the import script. I've revised the script, and everything is > working now. > > You can test the new GUMS and PRIMA with the following commands. > Setting OLD_VDT_LOCATION is optional, if you do so, the GUMS 1.1 > database will be copied from that location and imported into GUMS 1.3. > > export OLD_VDT_LOCATION=/some/path > pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache: > > Thanks, > scot > > > |
||||||||||||||
| # | Fri Nov 07 16:19:17 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
On Fri, Nov 7, 2008 at 10:51 AM, garzoglio@fnal.gov via RT <vdt-support@opensciencegrid.org> wrote: > just to double check... is it true that the new database will still have > the probe information, at the end of the configuration? You mean the sql code in addGIPProbeIDtoDatabase.mysql? Yes, that should always be run (and now it will run after the import, if applicable). |
||||||||||||
| # | Mon Nov 10 09:29:28 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||
Hi Scot, I tried downloading GUMS from the VDT with OLD_VDT_LOCATION set to an old one. GUMS_1_3 (instead of GUMS_1_1) should be passed as part of the --host parameter for the gums-setup-mysql-database script. Even when I changed this in the GUMS configuration, though, GUMS still can't access the database. I've checked that mysql is running on the right port and that the grants seem correctly setup. Any other ideas as to why this isn't working? Jay Scot Kronenfeld via RT wrote: > I forgot the package name in the pacman command. It should be: > > export OLD_VDT_LOCATION=/some/path > > # GUMS Service and GUMS Client > pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMS> > OR > > # Just GUMS Service > pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMS-Service> > > |
||||||||||||
| # | Mon Nov 10 10:34:28 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||
It looks like the password is that of the OLD_VDT_LOCATION. It should be the password of the new GUMS_1_3 in the new vdt location. Also, I need to update the addGIPProbeIDtoDatabase.mysql script to only insert it only if it doesn't already exist, which I'll do soon. Jay Jay Packard wrote: > Hi Scot, > > I tried downloading GUMS from the VDT with OLD_VDT_LOCATION set to an > old one. GUMS_1_3 (instead of GUMS_1_1) should be passed as part of > the --host parameter for the gums-setup-mysql-database script. Even > when I changed this in the GUMS configuration, though, GUMS still > can't access the database. I've checked that mysql is running on the > right port and that the grants seem correctly setup. Any other ideas > as to why this isn't working? > > Jay > > Scot Kronenfeld via RT wrote: >> I forgot the package name in the pacman command. It should be: >> >> export OLD_VDT_LOCATION=/some/path >> >> # GUMS Service and GUMS Client >> pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMS>> >> OR >> >> # Just GUMS Service >> pacman -get http://vdt.cs.wisc.edu/vdt_11098_cache:GUMS-Service>> >> >> |
||||||||||||
| # | Mon Nov 10 11:48:17 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
On Mon, Nov 10, 2008 at 10:34 AM, Jay Packard via RT <vdt-support@opensciencegrid.org> wrote: > It looks like the password is that of the OLD_VDT_LOCATION. It should > be the password of the new GUMS_1_3 in the new vdt location. Thanks for catching this, I've fixed these two issues, the hostname and password are now set correctly. > Also, I need to update the addGIPProbeIDtoDatabase.mysql script to only > insert it only if it doesn't already exist, which I'll do soon. Just let me know when you have an update. |
||||||||||||
| # | Mon Nov 10 12:10:31 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Do you prefer entire version upgrades, or are you OK with just the file (which is attached)? Scot Kronenfeld via RT wrote: > On Mon, Nov 10, 2008 at 10:34 AM, Jay Packard via RT > <vdt-support@opensciencegrid.org> wrote: > >> It looks like the password is that of the OLD_VDT_LOCATION. It should >>> be the password of the new GUMS_1_3 in the new vdt location. >> > Thanks for catching this, I've fixed these two issues, the hostname > and password are now set correctly. > > >> Also, I need to update the addGIPProbeIDtoDatabase.mysql script to only >>> insert it only if it doesn't already exist, which I'll do soon. >> > Just let me know when you have an update. > > > USE GUMS_1_3; DELETE FROM USER WHERE DN="/GIP-GUMS-Probe-Identity" AND GROUP_NAME="gums-test"; INSERT INTO USER SET DN="/GIP-GUMS-Probe-Identity", GROUP_NAME="gums-test"; |
||||||||||||||
| # | Mon Nov 10 12:19:16 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
On Mon, Nov 10, 2008 at 12:10 PM, Jay Packard via RT <vdt-support@opensciencegrid.org> wrote: > Do you prefer entire version upgrades, or are you OK with just the file > (which is attached)? Can you please release a new tarball? It is much easier for us. Thanks, scot |
||||||||||||
| # | Mon Nov 10 13:15:18 2008 | jpackard@bnl.gov - Correspondence added | [Reply] | |||||||||||
Hi Scot, We are trying to figure out which versions of the glite jars we want to use. Please let us decide on this before I release a new war. It's not a big deal that the GIP probe DN is in the database twice. Thanks, Jay Scot Kronenfeld via RT wrote: > On Mon, Nov 10, 2008 at 12:10 PM, Jay Packard via RT > <vdt-support@opensciencegrid.org> wrote: > >> Do you prefer entire version upgrades, or are you OK with just the file >>> (which is attached)? >> > Can you please release a new tarball? It is much easier for us. > > Thanks, > scot > > > |
||||||||||||||
| # | Mon Nov 10 13:40:16 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Jay, I would say that if we cannot converge on the new jars within a day, max two, we should go ahead with the old ones. We know that those are stable and we are not really using features from the new jars. We should clearly understand how to upgrade to the new jars for a future release. Cheers Gabriele Jay Packard via RT wrote: > Hi Scot, > > We are trying to figure out which versions of the glite jars we want to > use. Please let us decide on this before I release a new war. It's not > a big deal that the GIP probe DN is in the database twice. > > Thanks, > Jay > > Scot Kronenfeld via RT wrote: > >> On Mon, Nov 10, 2008 at 12:10 PM, Jay Packard via RT >>> <vdt-support@opensciencegrid.org> wrote: >> >> >>> Do you prefer entire version upgrades, or are you OK with just the file >> Can you please release a new tarball? It is much easier for us.>>> (which is attached)? >>> >>> >> >> Thanks, >> scot >> >> >> >> > > > ------------------------------------------------------------------------ > > Hi Scot, > > We are trying to figure out which versions of the glite jars we want to use. > Please let us decide on this before I release a new war. It's not a big deal > that the GIP probe DN is in the database twice. > > Thanks, > Jay > > Scot Kronenfeld via RT wrote: > > On Mon, Nov 10, 2008 at 12:10 PM, Jay Packard via RT > > > <vdt-support@opensciencegrid.org> wrote: > > > >> Do you prefer entire version upgrades, or are you OK with just the file > >> >> (which is attached)? > >> > > Can you please release a new tarball? It is much easier for us. > > > > Thanks, > > scot > > > > > > |
||||||||||||||
| # | Wed Nov 12 09:50:24 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi, I was wondering if there was any progress on this front. How far are we from packaging the new GUMS? Thanks Gabriele Scot Kronenfeld via RT wrote: > On Mon, Nov 10, 2008 at 12:10 PM, Jay Packard via RT > <vdt-support@opensciencegrid.org> wrote: > >> Do you prefer entire version upgrades, or are you OK with just the file >>> (which is attached)? >> > Can you please release a new tarball? It is much easier for us. > > Thanks, > scot > > > |
||||||||||||||
| # | Mon Nov 17 09:46:21 2008 | roy - Queue changed from vdt-support to vdt-internal | ||
| # | Thu Nov 20 17:43:59 2008 | kronenfe - Reference to ticket #4250 added | ||
| # | Mon Dec 08 09:47:31 2008 | cat - Priority changed from '3' to '-3' | ||
| # | Tue Apr 21 15:59:23 2009 | kronenfe - Status changed from 'open' to 'resolved' | ||
| # | Tue Apr 21 15:59:23 2009 | kronenfe - Fixed in 1.10.1v added | ||
Time to display: 5.130482
»|« RT 3.8.2 Copyright 1996-2008 Best Practical Solutions, LLC.
