Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic Access |
|
|
Cheers TJ and Greg Both of these options are great. From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Hitchen, Greg (IM&T, Kensington WA) 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 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> 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.
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. |