we here at GSI try to setup a global-PROOF-cluster on different institutes.
Unfortunately we are not able to authentificate via GLOBUS on our LSF-Cluster.
Even if we try to start the master and the slaves on the same host, the authentification
(between master and slaves, between client and master the authentification is successfull) fails.
We are not sure if we must initialize the globus-proxy on every host or only on the master-host. According to the manual it says:
“If the master requires globus-credentials for authentification to slaves, these are automatically transmitted to the slaves via a shared memory.”
We have tried different configurations but without success.
In this configuration the started the globus-session in user-mode with an globus-proxy on the master-host. But the slave-output says that we have to init the globus-proxy on the slave-hosts.
The debug-output is from following configuration :
root-session on lxts04
master on lxts04
slave1 on lxi001
slave2 on lxi002
If anybody outthere can help we’ll be very gratefully.
I think that the problem comes from the fact that the proofd
servers on the slaves are unable to access either a valid
proxy or a host certificates/keys.
Client credentials are automatically forwarded to the master
for use vis-a-vis of the slaves. However, the globus
functions require initialization also of server credentials,
which is done using the host certificate and key; the latter
requires superuser privileges to be read, so this works fine
only for daemons started as superuser (or by xinetd).
A work around for daemons started from an unprivileged
account (as, I believe, is your case) is to use the account
(=user) proxies. This is what happens on your master,
which is the same as your client machine, so the proxy are
initialized and everything works fine; however, on the slaves
there are no proxies and the thing fails.
If the problem is this then, at the moment, there are two
possible ways out:
start proofd via xinetd
logon to each slave machine and initialize by hand the
proxies of the account where you start proofd; I know,
this is very annoying if you have a large number of
slaves, but this is what globus_gss_assist_acquire_cred
wants; we are currently devising a light GSI
authentication package which would avoid this problem.
For the time being you should use tricks like init very long
lasting proxies (so that you don’t have to re-init very
often); or, if the user id is the same on all the machines,
perhaps you could even think of scp-ying or sftp-ing the
client /tmp/x509u_ to the slave machines.
Please, try solution 2 on your two-slave setup and let me
know how it goes.