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.

                                           Apr 14, 2024                           GET_HTCONDOR(1)