On Thursday 08 Dec 2005 16:38, gianfranco sciacca wrote:
> On Thu, 2005-12-08 at 13:18, Graeme Stewart wrote:
> > gianfranco sciacca wrote:
> > > I attach the output of srmcp into the DPM (successful) and trying to
> > > srmcp the same file back to the UI (fails). I also attach what appears
> > > on /var/log/messages on the DPM head node.
> >
> > Just a thought - when the dpm-gridftp gets a "normal" path, i.e., one of
> > the old sfn:// SURLs, does it not change its uid/gid to the pool
> > account? So it will be trying to access these files as atlasNNN:atlas.
> > This means the 770 permissions for dpmmgr:dpmmgr prevent the file from
> > being read.
> >
> > Try 775 for the directories, and chowning the old atlas files back to
> > the atlas group (or even just one to test).
>
> ok, with chmod 775 and files owned by dpmmgr on the pool node, lcg-cp of
> atlas data from the pool node works again (it fails with 770).
OK, so better ;-)
>
> Besides this I have established that:
> - from our UI, srmcp of atlas data from the pool node fails in both the
> 770 and 775 cases
srmcp using what SURL? The dpns nameserver entry created by the migration
script, I presume? The olf sfn:// SURLs I would not expect to be accessible
via the SRM.
> - from lxplus, it works instead, in both 770 and 775 cases
That's weird. Could you do it with -debug in both cases and look for any
differences in the SURL->TURL mappings. And what the error message is on the
UI.
> - glubus-url-copy always fails both from our UI and lxplus
What TURL are you using in this case?
>
> I take it this is due to the fact that different copy methods use
> different protocols behind the scenes and there might be firewall issues
> on the UI and/or SE?
Ultimately they all come down to a gridftp for the low level data transport. I
would make sure you have _no_ firewalling between the head node and the pool
nodes, because rfio also uses dynamic ports for data transport (and I can't
find a RFIO_PORT_RANGE anywhere).
> Is there a recommendation for the ports needed on
> the DPM pool node? We have opened the 5015, 5010, 8443, 8444, 5001, 2811
> and 20000-25000 on the DPM head node, but have left the pool node with
> its previous port settings for classic_SE (5001, 2811, 20000-25000 and
> 2135 to the Mon box).
Internally between the DPM nodes open everything. Externally, open 8443, 2811
and GLOBUS_PORT_RANGE (20000-25000) for gridftp/srm data transfers. Open 5010
and 5015 to enable DPNS and DPM queries and commands, respectively (I'd
recommend this). I would not open 5001 - that's for rfio, and I would
restrict that to the DPM nodes themselves. And to get it fully working you
need the dynamic rfio ports open too (everything > 1024 I think).
>
> Finally, given all the above, can I be satisfied that our DPM is working
> fine (aside from the accuracy of the storage it advertises)??
If it passes the gridftp and srm tests of
https://wiki.gridpp.ac.uk/wiki/DPM_Testing from the UI and lxplus then it is
functional for external users I'd say. (If you block rfio to the world than
you can only pass the rfio tests from an allowed node, say the pool to the
admin node.)
Did you do anything about remounting the /storage/atlas partition yet?
cheers
g
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
|