1GET_HTCONDOR(1) HTCondor Manual GET_HTCONDOR(1)
2
3
4
6 get_htcondor - HTCondor Manual
7
8 Install and configure HTCondor on Linux machines.
9
10
11
12
14 get_htcondor <-h | --help>
15
16 get_htcondor [--[no-]dry-run] [--channel name] [--minicondor | [--cen‐
17 tral-manager | --submit | --execute] central-manager-name]
18 [--shared-filesystem-domain filesystem-domain-name]
19
20 get_htcondor --dist
21
23 This tool installs and configure HTCondor on Linux machines. See
24 https://htcondor.readthedocs.io/en/latest/getting-htcondor for detailed
25 instructions. This page is intended as a quick reference to its op‐
26 tions; it also includes a section about the reasons for the configura‐
27 tions it installs.
28
30 -help Print a usage reminder.
31
32 --dry-run
33 Do not issue commands, only print them. [default]
34
35 --no-dry-run
36 Issue all the commands needed to install HTCondor.
37
38 --channel name
39 Specify channel name to install; name may be current, the
40 most recent release with new features [default] or stable,
41 the most recent release with only bug-fixes
42
43 --dist Display the detected operating system and exit.
44
45 --minicondor
46 Configure as a single-machine ("mini") HTCondor. [default]
47
48 --central-manager central-manager-name
49
50 --submit central-manager-name
51
52 --execute central-manager-name
53 Configure this installation with the central manager, submit, or
54 execute role.
55
56 --shared-filesystem-domain filesystem-domain-name
57 Configure this installation to assume that machines specifying
58 the same filesystem-domain-name share a filesystem.
59
61 On success, exits with code 0. Failures detected by get_htcondor will
62 result in exit code 1. Other failures may have other exit codes.
63
65 This tool may install four different configurations. We discuss the
66 single-machine configuration first, and then the three parts of the
67 multi-machine configuration as a group. Our goal is to document the
68 reasoning behind the details, because the details can obscure that rea‐
69 soning, and because the details will change as we continue to improve
70 HTCondor.
71
72 As a general note, the configurations this tool installs make extensive
73 use of metaknobs, lines in HTCondor configuration files that look like
74 use x : y. To determine exactly what configuration a metaknob sets,
75 run condor_config_val use x:y.
76
77 Single-Machine Installation
78 The single-machine installation performed by get_htcondor uses the
79 minicondor package. (A "mini" HTCondor is a single-machine HTCondor
80 system installed with administrative privileges.) Because the differ‐
81 ent roles in the HTCondor system are all on the same machine, we con‐
82 figure all network communications to occur over the loopback device,
83 where we don't have to worry about eavesdropping or requiring encryp‐
84 tion. We use the FS method, which depends on the local filesytem, to
85 identify which user is attempting to connect, and restrict access cor‐
86 respondingly.
87
88 The get_htcondor tool installs the standard minicondor package from the
89 HTCondor repositories; see the file it creates, /etc/condor/con‐
90 fig.d/00-minicondor, for details.
91
92 Multi-Machine Installation
93 Because the three roles must communicate over the network to form a
94 complete pool in this case,, security is a much bigger concern; we
95 therefore require authentication and encryption on every connection.
96 Thankfully, almost all of the network communication is daemon-to-dae‐
97 mon, so we don't have to burden individual users with that aspect of
98 security. Instead, users submit jobs on the submit-role machine, using
99 FS to authenticate. Users may also need to contact the central manager
100 (when running condor_status, for example), but they never need to write
101 anything to it, so we've configured authentication for read-only com‐
102 mands to be optional.
103
104 Daemon-to-daemon communication is authenticated with the IDTOKENS
105 method. (If a user needs to submit jobs remotely, they can also use
106 the IDTOKENS method, it's just more work; see condor_token_fetch.)
107 Each role installed by this tool has a copy of the password, which is
108 used to generate an IDTOKEN, which is used for all daemon-to-daemon au‐
109 thentication; both the password and the IDTOKEN can only be read by
110 privileged processes. An IDTOKEN can only be validated by the holder
111 of the corresponding password, so each daemon in the pool has to have
112 both.
113
114 This tool installs the role-specific configuration in the files
115 /etc/condor/config.d/01-central-manager.config, /etc/condor/con‐
116 fig.d/01-submit.config, and /etc/condor/config.d/01-execute.config;
117 consult them for details.
118
120 HTCondor Team
121
123 1990-2023, Center for High Throughput Computing, Computer Sciences De‐
124 partment, University of Wisconsin-Madison, Madison, WI, US. Licensed
125 under the Apache License, Version 2.0.
126
127
128
129
130 Oct 02, 2023 GET_HTCONDOR(1)