[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] valid mapped user name



On 2/22/2021 12:19 PM, rmorgan466@xxxxxxxxx wrote:
Hello.

I am trying to do condor_submit subfile -name hostA

But, I keep seeing 
"...did not result in valid mapped user name, which is required for this command..." on hostA's scheduler log file.

How can I fix this? 


Hi,

So my understanding of the above is you are trying to submit a job to a schedd running on a remote server (hostA).  I also assume you are on Linux, and you can run condor_submit successfully if you actually logged in to hostA and ran condor_submit there.

When you try to submit from job to the schedd, the schedd needs to authenticate (determine) the user that is running condor_submit.  It does so via an "authentication method".  HTCondor has several supported authentication methods (idtokens, fs_remote, ssl certicates, gsi certicates, munge, etc), but unfortunately most of them require additional setup to work when trying to authenticate over the network from one host server to another. 

An explanation of the authentication choices is in the manual at:  https://htcondor.readthedocs.io/en/latest/admin-manual/security.html#authentication

Example using FS_REMOTE: If your two hosts have a secure shared file system in common, and the user ids (UIDS) on the two hosts match (e.g. in /etc/passwd user rmorgan has UID on both hosts), then you create a tmp directory with chmod 777 on your shared file system and add the following to the config on both hosts:

    # FS and IDTOKENS are good defaults.  Here we add FS_REMOTE so hosts can submit
    # to a remote schedd so long as they can both mount /some/shared/path/tmp
    SEC_DEFAULT_AUTHENTICATION_METHODS = FS IDTOKENS FS_REMOTE
    FS_REMOTE_DIR = /some/shared/path/tmp

Example using IDTOKENS: If you are running v8.9.7 or above of HTCondor, login to the schedd host (hostA) as the user who wants to submit jobs remotely (e.g. user rmorgan) and run:
    condor_token_fetch -token rmorgan_htcondor_token
This will create the file "rmorgan_htcondor_token", and anyone who can read the contents of this file can authenticate as rmorgan to the schedd on hostA.  So treat this file with care!  If you move this file to he remote server where you are trying to submit and place it in subdirectory ~rmogan/.condor/token.d/ then things will work. 

If you are on a private network behind a firewall and trust everyone who can access both hosts, you could setup CLAIMTOBE authentication which simply tells the schded to trust whomever condor_submit claims to be without requiring any proof. 

Hope the above helps
Todd