 |
 |
Hi Fabrizio, So, I tried setting oss.localroot (and r/w) , but the data server still insists that it doesn't have write access to the filesystem and so sets itself to read only. Since it is being run as dpmmgr user, and the filesystem is owned by that user and is mode 0700, I'm at a bit of a loss to explain this. Thank you for the CERN link - I've been using the packages from the slac link, so at least the version of xrootd I have is reasonably up to date. Unfortunately, I doubt that I can directly use the all-in-one version without modifying it anyway, since I need to run the services on non-standard ports - I'm trying to run this initial test xrootd service on a head node which already hosts a dpm server (and dpm-xrootd plugins), so I can't use the default ports. (The style of the configuration files is based on the Example files provided on the SLAC website. Perhaps the examples need a bit of updating ;) ) Sam 2009/5/6 Fabrizio Furano <[log in to unmask]>: > Hi Sam, > > you should specify r/w in the export directive of the data server, writing > this: > > xrootd.export /gridstore4 r/w > > Then please verify that you are specifying the correct localroot option. > > Moreover, the config files you wrote look really obsolete, and probably > valid for very old versions. My suggestion is to get a newer package and > refer to the online documentation to configure it. Things are much simpler > now, in the sense that fewer directives are needed. > > Depending on your preferences, there are two flavors of the bundle which > you can get: the vanilla one and the 'automatic all-in-one' one. > Respectively, you can find the first here: > > http://xrootd.slac.stanford.edu > (or you can take the tarball from the last ROOT version) > > and the second here: > > http://savannah.cern.ch/projects/xrootd > > Fabrizio > > > Sam Skipsey wrote: >> >> Hello, all: >> >> I may be being stupid here, but: >> >> I'm in the initial phase of messing around with xrootd here at >> Glasgow, and I can't seem to get my diskserver to add itself as >> writeable. >> >> The arrangement is: >> svr025.gla.scotgrid.ac.uk running as a redirection server (xrootd on >> port 2525 and olbd on 2526) >> disk042.gla.scotgrid.ac.uk (for example) running as a data server >> (same services on same ports) >> >> The config for the two is: >> >> redirector: >> # >> # redirectserver.cf >> # >> # xrootd >> xrootd.port 2525 >> xrootd.fslib /root/20090202-1402/lib/libXrdOfs.so >> xrootd.export /gridstore4 >> #oss.readonly >> odc.manager svr025.gla.scotgrid.ac.uk 2526 >> odc.trace redirect >> # olbd >> olb.port 2526 >> olb.allow host disk042.gla.scotgrid.ac.uk >> olb.allow host svr025.gla.scotgrid.ac.uk >> ofs.redirect remote svr025.gla.scotgrid.ac.uk >> xrootd.allow host svr025.gla.scotgrid.ac.uk >> >> >> dataserver: >> # >> # dataserver.cf >> # >> # xrootd >> xrootd.port 2525 >> xrootd.fslib /root/20090202-1402/lib/libXrdOfs.so >> xrootd.export /gridstore4 >> #oss.readonly >> odc.manager svr025.gla.scotgrid.ac.uk 2526 >> # olbd >> olb.port 2526 >> olb.subscribe svr025.gla.scotgrid.ac.uk 2526 >> ofs.redirect remote svr025.gla.scotgrid.ac.uk >> oft.redirect target >> >> >> However, when disk042 connects to the redirection server, I see: >> >> 090506 14:19:21 31690 olb_Manager: server disk042 defaulted r / >> >> and on the disk: >> 090506 14:18:01 001 olb_Meter: Warning! No writable filesystems found; >> write access and staging prohibited. >> >> and, indeed, xrdcp to disk042 fails (but copying from it works perfectly). >> The exported filesystem (/gridstore4) is writable by the user owning >> the xrootd processes, however (indeed, it is owned by the same user, >> with mode 770). >> >> This is probably something stupid, but... any help appreciated. >> >> Sam Skipsey >> Glasgow >