Mailing List Archives

Public Access

 		[Computer Systems Lab]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Issue Getting Apache to Submit Condor Job

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
    <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
            <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/



        --
        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