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 (like READ, WRITE, DAEMON, ADVERTISE_STARTD). need multiple authorizations? you gotta specify -authz multiple times, one per authz. if you don't specify -authz at all, no authorization restrictions get added and authorization is solely based on the token's identity. NOTE that -authz cannot be used to give an identity additional permissions at the remote host. if the server's admin only permits the user READ authorization, then specifying -authz WRITE in 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 to stderr, based on the value of the configuration variable TOOL_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 the condor identity. 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 the SEC_TOKEN_DIRECTORY configuration variable (defaulting to ~/.condor/tokens.d), where the resulting token is stored. if not specified, the token will be sent to stdout. remember: relative only, no path info in the value! πŸ™ˆ
  • -type type β€” request a token from a specific daemon type type. if not given, a condor_collector is used. 🧚
also, hi, your synopsis mentioned -file filename β€” yes, that's a real part of the invocation. -file writes the token to the given file (an arbitrary filename is fine here!), while -token goes 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. πŸ‘‘)


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