Index of /pdp/files/packages/vocachedir

Icon  Name                             Last modified      Size  
[PARENTDIR] Parent Directory - [TXT] README.txt 2009-02-16 23:00 2.8K [   ] vocachedir-init-0.1-1.noarch.rpm 2009-02-16 22:26 6.5K [   ] vocachedir-init-0.1-1.src.rpm 2009-02-16 22:26 31K [   ] vocachedir-init-0.1.src.tgz 2009-02-16 22:26 29K

The VO Cache Directory Profile Initialisation

This script set, usable for the Bourne shell and, with also for the C-shell
if the Bourne shell is installed, will add the VO_xxx_CACHE_DIR environment
variable to the users' job environment if such a per-VO specific directory 
can be located in one of a few places.

By default, it will look for VO cache directories under:

  Set the VO_xxx_CACHE_DIR variable when appropriate, based on a list of
  possible base directories for such a cache. The script will accept any
  incoming VONAME definition (such as set by the globus Job Manager patch)
  but failing that will try to determine the VO based on the VOMS proxy.

  Put these script in the /etc/profile.d directory, and have them executed
  as early as possible. The default installation will ensure that by 
  prefixing the name with "AA". 

Configuration: will read /etc/sysconfig/vocachedir
  Set CACHEBASES to a list of directory paths to which the voname (in
  lower case) will be appended to name the actual cache directory. Its
  permissions MUST be at least 01755 (i.e. the directory MUST be sticky)
  and it MUST be owned by root

Note: the script will NOT do cleanup of this directory, use tmpwatch(8)
for that.

For the full semantics of the VO cache directory at Nikhef, please refer
to our Wiki pages at

In particular note the way you should write to the cache directory: since
multiple users may write there (it's only sticky but otherwise wide open)
you're vulnerable to all the default race conditions and exploits to which
mkstemp(3) provides the remedy. So, PLEASE USE mktemp(1) and friends to
create files in the VO_xxx_CACHE_DIR.

About the patch
The patch, to be applied to the setup file (which will later
generate the job manager script), will ensure that the VONAME
environment variable is set as soon as possible, even if on the worker node
there is no proxy or no voms-proxy-info command available. Especially
if you have 'non-griddy' worker nodes, this may come in handy. 
When $VONAME is already set, the script will NOT need 
the voms-proxy-info command. 

After applying this to a 3.1 lcg-CE, you need to regenerate the
file (using the globus setup tools) AND restart the globus-job-manager-marshal
process (service globus-job-manager-marshal restart).

Basically, only /bin/sh is needed (or /bin/csh for the csh variety). Only
if the VONAME environment variable is not yet set will voms-proxy-info be
needed on the worker node. 
This has not been put in as a dependency of the RPM, since the script will
degrade gracefully (to the NULL operation) if this command is missing.