Project

General

Profile

Support #22413

Possible wrong SEC_DEFAULT_AUTHENTICATION_METHODS line in the condor config for the frontend

Added by Marco Mambelli 9 months ago. Updated 10 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
04/18/2019
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

There seems to be a wrong SEC_DEFAULT_AUTHENTICATION_METHODS line in the condor config for the frontend.

# grep SEC_DEFAULT_AUTHENTICATION_METHODS /var/lib/gwms-frontend/vofrontend/frontend.condor_config
SEC_DEFAULT_AUTHENTICATION_METHODS = FS,PASSWORD,GSI
SEC_DEFAULT_AUTHENTICATION_METHODS = GSI
<pre>
Thos second line overrides the line created form the configuration on the frontend host, forcing only GSI and blocking other methods.
But somehow a schedd using only PASSWORD authentication seems to be queried correctly and trigger glideins.

1. Why was that line added?
2. Should it be removed?
3. Why PASSWORD auth seems to work anyway?

History

#1 Updated by Marco Mambelli 8 months ago

  • Target version changed from v3_5 to v3_5_1

#2 Updated by Marco Mambelli 5 months ago

  • Target version changed from v3_5_1 to v3_6_1
  • Assignee changed from Marco Mambelli to Dennis Box

Dennis, sonce you are fixing the authentication for HTCondor 8.9 could you look also at this?

#3 Updated by Dennis Box 3 months ago

  • Target version changed from v3_6_1 to v3_6_2

#4 Updated by Dennis Box 30 days ago

The config file in question, frontend.condor_config, is generated by cvWCreate.py::create_client_condor_config() during a frontend reconfig.

The algorithm it uses is

1) use condor_config_val -dump to get the current config
2) filter from this list any settings it doesn't want (helpfully #commenting them so you can see what was filtered out)
3)append its own values, including SEC_DEFAULT_AUTHENTICATION_METHODS = GSI.

The answers to the original questions:

1. Why was that line added?

PASSWORD almost certainly was set in the original condor configuration, create_client_condor_config() appended the second one, in effect 'winning' as far as the frontend is concerned. When the problem was found originally was it on a machine that had an OSG 3.5 install of the condor 8.8 series? In #23372 we discovered that PASSWORD is added as a default authentication method by OSG for this combination.

2. Should it be removed?

A rephrasing of the question: are frontend subprocesses using a different condor_configuration than the condor daemons running natively from config files? Yes. Is this a problem? Potentially. This is very likely part of the failure of the frontend to authenticate in #23372 .

Another rephrasing of the question: what is the desired value of SEC_DEFAULT_AUTHENTICATION_METHODS for the frontend? I would have said GSI,TOKEN, and I now know that while the condor daemons have been authenticating to each other with TOKENs for my work for #23092, the frontend processes WERE NOT.

3. Why PASSWORD auth seems to work anyway?

The condor daemons are all happily authenticating with each other with PASSWORD in this case, only the frontend is not. I presume it chugs along merrily using GSI to the condor daemons, just like my poor frontend that I thought was using token_auth in #23092

I want to think a bit more about if and how create_client_condor_config() should be fixed. It probably needs to accomodate TOKENs and SCITOKENs as part of #23092, I don't know if this is otherwise broken behavior.

#5 Updated by Dennis Box 10 days ago

  • Target version changed from v3_6_2 to v3_7


Also available in: Atom PDF