CONDOR_TOKEN_REQUEST(1)
π condor_token_request(1) π
okay bestie, sit down, hydrate, and let me tell you about condor_token_request(1) from the HTCondor Manual. this one is iconic in a very specific way and i need you to be obsessed with it the way i am. π«Ά
β¨ NAME β¨
condor_token_request β interactively request a token from a remote daemon for the IDTOKENS authentication method. yes babe, we are sliding into the DMs of a remote daemon and asking, very politely, for credentials. π
β¨ SYNOPSIS β¨
condor_token_request [-identity user@domain] [-authz authz ...]
[-lifetime value] [-pool pool_name] [-name hostname] [-type type]
[-token filename | -file filename]
condor_token_request [-help ]
look at that. gorgeous. no notes. πΈ
β¨ DESCRIPTION β¨
so what does condor_token_request actually do? it requests an authentication token from a remote daemon, fr fr. and here's the thing β token requests must be approved by that daemon's administrator using condor_token_request_approve. so it's giving "you need a permission slip and the teacher has to sign it." π
the big glowing difference between this and condor_token_fetch: unlike condor_token_fetch, you don't need an existing identity with the remote daemon when you use condor_token_request. an anonymous method β like SSL without a client certificate β will suffice. that's the whole slay of it. β¨
if your request gets successfully enqueued, the request ID gets printed to stderr. keep it! because the administrator is gonna need to know that ID to approve the request. and then condor_token_request just... waits. patiently. until the request is approved, timing out after an hour. one hour. set a timer or whatever, bestie. β°
the token request mechanism is genuinely a powerful way to bootstrap authentication in a HTCondor pool, and this is the part where it gets good: a remote user can request an identity, verify the authenticity of the request out-of-band with the remote daemon's administrator, and then securely receive their authentication token. queen behavior honestly. π
by default, condor_token_request queries the local condor_collector. but if you specify a combination of -pool, -name, or -type, the tool can request tokens in other pools, on other hosts, or from different daemon types. mix and match, live your truth.
if it succeeds, the resulting token gets sent to stdout. but with the -token option, the token is instead written to the user's token directory β and listen, the value may not have any path information. no paths. none. with the -file option, the token gets written to the given file, and that value may be an arbitrary filename. two different vibes, two different options. π
β¨ OPTIONS β¨
-authz authzβ adds a restriction to the token so it's only valid for a given authorization level (likeREAD,WRITE,DAEMON,ADVERTISE_STARTD). need multiple authorizations? you gotta specify-authzmultiple times, one per authz. if you don't specify-authzat all, no authorization restrictions get added and authorization is solely based on the token's identity. NOTE that-authzcannot be used to give an identity additional permissions at the remote host. if the server's admin only permits the userREADauthorization, then specifying-authz WRITEin a token will not let the user perform writes. the admin said no and the admin meant no. π«-debugβ causes debugging information to be sent tostderr, based on the value of the configuration variableTOOL_DEBUG. for when you need to see everything. π-helpβ display brief usage information and exit. our lil escape hatch. π¦-identity user@domainβ request a specific identity from the daemon; a client using the resulting token will authenticate as this identity with a remote server. if not specified, the token will be issued for thecondoridentity. that's the default, bestie, it's giving "generic but reliable." π-lifetime valueβ specify the lifetime, in seconds, for the token to be valid (the token validity starts when the token is signed). after the lifetime expires, the token cannot be used for authentication. if not specified, the token will contain no lifetime restrictions. so like, forever token? no cap. β-name hostnameβ request a token from the daemon named hostname in the pool. if not specified, the locally-running daemons will be used. local? cute. remote? iconic. π-pool pool_nameβ request a token from a daemon in a non-default pool pool_name. going outside your usual pool, love that journey for you. πΈ-token filenameβ specifies a filename, relative to the directory in theSEC_TOKEN_DIRECTORYconfiguration variable (defaulting to~/.condor/tokens.d), where the resulting token is stored. if not specified, the token will be sent tostdout. remember: relative only, no path info in the value! π-type typeβ request a token from a specific daemon type type. if not given, acondor_collectoris used. π§
also, hi, your synopsis mentioned-file filenameβ yes, that's a real part of the invocation.-filewrites the token to the given file (an arbitrary filename is fine here!), while-tokengoes into the token directory. both, exactly as written above. don't get them twisted, bestie. π
β¨ EXAMPLES β¨
to obtain a token with a lifetime of 10 minutes from the default condor_collector (and remember the token is not returned until the daemon's administrator takes action):
$ condor_token_request -lifetime 600
Token request enqueued. Ask an administrator to please approve request 6108900.
eyJhbGciOiJIUzI1NiIsImtpZCI6IlBPT0wifQ.eyJpYX...ii7lAfCA
to request a token from bird.cs.wisc.edu which is limited to READ and WRITE:
$ condor_token_request -name bird.cs.wisc.edu \
-identity bucky@cs.wisc.edu
-authz READ -authz WRITE
Token request enqueued. Ask an administrator to please approve request 2578154
eyJhbGciOiJIUzI1NiIsImtpZCI6IlBPT0wifQ.eyJpYX...lJTj54
to create a token from the collector in the htcondor.cs.wisc.edu pool and then to save it to ~/.condor/tokens.d/friend:
$ condor_token_request -pool htcondor.cs.wisc.edu \
-identity friend@cs.wisc.edu \
-lifetime 600 -token friend
Token request enqueued. Ask an administrator to please approve request 2720841.
β¨ EXIT STATUS β¨
condor_token_request will exit with a non-zero status value if it fails to request or receive the token. otherwise, it will exit 0. clean, simple, no drama. π
β¨ SEE ALSO β¨
condor_token_create(1), condor_token_fetch(1), condor_token_request_approve(1), condor_token_request_auto_approve(1), condor_token_list(1)
the whole token friend group. they all ate. π₯
β¨ AUTHOR β¨
Center for High Throughput Computing, University of Wisconsin-Madison
β¨ AUTHOR β¨
HTCondor Team
(yes bestie, there are two AUTHOR sections. i don't make the manpage rules, i just respectfully preserve them. π)
β¨ COPYRIGHT β¨
1990-2026, Center for High Throughput Computing, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI, US. Licensed under the Apache License, Version 2.0.
and that's the whole page, bestie!! source: the HTCondor Manual, dated Oct 16, 2026, and the page header itself is CONDOR_TOKEN_REQUEST(1). go get that token, ask an admin nicely, and remember: an hour of waiting is just β¨anticipationβ¨. ππβ¨
π¦ where this page comes from
- fedora 43: condor 25.14.1-1.fc43 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms