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).
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
- from lxplus, it works instead, in both 770 and 775 cases
- glubus-url-copy always fails both from our UI and lxplus
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? 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).
Finally, given all the above, can I be satisfied that our DPM is working
fine (aside from the accuracy of the storage it advertises)??
cheers,
gianfranco
|