Here is Jean-Philippe's explanation :

All physical files on disk belong to a special user "dpmmgr" and are only accessible by this user.

RFIOD and gsiFTP which are launched as root have been modified to check with the DPNS (DPM Name Server) if the client is authorized to open (or delete or ...). Then RFIOD or gsiFTP does the open on behalf of the user and returns an handle that can be used in rfio_read/rfio_write ...

The disk server must be trusted by the DPNS using entries in shift.conf of the form :

DPNS TRUST disk_server1 disk_server2 ...

The users are mapped using the standard grid-mapfile.

If the gliteIO daemon runs with a host/service certificate and is modified to be DPM-aware i.e. to contact the DPNS, everything is ok.

If you do not want to modify gliteIO daemon, and gliteIO runs as the client, you may still access data on other disk servers using RFIO, but you cannot access the data residing on the same machine as the glieteIO daemon because in this case the file is seen as local and RFIO does not use RFIOD.

One solution which was explained to Gavin and his successors was: it is possible to modify RFIO to use RFIOD even if the file is local. The cost is an extra copy operation between RFIOD et gliteIO servers. The modification is not very difficult but is not very high on our list of priorities either.

Please note that you will encounter the same problem with CASTOR as soon as the secure version of CASTOR is released.

-- SophieLemaitre - 26 Sep 2005

This topic: LCG > WebHome > LCGGridDeployment > LCGSoftware > DataManagementTop > DataManagementDocumentation > LfcTroubleshooting > GliteIOAndDpm
Topic revision: r1 - 2005-09-26 - unknown
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback