#!/usr/bin/perl -w
#
# jobwrapper.pl - job wrapper script for condor jobs
#
# This file is referenced by the USER_JOB_WRAPPER variable
# in the condor configuration files.
#
# To create/update the condor user job environment, run the
# following recursive command from an interactive login shell.
#
# $ sudo /usr/local/condor/etc/jobwrapper.pl jobwrapper.pl

$worker_node_temp = $ENV{'_CONDOR_SCRATCH_DIR'};

# read initial job environment from the osg .conf files

foreach my $confFile ("/var/lib/osg/osg-job-environment.conf",
                      "/var/lib/osg/osg-local-job-environment.conf",
                      "/etc/condor/jobwrapper.env") {
   next if (!-r $confFile);
   open(IN,"<$confFile") || die "unable to open osg .conf file";
   while (<IN>) {
      chop $_;
      if (/=/) {
         my ($key,$value) = split(/=/,$_);
         $value =~ /^"(.*)"$/;
         $ENV{$key} = $1;
      }
   }
}

# replace the string "worker_node_temp" with the value of $_CONDOR_SCRATCH_DIR

foreach $key (keys %ENV) {
  $ENV{$key} =~ s/worker_node_temp/$worker_node_temp/;
}

# fix added for condor-nfs-lite [rtj, 6-10-2010]
# -----------------------------------------------------------------
# The condor daemons create a limited proxy from the credential used at
# condor_submit time, store it in the file x509_up in the jobdir located
# on the gatekeeper node in the homedir of the user that owns the job, and
# set the environment variable X509_USER_PROXY to point to it in the job
# context.  Normally this is not a problem because the job dir is assumed
# to be accessible on the worker nodes over nfs.  However in the case of
# condor-nfs-lite, the jobdir is not directly accessible on the worker node.
# Apparently the authors of condor-nfs-lite noticed that job was not able
# to read the file pointed to by X509_USER_PROXY, so they modified the 
# jobmanager to copy its value into a new variable CHANGED_X509 and let
# X509_USER_PROXY point instead to a different file called x509_up that
# is located in $_CONDOR_SCRATCH_DIR.  This latter file is automatically
# created and placed there on the worker node $_CONDOR_SCRATCH_DIR directory
# by the condor daemons.  The history of how that file came to be generated
# is interesting, but not important for the present purposes.  It is
# sufficient to note here that this x509_up file in $_CONDOR_SCRATCH_DIR
# at job startup is not a valid certificate for most purposes: most grid
# operations will choke if that credential is used to authorize them.
#    DO NOT TRY IT -- SOMETIMES THINGS WILL WORK, VERY CONFUSING
# Instead what we want to do is to fetch a copy of what CHANGED_X509 points
# to on the gatekeeper and make X509_USER_PROXY point to that instead.
# How can this be done, without a valid proxy???  Use the bogus x509_up
# credential just to authorize this one fetch operation, then abandon it
# forevermore -- for the moment, this works on the UConn site.
#    WARNING -- THIS MAY BREAK IN FUTURE RELEASES, WATCH IT!
# -----------------------------------------------------------------

if (exists $ENV{'CHANGED_X509'}) {
    my $orig_x509_cert = "gsiftp://ce1.phys.uconn.edu/".$ENV{'CHANGED_X509'};
    my $new_x509_cert = "file:///".$ENV{'X509_USER_PROXY'}."_orig";
    system("globus-url-copy $orig_x509_cert $new_x509_cert");
    $ENV{'X509_USER_PROXY'} .= "_orig";
    chmod 0600, $ENV{'X509_USER_PROXY'};
}

chdir $worker_node_temp;
chmod 0744,$ARGV[0];
exec @ARGV;