Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Matt Doidge said:
> Atlas still can't install at our site as they use the
> WMS, which is having trouble finding our subclusters on our
> lcg-CE (even
> though we seem to be publishing all the information). Our
> atlas insider
> has told us this is down to us failing this query:
>
> ldapsearch -x -h $LCG_GFAL_INFOSYS -b 'o=grid'
> 'GlueServiceDataKey=GlueSubClusterUniqueID:quads.lancs.ac.uk'
I think there are some wires slightly crossed there ... the GlueService
entry that that Key refers to is independent of the SubCluster/CE
publishing itself and shouldn't have anything to do with WMS matching
per se. However it is possible that something else is querying for it,
and indeed you aren't publishing it. It should belong to a GlueService
object with a Type of org.glite.RTEPublisher, which publishes the
gridftp (or https) endpoint which is used to write the
RunTimeEnvironment tags for installed software.
> My question to the resident GridPP sages is can we coax the
> GlueServiceDataKey attribute into our information system
> without hitting
> it with the sledgehammer of yaim and running a full on
> config_gip (which
> then might not help). Our CE is up to date, although the information
> system hasn't been reconfigured in a while so that side of it
> could be crusty.
Well, it's likely that your old configuration is indeed the reason it's
missing. Looking back it seems to have come with update 49 in July so
you are quite a way behind. In principle you could no doubt unpick what
yaim does and do it by hand (basically it creates a small wrapper script
to call glite-info-service), but is there really a good reason not to
just run YAIM? (config_info_service_rtepublish is the relevant function,
but you may be missing other things too.)
Stephen
--
Scanned by iCritical.
|