2.13 Special Environment Considerations

2.13.1 AFS

    The Condor daemons do not run authenticated to AFS; they do not possess AFS tokens. Therefore, no child process of Condor will be AFS authenticated. The implication of this is that you must set file permissions so that your job can access any necessary files residing on an AFS volume without relying on having your AFS permissions.

If a job you submit to Condor needs to access files residing in AFS, you have the following choices:

1.

Copy the needed files from AFS to either a local hard disk where Condor can access them using remote system calls (if this is a standard universe job), or copy them to an NFS volume.

2.

If you must keep the files on AFS, then set a host ACL (using the AFS fs setacl command) on the subdirectory to serve as the current working directory for the job. If a standard universe job, then the host ACL needs to give read/write permission to any process on the submit machine. If vanilla universe job, then you need to set the ACL such that any host in the pool can access the files without being authenticated. If you do not know how to use an AFS host ACL, ask the person at your site responsible for the AFS configuration.

The Condor Team hopes to improve upon how Condor deals with AFS authentication in a subsequent release.

Please see section 3.11.1 on page  in the Administrators Manual for further discussion of this problem.

2.13.2 NFS Automounter

    If your current working directory when you run condor_submit   is accessed via an NFS automounter, Condor may have problems if the automounter later decides to unmount the volume before your job has completed. This is because condor_submit likely has stored the dynamic mount point as the job's initial current working directory, and this mount point could become automatically unmounted by the automounter.

There is a simple work around: When submitting your job, use the initialdir command in your submit description file to point to the stable access point. For example, suppose the NFS automounter is configured to mount a volume at mount point /a/myserver.company.com/vol1/johndoe whenever the directory /home/johndoe is accessed. Adding the following line to the submit description file solves the problem.

        initialdir = /home/johndoe

     
2.13.3 Using Globus software with Condor

Use of the Globus project software http://www.globus.org with Condor affects these issues:

GSS Authentication

Is an option only in special versions of Condor, available by request only, due to cryptographic software export controls and Condor distribution policy. Sites running the Condor software distributed with GSS-Authentication can set up their own Certification Authority (CA) by running the create_ca script. Once the CA is set up, the condor_ca script is used to generate certificates for the Condor daemons (e.g., condor_schedd) and to sign user and daemon certificates. Users can generate certificate requests and other needed files with the condor_cert program. An X.509 certificate directory pointed to by the submit description file variable x509CertDir indicates a client program which can use GSS authentication as a possible authentication method. Alternately, the environment variables X509_CERT_DIR, X509_USER_CERT, X509_USER_KEY can be used to override the default filenames and locations. NOTE: the AUTHENTICATION_METHOD configuration value list must contain the value 'GSS' for GSS authentication to be attempted.

Submitting to the Globus Universe

    requires Globus version 1.1, as well as a valid Globus X.509 certificate. The default location for the necessary files is $HOME/.globus, but they can be overridden by setting the X509_* variables in your environment or the submit description file. NOTE: AFS issues apply here, so you may have to copy your certificate, trusted certificates directory, private key, and proxy to a local file system disk.

condor_glidein

  requires a valid Globus X.509 certificate, and the PATH to the globusrun program must be in your environment. NOTE: to allow a globus resource to join your Condor pool, your administrator must add the host name(s) to the HOSTALLOW_WRITE and HOSTALLOW_READ configuration values.

2.13.4 Condor Daemons That Do Not Run as root

    Condor is normally installed such that the Condor daemons have root permission. This allows Condor to run the condor_shadow     process and your job with your UID and file access rights. When Condor is started as root, your Condor jobs can access whatever files you can.

However, it is possible that whomever installed Condor did not have root access, or decided not to run the daemons as root. That is unfortunate, since Condor is designed to be run as the Unix user root. To see if Condor is running as root on a specific machine, enter the command

        condor\_status -master -l <machine-name>

where machine-name is the name of the specified machine. This command displays a condor_master ClassAd; if the attribute RealUid equals zero, then the Condor daemons are indeed running with root access. If the RealUid attribute is not zero, then the Condor daemons do not have root access.

NOTE: The Unix program ps is not an effective method of determining if Condor is running with root access. When using ps, it may often appear that the daemons are running as the condor user instead of root. However, note that the ps, command shows the current effective owner of the process, not the real owner. (See the getuid(2) and geteuid(2) Unix man pages for details.) In Unix, a process running under the real UID of root may switch its effective UID. (See the seteuid(2) man page.) For security reasons, the daemons only set the effective uid to root when absolutely necessary (to perform a privileged operation).

If they are not running with root access, you need to make any/all files and/or directories that your job will touch readable and/or writable by the UID (user id) specified by the RealUid attribute. Often this may mean using the Unix command chmod 777 on the directory where you submit your Condor job.