Thanks for the explanation John, my academic interest has been satisfied.
😉 And as you mentioned, it works OK in the 9.0.* series (I tried 9.0.5). For our setup (currently all 8.8.12) we will be going the job transform method, with immutable job attributes: JOB_TRANSFORM_NAMES = $(JOB_TRANSFORM_NAMES) Encrypt JOB_TRANSFORM_Encrypt @=end #REQUIREMENTS universe =?= vanilla 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 # Do not allow users to edit the value of EncryptExecuteDirectory after submission # via tools like condor_qedit or chirp. IMMUTABLE_JOB_ATTRS = $(IMMUTABLE_JOB_ATTRS) EncryptExecuteDirectory Cheers Greg From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of John M Knoeller 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 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 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> 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:
|