Upgrading to 8.9.12


UPDATE! On March 26 2021 at 3:30pm the HTCondor v8.9.12 release was pulled down from our website after significant backwards-compatibility problems were discovered. We addressed these issues in the v8.9.13 release, please see Upgrading HTCondor to 8.9.13.


HTCondor 8.9.12 has introduced many security improvements. As a result, the HTCondor team expects that after upgrading from an earlier version of 8.9 to v8.9.12, explicit administrator intervention will be required for many pools. If you're upgrading from v8.8 or earlier, we strongly recommend waiting until mid-April 2021 for the release of HTCondor v9.0.

This document explains, in order of likelihood, how you may need to intervene when upgrading your pool from an earlier HTCondor v8.9.x, and what that intervention might be. For example, if after upgrading, you cannot see your pool via condor_status as before, it is likely a problem discussed here. A given pool might require multiple interventions, so please check each of the conditions after each heading below.

Step 1: Required changes to security configuration

The default HTCondor security configuration is no longer host-based. Specifically, to allow HTCondor 9.0 to be secure by default, we have commented out the line use security:host_based from the default /etc/condor/condor_config, and have added a new configuration file, /etc/condor/config.d/00-htcondor-9.0.config. (This file will not be overwritten by subsequent upgrades, so it is safe to modify.) This file adds the line

   use security:recommended_v9_0

which configures user-based security and requires encryption, authentication, and integrity. If you have already configured another daemon authentication method (e.g. pool PASSWORD, SSL, GSI, KERBEROS, etc) at some point in the past, you can comment out the above line in file 00-htcondor-9.0.config and skip to Step 2 below.

If you have not already configured some other daemon authentication method and thus are relying solely on host-based authentication (i.e. a list of allowed hostnames or IP addresses), you have three options:

        # condor_store_cred -c add
        # umask 0077; condor_token_create -identity condor@mypool > /etc/condor/tokens.d/condor@mypool

Step 2: Compatibility changes with IDTOKENS

We fixed a bug in how the IDTOKENS authentication method reads its signing key(s), which are stored in directory /etc/condor/passwords.d. If you are not currently using tokens, or you have created these signing key(s) by using the condor_store_cred command-line tool, you should not have any problems and can skip to Step 3. If, however, you created the signing key file(s) in directory /etc/condor/passwords.d via some other method (such as a copying from /dev/random), there is a possibility that previously issued tokens will no longer authenticate. In this case, we recommend that you re-issue these tokens to clients via either condor_token_create or condor_token_fetch.

Step 3: Directory permission changed in /etc/condor/tokens.d

HTCondor now reads files in /etc/condor/tokens.d as root. If you have files in that directory, you should change their ownership, using the following command (run as root):

   # chown -R root:root /etc/condor/tokens.d