Ah, you're using the quickstart. Yes, there's an ownership problem I
just discovered today with the quickstart. If you look in syslog, you
should see myproxy complaining about the ownership of $GLOBUS_LOCATION/
var/myproxy.
I've updated the xinetd entry in the quickstart to start the myproxy
server as the globus user instead of the root user. The $GL/var/
myproxy directory is first created in the quickstart by the myproxy-
admin-adduser command, which runs as globus. Jim, do you have any
opinion about the merits of running as root vs. globus? The other
solution would have been to make root run the myproxy-admin-adduser
commands, but then root also has to be the one who sets up the
simpleCA, which seemed suboptimal to me.
Charles
On Aug 19, 2008, at 2:53 PM, [EMAIL PROTECTED] wrote:
Hi Jim,
Thanks for your answer.
I am performing the GT4.2 Quickstart procedure on a new installation
directory and therefore pcd10238 has no certificates left from
another previous GT installation. I have purged them from ~/.globus.
When I shift right before the "Setting up your security on your
first machine" from GT4.2 Quickstart procedure to the GT4.0.x
Quickstart and proceed from that point on to the end, I succeed to
get the certificates for pcd10238 working. Therefore I thinks it is
not a problem with xinetd. (?)
It seems that there is some step missing in the new procedure (GT4.2
Quickstart).
I've run the grid-proxy-init -debug -verify and I've got the
following messages
[EMAIL PROTECTED]:/home/pcd/10238> grid-proxy-init -debug -verify
ERROR: Couldn't find valid credentials to generate a proxy.
grid_proxy_init.c:557: 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
[EMAIL PROTECTED]:/home/pcd/10238>
Let me know if you need further info.
Klaus
Jim Basney <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
18/08/2008 23:41
To
[EMAIL PROTECTED]
cc
[email protected]
Subject
Re: [gt-user] myproxy-logon Failed reading length 0 (GT 4.2.0)
I'm not sure what's causing the error, but one thing I notice:
> [EMAIL PROTECTED]:/home/pcd/10238> myproxy-logon -v -s pc222771
> MyProxy v4.2 10 Jan 2008
> Attempting to connect to 10.6.3.209:7512
> using trusted certificates directory
> /sandbox/globus/globus-4.2.0/share/certificates
> Failed reading length 0
> Error authenticating: Connection closed.
I'd expect to see the following in the output above:
"no valid credentials found -- performing anonymous authentication"
It makes me think that perhaps pcd10238 already has a credential
(from a
previous GT installation?) and that credential isn't accepted by the
myproxy-server for some reason. Unfortunately, the myproxy-server's
error message isn't very helpful (at least to me).
If pcd10238 does have an existing proxy credential, does it help to
run
grid-proxy-destroy before myproxy-logon?
For example, here's the output I get:
$ myproxy-logon -v
MyProxy v4.2 10 Jan 2008 PAM
Attempting to connect to 141.142.15.40:7512
using trusted certificates directory /etc/grid-security/certificates
no valid credentials found -- performing anonymous authentication
server name: /C=US/O=National Center for Supercomputing
Applications/CN=myproxy.ncsa.uiuc.edu
checking that server name is acceptable...
server name does not match "[EMAIL PROTECTED]"
server name matches "[EMAIL PROTECTED]"
authenticated server name is acceptable
Enter MyProxy pass phrase:
A credential has been received for user jbasney in /tmp/x509up_u25555.
The "no valid credentials found" message should appear before the
start
of the SSL handshake if there are no credentials available to the
client, and the error seems to be happening during the SSL
handshake, so
I'd expect to see that message before the error.
It's also odd that you get different output from myproxy-logon
depending
on whether you run the myproxy-server via xinetd or from the
command-line. In the former case, it seems that xinetd is failing to
start the myproxy-server, perhaps because LD_LIBRARY_PATH isn't set or
some other problem with /etc/xinetd.d/myproxy, so the network
connection
is closed before the client can ready any bytes. Is there any useful
syslog output for this case?
Sorry all I can offer is guesses...
-Jim
This message is intended solely for the use of its addressee and may
contain privileged or confidential information. If you are not the
addressee you should not distribute, copy or file this message. In
this case, please notify the sender and destroy its contents
immediately.
Esta mensagem é para uso exclusivo de seu destinatário e pode conter
informações privilegiadas e confidenciais. Se você não é o
destinatário não deve distribuir, copiar ou arquivar a mensagem.
Neste caso, por favor, notifique o remetente da mesma e destrua
imediatamente a mensagem.