Re: [HTCondor-users] Difficulty with LocalCredd on Windows

Mailing List Archives Authenticated access	UW Madison Computer Sciences Department Computer Systems Lab

I have already run condor_store_cred, and the CREDD daemon is running. The CREDD daemon is running on the same computer as SCHEDD I did find something interesting in the SchedLog:

06/03/24 16:06:00 (pid:25560) SetAttribute security violation: setting User to "lumshuechanj@<full_hostname>" when active User is "lumshuechanj@something"

06/03/24 16:06:00 (pid:25560) Activity on stashed negotiator socket: <my_ip>

06/03/24 16:06:00 (pid:25560) Negotiating for owner: lumshuechanj@<full_hostname>

06/03/24 16:06:00 (pid:25560) AutoCluster:config() significant attributes changed to MachineLastMatchTime Offline RemoteOwner RequestCpus RequestDisk RequestGPUs RequestMemory TotalJobRuntime ConcurrencyLimits FlockTo Rank Requirements

06/03/24 16:06:00 (pid:25560) Rebuilt prioritized runnable job list in 0.000s.

06/03/24 16:06:00 (pid:25560) Finished sending rrls to negotiator

06/03/24 16:06:00 (pid:25560) Finished sending RRL for lumshuechanj

06/03/24 16:06:00 (pid:25560) Activity on stashed negotiator socket: <my_ip>

06/03/24 16:06:00 (pid:25560) Negotiating for owner: lumshuechanj@<full_hostname>

06/03/24 16:06:00 (pid:25560) Negotiation ended: 0 jobs matched

I am not sure where the "something" is coming from, but it is different than $FULL_HOSTNAME. It corresponds to %USERDOMAIN%, but not %USERDNSDOMAIN%. Could this be the issue?

Thanks,

Joshua Lum Shue Chan

CAUTION: This email originated from outside of Leidos. Be cautious when clicking or opening content.

If you want to use run_as_owner on Windows, you need to run a single CREDD daemon for the pool and configure both the Schedd and the Execute nodes to use it.

Once the Schedd and the Execute nodes are using the same CREDD the LocalCredd attribute of the jobs will match the LocalCredd of the execute nodes. Note that you may have to remove and resubmit jobs after you change the configuration of the Schedd to use the CREDD daemon.

If you have already run condor_store_cred to store user passwords on your CM, then if you run the CREDD daemon on the CM, it will pick up the passwords that have already been stored since they are stored in the Windows registry.

See the sections named

Executing Jobs as the Submitting User

and

The condor_credd Daemon

on this page of the manual

https://htcondor.readthedocs.io/en/latest/platform-specific/microsoft-windows.html#the-condor-credd-daemon

-tj

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Lum Shue Chan, Joshua [US-US] via HTCondor-users <htcondor-users@xxxxxxxxxxx>
Sent: Friday, May 31, 2024 5:33 PM
To: htcondor-users@xxxxxxxxxxx <htcondor-users@xxxxxxxxxxx>
Cc: Lum Shue Chan, Joshua [US-US] <Joshua.T.LumShueChan@xxxxxxxxxx>
Subject: [HTCondor-users] Difficulty with LocalCredd on Windows

Hello,

I am trying to set up htcondor to use the windows shared filesystem. For testing, I have one computer acting as the central manager and submit node, and another computer as the execute node. Following the guide at Microsoft Windows — HTCondor Manual 23.7.2 documentation, I am able to execute a job that doesn't have run_as_owner defined in the .sub file, but when I try to run a job with run_as_owner = True, the job idles indefinitely. Below is the relevant output of condor_q, more info is in the attached files. What is my next step in troubleshooting this issue?

condor_q -better-analyze output:

[0] 1 TARGET.Arch == "X86_64"

[1] 1 TARGET.OpSys == "WINDOWS"

[3] 1 TARGET.Disk >= RequestDisk

[5] 1 TARGET.Memory >= RequestMemory

[8] 1 TARGET.HasFileTransfer

[12] 0 TARGET.LocalCredd is "<hostname of central manager>"

Thanks,

Joshua Lum Shue Chan

Mailing List Archives

Authenticated access

Re: [HTCondor-users] Difficulty with LocalCredd on Windows