2.11 Special Environment Considerations

2.11.1 AFS

The Condor daemons do not run authenticated to AFS; they do not possess an AFS token, and therefore no child process of Condor will be AFS authenticated either. This means that you must set file permissions so that your job can access any necessary files residing on an AFS volume during its run without relying on having your AFS permissions.

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

1.

Copy the files needed off of AFS to either a local hard disk where Condor can access them via 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 you need to set a host ACL (using the AFS ``fs setacl'' command) on the subdirectory which will serve as the current working directory for the job. If the job is a Standard Universe job, then the host ACL needs to give read/write permission to any process on the submit machine. If the job is a 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, please ask whomever at your site is responsible for the AFS configuration.

How Condor deals with AFS authentication is something the Condor Team hopes to improve in a subsequent release.

Please also see section 3.9.1 on page  in the Administrators Manual for more discussion about this problem.

2.11.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 workaround: When submitting your job, use the initialdir command in your submit-description file to point to the stable access point. For example, say 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. In this example case, simply add the following line to your condor_submit submit-description file:

        initialdir = /home/johndoe

2.11.3 Condor Daemons running as Non-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 process 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 decided not to run the daemons as root, or did not have root access. That's a shame, since Condor is really designed to be run as root. To see if Condor is running as root on a given machine, enter the following command:

        condor_status -master -l <machine-name>

where machine-name is the name of the machine you want to inspect. This command will display a condor_master ClassAd; if the attribute ``RealUid'' equals zero, then the Condor daemons are indeed running with root access and you can skip this section. If the ``RealUid'' attribute is not zero, then the Condor daemons do not have root access, and you should read on.

Please realize that using ``ps'' is not an effective method of determining if Condor is running with root access. When using the "ps" command, 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 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 doing a ``chmod 777'' on the directory where you submit your Condor job.