Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
On 4/7/2016 12:23 PM, Antelmo Aguilar wrote:
Hi All,
I wanted to give an update. I was messing around with the security of
HTCondor and I still have not been able to get it to work.
I set SEC_DEFAULT_AUTHENTICATION = NEVER and SEC_CLIENT_AUTHENTICATION =
NEVER, and that still gave me an error message (not the same one though).
By any chance is there a way of removing the authentication?
I suggest getting rid of your changes to SEC_*_AUTHENTICATION you made above so they go back to the defaults. The reason the above didn't help is the schedd forces authentication to happen when adding or removing jobs from the queue.
Instead I'd suggest try putting the following into your condor_config on your portal machine:
 SEC_DEFAULT_AUTHENTICATION_METHODS = FS
and then do a condor_reconfig. This should effectively remove GSI authentication as one of the default authentication methods, and from your error messages it looks like GSI was causing the problems.
If the above doesn't do the trick, and you really want to effectively remove authentication, you could do
 SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
and/or
 QUEUE_ALL_USERS_TRUSTED = True
See the Manual for details on the above knobs. This will effectively disable authentication, and thus it is a very insecure HTCondor setup -- anybody who has access to your schedd can submit jobs claiming to be any user (!), and can also remove any jobs. You should be certain that nobody other than your portal can your HTCondor daemons, i.e. this pool had better not be visible on the internet :).
Hope the above helps.
Todd
Also, if not possible, by any chance do you guys have a RHEL 7 stripped
tarball for version 8.0.6? I would like to see if I still have the same
issue with that version. If not, then I will just compile the code. I
would like to avoid that if possible though ^_^.
Thanks and I appreciate your help.
-Antelmo
On Wed, Apr 6, 2016 at 11:54 AM, Antelmo Aguilar
<Antelmo.Aguilar.17@xxxxxx <mailto:Antelmo.Aguilar.17@xxxxxx>> wrote:
  Hi All,
  Thank you for your responses and apologies for responding until
  now. For Todd's question. I was able to verify that the script is
  being executed by the Apache user with uid 48.
  Also, we are not specifying any kind of proxy or any kind of
  authentication in the submission scripts. Here is a sample
  submission script:
  *universe    = vanilla*
  *executable   = /opt/local/blast/bin/blastn*
  *output     =
  /data/web/root/data/job_results/users/122708.results.Aedes-aegypti_EST-CLIPPED_2012-12.fa.out*
  *log      Â=
  /data/web/root/data/job_results/users/122708.results.Aedes-aegypti_EST-CLIPPED_2012-12.fa.log*
  *error     Â=
  /data/web/root/data/job_results/users/122708.results.Aedes-aegypti_EST-CLIPPED_2012-12.fa.err*
  *
  *
  *Arguments = -query
  /data/web/root/data/job_results/users/122708.query.fa -db
  /vectorbase/dbs/Aedes-aegypti_EST-CLIPPED_2012-12.fa -word_size 11
  -evalue 10 -num_alignments 10 -num_descriptions 10 -task blastn*
  *
  *
  *Initialdir     = /data/web/root/data/job_results/users*
  *Transfer_executable = false*
  *Queue*
  *
  *
  Also, as mentioned earlier, if I submit a job through my account
  when logged into the server, the jobs runs without any issues.
  Also, I changed to the apache user by doing the following command as
  root "su -s /bin/bash apache" and opening a php shell and running
  the exact commands I use to submit the job through Drupal and the
  job runs without any issues.
  Thanks,
  Antelmo
  On Fri, Apr 1, 2016 at 12:26 PM, Todd Tannenbaum      <mailto:htcondor-users-request@xxxxxxxxxxx> with a  <tannenba@xxxxxxxxxxx <mailto:tannenba@xxxxxxxxxxx>> wrote:
    On 4/1/2016 9:58 AM, Iain Bradford Steers wrote:
      In particular I notice this error line:
      globus_sysconfig: File does not exist: /tmp/x509up_u0 is not
      a valid file
      Are you specifying a specific proxy file in your submit
      files or just
      'use_x509userproxy'
      Thanks,
      Iain
    In addition to wisdom from Iain and Brian, the above proxy name
    implies to me that condor_submit is being run as root (uid 0),
    not as the Apache user as you say below. This is not a good idea
    and probably not what you wanted to do. Or perhaps the uid for
    the apache user on your system is 0 (yikes!) ?
    regards
    Todd
      Recently we upgraded our server from RHEL6 to RHEL7 and I
      installed the
      newest stable version of HTCondor (8.4.5 from 8.0.6). When
      submitting
      jobs through the terminal, everything works correctly.
      However, when
      letting Drupal submit the jobs (as the Apache user), I get
      this error:
      04/01/16 10:29:23 (pid:21220) authenticate_self_gss:
      acquiring self
      credentials failed. Please check your Condor configuration
      file if this
      is a server process. Or the user environment variable if
      this is a user
      process.
      GSS Major Status: General failure
      GSS Minor Status Error Chain:
      globus_gsi_gssapi: Error with GSI credential
      globus_gsi_gssapi: Error with gss credential handle
      globus_credential: Valid credentials could not be found in
      any of the
      possible locations specified by the credential search order.
      Valid credentials could not be found in any of the possible
      locations
      specified by the credential search order.
      Attempt 1
      globus_credential: Error reading host credential
      globus_sysconfig: Could not find a valid certificate file:
      The host cert
      could not be found in:
      1) env. var. X509_USER_CERT
      2) /etc/grid-security/hostcert.pem
      3) $GLOBUS_LOCATION/etc/hostcert.pem
      4) $HOME/.globus/hostcert.pem
      The host key could not be found in:
      1) env. var. X509_USER_KEY
      2) /etc/grid-security/hostkey.pem
      3) $GLOBUS_LOCATION/etc/hostkey.pem
      4) $HOME/.globus/hostkey.pem
      Attempt 2
      globus_credential: Error reading proxy credential
      globus_sysconfig: Could not find a valid proxy certificate
      file location
      globus_sysconfig: Error with key filename
      globus_sysconfig: File does not exist: /tmp/x509up_u0 is not
      a valid file
      Attempt 3
      globus_credential: Error reading user credential
      globus_sysconfig: Error with certificate filename: The user
      cert could
      not be found in:
      1) env. var. X509_USER_CERT
      2) $HOME/.globus/usercert.pem
      3) $HOME/.globus/usercred.p12
      04/01/16 10:29:23 (pid:21220) DC_AUTHENTICATE: authentication of
      <192.168.1.80:49952 <http://192.168.1.80:49952>
      <http://192.168.1.80:49952>> did not result in a
      valid mapped user name, which is required for this command (1112
      QMGMT_WRITE_CMD), so aborting.
      04/01/16 10:29:23 (pid:21220) DC_AUTHENTICATE: reason for
      authentication
      failure: AUTHENTICATE:1003:Failed to authenticate with any
      method|AUTHENTICATE:1004:Failed to authenticate using
      GSI|GSI:5003:Failed to authenticate. Globus is reporting error
      (851968:713). There is probably a problem with your
      credentials. (Did
      you run grid-proxy-init?)|AUTHENTICATE:1004:Failed to
      authenticate using
      KERBEROS|AUTHENTICATE:1004:Failed to authenticate using
      FS|FS:1004:Unable to lstat(/tmp/FS_XXXMX9YKD)
      Also, I wanted to say that everything works fine in our
      RHEL6 server
      using HTCondor 8.0.6. I have been searching to see if
      anyone else had a
      similar problem, but I was not able to find anything. I really
      appreciate the help.
      Thank you,
      Antelmo
      _______________________________________________
      HTCondor-users mailing list
      To unsubscribe, send a message to
      htcondor-users-request@xxxxxxxxxxx
      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/
    --
    Todd Tannenbaum <tannenba@xxxxxxxxxxx
    <mailto:tannenba@xxxxxxxxxxx>> University of Wisconsin-Madison
    Center for High Throughput Computing ÂDepartment of Computer
    Sciences
    HTCondor Technical Lead        1210 W. Dayton St. Rm #4257
    Phone: (608) 263-7132 <tel:%28608%29%20263-7132>
     ÂMadison, WI 53706-1685
    _______________________________________________
    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 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/
--
Todd Tannenbaum <tannenba@xxxxxxxxxxx> University of Wisconsin-Madison
Center for High Throughput Computing ÂDepartment of Computer Sciences
HTCondor Technical Lead        1210 W. Dayton St. Rm #4257
Phone: (608) 263-7132Â Â Â Â Â Â Â Â Â Madison, WI 53706-1685
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to 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/