Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Hi Greg.
The problem with SUBMIT_ATTRS is due some long-standing behavior in condor_submit that was changed in the 8.9 series.
condor_submit before 8.9 was inconsistent about the way it honored SUBMIT_ATTRS when the submit file
did not specify the value for an attribute. For some things, like EncryptExecuteDirectory, condor_submit would always
give it a default value without first checking to see if SUBMIT_ATTRS had already provided a default.
In 8.9 condor_submit got a major re-write that made it more consistent about this sort of thing.
I just tried 9.0.6 and it worked as I expected.
Added these lines to the configuration of the machine where you I ran condor_submit.
SUBMIT_ATTRS = $(SUBMIT_ATTRS) EncryptExecuteDirectory
EncryptExecuteDirectory = true
I used this command to see what job classad condor_submit was producing without sending that classad to the Schedd
condor_submit NUL executable=%comspec% -dry-run tmp.ad -q 1
findstr /i encrypt tmp.ad
and I see this
EncryptExecuteDirectory=true
Requirements=(TARGET.Arch == "X86_64") && (TARGET.OpSys == "WINDOWS") && (TARGET.Disk >= RequestDisk) && (TARGET.Memory >= RequestMemory) && TARGET.HasEncryptExecuteDirectory && ((TARGET.FileSystemDomain == MY.FileSystemDomain) || (TARGET.HasFileTransfer))
This is how I know that SUBMIT_ATTRS works in 9.0 for EncryptExecuteDirectory.
The JOB_TRANSFORM_Encrypt solution that we gave you would overwrite the EncryptExecuteDirectory that condor_submit sent to the schedd, which is why I used
this method to test SUBMIT_ATTRS
-tj
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Hitchen, Greg (IM&T, Kensington WA) <Greg.Hitchen@xxxxxxxx>
Sent: Tuesday, August 17, 2021 1:41 AM To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx> Subject: Re: [HTCondor-users] Windows - Encrypt_Execute_Directory OK, I think the issue with the SUBMIT_ATTRS is to do with permissions.
EncryptExecuteDirectory1 = True SUBMIT_ATTRS = $(SUBMIT_ATTRS) EncryptExecuteDirectory1
results in condor_q -l for the job showing:
EncryptExecuteDirectory = false EncryptExecuteDirectory1 = true
However:
EncryptExecuteDirectory = True SUBMIT_ATTRS = $(SUBMIT_ATTRS) EncryptExecuteDirectory
results in condor_q -l for the job showing:
EncryptExecuteDirectory = false
i.e. it is not overwriting the default value of false
Even with:
ALL_DEBUG = D_FULLDEBUG
I canât see anything in the logs though. I know John said there wouldnât be. ð But thought Iâd try.
Cheers
Greg
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Hitchen, Greg (IM&T, Kensington WA)
Aaaargh! Thanks John.
I donât know why I suddenly saw it, but before even checking things/logs again I noticed a typo in the original job transform settings:
JOB_TRANFORM_NAMES = $(JOB_TRANFORM_NAMES) Encrypt JOB_TRANSFORM_Encrypt @=end SET EncryptExecuteDirectory = true # optionally also force match to nodes that can encrypt. (not all Linux nodes can encrypt) SET Requirements = ( $(MY.Requirements) ) && TARGET.HasEncryptExecuteDirectory @end
There are 2 missing âSâes in the first line, i.e. JOB_TRANFORM instead of JOB_TRANSFORM.
Itâs now working as expected.
Iâll keep checking the other method of:
EncryptExecuteDirectory = true SUBMIT_ATTRS = $(SUBMIT_ATTRS) EncryptExecuteDirectory
to try and figure out why itâs not working for me, but given the transform job method is working itâs more of an academic interest.
Cheers
Greg
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of John M Knoeller
For SUBMIT_ATTRS there's no log to look at, but for the Schedd transform, The SchedL should show the transform being loaded shortly after the Schedd is started up
08/16/21 10:20:45.217 (pid:4972) (D_ALWAYS) JOB_TRANSFORM_Encrypt setup as transform rule #1 : NAME Encrypt SET EncryptExecuteDirectory = true
And it should show the transform being applied when the job is submitted.
08/16/21 10:21:53.560 (pid:4972) (D_ALWAYS) job_transforms for 15893.0: 1 considered, 1 applied (Encrypt)
-tj
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Hitchen, Greg (IM&T, Kensington WA) <Greg.Hitchen@xxxxxxxx>
Thanks John and Todd
What I had already tried was: EncryptExecuteDirectory = true SUBMIT_ATTRS = EncryptExecuteDirectory on the submit node, which didnât work.
This, suggested by John, also doesnât seem to work: EncryptExecuteDirectory = true SUBMIT_ATTRS = $(SUBMIT_ATTRS) EncryptExecuteDirectory after a condor_reconfig, or even stopping and starting condor.
condor_q -l for the submitted job always shows: EncryptExecuteDirectory = false
This is what condor_config_val -dump -verbose shows: EncryptExecuteDirectory = True # at: C:\PROGRA~1\condor/condor_config.local, line 4 # expanded: True SUBMIT_ATTRS = EncryptExecuteDirectory # at: C:\PROGRA~1\condor/condor_config.local, line 5 # expanded: EncryptExecuteDirectory
The job transform doesnât seem to work either: JOB_TRANFORM_NAMES = $(JOB_TRANFORM_NAMES) Encrypt JOB_TRANSFORM_Encrypt @=end SET EncryptExecuteDirectory = true # optionally also force match to nodes that can encrypt. (not all Linux nodes can encrypt) #SET Requirements = ( $(MY.Requirements) ) && TARGET.HasEncryptExecuteDirectory @end
with condor_q -l for the submitted job again showing: EncryptExecuteDirectory = false
condor_config_val -dump -verbose shows: JOB_TRANFORM_NAMES = Encrypt # at: C:\PROGRA~1\condor/condor_config.local, line 5 # expanded: Encrypt JOB_TRANSFORM_Encrypt = SET EncryptExecuteDirectory = true # at: C:\PROGRA~1\condor/condor_config.local, line 10 # expanded: SET EncryptExecuteDirectory = true
Any suggestions? Is there anything, e.g. logs I can look at? Have I done something dumb?
Thanks
Cheers
Greg
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Todd Tannenbaum
On 8/12/2021 10:32 AM, John M Knoeller wrote:
|