[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] help needed to troubleshoot a "SECMAN: FAILED" issue
- Date: Fri, 29 May 2020 03:52:09 +0000
- From: Zach Miller <zmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] help needed to troubleshoot a "SECMAN: FAILED" issue
Sorry, I meant to respond to this earlier but Mark beat me to it so I just wanted to ask a couple questions and add a couple additions to Mark's email:
It looks like you are running condor_q as root perhaps? It (condor_q) seems to be using the pool password method of authentication and mapping you to the user "condor_pool@<domain>". That's perhaps okay, depending on the ALLOW_* settings, but it's kind of unexpected.
You mentioned two things -- adding a SchedD to a pool, and then running condor_q. It sounds like you got the SchedD added just fine. Is that correct? (Is it showing up when you run condor_status -schedd?)
For the issue with condor_q you want to check the ALLOW_* settings on the SchedD machine. Running condor_q requires READ-level authorization so you should run: "condor_config_ALLOW_READ". For extra-nerdy goodness, use this regular expression:
# This will show you the allow settings for all subsystems and authorization levels
condor_config_val -dump '^(.*\.)?ALLOW'
Basically, you need an entry in the ALLOW list that authorizes the user running condor_q, whoever that may be. You may not care and just want to set "ALLOW_READ = *". But let us know what results you get and we'll try to help!
ïOn 5/28/20, 5:58 PM, "HTCondor-users on behalf of coatsworth@xxxxxxxxxxx" <htcondor-users-bounces@xxxxxxxxxxx on behalf of coatsworth@xxxxxxxxxxx> wrote:
Hi Jose, here are a few quick troubleshooting questions.
On your central manager machine, can you send the result of a `condor_config_val ALLOW_WRITE_COLLECTOR` command? Do you see your new schedd domain in this list?
On both your schedd and central manager machines, can you send the result of a `condor_config_val ALLOW_DAEMON`? Again, you see your new schedd domain in both those domains.
Can you confirm the pool password you set on the new schedd is the same as other schedds? If you're not sure, try copying the pool password file directly from another schedd that works.
Lastly I'm pretty sure that <a_domain_name> should be your schedd domain, not the production infrastructure.
Please give these a try and let me know, if they don't reveal the problem then I'll ask our security experts to weigh in :)
On Thu, May 28, 2020 at 9:29 AM <jcaballero.hep@xxxxxxxxx> wrote:
El jue., 28 may. 2020 a las 15:17, Jose Caballero
> I need some guidance here.
> I am trying to setup a testing Schedd and add it to an existing pool.
> It has the same configuration that the other Schedd's on production.
> However, there is a difference, my testing Schedd is on a host with a
> different domain name that the rest of the infrastructure. I feel that
> is part of the problem here.
> When I try to run condor_q remotely against the new test schedd, I get
> this in the SchedLog
> SECMAN: FAILED: Received "DENIED" from server for user
> condor_pool@<a_domain_name> using method PASSWORD.
> where the <a_domain_name> is the domain name of the production
> infrastructure, not the domain name of this testing schedd.
> Is that a problem?
> Extra info, let me know if there is something else I need to provide:
> # condor_config_val SEC_PASSWORD_FILE
> # ls -l /etc/condor/pool_password
> -r-------- 1 root root 256 May 28 13:22 /etc/condor/pool_password
> # rpm -qa | grep condor
> Thanks a lot in advance.
An extra piece of info.
From the NegotiatorLog, replacing again real values by <foo>:
05/28/20 15:06:39 PERMISSION DENIED to condor_pool@<a_domain_name>
from host <the_schedd_ip> for command 421 (Reschedule), access level
DAEMON: reason: cached result for DAEMON; see first case for the full
05/28/20 15:06:39 DC_AUTHENTICATE: Command not authorized, done!
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
You can also unsubscribe by visiting
The archives can be found at:
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin-Madison