On Feb 1, 2017, at 9:04 AM, Feldt, Andrew N. <afeldt@xxxxxx
<mailto:afeldt@xxxxxx>> wrote:
This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing <http://aka.ms/LearnAboutSpoofing> Feedback <http://aka.ms/SafetyTipsFeedback>
Zach,
Unfortunately, this does not work in all environments. We are an
NFS/NIS set of systems. Without the fix you have suggested, condor_q
works for the submitter or a queue super user directly from the
submitting host but not from any other node (where one would have to
use the -g flag). However, after setting the two variables below,
condor_q does not even work from the submitting node.
An analysis of the logs (without the fix) shows that ‘condor_q -g’
from a non-submitting node fails because no authentication method
works. We use ‘FS’ authentication which works for 8.4 in our NFS
environment on RHEL 7.3 with SELinux enabled, but fails for 8.6.0.
Andy
*Andy Feldt*
/Senior System Support Programmer/
/Affiliate Assistant Professor/
Homer L. Dodge Department of Physics & Astronomy
The University of Oklahoma
On Feb 1, 2017, at 6:27 AM, Zach Miller <zmiller@xxxxxxxxxxx
<mailto:zmiller@xxxxxxxxxxx>> wrote:
This is indeed a problem, related to the new behavior of having
condor_q show only the jobs for the user running condor_q.
Unfortunately, it’s not as simple as running ‘condor_q –allusers’ to
return to the old behavior. For the time being, if you want to use
8.6.0 you’ll need to change:
SEC_DEFAULT_AUTHENTICATION = OPTIONAL
SEC_DEFAULT_NEGOTIATION = OPTIONAL
This does add some overhead in terms of network traffic, but it does
work. We’ll take a deeper look at how to address this, but in the
meantime I just wanted to put that workaround out there.
Cheers,
-zach
On 2/1/17, 12:22 AM, "HTCondor-users on behalf of
Greg.Hitchen@xxxxxxxx <mailto:Greg.Hitchen@xxxxxxxx>"
<htcondor-users-bounces@xxxxxxxxxxx
<mailto:htcondor-users-bounces@xxxxxxxxxxx> on behalf of
Greg.Hitchen@xxxxxxxx <mailto:Greg.Hitchen@xxxxxxxx>> wrote:
Hi All
Thought I'd have a look at the latest stable release but have had
some issues/problems.
I have tried this on win7 32 bit with 32 bit condor 8.6.0, win7 64
bit with 32 bit condor 8.6.0,
win2008 server 64 bit with 32 bit condor 8.6.0, and win2008 server
64 bit with 64 bit condor 8.6.0
Lastly I have tried it on Ubuntu1604 64 bit.
I have the same problem with all of the above combinations.
Security: host based
I'm testing the 8.6.0 version using the same condor_config files
that work for 8.4.4 (and previous versions).
If I try a condor_q command on the submit node for 8.6.0 I get:
condor_q
-- Failed to fetch ads from:
<152.83.64.39:9618?addrs=152.83.64.39-9618&noUDP&sock=4488_72cc_3> :
WIN2008-GJH9-VC.nexus.csiro.au <http://win2008-gjh9-vc.nexus.csiro.au/>
If I run the 8.4.4 condor_q executable it works and I get:
c:\condor-8.4.4\bin\condor_q
-- Schedd: WIN2008-GJH9-VC.nexus.csiro.au
<http://win2008-gjh9-vc.nexus.csiro.au/> : <152.83.64.39:9618?...
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
In fact I can run the 8.4.4 version of condor_q from any other
submit node using the -name option
and that works OK as well.
Turning on FULL_DEBUG gives the following in the schedd log file:
01/31/17 15:27:33 Calling Handler
<DaemonCommandProtocol::WaitForSocketData> (6)
01/31/17 15:27:33 Failed to read end of message from
<152.83.64.39:60746>; 310 untouched bytes.
01/31/17 15:27:33 AUTHENTICATE: handshake failed!
01/31/17 15:27:33 DC_AUTHENTICATE: Our security policy is invalid!
01/31/17 15:27:33 Return from Handler
<DaemonCommandProtocol::WaitForSocketData> 0.000196s
The above bit about "Failed to read end of message" seems strange?
As does the AUTHENTICATE
lines. For reference we have the following config lines some of
which should turn off authentication?
QUEUE_ALL_USERS_TRUSTED = True
SEC_DEFAULT_AUTHENTICATION = NEVER
SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
SEC_DEFAULT_AUTHENTICATION_TIMEOUT = 20
SEC_DEFAULT_NEGOTIATION = NEVER
If I install 8.6.0 from the msi windows installer file (rather
than just unzipping), and therefore use
the generated condor_config file then condor_q works OK.
I have painstakingly compared the output from condor_config_val
-dump- verbose for 8.6.0
using both our 8.4.4 config files and the 8.6.0 generated config
files and cannot see many
differences, and those don't "appear" to be important.
I've tried using the generated condor_config and renaming our
8.4.4 condor_config to condor_config.local
but then the condor_q error is back again.
Any help/suggestions greatly appreciated.
Cheers
Greg
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to
htcondor-users-request@xxxxxxxxxxx
<mailto:htcondor-users-request@xxxxxxxxxxx> with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
<mailto:htcondor-users-request@xxxxxxxxxxx> with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
<mailto:htcondor-users-request@xxxxxxxxxxx> with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}