5569 2007-09-16 22:25 use absolute paths in configuration files 2008-04-25 21:12:04 1 1 1 Unclassified GridShib GT plugin 0.6 PC Linux RESOLVED FIXED http://fisheye.globus.org/changelog/GlobusToolkit/?cs=gridshib_gt_0_6_0_branch:tfreeman:20070918025943 P3 enhancement 0.6.0 alpha 5568 1 tfreeman@mcs.anl.gov tfreeman@mcs.anl.gov gridshib-dev@globus.org trscavo@gmail.com vwelch@uiuc.edu tfreeman@mcs.anl.gov 2007-09-16 22:25:29 Using relative paths in the echo service's configuration files is the result of a balancing act between providing an out of the box configuration file for the echo service and a good configuration file. It is (I think) currently our recommendation to never use relative paths for service configurations -- but with the echo and test service's we wanted to provide good defaults to get the user going as quickly as possible with the least chance for errors/confusion. In general if relative paths are used, the interceptor configurations have an ambiguous job to do. For example, one could treat the current working directory (CWD) as the only place to base relative paths from or alternatively try several known locations in a certain order. e.g. 1. CWD, 2. GLOBUS_LOCATION (obtained from environment or container axis property), 3. /etc/grid-security. It's my opinion at least that any list or order here is suboptimal. The only OK relative path scheme in my opinion is to use CWD only. It is easy to explain and in most cases will avoid misconfiguration. But this restricts the container to being started from the actual GLOBUS_LOCATION which is not good for many reasons: - detached init.d scripts shouldn't have to worry about CWD - starting tests from the tests or GS4GT source directory is much more convenient than finding the ant tests file via the -f parameter from GLOBUS_LOCATION - potential ambiguity when the interceptors are running in other containers such as Tomcat - etc. In general, it would be simpler and safer to just require absolute paths. But then we could potentially lose the out of the box echo service (and of lesser importance convenient testing). I suggest we write the absolute deployment paths into the config files in a post-deploy task and just require absolute paths across the board. These are orthogonal things though, we could decide here to write absolute paths to the echo service's config files (and the end to end test service) without actually ruling out relative paths for interceptor configurations. The rest of this bug report deals with the former thing: Currently the relative paths for the 4.0 echo service come from deploy-server.wsdd "@config.dir@" replacement. The 4.1+ echo service relative paths are hard coded into the example security descriptor. Since the version number for the package is part of the package's $GL/etc directory, this is especially aggravating because a version update means we need to update that file manually. See Bug #5194 In the service build steps we could generate the relative portion of the version-dependent etc directory name using ant's copy+filter capabilities with a special token. All we would need to do is change the GAR builder's etc directory configuration in the ant script from the present etc directory to a build/etc directory that contains the copy+replaced file(s). Then in post-deploy, the absolute path to GLOBUS_LOCATION could be appended into the configurations. It is important this happens in post-deploy because that way generated binaries can still be deployed to any $GL. So there would be two tokens, one used to replace the package name during the build and one used to replace GLOBUS_LOCATION at deployment. For example: OLD 4.0: <parameter name="secctxecho-gridshibAuthzPolicyFile" value="@config.dir@/echo-attr-authz-vo.xml"/> OLD 4.1: <param:parameter name="gridshibAuthzPolicyFile" value="etc/gridshib-gt-echo-0_6_0-tp4/echo-attr-authz-vo.xml"/> NEW: value="@GS4GT_GL@/etc/@GS4GT_PACKAGENAME@/echo-attr-authz-vo.xml" The build files replace @GS4GT_PACKAGENAME@ with the right (version embedded) package name. The post-deploy task replaces @GS4GT_GL@ with the target GLOBUS_LOCATION absolute path. trscavo@gmail.com 2007-09-17 06:28:44 I think the suggestion to inject replaceable tokens into the config files of services we distribute makes sense. However, deployers should be advised not to use these tokens since it is safest to store config files outside $GL, otherwise users run the risk of clobbering their configs. We should illustrate the use of "safe" absolute paths in the GS4GT documentation. In fact, there's probably no need to mention the token mechanism at all in the GS4GT user documentation. tfreeman@mcs.anl.gov 2007-09-17 17:11:39 I agree. And they would not even have access to the token replacement ant scripting unless they went in and copied it explicitly. What do you think about the interceptors not accepting relative path configurations at all? trscavo@gmail.com 2007-09-17 17:23:16 (In reply to comment #2) > > What do you think about the interceptors not accepting relative path > configurations at all? Assuming the token replacement feature outlined in the Description, I don't think that's a problem at all. tfreeman@mcs.anl.gov 2007-09-17 22:04:16 Committed implementation to gridshib_gt_0_6_0_branch http://fisheye.globus.org/changelog/GlobusToolkit/?cs=gridshib_gt_0_6_0_branch:tfreeman:20070918025943 Implemented dynamic path generation for the echo and test service files that needed it (templates stored under the new "templates" directories) as well as the rejection of relative path configurations in the interceptors.