6342 2008-08-27 18:16 remove dependency on abs paths from properties files 2008-09-03 09:39:38 1 1 1 Unclassified GridShib SAML/Binding Tools 0.5 All All RESOLVED FIXED P3 normal beta 6167 1 trscavo@gmail.com trscavo@gmail.com gridshib-dev@globus.org trscavo@gmail.com 2008-08-27 18:16:20 On Wed, Aug 27, 2008 at 12:10 PM, Von Welch <vwelch@ncsa.uiuc.edu> wrote: > Here's the deal: > > During the 'init' target, the GS-ST build.xml creates two properties > files which have hard-coded paths to the install dir: > > org/globus/gridshib/resource/gridshib-bootstrap.properties > etc/log4j.properties > > The log4j.properties isn't a big deal, 'ant init' could re-make it > any any time. > > gridshib-bootstrap.properties ends up in the jarfiles, where it is > used by the java byte code. So if you distribute the jars, you would > have to have a process to change this file in the jar, which doesn't > currently exist. > > One possible solution, and I'm pretty sure this would work with the > log4j file - not sure about the bootstrap file, is to have something > earlier in the execution set a java system property based on > GRIDSHIB_HOME (which is the install path) and then have these > properties be relative to that install path. This should allow for > relocatability without re-generating of these properties file. On Wed, Aug 27, 2008 at 1:55 PM, Von Welch <vwelch@ncsa.uiuc.edu> wrote: > What is typical with a CTSS deployment today is a distribution that > does not require compilation to deploy. We can try giving them the > current GS-ST distribution and seeing if java compilation causes > problems, but I think it is worth exploring this a little to see if > we can distribute jar files that don't place new demands on their > process. > > To be more explicit with regards to my suggestion, the url below > gives an example of what I mean. > > http://dev-answers.blogspot.com/2006/03/propertyvariable-reference-in.html > > I propose that setting gridshib.home java system property that is > use in the properties file and defined by the GS code to be equal to > the value of the GRIDSHIB_HOME environment variable. > > So then the bootstrap file would contain values such as: > gridshib.cogConfigPath=${gridshib.home}/etc/cog.properties > > Is there something about that you think won't work? vwelch@uiuc.edu 2008-08-28 10:40:24 Here's a summary of CTSS installation from JP. In short I think it matches GS-ST now fairly well, but I'm still concerned about GS-ST's requirement for javac. If we could allow them to unpack gs-st, run ant-install, tar up the resulting directory, download that, untar and just have it work (with java of course, but not requiring javac), I think we would avoid serious headaches. The changes suggested in this bug will do that I believe. --start quote from JP-- All our CTSS installs download and untar tars. The only requirement that I can think of that might be important to you is that what is downloaded must be untarable into an arbitrary path and directory. Our deployment steps are typicall: mkdir <prefix>/foo-1.2.3-r1/ cd <prefix>/foo-1.2.3-r1 soft add +pacman (need installation tools in order to install) # define environment variables needed by tool, eg GLOBUS_LOCATION pacman -install TeraGrid/ctss4/foo:foo Which typically produces: <prefix>/foo-1.2.3-r1/bin <prefix>/foo-1.2.3-r1/lib etc. In some cases, after the download untar, our installers will run software specified installation commands, such as gpt-postinstall. Almost always these commands expect the deployment to already be layed out at it's target directory. They basically configure or tweak the layed out files.. In a few rare cases, like use to be the case for older condor tars, the untarred files expect to be given a different prefix to which they copy to produce the deployment. This is messy and less than ideal. We also prefer if the tars don't include their own prefix, but we can work around it if necessary since it's fairly common for tars to do so. In other words, if foo-1.2.3.tgz untars to foo-1.2.3/, then if we do the above steps mkdir <prefix>/foo-1.2.3-r1/ cd <prefix>/foo-1.2.3-r1/ pacman -install -> which downloads and untars foo-1.2.3.tgz We end up with <prefix>/foo-1.2.3-r1/foo-1.2.3/ Again, we can clean this up by moving stuff up a level or repackaging the tar ourselves.. So, if you give us a tar we can untar and run 'ant install' to afix the install location and do other install time configuration, that would be fine. We would prefer that the 'ant install' not re-copy everything to a new target directory, but instead expect everything to already be layed out as contained in a tar. trscavo@gmail.com 2008-08-28 11:15:57 In the java sh helper script, changed this line updateOptions "GRIDSHIB_HOME" "$GRIDSHIB_HOME" to this: updateOptions "gridshib.home" "$GRIDSHIB_HOME" In the java bat helper script, changed this line set LOCAL_OPTS=-DGRIDSHIB_HOME="%GRIDSHIB_HOME%" -Djava.endorsed.dirs="%GRIDSHIB_HOME%\endorsed" to these two lines: set LOCAL_OPTS=-Dgridshib.home="%GRIDSHIB_HOME%" set LOCAL_OPTS=-Djava.endorsed.dirs="%GRIDSHIB_HOME%\endorsed" %LOCAL_OPTS% These two changes expose system property "gridshib.home" to all command-line applications. trscavo@gmail.com 2008-08-28 13:04:39 (In reply to comment #0) > > > > gridshib-bootstrap.properties ends up in the jarfiles, where it is > > used by the java byte code. So if you distribute the jars, you would > > have to have a process to change this file in the jar, which doesn't > > currently exist. More specifically, gridshib-bootstrap.properties ends up in gridshib-saml-tools-0_5_0.jar, which is not meant to be distributed or deployed outside of GS-ST. This JAR file is used by the command-line tools only. Binary deployments are expected to provide their own gridshib-bootstrap.properties file. GS4GT, for example, has its own bootstrap properties file, for instance. (This is documented in the new Developer Guide, btw.) trscavo@gmail.com 2008-08-28 14:38:30 The gridshib.home property is already defined in build.xml: <property name="gridshib.home" location="${basedir}"/> (Note that the environment variable GRIDSHIB_HOME is not needed.) Added the following nested arg to every <java> and <junit> task in build.xml: <jvmarg value="-Dgridshib.home=${gridshib.home}"/> trscavo@gmail.com 2008-09-02 12:56:58 (In reply to comment #0) > On Wed, Aug 27, 2008 at 12:10 PM, Von Welch <vwelch@ncsa.uiuc.edu> wrote: > > > > org/globus/gridshib/resource/gridshib-bootstrap.properties > > etc/log4j.properties > > > > The log4j.properties isn't a big deal, 'ant init' could re-make it > > any any time. Actually, log4j.properties is now static, that is, once GS-ST is installed, no modifications to this config file are needed, even if the installation directory is moved somewhere else in the file system. The relevant line in the config file is the following: log4j.appender.R.File=${gridshib.home}/logs/saml-tools.log This ALWAYS works, provided the gridshib.home system property is defined. trscavo@gmail.com 2008-09-02 17:32:06 (In reply to comment #0) > On Wed, Aug 27, 2008 at 12:10 PM, Von Welch <vwelch@ncsa.uiuc.edu> wrote: > > > > So then the bootstrap file would contain values such as: > > gridshib.cogConfigPath=${gridshib.home}/etc/cog.properties > > > > Is there something about that you think won't work? No, that doesn't work, at least it's not as easy as that. As it stands now, the bootstrap properties in the bootstrap properties file are assumed to be absolute paths, without exception. That said, that can be changed. If we assume the existence of system property gridshib.home, we should be able to modify BootstrapConfigLoader to resolve relative paths relative to gridshib.home. trscavo@gmail.com 2008-09-02 17:57:09 (In reply to comment #6) > > If we assume the existence of system property > gridshib.home, we should be able to modify BootstrapConfigLoader to resolve > relative paths relative to gridshib.home. This has been done. So here's how it works: - At install time, a default bootstrap properties file with absolute paths is created as exactly as before. - BootstrapConfigLoader has been modified to resolve relative paths relative to gridshib.home. If gridshib.home is null, relative paths are resolved relative to user.dir (which is system dependent). For example, consider the following bootstrap properties file: -------------BEGIN----------- #Thu Aug 28 16:34:24 EDT 2008 gridshib.logConfigPath=etc/log4j.properties gridshib.SAMLToolsConfigPath=etc/gridshib-saml-tools-config.properties gridshib.certPath=etc/testcert.pem gridshib.keyPath=etc/testkey.pem gridshib.identityAttributesPath=etc/identity-attributes.txt gridshib.cogConfigPath=etc/cog.properties -------------END----------- If you set env var GRIDSHIB_CONFIG so that it points to the above file (absolutely), then you can move the GS-ST installation at $GRIDSHIB_HOME anywhere in the file system without having to re-install. I believe this solves the problem. Let me know if I've overlooked something. trscavo@gmail.com 2008-09-02 18:12:10 Committed all resources to CVS HEAD. This patch will be distributed with GS-ST v0.5.0 RC3. vwelch@uiuc.edu 2008-09-03 09:39:38 Looks good to me.