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.

                                                  Aug 06, 2025                                   GET_HTCONDOR(1)