Re: [HTCondor-users] Condor Credd for multiple pools

["Hitchen, Greg (IM&T, Kensington WA)" <Greg.Hitchen@xxxxxxxx>]

Hi Lachlan

 

We have 9 separate pools of windows execute nodes, each with linux central managers.

 

We have all our submit nodes in one of those pools. We also have a standalone windows credd machine in that same pool.

 

So that all windows execute nodes in all the pools can also see the credd machine, it’s configuration for CONDOR_HOST points to multiple pools:

 

CONDOR_HOST = pool1.xxx.xxx, pool2.xxx.xxx, pool2.xxx.xxx, etc.

 

That way the central managers in every pool will know about the credd machine.

 

I will point out that we have not gone production on this yet, but we have tested it and everything seems to work OK.

 

Cheers

 

Greg

 

 

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of John M Knoeller
Sent: Saturday, 4 September 2021 6:35 AM
To: 'HTCondor-Users Mail List' <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Condor Credd for multiple pools

 

There is no particular need to have the condor_credd running on the same machine as the condor_collector.   

The central manager does not need to know about the Credd at all.  The Schedd and the execute nodes need to know how to locate it, but the central manager does not.

 

If you have only a single Schedd, you might consider running a single condor_credd on that machine.  Otherwise

you can run the condor_credd on any machine you choose.

 

If you have a domain controller or active directory, you might consider running the condor_credd on that machine. 

 

You just need to set the CREDD_HOST configuration variable on all of the Schedd and Execute nodes to point to the machine  where the condor_credd is running.  If you use a dedicated CREDD_PORT, make sure to include that in the value of the CREDD_HOST 

 

-tj

 

 

---

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Lachlan Palmer <LPalmer@xxxxxxxxxxxx>
Sent: Friday, September 3, 2021 11:59 AM
To: 'HTCondor-Users Mail List' <htcondor-users@xxxxxxxxxxx>
Subject: [HTCondor-users] Condor Credd for multiple pools

 

Hi All,

 

I am running into issues with running jobs in different pools. We have three pools of Windows machines with their own central manager running a condor_credd daemon. Everything works fine when submitting jobs within the pool the submit node is in but when you launch jobs to another pool then there is a match failure on the job’s LocalCredd pointing to the submit node’s central manager while the LocalCredd for the execute nodes in the other pool being that pool’s central manager.

 

What is the recommended configuration in this case? Should we just pick one of the pools central manager to be the sole condor_credd? What is the appropriate way to configure the other central managers to point to this credd? Is it simply the same as for the submit and execute config files?

 

For more information here is our condor_credd config lines for a central manager (CM01):

## CREDD logging settings

## Customize these if you wish.

CREDD_LOG = $(LOG)/CreddLog

CREDD_DEBUG = D_COMMAND

MAX_CREDD_LOG = 50000000

 

# Timeout session quickly since we normally only get contacted

# once per starter

SEC_CREDD_SESSION_TIMEOUT = 10

 

# Set security settings so that full security to the credd is required

CREDD.SEC_DEFAULT_AUTHENTICATION = REQUIRED

CREDD.SEC_DEFAULT_ENCRYPTION = REQUIRED

CREDD.SEC_DEFAULT_INTEGRITY = REQUIRED

CREDD.SEC_DEFAULT_NEGOTIATION = REQUIRED

 

# Require PASSWORD auth for password fetching

CREDD.SEC_DAEMON_AUTHENTICATION_METHODS = PASSWORD

 

# Only honor password fetch requests to the trusted "condor_pool" user

CREDD.ALLOW_DAEMON = condor_pool@$(UID_DOMAIN)

 

# Require NTSSPI for storing credentials

CREDD.SEC_DEFAULT_AUTHENTICATION_METHODS = NTSSPI

 

CREDD_HOST = $(CONDOR_HOST)

CREDD_CACHE_LOCALLY = True

 

And for the execute and submit config:

CREDD_HOST = CM01.XXXXXXX.com

CREDD_CACHE_LOCALLY = True

STARTER_ALLOW_RUNAS_OWNER = True

 

Thanks,

 

Lachlan

This communication (both the message and any attachments or links) is confidential and only intended for the use of the person or persons to whom it is addressed unless we have expressly authorized otherwise. It also may contain information that is protected by solicitor-client privilege. If you are reading this communication and are not an addressee or authorized representative of an addressee, we hereby notify you that any distribution, copying or other use of it without our express authorization is strictly prohibited. If you have received this communication in error, please delete both the message and any attachments from your system and notify us immediately by e-mail or phone. In addition, we note that this communication and its transmission of data have not been secured by encryption. Therefore, we are not able to confirm or guarantee that the communication has not been intercepted, amended, or read by an unintended third party.