Install and configure HTCondor on Linux machines.
get_htcondor <-h | –help>
get_htcondor [–[no-]dry-run] [–channel name] [–minicondor | [–central-manager | –submit | –execute] central-manager-name] [–shared-filesystem-domain filesystem-domain-name]
This tool installs and configure HTCondor on Linux machines. See https://htcondor.readthedocs.io/en/latest/getting-htcondor for detailed instructions. This page is intended as a quick reference to its options; it also includes a section about the reasons for the configurations it installs.
Print a usage reminder.
Do not issue commands, only print them. [default]
Issue all the commands needed to install HTCondor.
- –channel name
Specify channel name to install; name may be
current, the most recent release with new features [default] or
stable, the most recent release with only bug-fixes
Display the detected operating system and exit.
Configure as a single-machine (“mini”) HTCondor. [default]
Configure this installation with the central manager, submit, or execute role.
Configure this installation to assume that machines specifying the same filesystem-domain-name share a filesystem.
On success, exits with code 0. Failures detected by get_htcondor will result in exit code 1. Other failures may have other exit codes.
This tool may install four different configurations. We discuss the single-machine configuration first, and then the three parts of the multi-machine configuration as a group. Our goal is to document the reasoning behind the details, because the details can obscure that reasoning, and because the details will change as we continue to improve HTCondor.
As a general note, the configurations this tool installs make extensive
use of metaknobs, lines in HTCondor configuration files that look like
use x : y. To determine exactly what configuration a metaknob sets, run
condor_config_val use x:y.
The single-machine installation performed by get_htcondor uses the
minicondor package. (A “mini” HTCondor is a single-machine HTCondor
system installed with administrative privileges.) Because the different
roles in the HTCondor system are all on the same machine, we configure
all network communications to occur over the loopback device, where we don’t
have to worry about eavesdropping or requiring encryption. We
FS method, which depends on the local filesytem, to identify
which user is attempting to connect, and restrict access correspondingly.
The get_htcondor tool installs the standard minicondor package from the
HTCondor repositories; see the file it creates,
/etc/condor/config.d/00-minicondor, for details.
Because the three roles must communicate over the network to form a complete
pool in this case,, security is a much bigger concern; we therefore require
authentication and encryption on every connection. Thankfully, almost all
of the network communication is daemon-to-daemon, so we don’t have to burden
individual users with that aspect of security. Instead, users submit jobs on
the submit-role machine, using
FS to authenticate. Users may also need to
contact the central manager (when running
condor_status, for example),
but they never need to write anything to it, so we’ve configured
authentication for read-only commands to be optional.
Daemon-to-daemon communication is authenticated with the IDTOKENS method.
(If a user needs to submit jobs remotely, they can also use the IDTOKENS
method, it’s just more work; see
condor_token_fetch.) Each role
installed by this tool has a copy of the password, which is used to
generate an IDTOKEN, which is used for all daemon-to-daemon authentication;
both the password and the IDTOKEN can only be read by privileged processes.
An IDTOKEN can only be validated by the holder of the corresponding
password, so each daemon in the pool has to have both.
This tool installs the role-specific configuration in the files
/etc/condor/config.d/01-execute.config; consult them for details.