---
name: "get_htcondor"
section: "1"
platform: "linux"
package: "condor"
version: "23.9.6+dfsg-2.1+b10"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/get_htcondor"
---

# get\_htcondor(1)

HTCondor Manual Install and configure HTCondor on Linux machines.

## NAME

get\_htcondor - HTCondor Manual

Install and configure HTCondor on Linux machines.

## SYNOPSIS

**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*\]

**get\_htcondor** **--dist**

## DESCRIPTION

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.

## OPTIONS

- **-help**

  Print a usage reminder.

- **--dry-run**

  Do not issue commands, only print them.  \[default\]

- **--no-dry-run**

  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

- **--dist**

  Display the detected operating system and exit.

- **--minicondor**

  Configure as a single-machine ("mini") HTCondor.  \[default\]

**--central-manager** *central-manager-name*

**--submit** *central-manager-name*

- **--execute** *central-manager-name*

  Configure this installation with the central manager, submit, or execute role.

- **--shared-filesystem-domain** *filesystem-domain-name*

  Configure this installation to assume that machines specifying the same *filesystem-domain-name* share a filesystem.

## EXIT STATUS

On success, exits with code 0.  Failures detected by **get\_htcondor** will result in exit code 1.  Other failures may have other exit codes.

## INSTALLED CONFIGURATION

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**.

### Single-Machine Installation

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 use the **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.

### Multi-Machine Installation

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-central-manager.config**, **/etc/condor/config.d/01-submit.config**, and **/etc/condor/config.d/01-execute.config**; consult them for details.

## AUTHOR

HTCondor Team

## COPYRIGHT

1990-2024, Center for High Throughput Computing, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI, US. Licensed under the Apache License, Version 2.0.