{section: Upgrading to 8.9.12 or 9.0}

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 8.8 or earlier, we strongly recommend waiting until mid-April for the release of 9.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.

{subsection: Required changes to security configuration}

The default HTCondor security configuration is no longer host-based.  If you have not specifically configured another daemon authentication method (e.g. pool password, SSL, GSI, KRB5, etc), you will need to change your configuration.  If you have, delete =/etc/condor/config.d/00-htcondor-9.0.config=.

Specifically, to allow HTCondor 9.0 to be secure by default, we have commented out the line

{code}
use security:host_based
{endcode}

from the default =/etc/condor/condor_config=.  We 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

{code}
use security:recommended_v9_0
{endcode}

which configures user-based security and requires encryption, authentication, and integrity.

You have three options.

Option A.  Use _get_htcondor_ to reinstall your pool with a fresh installation; see the {link: https://htcondor.readthedocs.io/getting-htcondor/index.html instructions}.  The _get_htcondor_ 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 =/etc/condor/config.d=.

Option B.  Run two commands (as root) on every machine in your pool to enable the recommended security configuration appropriate for  v8.9.12.  When prompted, type the same password for every machine.

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

Option C.  Revert to the previous host-based security configuration that was the default before v8.9.12.  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 =/etc/condor/config.d/00-htcondor-9.0.config=.

{subsection: 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 created these signing key(s) by using the _condor_store_cred_ command-line tool, you should not have any problems.  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_.

{subsection: 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):
{code}
# chown -R root:root /etc/condor/tokens.d
{endcode}