Okay. What happens if the client submits:
globus-job-run ardbeg.cs.st-andrews.ac.uk::/O=Grid/OU=SCIEnce/CN=host/
ardbeg.cs.st-andrews.ac.uk
Still get an authorization error? I'm wondering if the issue is
reverse DNS authorization troubles rather than CA troubles. I'd
expect a different error message then, but it seems like it is worth
checking.
If you have a recent openssl installation (that is., not the one from
4.0.1) try this command:
openssl x509 -in <hostcert> -noout -issuer_hash
openssl x509 -in <usercert> -noout -issuer_hash
If your openssl doesn't support issuer_hash, just use issuer. That
might help us distinguish whether the signing CAs are really the same
or not.
Charles
On Mar 12, 2009, at 3:46 PM, Vladimir Janjic wrote:
yes, user's certificate is signed by the same CA.
this is the output of grid-proxy-init -debug -verify
[...@ardbeg ~]$ grid-proxy-init -verify -debug
User Cert File: /home/vj/.globus/usercert.pem
User Key File: /home/vj/.globus/userkey.pem
Trusted CA Cert Dir: /etc/grid-security/certificates
Output File: /tmp/x509up_u516
Your identity: /O=Grid/OU=SCIEnce/CN=Vladimir Janjic
Enter GRID pass phrase for this identity:
Creating proxy ......++++++++++++
......++++++++++++
Done
Proxy Verify OK
Your proxy is valid until: Fri Mar 13 08:40:51 2009
here are the lines from usercert.pem and hostcert.pem, if that helps
usercert.pem :
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 98 (0x62)
Signature Algorithm: md5WithRSAEncryption
Issuer: O=Grid, OU=SCIEnce, CN=IeAT CA
Validity
Not Before: Jun 9 14:40:05 2008 GMT
Not After : Jun 9 14:40:05 2009 GMT
...
hostcert.pem :
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 131 (0x83)
Signature Algorithm: md5WithRSAEncryption
Issuer: O=Grid, OU=SCIEnce, CN=IeAT CA
Validity
Not Before: Mar 9 13:34:31 2009 GMT
Not After : Mar 9 13:34:31 2010 GMT
Subject: O=Grid, OU=SCIEnce, CN=host/ardbeg.cs.st-
andrews.ac.uk
vladimir
On Thu, Mar 12, 2009 at 8:34 PM, Charles Bacon <[email protected]>
wrote:
Could still be a permissions issue in /etc/grid-security/
certificates. Is the user's certificate signed by the same CA?
What is the output of grid-proxy-init -debug -verify?
-c
On Mar 12, 2009, at 2:20 PM, Vladimir Janjic wrote:
Thanks very much for the answer, Charles!
But, unfortunately this didn't fix the error. the entry for
gatekeeper is
service gsigatekeeper
{
socket_type = stream
protocol = tcp
wait = no
user = root
env = LD_LIBRARY_PATH=/usr/local/globus-4.0.1/lib
server = /usr/local/globus-4.0.1/sbin/globus-gatekeeper
server_args = -conf /usr/local/globus-4.0.1/etc/globus-
gatekeeper.conf
disable = no
}
so, it doesn't set any X509_* variable in 'env = ...'. issuer of /
etc/grid-security/hoscert.pem is the CA that exists in /etc/grid-
security/certificates (actually, it is the same issuer as for
another two machines on which everything works, and /etc/grid-
security/certificates
is the same on all three machines). i don't have X509_* set in my
environment, and i only have certificate in mu .globus directory.
i assume that error must be somewhere in my local setup, but i
cannot find out where
thanks a lot,
vladimir
On Thu, Mar 12, 2009 at 6:44 PM, Charles Bacon <[email protected]>
wrote:
Your local client does not trust the gatekeeper, guaranteed. The
"delegation protocol violation" the gatekeeper is reporting is that
the client is disconnecting before performing delegation. The only
reason the client would disconnect like that is because it failed to
authorize the gatekeeper's certificate.
Double-check your xinetd entry for the gatekeeper to make sure no
X509_* environment variables are being set. Then check the issuer
of your /etc/grid-security/hostcert.pem. Then check that that CA
exists in the /etc/grid-security/certificates directory. Then
double-check that your client environment doesn't have any X509_*
variables set. Then make sure you don't have a $HOME/.globus/
certificates directory.
One of those diagnostic steps should reveal where the problem is.
Charles
On Mar 12, 2009, at 1:31 PM, Vladimir Janjic wrote:
Hi all,
I am having a problem with Globus 4.0.1 and I don't have any idea
what is causing it and how can I solve it.
The problem is I cannot submit any job to the Gatekeeper, because I
get
GRAM Job submission failed because an authorization operation failed
(error code 7)
error. The globus-gatekeeper.log file gives the following error when
i try to run, for example,
globus-job-run ardbeg.cs.st-andrews.ac.uk /bin/date :
TIME: Thu Mar 12 18:16:52 2009
PID: 28192 -- Notice: 6: Got connection 138.251.214.66 at Thu Mar
12 18:16:52 2009
GSS authentication failure
GSS Major Status: General failure
GSS Minor Status Error Chain:
globus_gsi_gssapi: Error during delegation: Delegation protocol
violation
Failure: GSS failed Major:000d0000 Minor:00000001 Token:00000000
TIME: Thu Mar 12 18:16:52 2009
PID: 28192 -- Failure: GSS failed Major:000d0000 Minor:00000001
Token:00000000
I am submitting the job to the gatekeeper which is on the same
machine. I have read somewhere that the
problem might be that my certificate doesn't trust the host's
certificate, and that it is disconnecting from gatekeeper
immediately.
But, I can easily run jobs on gatekeeper locally on one other
cluster (wnxxx.grid.info.uvt.ro), using the same user certificate as
on ardbeg.cs.st-andrews.ac.uk. Also, the
hostcert.pem on the wnxxx.grid.info.uvt.ro cluster is signed by the
same CA as hostcert.pem on ardbeg.cs.st-andrews.ac.uk machine, and
files in /etc/grid-security/certificates are
the same on both machines.
I am desperate, because I need to run some tests on this machine,
but I cannot because of these problems.
Please help!!!!!!!!
Vladimir
