Ah yes, read is not working because the TOOL subsystem is only able to use FS,
KERBEROS, GSI, and CLAIMTOBE authentication, but I have been trying to work
around those issues I have been having with Kerberos I mentioned last week.
Has anyone been able to take another look at that? That error has me really
stumped.
Thanks for helping me find the root cause of that Todd,
Wes
Public Content
-----Original Message-----
From: Todd Tannenbaum <tannenba@xxxxxxxxxxx>
Sent: Monday, August 3, 2020 9:47 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>; Wesley Taylor
<wesley.taylor@xxxxxxxxxxx>
Subject: [External] - Re: [HTCondor-users] condor_q -better-analyze: "Could
not fetch startd ads"
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On 7/31/2020 6:20 PM, Wesley Taylor wrote:
> Hey all, its me again.
>
> Finally got HTCondor ready for preliminary smoke testing on the production
> network, and have been debugging issues as we go. There has been one really
> weird error I haven't been able to figure out on my own. When I run
> "condor_q" it runs fine. However, if I run "condor_q -analyze" or
> "condor_q -better-analyze" I get back "Error: Could not fetch startd ads".
On the same machine where "condor_q" works but "condor_q -analyze" fails, does
"condor_status" work for you?
If "condor_status" also does not work, then my guess is the security
permissions on your pool's central manager are setup in a manner that is now
allowing read access to the condor_collector from the machine where
condor_status/condor_q -analyze fails. From this same machine try running
this command to confirm/deny if read access is being blocked:
condor_ping -pool condor.cs.wisc.edu -type collector READ
If you can connect but READ is being denied, look at the ALLOW_READ setting in
the condor_config file(s) on your central manager.
Hope the above helps
Todd
Attachment:
smime.p7s
Description: S/MIME cryptographic signature