Upgrading from 8.9 to 9.0
If you successfully upgraded to 8.9.13, the upgrade to 9.0 should be seamless.
Otherwise, this document explains, in order of likelihood, how you may need to intervene when upgrading your pool to 9.0 from an v8.9.x release of HTCondor, 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
from the default
, and have added a new configuration file,
. (This file will not be overwritten by subsequent upgrades, so it is safe to modify.) This file adds the line
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
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:
to reinstall your pool with a fresh installation; see the
tool will configure your pool with our recommended security configuration for you. Once it's done, you can copy your site-specific configuration from your old installation to the new installation by placing configuration files into
Option B . Run two commands (as root) on every machine in your pool to enable the recommended security configuration appropriate for v8.9.13. When prompted, type the same password for every machine. ( Note: if typing a password is problematic, see the condor_store_cred manual page for other options such as reading the password from a file or command-line).
# condor_store_cred -c add # umask 0077; condor_token_create -identity condor@mypool > /etc/condor/tokens.d/condor@mypool
. Revert to the previous host-based security configuration that was the default before v8.9.13. This is the most expedient way to get your pool running again as it did before upgrading, but realize that a host-based security model is not recommended. If you go for this option, please consider it a temporary measure. To configure HTCondor to function as it did before the upgrade, see the instructions in
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
. If you are not currently using tokens, or you have created these signing key(s) by using the
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
via some other method (such as a copying from
), there is a possibility that previously issued tokens will no longer authenticate.
You can use the new
tool to determine if your signing key(s) were affected by this bug (run as root):
If this tool indicates that your signing keys were truncated, we recommend that you re-issue these tokens to clients via either condor_token_create or condor_token_fetch . The `condor_check_password` tool may also be used to truncate the affected key(s) before the first byte causing the problem, which will allow existing tokens to continue to work, but is, perhaps substantially, less cryptographically secure. If you'd like to do so anyway, use the following command (run as root):
# condor_check_password --truncate
Step 3: Directory permission changed in /etc/condor/tokens.d
HTCondor now reads files in
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